LA Test Orders - "Weight at Collection" OUM Conversion

[JScott-JMC]

This is essentially the same function as #1650 with a different LOINC code in OBX.3.1

Story

As the LA PHL, so that I can parse the Ochsner facilities' Weight at Collection data in the appropriate unit of measure (OUM), I need the CDC Intermediary to convert this numeric field from kilograms to grams for all Ochsner NBS test order messages.

Pre-conditions

• A test order is received in RS from the LA Ochsner NBS system (MSH.3 = "13^1.2.840.114350.1.13.286.2.7.2.695071^ISO").
• The order message contains an OBX segment with an OBX.3.1 value of "58229-6".

*Note: The Ochsner team will NOT be sending the actual OUM in OBX.6, but they confirmed it will be in kilograms

Acceptance Criteria

• The numeric Weight at Collection value in OBX.5.1 (when OBX.3.1 = 58229-6) is multiplied by 1000x.
• The UOM designation of "g^gram^UCUM" is added to OBX.6.
• This transformation is successfully performed for all NBS test orders received from the LA Ochsner system.
• This transformation is not performed for NBS test orders received from other hospital systems.
• Obtain an Ochsner-specific example order message that captures the Weight at Collection as identified above.
• Create a new transform that multiplies the proper OBX 5.1 value by 1000x.
  • Clarify if we can re-use an existing transform or if a new one will be needed.
• Configure the transform above.
• Add assertion to the automated tests for this scenario.

Tasks

Research

• Research work needed to complete the story
• Foundational: High-level research that will support this and future efforts

Engineering

• Engineering work needed to complete the story
• Foundational: Technical runway work to support this and future efforts

Definition of Done

• Documentation tasks completed
  • Documentation and diagrams created or updated
    • ADRs (/adr folder)
    • Main README.md
    • Other READMEs in the repo
    • If applicable, update the ReportStream Setup section in README.md
  • Threat model updated
  • API documentation updated
• Code quality tasks completed
  • Code refactored for clarity and no design/technical debt
  • Adhere to separation of concerns; code is not tightly coupled, especially to 3rd party dependencies
• Testing tasks completed
  • Load tests passed
  • Additional e2e tests created
  • Additional RS e2e assertions created in the rs-e2e project for any new transformations. Includes improvements to the assertion code required to make the new assertions
• Build & Deploy tasks completed
  • Build process updated
  • API(s) are versioned
  • Feature toggles created and/or deleted. Document the feature toggle
  • Source code is merged to the main branch

Note: Please remove any DoD items that are not applicable

Research Questions

• Optional: Any initial questions for research

Decisions

• Optional: Any decisions we've made while working on this story

Notes

• Optional: Any reference material or thoughts we may need for later reference

[basiliskus]

Related to #1091

[basiliskus]

Link to orders gap analysis: https://docs.google.com/spreadsheets/d/1irLQZ-Kr3Btud6yBnTw9J3OXCdrFuE4C/edit?usp=drive_link&ouid=102849307490663018252&rtpof=true&sd=true

[JohnNKing]

Closing in favor of combining this effort with #1650

[scleary1cs]

Updated LA Orders Gap Analysis:
https://docs.google.com/spreadsheets/d/1irLQZ-Kr3Btud6yBnTw9J3OXCdrFuE4C/edit?gid=2047071728#gid=2047071728