Profiling Fast Healthcare Interoperability Resources (FHIR) of Family Health History based on the Clinical Element Models

Abstract

In this study we developed a Fast Healthcare Interoperability Resources (FHIR) profile to support exchanging a full pedigree based family health history (FHH) information across multiple systems and applications used by clinicians, patients, and researchers. We used previously developed clinical element models (CEMs) that are capable of representing the FHH information, and derived essential data elements including attributes, constraints, and value sets. We analyzed gaps between the FHH CEM elements and existing FHIR resources. Based on the analysis, we developed a profile that consists of 1) FHIR resources for essential FHH data elements, 2) extensions for additional elements that were not covered by the resources, and 3) a structured definition to integrate patient and family member information in a FHIR message. We implemented the profile using an open-source based FHIR framework and validated it using patient-entered FHH data that was captured through a locally developed FHH tool.

Introduction

FHH has been recognized as a powerful tool for diagnosis and risk assessment in clinical genetics, aiming to identify risk of a specific gene disorder for the purpose of ensuring appropriate primary care and specialist intervention ¹. However, utilization of FHH information has been limited by the lack of tools implemented in the clinical workflow to perform the required analysis. Unlike other clinical data, FHH includes not just patient data, but also their family members, including all relationships, their disease history, and age of disease onset or death. Traditionally clinicians have relied on interviews or questionnaires to collect narrative-only FHH information from patients, but due to the limitation of time in clinical settings, this method does not ensure sufficient information or data quality to complete the analysis². FHH is still mostly captured and stored in narrative text form, summarizing only essential or a minimum of information for risk assessment (e.g. family history of ovarian cancer on maternal side).

With support of computerized tools, improved electronic health record (EHR) systems are now capable of capturing and storing detailed FHH information in a structured way. Such tools have been implemented not only to be used by clinicians, but also outside clinical settings, as it ensures enough time and a systematic way to enter pedigree based FHH data by patients. Based on the ideal features of the FHH tools that have been suggested by the American Health Information Community ^3,4, recently implemented tools provide a web-based access environment and visualization of family pedigree diagrams to connect with healthcare consumers, and motivate them to enter accurate FHH information^5,6,7,8.

In anticipation of increasing adoption of these tools, there have been efforts to develop a standardized data model of FHH for exchange across systems. The Health Level 7 (HL7) Version 3 implementation guide for family health history and pedigree interoperability⁹ is a well-known standard to represent FHH as an extensible markup language (XML) and has demonstrated its ability to be used for genetic risk assessment services across systems in a case study¹⁰. However, it has been true that in general, HL7 Version 3 based standards haven’t been as widely adopted as Version 2, because Version 3 was thought to be difficult to develop, expensive, and required too much project time to develop ¹¹.

FHIR is a next generation standard framework created by HL7 which has an implementation focused approach. FHIR provides an alternative to document-centric approaches by directly exposing discrete data elements, which compromise a FHIR resource, as services¹². Because the benefits of using FHIR are pre-built and standardized resources which are easily extensible, and the ability to combine these into profiles for easier implementation in development, a complex data model like FHH will be handled more efficiently using FHIR. Yet existing FHH resources do not cover detailed FHH data model such as full pedigree to support genetic risk assessment, and a few published extensions still have limitations.

In this manuscript, we used CEMs as a baseline data model to develop FHIR profile to address the gap. Elements of CEMs have features to be transformed to FHIR profiles in a straightforward manner, as the CEM strategy defines generic structures which specify the data type of an element, its permissible values or range, multiplicity of value sets of the element, and permissible qualifying information, etc. ^13,14 In our previous study, we developed CEMs that can cover essential of FHH information; its key features are to capture full pedigree of FHH, linkages of family members to their patient records in EHR, and social history and health behaviors ¹⁵.

We selected FHH related resources by conducting a gap analysis between existing FHIR resources and FHH CEM elements, and added CEMs were not covered by the existing FHIR as extensions. We developed a structured definition that can contain all the selected resources and extensions as a patient’s full pedigree based FHH in one FHIR message. We used an open source based FHIR framework to implement the profile and to create messages using empirical FHH data of Intermountain Healthcare, and validated it by analyzing the gaps. We assume the profile to be used to run an external web service of genetic risk assessment.

Background

Intermountain Healthcare is a not-for-profit, community-oriented organization based on Salt Lake City in Utah with more than 37,000 employees, about 1,400 employed primary care and secondary care physicians, and provides healthcare services based on Utah and southeastern Idaho. It operates 22 hospitals and more than 185 clinics throughout the regions¹⁶.

Intermountain Healthcare provides a web-based FHH collection tool named OurFamilyHealth, which was initially developed in 2009 and has made available through Intermountain’s patient web portal: MyHealth ¹⁷. The purpose of OurFamilyHealth is to provide patients the ability to enter FHH data by building a graphical family pedigree and assign disease and conditions to specific member in their history (see Figure 1). Patients are given a basic family tree at their first access and can add their family members to the tree with detailed demographic, disease histories, and health behavior information such as height, weight, and smoking status.

Figure 1.

Screen shot: a graphically represented immediate family consists of a patient, father, mother, spouse, and two children in OurFamilyHealth

In our previous study, we introduced the principle and strategy of developing OurFamilyHealth, and also analyzed its early usage patterns ¹⁸. Although OurFamilyHealth was designed to capture and store essential FHH data elements based on the AHIC recommendation, yet it was not integrated with Intermountain’s EHR. As groundwork of the integration, we developed CEMs as baseline logic and data model to cover the essential of FHH information in OurFamilyHealth, to be eventually stored into our clinical data repository (CDR).

We currently have two use cases of utilizing the CEMs at Intermountain. First, OurFamilyHealth currently only collects patient’s FHH data but does not provide any decision support function to clinicians for patients. We have a plan to enhance the application connected to an external risk assessment service such as HughesRiskService ¹⁹. To do so, OurFamilyHealth should be able to transform its FHH data into a standard message to run against the service, but also to interpret outcome of risk assessment from the service and present it to patients. The other motivation is integration of FHH data into our new EHR based on Cerner. Since OurFamilyHealth is a locally developed tool, it does not yet interface with Cerner system and a standard message can be used to exchange OurFamilyHealth data with Cerner’s CDR and applications. The data model and logic of the CEMs can be used in the both use cases.

Limitation of current model

HL7 FHIR builds on previous data format standards from HL7, like HL7 version 2.x and HL7 version 3.x, and is the most enhanced standard to exchange healthcare data. It is easier to implement because it uses a modern web-based suite of Application Programming Interface (API) technology, including a RESTful (Representational State Transfer) protocol, a choice of JavaScript Object Notation (JSON) or XML for data representation. FHIR is currently on second stage of draft standard for use (DSTU 2) and provides an alternative to document-centric approaches by directly exposing discrete data elements as services. For example, basic elements of healthcare like patients, admissions, diagnostic reports and medications can each be retrieved and manipulated via their own resource uniform resource identifiers (URIs).

A resource in FHIR is a small logically discrete unit of data exchange and has a known identity by which it can be addressed. Among FHIR resources, FamilyMemberHistory resource in the clinical category is to represent a simple structure used to capture an elementary family history for a particular family member. Figure 2 depicts a diagram of the data model of FamilyMemberHistory.

Figure 2.

UML Diagram of FHIR Resource: FamilyMemberHistory (DSTU2)¹⁹

Since FHH information consist of disease history of a patient and family members, ideally a combination of a Patient resource and a set of Family MemberHistory resources with appropriate linkages between resources can represent a FHH. The problem is that a Family MemberHistory only describes “a relationship of a family member to a patient” using the HL3 v3 relation codes ²⁰, but it does not describe relationships between family members. For example, a FamilyMemberHistory resource instance with relationship code “PCOUSN” implies that a patient has a paternal cousin. But merely the relationship code does not examine who is parent of the cousin out of uncles and aunts, unless the patient has only one paternal uncle without aunts or one paternal aunt without uncle. Similarly, if a patient has multiple spouses and multiple children, a list of FamilyMemberHistory does not inform a child is from which of the spouses. As a result, we are unable to render a full pedigree from a set of FamilyMemberHistory.

FHH CEMs

The FHH CEMs are developed using Constraint Definition Language (CDL). CDLs were originally developed by GE Healthcare and are syntax for expression of constraint models that are key features of CEMs, with extensions including additions of new constraints to the modeling language, formalization of the model specialization capabilities, and a concrete reference object model 21. Based on our previous project, we have 126 CDLs to cover FHH including full pedigree, disease and conditions, and social history, such as smoking status, alcohol consumption status, and physical activity. Table 1 describes the key CDLs and their attributes.

Table 1.

FHH CDL

Category / data element		CDL	Data type
Patient	Identifier	PatientExternalIdentifier	IREF
	Name	GivenName	ST
		FamilyName	ST
	Gender	AdministrativeGender	CD
	Adoption	AdoptedInd	CD
	Race	AdministrativeRace	CD
	Ethnicity	AdministrativeEthnicGroup	CD
	Living status	DeceasedInd	CD
	Date of birth	BirthDate	TS
	Date of death	DeceasedDate	TS
	Age	Age	PQ
	Decease age	DeceasedAge	PQ
	Multiple birth	MultipleBirthInd	CD
		MultipleBirthType	INT
	Cause of death	CauseOfDeath	CD
Family relationship	Father	FamilyPanel {item Patient parent1, item Patient parent2, item Patient child}
	Mother
	Children
	Marital status	AdministrativeMaritalStatus	CD
	Consanguinity	ConsanguinityInd	CD
Disease and condition	Disease name	ClinicalAssert	CD
	Age of onset	AgeOfOnset	PQ
	Cause of death	CauseOfDeathInd	CD
	Note	ClinicalAssertNote	ST
Health behavior	Height	HeightMeas	PQ
	Weight	BodyWeightMeas	PQ
	BMI	BodyMassIndexMeas	PQ
	International travel	InternationalTravelInd	CD
		InternationalTravelDestination	CD
	Physical exercise	PhysicalExerciseDurationPerDay	PQ
		PhysicalExerciseFrequency	PQ
	Tobacco use	TobaccoUseStatusPanel	CD
		TobaccoUsePostcoordinated	CD
		TobaccoUseYears	PQ
		TobaccoUseQuitAttemptsInd	CD
		TobaccoUseCessationYears	PQ
		TobaccoUseFrequency	PQ
		TobaccoProductType	CD
		TobaccoUseNote	ST
	Alcohol use	AlcoholUseStatusPanel	CD
		AlcoholUsePostcoordinated	CD
		AlcoholUseFrequency	PQ
		AlcoholProductType	CD
		AlcoholUseNote	ST
	Drug abuse	SubstanceUseInd	CD
		SubstanceUseNote	ST

^*Data type: IREF (Item reference), PQ (Physical quantity), ST (String), CD (code), TS (Coded simple), INT (Integer)

Method

A FHIR profile is a set of base resources and is to author and publish a customized and more specific resource definition, by specifying a set of constraints and/or extensions on the base resource ²². Therefore concrete FHIR resources can express their conformance to a specific profile, and a FHIR server can to programmatically validate a given resource against the associated profile definition.

Our first step of profiling is to identify the base resources covering essential information of FHH, and then find extensions to cover rest of the information. We conducted a gap analysis between the FHH CDLs and current FHIR resources. The FHH CDLs are categorized by four meaningfully related groups ²³: patient, family relationship, disease and condition, and health behavior. For every data elements in each category, we investigated if there is a match of FHIR resources, and then compared details with value sets in data elements in the two domains.

Patient

In a family pedigree represented based on the FHH CEMs, all the persons in the tree are recognized as patients and they are flat. However, we can also specify one person in the tree as a proband: a term used in genetic counseling to refer a patient describing his/her FHH to a counselor. In this case, a proband is a node locates in the center of a family pedigree, and relationships of all family members may be described as a set of “relationship to proband” (e.g. paternal father of patient). Data elements in this category cover mainly patient’s demographic information such as name, age, sex, and race / ethnicity, etc. Table 2 presents gap analysis between the data elements of proband category.

Table 2.

Patient category: gap analysis

CDL	FHIR resource	Gap analysis
PatientExternalIdentifier	FamilyMemberHistory.identifier	EMPI* is used internally at Intermountain Healthcare. If a message is being used to share FHH between systems, system wide (or nation wide) master person index should be used to replace EMPI. If a message is being used to run risk assessment service and will not be stored anywhere, EMPI should be de-identified.
GivenName / FamilyName	FamilyMemberHistory.name	Exact match
AdministrativeGender	FamilyMemberHistory.gender	Exact match
AdoptedInd	FamilyMemberHistory.extension	HL7 relationship code is able to represent an adopted relationship of a family member, but it does not represent adopted by which family.
AdministrativeRace	FamilyMemberHistory.extension	Patient resource does not cover race, it may be added as an extension with value sets: White, Black/Afro American, American Indian, Asian Indian /Alaska native, Chinese, Filipino, Japanese, Korean, Vietnamese, Native Hawaiian, Guamanian / Chamorro, Samoan, Pacific islander, Other, Unknown
AdministrativeEthnicGroup	FamilyMemberHistory.extension	Patient resource does not cover race, it may be added as an extension with value sets: Non-Hispanic, Hispanic/Latino, Ashkenazi Jewish, Other, Unknown
DeceasedInd	FamilyMemberHistory.deceased	deceasedBoolean may be used.
BirthDate	FamilyMemberHistory.born	BirthDate has a qualifier of approximate flag. This should be added as an extension.
Age	FamilyMemberHistory.age	Exact match
DeceasedDate	FamilyMemberHistory.deceased	deceasedDate may be used.
MultipleBirthInd	Observation.category	This presents that a person belongs to one of multiple birth category. Observation.category = social-history
MultipleBirthType	Observation.valueString	Twin, Triplet, Quadruplet, Quintuplet, Sextuplet
CauseOfDeath	FamilyMemberHistory.extension

^*EMPI: Enterprise Master Person Index

Family relationship

The family relationship structure in FHH CDLs is described by the Family Panel contains three items: parent1, parent2, and child (See Figure 3), which means a unit family basically consists of two parents and one child. The model of the three items is Patient, which implies every family member in the Family Panel is considered as patients and also identified by PatientExternalldentifier that may be linked to patient records in EHR systems. AdministrativeMaritalStatus and Consanguinity represent marital information of parent1 and parent2. If a person has relationships with multiple spouses, Family Panels may be needed as many as the number of the spouses. For example, if person A has married twice with spouses B and C, and has had children D and E from with spouse, the relationship will be presented with two Family Panels consist of the following items: {A,B,D} and {A,C,E}.

Figure 3.

Family Panel in CEM presented as CDL.

Disease and condition

Disease and condition history of proband and family members is essential information to assess risk of genetic diseases. Not all disease and condition concepts are captured; the FHH CEMs may bind consumer-facing disease concepts or family history²⁴. These concepts are mapped to SNOMED concepts. When a FHIR message is created, local disease code should be transformed to a SNOMED code to ensure interoperability with external systems.

Health behavior

The FHH CEM also contains data elements of health behaviors, which are potentially related to genetic risk assessment as environmental factors (e.g. smoking history of family with lung cancer). We mapped Observation resource to represent health behaviors as they may cover a diagnosis, monitor progress, baselines and patterns, and demographic characteristics.

Gap analysis result

From the gap analysis in four categories, we identified five types of gaps to address between the two models.

• Exact match: concepts of data elements are same with their data types and value sets (e.g. first / last name, date of birth).

• Mapping required: race and ethnicity in the two domains have same concepts but different value sets and need to be mapped. For example, OurFamilyHealth captures “Ashkenazi Jews” particularly in ethnicity, as they statistically have more BRCA1 and BRCA2 genes that imply higher risk of breast, ovarian, and prostate cancer ²⁵, however HL7 ethnicity code does not support it.

• Reasoning required: e.g. inferring a family member’s adoption status in his/her family from a HL7 relationship code of the person and proband.

• Type conversion: age in years can be calculated from date of birth. However date of birth can be only estimated as a range from age in years.

• No match: existing FHIR resources or HL7 value sets do not cover consanguinity. It should be added as a new Observation or extension.

FHIR structure

In addition to selecting the base resources and extensions, we built a model of structure to integrate them in one FHIR message. We used two infrastructure resources: Bundle and List. Bundle refers to a container for a collection of resources, particularly to gather a collection of resources into a single instance with containing context. List is to contain a set of information summarized from a list of other resources and is a flat, possibly ordered, collection of records. Resources supported by the List resource can be homogenous – consisting of only one type of resource or heterogeneous – containing a variety of resources. Here we used List to contain homogenous resources such as Condition and FamilyMemberHistory. Using the features of Bundle and List, a structure of a FHH FHIR message can be formed as Figure 3.

In the structure, a family pedigree of a patient can have 1) a HeaderList that contains information of message header such as identifier of a FHIR message, message created (or sent) date, language code, etc., 2) a PatientBundle that contains a patient’s conditions and observations, and 3) a FamilyMemberHistoryList that contains multiple FamilyMemberHistory resources and their conditions and observations. All resources in the structure have resource references to a patient that indicate who is proband in a family pedigree. In addition, all Observations and Conditions of family members have subject references that indicate whom in the tree this clinical data belongs to.

Implementation

We implemented the proposed profile using HAPI framework; an open source based library for creating and validating FHIR messages. HAPI is pure Java based, and licensed under the business-friendly Apache Software License, version 2.0 ²⁶. Developers can create a FHIR message reusing Java objects, methods, and value sets provided by the libraries. Using these components, we developed a composer to generate a FHH FHIR message based on the profile we created.

To validate the FHH profile with HAPI, we used empirical patient data from OurFamilyHealth. FHH data in the database of OurFamilyHealth is stored in form of XML. We developed a parser to extract the XMLs from the database and decompose then as Java objects at the level of the FHH data elements. We automated parsing each patient’s FHH XML into individual data elements then feed them into the parser to generate FHIR XMLs. In the process we de-identified the data prior to creating messages by eliminating the tags of personal identification including names, birthdates of patients and families. As a result, we successfully created 4594 XMLs of FHH FHIR message (See example message in Figure 4).

Figure 4.

An XML of FHH FHIR message created based on HAPI. Two extension tags represent two parents of a patient (left), and their internal person Ids (Id = 1, 2) match person Ids of FamilyMemberHistory (right).

Conclusion and future research

Our approach of deriving the profile of FHH FHIR through gap analysis based on the CEMs was plausible. We successfully implemented the profile and created FHIR messages using an open source based FHIR framework and empirical patient data.

We have limitations in our study and future works to address them. First, although our FHH CEMs were developed to be a general data model for FHH, they were developed based on the local data model of OurFamilyHealth. In addition we used patient data from OurFamilyHealth for validating the profile. Because of this the profile should be more validated in outside Intermountain settings and use cases. Secondly, although we assumed that the profile would adopt the feature of the FHH CEMs that can link family members to patient records in EHRs, we have not validated the idea. In our use case, we assumed that all the patients are independent and don’t have any links each other.

There are ongoing efforts to validate and implement the created profile in real use cases. We are working with the team of HughesRiskApp to connect OurFamilyHealth to their risk assessment service through FHIR. Currently we are validating the profile based on the historical patient data to see it can properly be consumed and interpreted by the service. In the future we plan to run the service real-time. For example, at the end of a session that a patient enters FHH into the application, he/she will be presented risk analysis results given the information entered.

We are also working with Healthcare Services Platform Consortium (HSPC): a provider-driven organization of healthcare institutes, IT vendors, systems integrators, and venture firms, providing a collaborative platform to achieve the gold standard of semantic interoperability of healthcare applications ²⁷. HSPC is working on general profiling of FHIR based on CEMs, and our FHH profile will be part of the process eventually to be validated, publicized, and standardized.

Figure 3.

Composite structure of FHH bundle

Table 3.

Family relationship category: gap analysis

CDL	FHIR resource	Gap analysis
Parent1	FamilyMember.extension	Internal Id of a parent in a FHIR message
Parent2	FamilyMember.extension	Internal Id of a parent in a FHIR message
Child	FamilyMember.identifier	Internal Id of a child
Consanguinity	FamilyMember.extension	Consanguinity means that a father and a mother have another relationship than marriage.
AdministrariveMaritalStatus	FamilyMember.extension	This is to represent marital status for parent1 and parent2 at the time of data entry. Value sets: {married, divorced, partner, separated}

Table 4.

Disease / condition: gap analysis

CDL	FHIR resource	Gap analysis
ClinicalAssert	FamilyMemberHistory.condition.text	SNOMED code
AgeOfOnset	FamilyMemberHistory.condition.onsetQuantity	Age of onset as number
Cause of death	FamilyMemberHistory.condition.outcome	This is to specify a disease is cause of death or not.
Note	FamilyMemberHistory.condition.note	This is free text to describe details of disease history.

Table 5.

Health behavior: gap analysis

CDL	FHIR resource	Gap analysis
HeightMeas	Observation.category Observation.code Observation.value	Observation.category = “vital sign”
BodyWeightMeas	Observation.category Observation.code Observation.value	Observation.category = “vital sign”
BodyMassIndexMeas	Observation.category Observation.code Observation.value	BMI can be optional if in case height and weight are known. Otherwise it can be an independent measure.
InternationalTravelInd	Observation.category Observation.code Observation.value	Observation.category = “social-history”
InternationalTravelDestination
PhysicalExerciseDurationPerDay	Observation.category Observation.code Observation.value	Observation.category = “social-history”
PhysicalExerciseFrequency
TobaccoUsePostCoordinated	Observation.category Observation.code	Observation.category = “social-history” Temporal aspect of tobacco use can be translated and presented using Observation.valuePeriod based on computational reasoning.
TobaccoUseYears	Observation.valuePeriod
TobaccoUseQuitAttemptsInd
TobaccoUseCessationYears
TobaccoUseFrequency	Observation.valueQuantity
TobaccoProductType
TobaccoUseNote	Observation.comment
AlcoholUsePostCoordinated	Observation.category Observation.code	Observation.category = “social-history” Temporal aspect of alcohol use can be translated and presented using Observation.valuePeriod based on computational reasoning
AlcoholUseFrequency	Observation.valueQuantity
AlcoholProductType
AlcoholUseNote	Observation.comment
SubstanceUseInd	Observation.category Observation.code	Observation.category = “social-history”