Laboratory Order and Result

Submitting WG/Project/Implementer Group

Orders and Observations Working Group

Justification

Implementer need:

FHIR RESTful transactions for "request" resources such as DiagnosticOrder using the current FHIR workflow resources - Order(ActionRequest)and OrderResponse(ActionResponse) - are the main focus of DSTU 2.1 and the main focus of ongoing Workflow Discussions. This track seeks to gain further insite into what works and doesn't work with regard to them. Things like:
- Order with multiple components
- Need to update both Order and OrderResponse with the ability to identify the “activity types” within the overall order being requested/agreed to as well as the number of repetitions agreed to (e.g. cancel, change) are of particular interest.
DiagnosticOrder contains a recursive structure of event which is unlike any other request resource in FHIR. One question is whether this can be handled better as separate requests.
Clarify grouping of observations such as components vs related and diagnostic reports.
Implement other Order and Observation resources - including DiagnosticReport, Observation and Specimen.

Impact on ballot:

The OO workflow resources DiagnosticOrder, Order(ActionRequest), OrderResponse(ActionResponse) are the main focus of DSTU 2.1 and the 2016 Connectathon. For DiagnosticReport, Observation, and Specimen, any discovered issues as a result of the Connectathon would be balloted as part of DSTU 3.0 see Workflow Discussion

FMM readiness of the resources:

DiagnosticOrder, Order(ActionRequest) and OrderResponse(ActionResponse) are FMM 1 and FMM 0 respectively - see above for discussion on impact on ballot for these resources. These resources have not been the topic of any Connectathon to date and need to be exposed to testing to help understand the issues and potential solutions for request and workflow resources.

DiagnosticReport and Observation are FMM3 and would benefit from being the focus of a Connectathon to help move them forward to FMM4, as well as to identify issues surrounding nested grouping of observations for cases such as culture and susceptibility (sensitivity).

Specimen resource is FMM1 and has not been supported in any Connectathon. This is needed to uncover issues with this immature resource and help move it to FMM2

Proposed Track Lead

Eric M Haas DVM,MS

President Health eData Inc

Eric Haas

Track Skype Chat

The LabOrder Track has a Skype chat to coordinate preparation and participation in the track:

LabOrder Connectathon Channel

Expected participants

Organization:

National/Regional Labs
LIS Vendors
EHR Vendors

Roles

See | Lab Order Conceptual Model] for a detailed of roles and actors in lab ordering.

The Order Management and Fulfillment Management may be realized by various Actors. This is one simple scenario.

What does the EHR-S do?

An information system that receives, processes, and stores information related to the health and health care provided to patients.
As part of an EHR-S system, used by a Provider (Order Placer) to manage a laboratory order, including generating the laboratory requisition, sending it to a laboratory, and monitoring/tracking of the status of the laboratory order.
- Typically a laboratory order system is an integral part of an order management system that enables users to manage orders for many different types of services, procedures, supplies, etc. Since we only focus on data exchange relative to laboratory orders we are purposely using a very limited definition.
To meet the requirements of the the Use Case below the EHR-S, at minimum, must have the following characteristics:
- Data model that includes discrete representations of patients, clinician end-users, orgnizations, specimens, laboratory test requisitions/orders, laboratory tests (including panels), and laboratory test results (at the level of individual analytes), and specimens.
- Capability to interface with an LIS using the FHIR RESTful API.
- Capability to update the status and results of laboratory orders that have been ordered.

This definition is very minimal and omits many features and capabilities that are typically associated with Electronic Health Record systems. The minimal nature of the definition by no means excludes EHR-Ss with significantly greater capabilities.

What does the LIS do?

An information system that receives, processes, and stores information related to laboratory processes.
To meet the requirements of the the Use Case below the LIS, at minimum, must have the following characteristics:
- Data model that includes discrete representations of patients, clinician end-users, laboratory test requisitions/orders, laboratory tests (including panels), and laboratory test results (at the level of individual analytes), and specimens.
- Capability to interface with an EHR-S using the FHIR RESTful API.
- Capability to update the status and results of laboratory tests that have been ordered.

This definition is very minimal and omits many features and capabilities that are typically associated with laboratory information systems. The minimal nature of the definition by no means excludes LIS with significantly greater capabilities.

What FHIR resources does the EHR-S use to do the above things?

Patient
Provider
Organization
Specimen
Diagnostic Order
Order

What FHIR resources does the LIS use to do the above things?

Organization
Practitioner
OrderResponse
DiagnosticReport
Specimen
Observation

Who is the client and who is the server and what functions do they they need to offer?

EHR-S would be either client or server, or both depending on the function
- EHR Client functions:
  - Create and retrieve and update the DiagnosticOrder resource
  - Create and retrieve and update the Order resource
  - Retrieve the OrderResponse resource
    - Capability to check for updates to OrderResponse -- e.g. polling
  - Retrieve the DiagnosticReport resource and resources referenced by it - Observation, Specimen, Patient, Provider, and Organization

LIS would be either client or server, or both depending on the function
- LIS Client functions:
  - Retrieve the Order resource
  - Retrieve the DiagnosticOrder resource referenced by the Order and resources it references - Specimen, Patient, and Provider
  - Create and retrieve and update the OrderResponse resource
  - Create and retrieve and update the DiagnosticReportc and Observation resource(s)
Server functions:
- Whether there is a distinct EHR-S Server and LIS Server or a single Server filling both roles, at a minimum store the lab order and lab result resources listed above

GG's comments:

why does the EHR FHIR Client retrieve the DiagnosticReport resource? is this clinical time general access to diagnostic reports? or something more limited? EH: from a connectathon perspective to verify completion of order? Very broadly EHR-client could be Clinician UI?
is the idea that EHR would be either client or server, or both depending on the function? EH: I guess so not sure what you mean by both. the EHR pushes stuff to LIS and maintains/store own stuff.
why does the EHR FHIR Client read and create DiagnosticOrders? Doesn't it have them internally in it's own store, and just send them to the LIS when it wants to tell the LIS something has changed? EH: I set up the test steps to include creation of order, but yes could be stored as well and would not need this functionality
what does 'simple polling' mean? EH: me being pedantic since I just wanted to make a note of the need for some way to know when the was an update.
what about observations and clinical images? EH: Yes I omitted Observations, Specimen and patient and practitioner since they are all referenced in DR, images as attachments or binaries or imaging resources? ... kind of out of scope for my simple use case.

GG's comments:

I'm not sure why an EHR FHIR server should provide create, history, read, search, update. What is the functional outcome for doing these? Is it creating diagnosticOrders internally, and waiting for the LIS to poll for them? _EH: see changes only expectation is storage right now.
why is the server list of resources longer than the client list?
what about images? EH: above do you want to be in scope?

Scenarios

Test Case 1. Create Lab Order (Lab Collect) Simple Case

This is the simplest Case as shown in the diagram below:

See | Lab Order Conceptual Model] for more details

Generic Storyboard - Create Lab Order (Lab Collect)

Todd Lerr presents at Good Health Hospital Outpatient Clinic
and is seen by Dr. Leonard Blooddraw. Todd reports a history and Dr. Blooddraw 
enters a request into the care system which then sends the test requests to 
the lab system at the Acme Laboratory service.  Todd is provided instructions
for where to find the collection center.

Later, at the Lab Collection Center, the appropriate samples are 
collected and the sample information entered into the information
in the lab system. 

The lab performs the analysis on the specimen(s), enters the results into 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 teh patient of the results and
treatment.

Assumptions

Simplest Case:

>>Note: Order/OrderResponse are also known as the ActionResponse/ActionRequest resources

This track is focusing on the transaction between the EHR and LIS using FHIR RESTful API, testing the basic FHIR REST transactions, create, update, and read.
- For systems where a particular step is done in some other way than using FHIR RESTful approach.(For example step 1a be done by a non FHIR CPOE system.) verification of that step may need to be handled by some other method.
Resource Id can either be created by the client or the server (depending on the capability of the server). However, if the server assigns the Id, then the client will need to be able to retrieve the Id from the server response or by a query. However, all the resources are provided use client created ID.
The FHIR EHR and LIS Servers are represented by a single FHIR Server with 'virtual' roles (i.e. Order Server + Fulfillment Server) for this test case.
- Other architectures such as a two server model as pictured above are anticipated but will require modification of the test steps listed below.
This track will use either XML or JSON format. However, all the test resources are provided only in XML.
The specimen collection flow is out of scope.
A set of 4 tests "test catalog" is provided from which to order. Patient, Organization and Practitioners will be fixed (default). (see Testscripts Section below for source files):

Test Order Number	Description of Test	Specimen	Patient	Provider	Performer	Performing Organization
100	PT+INR	Platelet Free Plasma	Todd Lerr	Leonard Blooddraw	Gregory F House	Acme Labs
200	Blood Lead	Whole Blood	Todd Lerr	Leonard Blooddraw	Gregory F House	Acme Labs
300	CBC	Citrated Whole Blood	Todd Lerr	Leonard Blooddraw	Gregory F House	Acme Labs
400	Micro w/suscept	Stool	Todd Lerr	Leonard Blooddraw	Gregory F House	Acme Labs

Step 1 Order a new lab test

Step 1.1

Action: EHR Client posts DiagnosticOrder to Server

Precondition: DiagnosticOrder does not exist in service prior to action

Success Criteria: DiagnosticOrder created correctly on the server (use browser to inspect)

Step 1.2

Action: EHR Client posts Order containing a reference to DiagnosticOrder to the Server saying "Do this" (i.e. have a laboratory perform the test(s))

Precondition: Order does not exist in Server prior to action

Success Criteria: Order created correctly on the server (use browser to inspect)

Step 2 Accept new lab orders

Step 2.1

Action: LIS Client monitors server for Order resources (and changes to them) assigned to them via polling

LIS Client gets Order as part of query response

Success Criteria: Copy of Order along with reference to DiagnosticOrder received by Fulfillment Client as part of polling operation.(use client console to inspect)

Step 2.2

Action: LIS Client posts OrderResponse to Server referencing Order and agreeing to fulfill DiagnosticOrder

Precondition: OrderResponse does not exist in service prior to action

Success Criteria: OrderResponse created correctly on the server (use browser to inspect)

Step 2.3

Action: EHR Client monitors Server for OrderResponse resources pointing to Orders they own via polling. and gets OrderResponse as part of query response

Precondition OrderResponse does not exist in Server prior to action

Success Criteria: Copy of OrderResponse received by EHR Client as part of polling operation.(use client console to inspect)

Step 3 Fulfill Lab Order

Step 3.1

Action: LIS Client posts DiagnosticReport to Server referencing DiagnosticOrder

Precondition: DiagnosticReport, Observation and Specimen Resources created and stored in Server

Success Criteria: DiagnosticReport, Observation and Specimen Resources received and stored in Server. (use browser to inspect)

Step 3.2

Action: LIS Client posts OrderResponse referencing the DiagnosticReport and Order and indicating they believe order is fulfilled to the Server.

Precondition: DiagnosticReport, Observation and Specimen Resources created and stored in Server

Success Criteria: OrderResponse received stored. (use browser to inspect)

Step 4 Receive Lab Results

Step 4.1

Action: EHR Client monitors Server for OrderResponse resources pointing to Orders they own via polling. EHR Client gets 2nd OrderResponse as part of query.

Precondition: OrderResponse exist in Server with status of 'accepted' prior to action

Success Criteria: Copy of OrderResponse received by EHR Client as part of polling operation.(use client console to inspect)

Step 4.2

Action: EHR Client retrieves DiagnosticReport

Precondition: DiagnosticReport exists in Server with status of 'completed' prior to action

Success Criteria: Approporate DiagnosticReport with status of 'completed' received stored. (use browser to inspect)

Step 4.3

Action: EHR Client updates DiagnosticOrder to indicate they are completed.

Precondition: DiagnosticOrder exists in Server with status of 'requested' prior to action

Success Criteria: DiagnosticOrder with status of 'completed' received stored. (use browser to inspect)

Scenario 1 RoundTrip Success Criteria:

DiagnosticReport is appropriate for DiagnosticOrder - patient, order Id, test code matches

Scenario 1 Bonus point

replace polling with subscriptions, where Order and Fulfillment are clients and Order manager accepts subscriptions.
progression from preliminary to final to corrected results
composite order (todo)
update (cancel, revise) DiagnosticOrder
update (cancel, revise) Order

Help Links

Here are some links to assist implementers:

link to the HL7 Lab Order conceptual model

[Lab Order Conceptual Model]

Links to the FHIR Standard

FHIR tooling

David Hay's blog for additional information and discussion and a example FHIR client application for ordering
Rob Hausam's combined Order+Fulfiller test server for testing
Java client sample.
.net client sample.
Publicly Available FHIR Servers for testing.

TestScripts

The supporting TestScripts resources, corresponding test-case examples resources files, and test plan documents have been committed to the FHIR SVN repository at:

http://gforge.hl7.org/svn/fhir/trunk/connectathons/OrlandoJan2016/Connectathon11/Track7-LabOrderLabReport

>> Use an SVN browser such as Tortoise to view files

There are 4 TestScripts definitions - one for each original test order:

Test Order Number 100
Test Order Number 200
Test Order Number 300
Test Order Number 400

FHIR Resource ID Assigned by the Client, XML Format - Baseline DiagnosticOrder, Order, OrderRespone, DiagnosticReport, Observation, Specimen, Patient = Todd Lerr, Practitioner = Leonard BloodDraw, Practitioner = Gregory F House, Organization = Acme Labs to create, update, retrieve history and search with client assigned resource id.

>>todo add bonus testscripts

201601 LabOrderLabReport