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

Difference between revisions of "Interaction wrappers Dutch Requirements"

From HL7Wiki
Jump to navigation Jump to search
Line 1: Line 1:
 
=Wrappers – Dutch requirements and use cases=
 
=Wrappers – Dutch requirements and use cases=
Author: Alexander Henket
+
Author: Alexander Henket<br/>
Date: May 18, 2011
+
Date: May 18, 2011<br/>
Purpose: provide insight in the way Nictiz uses wrappers as background for the InM Requirements analysis for Wrappers R2
+
Purpose: provide insight in the way Nictiz uses wrappers as background for the InM Requirements analysis for Wrappers R2<br/>
Status: initial writeup for review
+
Status: found fit for use in the InM project regarding wrappersr2<br/>
  
 
Note: this is the Nictiz perspective on wrappers as they are used on the national infrastructure. There are more V3 implementations than just there. Some of them are services based and do not use wrappers. – See e.g. Michael van der Zel (RIMBAA) for his take on wrappers.
 
Note: this is the Nictiz perspective on wrappers as they are used on the national infrastructure. There are more V3 implementations than just there. Some of them are services based and do not use wrappers. – See e.g. Michael van der Zel (RIMBAA) for his take on wrappers.

Revision as of 23:33, 5 June 2011

Wrappers – Dutch requirements and use cases

Author: Alexander Henket
Date: May 18, 2011
Purpose: provide insight in the way Nictiz uses wrappers as background for the InM Requirements analysis for Wrappers R2
Status: found fit for use in the InM project regarding wrappersr2

Note: this is the Nictiz perspective on wrappers as they are used on the national infrastructure. There are more V3 implementations than just there. Some of them are services based and do not use wrappers. – See e.g. Michael van der Zel (RIMBAA) for his take on wrappers.

Transmission Wrappers currently in use

  • Response Batch(MCCI_RM200101UV)
  • Send Message Payload (MCCI_RM000100)
  • Send Accept Acknowledgement (MCCI_RM000200)
  • Send Application Acknowledgement (MCCI_RM000300)

Control Acts currently in use

  • Trigger Event Control Act (MCAI_RM700200)
  • Query Control Act Request : Parameter List (QUQI_RM020000)
  • Query Control Act Request : Query By Parameter (QUQI_RM021000)
  • Query Control Act Request Continue / Cancel (QUQI_RM000001)
  • Query Control Act Response / Acknowledgement (QUQI_RM120000)
  • Master File / Reg Event Notification Control Act (MFMI_RM700700)
  • Master File / Registry Query Response Control Act (MFMI_RM700710)
  • Master File / Reg Registration Request Control Act (MFMI_RM700720)

Note that we do not use the current normative editions, but the Ballot 7 artefacts.

About the Dutch infrastructure

General background information: see AORTA.

We originally worked based on the once existing Web Services Profile Release 2.

  • Interaction in, interaction out, no SOAP headers, interaction in SOAP Body

Later on we had requirements for authentication tokens, electronic signatures and SAML. These are obviously populated in the SOAP headers. We do not use WS-Addressing, WS-Trust, WS-Reliable Messaging, etc. (see [1] for a whitepaper that discusses some of these webservices related topics)

A few specifics of what we use. The full listing is below that.

Interaction-id

We rely heavily on the interaction-id as the basis for routing, authorization, processing

Profile-id

We have made profile-id mandatory [1..1] to tie a message into a specific version of its implementation guide. This is now a strandardized practice in the universal HL7 v3 specification.

Application identification (sender/receiver)

We deploy an Application Registry on the central hub, that assigns ids to all applications on the national infrastructure. All traffic goes through this central hub (see AORTA for architecture). The hub does application-id to webservice/URI resolving. The sender just needs to know the receiving application-id, and uses the central hub as his end point. The hub takes care of the delivery, if it is not the endpoint itself.

Patient identification

Initially we let the central hub inspect the full message to get the patient-id out for auditing, and authorization purposes. This was cumbersome as the patient is in a different location depending on the message, and we decided to put the patient-id up in the transmission wrapper AttentionLine. Only initiated interaction require AttentionLine.

Legal authors and/or overseers

We have 2 levels of trust: low and middle. On trust level low, application may send/receive messages without any person attached to them. This is only applicable to non-medical contents, and useful for e.g. prefetching. Any certified application may send message as authorOrPerformer without an overseer being responsible.

On trust level middle any initiated interaction must be under the responsability of a licensed care provider with an appropriate role, or under the responsability of a patient/parent/guardian or otherwise legal representative for the patient this interaction is about. Finally we have a licensed government body that acts as customer service for patients, and a patient (or his legal representative) may ask them to perform certain operations.

Allowed combinations at trust level middle

  1. . If the patient initiates interactions:
    1. . Patient - Control Act overseer
    2. . Patient - Control Act authorOrPerformer
    3. . Patient - Payload
    4. . Patient - AttentionLine
  2. . If a legal representative initiates interactions for the patient:
    1. . Legal representative - Control Act overseer
    2. . Legal representative - Control Act authorOrPerformer
    3. . Patient - Payload
    4. . Patient - AttentionLine
  3. . If Customer service initiates interactions for a patient:
    1. . Patient - Control Act overseer
    2. . Customer service - Control Act authorOrPerformer
    3. . Patient - Payload
    4. . Patient - AttentionLine
  4. . If customer service initiates interactions for a legal representative:
    1. . Legal representative - Control Act overseer
    2. . Customer service - Control Act authorOrPerformer
    3. . Patient - Payload
    4. . Patient - AttentionLine
  5. . If a properly licensed care provider initiates a message
    1. . Licensed care provider - Control Act overseer
    2. . Licensed care provider - Control Act authorOrPerformer
    3. . Patient - Payload
    4. . Patient – AttentionLine
  6. . If any care employee initiates an interaction under the responsability of a properly licensed care provider:
    1. . Licensed care provider - Control Act overseer
    2. . Care employee - Control Act authorOrPerformer
    3. . Patient - Payload
    4. . Patient – AttentionLine

Allowed combinations at trust level low

  1. . If an application initiates or replies to an interaction:
    1. . Application - Control Act authorOrPerformer
    2. . Patient – Payload (if applicable)

Listing of attributes used in MCCI_DM000000UV (D-MIM Transmission)

  • Batch.id, Message.id
  • Batch.creationTime, Message.creationTime
  • Batch.versionCode, Message.versionCode
  • Batch. interactionId, Message.interactionId
  • Batch.profileId (we added that), Message.profileId (Mandatory, 1..1)
  • Batch.transmissionQuantity
  • Message.processingCode
  • Message.processingModeCode
  • Message.acceptAckCode
  • Message.Sender (1..1)/Receiver (1..1)/RespondTo (0..*).Device.id
  • Message.Sender (1..1)/Receiver (1..1)/RespondTo (0..*).Device.asAgent.Organization.id/name
  • Message.AttentionLine
  • Message.Acknowledgement.typeCode
  • Message.Acknowledgement.TargetTransmission.id
  • Message.Acknowledgement.AcknowledgementDetail.* (all attributes)

Listing of attributes in MFMI_DM700700 (D-MIM Master File / Registry)

  • ControlActProcess.code
  • ControlActProcess.effectiveTime
  • ControlActProcess.authorOrPerformer.R_AssignedPerson
    • id, code, Person.name. Organization.id, Organization.name, Organization.addr
  • ControlActProcess.authorOrPerformer.R_AssignedDevice
    • id, name, addr
  • ControlActProcess.overseer.R_AssignedPerson
    • id, code, Person.name. Organization.id, Organization.name, Organization.addr
  • ControlActProcess.subject.RegistrationProcess
    • id, statusCode, effectiveTime
    • subject1.RegisteredRole
    • subject2.RegisteredAct

Listing of attributes in MCAI_DM700200 (D-MIM Trigger Event Control Act)

  • ControlActProcess.code
  • ControlActProcess.effectiveTime
  • ControlActProcess.authorOrPerformer.R_AssignedPerson
    • id, code, Person.name. Organization.id, Organization.name, Organization.addr
  • ControlActProcess.authorOrPerformer.R_AssignedDevice
    • id, name, addr
  • ControlActProcess.overseer.R_AssignedPerson
    • id, code, Person.name. Organization.id, Organization.name, Organization.addr
  • ControlActProcess.reasonOf.DetectedIssueEvent
    • id, code, text, value

Listing of attributes in QUQI_DM000000 (D-MIM Query Infrastructure)

  • ControlActProcess.code
  • ControlActProcess.effectiveTime
  • ControlActProcess.authorOrPerformer.R_AssignedPerson
    • id, code, Person.name. Organization.id, Organization.name, Organization.addr
  • ControlActProcess.authorOrPerformer.R_AssignedDevice
    • id, name, addr
  • ControlActProcess.overseer.R_AssignedPerson
    • id, code, Person.name. Organization.id, Organization.name, Organization.addr
  • ControlActProcess.reasonOf.DetectedIssueEvent
    • id, code, text, value
  • ControlActProcess.QueryByParameter
    • queryId, statusCode, modifyCode, responseModalityCode, responsePriorityCode, executionAndDeliveryTime
    • Parameter
    • ParameterList
  • ControlActProcess.QueryContinuation
    • queryId, statusCode
  • ControlActProcess.QueryAck
    • queryId, statusCode, queryResponseCode, resultTotalQuantity, resultCurrentQuantity, resultRemainingQuantity