Leveraging the Value of Human Relationships to Improve Health Outcomes

Summary

Objectives

Despite significant awareness on the value of leveraging patient relationships across the healthcare continuum, there is no research on the potential of using Electronic Health Record (EHR) systems to store structured patient relationship data, or its impact on enabling better healthcare. We sought to identify which EHR systems supported effective patient relationship data collection, and for systems that do, what types of relationship data is collected, how this data is used, and the perceived value of doing so.

Materials and methods

We performed a literature search to identify EHR systems that supported patient relationship data collection. Based on our results, we defined attributes of an effective patient relationship model. The Open Medical Record System (OpenMRS), an open source medical record platform for underserved settings met our eligibility criteria for effective patient relationship collection. We performed a survey to understand how the OpenMRS patient relationship model was used, and how it brought value to implementers.

Results

The OpenMRS patient relationship model has won widespread adoption across many implementations and is perceived to be valuable in enabling better health care delivery. Patient relationship information is widely used for community health programs and enabling chronic care. Additionally, many OpenMRS implementers were using this feature to collect custom relationship types for implementation specific needs.

Conclusions

We believe that flexible patient relationship data collection is critical for better healthcare, and can inform community care and chronic care initiatives across the world. Additionally, patient relationship data could also be leveraged for many other initiatives such as patient centric care and in the field of precision medicine.

1. Background

As social animals, humans build complex relationships with one another within the community that they live in [1]. Identifying such relationships between patients and their caregivers, family members/dependents, and healthcare providers can help inform community support structures, identify disease discordance/relationship-based clusters, and improve community health care delivery, thus improving the efficiency, effectiveness, and impact of healthcare [2–4].

In the United States and other developed nations, patient relationship data are critical for supporting the move towards patient centric and patient controlled care models [5]. Relationship data may also contribute to assessing family health history, which helps promote comprehensive patient and family centered care with the potential to impact individual, family, and population-based outcomes [6].

Patient relationship data are also of critical importance for many Low and Middle Income Countries (LMIC), which are defined as countries with a gross national income (GNI) less than 12,736 US dollars per capita in 2014 [7]. In LMIC, relationships play a crucial role in maximizing use of limited health resources by linking patients to various community support structures and community health management programs that enable better healthcare delivery [8, 9]. Relationships also play a pivotal role in managing epidemics and chronic care delivery. As an example, recognizing maternal/child relationships and ensuring that this information is collected within a medical record can impact Human Immunodeficiency Virus (HIV) disease transmission, including maternal-newborn vertical transmission [10]. For Community Health Worker (CHW) initiatives, relationship data are essential to identify which patients are cared for by which CHW and to facilitate community based health status evaluations.

These reasons create a strong argument to collect patient relationship information in Electronic Health Record (EHR) systems. Historically, effective collection of patient relationships was never considered a significant factor in the design of EHR systems. Empirical evidence suggests that such features, if any, have largely been limited to administrative and billing use cases such as the identification of a primary care provider, guardian and/or parent. These data are usually captured in free text form, and represented using a name or contact information field. Existing approaches also fail to leverage family health history data for patient care. To date, family history data are primarily recorded as clinical disease states of family members; these data may be recorded in a structured format or buried deep inside free text clinical and/or social service notes that are not easily accessible to the care delivery team [11]. While it is possible to identify actionable family history information from both structured and unstructured data using natural language processing and chart review, such approaches can be error prone and resource intensive [12]. Also, such data are primarily limited to family member disease burden and do not typically contain information about relationships between patients and their caregivers and/or community members.

2. Objectives

We sought to identify which EHR systems supported effective collection of patient relationship data for clinical purposes, and for such systems, what types of relationship data were collected, how such data were used, and the perceived value of doing so. This analysis will help inform implementers of the benefits of recording patient relationships, which relationship types are most beneficial/useful, and how to design and implement effective relationship data collection models to meet their own needs.

3. Materials and Methods

3.1 Identification of EHR systems that support effective relationship data collection

We performed an extensive literature search across Ovid Medline, Web of Science and EMBASE databases to identify EHR systems that supported relationship data collection (▶ Table 1).

Table 1.

Literature search strategies

Search #	Search terms	No. of Results
(a) Ovid MEDLINE
1	exp Medical Records Systems, Computerized/	29990
2	clinical information system*.mp.	1318
3	exp Caregivers/	25133
4	exp Parents/	85,213
5	exp Legal Guardians/	3148
6	patient relationship*.mp.	20064
7	(1 or 2) and (3 or 4 or 5 or 6)	328
(b) Web of Science
1	TOPIC: (computerized medical records system* OR clinical information system*) AND TOPIC: (caregiver* OR parent* OR legal guardian* OR patient relationship*) AND TOPIC: (informatics) Indexes=SCI-EXPANDED, SSCI, A&HCI, CPCI-S, CPCI-SSH, BKCI-S, BKCI-SSH, ESCI, CCR-EXPANDED, IC Timespan=All years	80
(c) EMBASE
1	‘electronic medical record’/exp OR ‘hospital information system‘/exp OR ‘medical information system‘/exp AND (‘caregiver‘/exp OR ‘parent‘/exp OR ‘legal guardian‘/exp OR patient) AND relationship* AND ‘medical informatics’/exp	55
2	Search strategy #1AND [embase] /lim NOT [medline] /lim	18

Publications identified using the aforementioned approaches were refined based on the following study selection process (▶ Figure 1).

Fig. 1.

The study selection process

Due to a perceived lack of adequate literature, we sought to review as many manuscripts as possible. Thus, we excluded only publications published prior to 1995. We also excluded publications that spoke of qualitative relationships not recorded via EHR systems (ex. the quality of a doctor – patient relationship) and relationship information not collected as part of an EHR, but rather, as a paper record. Out of 481 original articles, only a total of 35 articles were deemed suitable for full review.

Unfortunately, these publications failed to inform our research question. In most cases, publications tended to focus on the quality of human interactions, as opposed to the technical aspects of storing relationship fields in EHR systems. However, the literature search identified Electronic Health Record (OpenEHR, London, UK), an open domain-driven platform [13] that supports the mapping of familial and employment relationships. We found some use of OpenEHR in Europe, where it supported parent – child relationships for maternal care [14] and was also used for research purposes [15]. However, there was little evidence of widespread OpenEHR implementations [16], especially systems that leveraged patient relationship data. Scientific literature [17] and the OpenEHR website [13] indicated that several countries were also developing proof of concept OpenEHR systems. However, the proof of concept systems did not express any plans to leverage patient relationship data.

Another candidate system identified via the literature search was the Open Electronic Medical Record (OpenEMR) [18]. A review of the OpenEMR demo website showed that OpenEMR allows patients to be linked to their spouse or child. However, this is also in support of billing/insurance needs, and not for clinical care [19]. Additionally, OpenEMR stores patient relationships in the form of free text – meaning that the individual a patient is linked to is not a separate entity, but rather, a free text field consisting of a name and/or contact number. Similarly, it was unclear as to how widespread OpenEMR implementation was, and if implementations leveraged patient relationship data. Scientific literature pointed to some use for research purposes in the past [20] and several implementation initiatives [21–23]. However, the current status of these implementations is unclear, and it is unknown if they actively collection patient relationship data.

Our literature search identified the Open Medical Record System (OpenMRS), an open source medical record platform designed specifically for use across underserved settings [24]. Unlike other systems, the OpenMRS platform (OpenMRS Inc, Grandville, Michigan, USA) offers users the ability to capture relationship data in standard format and to create implementation specific relationship types based on their own needs. OpenMRS relationships are mapped between two individuals that are comprised of multiple attributes such as name, contact information, age, gender and address [25]. In comparison to the aforementioned systems, OpenMRS relationships are (a) usable for both clinical and administrative purposes, and not limited to patient/guardian name/contact information for billing needs (b) capture data in structured format not limited to plain text data fields and (c) can be extended to create and record new types of patient relationships as driven by implementation specific needs. We found numerous examples of these features being used to drive clinical care and/or administrative needs in other systems [26–28]. However, we failed to identify any other EHR systems that contained relationship data management features that could support as wide a range of tasks as OpenMRS.

It is also noteworthy that our literature search did not identify any articles that addressed clinical use of relationship data within EHR systems deployed in developed countries, including EHR systems such as Epic (Epic Systems Inc., Verona, Wisconsin, USA) [29], Cerner (Cerner Corporation, North Kansas City, Missouri, USA) [30] or eClinicalWorks (eClinicalWorks Inc., Westborough, Massachusetts, USA) [31]. However, these systems were assessed based on information found on their websites and other technical reports. We found that the patient relationship models of these systems were also very basic and rigid, and greatly limited in what they enabled users to do. While these features were adequate to meet basic billing and administrative needs, they failed to support relevant clinical use cases such as HIV and other chronic illnesses, as described above. They are also inflexible, meaning that they cannot be used to collect data on relationship types other than those built in by default. Thus, none of these systems qualified as effective patient relationship management models.

3.2 The OpenMRS patient relationship model

OpenMRS is an open source EHR platform designed specifically for use across underserved settings. Since its humble beginnings in 2006, OpenMRS has been adopted at local, regional, and national scale in over 40 LMIC countries. Support for storing patient relationship data was first introduced to the OpenMRS data model as part of the OpenMRS 1.0 platform release in 2006. This functionality was introduced in response to the needs of two implementers: Kenya‘s Academic Model Providing Access to Healthcare (AMPATH) program which needed to record discordant HIV couples for their HIV/AIDS programs and Partners In Health (PIH) OpenMRS deployments, which needed to record patient to Community Health Worker (CHW) relationships as part of their Accompagnateur program [32]. Initially, relationships were unidirectional, meaning that only one participant in the relationship (the patient) was aware of which persons they were linked to. However, this was expanded in the next release to support bidirectional relationships mapping. This ensured that both parties in the relationship were aware of their roles within the healthcare system. As an example, in a patient provider unidirectional relationship, the patient is ‚aware‘ of their provider, while the provider is unable to identify patients linked to him via a relationship field. However, in a bidirectional relationship, both participants are aware of their roles and whom they are linked to.

The release of OpenMRS 1.0 platform in 2006 included several core relationship types that were available by default: (a) Doctor Patient, (b) Sibling Sibling, (c) Parent Child and (d) Aunt/Uncle Niece/Nephew. OpenMRS also allowed administrators to create additional relationship types based on implementation specific needs. Relationship data were collected as structured data elements. However, while the OpenMRS platform supported medical terminologies such as SNOMED, Columbia International eHealth Laboratory (CIEL) or Logical Observation Identifiers Names and Codes (LOINC), these terminologies were not intended to model human relationships. Thus, OpenMRS relationship types are not currently linked to any of these terminologies.

3.3 Assessing the collection and use of relationship data by OpenMRS implementers

We designed a questionnaire (Supplementary online Appendix A) to understand how OpenMRS implementations leveraged patient relationship data. For each implementation, we sought to answer the following questions; (a) what relationship types were being used, (b) their levels of use and (c) the real and/or perceived value of collecting relationship data for healthcare delivery.

For the ease of underserved implementations that are understaffed and historically have limited technical support, we abbreviated the questionnaire, and in the case of quantitative questions on the usage of relationship data, provided respondents with SQL commands that they could run on their production servers, and report outcomes. The questionnaire was comprised of five questions and validated by the OpenMRS community. Of these, only one question required a short written description as an answer. The questionnaire [33] was widely publicized on OpenMRS talk, a public community driven forum used by OpenMRS implementers and developers to interact with one another. We also reached out to contacts at several mature OpenMRS implementations, and directed them to our survey posting on OpenMRS talk. Participation in the survey was voluntary.

In evaluating results collected by the first survey, we identified several additional questions. We subsequently emailed respondents directly, and asked them to provide responses to the following additional questions; (a) when was your implementation launched? (b) How many patients does your implementation serve? (Execute „SELECT count (*) FROM patient“ on your database), and (c) What specific kinds of care does your implementation focus on?

4. Results

Our questionnaire posting on OpenMRS talk received a total of 166 unique views and 15 responses from multiple AMPATH home-based catchment areas in Kenya, PIH implementations in Rwanda, Malawi and Lesotho, the Human genetics unit of the facility of medicine, University of Colombo, Sri Lanka, Hospital Albert Schweitzer, Haiti, OpenMRS implementations in Tajikistan and Pakistan, and two implementations of Bahmni [34], an open source hospital information system that uses OpenMRS as a component.

Of these, the implementations in Tajikistan and Pakistan focused on Multi Drug Resistant Tuberculosis (MDR-RB) programs and drug susceptible Tuberculosis care. However, both these implementations described future plans to collect relationship data, and therefore, were removed from the analysis. Of the two Bahmni implementations, one sought to collect case manager patient relationship data for mental health care, while the other proposed to adopt family relationship support for treating indigenous peoples of India. Unfortunately, these were also in the early stages of implementation, and data collection had not yet commenced. Therefore, only 11 of the responses were deemed useable for further evaluation.

We were satisfied with the number of responses collected on the following grounds;

• OpenMRS Talk is the recommended way to communicate with the OpenMRS development and implementer communities.

• The questionnaire was distributed and advertised by an OpenMRS community manager who directly assisted implementations.

• We received responses from major implementations including the AMPATH and PIH sites that led to the introduction of the patient relationship feature. This included a regional healthcare implementation comprised of multiple healthcare facilities spread across a large area. In short, a significant majority of older and well-established OpenMRS implementations that had been collecting patient relationship data over several years responded to the survey.

A detailed breakdown of data collected by our survey can be seen in Appendix B. In consideration to privacy needs, implementations have been de-identified and labeled as implementations A to K in presenting these results.

Based on these results, we assessed the use of core relationship types included in the OpenMRS platform by default (▶ Table 2).

Table 2.

The usage of core relationship types available in the OpenMRS platform

Core relationship type	Frequency of use	Description
Doctor ↔ Patient	33 across one implementation	While this relationship type is used at only one implementation, similar relationships between CHW and patients are widely collected.
Sibling ↔ Sibling	1811 across two implementations	In addition to Sibling Sibling relationships, two implementations have developed other relationship types to record similar blood relationships.
Parent ↔ Child	~224,140 across ten implementations	This relationship type is collected at almost every implementation in our study.
Aunt/Uncle ↔ Niece/Nephew	4525 across five implementations	In addition to Aunt/Uncle ↔ Niece/Nephew relationships, five implementations have developed other relationship types to indicate similar blood relationships.

Based on ▶ Table 2, it was evident that many implementations were not collecting data on certain core relationship types. However, data in appendix B indicated that implementations were creating custom relationship types, and were actively collecting data using these relationship types. A proportionate visualization of the numbers of core and implementation specific relationship types collected across each implementation is as follows (▶ Figure 2). Please note that implementations B, D and E are not included in ▶ Figure 2 as these implementations did not provide counts of each patient relationship type that they collected.

Fig. 2.

A proportionate visualization of core and implementation specific relationship data collection across multiple OpenMRS implementations

A further assessment of the responses in appendix B indicated that many implementation specific relationship types were similar to core relationship types. We categorized all relationship types based on their similarities, frequency of use, and intended usage in clinical care (▶ Table 3). While there are certain logical overlaps between proposed categories (i.e. Patient grandparent and patient relative), we feel that these categorizations should be reported based on their widespread usage.

Table 3.

Categorization of core and implementation specific relationship types in clinical care

Relationship category	Description	Relationship types that belong to this group
Parent/guardian to child	Relationship between patient/guardians and a child	Parent ↔ Child, Guardian (non-parent) ↔ Child, mother child, Foster Child ↔ Foster parent
Patient to grandparent	Relationships between a patient and their grandparents	Grandchild ↔ Grandparent,
Patient to relative	Various blood and in-law relationships	Aunt/Uncle ↔ Niece/Nephew, Sibling Sibling, Child-in-law ↔ Parent-in-law, Stepchild ↔ Stepparent, Cousin ↔ Cousin, Co-wife ↔ Co-wife
Patient to spouse	Spousal relationships	Spouse ↔ Spouse
Patient to Care provider	Relationships between patient and CHW/caregivers or doctors	Patient ↔ CHW, Accompagnateur Patient, Patient ↔ Doctor

▶ Figure 3 presents how each implementation collected data across each of the aforementioned relationship categories. The chart represents data collected on each relationship category as a percentage of total relationship data collected at that implementation. This provides a more comprehensive picture of how each implementation contributed towards the collection of different relationship types. Please note that implementations B, D and E are not included in this chart as these implementations did not provide counts of each patient relationship type that they collected. ▶ Figure 3 was compiled using the aggregate information presented in ▶ Table 4.

Fig. 3.

An aggregate representation of the most widely used relationship categories across implementations, which presents data collected on each relationship category as a percentage against total relationship data collected at that implementation.

Table 4.

A breakdown of patient relationship type counts across each implementation.

Implementation name	Patient ↔ Parent / guardian	Patient ↔ Grandparent	Patient ↔ Family	Patient ↔ Spouse	Patient ↔ Caregiver	Totals
A	112	0	0	0	1280	1392
C	32048	0	0	75	10770	42893
F	96285	9801	5731	18408	33	130258
G	11656	3529	3170	3976	0	22331
H	28919	5166	4211	9927	0	48223
I	16902	2274	2378	5497	0	27051
J	32684	2553	3129	8959	0	47325
K	6525	1030	600	1758	0	9913
Totals	225131	24353	19219	48600	12083

5. Discussion

Our results indicate that the OpenMRS relationship model is a realistic solution to managing patient relationships, and has been used across multiple implementations for multiple needs.

However, ▶ Table 1 clearly shows that core OpenMRS relationship types such as patient doctor and sibling sibling were rarely used. In comparison, the parent child relationship type was used across every implementation under evaluation. ▶ Figure 2 also indicates widespread creation and use of implementation specific relationship types that were relatively similar to the core relationship types (▶ Table 3). While a majority of implementations did not collect patient doctor relationship data, there was significant interest in collecting data on patients and their caretakers/community health workers/village health workers (▶ Table 2). Additionally, while sibling sibling and Aunt/Uncle Niece/Nephew relationship types were less frequently used, implementers had in some instances introduced similar relationship fields such as Co-wife Co-wife, Foster child Foster parent, Friend Friend, and Cousin Cousin for capturing family relationships within an EHR (▶ Table 3).

We believe that implementers’ willingness to create new relationship types, as demonstrated by the significant number of implementation specific relationship types listed in ▶ Table 3, indicates that relationship data are useful in improving healthcare delivery across these implementations. Implementers felt empowered to address their needs by creating implementation specific relationship types that they required. The enthusiasm and commitment to adding implementation specific relationship types also reflects a desire to provide more informed care.

These results indicate that the simplistic design of the OpenMRS relationship model fully met the original use cases for HIV care and CHW programs, and could be expanded to support additional implementation needs. However, implementers tended to leverage relationship data for chronic care and/or community health, with little or no evidence of relationship data being used for acute care delivery (▶ Figure 4). We also found that the focus of implementations that supported relationship data collection over the past ten years had not changed – a majority of these implementations still focused only on HIV/AIDS or Tuberculosis care. A notable exception was the OpenMRS implementation at Colombo, Sri Lanka, a relatively smaller implementation that leveraged patient relationships for treating genetic disorders.

Fig. 4.

Uses of OpenMRS relationship data across implementations

The OpenMRS experience indicates that collection of relationship data results in a richer data set that may assist in managing the comprehensive care of patients. While the respondents to our survey hailed from low and middle-income countries (LMIC), we believe that they are aligned with the needs of healthcare delivery programs in the US and other developed nations. As the US health care system and reimbursement model changes, a standardized approach to identify relationships may prove to be critical. For instance, the identification of a ‘friend’ relationship may help predict social support or decreased risk for social isolation. Alternatively, knowledge that patients are not assigned to a primary behavioral health therapist may indicate they are at risk for increased emergency room visits. Our survey showed that relationships played a pivotal role in linking patients with CHW‘s. These lessons may be directly reapplied in the US and other developed countries that are developing interests in community health models. They may also be useful in caring for vulnerable groups such as the American Indian/Alaska Native population (AI/AN) [35].

We also perceive that clinical needs based relationship fields have the potential to support precision medicine (PM) initiatives. PM is defined as „an emerging approach for disease treatment and prevention that takes into account individual variability in genes, environment, and the lifestyle of each person“ [36]. In many cases, genetic determinants of disease could be inferred from clinical data from blood relatives, thereby reducing the need for expensive and time-consuming genetic testing. Social and environmental determinants of illness may also be inferred from relationship data – for example, a parent receiving treatment for substance abuse may be indicative of an insecure situation for a child, and indicate a need for intervention evaluation, including counseling and/or screening for depression. At minimum, blood relationship information can directly affect clinical care by helping identify potential donors and guardian/contact information.

These results highlight several problem areas that warrant further study. While the freedom to create implementation specific relationship types is a perceived advantage, it may hinder inherently structured and formalized healthcare delivery across the developed world. Therefore, we perceive a need to research patient relationship types most necessary for US or other country specific contexts. The study of relationships and secondary linking of patient data may also help address clinical questions such as social well being, longitudinal impact of pregnancy conditions on neonatal and infant outcomes, adverse childhood events impact on adults, and many others. Additionally, the lack of support for recording patient relationship data in commercial EHR systems that dominate the developed world poses a significant challenge in exchanging relationship data across the healthcare eco system, and should be addressed.

5.1 Limitations

We believe that respondents to our survey fully represented the general uses of the OpenMRS relationship model across the implementer community. Our analysis included data on the utilization of core and implementation specific relationship types, qualitative insights into clinical drivers for the utilization of these data fields, and the perceived value and use of the data being collected. However, we did not analyze the actual value or impact of these data on individual patients or the overall health care team. We also did not evaluate the frequency of use of these data once they had been collected.

6. Conclusion

Despite longstanding agreement that the efficiency, effectiveness, and clinical impact of healthcare depends partially on identifying relationships between patients, caregivers and the greater community, EHR systems the world over offer little support for recording or using such information in a meaningful manner. In contrast, relationship measures are widely used by OpenMRS implementations across LMIC‘s, where they are perceived as an enabler of community driven care and effective chronic care. Our findings indicate relationship data represent an essential data domain that may have significant impact in improving health outcomes across developed countries and LMIC. There is a need for future research to address the development, utilization, and value of health information technology (HIT) based knowledge of relationships. Further study on how medical dictionaries should support the collection of relationship types is also merited.