CDCgov
Finalize OML Mappings
User Story
As a Report Stream developer I want to fully test all supported fields for an OML message type, so that our integration tests will alert for fields which have been modified.
Description/Use Case
Evaluate new fields to be mapped The following fields should be evaluated for HL7 -> FHIR -> HL7 mappings: PID.17.1.2-6, PID.22.1.2-3, PID.35.1.2-3, PID.39.1.2, PV1.7.14, PV1.20, OBR.32.1-11, OBR.34.1-11, NTE.5.14 (OBR), NTE.9 (OBR), SPM.12.3 (See also: pr comment 1, pr comment 2, pr comment 3, pr comment 4, pr comment 5)
Update OML integration test
- A basic integration test for OML messages was added in the first ticket, but it did not feature all the possible fields. All possible OML fields should be mapped.
- Additionally, this test should represent the different ways NTE and PRT segments can be mapped. For example, NTE segments can be mapped as part of a ServiceRequest or an Observation.
- In addition, it is possible that by adding these fields to the integration test, it will expose some fields which aren't yet mapped in OML FHIR->HL7. If any unmapped fields are discovered, they should be mapped.
Update segment-specific integration tests Lastly, some of our current mapping inventory integration tests are missing supported fields: NK1-13, OBR-9, OBR-14, OBR-15
Risks/Impacts/Considerations
The vast majority of test values can be taken from existing integration tests.
Acceptance Criteria
- All supported fields are present in the OML integration test
- Any new mappings are created and added to all appropriate integration tests
- Any missing segment-specific fields are added to their respective integration tests.
After stuffing as many notes and todos into this task as cropped up, another pass will need to be made to see if any of the low priority items here can be broken into other tickets.
Hey team! Please add your planning poker estimate with Zenhub @adegolier @arnejduranovic @david-navapbc @jack-h-wang @JFisk42 @kant777 @mkalish @thetaurean
All possible OML fields should be mapped -> All possible OML fields in supported segments should be mapped? @JFisk42
Good catch @arnejduranovic, looks like I made that mistake in a few places. You're correct that wherever I mention "all fields" I'm speaking only of fields in currently supported segments.
This ticket is now ready to be refined. Most of the originally proposed fields to add in this ticket were incorrectly identified. As part of the ORM mappings work I've created a list of mappings to update/add. I'll log a ticket for this on Monday.
Hey team! Please add your planning poker estimate with Zenhub @adegolier @jack-h-wang @jalbinson @thetaurean
Spillover reason: Encountered unexpected difficulty in creating repeating segments that is a technical limitation of the hl7 parsing library we use. This resulted in several days of tracking down the exact cause of this issue. Also had to add some scope to this ticket to create some Java classes for OML to avoid some data loss in conversion.
Spillover reason: Main tipping factor this sprint was in some last minute technical changes. (These were related to OBR -> Specimen/ServiceRequest.extension mappings, see PR Comment). These changes had a cascade effect on test data and pushed the PR being opened.