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
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
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
Multiple Choice Questions
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.
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.
