Composite Order

Back to Orders & Observations WG main page

Back to OO Projects page

Scope of Composite Order

The Composite Order topic includes the ability to order multiple basic healthcare services in one message; the disciplines included are request for lab services, diagnostic imaging services, and pharmacy services. This topic covers all interactions related to requesting single or combinations of healthcare services. The Composite Order project has a couple of sub-projects (project which contribute content to composite order):

• Behavioral Framework Project
• Lab Order Template

Link to the Conceptual Specification

• Composite Order Conceptual Specification

Leadership

Co-Chair: Patrick Loyd; 415-209-0544, patrick.e.loyd@gmail.com

Project Facilitator: Patrick Loyd

Conference Calls and Minutes

Dates: Meets w/regularly scheduled OO conference calls. Weekly on Thursdays.

Time: 13:00 - 14:00 EST

Phone Number: +1 (770) 657 9270

Participant Passcode: 653212

Characteristics of a Composite Order

The current design thinking for Composite Order is to move from an entirely constraint-based approach to a building-blocks approach; a move which we believe aligns with the SAIF principles and emerging HL7 Architecture. Meaning we're moving from a big DMIM which represents the collective knowledge for a topic or subject area (Laboratory, Pharmacy, etc.)from which all RMIMs in that business topic are properly derived, to an approach where the DMIM is more general (realistically a representation of the RIM). Then RMIMs are templates which are applied to define constraints. One of the new key principles of this approach is that successive templates are applied to the DMIM, each which adds business context.

• with order constraints? (some like this approach)
• without order constraints? (others like this approach)

What does it mean to use the RIM or a barely constrained version of the RIM as the composite order as a DMIM?

OO asserts that Composite Order is a high-level template. In this case, we define template as a set of definitions which are constraints on the parent model for the core data. However, the 'edge' of the template (scope) of the template at this level is up for discussion. In composite order template, do we use any CMETs? What is the edge or scope (can that be implied by the need for a CMET)? Specifically the composite order template is a common set of classes, common to all requests for healthcare services. Specialized classes are not included in this template; and subject areas are expected to create specialized, topic and business-specific templates which define exact information content and constraints for a specific triggering action.

For example, there is a DMIM model for common product model. CPM is then constrained and used by Pharmacy, for example. So for composite order, do we 'reference' the CPM? do we put in a CPM 'stub'?

Further to this approach, the domain-specific model/template is then used to specify and define the model exactly for that domain's usage. The domain-specific model is a properly constraint on those higher-level templates as 'joined' in a large logical model (elaborate the stubs or references).

Proposed Characteristics and Design Principles for Composite Order (by Austin Kreisler)

There were inspired by the characteristics associated with CDA R2.

• Characteristics of an Order
  • Context – An order establishes the default context for its contents. Context includes, but is not limited to author, subject, record target, verifier and transcriber.
  • Verifiable – 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).
• Design Principles for Orders
  • The work-flow associated with the management of an order must be kept distinct from the details of the order itself. Work-flow action is separate from the underlying activity being ordered. Order work-flow is focused on managing custodianship, verification status, fulfillment status, action-ability and state of the order.
    • Maintaining a clean separation between work-flow and order detail allows clinical documents (CDA) to focus on conveying order detail without entanglement of work-flow. It also clearly means that documents are not being used to convey work-flow for orders.
    • This also allows services to be defined that manage order work-flow vs. order detail.
  • Work-flow of an order is associated with its own context (i.e., author of a work-flow step, subject of the work-flow step, etc.) which must be kept distinct from the default context of an order (i.e., the order author, subject, etc.).

Edges

What are the edges?

CMET

Stub

Reference Is a change is tack; but it was asserted (conceptually) to build a v3 ORC-ish

Leave off the edges

Choice box

Links

Open Composite Order Vocab Items