hl7 version 3 domain analysis model: laboratory orders ...draft standard for trial use . december...

Laboratory Order Conceptual Specification r1 December 2013 © 2013 Health Level Seven International. All rights reserved.

V3DAM_LABORD_DSTU_R1_2013DEC

HL7 Version 3 Domain Analysis Model: Laboratory Orders, Release 1

Draft Standard for Trial Use December 2013

Publication of this draft standard for trial use and comment has been approved by Health Level Seven International (HL7). This draft standard is not an accredited American National Standard. The comment period for use of this draft standard shall end 24 months from the date of publication. Suggestions for revision should be submitted at http://www.hl7.org/dstucomments/index.cfm.

Following this 24 month evaluation period, this draft standard, revised as necessary, will be submitted to a normative ballot in preparation for approval by ANSI as an American National Standard. Implementations of this draft standard shall be viable throughout the normative ballot process and for up to six months after publication of the relevant normative standard.

Copyright © 2013 Health Level Seven International ® ALL RIGHTS RESERVED. The reproduction of this material in any form is strictly forbidden without the written permission of the publisher. HL7 International and Health Level Seven are registered trademarks of Health Level Seven International. Reg. U.S. Pat & TM Off.

http://www.hl7.org/dstucomments/index.cfm

Laboratory Order Conceptual Specification r1 © 2013 Health Level Seven International. All rights reserved. December 2013

IMPORTANT NOTES: HL7 licenses its standards and select IP free of charge. If you did not acquire a free license from HL7 for this document, you are not authorized to access or make any use of it. To obtain a free license, please visit http://www.HL7.org/implement/standards/index.cfm. If you are the individual that obtained the license for this HL7 Standard, specification or other freely licensed work (in each and every instance "Specified Material"), the following describes the permitted uses of the Material. A. HL7 INDIVIDUAL, STUDENT AND HEALTH PROFESSIONAL MEMBERS, who register and agree to the terms of HL7’s license, are authorized, without additional charge, to read, and to use Specified Material to develop and sell products and services that implement, but do not directly incorporate, the Specified Material in whole or in part without paying license fees to HL7. INDIVIDUAL, STUDENT AND HEALTH PROFESSIONAL MEMBERS wishing to incorporate additional items of Special Material in whole or part, into products and services, or to enjoy additional authorizations granted to HL7 ORGANIZATIONAL MEMBERS as noted below, must become ORGANIZATIONAL MEMBERS of HL7. B. HL7 ORGANIZATION MEMBERS, who register and agree to the terms of HL7's License, are authorized, without additional charge, on a perpetual (except as provided for in the full license terms governing the Material), non-exclusive and worldwide basis, the right to (a) download, copy (for internal purposes only) and share this Material with your employees and consultants for study purposes, and (b) utilize the Material for the purpose of developing, making, having made, using, marketing, importing, offering to sell or license, and selling or licensing, and to otherwise distribute, Compliant Products, in all cases subject to the conditions set forth in this Agreement and any relevant patent and other intellectual property rights of third parties (which may include members of HL7). No other license, sublicense, or other rights of any kind are granted under this Agreement. C. NON-MEMBERS, who register and agree to the terms of HL7’s IP policy for Specified Material, are authorized, without additional charge, to read and use the Specified Material for evaluating whether to implement, or in implementing, the Specified Material, and to use Specified Material to develop and sell products and services that implement, but do not directly incorporate, the Specified Material in whole or in part. NON-MEMBERS wishing to incorporate additional items of Specified Material in whole or part, into products and services, or to enjoy the additional authorizations granted to HL7 ORGANIZATIONAL MEMBERS, as noted above, must become ORGANIZATIONAL MEMBERS of HL7. Please see http://www.HL7.org/legal/ippolicy.cfm for the full license terms governing the Material.

http://www.hl7.org/implement/standards/index.cfm

http://www.hl7.org/legal/ippolicy.cfm


Acknowledgments Orders and Observations Work Group Co-Chairs: Hans Buitendijk, Siemens Healthcare Lorraine Constable, Constable Consulting Inc. Patrick Loyd, ICode Solutions Robert Hausam MD, Hausam Consulting Ken McCaslin, Quest Diagnostics, Incorporated Modeling / Project Facilitators: Patrick Loyd, ICode Solutions Lorraine Constable, Constable Consulting Inc. Publishing Facilitator: Patrick Loyd, ICode Solutions


Table of Contents 1 Executive Summary ......................................................................................................... 6 2 Business Model Conceptual Artifacts ........................................................................ 6

2.1 Business Context........................................................................................................ 6 2.2 Business Function ..................................................................................................... 6

2.2.1 Basic business process use case bubble diagram ................................... 7 2.3 Conceptual Roles ........................................................................................................ 8 2.4 Processes ....................................................................................................................... 9

2.4.1 Business Process ................................................................................................. 9 2.4.2 Laboratory Business Process .......................................................................... 9 2.4.3 Laboratory Business Process Assumptions ............................................. 10 2.4.4 Laboratory Business Process Workflow ..................................................... 10 2.4.5 Laboratory Business Process Workflow Narratives ............................... 11 2.4.6 Process - Create Laboratory Order .............................................................. 11 2.4.7 Change Laboratory Order - Process ............................................................ 16

3 Information Model Conceptual Artifacts ................................................................. 19 3.1 Conceptual Information Model ............................................................................ 19 3.2 Conceptual Data Types Model ............................................................................. 20 3.3 Conceptual State Model ......................................................................................... 20 3.4 Concept Domains ..................................................................................................... 24

4 Solution Specification .................................................................................................... 24 4.1 Computational Viewpoint ...................................................................................... 24

4.1.1 Overview ............................................................................................................... 24 4.1.2 Contract Roles and Agents............................................................................. 25 4.1.3 Scenario 1 - Create Lab Order ...................................................................... 27 4.1.4 Scenario 2 - Change Lab Order .................................................................... 28 4.1.5 Scenario 3 - Cancel Lab Order ..................................................................... 29

4.2 Contractual Semantics and Issues ..................................................................... 29 4.2.1 Conformance Assertions ................................................................................. 30

5 Computational Services ................................................................................................ 30 5.1 Order Manager .......................................................................................................... 30

5.1.1 Service Description and Purpose ................................................................. 30 5.1.2 Scope ..................................................................................................................... 30 5.1.3 Reason why the service is necessary .......................................................... 31 5.1.4 Structure of the Service .................................................................................. 31 5.1.5 Assumptions and Dependencies .................................................................. 32 5.1.6 Implementation Considerations ................................................................... 33 5.1.7 Detailed Functional Model for Each Operation ....................................... 33 5.1.8 Profiles .................................................................................................................. 37 5.1.9 Recommendations for Conformance and Compliance .......................... 37

5.2 Fulfillment Manager ................................................................................................ 37 5.2.1 Service Description and Purpose ................................................................. 37 5.2.2 Scope ..................................................................................................................... 38 5.2.3 Reason why the service is necessary .......................................................... 38 5.2.4 Structure of the Service .................................................................................. 38


5.2.5 Assumptions and Dependencies .................................................................. 39 5.2.6 Implementation Considerations ................................................................... 39 5.2.7 Detailed Functional Model for Each Operation ....................................... 39 5.2.8 Profiles .................................................................................................................. 42 5.2.9 Recommendations for Conformance and Compliance .......................... 42


1 Executive Summary • This document contains the necessary definitions, descriptions, graphics, and

artifacts relevant to the specification of electronic request for healthcare services between an ordering provider and a performing laboratory. In this document, laboratory testing refers to the collection, processing, and analysis of specimens.

2 Business Model Conceptual Artifacts 2.1 Business Context

• The laboratory domain comprises the models, messages, and other artifacts that are needed to support messaging related to laboratory tests, or observations.

• The HL7 Laboratory domain includes the provision and use of analytic services in areas such as chemistry, hematology, serology, histology, cytology, anatomic pathology, microbiology, and virology. It does not include blood bank or blood transfusion services. (Note that not all lab specializations will be supported in this first HL7 V3 R1 of the Laboratory Request Topic.)

• Analytic services typically result in observations returned to the order placer and/or added to the patient medical history. Observations may be simple numeric quantitative measurements, such as a blood serum glucose level, qualitative measurements such as micro-organism susceptibility to a particular antibiotic, or complex diagnostic pathology reports.

• Services may be delivered/executed at a external lab, an on-site lab, or at the point of care. This topic covers service requests from all locations, including bedside and in-hospital, clinic and outpatient, and lab-to-lab interactions. It includes orders accompanied by specimens to be analyzed, as well as orders for which the performing laboratory is responsible for obtaining the specimens. Observations (results) may be generated for both ordered and unordered (e.g., POC) tests.

• Workflow includes ability of performing laboratory to accept, modify, or reject an order, with an appropriate indication sent back to the orderer. Modification may include breaking a parent order into child orders or work items.

2.2 Business Function For this specification, the business function at its most basic is about ordering (requesting a healthcare service) and the fulfillment of that request by filling entities.


2.2.1 Basic business process use case bubble diagram

The following bubble diagram describes the ordering business process.

dm Specimen Laboratory Manage Orders

Manage Orders - Subject

Manage Orders - Specimen

Read

Change

Create

Cancel

Fulfill

«include»

«include»

«include»

«include»

«include»


2.3 Conceptual Roles class Laboratory Order Actors

Specimen Collector

Prov ider

Subject

Laboratory Technician

Laboratory Medical Director

Pathologist

Ordering System

Laboratory Information

System

Role which represents an entity seeking healthcare services or the entity from which a specimen was obtained. For most care settings, this is a patient. For public health, subject is a more apt descriptor.

For Surgical/Anatomic/Cyto- Pathology and Laboratory testing, the pathologist is responsible for the observation of specimen pieces/parts and clinical interpretation of those observations and other laboratory results.

Role which provides some type of added value to healthcare services. This includes the care providers as well as non-care providers.

Any computer system at the Provider's Point-of-Care used to capture and exchange healthcare information.

Any computer system in the Laboratory used to capture and exchange Laboratory information.

Specimen

Role representing any material obtained from a subject for the purpose of laboratory testing.

Role for the human(s) who collects the specimen from the subject.

Role for the persons who perform or are responsible for the testing processes on the specimen and document the outcomes..

Role for the Medical Director of the Laboratory. This is regulatory information necessary in the US realm.

Patient

Role which indicates a subject who is specifically a patient (context of patient care and not the public health context)

Specimen Collector System

System that manages collection of specimen and data exchange

Laboratory Order Repository

Any system to which lab orders are sent and which both ordering systems and fulfi l l ing systems (in this case, Laboratory) have access.

Laboratory

The organization or department (part of an organization) which conducts specimen testing, analysis, and results documentation in fulfi l lment of requests for healthcare services.

Ordering Organization

Organization or department (part of an organization) requesting healthcare services fora subject/patient.

Specimen Collector Organization

Organization or department (could be the laboratory itself) which collects appropriate specimen(s) depending on the order(s).

Laboratory Repository

Organization

Organization or department (part of an organization) that maintains a regional repository of laboratory order information.


2.4 Processes 2.4.1 Business Process

At its most basic, the business process documented in this use case is one of a requested service and documentation when that service is performed. Many ambulatory use cases follow this basic pattern and the only communications are the two, the first from placer to filler with the request and the second from the filler to the placer with the fulfillment of that request. Conversely in acute care settings, the business process for laboratory specimen testing is quite rich as the order placer and laboratory perform more electronic exchanges, usually centered around specimen collection.

2.4.2 Laboratory Business Process

For Laboratory Diagnostics (specimen testing), the following illustrates high-level business functions:

1. Diagnostic (or Public Health) Specimen-based Laboratory work requested for a subject (e.g., patient, animal, environmental)

2. Specimen collected from subject 3. Specimen accessioned by the Laboratory (i.e., enters lab testing process) 4. Laboratory sometimes communicates an intent to perform the work requested 5. Specimen processed into testable samples, tested, and analyzed 6. Results from lab testing interpreted, documented, formatted,

approved/authorized 7. Laboratory sometimes formats the results as a report 8. Results returned to requester 9. Requester determines if all requests have been fulfilled, next steps and course of

action

http://wiki.hl7.org/index.php?title=File:LaboratoryOrderConceptualEventFlow.png�


From which a set of concepts representing the state or status of a laboratory order can be derived.

2.4.3 Laboratory Business Process Assumptions

While the above list shows the performed steps in a basic lab ordering/fulfillment process, each of these steps may be performed by different actors/roles in any one specific process; for example, a Clinician, Laboratory Technician (e.g., phlebotomist), Investigation Team Member, the Subject (patient), or a person responsible for a Subject may collect the specimen. In addition, the steps may be performed at different locations; specimens may be collected at the point of care, at the subject's location (e.g., at a patient's home, "in the field", etc), in the testing lab, or at a specimen collection organization. The steps may also be performed in different order or not performed at all under given, specific conditions - a specimen may not require any processing prior to being tested or a specimen is assigned an accession number prior to being collected if it is being collected in the lab.

Finally, the involvement of an electronic system to capture the information and facilitate the business process is assumed in the above steps and must be present depending upon the conditions under which each step is performed. All step-specific conditions and event-specific conditions are documented in the process-specific section of this specification. Note that this specification is for interoperability between electronic systems; manual processes are documented as they relate to information exchange and are ignored otherwise.

2.4.4 Laboratory Business Process Workflow

http://wiki.hl7.org/index.php?title=File:LaboratoryOrderProcessConceptualStateMachine.png�


The business process documentation above describes the generic steps in the performance of a request for laboratory services. This view of the laboratory business has another dimension which is a further specialization of the concept of the request. That specialization, sometimes referred to as workflow event, further clarifies whether the request is for a new service (not having been communicated bewteen systems previously); or if this request is a 'request to change' an order previously submitted and communicated; or a request to cancel.

2.4.5 Laboratory Business Process Workflow Narratives

The following are the in-scope business workflow-specific processes:

• Create Laboratory Order • Change Laboratory Order • Cancel Laboratory Order • Query Laboratory Orders

2.4.6 Process - Create Laboratory Order 2.4.6.1 Process Storyboards - Create Laboratory Order 2.4.6.1.1 Storyboard (Universal) - Create Lab Order (Lab Collect)

Eve Everywoman, a 27-year-old female, presents at Good Health Hospital Outpatient Clinic and is seen by Dr. Patricia Primary. Eve reports a history of Anemia and recent, excessive tiredness. Dr. Primary enters a request to check the iron levels in Eve’s blood into her care system. Dr. Primary’s care system then sends the test requests to the lab system at the Good Health Hospital’s Laboratory service. Eve receives a paper order requisition that serves as a reminder, provides instructions for where to find the collection center, and also details preparation instructions for the patient to follow (no food or drink from midnight until collection time on the day of collection). Later that week Eve presents herself at the Lab Collection Center. The lab looks up and finds the order for her testing in the lab system. The appropriate blood samples are extracted, their containers labeled, and the sample information added to the information in the lab system. The lab performs the analysis on the specimen(s), enters the results to the lab system, and sends the results to Dr. Primary’s care system reported as final. Dr. Primary reviews the results, formulates a treatment, if needed, and notifies Eve Everywoman of the results and treatment.

2.4.6.1.2 Storyboard (Universal) - Create Lab Order (Provider Collect)

Adam Everyman, a 53-year-old male, has an appointment with Dr. Carl Cardiology at Good Health Hospital Outpatient Clinic. Adam reports a history of Anemia and recent, excessive tiredness. Dr. Cardiology enters a request to check the iron levels in Adam’s blood into his care system. Dr. Cardiology’s care system then sends the test requests to the lab system at the Good Health Hospital’s Laboratory service. Dr. Cardiology’s staff collects the necessary specimen(s), labels them, packages them and ships them to the laboratory. The lab receives the specimen(s) and accessions each. Specimen is evaluated for use by the Laboratory Technician. Next, an analysis is performed on the specimen(s), the results are added to the lab system and QA'ed as appropriate. Upon completion of QA, the results are structured as


a report document using CDA. The report is then sent to Dr. Cardiology’s care system reported as final. Dr. Cardiology reviews the results, formulates a treatment, if needed, and notifies Adam Everyman of the results and any follow-up treatment.

2.4.6.1.3 Storyboard (Universal) - Create Lab Order (3rd Party Collect)

There are, in many scenarios, services separate from the provider or lab who travel each patient in order to perform specimen collection.

Eve Everywoman, a 27-year-old female, presents at Good Health Hospital Outpatient Clinic and is seen by Dr. Patricia Primary. Eve reports a history of Anemia and recent, excessive tiredness. Dr. Primary enters a request to check the iron levels in Eve’s blood into her care system. Dr. Primary’s care system then sends the test requests to the lab system at the Good Health Hospital’s Laboratory service. Eve receives a paper order requisition that serves as a reminder, provides instructions for where to find the collection center, and also details preparation instructions for the patient to follow (no food or drink from midnight until collection time on the day of collection). Later that week Eve calls a 3rd Party collection service. The service looks up and finds the order for her testing in the regional repository. The 3rd party collector then travels to the patient location. The appropriate blood samples are extracted, their containers labeled, and the sample information added to the information in the repository. The lab receives the specimen(s) and accessions each. Specimen is evaluated for use by the Laboratory Technician. Next, an analysis is performed on the specimen(s), the results are added to the lab system and QA'ed as appropriate. The lab performs the analysis on the specimen(s), adds the results to the lab system, and sends the results to Dr. Primary’s care system reported as final. Dr. Primary reviews the results, formulates a treatment, if needed, and notifies Eve Everywoman of the results and follow-up treatment.

2.4.6.2 Process Description - Create Laboratory Order

Patient Presents. Provider observes, measures, evaluates, and analyzes patient, then orders specimen-based diagnostic testing. Specimen is collected. Specimen is accessioned, tested, analyzed. Results of testing are documented, formatted, approved. Results sent to original requestor.

2.4.6.3 Process Actors - Create Laboratory Order

Primary/Secondary Human/System Name Description

Primary Human/Non-Human Subject/Patient

Role which represents one of:

• 1) an entity seeking healthcare services, or

• 2) an entity from which a specimen was obtained. For most care settings, this is a patient. For public health, subject is a


more apt descriptor, or • 3) an entity existing in

healthcare for which administrative tasks are performed (e.g. cleaning a patient room)

Primary Human Provider

Role which provides some type of added value to healthcare services. This includes the care providers as well as non-care providers.

Primary System Ordering System

Any computer system at the Provider's Point-of-Care used to capture and exchange healthcare information.

Primary Human Specimen

Role representing any material obtained from a subject for the purpose of laboratory testing.

Primary System Laboratory Information System

Any computer system in the Laboratory used to capture and exchange Laboratory information.

Primary Human Laboratory Technician

Role for the persons who perform the testing processes on the specimen and document the outcomes.

2.4.6.4 Process Scope - Create Laboratory Order

A healthcare provider needs specimen-based diagnostic testing on a patient. This is the initial request; no request has previously been communicated for the same service at the same date/time.

2.4.6.5 Process Event Flow - Create Laboratory Order

Below is the event flow for Create Laboratory Order which defines the necessary activities, decisions, and information exchange points. The Laboratory Order Repository needed for the 3rd storyboard above is handled via an alternate flow and is not represented in the diagram below.


http://wiki.hl7.org/index.php?title=File:CreateLaboratoryOrderEventFlow.png�


2.4.6.6 Process Alternate Flows - Create Laboratory Order

• Alternate Flow 1 o Description: Order Repository o In order to deploy ordering to a region, vs. a single facility or set of

facilities, an architecture which includes a repository is common. This alternate flow includes the deltas from the main flow to accomodate changes necessary to the workflows when a regional order repository is used.

o Details: TBD next version • Alternate Flow 2

o Description: Specimen Problems not resulted o If the specimen has been determined to be unsuitable for testing, the

performing laboratory contacts the ordering provider. It is a current assumption of this use case that the communication of unsuitable specimen(s) is performed using a result.

o Details: TBD next version

2.4.6.7 Process Pre-Conditions - Create Laboratory Order

• User has create functionality and permissions

2.4.6.8 Process Post-Conditions - Create Laboratory Order

Laboratory order requestor (placer) is satisfied that the laboratory performed the tests as requested within the current conditions and has documented and communicated those results to the order requestor.

2.4.6.9 Process Special Requirements - Create Laboratory Order

None identified.

2.4.6.10 Process Extension Points - Create Laboratory Order

None identified.

2.4.6.11 Process Business Rules - Create Laboratory Order

Order can't be created without a subject.

Orders are placed with labs that can perform those orders (not all labs can perform all tests).


2.4.7 Change Laboratory Order - Process 2.4.7.1 Universal Storyboard - Change Lab Order (Provider Collect)

Adam Everyman, a 53-year-old male, has an appointment with Dr. Carl Cardiology at Good Health Hospital Outpatient Clinic. Adam reports a history of Anemia and recent, excessive tiredness. Dr. Cardiology enters a request to check the iron levels in Adam’s blood into his care system. Dr. Cardiology’s care system then sends the test requests to the lab system at the Good Health Hospital’s Laboratory service. Dr. Cardiology’s staff collects the necessary specimen(s), labels them, packages them and ships them to the laboratory. The next day during a review of Adam's chart, Dr. Cardiology determines that he needs to order an additional test. Dr. Cardiology or his staff updates their local system to change (revise/modify) the order which is then communicated to the lab system. Since the specimen was already sent to the lab, the staff then contacts the lab to ensure they are aware of the requested change. The lab receives the specimen(s) and accessions each. Specimen is evaluated for use by the Laboratory Technician and whether there is adequate volume of suitable specimen to accomodate the additional tests. There is sufficient specimen: therefore, analysis is performed on the specimen(s); the results are added to the lab system and QA'ed as appropriate. Upon completion of QA, the results are structured as a report document using CDA. The report is then sent to Dr. Cardiology’s care system reported as final. Dr. Cardiology reviews the results, formulates a treatment, if needed, and notifies Adam Everyman of the results and any follow-up treatment.


2.4.7.2 Change Laboratory Order Event Flows

Next is the event flow for Change Laboratory Order. Note that any change is a 'request to change'. Depending on the situation, the performing laboratory may reject the change.

http://wiki.hl7.org/index.php?title=File:ChangeLaboratoryOrderEventFlow.png�


2.4.7.3 Cancel Laboratory Order Event Flows

Next is the event flow for Cancel Laboratory Order. Note that any cancel is a 'request to cancel'. Depending on circumstances, the test may be able to be cancelled up to the point that the test is resulted.

act Cancel Laboratory Order

Patient:Subject Provider:Provider Provider POS System:Ordering System Phlebotomist:Specimen Collector Laboratory POS System:Specimen Collector System Laboratory:Laboratory Technician Laboratory System:Laboratory Information System

3.1 Prov ider Enters Request into POS

2.7 Prov ider Contacts Lab Regarding Request to Cancel

6.1 Lab Receiv es Specimen

7.2 Push ElectronicConnectivity fromOrderer

7.3 Query for Lab Order3.6 Respond to Lab

Order Query

6.2 Ev aluate Specimen suitability for testing

7.4 Notify Specimen Collector and/or Ordering Prov ider

6.5 Testing Performed (Measure, Analyze,

Categorize, Interpret)

7.6 Push Result orSend Notification

7.7 Send Results to Provider

3.8 Receive Results from Lab

7.8 Notify Provider - Results Available

3.9 All Expected Results Receiv ed

2.5 Receive Notification

2.6 Query Results7.9 Result Query

Response

0.9 All ResultsReceived,OrderComplete

Name: Cancel Laboratory OrderAuthor: PatrickVersion: 1.0Created: 9/9/2012 7:14:47 AMUpdated: 9/12/2012 6:55:42 AM

6.4 Lab Accessions Specimen

6.6 Document and Format Result

2.4 Notifcation to Prov ider

0.3 Cancel Lab Order

2.10 Request to Cancel an Order

3.10 Specimen(s)Collected By - Cancel

2.11 Order Cancelled

4.11 Specimen AlreadyCollected - Cancel

6.3 SpecimenSuitable for Order

3.4 Push ElectronicConnectivity to Lab

3.12 Send Request to Cancel to Lab

7.10 Receive Request to Cancel

Yes

NoNo

No

Yes

No

Yes


3 Information Model Conceptual Artifacts 3.1 Conceptual Information Model The following classes were derived from the storyboards and use cases.

http://wiki.hl7.org/index.php?title=File:Conceptual_Laboratory_Information_Objects.png�


3.2 Conceptual Data Types Model The following conceptual data types are referenced from the information model

3.3 Conceptual State Model There are a couple of different types of state models. The first is representing the status of the whole business process. The states are represented as statuses which correlate to Key activities on the event flow. The second are a set of state models, one for each Key information object, defining the appropriate statuses for each object.

http://wiki.hl7.org/index.php?title=File:ConceptualDatatypes.png�


For the business process state machine:

An order is 'resulted' status is when a placer has received a result from a fulfiller based on a prior order; the action is one taken by the placer to evaluate whether the result indeed fulfills the original order. We can derive the following request object states and transitions from the above storyboards:

http://wiki.hl7.org/index.php?title=File:LaboratoryOrderProcessConceptualStateMachine.png�


In the Lab Order conceptual State Machine, notice that the request object has a status for when the fulfiller asserts the request is fulfilled, but the request has not yet evaluated that assertion (called fulfillment resolution). There are also the two other, expected, request statuses: active and complete. In the simplest request use cases, the request only takes one of these states. We can derive the following fulfillment object states and transitions from the storyboard:

http://wiki.hl7.org/index.php?title=File:LaboratoryOrderSTM.png�


Again the status, this time for fulfillment, is restricted in this simplest use case to null and resulted.

Lastly for this simple use case, we can derive the following result object states and transitions from the storyboard:

http://wiki.hl7.org/index.php?title=File:FulfillmentLiteSTM.PNG�


In this use case, only the completed state is important for interoperability.

3.4 Concept Domains • ActStatus • LaboratoryOrderableTestCode • LaboratoryQualitativeResultValue • DocumentTypeCode

4 Solution Specification 4.1 Computational Viewpoint 4.1.1 Overview 4.1.1.1 Business Scenario

The event flow for a simple lab order formed the input for the interactions and contract roles described here.

http://wiki.hl7.org/index.php?title=File:ResulttLiteSTM.PNG�


4.1.2 Contract Roles and Agents

The parties supporting this process are the Order Manager and Fulfillment Manager, depicted below. Specimen collection is a constrained profile of Order Management. As described in the event flows above, the Specimen Collection role may be performed by the Provider, the Lab or a third party specimen collector.

System Actors from the storyboards above may implement one or more contract roles

http://wiki.hl7.org/index.php?title=File:ConceptualContractInterfaces.png�


http://wiki.hl7.org/index.php?title=File:ActorContractRole.png�

4.1.3 Scenario 1 - Create Lab Order

The following sequence diagram depicts the interactions that support the Create Lab Order event flow

http://wiki.hl7.org/index.php?title=File:CreateLabOrderSequence.png�

Laboratory Order Conceptual Specification R1 © 2013 Health Level Seven International. All rights reserved. December 2013

4.1.4 Scenario 2 - Change Lab Order

The following sequence diagram depicts the interactions that support the Change Lab Order event flow. The specimen collection step is optional, as it may have already occurred when the change request begins.

http://wiki.hl7.org/index.php?title=File:ChangeLabOrderSequence.png�


4.1.5 Scenario 3 - Cancel Lab Order

The following sequence diagram depicts the interactions that support the Cancel Lab Order event flow. This scenario assumes that if the specimen is already collected, the order cannot be cancelled.

4.2 Contractual Semantics and Issues Conceptual conformance statements defined by this specification will be further refined at the logical and implementable levels. Conceptual conformance statements may require evaluation by humans rather than automated tests to confirm conformance.

• Contract roles define the operations that realize a specific set of accountabilities. Profiles on the contract roles defined subsets of operations that are intended to work together. Implementations claiming conformance to a specific profile must support all operations of that profile

• Information objects used in operations must conform to the defined static representations. The information classes will be further refined at the

http://wiki.hl7.org/index.php?title=File:CancelLabOrderSequence.png�


logical level based on the specification paradigm. For instance, for version 3 models, information structures will be represented by RMIMs.

• Services may be composed to support an unlimited number of interoperability scenarios. This specification describes representative business interaction scenarios, but does not attempt to limit conceivable interactions to those described. In particular, the scope of this specification focused on a simple lab order. More complex scenarios will result in more complex interaction patterns.

4.2.1 Conformance Assertions

• Each subject must be identified by an identifier that is unique within the namespace/assigning authority assigning the identifier.

• The minimal allowable steps of lab process are the request and the result. All other steps are optional

• Business states are not directly mappable to HL7 Act States - they are different state machines.

<note - this section is expected to elaborated further in future revisions of these artifacts>

5 Computational Services 5.1 Order Manager 5.1.1 Service Description and Purpose

The purpose of the order request manager is that of a service which provides functionality to manage requests for clinical services and access to the status of their fulfillment.

5.1.2 Scope

The Order Manager Service describes the communication patterns between members of a healthcare team that support request and fulfillment, and specifically those pertaining to the management and performance of a request for service(s). This order is considered separately from any process of fulfillment or reporting, except in terms of offering communications to support documentation as an ultimate result of an order request. Since these steps are common regardless of clinical service offered, they form a consistent pattern of behavior that may be applied in many situations. In so doing, the Order Manager Service distinguishes between the order for a lab test, the promise of fulfillment, and the lab test itself, which may have a different lifecycle or which may serve a broader audience. More specifically, the Order Manager is explicitly built to provide services for the initiators of the request and fulfillment pattern.


5.1.3 Reason why the service is necessary

The Order Manager Service provides a key integration component between systems involved in the distributed practice of patient-centric clinical care. It allows these various systems tied to clinical services to be decoupled from the requests for fulfillment that come from healthcare practitioners. Organizations engaged across organizational boundaries that need to share the business processes around request and fulfillment can benefit from this boundary, as well as more centrally controlled systems within a single jurisdiction. For example, the Order Manager Service enables a lab to operate completely independently from the Order Entry system, and for the clinical process to be managed completely separately from the financial management process that may happen in parallel. Additionally, this separation can happen at an institution or across several institutions or facilities.

In practice, this separation of concerns provides a clear boundary for the Order Manager's own capabilities. An order is typically accompanied by a set of expectations around the fulfillment of that order; one of which may be that the requester can expect the order management system to reliably capture the status of the eventual fulfillment. The Order Manager Service provides a specification of how this order request can be handled and several different configurations that support different means of systems communicating regarding the status of that request.

Note here that this service establishes expectations around the management of the order requests, and hides the details of the fulfillments of that request. Thus, a single order may generate multiple requests for promises of fulfillment, or one, or the Order Manager Service implementation may return a business error (“Request cannot be handled”). By the same token, fulfillment is managed separately as detailed in the Fulfillment Management (FM) Service. A complicated use case serves to demonstrate the flexibility of separating Order Management and Fulfillment Management in this way. For example, a promise of fulfillment may be generated without an initiating order. Separating the services support those sorts of behavioral patterns, but also allow policies to be enforced such that the promise of fulfillment requires an explicit order to be generated. In other words, these services support various policies and means of implementation without unduly binding them all together.

5.1.4 Structure of the Service

The Order Manager Conceptual Diagram is shown below. A separate functional profile is defined for organizations that need only specimen collection operations (for instance, third party specimen collectors).


5.1.5 Assumptions and Dependencies

The Order Manager is a part of an overarching Fulfillment Pattern that describes the contracts that must be implemented by all parties in order to manage the complex business process that underlie Orders and Observations. The Fulfillment Pattern is a choreographed behavioral specification that utilizes these profiles to provide support for key use cases in the Orders and Observations Process provisioned across multiple interfaces. The Fulfillment Pattern has the following components:

• The Order Manager Service, with its Order Request State Machine • At least one Fulfillment Management (FM) Service • The Fulfillment Behavioral Model, including Fulfillment Pattern’s State

Machine

The Order Manager, while deployed separately from these other components, fits within the Fulfillment Behavioral Model as the state of an Order Request may lead to subsequent Fulfillment Behavioral States. In addition, it likely requires the following components in a deployed architecture:

• A mechanism for identifying and resolving duplicate orders; • A unique identification scheme for requestors and trackers. For example,

the requestor of an order will require identification for security and auditing

http://wiki.hl7.org/index.php?title=File:OrderManagementConceptual.png�


concerns, and the order tracker will need a unique address for communication, such as email, application proxy, etc.

• A shared identification scheme for patients about whom orders are written. This shared scheme should be manifest to all clinical service components as well (labs, images, consults, etc.).

• [Optional] A Service Registry would provide authoritative listings of potential types of orders

Note however that Order Manager may be deployed without these other components as it effectively provides Order Manager clients with the core ability to manage their requests and to view a condensed view of fulfillment per se. That is often enough. In short, consumers of the Order Manager will need to have the ability to appropriately form requests and handle responses about them. This interaction with the Order Manager will preclude any explicit knowledge of the fulfillment of the Order itself via the service interface; that is, any knowledge of the fulfillment will happen through other mechanisms (policy, configuration, and so on).

5.1.6 Implementation Considerations

None at this time

5.1.7 Detailed Functional Model for Each Operation 5.1.7.1 Create Order

• Description: Allows the client to create an order for a service

• Pre-Conditions:

o The client has sufficient information to create the request o The client has permissions and authority to create a request within

the context • Conceptual Information Objects

o Inputs: Order o Outputs: Order

• Post-Conditions: The system has recorded the order information, assigned it an identifier, and is able to produce the order information for a requestor.

• Exception Conditions:

o None identified

• Aspects left for Technical Bindings (optional)

• Reference to Functional Profiles (optional)


• Notes

5.1.7.2 Change Order

• Description: Allows the client to submit a change to an existing Order.

• Pre-Conditions:

o An order exists and the identifier is known o The order is not completed o The user or requestor has permission to update an order

• Conceptual Information Objects o Inputs: Order, Order Identifier o Outputs: Order, Promise(optional)

• Post-Conditions:

o The order referenced by order identifier has been updated to match the requirements in the input order

o The modified order is returned


o Order is not known to the fulfiller o Order has already been completed



• Notes

5.1.7.3 Cancel Order

• Description: Used when a requestor (placer) would like for a previously requested, and not yet completed, order to not be performed.

• Pre-Conditions:


• Conceptual Information Objects o Inputs: Order, Order Identifier o Outputs: Order



o The order referenced by order identifier has been cancelled and will not be acted upon.

o The cancel order is returned


o Order is not known to the fulfiller o Order has already been completed o Order partially completed prior to receipt of cancel request

5.1.7.4 Query Orders

• Description: Used to obtain a list of Orders relevant to a specific Subject.

• Pre-Conditions:

• Conceptual Information Objects o Inputs: Subject o Outputs: a list of Orders

• Post-Conditions

• Exception Conditions



• Notes: o At the logical level, addition query criteria (eg date ranges, result

status, etc) may be defined

5.1.7.5 Retrieve Order

• Description: Allows the client to retrieve a specific Order, given an order identifier

• Pre-Conditions:

o The order identifier is known o The client has permission to retrieve orders

• Conceptual Information Objects o Inputs: Order Identifier


o Outputs: Order

• Post-Conditions




• Notes

5.1.7.6 Update Order Status

• Description: Allows the client to identify a change in status of the order (e.g. update the status to 'specimen collected')

• Pre-Conditions:

• Conceptual Information Objects o Inputs: Order Identifier, Status o Outputs: Order

• Post-Conditions: The order status has been changed to the new value

• Exception Conditions: The order identifier cannot be found. The status change request is an invalid state transition



• Notes

5.1.7.7 Update Result Status

• Description: Allows the fulfiller (or performer) of the order (whom is also the author of the result) to change the status of the result.

• Pre-Conditions:

o Result must already exist

• Conceptual Information Objects o Inputs: Result, Result Identifier o Outputs: Result


• Post-Conditions

o Result updated with new status

• Exception Conditions: Order does not previously exist



• Notes

5.1.8 Profiles

TBD

5.1.8.1 Introduction

TBD

5.1.8.2 Functional Profiles

TBD

5.1.8.3 Information Profiles

TBD

5.1.9 Recommendations for Conformance and Compliance

These will be elaborated in the next round of specification development

5.2 Fulfillment Manager 5.2.1 Service Description and Purpose

The Orders Fulfillment Service provides access to information regarding the fulfillment(s) of clinical services. It is separate and distinct from the actual capability services that:

• support clinical processes (including but not necessarily limited to Labs, Images, and Consults)

• the actual management of the Order Request itself


• the actual delivery of information obtained in clinical processes and ordered via Order Requests.

This service is leveraged by the Request and Fulfillment Interoperability Pattern. It provides a consistent means of integrating certain capabilities between the components of a dispersed healthcare team working with different infrastructures, systems, standards, and business processes.

5.2.2 Scope

The Order Fulfillment Service describes a number of discrete steps in managing the fulfillment portion between members of a healthcare team that support request and fulfillment. Since these steps are common regardless of clinical service offered, they help to form a consistent pattern of behavior that may be applied in many situations. In so doing, the OF Service distinguishes between the order for a lab test, the promise of fulfillment, and the lab test itself, which may have a different lifecycle or which may serve a broader audience.

5.2.3 Reason why the service is necessary

The Order Fulfillment Service provides a key integrating component between systems involved in the distributed practice of patient-centric clinical care. It allows various systems performing clinical services to negotiate the fulfillment of requests for those services. This in turn provides a decoupling for these systems from the business processes invoked by healthcare practitioners. This separation of concerns also provides a clear boundary not only for its own capabilities, but for organizations engaged across organizational boundaries that need to share the business processes around request and fulfillment. Thus, for example, the Order Fulfillment Service enables a lab to operate completely independently from the Order Request system, and for the management of the clinical process to be managed separately from the financial management process that may happen in parallel. Additionally, this separation can happen at an institution or across several institutions or facilities.

5.2.4 Structure of the Service

The Fulfillment Manager Conceptual Diagram is shown below. The variation on the RequestFulfillment return value reflects the business flow difference between ambulatory and in-patient labs - in ambulatory, there is no return value, where in-patient returns a Promise.


5.2.5 Assumptions and Dependencies

The Order Fulfillment Service represents a series of components that may participate in complex conversations between multiple actors dealing with the management of orders and the promises associated with them. In some cases, the number of actors is arbitrary, growing in response to real time business judgments that are made through either machine or human mediation that alter the nature of the order / promise relationship. The Order Fulfillment Service creates distinct boundaries between responsibilities using these components, providing encapsulation supporting ownership of orders and ownership of promises for fulfillment. Thus, while any given implementation may only provide a single functional profile, these various profiles are intended to work together to form an appropriate abstraction of the ordering process.

5.2.6 Implementation Considerations

TBD

5.2.7 Detailed Functional Model for Each Operation

5.2.7.1 Request Fulfillment

• Description: Allows an order manager to request fulfillment of an order • Pre-Conditions:

o The client has sufficient information to create the request o User or requestor has permissions to create a request within the

context • Conceptual Information Objects

o Inputs: Order o Outputs: Promise

http://wiki.hl7.org/index.php?title=File:FulfillmentManagementConceptual.png�



• Exception Conditions: None identified



• Notes

5.2.7.2 Communicate Result

• Description: Allows the fulfiller to communicate a result to the requestor. This is a conceptual operation representing the "push" of a result from the Fulfiller to the Orderer - at the logical level it would be represented by several operations based on the message exchange pattern.

• Pre-Conditions:

o A Result (preliminary or final) is available to be communicated to the orderer

• Conceptual Information Objects o Inputs: Result o Outputs: Code


o Result has been communicated and the receipt acknowledged




• Notes o This is a conceptual operation representing the "push" of a result

from the Fulfiller to the Orderer - at the logical level it would be represented by several operations based on the message exchange pattern.

5.2.7.3 Cancel Order


• Description: Used when a requestor (placer) would like for a previously requested, and not yet completed, order not to be performed.

• Pre-Conditions:


• Conceptual Information Objects o Inputs: Order, Order Identifier o Outputs: Order


o The order referenced by order identifier has been cancelled and will not be acted upon.

o The cancel order identifier is returned


o Order is not known to the fulfiller o Order has already been completed o Order partially completed prior to receipt of cancel request

5.2.7.4 Retrieve Result

• Description: Allows a requestor to retrieve a result from the fulfiller using the result identifier

• Pre-Conditions:

o The result identifier has been previously communicated to the fulfiller.

• Conceptual Information Objects o Inputs: Result Identifier o Outputs: Result

• Post-Conditions





• Notes

5.2.8 Profiles

TBD

5.2.8.1 Introduction

TBD

5.2.8.2 Functional Profiles

TBD

5.2.8.3 Information Profiles

TBD

5.2.9 Recommendations for Conformance and Compliance

These will be elaborated in the next round of specification development

hl7 version 3 domain analysis model: laboratory orders ...draft standard for trial use . december...

Documents