New post
Question
· Apr 5, 2022

Storing LOINC Code for the Clinical Note in the Document SDA and Document Streamlet

#Data Import and Export #FHIR #HL7 #Interoperability #HealthShare

Hello,

I am working on the new USCDI Requirement to store LOINC Codes/Descriptions for various types of Clinical Notes in the SDA.

According to all of the documentation I had been able to find, in order to store a coded value for Document Type, I have to use Custom Pairs:

#; Code System
        do ..write(cr_"<CustomPairs")
        do ..write(cr_"<NVPair>")
        do ..write(cr_"<Name>DocumentNameCodingStandard</Name>")
        do ..write(cr_"<Value>LN</Value>")
        do ..write(cr_"</NVPair>")
        #; Code
        do ..write(cr_"<NVPair>")
        do ..write(cr_"<Name>DocumentNameCode</Name>")
        do ..write(cr_"<Value>"_LOINC_Code_"</Value>")
        do ..write(cr_"</NVPair>")
        #; Description
        do ..write(cr_"<NVPair>")
        do ..write(cr_"<Name>DocumentNameDescription</Name>")
        do ..write(cr_"<Value>"_LOINC_Descriptions_"</Value>")
        do ..write(cr_"</NVPair>")
        do ..write(cr_"</CustomPairs")

However, given that the client is also building a database of FHIR Resource, I am thinking to also store Document LOINC Code/Description in the DocumentType.Code and DocumentType.Description in order to make it translatable to FHIR Resource DocumentReference:type. This way, the Custom Pairs will get stored in the Streamlet Database and also will be stored in <DocumentType><Code>LOINC_Code</Code><Description>LOINC_Description</Description></DocumentType> for future conversion to a FHIR Resource.

I would welcome any suggestions and/or thoughts.
 

Product version: HealthShare 2019.2
Discussion (3)1
Log in or sign up to continue
Vitaly Furman · Apr 5, 2022

Thank you Marc for your prompt response.

The only thing that led me to the Custom Pairs trail is this code in HS.Gateway.HL7.HL7ToSDA3:

#; TXA-2 : DocumentType
    #; For "DS", default Description to "DischargeSummary" (JLD190)
    if $$$TXADocumentType = "DS" {
        do ..write(cr_"<DocumentType>")
        do ..write(cr_"<Code>DS</Code>")
        do ..write(cr_"<Description>DischargeSummary</Description>")
        do ..write(cr_"</DocumentType>")
    }
    elseif $$$TXADocumentType'="" {
        do ..write(cr_"<DocumentType>")
        do ..write(cr_"<Code>"_$$$TXADocumentType_"</Code>")
        do ..write(cr_"</DocumentType>")
    }

However, since that class had already been extended, I can add 

 do ..write(cr_"<Description>"_$$$TXADocumentDescription_"</Description>")

and it will get stored in the SDA.

The one exception might be Discharge Summaries since the Clinical Viewer seems to expect "DS" in the DocumentType.Code property. Unless there is a way to modify that behavior, I may have to use CustomPairs just for that case and then alter the SDA3 to FHIR transform when it is time to store in a FHIR Resourse

0 0
Craig Regester · Apr 6, 2022

I may be misunderstanding your complete use-case but we are also doing something similar for 21st Century Cures and the easiest way to handle this, that I identified anyway, is through dynamic terminology mapping.

So DS can go in for the DocumentType.Code per usual but if you look at the FHIR Annotations/Mappings, you'll note DocumentType is a CodeTableDetail item - HS.SDA3.CodeTableDetail.DocumentType - so you can setup a simple CodeTable to map from DS to the appropriate LOINC without needing to mess with extensions and custom pairs. Just ensure you have an appropriate Translation Profile setup for your access gateway that serves out FHIR (ODS likely) so that it picks up the map to get from your HL7v2 DocumentType code table to LOINC.

EDIT to add - thus far, I have not once had to modify a built in transform to support US CDI Requirements. I suspect with the UCR release coming out in the next month or two, most of the US CDI v2/v3 mappings will also be handled better with standard CodeTable/Terminology Maps filling in any gaps.

0 0