Question: Removing hard-coded OIDs in entry population functions

[ewhitley]

Hello -

I'm reviewing BlueButton.js and trying to use it to load a wide variety of CDA document types and versions I've seen. As I'm doing so, I'm reviewing the way the javascript incorporates fixed template ID references.

EX: AllergyObservation

• In the C32 parser, it's 2.16.840.1.113883.3.88.11.83.6
• In the CCDA parser, it's 2.16.840.1.113883.10.20.22.4.7

In the code for the CCDA entry parser, the ID reference is fixed ala...

el = entry.template('2.16.840.1.113883.10.20.22.4.7').tag('value');

In another project I've worked on,this has become problematic to maintain (for me, at least) as the various Template IDs are versioned (R1, R2, etc.). I'm wondering what people think about removing the fixed IDs and moving them to some sort of lookup functionality.

Example idea:

var CDA_ENTRY_MAP = {
  'AllergyObservation': [
      '2.16.840.1.113883.10.20.22.4.7',  //CCDA
      '2.16.840.1.113883.3.88.11.83.6'   //C32
  ]
};

As I've tinkered with the javascript on my own personal version, I've done this (just kicking the tires) and then also changed the related entry.template() function to allow either a single string or an array of values (so you can just say "go forth and find me stuff"). It's helped me, as I've just had to go through and manage a single reference to the IDs vs. the fixed versions in the code.

Thoughts? Good idea? Bad idea?

[sankarravi]

Yeah, if it's true that even with CCDAs, the various revisions have different template IDs, I think a strategy like this would make lots of sense. If you can make a pull request around the work there and it passes the tests, seems like that would be a straightforward thing to merge in!

[ewhitley]

Cool. Working on it now.

[ewhitley]

OK - here's what I'm finishing up. Going to take me a bit to work through the test cases. I'm going to have to modify the ccda ejs emitter as well as the expected XML and json to incorporate the inclusion of translation codes.

Here's what will show up in the pull request when all test cases validate:

• Hard-coded document, section, and entry OIDs moved to lookups (refer to oids.xml)

  These exist for:

  • Document types (Core.OIDs.document)
  • Section types (Core.OIDs.section)
  • Entry element types (Core.OIDs.entries)

• Template retrieval functionality changed to allow arrays of OIDS (in addition to existing single OID string)

    el = entry.template(Core.OIDs.entries('allergy')).tag('code');
  

• Hard-coded OIDs removed from document, section, and entry functions - replaced with alias-based OID lookup.

• Increased number of document, section, and entry templates supported to account for broader versions and "real world" mis-use of CDA templates (from private examples from multiple institutions). EX: For a document, detailed template ID supplied, but no general realm header is found.

• Patient demographics name now captures suffix (Documents.parseName)

• nullFlavor code reference now included in Core.Codes.nullFlavor (EX: 'PINF' : 'Positive Infinity')

• OIDs now exposed for common vocabulary systems in Core.OIDs. Forward lookup codeSystemForOID and reverse lookup OIDForCodeSystem.

• Generalized functions for code capture with nested translation support (Documents.codedEntry). Also attempts to resolve any missing / not supplied codeSystemName from embedded codeSystem using codeSystemForOID.

• New ejs tag helper tagHelpers.codeTag for uniform display of all code entries (EX: value, code, etc.)

  Parameters:

  • tag: The HTML tag you would like to emit. EX: code or value
  • data: The structured entry for the coded data. Passes all coded data to the existing hl7Code filter. If any translation_codes entries exist, they will be emitted via the hl7Code filter as well.
  • extra_tag_content: Additional tag content like xsi:type="CD"
  • original_text: Content that will appear within the originalText element

  Tag entry...

    <%-: tagHelpers.codeTag('value', bb.allergies[i].reaction_type, 'xsi:type="CD"', null) %>
  

  Would display...

    <value xsi:type="CD" displayName="Food allergy (disorder)" code="414285001" codeSystem="2.16.840.1.113883.6.96" codeSystemName="SNOMED-CT"/>
  

  Tag entry...

    <%-: tagHelpers.codeTag('value', bb.allergies[i].reaction_type, null, 'This food allergy has more text') %>
  

  Would display...

    <value displayName="Food allergy (disorder)" code="414285001" codeSystem="2.16.840.1.113883.6.96" codeSystemName="SNOMED-CT">
      <originalText>This food allergy has more text</originalText>
    </value>
  

  If translations are present, they will be automatically emitted as child entries.

      <value xsi:type="CD" displayName="Food allergy (disorder)" code="414285001" codeSystem="2.16.840.1.113883.6.96" codeSystemName="SNOMED-CT">
        <translation displayName="My First Translation" code="12345" codeSystem="2.16.840.1.113883.6.96" codeSystemName="SNOMED-CT"/> 
        <translation displayName="My Second Translation" code="98765" codeSystem="2.16.840.1.113883.6.96" codeSystemName="SNOMED-CT"/>
      </value>