CA Transform: Copy ORC-12 to OBR-16

[JohnNKing]

Backlog Task

For CA, copy ORC-12 to OBR-16.

The branch for this is story/1242-copy_ORC-12_to_ORC-16

Completion Criteria

• [x] Data in ORC-12 is now populated in OBR-16, unless ORC-12 is empty, in which case OBR-16 should be left as-is.
• [x] ORC-12 will stay untouched (similar to copy/paste not cut/paste)

Tasks

• [x] Find out FHIR Paths for fields
  • [x] ORC-12 Bundle.entry.resource.ofType(ServiceRequest).requester.resolve().practicioner.resolve().name
  • [x] OBR-16 Bundle.entry.resource.ofType(ServiceRequest).extension.where(url='https://reportstream.cdc.gov/fhir/StructureDefinition/obr-observation-request’).extension.where(url='OBR.16').resolve().name
• [x] (Optional) Add FHIR Paths in etor/src/main/java/gov/hhs/cdc/trustedintermediary/plugin/path/Hl7FhirMappingPath.java. Even if not used by the code, it's useful to have them documented there for future reference - @tjohnson7021
• [x] Create a new class implementing CustomFhirTransformation in etor/src/main/java/gov/hhs/cdc/trustedintermediary/etor/ruleengine/transformation/custom and add the transformation code Note: you can mimic what's in UpdateReceivingFacilityWithOrderingFacilityIdentifier.java to implement the transformation
• [x] Add tests in etor/src/test/groovy/gov/hhs/cdc/trustedintermediary/etor/ruleengine/transformation/custom
• [x] Add transformation entry in etor/src/main/resources/transformation_definitions.json, using the class name and arguments in the custom class

Other Notes

Test file(s) used:

• We have created new test files (017-019) in /examples to account for the test cases.

[scleary1cs]

This is an XCN data type

[scleary1cs]

Both ORC-12 and OBR-16 are XCN data types.

[jbiskie]

Similar previous work: #1096

[luis-pabon-tf]

If OBR-16 already has a value, are we going to override it?

[basiliskus]

If OBR-16 already has a value, are we going to override it?

Yes, I don't think we need to preserve the OBR-16 value

[scleary1cs]

My $0.02, I agree, OBR-16 does not need to be preserved. We can confirm this on an upcoming call or an out of cycle email. Unless @dbgolson happens to know now.

[jbiskie]

More detail from @dbgolson: For this CDPH-specific data transformation need, yes, we would want to replace any content in OBR-16 with content from ORC-12. Both are fields designated for Ordering Provider and both constrained by the HL7 v2 LRI implementation guide to be equivalent. The current problem is that CDPH is only partially populating OBR-16 and UCSD looks to OBR-16 for Ordering Provider matching purposes.

Regarding the instance where ORC-12 is empty, both OBR-16 and ORC-12 are strictly Required to be populated per the HL7 v2 LRI IG, so this should not happen and would be an error. However, the Intermediary is only doing limited message content validation, so if ORC-12 were actually empty, I would not suggest replacing OBR-16 data with the empty data from ORC-12

[tjohnson7021]

We scraped a test for "when the OBR extension exists, but the OBR.16 extension does not exist". This is probably not a real-world situation.

[jorg3lopez]

Transformation is done, we will move on testing the code.

[jorg3lopez]

tests: case1: ORC12 has value, OBR16 is empty -> OBR16 gets populated with ORC12s value case2: ORC12 has value, OBR16 has value -> OBR16 gets populated with ORC12s value case3: ORC12 is empty, OBR16 has value -> fails RS ingestion of FHIR message.

We will continue to run more tests to see if there was something we missed for the reason of case 3 to fail.

[jbiskie]

All 4 test cases passed for me locally. @sdjpark also ran test case 3 successfully, so we may want to take another look at what went wrong with your test case 3, @jorg3lopez.

I added the 3rd and 4th steps to the example files for 017-019 and updated the 3rd and 4th steps for the existing 007 examples so they match current state.