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