Skip to end of metadata
Go to start of metadata

Introduction

As the health care industry has moved to electronic medical records, it has taken iterative steps in the evolution of this technology. Although transition to an electronic platform has mostly replaced paper, ushering in potential efficiencies in care, capabilities in surveillance and speedier access to records, much of the industry remains siloed in disparate systems. Interoperability of electronic medical records is imperative to advancing the sharing of information across care teams, inclusive of patients and their caregivers; promoting innovations in technical tools, such as apps; and continuing population health efforts, such as registries for disease surveillance.

The good news is that the potential for interoperability in health care is at our doorstep, and its name is FHIR® (Fast Healthcare Interoperability Resources). FHIR is the next step in data standards in health care out of HL7, one that brings the potential to embed more easily developed clinician apps into the electronic medical record and connect patients to their own data, as well.

FHIR facilitation of app development has come just in time, as apps have made their entrance into health care and are here to stay. In fact, there are tens of thousands of apps related to medicine, health and wellness, per Baumel et. al. Further, in addition to the established desire for health apps, the Promoting Interoperability Program (previously named Meaningful Use Stage 3) – government regulations regarding the meaningful use of electronic medical records – dictates that eligible organizations comply with patients’ requests to have the app of their choice connected to their electronic medical record. The current deadline for this regulation is January 1, 2019, with a 90-day reporting period within the calendar year.

With the industry thirst for health apps, government regulations and the desire to be at the forefront of care, Emory is embarking on its journey to implement FHIR. Cerner, the organization’s electronic medical record (EMR) vendor, has embraced FHIR through its Cerner Ignite APIs, which will allow Emory Healthcare to turn on this API functionality to enable access to the Emory Electronic Medical Record (EeMR) Millennium database. 

SMART on FHIR

SMART on FHIR (open specification) brings both FHIR, as referenced above, and the SMART (Substitutable Medical Applications, Reusable Technologies) concept together to provide plug-and-play apps that should work regardless of the system.

FHIR (Fast Healthcare Interoperability Resources)

  • Next data standard out of HL7
  • Supports an open-source public API (application programming interface)
  • Defines the transport (HTML) and structure of the data
  • Includes data models, naming structures (e.g., Procedure, Condition) and method to exchange data (i.e., FHIR server)
  • Example: MedicationPrescription includes prescriber (FHIR Practitioner), patient (FHIR Patient) and drug (FHIR Medication)

SMART (Substitutable Medical Applications, Reusable Technologies)

  • Defines standard data profiles to which FHIR must conform – terminology (e.g., LOINC), cardinality (e.g., must have name field on Patient resource, data (e.g., numerical values on a lab result) and hierarchical structuring (e.g., blood pressure must have systolic and diastolic readings)
    • Authorization (i.e., secure access token)
    • Authentication (i.e., sign in)

To develop SMART on FHIR apps, you can use any language; however, there are a few existing libraries that are already developed, which would make it easier to get started.

See Emory's guide to SMART on FHIR APIs and Implementation Strategies for more details.

Cerner on FHIR (Ignite)

As referenced, Cerner Ignite APIs for Millennium enable applications to access Millennium (note: Developing clinician/research apps that will work in Millennium does mean immediate implementation at Emory. Please note the Implementing SMART on FHIR Apps at Emory section below). 

Cerner Ignite APIs for Millennium enables applications to access EeMR. You'll need an account in the Cerner developer portal to get started writing applications. Through this program, you obtain access to a group to join to ask questions, educational resources and access to test your app in a sandbox environment with fake patients.

There is a step-by-step tutorial that will walk you through creating an app in Cerner’s SMART on FHIR ecosystem as well as the SMART IT Sandbox.

FHIR Version 4 and Cerner

What Health Care Leaders Need to Know About the Latest HL7 FHIR Release

Emory Patient API Gateway

In February 2018, Emory launched a proof-of-concept initiative for the Emory Patient API Gateway. The scope of the proof-of-concept is to implement the API Gateway infrastructure, a FHIR endpoint on an Emory Cerner database that is replicated using Emory’s existing near real-time replication strategy, and map a number of high-value FHIR resources using a variety of sourcing strategies for subject matter expertise. Specifically, this proof-of-concept will deliver:

  1. A detailed, working design and implementation of an internet-scale API gateway with security controls that will meet Emory’s information security and compliance requirements such as HIPAA audit logging.
  2. The API gateway will proxy requests to both Cerner Ignite and to the Emory FHIR endpoint, allowing Emory to offer a common endpoint for each application and source FHIR resource requests as best suited for each application.
  3. Mappings of new FHIR resources presently unavailable from Cerner Ignite, specifically in areas of basic demographics, basic visit details, lab test results, medication orders, problem list, and diagnosis and procedure codes (to the extent the Cerner system has that data). These resources draw from tables already mapped for ETL purposes by the Clinical Data Warehouse and Emory i2b2 teams.
  4. Resource providers will be implemented for these mappings and deployed into the Emory FHIR endpoint.
  5. The new resources will be proxied by the Emory Patient API Gateway, making all of the Cerner Ignite FHIR resources and new Emory FHIR resources available to a sample application.
  6. A sample FHIR mobile application and web application will be developed using the Emory Patient API Gateway tools to demonstrate using APIs from both Cerner Ignite and the EAR FHIR endpoint from the common API gateway.


FHIR Specification Implementation and Compliance

Cerner Ignite supports the DSTU 2 Final (1.0.2) version of the FHIR protocol specification and a subset of the FHIR resources and actions. The following table was compiled from Cerner's API documentation to serve as a quick reference to which resources and actions Cerner Ignite supports. Those resources listed in green have the implemented actions indicated with an X in the table. The resource name contains a link to the Cerner API documentation for the resource. The X marks are links to the documentation for the action within the resource document.


Resource NameSearchRetrieve By IdCreateUpdate$autogen-ccd-ifOperation: docref
CarePlan XX    
Goal XX    
Observation X     
DiagnosticReport X     
Device XX    
Encounter XX    
Contract XX    
Person XX    
AllergyIntolerance XXXX  
Condition XXXX  
Procedure XX    
Binary X   X 
DocumentReference   X  X
Patient XX    
Practitioner XX    
RelatedPerson XX    
Immunization XX    
MedicationOrder X     
MedicationStatement XXXX  
MedicationAdministrationt XX



Appointment XXX   
Schedule XX    
Slot XX   

 


Implementing Apps That Use Patient Data - Both Integrated in Emory's Electronic Medical Record (EeMR) and Not Integrated

Emory applauds the innovative spirit behind the development of patient-related apps, as these apps hold much promise for improving health, fostering groundbreaking discoveries and improving the clinician workflow. However, it is also imperative that apps making use of patient data, relying on Emory data and serving as a tool for patient care be thoroughly vetted.

As such, Emory has implemented a formalized app endorsement process. The process is operationally supported by the FHIR Advisory Committee – a group of stakeholders from a variety of disciplines from within the organization that serves as the steward for Emory’s FHIR operations, strategy and governance program. At is core, the committee’s main goal is to advocate and advance the liberal and responsible access to Emory’s data to support innovation, advancements in patient care and improvements in clinician workflow.

The endorsement process provides a standardized process by which an app – either clinician or patient facing – is endorsed by Emory, ensuring organizational support for apps that are:

  • Concordant with clinical evidence or national standards
  • Connected to Emory’s tripartite mission, vision and goals
  • Evaluated as improving the clinician workflow or having a defined positive impact on patients
  • Aligned with best practices in usability and design for user technology acceptance
  • Secure and exhibiting high standards in protecting patient privacy
  • Developed with technology that has a minimal impact on system performance
  • Demonstrating over time positive contributions to patient care and substantial use to maintain endorsement

All clinician apps using patient data – be it within EeMR or as a standalone app within the Emory app store – must go through this endorsement process. For patient apps, although patients may request that apps of their choosing be connected to their data, it is strongly recommended that patients use only those apps that have been through the Emory app endorsement process, as the process includes evaluation of security and the methods behind what the app is aiming to achieve.

Emory App Endorsement Steps

The steps of the app endorsement process are below. Please email Elizabeth Sprouse at elizabeth.sprouse@emoryhealthcare.org with questions or to discuss a specific app.

  1. App developer (e.g., outside vendor, research team, student) or an Emory team member (e.g., physicians, administration, researchers) requests an app to be reviewed for endorsement. At the same time, Emory business owner should enter an IS new business request.
  2. App is entered into the endorsement process. A quick, rapid review will take place at this point.
  3. App developer must go through a validation process established by Cerner, Emory’s electronic medical record vendor, or through review by an Emory preferred vendor for design, functionality, etc.
  4. App developer must go through Emory’s Enterprise IS review process, which includes Office of Technology Transfer, Security, Legal, Branding and Architecture review.
  5. The app will be tested to ensure it works properly in the Emory environment.
  6. The app will be tested to ensure it does not negatively affect performance of Emory’s system.
  7. The Emory FHIR Advisory Committee responsible for strategic app decisions will evaluate the app against the endorsement principles outlined above.
  8. The app developer will be alerted to the status of the review with feedback.
  9. If the app is endorsed and it is relevant to do so, the app developer must complete the Apple App Store submission process.
  10. At this stage, endorsement will be documented. The Emory team will communicate the endorsed app to patients or proceed to a technical implementation phase.
  11. Apps will be reviewed regularly for continued endorsement.

Cerner coverage of FHIR Resources

Cerner supports various actions on 23 of the 93 resources defined in FHIR for a simple coverage metric of 25%. The Cerner implementation represents 8% of the specification when the total number of resources and operations are taken into account. The Cerner roadmap for adding additional resources and operations is aligned with regulatory mandates such as Meaningful Use Stage 3 and the requests of the majority of their clients, so their product roadmap is less aggressive than Emory desires. Presently only four more resources with several actions appear on the roadmap. Once implemented that would represent only 9% of FHIR specification coverage. 

Coverage Calculation Method

FHIR DTSU 2

Cerner Ignite (Future)

Percent Coverage

Number of Resources

93

27

29.03%

Number of Resources * Actions

372

33

8.87%


This section lists all the FHIR resources by category in blue. The ones listed in green are supported by Cerner. The number following the resource name is its "Maturity Level." The higher the number, the more mature the resource.

Each resource is linked to its section in the FHIR spec.


ClinicalResources: 27Supported by EeMR: 11Unsupported: 17

General:

Care Provision:

Medication & Immunization:

Diagnostics:

IdentificationResources: 13Supported by EeMR: 6Unsupported: 7

Individuals:

Groups:

Entities:

Devices:

WorkflowResources: 17Supported by EeMR: 4Unsupported: 13

Patient Management:

Scheduling:

Workflow #1:

Workflow #2:

InfrastructureResources: 16Supported by EeMR: 2Unsupported: 14

Information Tracking:

Documents & Lists:

Structure:

Exchange:

ConformanceResources: 10Supported by EeMR: 0Unsupported: 10

Terminology:

Content:

Operations Control:

Misc:

FinancialResources: 10Supported by EeMR: 0Unsupported: 10

Support:

Billing:

Payment:

Other:

Links and References

Draft EHC FHIR Presentation

All Published versions of FHIR 

Implementation Guide Registry

Baumel, A., et al., Enlight: A Comprehensive Quality and Therapeutic Potential Evaluation Tool for Mobile and Web-Based eHealth Interventions. Journal of Medical Internet Research, 2017.

Bloomfield, R.A., et al., Opening the Duke electronic health record to apps: Implementing SMART on FHIR. International Journal of Medical Informatics, 2017.

Mandel, J.C., et al., SMART on FHIR: a standards-based interoperable apps platform for electronic health records. AMIA, 2016.

Puri, H., Interoperability Update: FHIR.

A White Paper from Open Mapping Software Ltd

 



  • No labels