This wiki has undergone a migration to Confluence found Here
<meta name="googlebot" content="noindex">

Difference between revisions of "201601 LabOrderLabReport"

From HL7Wiki
Jump to navigation Jump to search
Line 87: Line 87:
 
*Support the receiving and processing of the ActionResponse/OrderResponse resource operations: history, read, search.
 
*Support the receiving and processing of the ActionResponse/OrderResponse resource operations: history, read, search.
  
===FHIR Client Fulfillment System/LIS ( Fulfillment Client)===
+
===FHIR Client Fulfillment Management Interface ( Fulfillment Client)===
 
(note: The Order Fulfillment Management Interface Client may be realized by various Actors as illustrated above)
 
(note: The Order Fulfillment Management Interface Client may be realized by various Actors as illustrated above)
 
*Create and retrieve the ActionResponse/OrderResponse resource using the defined basic CRUD operations: create, history, read, search, update and delete.
 
*Create and retrieve the ActionResponse/OrderResponse resource using the defined basic CRUD operations: create, history, read, search, update and delete.

Revision as of 19:34, 18 December 2015


Track Name

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.

  1. 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 a separate requests.
  2. clarify grouping of observations such as components vs related and diagnostic reports.
  3. Implement other Order and Observation resource 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 2106 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 resource have not been the topic of any Connectathon to date and need to be exposed to testing to help understand the issues and potential solution for request and workflow resources.
  • DiagnosticReport and Observation are FMM3 and would benefit from being the focus of Connectathon to help move them forward to FMM4 as well as identify issues surrounding nested grouping of observation for cases such as culture and 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

Skype: haas.eric1

Expected participants

Organization:

  • National/Regional Labs
  • LIS Vendors
  • EHR Vendors

Roles

See | Lab Order Conceptual Model] for details


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

ActorContractRole.png

NOTE: The Order Management Interface Client may be realized by various Actors as illustrated above. So either ordering or fulfillment systems might also choose to play the roll of order manager. The test steps listed below is one scenario.

FHIR Client Order Management Interface (Order Client)

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

FHIR Server Order Management Interface (Order Server)

(note: The Order Management Interface Server may be realized by various Actors as illustrated above)

  • Support the receiving and processing of the DiagnosticOrder resource operations: create, history, read, search and update.
  • Support the receiving and processing of the DiagnosticReport resource operations: history, read, search.
  • Support the receiving and processing of the Action/Order resource operations: create, history, read, search and update.
  • Support the receiving and processing of the ActionResponse/OrderResponse resource operations: history, read, search.

FHIR Client Fulfillment Management Interface ( Fulfillment Client)

(note: The Order Fulfillment Management Interface Client may be realized by various Actors as illustrated above)

  • Create and retrieve the ActionResponse/OrderResponse resource using the defined basic CRUD operations: create, history, read, search, update and delete.
  • Retrieve the Action/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 Server Fulfillment Management interface (Fulfillment Server)

(note: The Order Fulfillment Management Interface Server may be realized by various Actors as illustrated above)

  • Support the receiving and processing of the OrderResponse/ActionResponse resource operations: create, history, read, search and update.
  • Support the receiving and processing of the Order/Action resource operations: history, read, search
  • Support the receiving and processing of the DiagnosticOrder resource operations: update history, read, search
  • Support the receiving and processing of the DiagnosticReport resource operations: create, history, read, search and update.

Scenarios

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

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

FulfillmentLiteSTM.PNG

See | Lab Order Conceptual Model] for more details


Assumptions

Simplest Case:

  • This track is focusing on the transaction between the Ordering and Fulfillment System 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 Ordering and Fulfillment System is represented by a single 'Order+Fulfiller Server' with "virtual" roles (i.e. Order Management Server + Fulfillment System/LIS ) for this test case.
    • Other architectures such as a two server model are anticipated but will require modification of the test steps listed below.
  • This track will use either XML or JSON format. However, all the 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
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.

Step 1.1

Action: Order Client posts DiagnosticOrder to Order Server

Precondition: DiagnosticOrder does not exist in service prior to action

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

Step 1.2

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

Precondition: Order does not exist in Order Server prior to action

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

Step 1.3

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

Fulfillment 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)

>> note dependent on the Architecture: the Fulfillment Client may poll and order/fulfiller system instead assuming
a copy of the order was pushed to the filler side

Step 1.4

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

Precondition: OrderResponse does not exist in service prior to action

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

Step 1.5

Action: Order Client monitors Order 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 Order Server prior to action

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

Step 1.6

Action: Fulfillment Client posts DiagnosticReport to Order 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 Order Server. (use browser to inspect)

Step 1.7

Action: Fulfillment posts OrderResponse to Order manager pointing to DiagnosticReport and Order indicating they believe order is fulfilled

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

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

Step 1.8

Action: Order Client monitors Order 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: OrderResponse with status of 'completed' received stored. (use browser to inspect)

Step 1.9

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 1.10

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

Precondition: DiagnosticOrder exists in placer 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

FHIR tooling

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