Essential Concepts OO Behavior

Back to Orders & Observations WG main page

Introduction

In Cambridge, the OO group discussed the principles involved in communicating order information between partners.

The slide deck for this can be found here:

2010 10 06 Cambridge Working Slide Deck

This deck was modified to comply with the HL7 SAIF Behavioral Framework. That deck can be found here:

Behavioral Framework Concepts

These concepts are discussed on this page.

Principles

• Context – An order establishes the default context for its contents. Context includes, but is not limited to author, subject, record target, verifier and transcriber. An order is an assemblage of information that may be verified.
• Management – The state of an order is managed by the entity (organization or device) that is the custodian of the order. The custodian for an order may change over time, so there need to be clear mechanisms in place in the behavioral order model for transferring custodianship of an order.
• Fulfillment – An order is intended to be fulfilled (satisfied) by the actions taken by the performer(s). The custodian of the order is responsible for determining if the actions taken by the performer fulfill the order.
• Actionable – An order clearly communicates the action to be taken by the performer(s).
• Completeness - An order includes relevant details necessary to perform the requested action(s).

(Note: Verifiable is another principle felt to be subsumed by the others)

Elemental Components in Interoperable Communications

In any communication described by a behavioral model, there are three essential elements:

• Contract between parties - the broader integration context between the parties covering issues of timing, liveness, service levels, and so on
• Context Binding - the interoperability context between parties that binds essential elements of the business act (e.g., providing health care) to the broader integration contract
• Payload - Information to be communicated concerning activities within the custody of one party

In HL7, there are two ways of Context Binding:

• Control Wrappers - Control wrappers are at their heart about managing workflow, what action to take on the payload. This workflow has its own context that is separate from the context of the payload. For instance, we have an order which was authored by a specific provider. That's part of what we have agreed as the context for the order. It may be canceled by a different provider, who authors the control wrapper but does not alter the payload.
• Context Wrapper - Context wrappers provide important behavioral bindings to other activities or threads in execution between the payload and the contract. For example, exceptions, including information and warnings, may be managed through a context wrapper without altering the essential payload.

Interoperability Paradigms

These concepts form intersections that describe essential characteristics of the HL7 Interoperability Paradigms.

Principle	Contract	Control Wrapper	Context Wrapper	Payload
Context	X		X
Management	X	X
Fulfillment	X	X
Actionable				X
Complete				X

Within these definitions:

• Services comprise:
  • Contract
  • Control Wrapper
  • Context Wrapper
  • Payload
• V3 Messaging comprise:
  • Control Wrapper
  • Context Wrapper
  • Payload
• Documents comprise:
  • Context Wrapper
  • Payload

The Context Binding takes a different form, depending on the paradigm.

• Service Context Binding
  • Control Wrapper - may take the form of a technology component (for example, session component or payload wrapper) or a function parameter (token)
  • Context Wrapper - may be a characteristic of the service itself
• V3 Messaging
  • Control Wrapper - the traditional Control Act Wrapper
  • Context Wrapper - some realms have blurred the context conduction rules in place around the control act, allowing it to carry context
• Documents
  • Context Wrapper - The context of the document (signing authority, authorship) are elements of the document itself.