This wiki has undergone a migration to Confluence found Here
<meta name="googlebot" content="noindex">

Orchestration of Error Responses in a Batch

From HL7Wiki
Revision as of 07:07, 9 May 2007 by Rene spronk (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

Issue: how does one deal with the grouping/routing of query responses if those contain errors?

AORTA, the Dutch NHII, uses a central orcehstration manager application to route queries and responses. In a simplified scenario,

  1. The querying system queries the orchestration manager for the details of all medication supplies to patient #123. As far as the querying system is concerned the only party it is exchanging messages with is the destination of its query (the orchestration manager). It is the intent that the orchestration manager acts as a virtual frontend.
  2. The orchestration manager doesn't have a copy of the clinical data, it only knows what other systems it should route this query to. Those systems that the query was sent to respond with 0 or more medication supplies to the orchestration manager.
  3. The orchestration manager changes the Transmission wrappers in the response interactions, and updates the information contained in the queryAck class so it will appear to the original querying system as if the response was generated by the orchestration manager.

This works just fine. Until we have a situation where 1 or more of the secondary systems being queried respond with errors/rejects (in any of its responses, it may sent multiple response messages to the query). Example:

  • System 1 responds with: AA(1)
  • System 2 responds with: AA(2) AE(3)
  • System 3 responds with: AR(4)
  • System 4 responds with: AA(5)

When does a Query end?

If we assume the above order is also the one used to route responses to the original querying system, then it receives

  • AA(1) AA(2) AE(3)

At which point the querying system may stop listening for responses, because it has received an error. Note: there may be business rules for certain queries to abort after having received the first AE, or an AE of a specific type. No such use-case is known at this point in time.

Orchestration Manager Scvenario

The orchestration manager

  1. could be intelligent by grouping all errors/rejects into 1 final reponse interaction:
    • AA(1) AA(2) AA(5) AE(3,4)
    • This option requires that all detectedIssues and all syntax issues related to the query be grouped into this final Error interaction.
  2. Define that query results will be in random order and SHALL be processed until resultRemainingQuantity hits 0, regardless of AE/AR/AA.

Given the motion above option 1 should be used.