Enhancement: Generalized "code" capture with translations

[ewhitley]

Hello -

I'm submitting this as an advanced "I'd like to work on this" enhancement so I can get feedback on whether it's worthwhile.

I'm seeing repeated capture of code/codeSystem elements ala:

// performer
el = entry.tag('performer').tag('code');
var performer_name = el.attr('displayName'),
    performer_code = el.attr('code'),
    performer_code_system = el.attr('codeSystem'),
    performer_code_system_name = el.attr('codeSystemName');

In some places translations are applied. In others, not.

I'd like to introduce a generalized getCodedEntry(el) method that would uniformly return the following:

• name : (String) displayName (or the appropriate embedded text or originalText if displayName is missing)
• code : (String) code
• code_system : (String) codeSystem OID
• code_system_name : (String) codeSystemName
• code_system_version : (String) codeSystemVersion
• null_flavor : (String) nullFlavor (I've seen this a lot in systems without vocabulary mappings). Case in point <code codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC" nullFlavor="UNK"> Even if code is left null, I don't see any harm in being explicit about why and adding nullFlavor
• translations : (Array) List of all child translation coded entries. This would be present in all results.

From there it would be used like...

el = entry.tag('performer').tag('code');
var performer = getCodedEntry(el)

and magically handle obtaining all code data and any/all nested translation values in a single data gathering function.

I'm also suggesting to take it one step further. In the data capture process, I'd like to have a reference set for all vocabulary OIDs. With a given OID, we could...

• Emit a vocabulary code system name for any not provided in the code (if they're missing). EX: OID 2.16.840.1.113883.6.96 is found with a null (absent) codeSystemName - we would resolve the codeSystemName to SNOMED CT
• Optionally, uniformly replace all code system names with a uniform string bb.js provides. EX: We find OID 2.16.840.1.113883.6.96 with one of a given set of codeSystemName variants - "SNOMED-CT" vs. "SNOMED" vs. "SNOMED CT". We would elect to uniformly replace that with the bb.js preferred SNOMED CT.

I think this would help simplify code and present a uniform way to also handle translation capture - and all with zero impact to the existing response body.

Anyhoo - I'd like to get cracking on that :)

[ewhitley]

OK, this is now working and I'm adjusting templates.

• Consolidates code gathering into one function
• Returns an object that contains all of the prior stuff as well as nullFlavor
• Includes translations
• If codeSysemName is missing, does a lookup (by OID) to try to find a valid one

Original call to get data:

    // value => reaction_type
    el = entry.template('2.16.840.1.113883.10.20.22.4.7').tag('value');
    var reaction_type_name = el.attr('displayName'),
        reaction_type_code = el.attr('code'),
        reaction_type_code_system = el.attr('codeSystem'),
        reaction_type_code_system_name = el.attr('codeSystemName');

Revised call to get data:

    // value => reaction_type
    el = entry.template('2.16.840.1.113883.10.20.22.4.7').tag('value');
    var reaction_type_code_data = codedEntry(el);

• Leaving in existing coded data references to avoid breaking compatibility. Existing coded entry information that's represented at the root level is left intact - I'm just sourcing it from the new "get me coded entry information" model.

EX: for an allergy entry

    {
        "name": null,
        "code": "ASSERTION",
        "code_system": "2.16.840.1.113883.5.4",
        "code_system_name": "HL7 Act Code",
        ...
    }

• Then I'm injecting the full codes entry into the json, which will include translations, etc.

    "codes": {
        "name": null,
        "code": "ASSERTION",
        "code_system": "2.16.840.1.113883.5.4",
        "code_system_name": "HL7 Act Code",
        "null_flavor": null,
        "translations": []
    }

• For any translations that do appear, they're simply nested coded entries

    "codes": {
         "name": "A Concept",
         "code": "12345",
         "code_system": "1.1.1.1.1.1.1.1.1",
         "code_system_name": "Bogus Code System",
         "null_flavor": null,
         "translations": [
              {
                  "name": "A Similar Concept",
                  "code": "abcde",
                  "code_system": "2.2.2.2.2.2.2",
                  "code_system_name": "Bogus Code System 2",
                  "null_flavor": null
              },
              {
                  "name": "One More Related Concept",
                  "code": "zyxw",
                  "code_system": "3.3.3.3.3.3.3",
                  "code_system_name": "Bogus Code System 3",
                  "null_flavor": null
              }
         ]
    }

[djlawler]

As someone struggling to convert CCDA information into formats that are easier to use for data conversion, this would be an extremely useful enhancement. Are your changes available anywhere?