LA Order Weight Conversion

[JohnNKing]

Story

As the LA PHL, so that I can parse the Ochsner facilities' weight data in the appropriate unit of measure (UOM), 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").
• We have a sample order message contains an OBX segment with an OBX.3.1 value of "8339-4"
• We have a sample 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 unit of measurement (UOM) 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 = "8339-4" OR "58229-6".) is multiplied by 1000x.
• The UOM designation of "g^gram^UCUM" is added to OBX.6 in the outgoing order message.
• 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.

Tasks

Research

• Discuss in Friday SME call to clarify inbound birth weight. (Will it really be a string value, and include ounces in parentheses?)

Engineering

• 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.
• Configure the transform above to only be applied to Ochsner order message.
• Add assertion to the automated tests for this scenario.

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

[JohnNKing]

See #913 for a closed but related effort

[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

[scleary1cs]

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