 |
| HL7.org |
After the Orlando meetup, we were looking to take a deeper dive into the standard and share what we had been working on since January.
One of HL7's stated goals for the event was to "identify issues and potential trouble spots" in the CCDA. While some of us in the room are nominally competitors, we are all united around the common goal of making CCDA use and implementation as easy as possible, resolving ambiguities in the standard and working toward greater interoperability. EHR firms such as Epic and NextGen and a range of other developers, users and experts were all in the room, working toward this shared goal.
The collaborative spirit was encouraging, though some of the major industry players have been missing. This can make it difficult to coalesce around a decision on how to overcome major roadblocks to interoperability.
As is often the case at Connect-a-thons and other healthcare IT meetups, there were plenty of new faces, an indication of the growth in interest and a reminder that the standard requires ongoing outreach and education.
Here's a quick and dirty rundown of some key topics covered, followed by a few of our observations on specific discussion areas:
- Implantable devices
- Gender identity: administrative gender and birth gender
- "Assessment and Plan" vs. "Assessment" and "Plan of Care"
- Approaches to "no known" value (allergies, medications, problems, etc.)
- Discharge Medications (v1.1 vs. v2.1)
- Care Plan: when to send, defining sections
- ONC C-CDA test data review and import
- Human readable vs. machine readable format and its effect on interoperability
- Medications: approaches to recording a "tapered dose"
Implantable devices
 |
| PHOTO: Boston Scientific |
Does it go into "Procedures,""Medical Equipment" or some combination of the two?
For ONC Certification, it is expected to be in "Procedures" section, unless there is no implantable info, then it lives in the"Medical Equipment" section. At the Implementation-a-thon, HL7 further clarified that the implantable device information should always appear in the Medical Equipment section. When the specific procedure for the implant is known, it should also go into Procedures.
Gender identity
There is not yet an agreed-upon standard in healthcare data for distinguishing the sex of the patient as determined at birth from other notions of gender identification.
HL7 currently uses the concept of administrative gender, defined as "the gender of a person used for administrative purposes." FHIR, which built upon RIM, can incorporate XML resources to capture gender identity, but the best practice has not been decided.
In the case of a transgender male - whose birth sex was assigned female and whose current gender identification is male - SNOMED codes are capable of capturing this distinction. Common practice in C-CDA would most likely record the Administrative gender for this patient as female.
As HL7 explains in its current detailed descriptions:
(G)ender may not match the biological sex as determined by genetics, or the individual's preferred identification... Systems providing decision support or enforcing business rules should ideally do this on the basis of Observations dealing with the specific gender aspect of interest (anatomical, chromosonal, social, etc.) However, because these observations are infrequently recorded, defaulting to the administrative gender is common practice.That last sentence gets at the fact that even the underlying process for recording gender identity and sex assignment is in need of clarity. There is no single approach, for instance, to mapping gender as recorded on an intake form with relevant C-CDA sections.
The Implementation-a-thon also explored the example of administrative gender as represented in 'UNK' nullFlavor, paired with an observation recorded in Social History. The general guidance from HL7 is that gender identity concepts should appear in"Social History,"while the "pending guidance" on birth sex is as follows:
C-CDA recordtarget/Administrative Gender is the field used to record the Birth Sex and must be coded as follows: M (male), F (female) or a nullFlavor of 'UNK'.However, there will be further clarification coming from ONC and report back to the group.
Future considerations on this subject:
- Some Clinical Quality Measures require a reliable location for patient birth sex.
- Similarly, certain genetic predispositions and Clinical Decision Support in general also require birth sex, but not at the expense of multiple conceptions of gender identity.
- Which concept of sex or gender identity should be used in patient matching across data sets?
The discussion centering around this issue further underscored the need for all major players to take part in the shaping of the standard in order to avoid confusion and incoherence.
Lessons Learned
HL7 events never fail to be highly educational. Among the takeaways for us:
- As the C-CDA standard becomes increasingly flexible and interoperable, wide participation in dialogue and educational outreach are esssential
- Recording of gender identity and sex will likely be unresolved until an industry-wide consensus can be achieved across major providers, EHR developers, payers and policymakers
- As the standard and certification testing evolve, development practices must follow suit. The new testing tool is a great help in this process.
- Translation codes for alternate value sets should be used whenever possible, rather than rejecting a C-CDA outright.
- More focus is needed on reconciling discrete values in machine readable with the text description in the human readable portion.
