INM wrappers requirements

InM Wrappers Requirements

This page is the "home page" for the InM project to develop the requirements for a new wrappers specification.

HL7 GFORGE will be the place for formal documents, while this wiki will be used for discussion/collaboration.

Tony Julian 14:48, 12 May 2011 (UTC)

Alexander Henket Considering the GForge pages are currently empty: are there no initial requirements gathered yet? A few things that have come up at Nictiz over time:

• Formal way to carry a patient in the ControlAct. Currently there's R_AssignedPerson, which just works employees of some sort. e.g. add R_Patient. See InM List discussion
  • Additional requirement: formal way to carry a patients legal representative in the ControlAct, e.g. parent, or a guardian.
• A solution for publish/subscribe, that includes the ability to query for subscriptions. @modifyCode just a allows subscribe en unsubscribe -- maybe this goes a little beyond just wrappers
• ProfileId in Batch wrapper
• Updated explanation of QueryAck.queryId which now reads as if the querying system determines that instead of the responding system. The querying system just determines QueryByParameter.queryId

Rene spronk Many requirements are known, without them being explicitely documented. In general there's

• a tendency to move all participants that are "contextual" to the controlAct wrapper (from the payload), where one is even allowed to not send them in the wrapper itself, but as a separate parameter in an operation (i.e. as if the wrapper inherits them from the set of operation parameters).
• and there's the standing requirement that the new wrappers be suitable for use in both services as well as messages.
• The work at NCI, which will probably be presented by John Koisch during the May2011 WGM appears to be a good starting point for discussion. Their work is pragmatic and doable and can be extended to both messages as well as services (probably even documents if you wish to stretch it into the CDA header space).

Alexander Henket It would seem vital to get the requirements documented properly before anything.

• Dutch need the wrappers for interaction information exposed in the transmission wrapper, Control Act, and transmission.
  • We dont initiate a batch, only respond.
  • The attention line is used to communicate information including patient information to reduce the need to parse the rest of the content.
  • The central hub reads the attention line, matches to SOAP headers
  • The receiver matches attention line to payload.
  • Always use author, may use overseer, depending on the message.
  • Devices have no overseer, Medical information does.
  • Patient may be author and/or overseer.
• Canada has same requirements.
  • It should be a role under proper modeling.
  • It was put in for use by those who wished to use it for whatever.

• Need to aplit to two transport wrappers/structure headers differently
  • One to be used for
    • Addresses
    • Time Stamps
    • Attention line
  • One for contract - lives between transport and control act.
    • Should include control id
  • Do we do assertions about how to fill in a soap header using HL7?
  • Survey and get a sense of what people need to get their business.
  • Maybe IC
  • Should discuss appropriate transports.
• What do we need to support?
• we should identify use cases.
• Alexander will document the Dutch use case(s)
• Patrick or Jean will document the Canadian use case
• Transports supported/expected to support would be useful metadata
• Tony will contact other groups - SOA, ArB, OO, MnM, IC, ITS , VOCAB (possibly later on) to determine involvement.
• Composite order is doing SAIF, CDA will plug in somewhere - do we want to follow SAIF?
• Patrick suggested/moved to get assigned a "SAIF" project.