- Read Online
The purpose of this document is to highlight current approaches and challenges in enabling family history to guide clinical care to developers of clinically-oriented family history collection systems, including stand alone and EHR-integrated systems. Additionally, this document provides an overview of key design features (and supporting rationale) of family history systems for potential consumer/purchasers.
Work Product Details
Work Product Type:
Related Work Product(s):
- family history
- pedigree consent
- standard; eHealth
- Ed Conley , The Farr Institute of Health Informatics Research United Kingdom
- Megan Doerr , Sage Bionetworks , Seattle, United States
- Jeff Greenberg , Kaiser Permanante , Pasadena, United States
- John Mattison , Kaiser Permanante , Pasadena, United States
- Ingrid Winship , Royal Melbourne Hospital , Melbourne, Australia
- Grant Wood , Intermountain Healthcare , Salt Lake City, United States
Enabling Family History in Clinical Practice: a review of current practice and policy considerations - Read Online
Enabling Family History Use in Clinical Practice:
A review of current practice and policy considerations
This is a living document created by the Family History and Pedigree Consent task group of the eHealth, Clinical Working Group of the Global Alliance for Genomics and Health. This document is open for comment and will undergo regular revision. If you have comments or questions about this document please contact Megan Doerr, MS, LGC (firstname.lastname@example.org).
Version: 3.2 (7Feb2016)
The purpose of this document is to highlight current approaches and challenges in enabling family history to guide clinical care for developers of clinically-oriented family history collection tools, including both "stand alone" and EHR-integrated products. Additionally, this document provides an overview of key design features (and supporting rationale) of family history collections and analysis tools for potential consumer/purchasers.
The goal of family history collection within medical practice is to improve patient care. Family history plays a central role in assessing patterns of disease inheritance and estimating risk of developing specific conditions. Accurate reporting of family history is essential to clinical care, facilitating appropriate management of patients and their families. Additionally, family history informs the interpretation of sequence variation, an application that is becoming increasingly important in precision medicine initiatives worldwide. (1) The benefits of family history collection and use thus include both customized patient-specific care as well as improved population management. (2) In all cases, the required elements that comprise a complete family history remain constant: family structure and family health history.
For the purposes of this statement family structure is the number, sex, vital status, and current age/age at death of biological relatives, as well as the precise relationships that link them. The ability to accurately and consistently capture intra-family relationships (e.g., distinguish between half-siblings) is critical to the utility of the family structure data set.
Family health history describes the health conditions experienced by family members over the course of their lifetimes, including the family member's age at the onset of the condition and other specific descriptors of the condition. The ability to capture multiple conditions and multiple ages of diagnosis for family members (and multiple ages at diagnosis for a single condition for a single family member) is an essential design feature.
Both family structure and family health history are critical to probabilistic risk assessment. Without knowing the number of both affected and unaffected relatives, as well as the precise relationships linking them, the application of even the most common probabilistic risk assessment models (e.g., Bayesian analysis) is significantly limited.
Approaches to data collection
At this time, there are two primary potential sources for family history data: self-report directly from patients, and official records (e.g, medical records, autopsy reports). Ideally, both of these sources would be tapped, with electronic aggregation and standardized processes for reconciliation. A key design requirement for a multi-source system is the collection of metadata about the source of family history information (i.e., provenance) for each data elements.
Several existing clinical family history tools use patients as the primary data source for both family structure and family health history (see Inventory for examples). Although limitations to the accuracy and detail of self-report have been described (3), family history collection can be a concrete and practicable way to engage patients as committed partners in improving health. We may find that patient-report reliability increases when patients are asked in structured and consistent ways about their family health history. Additionally, patient self-reporting may become more reliable as medical systems around the world become more fully transparent and patient access to complete medical records becomes routine (e.g, the US Blue Button program, http://www.healthit.gov/patients-families/blue-button/about-blue-button).
Challenges faced by family history capture directly from patients
Two significant barriers to engaging patients as family historians are language and interface. Existing lexicons used to describe health history have been designed for clinician use (e.g., ICD, SNOMED). We currently lack a standardized patient-centered, plain language family health history dictionary that would facilitate accurate family health history data capture directly from patients. Also needed to facilitate meaningful data capture from patients is continued exploration/experimentation to identify the best patient-facing interface to accurately capture family structure.
Challenges posed by family history data capture with clinicians as intermediaries
One of the principal challenges posed by relying on clinicians to capture patient family health history is time; around the world, clinician time is highly constrained (most often due to underlying reimbursement structures. There is little time spent capturing family history, as well as a reliance on incomplete ( i.e, "problem-focused"). (4) Due to deep, systemic nature of this challenge, it is out recommendation that patients should be viewed as the preferred "first line" for data entry in any family history program design. If clinicians are asked to capture family history, as for direct patient-entry system, structured investigation is needed to identify the best interface (s) for accurate, complete data capture. Equally critical are studies assessing these systems' impact on clinical workflows in diverse clinical settings, as well as investigation to identify the interface design and implementation features that optimize clinician completion.
Regardless of who holds the responsibility for family history data entry, a universal challenge to the accuracy of patient-created family histories is the dearth of mechanisms to allow for intra-familial collaboration on family history for use in clinical care. There is evidence emerging that by creating family history platforms that enable intra-familial collaboration and sharing, data quality may improve. (5) However, few existing clinical family history tools allow for explicit intra-familial collaboration. While collaborative platforms have proliferated in commercial ancestry tools, a lack of clarity on how regulatory and ethics frameworks might apply to such collaborative platforms, and commensurate privacy and security liability concerns, may be limiting their development by clinical family history tools.
Although most official records (e.g., medical records, autopsy reports) are poor sources for family structure at this time, they can be an excellent source of condition-specific data. Data structure is currently a large hurdle to effective data mining from official records; most of this data is not structured for sophisticated data transfer, match, and marry, including genetic test results, pathology, and other laboratory data. Ideally, not only the records of the patient him/herself but also records from consenting family members would be tapped. A standardized cross walk between any plain language terms and clinical terms will be required for this data merge, as well as an explicit procedure for matching family relationships.
Approaches to review
At this time, there is no replacement for clinician review of the assembled family history data. Direct conversation with the patient, careful review of the aggregate picture, and the ability to request additional records (ideally, electronically) serve as the quality check on any family history-informed changes to clinical care. Provider time constraint and lack of engagement remain arguably the largest barrier to maximizing the review and use of family history to guide clinical care. Again, the user interface for any family history system is critical, with highly intuitive/minimally intrusive/purposefully integrated systems required in the clinical setting. Worthy of consideration are "learning" systems that highlight the most germane family history to a given clinical encounter, although this may only serve to perpetuate the limitations of "problem focused" family history
Additional data layers
The patient and his/her family member’s social context, including household composition, lifestyle choices (e.g., physical activity level, alcohol consumption), and educational and occupational history may also strongly influence the health history. Of additional consideration is residence history with regards to know environmental risk factors (e.g., proximity to refineries, hazardous waste sites, naturally occurring asbestos). For this reason, social context may be an important additional data layer to family structure and family health history. At this time, there are no standardized approaches to integrating social context that have been included in existing family history systems; with few exceptions, inclusion of social context is done “manually” as part of the clinician review.
Consent documentation is currently lacking in most family history tools. This is in part because collection of family history information in the clinic is required for care, so consent has traditionally been implied. The ease with which electronic family history health information can be shared with and used by third parties, however – including family members, tool developers, clinicians, and researchers, as well as unauthorized users (e.g., employers, insurers, data brokers, criminals) – brings renewed attention to questions of privacy and consent, not only for patients, but also for their family members.
A failure to address the critical issue of consent to the collection, use, and sharing of family history information could hinder patient care, tool development, and health research. Expanded data sharing means family history information may be subject to multiple, overlapping privacy regulation frameworks (e.g., commercial, clinical, and health research). Each framework has distinct rules governing the collection, use, modification or disclosure of health information, as well as distinct rules about when consent is required and what constitutes valid consent. Open questions include:
- Under what conditions is explicit consent required to collect, aggregate,use, disclose family history information?
- What obligations do tool developers have to protect the confidentiality and security of family history information?
- What forms of consent, such as broad consent to future unspecified use, are valid?
- Are opt-in or opt-out processes acceptable for certain uses?
Consent processes also need to be designed with a level of granularity that balance respect for patient preferences with the needs of clinician users for access to comprehensive, high quality, and accurate information. This could likely be achieved through a tiered consent process – one that asks patients increasingly specific questions about who can access their information, what types of information will be shared, and for what purposes.
The challenges posed by intra familial data sharing warrant specific consideration:
- Are there circumstances where consent of family members is required for collection? For example, where information that is “identifiable” in relation to family members is used for research, familial consent or waiver from an ethics body may be required.
- Who has the right to access family history information, especially family history entered on a collaborative platform? Typically, individual access rights are limited where the confidentiality of a third party is threatened.
Once patient preferences are established as a “consent directive,” this directive needs to be stored, managed, and enforced within a consent management system. Such a system would need to consistently associate consent with the family history information, allow patients to modify or revoke consent over time (ideally as a dynamic process), and would need to be interoperable across user platforms.
Our perspective is that explicit and informed consent should be built into family history collection tools for any use outside of direct clinical care. The purpose or purposes of data collection must be disclosed e.g., to support tool improvement, to enhance a population phenotypic repository for research. Those patients not consenting to their data being used for secondary purposes should not be prohibited from using family history collection tools for clinical care.
Existing data standards
Although there is a paucity of existing global standards for family history, detailed data standards have been developed and published in the United States as an offshoot of ongoing healthcare reform efforts in that country. The U.S. Department of Health and Human Services launched the Personalized Health Care Initiative in 2006. As part of that initiative, the American Health Information Community's (AHIC) Family Health History Multi-Stakeholder Workgroup was formed to define a core data set for family history and guide the creation of computer applications used to collect that data. The goal of this effort was to promote the incorporation of family history information in electronic health records, as well as to enable clinical decision support features based on family history, including risk assessment, referral guidance for genetic counseling, and assistance with genetic testing decisions. The Multi-Stakeholder Workgroup’s recommendations were adopted by AHIC in 2007.
Also in 2007, HL7 International’s Clinical Genomics workgroup published its implementation guide on the Family History (Pedigree) Model. This standard supports the transmission of family histories between electronic systems. The HL7 data model includes describing a patient’s full family structure/pedigree and family health history, with options for linking genetic data and risk analysis for clinical decision support and risk assessment. This standard was re-balloted and supported in 2013, and was referenced in the U.S. Meaningful Use Stage 2 requirement for the certification of U.S. electronic health records. MU Stage 2 also requires the ability to transmit and receive HL7 Continuity of Care Documents (CCD) and Clinical Document Architecture (CDA), both of which may contain summary or disease-specific family history information.
HL7 International is currently developing a new draft standard format called Fast Healthcare Interoperability Resources, or FHIR. FHIR consists of basic sets of healthcare/medical data called “resources”. A family history resource represents a simple structure used to capture an “elementary” family history. However, it can also be the basis for capturing a more rigorous history useful for genetic and other analyses; see the Genetic Pedigree profile for an example. A resource can be extended to include more data types, or combined with other resources to create a profile. Family history resources, extended resources, and a profile are available now for trial use, with the goal that they will become a normative standard.
Family history is an essential component of the longitudinal phenotypic dataset of every patient; therefore family history data must be stored in a way to facilitate complex risk assessment and ease of transfer, and opportunities for frequent updating. Given these requirements, family history may be best stored in sovereign systems external to electronic medical records, communicating periodically with the EMR in standardized ways, e.g., HL7 pedigree standard although advances in EMR platforms may soon make this recommendation outdated.