Not all the Value getting mapped properly in Hlv2 to fhir converter
manaschandanroy opened this issue · comments
- have built a small JAVA poc by using the maven dependency for Hl7v2 to fhir 1.0.14 and hapi 5.6.21.
I tried to convert below mentioned hl7 message . Now the problem I see is that for PID you guys have done the mapping in Patient.yml (how is it getting utilized still not sure) . But for this case PID 3 i.e. Patient Identifier list is 155919 but in converter FHIR JSON this values comes as
system": "urn:id:HEALTHY_TIMES_HOSPITAL",
"value": "155919
Is this behaving the right way. Attached below Hl7 message and FHIR JSON
Hl7&FHIR.zip
2.) Additionally whatever event trigger & segments are mentioned has anybody tested for all of them. If yes can you share the hl7v2 messages because i feel that some subfields are not getting converted.
- Also for the Segments like AL1 or PID , have we mapped all the values or the required only.
@pbhallam Would be really helpful if someone can answer these questions for me.
Answer to Q1: I'll take a look at your HL7 & json you provided.
Answer to Q2: We have extensively tested all of the messages and segments we support as listed in the README. You can inspect the tests to see how messages, segments, and fields are tested.
Answer to Q3: For each segment, we cover a broad set of fields, many more than the required, but not all fields for every segment. There are two ways to see what fields are covered:
- If you know what FHIR element the segment converts to, look at the corresponding YAML file. For example, if you look at the Patient.yml you can see we handle PID 3, 5, 6, 7, 8, 10, 11, 13, 14, 15, 16, 17, 19, 20, 24, 25, 29, 30. We also handle in Procedure.yml PID.18. For AL1, look at AllergyIntolerance.yml and you can see we handle AL1 2, 3, 4, 5, 6.
- Or you can just download the source and search on
PID.orAL1.and you can see the instances ofPID.xetc. This will also lead you to where these are tested in unit tests.
Regards, Brian
Regarding Q1: HL7 V2.6 PID.3 is of type CX.
The fields in PID.3 are mapped as follows:
PID-3 Patient Identifier List:
├ PID-3.1 (ID Number) 155919
├ PID-3.2 (Check Digit)
├ PID-3.3 (Check Digit Scheme)
├ PID-3.4 (Assigning Authority) HEALTHY TIMES HOSPITAL
├ PID-3.5 (Identifier Type Code) MR
├ PID-3.6 (Assigning Facility) HEALTHY TIMES HOSPITAL
├ PID-3.7 (Effective Date)
├ PID-3.8 (Expiration Date)
├ PID-3.9 (Assigning Jurisdiction) USSSA
└ PID-3.10 (Assigning Agency or Department) SS
We map CX.1 "ID number" as the identifier.value
We map CX.4 "Assigning authority" as the identifier.system. Because HEALTHY_TIMES_HOSPITAL is an unknown authority, we attach urn:id at the front.
This produces:
"identifier": [
{
"type": {
"coding": [
{
"system": "http://terminology.hl7.org/CodeSystem/v2-0203",
"code": "MR",
"display": "Medical record number"
}
]
},
"system": "urn:id:HEALTHY_TIMES_HOSPITAL",
"value": "155919"
},So the output you are seeing is working as designed. Is there some different output you expect?
@cragun47 didnt understand why HEALTHY_TIMES_HOSPITAL is an unknown authority, we attach urn:id at the front. PID 3.4 is mapped right
Can you explain what does it mean by Unknown Authority
When we have an authority, we first look it up in our tables to see if we know it. We look in this table.. If we can't find it, it is an unknown authority.
But we have to have system. A missing system will cause an error in validation. A system that is not valid will cause errors in the validation step. So we construct a system that will only produce a warning. By doing so, we allow the conversion to complete, and we don't throw away information provided for the unknown system.
While there may be other ways to construct a unique system that will produce only a warning, and retain the original information, the way we chose was to prepend urn:id:.
URIs of the urn: scheme are not locators, are not required to be associated with a particular protocol or access method, and need not be resolvable. They should be assigned by a procedure which provides some assurance that they will remain unique and identify the same resource persistently over a prolonged period wikipedia
@cragun47 We did some thorough analysis and check on fields that were mapped for different segment but the below mentioned resources were not there in the generated FHIR message.
Specimen
Immunization
common
coverage
device
relatedperson
diagnostic report
documentreference
observation_immunizationreaction
medication Administration
medication
medication Request
Organization_ServiceProvider
We have attached the HL7v2 and FHIR message in a zip for your reference. Please help us understand as to why the resources are not getting generated in attached output fhir.json file. We are using maven dependency 1.0.14 and hapi 5.6.21 for this.
It would be helpful if you would run this HL7 file at your environment and provide us with the converted output file
files.zip
@arch2199 I will have a look at your files and respond later today.
Hi @arch2199. I ran your .hl7 file through the most current code of the converter. The results were the same as the file you provided.
Three resources were created:
- MessageHeader (from the MSH)
- Observation (from the OBX)
- Patient (from the PID and PD1).
The EVN, ORC, RXA, RXE, RXR, SPM, and TXA segments were not converted because the message ADT_A01 does not support them according the HL7 V2.6 documentation for ADT_A01. To convert them, you will need an applicable supported message.
Regarding your list of segments you mention in your analysis:
- Specimen (SPM) is supported in
ORU_R01messages. - Immunization (RXA) is supported in
VXU_V04messages. - (I'm not sure what segment common refers to, please tell me more)
- Coverage (IN1) is currently being developed and will be supported in
DFT_P03andADT_A01messages the next release. Note however that your provided .HL7 message did not have any IN1 segments, so no coverage was created for your example. - Device (OBX.18) is supported for
ADT_Axx,OMP_009,ORM_O01,ORU_R01,PPR_PC1, andVXU_V04. However, your example did not include field 18 in OBX, so no device resource was created. - RelatedPerson (from IN1) is currently being developed and will be supported in
DFT_P03andADT_A01messages the next release. Note however that your provided .HL7 message did not have any IN1 segments, so no RelatedPerson was created for your example. - DiagnosticReport (from ORC / OBR) is supported for
ORU_R01messages. - DocumentReference (TXA) is supported for messages
MDM_Txx,ORM_O01, andPPR_PC1 - Observation Immunization Reaction (AL1), is supported for
VXU_V04andADT_A01messages. However your example did not include an AL1 segment. - Medication Administration is not currently supported by current messages.
- Medication is not currently supported by current messages.
- MedicationRequest (RXE/RXO) is supported for messages
OMP_O09,ORM_O01,PPR_PCx,RDE_Oxx. Note there are significant improvements for MedicationRequest being added in the next release. - Organization ServiceProvider (PV1) is supported by messages
ADT^A01,ADT_A08,OMP^O09,ORU^R01,RDE^O11,RDE^O25, andVXU^V04. Your example did not have an PV1 segment.
As you can see we currently support many of the segments you mention, given the correct message and segments. With the next release, we will support several more.
Does that answer your question?
@cragun47 thank you for the detailed reply. We would like to contribute to this project.
We dont fully understand how things are mapped and related but on a starting note if we would want to start contributing with a new resource , how can we start doing that
What is the process you suggest.
Thanks again for the detailed info.
Hi @manaschandanroy, we'd love to have help.
I am checking in tonight Suggestions for the new developers in DEVELOPMENT.
I think before you decide what you want to contribute, understanding how the templates control the converter is really key.
I suggest these steps:
- Download the project
- Set up your environment for Java development. We have contributors using VS Code, Eclipse, and IntelliJ.
- Run command
gradle clean build. This will confirm your libraries are set up correctly and your development environment is working. (Be prepared that testing step has 500+ tests and may take 10 minutes or more to complete.) - Select a unit test and run it. This will confirm your unit test set up is working. For example, you could try: Hl7FinancialInsuranceTest.java
- Set
localDevEnv = trueingradle.properties. This will help you see your changes without doing a full build. - View the json created from the conversion in the test. The easiest way to do this is put a breakpoint immediately after the command
.convert, which returns json. For most tests this is in a common method:createFHIRBundleFromHL7MessageReturnEntryListinResourceUtils.java. - Use the debugger to step through the asserts of the test. View the associated data structures.
- Look at the templates that make your test run.
- Find the message in src/main/resources/hl7/message. e.g. DFT_P03.yml
- Find the segments created by the message in src/test/java/io/github/linuxforhealth/hl7/segments. For example: Coverage.yml and Organization.yml and RelatedPerson.yml.
- Observe how the Segment.Fields, such and IN1.17 map to resources.
- Make a small change to one of the tests. Change the input HL7 and see how the output works. Repeat.
You'll want to read: TEMPLATING. and do your best to understand that.
Let me know how it goes.
Closing as questions have been answered, please feel free to comment or reopen if you have further issues!