Lessons Learned in Creating Interoperable Fast Healthcare Interoperability Resources Profiles for Large-Scale Public Health Programs

Abstract

Objective This article describes lessons learned from the collaborative creation of logical models and standard Health Level Seven (HL7) Fast Healthcare Interoperability Resources (FHIR) profiles for family planning and reproductive health. The National Health Service delivery program will use the FHIR profiles to improve federal reporting, program monitoring, and quality improvement efforts.

Materials and Methods Organizational frameworks, work processes, and artifact testing to create FHIR profiles are described.

Results Logical models and FHIR profiles for the Family Planning Annual Report 2.0 dataset have been created and validated.

Discussion Using clinical element models and FHIR to meet the needs of a real-world use case has been accomplished but has also demonstrated the need for additional tooling, terminology services, and application sandbox development.

Conclusion FHIR profiles may reduce the administrative burden for the reporting of federally mandated program data.

Keywords

family planning - health information - interoperability - SNOMED CT - LOINC - HL7 FHIR - reproductive health

Introduction

Interoperable health information systems can potentially improve the quality of patient care and reduce the burden on providers and health system administrators.[1] The prospect of utilizing emerging standards such as Health Level Seven (HL7) International's Fast Healthcare Interoperability Resources (FHIR) is particularly promising for large public health programs with networks comprising thousands of clinics utilizing disparate electronic health record (EHR) systems.[2] Federal health programs such as the U.S. Department of Health and Human Services' (HHS) Title X Family Planning Program and the Health Resources and Services Administration's (HRSA) Health Center Program require aggregate annual reporting from clinics receiving funding. Analyses based on aggregate data such as these are limited to descriptive trends that cannot be stratified by subgroups of interest. In addition, the Family Planning Annual Report (FPAR) collection form and analytics have thus far been based on manual data entry into electronic and paper-based forms, creating a significant administrative burden.[3] Patient-level data extracted directly from the EHR could provide a much more detailed evaluation of both the care delivered and the system delivering care. The HHS Office of Population Affairs (OPA) has called for a solution to help Title X Family Planning Program grantees provide this encounter-level data in a less burdensome and more automated way.

This article focuses on the experience of OPA in creating standard terminology-bound FHIR profiles for use in populating the FPAR and improving analytics. In collaboration with the American College of Obstetricians and Gynecologists (ACOG) and the Health Services Platform Consortium (HSPC), OPA's project marks the first federal health program to leverage interoperability standards to replace an outdated federal public health grantee data reporting system.[4] To meet the project's goal, data elements were defined based on standard terminologies and value sets, and FHIR profiles (knowledge assets) were created.[5] This work is at an early stage and the intention of this manuscript is to share lessons learned thus far, so others can benefit from our experience. A description of the processes involved in creating these standards, with a particular focus on developing standardized terminology and data elements meeting current FHIR specifications, is described here and may serve as a guide to health care networks with similar reporting needs and goals. Exposing unresolved challenges in creating and implementing these FHIR profiles may also help advance development of these nascent standards.

Background and Significance

The federal Title X Family Planning Program was legislated in 1970 as part of the Public Health Services Act and is the only federal grant program dedicated to providing individuals with comprehensive family planning and related preventive health services.[6] [7] [8] [9] The HHS/OPA receives annual appropriations of approximately $286.5 million USD from the U.S. Congress and administers the Title X program by awarding competitive grants to eligible health care entities, including state and local health departments, federally qualified health centers, nonprofit health care organizations, independent reproductive health care organizations, universities, and more. Types of services provided by clinical sites in the Title X Family Planning Program network include contraceptive supplies and information, breast and cervical cancer screening, sexually transmitted disease (STD) testing, human immunodeficiency virus (HIV) testing, and referral for treatment. Title X is designed to provide access to these important reproductive health services to all individuals who want and need them throughout the United States, its territories, and jurisdictions.

The Title X clinical network is vast, with approximately 90 grantees and over 4,000 clinical service sites. There are over 100 different EHR products in use at these sites. As an annual requirement of receiving federal funding, all Title X grantees must report key programmatic and operational data to OPA through the FPAR.[7] Since 1970, OPA has requested cumulative data for each grantee's network of clinics providing Title X services. The first version of the FPAR (1.0) requested only summative data from the sites. This dataset was compiled by manual chart review and using a simple spreadsheet program to tally up totals for a month or year. The summary nature of this dataset precluded any detailed analysis of the care provided at the site. A new initiative was approved (FPAR 2.0) to retrieve data at the individual patient visit level to facilitate more detailed and sophisticated analytics. OPA has been investigating a system for collecting encounter-level data directly from EHR systems at Title X service sites with the dual purpose of improving data quality and reducing reporting burden on grantees and their networks.

Initial work toward this goal focused on the development of a Consolidated-Clinical Document Architecture (C-CDA) specification for clinical family planning encounters. The C-CDA for family planning profile was developed in partnership with a standards development organization (SDO) Integrating the Healthcare Enterprise (IHE).[6] [10] This C-CDA profile, the “IHE Family Planning Profile,” underwent multiple rounds of public comment to define and assess feasibility of electronically collecting the data elements necessary for Title X reporting and quality improvement efforts. While “Meaningful Use” has made production and exchange of C-CDAs a requirement for EHR systems, there are limitations to this data exchange format.[11] For example, recommended coding systems are not enforced and the data model is complex.[12] The C-CDA was tested at the IHE 2015 North American Connectathon by five vendors (Mitchell and McCormick, Netsmart, Patagonia, GE Centricity, and ithlcoserve—an international vendor).[13] Results from testing revealed several shortcomings to the C-CDA specification, including mapping errors, issues with correct logical models for data elements, and several missing data elements.

In 2016, OPA decided to pursue a FHIR-based platform in addition to continuing development of the C-CDA specification.[14] Building upon experiences in creating the C-CDA profile, OPA engaged a range of partners and issued a contract to ACOG to pursue development of a FHIR-based platform for this data exchange as well as updating the C-CDA specification to correct identified deficiencies. FHIR is increasingly recognized as the preferred solution to enable application-based interoperable health information tools.[15] [16]

Objective

ACOG's primary objective was to guide the development of the FHIR-based platform for OPA by engaging the HSPC terminology and modeling experts. HSPC is a provider-driven organization of leading health care organizations, information technology (IT) vendors, systems integrators, and venture firms dedicated to accelerating the delivery of a platform that supports innovative health care applications for the improvement of health and health care. Intermountain Healthcare and ACOG are HSPC members. HSPC's mission is to improve health by creating interoperable platforms, applications, and knowledge assets. To provide a foundation for this effort to reach true semantic interoperability, HSPC includes a terminology and modeling initiative. This involves implementation and adoption of standards developed by SDOs composed of HL7 FHIR, HL7 Clinical Information Modeling Initiative (CIMI), Logical Observation Identifiers Names and Codes (LOINC), SNOMED Clinical Terms (SNOMED CT), Argonauts, and other related industry efforts.

OPA's FPAR 2.0 is HSPC's pilot project for developing standardized logical models for FHIR profiles. FHIR specifies a framework for this type of standardization.[2] [17] Mapping the data elements in the FPAR 2.0 specification to a FHIR standard provides a guide for vendors currently supplying Title X clinical sites. While FHIR has been demonstrated in specific environments, such as laboratory information systems, operationalizing this standard across Title X sites is an opportunity to demonstrate HSPC's provider–vendor collaboration as well as FHIR's utility in both testing and production environments on a large scale.[18] To demonstrate the use of FHIR standard profiles for transmitting the FPAR 2.0 dataset, we hope to use FHIR servers established by a group of EHR vendors serving the Title X network to measure the reliability and accuracy of data transmission.

Materials and Methods

The project team of OPA and ACOG convened three stakeholder groups to review the work and provide feedback: (1) a technical steering committee of experts from leading health IT organizations including Intermountain Healthcare, HSPC, HHS Office of the National Coordinator, HHS Department of Veterans Health Affairs, HHS Centers for Disease Control and Prevention, IHE, and ACOG; (2) an EHR vendor work group comprising 13 vendors serving the majority of the Title X network including Patagonia Health, Epic, and NextGen; and (3) a Title X grantee expert work group with representatives from 10 Title X grantee organizations including state health departments, federally qualified health centers, and independent reproductive health care organizations. Regional OPA staff and national associations representing Title X grantees were also members of this group to ensure that all perspectives were represented during the development of the project. Periodic webinars with these groups provided alignment of stakeholders' needs. Weekly meetings of the core project team kept the day-to-day aspects of the project on track and Web-based meetings to review the work were regularly scheduled as well. The process for developing the FHIR platform for OPA is displayed in [Fig. 1]. The methods and results are described below.

Fig. 1 FPAR FHIR development process. FHIR, Fast Healthcare Interoperability Resources; FPAR, Family Planning Annual Report.

Data Element Analysis

The project team reviewed the FPAR 2.0 data elements for semantic consistency and nonambiguity and each definition was assessed to ensure that the data elements were clearly defined. The definitions were then discussed and redefined as needed by OPA to ensure that the data elements, once collected, would meet the needs for programmatic oversight and quality improvement analyses. A key focus of this baseline analysis was whether the content was at the level of granularity needed to query data stored in an EHR and autopopulate the FPAR data elements.

Data Model Request

Following analysis, the data were entered into a model request spreadsheet which included the data element, definitions, data types, cardinality, units of measure, and each value needed for nominal data elements. The spreadsheet was then used in the following steps for mapping to standard terminologies, existing models, and determining broadly the fit to existing FHIR profiles.

Mapping to Standard Terminologies

To evaluate gaps between the FPAR data and terminology standards, we mapped the data elements to LOINC (version 2.56) and the data element values to SNOMED CT (version 2017–01–31). For example, the FPAR data element “Date of Birth” was mapped to LOINC code 21112–8 “Birth Date.” These terminologies were chosen because of the recommendations outlined in the Interoperability Standards Advisory (ISA) and the data elements and value sets within the U.S. Core FHIR profiles.[19] [20] [21] Experts in both LOINC and SNOMED CT (S.M. and B.H.) performed the mapping. When a match was found, the appropriate code and fully specified name (FSN) were added into additional rows within the model request spreadsheet. When the FPAR content could not be matched, new content was requested from either LOINC or SNOMED CT using each organization's standard request process, e.g., the US SNOMED CT Content Request System (USCRS).[22]

Value Set Definition

Value sets for each nominal (or coded) data element were developed in the National Library of Medicine's (NLM) Value Set Authority Center (VSAC).[23] [24] VSAC offers both a shareable repository and a source of values for value sets used to satisfy reporting requirements and, importantly, provides the ability to keep value sets up to date with terminology updates. With the use of VSAC as a central repository and FHIR's referencing capability, updates to the value set should be immediately accessible to adopters of the FHIR profiles. Within VSAC, the value set definition is expressed by the codes the value set contains. In the process of value set creation, OPA and ACOG reviewed both the value set content and metadata to ensure accuracy and completeness. Initial value set members were chosen by examining data values used by Intermountain Healthcare and consulting with ACOG's subject matter experts, then by mapping these values to SNOMED CT or LOINC Answer (LA) codes.

Clinical Element Logical Model Development

Logical models were developed for each FPAR data element. Logical models are integral to the development pipeline because they are a platform-independent modeling form, language and implementation agnostic, and not limited by the constraints of the programming language. Logical models can be used in many other areas besides FHIR, such as creating documentation screens, decision support, electronic clinical quality measures (eCQMs), and as a research framework. Intermountain chose to use clinical element models (CEMs) instead of CIMI models because CIMI was still in development and was lacking tools to support the recommendations. The CEMs will be transformed to CIMI models as soon as the model formalism and tooling is available. CEMs are a means of logically representing both the semantics and structure of the data elements using Clinical Element Modeling Language (CEML).[25] CEML specifies how to create a “model” of a particular type of data (such as a clinical observation), where the model declares how a valid “instance” of that type of data should be structured, and the semantics of that structure. The CEM consists of a generic structure of data and defines how to constrain the generic structure to create specific CEMs.[19] A CEM is a human-readable, textual outline of the key pieces of data. These pieces consist of the data's name and value (a name/value pair) along with components that qualify the data's meaning. The CEMs conform to a syntax. This allows for the use of a compiler to ensure correctness and accuracy. This also makes it possible to generate computable model serializations, such as eXtensible Markup Language (XML) or JavaScript Object Notation (JSON), consumable by software.

The CEMs contain all the data elements needed to represent their target concept. For example, the “patient” CEM contains the elements required to represent the concept of a patient (first name, given name, identifiers, etc...). Each data element in a CEM is linked to a term from a standard terminology.

Model developers used the model request spreadsheet with additionally specified column headings to define the data element requirements for CEMs. The spreadsheet identified the main data elements and component elements (qualifiers, modifiers, and attributes), along with data types and data values. Data values are typically coded concepts that are the responses recorded for the data element. These are needed to create the proper value set constraints. These constraints define the allowed data values.

During the definition process, additional data elements were added to the same spreadsheet by OPA and ACOG with the assistance of Intermountain. For example, pregnancy status was divided into two data elements: self-reported and laboratory reported. The spreadsheet was then analyzed by the modeling engineers to determine the model structures which identified data types and value sets needed. The final spreadsheet was used to guide the creation of the CEMs.

The modeling engineers created the CEMs using the Clinical Element Design and Review tool (CEDAR). CEDAR was designed and developed by Intermountain Healthcare and is currently only available to Intermountain Healthcare employees. CEDAR allows a modeling engineer to write a new textual representation of the CEM, edit an existing CEM, save it as a text-based file, and export it in various formats. The modeling formalism used within CEDAR is CEML.[25] [26] CEDAR simplifies the creation process by incorporating automatic syntax checking of the CEM with a compiler and is able to export the CEM into different formats such as XML and JSON. CEDAR also incorporates the ability to connect to a terminology server facilitating the binding of CEMs to standard terminologies.

FHIR Profiles

The FHIR profiles were created using the CEMs for reference with FHIR resources version 3 (STU3) and STU3 versions of the U.S. Core profiles as the basis for the FPAR profiles.[2] [21] The CEMs were compared with the U.S. Core FHIR profiles or base FHIR resources (if a U.S. Core profile did not exist) to determine which they most closely matched (e.g., observation, condition, or patient resource).[21] Once identified, the matched U.S. Core profile or FHIR resource was used as a template from which a profile was adapted manually.[17] This manual process consisted of editing an XML file; adjusting tag headings, changing tag-identifying values, adding bindings, removing sections, tags, or bindings, and modifying the overall XML file to be a child of either a U.S. Core profile or a FHIR base resource. Profiling facilitates extending and/or constraining resources for particular use cases.

In the case of the laboratory observations, we were able to utilize a more automated approach using Perl scripts to produce the profiles since these were very similar in structure and all used the U.S. Core Observation Results profile as their base. The FHIR profiles were then validated for structure and syntax using a validation tool downloaded from the FHIR Release 3 (STU) Web site.[27]

Results

Analysis

Nine of the FPAR data elements, such as organization identity document (ID), practitioner ID, race, and ethnicity, were already contained as parts of either FHIR STU3 base resources or the U.S. Core STU3 published profiles. Twelve nonlaboratory data elements, such as pregnancy status, parity, annual household income, and household size, required new profiles. Many of these required the creation of more than one profile. For example, the data element “pregnancy status” (positive, negative, or unknown) can be derived from laboratory results or stated by the patient. Hence, the “pregnancy status” data element has seven data elements to consider, the subjective observation and six different pregnancy laboratory results.

Additionally, FPAR contained data elements for “date of last X lab observation” where “X” is a specific laboratory result such as tests for chlamydia, gonorrhea, and HIV. Aside from the date, FPAR finds great value in the additional detail provided by the type and result of a laboratory. FHIR Observation resource facilitates the reporting of test date, test performed, and result. The laboratory results could potentially be stored in the EHR with different LOINC codes because of differing specimen types, properties and methods. Therefore, we included a curated list, based on ACOG's recommendations and clinical use, of appropriate laboratory result LOINC codes to facilitate autoretrieval of the data. This vastly increased the number of specific FHIR profiles required for this project. [Fig. 2] illustrates four of the seven laboratory results required to retrieve the appropriate HIV tests.

Fig. 2 HIV test results. HIV, human immunodeficiency virus.

FHIR profiles and CEMs built for these laboratory codes are created to explicitly retrieve specific laboratory result LOINC codes and value sets, which satisfy the FPAR laboratory date and value data elements. The laboratory results include Pap smear, HIV, human papilloma virus, and both individual and combined chlamydia and gonorrhea tests. A group of pregnancy tests is also identified to satisfy the method of pregnancy detection data element. These laboratory profiles, based on the FHIR Observation resource, are meant to be used for data retrieval to autopopulate to FPAR ([Table 1]).

Table 1 Number of LOINC codes for reporting laboratory tests

Laboratory test	PAP	HIV	HPV	Chlamydia	Gonorrhea	Combined chlamydia/gonorrhea	Total profiles
Number of LOINC codes	8	7	16	24	20	11	86

Abbreviations: HIV, human immunodeficiency virus; HPV, human papillomavirus; LOINC, Logical Observation Identifiers Names and Codes; PAP, Papanicolaou.

Terminology Content

Across the data elements and values, 236 unique concepts were required, of which 179 (76%) were found in existing standard terminologies (see [Table 2]). As stated above, we attempted to constrain our mapping to SNOMED CT and LOINC. However, there were four data elements requiring content from different terminologies. These included birth sex that aligned with administrative gender containing HL7 Terminology concepts; race and ethnicity containing Centers for Disease Control (CDC) concepts; and insurance coverage type containing source of payment typology codes for insurance payment concepts.[28] We requested the insurance types from SNOMED CT but were denied because SNOMED CT does not contain insurance types.

Table 2 Mapping of concepts to standard terminologies

	Concepts in models N	Present in terminologies N (%)	New requests N (%)	Requests denied or withdrawn N	Concepts identified by SDO N
SNOMED CT	66	43 (65)	23 (35)	8	8
LOINC	147	126 (86)	21 (14)	3	3
LOINC panels	13	0	13 (100)	0	0
Administrative gender	3	3 (100)	N/A	N/A	N/A
CDC race and ethnicity	7	7 (100)	N/A	N/A	N/A
Total	236	179 (76)	57 (24)	11	11

Abbreviations: CDC, Centers for Disease Control; LOINC, Logical Observation Identifiers Names and Codes; SDO, standards development organization.

One hundred forty-seven of the concepts required LOINC codes: 95 laboratory observation codes, 36 FPAR data elements, and 16 LAs. Of the 36 data element LOINC codes, 17 resulted in new LOINC codes. Thirteen new LOINC panel concepts were requested to organize the LOINC codes into a nested panel structure (LOINC code 86636–8, Family planning report—FPAR 2.0 set). There were 66 SNOMED CT codes needed, of which 23 were new and requested via the USCRS. Eight of these requests were withdrawn or rejected by the SNOMED CT team. We were instructed to use “organism” instead of the “finding” semantic type for three “microorganism detected” concepts and less specific concepts for the other five. For example we requested “contraceptive method provided during visit” and were advised to use “patient encounter procedure.” The extensive process to request new concepts helped refine the data element definitions as well as the values used. However, the time between request and SDO content release increased the time for delivery of the FPAR content.

Value Set Creation

Twenty-seven value sets were required for the FPAR. These were aligned with existing value sets published in the FHIR profiles and/or VSAC. As described above, we were able to reuse four value sets previously in VSAC: race, ethnicity, administrative gender, and payer. Twenty-one new value sets were created: seven for grouping LOINC codes for laboratory and pregnancy tests, and 14 for data element answer lists.

There were two value sets containing copyrighted content from other organizations outside of OPA's purview. Hence, copyright needed to be obtained by LOINC from the two organizations for the content to be used. First, One Key Question (OKQ), stewarded by Power to Decide, was needed to result the pregnancy intention data element.[29] Second, the Bethesda System was required for resulting Pap smears.[30] We engaged with the LOINC team and the organizations to facilitate creation. Consequently, OKQ has been created in LOINC and the value set is in VSAC. Despite multiple attempts, the value set containing the Bethesda System has yet to be created.

OPA accepted stewardship responsibility for the other new value sets required for the FPAR data elements. After the new value sets were created, the steward validated each value set and published it within VSAC.

CEM Logical Model Creation

One-hundred twenty-eight CEMs were created. This included 94 laboratory models and 34 patient observation models. As a convenient means of locating individual test results for a group of laboratories needed to result one FPAR data element, such as HIV tests, we created CEM panels.

FHIR Profile Creation

Ninety-four FHIR profiles (mostly laboratory evaluation results and other observations) are derived from the U.S. Core “ObservationResults” profile. The “Patient”, “Practitioner,” and “Organization” profiles are derived from the corresponding U.S. Core profiles. All of the U.S. Core profiles are derivations of their respective STU3 FHIR base resources. The “Coverage”, “Encounter”, “PractitionerRole”, and “ReferralRequest” profiles are derived directly from their corresponding STU3 FHIR base resources.

There were challenges encountered during the CEM to FHIR transformation process. FHIR did not have all the elements needed, so FHIR extensions had to be created. For example, “deltaFlag” was added to all laboratory profiles.[31] The encounter resource contained 13 extensions such as “ambulatoryStatus”, “hospitalOrganization”, and “departedByTransportation.” The extension may be because FHIR uses the 80/20 rule and CEMs are prescriptive. The extensions may prove a challenge for implementers because they need to know if code should be created for each extension.

Second, mapping from the CEM attributes to the FHIR attributes was a challenge because the CEM naming convention is different from FHIR. For example CEM “ProviderPractitioner” is synonymous with FHIR “Practitioner.” This required manual review of the CEM and FHIR attribute definitions.

Discussion

This article demonstrates the steps taken by a large federal health program to develop interoperability standards to collect encounter level data and replace outdated aggregate data reporting systems. In the process of developing these standards, some difficulties were encountered and are outlined below.

Terminology Issues

Mapping the data elements and values is important for interoperability but obtaining new SNOMED CT and/or LOINC codes is a time-consuming process. The mean turnaround time for LOINC codes posted on their submission site is 125 days. For SNOMED CT, our submission was in April 2017 and finalized completely in March 2018. The process of obtaining new codes may prove to be a significant bottleneck to wholesale development of FHIR profiles. Therefore, we recommend budgeting project time for this process and engaging early with the SDOs.

The ISA recommendation to use LOINC for the question and SNOMED CT for answer lists poses a challenge because there is only shared governance between LOINC and SNOMED CT for laboratory and vital sign observations, not for the nominal answer list concepts.[31] As a result, duplicate concepts, especially for answer lists, are being created in both LOINC and SNOMED CT.

Obtaining permission to use copyrighted proprietary content poses two challenges. First, dependence on external data stewards and the inability to create needed value sets such as the Bethesda System slows down the process and hampers interoperability. Second, the copyright owner may not grant permission for their content to be included in the standard terminologies. Due to these restrictions there is significant risk to open source development of FHIR profiles with copyrighted instruments.

We created all the value sets in VSAC because VSAC uses FHIR “value set expansion” services for value set retrieval. We were unable to retrieve the value set using the object identifier (OID) because VSAC did not allow a system to login for authentication, only a person. Therefore, we created value set references for value sets in the FHIR structured definitions. This issue was communicated to the VSAC staff at the NLM.

CEM/FHIR Issues

One may ask why create CEMs and not just the FHIR profiles? CEMs are logical models that are static while FHIR is an evolving standard requiring remapping to the next FHIR version. This proved truly beneficial when FHIR versions moved from STU2 to STU3 since the logical models could be applied to either version. Also, FHIR is an implementation specification while logical models can be used for multiple purposes such as decision support, documentation, and analysis.

The FHIR profiles were developed in STU3 in the expectation that EHR vendors would be transitioning to this version of FHIR in 2017 to 2018. At the time of this writing, however, no vendor has offered a release date for STU3 FHIR services. We believe they are likely to stay on version 2 and then jump to version 4. This limits our ability to test these profiles outside of sandbox environments and against real patient data. Hopefully this situation will resolve over the coming months. A larger problem is whether a given EHR vendor will have representation of the specific FPAR data elements in their foundational build and whether clinicians will capture all data elements in their clinical workflows. Many vendors have been eager to comply with the data elements requested but we expect having complete representation of the FPAR 2.0 data elements across all 100 plus EHR vendors serving the Title X network will require time and assistance from OPA and project partners.

The number of FHIR profiles developed may seem daunting to the implementer due to the previously described laboratory issues. It appears the adopters need to support 100 plus data elements, when in reality it is around 40. The laboratory profiles are also aggregated and queried using FHIR services to simplify the process for reporters by providing the LOINC code and value set where applicable.

Future work encompasses validation of the FHIR profiles, validation of the implementation guide, and testing.[32]

Recommendations

Retrieving data from EHRs requires an understanding of how the data are entered into an EHR. We recommend working with specialty organizations (such as ACOG) to ensure that the correct clinical data are chosen, and the logical model is accurately represented by the specific data element in question. We endorse reusing U.S. Core FHIR profiles and VSAC value sets wherever possible. New FHIR profiles should be built using software developed for this specific purpose (tooling) instead of manually editing the XML or JSON source files. The longest part of the process is the wait times for new vocabulary requests; therefore, new content should be identified as soon as possible in the process.

The FHIR profiles built here can be used for other things such as clinical documentation and eCQMs. For example, in a parallel effort, OPA is leveraging this work on standardized data elements for family planning by respecifying three National Quality Forum-endorsed contraceptive provision measures into eCQMs.[33] [34] [35] The three performance measures are contraceptive care—(1) most and moderately effective methods; (2) access to long-acting reversible contraception; and (3) postpartum and evaluate the type of and effectiveness of contraception provided to women age 15 to 44 years. The FPAR data elements used to query for these measures include birth date (LOINC code 21112–8), pregnancy status (LOINC code 82810–3), contraceptive method at intake (LOINC code 86649–1), and contraceptive method at exit (LOINC code 8653–3). These measures will provide a way for grantees and OPA to assess quality of care at various sites, and for the sites themselves to understand opportunities for improving care delivery.

Vendors need to be involved in the project from the beginning because new FHIR application programming interfaces (APIs) and terminology mappings will be needed. The use of FHIR requires vendors to map their internal identifiers to the standard terminology codes used to retrieve the data. These mappings are used for code-to-code translations using the FHIR terminology services. Also, vendors will need to increase the number of FHIR resources they support, beyond U.S. Core. In our case, seven different resources were used, including four that are not part of U.S. Core. Preliminary testing of a SMART on FHIR application to pull the FPAR 2.0 data elements from a production server has demonstrated numerous gaps related to insufficient mapping, and insufficient resource availability (S. Hasley, unpublished data). As FHIR matures, hopefully these gaps will diminish, but close communication with vendors is imperative so they have a sense of real-world priorities.

Conclusion

The digital promise of making health care knowledge interoperable and thereby improving care at all levels of the health care system is still far from being realized. OPA is attempting to actualize the Learning Healthcare System by retrieving patient-level data from a wide range of practice settings and EHR systems. Being able to compute quality metrics across multiple sites using EHR encounter-level data will further the goal of ensuring all Title X clients have access to high-quality family planning services. Reducing the burden of collecting these data will increase the efficiency of the process, and lower costs.

As stated earlier, the development of FPAR 2.0 FHIR profiles is the first step in this vision of interoperable federal reporting. Testing of these profiles is underway. As more vendors adopt FHIR and stand-up working FHIR services, this project will expand into testing against real patient data. The next step is for OPA to test the family planning FHIR profiles with a handful of Title X service sites and their EHR vendors.

The burden of moving data from one silo to another, often with a human interface as the mechanism for this movement, severely hampers advances in health care. This project lays out the steps for a process to improve this movement of data, exposes current challenges, and has produced artifacts for exploring the next step of this journey.

Clinical Relevance Statement

The use of logical models and FHIR profiles encoded with standard terminologies can facilitate data collection and analytics. Patient data regarding family planning, collected in a standardized format, can facilitate quality family planning service provision. Performance measures for contraceptive provision can be calculated in a standard way. The FHIR profiles described in this article can be reused across specialties and settings. As FHIR gains more of a foothold, organizations that report registry information can use the same technology for reporting patient-specific data. With further development, clinical pathways (apps) can access FHIR-based data across multiple platforms and return standard advice to clinicians in multiple venues.

Multiple Choice Questions

1. The FPAR data element “Date of last HIV” required more than one FHIR profile. Why?

   • To facilitate autopopulation of laboratory data.

   • To test FHIR query services.

   • Because the data element required information from more than one FHIR profile.

   • To facilitate manual data entry.

   Correct Answer: The correct answer is option a. The FPAR data element for “Date of last HIV” test result was independent of specific laboratory tests and we had no control over which test a given clinical site might use. Therefore, we included a list of appropriate laboratory tests to facilitate autopopulation of the data.

2. Why were LOINC and SNOMED CT terminologies chosen?

   • They have the clinical content needed to encode FPAR.

   • They provide a hierarchy that can be used for queries.

   • Because of the recommendations outlined in the Interoperability Standards Advisory (ISA).

   • They support the encoding of decision logic.

   Correct Answer: The correct answer is option c. The Interoperability Standards Advisory recommends specific terminologies for clinical areas. LOINC is recommended for clinical and laboratory observations and SNOMED CT is recommended for observation answers.

Conflict of Interest

None declared.

Acknowledgments

We would like to acknowledge HSPC members who considered this their “pilot project” and reviewed the results throughout the process. Viet Nguyen, MD, and Rick Freeman were instrumental in advising us regarding the model alignment to FHIR profiles. The process went smoothly because of our project manager Saritha Patur. Thank you to the EHR vendors who have been collaborating with OPA through the FPAR 2.0 EHR vendor workgroup and to the Title X sites that volunteered to participate in piloting FHIR.

Protection of Human and Animal Subjects

This project did not involve human/animal subjects.

• References

• 1 Braunstein ML. Patient–physician collaboration on FHIR (Fast Healthcare Interoperability Resources). Paper presented at: International Conference on Collaboration Technologies and Systems (CTS). IEEE; 2015:501–503
• 2 HL7. FHIR overview. 2017. Available at: http://hl7.org/fhir/overview.html . Accessed July 19, 2018
• 3 Office of Population Affairs. Title X Family Planning Annual Report Forms and Instructions. Rockville, MD: OPA; October 2016. Available at: https://www.hhs.gov/opa/sites/default/files/fpar-forms-instructions-reissued-oct-2016.pdf . Accessed October 11, 2018
• 4 HSPC. Health Services Platform Consortium. 2018. Available at: https://www.hspconsortium.org/ . Accessed July 19, 2018
• 5 HL7. Profiles defined as part of FHIR. 2017. Available at: http://hl7.org/fhir/profilelist.html . Accessed July 19, 2018
• 6 D'Amore JD, Mandel JC, Kreda DA. , et al. Are meaningful use stage 2 certified EHRs ready for interoperability? Findings from the SMART C-CDA Collaborative. J Am Med Inform Assoc 2014; 21 (06) 1060-1068
• 7 Fowler CI, Lasater B. Family Planning Annual Report: 2016 National Summary. Research Triangle Park, NC: RTI International; 2017. Available at: https://www.hhs.gov/opa/sites/default/files/title-x-fpar-2016-national.pdf . Accessed January 03, 2019
• 8 U.S. Government Publishing Office. Title 42 Code of Federal Regulations (CFR) Part 59, Grants for Family Planning Services. 2000. Available at: https://www.govinfo.gov/content/pkg/CFR-2007-title42-vol1/pdf/CFR-2007-title42-vol1-part59.pdf . Accessed January 03, 2019
• 9 Department of Health and Human Services. Public Health Service Act, 42 U.S.C. 300, et seq. Title X – Population Research and Voluntary Family Planning Programs. Available at: https://www.hhs.gov/opa/sites/default/files/title-x-statute-attachment-a_0.pdf . Accessed January 03, 2019
• 10 Vegoda P. Introducing the IHE (Integrating the Healthcare Enterprise) concept. J Healthc Inf Manag 2002; 16 (01) 22-24
• 11 Centers for Medicare & Medicaid Services (CMS), HHS. Medicare and Medicaid programs; electronic health record incentive program. Final rule. Fed Regist 2010; 75 (144) 44313-44588
• 12 Mandel JC, Kreda DA, Mandl KD, Kohane IS, Ramoni RB. SMART on FHIR: a standards-based, interoperable apps platform for electronic health records. J Am Med Inform Assoc 2016; 23 (05) 899-908
• 13 IHE. Family planning. 2017. Available at: https://wiki.ihe.net/index.php/Family_Planning . Accessed October 27, 2018
• 14 IHE QRPH Technical Committee. Family Planning Version 2 10 (FPv2) Rev. 1.2–Trial Implementation. 2018. Available at: http://www.ihe.net/uploadedFiles/Documents/QRPH/IHE_QRPH_Suppl_FPv2.pdf . Accessed October 27, 2018
• 15 Rosenbloom ST, Carroll RJ, Warner JL, Matheny ME, Denny JC. Representing knowledge consistently across health systems. Yearb Med Inform 2017; 26 (01) 139-147
• 16 Bloomfield Jr RA, Polo-Wood F, Mandel JC, Mandl KD. Opening the Duke electronic health record to apps: implementing SMART on FHIR. Int J Med Inform 2017; 99: 1-10
• 17 Leroux H, Metke-Jimenez A, Lawley MJ. Towards achieving semantic interoperability of clinical study data with FHIR. J Biomed Semantics 2017; 8 (01) 41
• 18 Gordon WJ, Baronas J, Lane WJ. A FHIR human leukocyte antigen (HLA) interface for platelet transfusion support. Appl Clin Inform 2017; 8 (02) 603-611
• 19 Office of the National Coordinator for Health Information Technology. Interoperability Standards Advisory. 2018. Available at: https://www.healthit.gov/isa/ . Accessed July 19, 2018
• 20 HL7. US Core Implementation Guide (Release 1.0.1) 2017. Available at: http://www.hl7.org/fhir/us/core/ . Accessed July 19, 2018
• 21 HL7. Profiling FHIR. 2018. Available at: http://build.fhir.org/profiling.html . Accessed October 26, 2018
• 22 National Library of Medicine. U.S. SNOMED CT Content Request System (USCRS). 2018. Available at: https://uscrs.nlm.nih.gov/ . Accessed July 19, 2018
• 23 Bodenreider O, Nguyen D, Chiang P. , et al. The NLM Value Set Authority Center. Stud Health Technol Inform 2013; 192: 1224
• 24 National Library of Medicine. Value Set Authority Center. 2018. Available at: https://www.nlm.nih.gov/vsac/support/index.html . Accessed July 12, 2018
• 25 Oniki TA, Coyle JF, Parker CG, Huff SM. Lessons learned in detailed clinical modeling at Intermountain Healthcare. J Am Med Inform Assoc 2014; 21 (06) 1076-1081
• 26 Oniki TA, Zhuo N, Beebe CE. , et al. Clinical element models in the SHARPn consortium. J Am Med Inform Assoc 2016; 23 (02) 248-256
• 27 HL7. FHIR validation resources. 2018; Available at: https://www.hl7.org/fhir/validation.html . Accessed July 12, 2018
• 28 National Library of Medicine. SOP (Source of payment typology) - synopsis. 2017. Available at: https://www.nlm.nih.gov/research/umls/sourcereleasedocs/current/SOP/ . Accessed July 19, 2018
• 29 Power To Decide. One Key Question. 2018. Available at: https://powertodecide.org/one-key-question . Accessed July 19, 2018
• 30 Solomon D, Davey D, Kurman R. , et al; Forum Group Members; Bethesda 2001 Workshop. The 2001 Bethesda System: terminology for reporting results of cervical cytology. JAMA 2002; 287 (16) 2114-2119
• 31 SNOMED International. Regenstrief and the SNOMED International are working together to link LOINC and SNOMED CT. 2017. Available at: https://loinc.org/collaboration/snomed-international/ . Accessed December 3, 2018
• 32 HL7. The Family Planning Annual Report (FPAR) Implementation Guide. 2018. Available at: http://build.fhir.org/ig/hspc/ACOG-OPA-IG/ . Accessed November 2, 2018
• 33 Gavin L, Frederiksen B, Robbins C, Pazol K, Moskosky S. New clinical performance measures for contraceptive care: their importance to healthcare quality. Contraception 2017; 96 (03) 149-157
• 34 Gavin LE, Ahrens KA, Dehlendorf C, Frederiksen BN, Decker E, Moskosky S. Future directions in performance measures for contraceptive care: a proposed framework. Contraception 2017; 96 (03) 138-144
• 35 Moniz MH, Gavin LE, Dalton VK. Performance measures for contraceptive care: a new tool to enhance access to contraception. Obstet Gynecol 2017; 130 (05) 1121-1125