Blog

CDHI Goes to FHIR Dev Days 2019: What’s New With FHIR, the Healthcare Data Interoperability Standard that Enables Digital Health

Share:

Ed Martin, Sondra Renley & Fel Bautista

 

A few of the CDHI Technology Team members attended FHIR Dev Days 2019, held at the Microsoft Campus in Redmond, WA, on June 11-13  to learn about the latest developments around the FHIR standards. FHIR usage has gained serious momentum, as evidenced by the attendance at this conference.  There were 600+ attendees, including electronic health record (EHR) vendors Epic and Cerner, as well as major technology companies Google, Apple, and Microsoft, who have only recently started participating in just the last few years.  That’s significant growth from the first Dev Days conference  held in Amsterdam in 2013 when there were fewer than 30 attendees.  While FHIR was in its infancy and considered a novelty in 2012, it was recently been ratified as an ANSI (US national) standard in December 2018, and it has been baked into healthcare policy by the ONC with the 21st Century Cures Act. 

 

FHIR Evolution

The current ratified standard is a good start, but it is incomplete.  The good news is that CDHI and others in the health technology community actively collaborate to improve FHIR.  As was highlighted at FHIR Dev Days, there are two categories of improvements:  evolution of the FHIR standard and new adjunct standards dependent on FHIR.

 

Only 13 FHIR resources have been designated as “normative” as part of the official standard, aka version release 4 or R4.  According to Grahame Grieve, FHIR’s Project Director and one of its creators, “normative” means no future releases will break your app if it conforms to the standard.  130 other FHIR resources are in varying states of maturity and will be incorporated into (or culled from) subsequent standard releases.  The next release of the standard, R5, tentatively set for October 2020, should include many more normative resources.  From the CDHI perspective, we continue to advocate making progress around patient access related FHIR resources (scheduling, appointments, and referrals) and care planning.

 

Another interesting evolution is the emergence of adjunct standards that utilize the FHIR standard.  In the last couple of years, examples of these adjunct standards include SMART-on-FHIR, a way of securely launching contextual apps from the EHR or the Patient portal, and CDS Hooks, an external clinical decision support algorithm integrated into the EHR workflow (Note that SMART-on-FHIR has been be implemented by the major EHR vendors, and CDS Hooks is coming soon).  As CDHI has learned implementing SMART-on-FHIR apps, there are areas where we’d like to see improvements, especially around workflow improvements, usability, and app performance.  These new adjunct standards will enable building better apps for providers and patients.

 

The Argonaut Project, a HL7 project that addresses ONC JASON task force recommendations, continues to improve FHIR by expanding specifications to enable expanded information sharing for electronic health records, documents, and other health information based on the FHIR specification.  Three of the four latest Argonaut projects seek to improve EHR to SMART-on-FHIR application communications: SMART Web messaging, FHIRCast, and the Subscription resource.  The fourth Argonaut project is Provenance Guidance, which is to provide consistent implementation of provenance of FHIR resources.

 

SMART Web Messaging

SMART Web Messaging aims to provide clinicians with apps that have a better user experience through a better UI with faster EHR query responses.  SMART Web Messaging uses HTML5’s Web Messaging framework to allow a web app from one domain to send data from another web app on a different domain, for example, launching a SMART-on-FHIR or CDS Hooks app from the Epic Hyperspace UI (which is technically a web app under the covers).  The data is exchanged via the browser, so communication is faster and more secure, since data doesn’t go over the open Internet.

 

Examples from their website give some key use cases that SMART and CDS Hooks don't address today:

  • Communicate a decision made by the clinician within the SMART app, such as placing an order, annotating a procedure with an appropriateness score or radiation count, transmitting a textual note snippet, or suggesting a diagnosis or condition to the patient’s chart.

  • Interrogate the orders scratchpad / shopping cart, currently only known within the ordering provider's CPOE session.

  • Allow an app to communicate UX-relevant results back to the EHR, for example, navigate to a native EHR activity, or an "I'm done signal".

 

FHIRCast

FHIRCast enables patient safety by ensuring physicians are looking at the correct patient data if multiple apps/displays are open, preventing mistakes from reading the wrong information.  FHIRCast provides a new means of synchronizing EHR context between itself and one or more SMART-on-FHIR apps in real time.  One example is provided by the FHIRCast website:  a radiologist often works in three disparate applications at the same time (a radiology information system, a PACS, and a dictation system), she wants each of these three systems to display the same study or patient at the same time.

 

FHIRcast builds on the prior HL7 Clinical Context Object Workflow (CCOW) model, but it uses lighter weight http and simple context synchronization that doesn't require a separate context manager.  It utilizes a simple publication-subscriber, requiring apps to subscribe to notifications about context changes in the EHR.

 

While CCOW technically worked, it didn’t have much adoption from the HIT vendor community, as it required an additional server running the context manager.  With FHIRCast, the goal is to create a simpler standard that all EHR vendors will adopt, and that SMART-on-FHIR app developers can easily utilize.

 

Subscription

Subscriptions simplify the way FHIR based apps can be notified when there are changes to data, for example, when a patient has been admitted, discharged, or transferred, or if a new medication has been prescribed.  The Subscription resource is used to define a push-based subscription from a server to another system.  Once a subscription is registered with the server, the server checks every resource that is created or updated, and if the resource matches the given criteria, it sends a message on the defined "channel" so that another system can take an appropriate action. 

 

The Subscription resource continues to be refined with lessons learned from the Connectathons.  It differs from FHIRcast as it is an asynchronous implementation.  The Argonaut goal in 2019 is to create an “Encounter Subscription Implementation Guide” that enables an authorized SMART-on-FHIR application to register a long-term data subscription based on a specific patient id and/or based on a specific practitioner id.

 

Provenance Guidance

While FHIR establishes the standards for exchanging healthcare data resources, how do you know if you can trust the data and its origin?  Provenance of a resource is a record that describes entities and processes involved in producing and delivering or otherwise influencing that resource. Provenance provides a critical foundation for assessing authenticity, enabling trust, and allowing reproducibility.  Provenance assertions are a form of contextual metadata and can themselves become important records with their own provenance.  Provenance statements indicate clinical significance in terms of confidence in authenticity, reliability, and trustworthiness, integrity, and stage in lifecycle (e.g. Document Completion - has the artifact been legally authenticated), all of which may impact security, privacy, and trust policies.  We believe that Provenance will be critical to shared care planning, as the sources of the care plan information must be fully trusted.   

 

Helping to Advance FHIR

Several speakers attributed the growth of FHIR to the community involvement and actively solicited participation.  Steve Posnack, the Executive Director for Technology at the ONC and one of the keynote speakers, stated that advancement and adoption of the standards required the collaboration of policy makers (the ONC), standards developers (HL7), and HIT Implementers (developers). 

 

At CDHI we’ve been active in FHIR community and have been actively promoting its adoption, evolution, and advancement over the last 5 years.  We have participated in several HL7 Connectathons, programming events where we’ve tested our code against others’ FHIR server implementations of the latest proposed standards, provide feedback on what does or doesn’t work, and make suggestions for improvement.  Most visibly, we’ve been commenting on the ONC’s Notices of Proposed Rule Making (NPRM).  We have also been actively engaging our internal UCSF app implementer community through the Digital Diagnostics and Therapeutics (DD&T) Committee, which helps developers access FHIR API’s in our EHR sandbox for building new digital health tools.  Over the past one and half years, we have launched 8 apps live in production.  UCSF’s recent successes utilizing FHIR APIs include Careweb, a modern care collaboration tool, and the UCSF Weill Institute’s Bridge app, a precision medicine dashboard that allows clinicians to provide the latest research data to allow patients to make better care decisions.

 

FHIR Adoption Must Accelerate

Two of the keynote speakers, Peter Lee / VP Healthcare, Microsoft, and Greg Simon / President, Biden Cancer Initiative, urged the audience to accelerate FHIR adoption to improve healthcare.  While FHIR usage is growing and becoming a universal standard for health data, it still has a long way to go to support the myriad of use cases in healthcare.  Greg Simon, in particular, pleaded the HIT community to move faster, as people are literally dying while health data interoperability standards are deliberated.  From CDHI’s perspective, we couldn’t agree more, and we continue to work to advance improvements in the FHIR standards.

 

Patient safety should always be at the forefront of what we do as HIT implementers, not as an afterthought and certainly never a corner that’s cut.  Graham Grieve urged everyone at FHIR DevDays to read and understand the FHIR Safety Checklist.  The checklist emphasizes clinical safety when implementing FHIR technologies.  Please review the checklist before, during, and after any FHIR implementation you’re working with.

 

 

 

Ed Martin, Director of Technology

Sondra Renly, Solutions Architect

Fel Bautista, Principal Engineer