201601 LabOrderLabReport

Laboratory Order and Result

Submitting WG/Project/Implementer Group

Orders and Observations Working Group

Justification

Implementer need:

1. 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.
2. 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.
3. Clarify grouping of observations such as components vs related and diagnostic reports.
4. 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.

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

EHR FHIR Client (Order Client)

• Create and retrieve the DiagnosticOrder resource using the defined basic CRUD operations: create, history, read, search, update and delete.
• Retrieve the DiagnosticReport resource using the defined basic CRUD operations: history, read, search,
• Create and retrieve the Order resource using the defined basic CRUD operations: create, history, read, search, update and delete.
• Retrieve the OrderResponse resource using the defined basic CRUD operations: history, read, search,
• support simple polling

EHR FHIR Server (Order Server)

• Support the receiving and storing of the DiagnosticOrder resource operations: create, history, read, search and update.
• Support the receiving and storing of the DiagnosticReport resource operations: history, read, search.
• Support the receiving and storing of the Order resource operations: create, history, read, search and update.
• Support the receiving and storing of the OrderResponse resource operations: history, read, search.
• Support the receiving and storing of the Observation resource operations: create, history, read, search and update.
• Support the receiving and storing of the Specimen resource operations: create, history, read, search and update.
• Support the receiving and storing of the Patient resource operations: create, history, read, search and update.
• Support the receiving and storing of the Practitioner resource operations: create, history, read, search and update.
• Support the receiving and storing of the Organization resource operations: create, history, read, search and update.

LIS FHIR Client (Fulfillment Client)

• Create and retrieve the ActionResponse/OrderResponse resource using the defined basic CRUD operations: create, history, read, search, update and delete.
• Retrieve the Order resource using the defined basic CRUD operations: history, read, search,
• Create and retrieve the DiagnosticReport resource using the defined basic CRUD operations: create, history, read, search, update and delete.
• Retrieve the DiagnosticOrder resource using the defined basic CRUD operations: history, read, search
• support simple polling

FHIR LIS Server (Fulfillment Server)

• Support the receiving and storing of the OrderResponse resource operations: create, history, read, search and update.
• Support the receiving and storing of the Order resource operations: history, read, search
• Support the receiving and storing of the DiagnosticOrder resource operations: update history, read, search
• Support the receiving and storing of the DiagnosticReport resource operations: create, history, read, search and update.
• Support the receiving and storing of the Observation resource operations: create, history, read, search and update.
• Support the receiving and storing of the Specimen resource operations: create, history, read, search and update.
• Support the receiving and storing of the Patient resource operations: create, history, read, search and update.
• Support the receiving and storing of the Practitioner resource operations: create, history, read, search and update.
• Support the receiving and storing of the Organization resource operations: create, history, read, search and update.

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:

• 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 'OM 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 OM 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 OM Server saying "Do this" (i.e. have a laboratory perform the test(s))

Precondition: Order does not exist in OM 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 OM 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 OM 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 OM 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 OM Server prior to action

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

Step 3 Fulfill Lab Order

Step 3.1

Action: Fulfillment Client posts DiagnosticReport to OM Server referencing DiagnosticOrder

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

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

Step 3.2

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

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

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

Step 4 Receive Lab Results

Step 4.1

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

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

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

Step 4.2

Action: Order Client retrieves DiagnosticReport

Precondition: DiagnosticReport exists in placer 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: Order Client updates DiagnosticOrder to indicate they are completed.

Precondition: DiagnosticOrder exists in OM 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.
• composite order (todo)
• update (cancel, revise) DiagnosticOrder
• progression from preliminary to final to corrected results

Help Links

Here are some links to assist implementers:

Links to the FHIR Standard

• REST API in the Specification.
• DiagnosticOrder resource in the Specification.
• Order resource in the Specification.
• OrderResponse resource in the Specification.
• DiagnosticReport resource in the Specification.
• DiagnosticObservation resource in the Specification.
• Specimen resource in the Specification.

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 list above.

FHIR Resource ID Assigned by the Client

• Test Order Number 100 -- 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