Spike: Scoping of ACK Support

[JohnNKing]

Spike Goal

Generate options and approximate level of effort to support ACK handling as needed by initial partners.

Completion Criteria

• [x] List of implementation options documented
• [ ] Pros and cons documented for each option
• [x] Rough level of effort estimated for each option

Tasks

• [x] Epic 1
  • [x] Review stories listed below
  • [x] Discuss during Engineering Block
  • [x] Determine potential solutions
  • [x] Determine what needs to happen in ReportStream to support those options
  • [x] Estimate level of effort for each solution
• [x] Epic 2
  • [x] Review stories listed below
  • [x] Discuss during Engineering Block
  • [x] Determine potential solutions
  • [x] Determine what needs to happen in ReportStream to support those options
  • [x] Estimate level of effort for each solution
• [x] Epic 3
  • [x] Review stories listed below
  • [x] Discuss during Engineering Block
  • [x] Determine potential solutions
  • [x] Determine what needs to happen in ReportStream to support those options
  • [x] Estimate level of effort for each solution

Potential Epic 1

• Note: Need to learn how notifications currently work in ReportStream
• Generate email warning on message failure; see:

  • 659 - Failure Notification: ReportStream Inbound Orders

  • 660 - Failure Notification: Trusted Intermediary Orders

  • 661 - Failure Notification: ReportStream Rejected Outbound Orders

  • 662 - Failure Notification: ReportStream Outbound Order Delivery

  • 772 - Failure Notification: Results

  • 1049 - Email Notification of Failures

Potential Epic 2

• Pass through HL7 MSA messages generated by EHR or LIMS asynchronously; see:

  • 890 - HL7 ACKs => FHIR

  • 888 - Receiving ACKs via REST

  • 889 - Sending ACKs via REST

  • 906 - FHIR => HL7 ACKs

Potential Epic 3

• Generate HL7 MSA messages based on HTTP connection failure
  • (Stories needed)
• Generate HL7 MSA messages based on HTTP response status code; see:

  • 1051 - Generate ACK from EHR HTTP Success

  • 1050 - Create NAK from EHR HTTP Error

• Forward HL7 MSA message returned in REST response body
  • (Stories needed)
• Forward HL7 MSA message returned via SFTP
  • (Stories needed)

Independent Story

• 1052 - Prevent Order Delivery for Certain Validation Errors

Timebox

16 hours

Notes

• see https://github.com/CDCgov/trusted-intermediary/issues/340#workspaces/633de70d939f6c00155f3722/epics/Z2lkOi8vcmFwdG9yL1plbmh1YkVwaWMvMTc2NDc3
• see AL and LA service blueprints
• How can we categorize these ACK/NAKs? Sync vs async? Due to validation (caused by message content) vs connectivity?
• Scenarios to consider:
  • HL7 MSA messages with either AA or AR data type (ACKs & NAKs)
  • Potentially HL7 MSA messages with the CA or CR data type
  • MSA received via ReST:
  • Asynchronously (similar to orders and results sent through ReportStream)
  • Synchronously (within the response body -- returned when POSTing an order or result to an EHR or LIMS)
  • MSA received via SFTP
  • Generating NAKs in response to a connectivity failure (e.g. cannot deliver to EHR or LIMS)
  • Generating NAKs in response to an HTTP error returned by an EHR or LIMS
  • Generating NAKs in the event of an internal RS/TI error
  • Returning an ACK via the ReportStream response body (may be needed by Epic if RS can fail with an HTTP 200)

[scleary1cs]

"Scoping of ACK Support" added to the 05/24 biweekly RS meeting.

[scleary1cs]

https://lucid.app/lucidchart/339b7c79-7228-40b8-b7bf-92566696077b/edit?invitationId=inv_3da4c961-cb78-4b57-ac28-dc9eda35664b&page=0_0#

[JohnNKing]

https://docs.google.com/document/d/1q-7A5_1XVX-LruDal3dtpZtI95XH_zJA6ologCkMKSA/edit#heading=h.b6at402afy9b

[JohnNKing]

Stories updated based on this spike: #888 & #1049