FHIR works: Notes from Baltimore Plenary Meeting and Virginia CCDA 2.1 Implementationathon

We say this every time we attend a meetup, but it remains true: interest in HL7 interoperability standards continues to grow remarkably. As FHIR in particular matures, we see proliferation of attendees, ballot comments and general buzz. As Graham Grieve mentioned over on the FHIR Directors Blog, the most recent meetup was most likely HL7's largest meeting to date.

Baltimore at night.

Members of the DHIT team traversed the DMV (that's DC-Maryland-Virginia, in Beltway-speak) last month, heading to Baltimore for the annual plenary meeting and Arlington, VA, for the C-CDA Implementation-A-Thon.

News on FHIR
As the FHIR Chief himself, Grahame Grieve, mentions over at his blog, there were some major headlines at the very well-attended FHIR plenary event:

• FHIR release 3 is slated for release at the end of this year.
• New communities are cropping up, including from medical disciplines that hadn't previously shown up on the FHIR scene
• The FHIR Foundation will continue to be a key player, supporting the "implementation process of standard"
• The site fhir.registry.org will go live soon
• Discussion of whether to support logical reference; in short, a "URL-based view of the world," as Grahame puts it, may be incomplete.

As Grahame also mentioned, the "most significant single decision" made at the plenary was to take the specification known previously as “DAF-core” and rename it the US Realm Implementation guide. That may sound like inside baseball, but it's another symbolic leap in the maturity of the standard.

From the DHIT standpoint, we are well underway developing features in our flagship interoperability application, ConnectEHR, and across our product line to support EMR clients, including the development of testing and production FHIR servers. Our overriding goal is for our clients to move forward in interoperability as they meet the latest edition of ONC Certification Standards (2015 Edition).

We anticipate that FHIR may one day become an explicitly mandated standard and, as it stands, is a boon not only to interoperability but meeting meaningful use in Stage 3 and beyond.

We participated in the "CCDA on FHIR" track as document creator as well as document consumer, testing our implementation against multiple servers (including those of other participants as well as the reference servers from Grahame Grieve and Furore). Our coding was done in C# using the fhir-net-api provided by fellow FHIR Chief Ewout Kramer.

CCDAs in VA
HL7 hosted its third C-CDA Implementation-A-Thon last week in Arlington, VA. The DHIT team kept up its perfect attendance, convening with other CCDA developers and experts just outside DC.

In addition to the usual networking and educational opportunities afforded at HL7 Events, it's always interesting to chart the development progress of the industry as a whole. And the "real-world" scenarios provided at the event - creating and exchanging live data - are worth the trip alone.

As is typical of healthcare standards-based Connectathons, clinical scenarios are laid out for participants to navigate. In this case, the exercises were related to the exchange of v2.1 documents, discharge summaries and electronic referrals. We're proud to report that we all the CCDA Homework Scenarios were accomplished. 'A+' goes to the DHIT developers on hand.

Valueset OIDs
Valueset OIDs continue to be a point of some controversy. There was a presentation at the event providing background and information on the process of creating them. For the initiated, value sets for use in EMRs, CQMs, research and other contexts are created by professionals and organizations and submitted to be approved by the National Library of Medicine (NLM), under its Unified Medical Language System (UMLS) arm. The code sets are validated and checked for duplicates. However, our development has uncovered some of the codes may be subject to duplication and we've requested some further information from NLM.

Lessons learned

We left with some takeaways on the process of generating a v2.1 CCDA and we wanted to share with our audience:

• Often overlooked, developers should pay a little bit more attention to mood codes and their usage even though it may complicate the data that is requested from a client
• C-CDA Scorecard is a very useful checkpoint in development
• Having lower score in the scorecard doesn’t mean that the CCDA will fail the validation. Higher scores will determine that the CCDA is much closer to the expected standard
• Display name should come from the code system otherwise it will lower the score. 
• Narrative Text for all sections and textual clinical notes
• The task of categorizing results may tolerate multiple pathways. Example: CT scans go to Procedures or Results or both
• Allergies and problems should always have time recorded
• For effectiveTime of immunizations, do not use low+high when moodCode=EVN