Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.

Table of Contents


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, 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 Meaningful Use Stage 3 is January 1, 2019.

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 (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.

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  
Appointment XXX   
Schedule XX    
Slot XX   


Implementing SMART on FHIR Apps at Emory

Developing SMART on FHIR Apps for General Use (not integrating with EeMR)

[Describe development process, resources, sandbox strategies, Emory app review and distribution processes, etc. with links. We have all of this from the app process documentation.]

Integrating SMART on FHIR Apps With EeMR

[Describe additional EHC processes with links. This is material we need from Elizabeth Sprouse, Dr. Hollberg, and Rhoda Dozier. These are the additional steps to the app process that are required for apps that will integration with Emory's EMR.]

Cerner coverage of FHIR Resources

Cerner supports various actions on 22 of the 93 resources defined in FHIR for a simple coverage metric of 24%. 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


Cerner Ignite (Future)

Percent Coverage

Number of Resources




Number of Resources * Actions




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: 10Unsupported: 17


Care Provision:

Medication & Immunization:


IdentificationResources: 13Supported by EeMR: 6Unsupported: 7





WorkflowResources: 17Supported by EeMR: 4Unsupported: 13

Patient Management:


Workflow #1:

Workflow #2:

InfrastructureResources: 16Supported by EeMR: 2Unsupported: 14

Information Tracking:

Documents & Lists:



ConformanceResources: 10Supported by EeMR: 0Unsupported: 10



Operations Control:


FinancialResources: 10Supported by EeMR: 0Unsupported: 10





Links and References

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


View file