 |
| Baltimore Inner Harbor |
The backdrop of the harbor served as a visual metaphor for the navigation required of implementers. As in global shipping, we move valuable product (in our case, data) around the world and the care for each aspect – packaging, chain of custody, containers – requires thoughtful attention to detail (as you’ll see below, especially the containers).
The Dynamic Health IT team focused efforts on two subject-based tracks: Clinical Reasoning, which centered around CQMs; and FHIR Documents, which involved creating and consuming FHIR-specific documents to a server.
The Documents Track
For the FHIR Documents Track, participants tackled both creation and consumption of FHIR documents, with the primary goal of sending a composition. In FHIR, a composition is meant to “provide a single coherent statement of meaning” as well as provide a clear identification attribution for the document. While it may seem obscure, getting this right is essential to transparency and trust on which true interoperability depends.
On the creation side, we were tasked with assembling a FHIR document – defined as a “bundle containing a Composition and supporting resources” and submitting that document to a FHIR server. There were a number of approaches to document creation. From the beginning, ours has been to use C-CDA R2.1 XML as the basis and create FHIR resources accordingly. This is the transformation on which our Dynamic FHIR API is based. This foundation enables us to support the use of familiar conventions and data types in CDA r2.1, while introducing clients to the FHIR standard and providing a method for fully meeting the 2015 ONC Certification API requirement.
Another point of discussion in document creation was the need to use the “contains” operator to create the Composition. In FHIR, ‘contains’ has a very specific use case and most agreed that it is not meant for creating a composition. The main takeaway here is that by wrapping a composition in a ‘contains,’ the data is rendered non-interoperable.
The consumer side of the Documents track presented fewer hurdles conceptually. The goal was to retrieve a FHIR document from a reference server and prove its validity. One way to do this was to use an XSL stylesheet to display the human readable version of the document retrieved. The DHIT team’s preparation in mapping FHIR to CDA R2.1 in the forward direction paid dividends here.
Clinical Reasoning Track
The clinical reasoning track dealt was a intersection of DHIT’s core competencies in quality measures and interoperability. Participants set out to integrate FHIR with clinical quality measures, focusing on the CMS-based electronic CQMs. DHIT specifically focused on testing against the latest versions of CMS 124, 125, and 130.
Our team’s preparation going into the Connectathon was an essential prerequisite for success. In the lead up to the event, this meant taking FHIR-based CQM data and converting to Quality Data Model (QDM) format to enable calculation. This is certainly not the only approach our team will be adopting as FHIR-based CQMs evolve. But as long as the Quality Data Model remains relevant, it provides a direct link between the measure logic and the underlying FHIR data.
This intermediary requires that QDM-based concepts such as ‘Encounter, Performed’ (which do not exist in FHIR) need to be converted to FHIR-standardized data. Our approach has been to convert the data coming in:
FHIR server with FHIR data --> CQMsolution data format --> QRDA-I/QRDA-III/FHIR MeasureReport
Data can be gathered from FHIR and filtered by hospital, clinic, clinician, etc, for calculation by CQMsolution’s engine.
FHIR’s proposed Bulk Data extraction method, for use with large datasets, has great potential to expand quality measure interoperability. When interacting with FHIR servers that do not perform calculation, our CQMsolution application would make use of this standardized bulk transfer method on a specified group of patients as dictated by the client and receive a ready status when the bulk export is available for calculation and analysis.
During the Connectathon, we performed calculation and manual analysis to compare our results to the reference server, comparing against synthetic FHIR-based patients there. The exercises were largely focused on proof of concept and tracking data from point-to-point. The next steps in FHIR CQMs will likely involve more validation of calculations and to start looking at more exotic data types, such as negated elements or embedded events.
Our team is eager to identify use cases for data required by Quality Measures across the spectrum.
Looking ahead
With another Connectathon come and gone, there’s still plenty to unpack. We’re looking ahead to wider adoption of DSTU4 and to the emergence of bulk data processing, while devoting current efforts to resolving the very real challenges facing the community at present. As consensus builds, implementers will be able to make fewer compromises between maintaining interoperability and steering toward the standard.
Keep in touch and check out our website for more information where we’re going with FHIR.
No comments:
Post a Comment