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 121: Line 121:
 
**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.
 
**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.
 
*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 System + Fulfillment Management System) for this test case.
+
*The Ordering and Fulfillment System is represented '''by a single 'OM Server'''' with "virtual" roles (i.e. Order Management System + Fulfillment Management System) for this test case.
 
**Other architectures such as a two server model are anticipated but will require modification of the test steps listed below.
 
**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.
 
*This track will use either XML or JSON format.  However, all the resources are provided only in XML.

Revision as of 19:48, 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 and Fulfillment Management 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 System (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 System (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 System ( 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 System (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 'OM Server' with "virtual" roles (i.e. Order Management System + Fulfillment Management System) 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 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: Order 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 1.3

Action: Fulfillment Client monitors OM 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)


Step 1.4

Action: Fulfillment 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 1.5

Action: Order 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 1.6

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 1.7

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 1.8

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

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