New Standards and Enhanced Utility for Family Health History Information in the Electronic Health Record: An Update from the American Health Information Community's Family Health History Multi-Stakeholder Workgroup

Abstract

Family health history is a complex, multifaceted tool for assessing disease risk that can offer insight into the interplay between inherited and social factors relevant to patient care. Family health history tools in electronic health records can enable the user to collect, represent, and interpret structured data that properly supports clinical decisions. If these data can be made interoperable, important health information can be shared with minimal duplication of effort among entities involved in the continuum of patient care. This paper reviews the efforts by the American Health Information Community's Family Health History Multi-Stakeholder Workgroup to create a core data set for family health history information and to determine requirements to promote incorporation of such information in electronic health records. The Workgroup is a component of the U.S. Department of Health and Human Services' Personalized Health Care Initiative.

Family Health History and Health Information Technology: An Opportunity for Synergy

As our scientific understanding of the molecular and genetic/genomic basis for health and disease improves, the importance of family health history as a predictive tool continues to increase. Although currently underutilized in health care, family health history information can play a central role in enhancing the uptake and effectiveness of preventive services for a variety of disorders that affect public health. ^1,2 Family health history can clarify a patient's potential disease risk and treatment options and inform differential diagnosis in symptomatic patients. Additionally, guidelines for screening and management of common disorders, including diabetes, cancer, and cardiovascular disease, incorporate family health history information. ^3–5 However, obtaining a family health history is time-consuming, and many primary care providers are insufficiently trained to appropriately interpret the information they obtain. ² Numerous studies show that health care providers often obtain minimal to no family health history in the context of health care visits. ⁶ With the transition from paper-based systems to electronic personal health record (PHR) and electronic health record (EHR) systems, this situation may worsen as many of these systems are underdeveloped with regard to family health history capabilities.

A potential solution to optimize the use of family health history in clinical medicine is to develop health information technology (HIT) systems that facilitate patient entry of family health history information and provide automated clinical decision support for health care providers. Several web-based tools have been developed to facilitate patient collection of family health history information, most notably My Family Health Portrait (MFHP; freely available at www.familyhistory.hhs.gov) created by a collaboration between the Centers for Disease Control and Prevention (CDC), the Office of the Surgeon General, and the National Human Genome Research Institute of the National Institutes of Health, and the CDC's Family Healthware™. The former, which has been tested extensively in a variety of user populations, helps patients to collect and organize their family health history but does not include interpretive capabilities. The latter, currently available as a research tool (http://www.cdc.gov/genomics/about/family.htm), helps patients collect family health history information and incorporates interpretive capabilities such as disease risk determination. Taken together, these evolving tools represent the most widely used patient-centered electronic family health history tools in the United States.

Unfortunately, neither of these tools is currently structured to facilitate the electronic transfer of family health history information into HIT systems that are in current clinical use. This illustrates a critical barrier to enabling the use of family health history in the EHR; namely, there is currently little standardization of, or interoperability between, the family health history capabilities of existing PHR and EHR systems. Achieving synergy between HIT and family health history centers around the development and use of interoperable standards, a process that will require an accepted core data set for family health history information; standardized nomenclature for family health history; development and harmonization of standards for the collection, exchange, and security of family health history information; development and/or enhancement of tools to facilitate consumer entry of family health history information into HIT systems; and development of clinical decision support tools that utilize structured family health history information. Failure to reconcile HIT systems and family health history capabilities will hamper patients from receiving the full benefit of their family health histories.

Towards Interoperable Family Health History Tools: The American Health Information Community's Personalized Health Care Workgroup

One component of the U.S. Department of Health and Human Services (HHS) Personalized Health Care Initiative, ⁷ the American Health Information Community (AHIC) ⁸ Personalized Health Care (PHC) Workgroup, ⁹ formed in 2006, has set as a priority the development of interoperable approaches to capture and use family health history information in EHR/PHRs. The group envisions personalized health care as a forward-looking, consumer-centric system in that features customized diagnostic, treatment, and management plans based on a variety of patient factors, including culture, personal behaviors, preferences, family health history, and genetic/genomic makeup. This vision is informed by the development of HIT systems and the rapid advances in our basic understanding of the relationships between health, disease, and genetics. The PHC Workgroup is charged with recommending means to establish standards for reporting and incorporating common medical genetic/genomic tests and family health history data into EHR/PHRs and to provide incentives for nationwide adoption.

Recommendations made by the Workgroup are then used to inform the development of use cases by the ONC that outline the needs of multiple stakeholders (e.g., patients, organizations, and systems) and describe the flow of information and the requisite information systems necessary to connect them at multiple levels. These use cases reflect the continuum of information collection, from consumer entry of family health history in the PHR to entry of family health history in the EHR/PHR by the health care provider, with the long-term goal of interoperability between the two electronic systems. Use cases then pass through several rounds of public comment before being delivered to the Health Information Technology Standards Panel (HITSP). ¹⁰ Accredited by the American National Standards Institute, HITSP is a public-private partnership that evaluates existing standards and works to harmonize them or identifies gaps that require additional development. The Certification Commission for Health Information Technology (CCHIT), ¹¹ an independent, non-profit organization formed in 2004 by the American Health Information Management Association, Healthcare Information and Management Systems Society, and the National Alliance for Health Information Technology, then develops specific criteria for HIT systems and evaluates whether available systems can support and perform the intended activities, maintain data confidentiality, and exchange information with other systems.

An Iterative Process to Arrive at a Core Family Health History Data Set

To support the development of a use case for PHC, a core minimum set of data and common data definitions for the collection of family health history information must be developed. Recognizing the critical importance of this data set, on July 31, 2007, AHIC adopted the following recommendations from the PHC Workgroup pertaining to the priority area of family health history:

• • Form a multi-stakeholder workgroup to develop a family health history core minimum data set for primary care providers.

• • Conduct studies to determine an evidence-base, the validity and utility of family health history risk assessment and management tools, and clinical decision support tools, and to inform medical decisions.

• • Sponsor pilot programs to evaluate the core minimum data set and evidence-base and examine the feasibility of consumer-clinician exchange between PHR and EHR systems. The pilot programs should test and implement the standards and architecture identified in the HITSP-developed use case.

This manuscript details efforts to date to fulfill these recommendations.

The Family Health History Multi-Stakeholder Workgroup, comprised of more than 40 members who represent approximately 18 organizations, was convened in August 2007 (for membership, see Appendix 1: “Family Health History Multi-Stakeholder Workgroup,” available as an online data supplement at www.jamia.org). This group includes members from the private sector and federal agencies who have been active in the PHC Workgroup or subgroups, as well as individuals with knowledge and expertise in the areas of family health history, health information technology, and health care delivery. In particular, an effort was made to include representatives from private-sector organizations that would be affected by the inclusion of a family health history core data set in the EHR. In October 2007, the Multi-Stakeholder Workgroup presented a report to the PHC Workgroup that defined the minimum family health history core data set. ¹² In December 2007, the Workgroup prepared a Data Requirements Summary for the family health history core data set, which was released for public comment on January 15, 2008. ¹³

This data set was created through an iterative, consensus-building process based initially on information contained in a draft of proposed standards for family health history information developed by a small group of experts on family history and primary care. A prototype of the AHIC PHC use case ¹⁴ was also used as a reference for this process. The detailed personalized healthcare use case ¹⁵ describes a “Clinical Assessment” scenario that includes both family history and genetic testing information and takes into account perspectives of the consumer, clinician, testing laboratory, and information exchange. This scenario is used to outline the information flow and actions for the following five steps:

• 1 The consumer provides available family medical history information to the clinician.

• 2 Validated consumer and family health history information, available genetic/genomic testing information, and additional information about health status are accessed and gathered electronically via health information exchange.

• 3 The patient, authorized family members, and/or other providers receive newly constructed pedigree and family health history.

• 4 Information retrieved from genetic/genomic knowledge repositories and consultation with genetic specialists supports the selection of genetic tests.

• 5 The clinician communicates orders for genetic/genomic tests for the patient to the laboratory.

From these documents, a straw-man document was crafted and circulated among group members. When discussing and revising the straw man document the workgroup focused on what the stakeholders felt to be the core set of family health history information in the primary care health delivery environment. Stakeholders were then asked to supply comments on the straw-man document and to provide relevant materials used internally by their respective organizations to define the core data set for family health history. For this reason it was impossible to use a Delphi approach, as anonymity of the contributors could not be maintained. Comments and supporting documents supplied by the stakeholders were then used to assemble a draft document that defined the core variables and functionalities related to the representation of family health history information in the EHR/PHR. The group that was convened to create the core minimum data set purposefully included not only genetics experts but practicing primary care expertise—the core data set reflects data relevant to “validated” clinical prediction rules and incorporates elements of family history used in routine clinical practice—much of which will never be formally “validated” but is critical to ongoing health care.

While core functional requirements, such as the ability for the patient to indicate information as “sensitive” or to indicate degrees of uncertainty about the accuracy of the information, were outlined in the data set requirements, the governance structure and implementation methods were not described. Therefore, many issues concerning the confidentiality, privacy, and security of family history information were not addressed in this exercise. The PHC workgroup has previously discussed points to consider when including genetic test information in the EHR/PHR, ¹⁶ and many of these broad principles could also be applied to family health history information. These issues will be addressed most appropriately on an individual level, as organizations and institutions implement the standardized collections of family health history.

Core elements and functionalities related to family health history were categorized either as required or optional in the EHR/PHR environment. When making this designation, Workgroup members considered use of family health history information in the EHR/PHR from the perspectives of primary care providers and patients. In addition, the group discussed the concepts or functions that the EHR/PHR should capture or perform, with the understanding that the health care provider (or patient in the case of a PHR) may not use all of these concepts or functions in any given encounter. Finally, the group agreed that the listing should include concepts and functions that will be relevant to contemporary EHR/PHR users and to those 5–10 years into the future. Stakeholder responses were reviewed by the task force chairs, summarized, and used as a basis for three facilitated discussions among the stakeholders to achieve consensus on the family health history concepts/functionalities that should be part of every EHR/PHR. Additionally, the core dataset was posted electronically for further public comment in January of 2008 as an accompanying document to the PHC use case and modified accordingly based on the comments received.

The Family Health History Minimum Core Data Set

The core data set created by the Multi-stakeholder Workgroup is provided in ▶. ▶ These Tables list suggested required and optional items for incorporation into the family health history capabilities of PHRs and EHRs but are not meant to be an exhaustive collection of all of the concepts that could be incorporated under the construct of family health history. This document is intended for use by HITSP for the standards identification and development process and is not intended as a technical requirement document to support software development activities. The notes presented in the tables describe the complexities of including a particular item in the core data set. In many cases the group easily reached agreement on concepts or functions that should be represented in the EHR/PHR, although there were divergent views on how to achieve this.

Table 1.

Table 1 The Suggested Required Core Data Set for Family Health History Representation in the Personal Health Record/Electronic Health Record

Data Category (Individual)	Notes
Identification	First and last name for patient; for relatives, ideally first and last. For both, individual numerical identifier assigned by system and used only for structuring the family health history.
Age	For relatives, represent date of birth in a way that can be used for effective clinical decision support. Ideally this includes the full date of birth for each relative, but at a minimum should include the year of birth. Also could use a date stamp when a relative's age was recorded. Listing of year of birth could be an acceptable compromise.
Date of death	Age at death is sufficient.
Cause of death	Note if unknown.
Ethnicity/race (self-identified)	Will inform risk assessment. Examples include the role of ethnicity in determining risk for hereditary breast and ovarian cancer syndrome.
Biological sex
Multiple-birth status	Identical/fraternal noted if multiple births for index case (proband) only.
Biological parents identified	Forms backbone of family health history; permits pedigree construction.
Consanguinity	Represented for index case's (proband) parents
Adoptive status
Disorders	List of disorders must be context-specific and context would be best determined based on the intended end user of the application (patient and/or clinician) and the life-stage of the patient. Requires standard vocabulary to address diagnosis, age of onset, and multiple disorders.
Research identifier placeholder	To be assigned value only if individual is part of data bank/research protocol.
Relevant genetic/genomic test results	Must consider confidentiality, privacy, and security issues.
Data field for “unknown”	Denotes that question was asked but answer was not known
Approximate dates/ages for data fields	Useful for risk stratification when patients cannot recall specific dates/ages.
Sensitive fields	Designates fields that patient would prefer have restricted access.
“Certainty of data”	Noted by provider in text box
Integration with other EHR elements	Systems should not force duplicate entry of family history data that is already stored in a legacy system (e.g., age, past medical history relevant to family history, and self-described ethnicity data).
Ability to define data sharing status	Global means to provide patient maximum control over sharing of his/her data with individuals including family members.
Text box for annotations

Data Category (Family)	Notes
Data representation	Acquire data that would allow generation of pedigree using standardized graphical nomenclature; include ability to redefine the person about whom the history/pedigree is constructed
Relatives	System should handle a minimum of 1st- and 2nd-degree relatives

Table 2.

Table 2 Data Suggested as Optional for Family Health History Representation in the PHR/EHR

Data Category	Data Elements
Individual	Place of birth Date of birth Multiple birth status (other than for proband) Assigned gender Consanguinity Severity of disorders Non-diagnosed health status Partner status Non-genetic laboratory results Relevant environmental/social data Context-sensitive data collection (e.g., age and gender specific questions only)
Family	Representation of relationship qualities (e.g., estranged, close, household member)

PHR = personal health record; EHR = electronic health record.

Required items include individual identifiers, demographic characteristics (e.g., ethnicity/race, age), specific medical information (e.g., certain disorders, laboratory data, and genetic/genomic test information), and subjective patient responses (e.g., certainty of data, approximate dates/ages for data fields). Workgroup members felt it was particularly important that data be gathered in way that could support the generation of a graphical pedigree. Optional items represent entries that the stakeholder group considered optional for inclusion in the EHR/PHR. In some cases elements were considered optional because Workgroup members could not reach consensus about their value. In other instances, consensus as to the value of the elements was obtained, although concerns about confidentiality issues remained. In a few cases, questions were raised about the value of representing the information in the family health history section of the EHR/PHR.

The Tables include elements that represent data (e.g., date of birth, diagnosis) and functionalities (e.g., the ability to represent the data as a pedigree) and are divided into sub-headings for the “Individual” and the “Family.” In general, the term “Individual” refers to any person represented in the family health history obtained by the clinician or provided by the patient, including the individual who is the focus of the history. In most cases this person will be the actual or potential patient, who is also referred to as the index case (or proband). For some data elements, the Workgroup felt that it was necessary to draw a distinction between data that may be collected from the patient's EHR/PHR and those from the family members' EHR/PHRs. In general, the term “Family” refers to the biological relatives of the patient providing the family health history. The group recognizes that the concept of “Family” encompasses more than the biological relationships between individuals. However, the group also felt that the primary focus of its work should be to develop the core data set that would be useful to automated clinical decision support for disease risk assessment in the primary care environment. It is envisioned that the Workgroup's efforts will inform future efforts to establish data sets that incorporate family health history as it relates to the social environment.

When developing this table, the Workgroup recognized certain disparities regarding the level of detail required for the patient versus his/her family members. Additionally, the Workgroup intentionally omitted the finer details regarding the specific format for data collection. For example, many recommended data entry fields could potentially be programmed with a list of responses as opposed to free text. The Workgroup felt that each implementing organization should determine the appropriate user interface for data entry, recognizing that canned responses and data structures may differ among the various legacy systems. However, interoperability should be a key feature of implementation strategies if legacy data and data structures are to be maintained. Finally, the Workgroup understands that much of the recommended core data set may already exist in legacy systems and EHR/PHRs. Implementing agencies are therefore encouraged to cull family health history data that already exist rather than duplicate entry and storage of data in a family health history module.

Federal Partnerships as Models for Pilot Programs to Achieve Interoperable Exchange of Family Health History Information

In many ways, family health history offers a concrete focus for interoperability efforts between HHS and Federal partners, including the Department of Defense, the Veterans' Health Administration, and the Indian Health Service. Current Federal HIT systems to gather family health history information are under-developed, making these viable models for transitioning from current practice. Moreover, a messaging standard for family health history has recently been developed and approved by Health Level Seven (HL-7), a not-for-profit organization that works to provide a framework and standards for exchanging, integrating, sharing, and retrieving family health history information. ¹⁷

In addition, well-developed tools for patient entry of family health history, such as the aforementioned MFHP and Family Healthware™, are in use within the Federal system. Efficient collection of standardized family health history information using such tools will be critical to the downstream development and testing of clinical decision support. Finally, the development of systems that collect and interpret structured family health history information coupled with the development of enhanced interoperability will present a variety of issues regarding confidentiality, privacy and security. Addressing these issues for family health history information could serve as a proxy for the increasing advent of genetic test information in the electronic record. Moreover, many developers of private sector EHR and PHR systems have yet to fully develop their systems' family health history capabilities. This suggests that any Federal effort (which would encompass more than ten million individuals with full participation by the Department of Defense, the Veterans' Health Administration, and the Indian Health Service) could serve as a model for the development of much broader interoperability regarding family health history information.

An interoperable system for collecting, interpreting, and exchanging family health history between willing Federal partners would ideally feature the following attributes:

• • A common electronic patient interface;

• • A common core data set for family health history that each system can accept, collect, and curate in an interoperable, structured manner;

• • A user-friendly interface for providers;

• • A means for structured data transfer between systems that is accepted by the partners and external health care entities;

• • Standardized, evidence-based, interpretative algorithms with risk-specific messaging that can be accessed and applied to family health history data at various points on the continuum of data collection and curation by each partner based on its needs;

• • Safeguards for confidentiality, privacy, and security accepted by all partners;

• • A mechanism to track data flow, system use patterns, and outcomes.

The latter component will be critical to evaluate the effectiveness of interpretive algorithms in practical settings and for ongoing quality improvement purposes. The development of an effective governance mechanism, along with an action plan with well-defined milestones and mechanisms to ensure accountability will also be critical to enable effective communications and resource management. Establishing such a system will require free exchange of ideas and opinions with partner agencies and a willingness to share products with the health care community. However, doing so will ultimately enhance interoperability of HIT data between systems, thereby improving patient care and reducing systemic burdens.

Conclusion

Family health history is a complex, multifaceted tool for assessing disease risk. Ultimately, it can be a tool for gaining an understanding of the interplay between inherited and social factors that are relevant to patient care. The value of a family health history tool in the EHR/PHR environment resides in enabling the user to collect, represent, and interpret structured data obtained from patients and other sources in a manner that properly supports clinical decisions. Further, the main goal will be achieved if these structured data can be made interoperable between entities, thereby ensuring the availability of important health information to all health care entities involved in the continuum of patient care with minimal duplication of effort.

The Workgroup recommends specific family health history data to be captured, stored, and viewed in both EHR and PHR environments and has documented desired functionality for a family health history module. The family health history data sets presented here were submitted for consideration during the AHIC use case development process as a potential benchmark for the family health history content of EHR/PHR systems seeking standards development and certification. Once finalized, the core data set will be used to inform federal and private pilot projects that will test and implement the architecture described in the HITSP use case. At the same time, this document can provide guidance to entities that are developing or updating the family health history capabilities of their EHR/PHR systems. Suggested immediate next steps for creators of existing EHR/PHR systems include performing a cross-walk between this set of data requirements and their systems and considering altering data collection accordingly.

This effort represents an early step in the incorporation of family history in the EHR/PHR: the core data set provides a much-needed, widely-accepted foundation of data upon which all systems can build. Clearly, many downstream steps will need to occur to achieve an interoperable approach to capture, store, and link the myriad concepts that emerge when patients relate their family health histories to providers. Representatives of the AHIC and its successor are actively pursuing these next steps. Ultimately, these efforts will streamline health information flow, facilitate clinical decision support, and improve patient care.