|
|
| (4 intermediate revisions by the same user not shown) |
| Line 1: |
Line 1: |
| − | The NHS use-case is as follows: "NHS Connecting for Health has a requirement is to create a pair of querry / response interaction pair that will allow a pharmacies to retrieve the details of any number of specified prescriptions and the last dispense against from a central ETP component. The prescription and dispense message instances are pre-existing messages that the ETP component has previously received and stored, and are now being retrieved by the pharmacist. It is proposed to retrieve information using a query containing the pharmacy id and one or more prescription ids."
| + | (orphaned page) |
| − | | |
| − | If one generalizes this use-case it is what was known as "event-replay" in HL7 v2, something not yet supported in HL7 v3. From HL7 v2 (RQQ^Q09, Ch.5): ''The Event Replay Query under version 2.x provides a way for the querying system to request data formatted very similar to the format that would have been used were this data to be sent as an update in response to a trigger event.''. The response message (ERP^R09) consists of the MSH, MSA, QAK, ERQ segments; ''the remainder of this message is defined by the contents of the corresponding segment-oriented record-oriented unsolicited update message, excluding the MSH, as defined by the function-specific chapters of this specification. The input parameter list may be satisfied by more than one record-oriented unsolicited update message: in this case, the segment group after the ERQ segment may repeat.''
| |
| − | | |
| − | To support this use-case the NHS proposal 968 describes a Control Act that provides a container for batching of one or more controlled Acts (or other payload types) within a single transmitted interaction. The container is designed to permit batching of multiple payloads that have the same administrative data (e.g. ControlAct author, etc), whilst allowing error information to be returned for individual items.
| |
| − | | |
| − | The Batch Control Act consists of a root or “outer” Control Act that holds the administrative and batch-level information common to all items in the batch (this is effectively the controlAct as present in the current ControlAct wrapper) and one or more “inner” or payload Control Acts (apart from the payload, detectedIssueEvent and queryAck these have no associations, but inherit them from the "outer" controlAct). As a result the model factors out the commonly repeating transmission control and administrative elements required when items are batched at the transmission-wrapper.
| |
| − | | |
| − | == Alternative solutions ==
| |
| − | *The use of a single Trigger Event Control Act with multiple payload stubs (as provided by MCAI_DM700200), for example, would not allow errors to be returned for individual items. Each payload Control Act is designed to hold an individual business payload or payload error. The business payload may consist of a request or notification, a query request or a query response.
| |
| − | *The use of the [[Batch Transmission Wrapper]] mechanism incurs the overhead of multiple individual transmission and control act wrappers. The provider of the English national infrastructure has estimated this overhead to be 7% for a 50Mb Batch.
| |
| − | | |
| − | == Actions ==
| |
| − | *Create a special R-MIM for the event-replay controlAct wrapper.
| |
