Convert your FHIR JSON -> XML and back here. The CDA Book is sometimes listed for Kindle here and it is also SHIPPING from Amazon! See here for Errata.

Saturday, March 5, 2016

Is that a concept domain or a value set?

One of the challenges currently being investigated for Certification under the ONC 2015 edition of certification requirements has to do with APIs and the Common Clinical Data Set.  Let's look at a simple example.

According to the rule, sex must be coded:
(n) Sex—(1) Standard. Birth sex must be coded in accordance with HL7 Version 3 Standard, Value Sets for AdministrativeGender and NullFlavor (incorporated by reference in § 170.299), attributed as follows:
(i) Male. M
(ii) Female. F
(iii) Unknown. nullFlavor UNK
However, in HL7 FHIR, sex is coded using Administrative Gender, defined as:
CodeDisplayDefinitionv2 Map (0001)v3 Map (AdministrativeGender)
maleMaleMale=M=M
femaleFemaleFemale=F=F
otherOtherOther<A
<O
<UN
unknownUnknownUnknown=U=UNK

As you can see here, there is direct, one-to-one and onto mapping from the specified value set for Meaningful Use, and the FHIR required value set.  Conceptually, they support the same concept domain.

In this case, I don't think ONC meant to preclude the use of FHIR simply because the actual values of the codes are a little different.  As the FHIR mapping table shows, the FHIR codes mean exactly the same thing.  I see two ways forward to address this problem:

  1. Subregulatory guidance to the ONC Testing bodies and certifiers that this sort of mapping, where there is a direct one-to-one and onto map provided and published in a consensus standard, should be acceptable for coding fields in the Common Clinical Data Set.
  2. Changing the FHIR Coding system to be the HL7 Version 3 coding system for Administrative Gender.
I prefer solution 1, as the FHIR coding system purposefully clarified and reduced the challenges that V3 created with Undifferentiated (UN).  Furthermore, I believe that solution to be aligned with the goals of ONC in specifying the use of an API.  The two systems support exactly the same concept domain, and the provision I highlighted ensures that this exception only works in the case where the mapping is created by an SDO in a consensus manner.  This prevents others from creating their own maps from SNOMED CT, LOINC or other specified standards that would duplicate the use of those codes.  In other words, it minimizes the impact and ensures that we can continue to use FHIR, but still be in accord1 with the standard.

-- Keith

P.S. I'll let you know how the investigation turns out.

1 Accord - To be in agreement or harmony, agree -- which these value sets do, given that they represent the same concept domain.

0 comments:

Post a Comment