HL7 January 2019 Working Group Meeting, FHIR Connectathon and C-CDA IAT: A Recap (Part II)

For the week following January 12th, a delegation from the Dynamic Health IT development team was on hand in San Antonio for the HL7 Working Group Meeting and FHIR Connectathon. Our team shared technical approaches and a vision for the future of FHIR, C-CDA and our industry at large. This is Part II of our recap of the week’s events.

While the Working Group Meeting (WGM) covered the entire week’s festivities, FHIR and C-CDA got the intensive treatment over the weekend of January 12th. While FHIR had its own discussion track at the WGM, in-depth technical discussions of interoperability at the document and data levels reigned over the weekend.

As in any technological meeting of minds, some of the discussion can become obscure. But it is just this level of detail that is pushing the maturity of the standards and is proving crucial to adoption.

Among other efforts over a busy weekend, our team discussed important use cases for the standards, reviewed USCDI data elements, shared our methodology for C-CDA to FHIR (not to be confused with C-CDA on FHIR) and went deep into the details of Clinical Notes. There were also, as always, a range of tracks offered to put developers through their paces.

In Part II, we summarize few more of these important flash points.

Provenance comes of age

DHIT team in a rare moment of down time.

Provenance is “data and metadata for who and when information was/is created, for the purposes for trust, traceability and identification.” And it’s been hot topic of conversation in some recent C-CDA events and this time was no different. To show that it’s arrived (and needs to be taken seriously) it has been included in the expanded USCDI.
If document-level meta-data can be verified and included as a matter of course, it will go along way to breaking down barriers of distrust between providers and systems.

Patient Summary vs. Encounter Summary

We discussed Encounter Summary documents at length in our previous post in which we reviewed some of the Carequality/CommonWell recommendations. Whereas an encounter summary is meant to be limited to a specific episode of care, patient summary documents contain a record of care over a period of time, including multiple encounters. 

But as debated at the IAT, how do we represent a problem list – should it show a snapshot in time, a net problem list or be in some way shifted to another document type or section to avoid any confusion? Most clinicians, at any given time, want condensed data that provides direct insight to the patients’ current state of being – so what happens to the history when a document is compiled?

Meds and Labs

Shades of meaning become increasingly important as standards are defined down to the last character.  While a ‘Medication, Administered’ should indicate that a clinician confirmed that the patient took the med, medication “complete” is another story.

There was a consensus for putting all lab results in the results section, while some associated procedures may be essential dual-entered in the procedures section.

Close quarters at Connectathons, while at times chaotic, have the virtue of providing sustained and meaningful interaction. Many questions that may get overlooked during a normal workday back at each of our respective offices get answered.

If the spirit of the event is “share and share alike,” then San Antonio was another roaring success. When it comes to interoperability, the learning and collaboration never stops.

HL7 January 2019 Working Group Meeting, FHIR Connectathon and C-CDA IAT: A Recap (Part I)

Tower of the Americas, San Antonio, TX.

For the week following January 12th, a delegation from the Dynamic Health IT development team was on hand in San Antonio for the HL7 Working Group Meeting and FHIR Connectathon. Our team shared technical approaches and a vision for the future of FHIR, C-CDA and our industry at large. 

For the uninitiated, the event is an interoperability extravaganza, allowing implementers to dive deep and uncover best practices in health data sharing.  The Connectathon portion now also hosts the C-CDA Implementation-a-Thon (IAT), allowing in-depth collaboration with industry leading EHR developers.

Major policymakers, developers and stakeholders are in attendance for an ambitious look at interoperability from practical and conceptual standpoints. The free flow of information on display mirrors what interoperability itself aspires to be: open and unencumbered. Perhaps most importantly, it reminds us that our human connections are essential to our virtual ones.

FHIR: Is the future now?

The FHIR Connectathon added the C-CDA IAT track, which allowed for exploration of the connection between FHIR and C-CDA documents. We continued our active engagement in this collaboration as we hammered out the C-CDA to FHIR Mapping. A CDA to FHIR and FHIR to CDA roundtrip allows implementers who only do CDA (or who only do FHIR) to communicate with each other.

One of the greatest challenges in this effort is to decide on and maintain the conversion mechanism that translates a C-CDA document into a FHIR C-CDA document (and vice versa). C-CDAs rendered in XML do not always map neatly to FHIR resources and there are all sorts of judgment calls to be made; though it should be said: getting these two to play nicely is a key goal for HL7 policymakers and the next major release of FHIR (R5) will have more support for migrating data to and from v2.1 CDA documents.

FHIR Connectathon swag.

One conceptual hurdle, aside from mapping, is the fact that a C-CDA document tells a clinical story and is therefore more legible. FHIR’s resources are more abstract and, while highly flexible. Therefore, they’re better positioned to serve as the clearinghouse: to be “read” directly by EHRs and mobile applications. But clinicians and other human readers require the narrative quality that a discrete document format provides.

The Dynamic team shared its experience with implementing CCDA to FHIR in and our decision to emphasize the use of a document repository that creates FHIR resources on the fly. We have rolled this all the way up to a prototype mobile app for patient end-users, while our near terms goals include having Apple HealthKit talking directly to our Dynamic FHIR product.

Quality Measures – they’re everywhere

Clinical quality measures calculation from FHIR (or CCDA) remains a nascent field of inquiry. The data sources for CQMs currently in the field are overwhelmingly based on mapping measure logic to some existing relation data format used by the EHR. But as our team has shown in previous Connectathon events, CQM calculation can work hand-in-hand with FHIR.

With the advent of Clinical Quality Language (CQL) in 2019, there is further hope that this more interpretable logic will enable more interoperability in CQMs. In theory, CQL files should be easier to create, read and share across domains beyond CQM compliance (for instance, clinical decision support). And by extension, they should dovetail more easily with FHIR resources.

There is plenty of cause for optimism here, including the fact that the team beyond CQL offers a wealth of open source tooling and some emerging recommendations that CQM programs support more of the code systems under 2015 Edition.

Here is another example of the way in which clinical documents are colliding with CQMs:  The CPC+ program, which includes a subset of required CQMs, will also be requiring the output of a Care Plan document. Dynamic Health IT, along with a handful of other vendors, has previously implemented the Care Plan C-CDA in a production environment.

Connecting and collaborating.

C-CDA Scorecard rubric updates
Many EHRs have implemented some version of incoming C-CDA grading consistent with 2015 Edition. Use of the ONC-engineered Scorecard Tool is not required for certification, but some form validation similar to that made available by ONC via API is needed. The Scorecard, which provides the additional flourish of a letter grade, was ONC’s way of allowing users to check the quality of the C-CDA from a sending system and provide a channel for accountability.

However, there has been some pushback by EHRs that the analysis provided by the tool is too blunt and users of the tool are getting caught up in the grade, as opposed to what the grade represent (not unlike college). EMR vendors seem to prefer a Progress Bar allowing the end-user to understand where progress can be made to improve the provided data. 

ONC has some enhancements coming to provide more meaningful feedback to implementers by indicating the number of tests graded and number of tests passed, while indicating the number of unique issues.

There has also been a request from EHR vendors for more clarity in error messaging, which may be addressed in part by further education.

Stay tuned for our next post for more information on some of the lead-edge discussions around interoperability standards.