HL7 Field Iteration and SDA3 / FHIR
I have a question around mapping between different datasets during the HL7 -> SDA3 -> FHIR transformation.
We have a FHIR server which uses the standard ISC HL7->SDA3->FHIR conversion when ingesting HL7 messages. There is the odd requirement to enrich FHIR data from the original HL7 message.. due to site specific HL7. Our approach is to extend HS.Gateway.HL7.HL7ToSDA3 with a custom GetSDA method that includes the original HL7 Message ID via CustomPairs. This makes the original HL7 message available at a later stage for enrichment.
Our enrichment occurs in DTLs for example a custom Patient DTL would subtransform HS.FHIR.DTL.SDA3.vR4.Patient.Patient and then make a number of site specific tweaks.
My question is it safe to assume that data mapped by the standard ISC transformations (HL7->SDA3->FHIR) is in the same order when dealing with repeating elements?
For example in the below DTL snippet there is an assumption that key tAddrIdx on Source.Addresses will also match the same address on the HL7 message fetched by GetAddressUse method.
DTL:
<foreach property='source.Addresses()' key='tAddrIdx' >
<if condition='tAddrIdx <= target.address.Count()' >
<true>
<!-- Fetch AddressUse from HL7 message -->
<assign value='##class(MQHealth.Transform.PatientHelper).GetAddressUse(HL7MessageId, tAddrIdx)'
property='tAddrUseCode'
action='set' />
GetAddressUse Method:
/// Get Address Use Code from PID.11.7 using the Message ID
/// and index of the address as PID.11 can repeat
ClassMethod GetAddressUse(HL7MessageId As %String, myIdx as %Integer) As %String
{
Set addrType = ""
set MsgObj = ##class(EnsLib.HL7.Message).%OpenId(HL7MessageId)
if MsgObj {
Set addrType = MsgObj.GetValueAt("PID:11(" _ myIdx _ ").7")
}
Return addrType
}Comments
The returned material shows how to customize the HL7->SDA3 step and how SDA/FHIR mappings can be inspected, but it does not state that repeating elements preserve positional order across the standard HL7->SDA3->FHIR pipeline, nor does it document that an SDA list index such as source.Addresses() is guaranteed to match the original HL7 repetition index such as PID:11(n). [1][2][3][4][5][6]
What is documented is:
- If you use
HS.Gateway.HL7.HL7ToSDA3, extending that class and adding custom handling is a supported customization approach. [1][2][3] - Custom SDA data can be carried forward using
CustomPairs, and when the target is FHIR,CustomPairsare mapped into a FHIR extension containing a Parameters resource. [4][5][6] - The FHIR Annotations tool can be used to inspect mapping details, including field-to-field mappings, cardinality, whether a mapping appends to an existing target object, and whether it uses a subtransformation or class method. [4][5]
[!IMPORTANT]
Any persistent class such as HS.Registry.Patient must be recompiled after modifications are made to HS.Local.SDA3.PatientExtension. [1][2][3]
Because the available sources do not explicitly guarantee order preservation for repeating fields in the standard HL7->SDA3->FHIR transforms, it is not safe to conclude that tAddrIdx will always correspond to the same original PID.11 repetition based on these documents alone. [1][2][3][4][5][6]
If you need to verify the exact behavior for Patient address mappings, the documented way to investigate is to review the mapping details in FHIR Annotations, where you can inspect the specific SDA-to-FHIR mapping, cardinality, and technical mapping definition for the relevant fields. [4][5]
Sources: