Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Inbound OML Processing #819

Closed
4 of 31 tasks
sfradkin opened this issue Jan 29, 2024 · 6 comments
Closed
4 of 31 tasks

Inbound OML Processing #819

sfradkin opened this issue Jan 29, 2024 · 6 comments

Comments

@sfradkin
Copy link
Contributor

sfradkin commented Jan 29, 2024

Story

As an HCO, so that our OML orders can be sent to our public health lab, we want RS to be able to process inbound HL7v2.5.1 OML messages.

Acceptance Criteria

  • A properly formatted OML message is processed through RS without error.
  • An improperly formatted OML message is returned from RS with an error.
  • RS sends the intermediary FHIR converted from the HL7 OML message.

Tasks

Research

n/a

Engineering

  • Update ReportStream to be able to accept OML messages (without an HTTP error resulting) : Inbound OML Accepted by ReportStream #962
  • Determine if we can use LinuxForHealth/hl7v2-fhir-converter for OML conversion. Their readme states they only partially support it
    • If we can't use LinuxForHealth, find out if there's another tool we can use
    • If there's no third-party tool we can use, we need to make one
  • Test the behavior of TI in staging now that OML is supported
  • If needed, update the TI service to handle inbound FHIR resources that are unique to OML (in comparison to ORM; e.g. Patient contacts via NK1)

Definition of Done

  • Documentation tasks completed
    • Documentation and diagrams created or updated
      • Implementation guide (/ig folder)
      • 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
    • Code is reviewed or developed by pair; 1 approval is needed but consider requiring an outside-the-pair reviewer
    • Code quality checks passed
  • Security & Privacy tasks completed
    • Security & privacy gates passed
  • Testing tasks completed
    • Load tests passed
    • Unit test coverage of our code >= 90%
  • 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

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
@sfradkin sfradkin added the story label Jan 29, 2024
@scleary1cs
Copy link
Contributor

RS already supports inbound ORM.

@scleary1cs
Copy link
Contributor

Specify/What is the expected format for the FHIR message coming out of RS?

@scleary1cs
Copy link
Contributor

The converter partially supports the following message types/events:

OML_O21 - Laboratory Order
Repeating ORDER groups are not supported
ServiceRequest resources are only created when both ORC and OBR are provided
PID must be provided to avoid FHIR validation errors
OBX and Observations are not yet supported

@JohnNKing
Copy link
Contributor

Created draft PR: CDCgov/prime-reportstream#13766

@scleary1cs
Copy link
Contributor

CDCgov/prime-reportstream#15910
Update OML mappings #15910

@scleary1cs
Copy link
Contributor

AL no longer an initial implementation partner.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants