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

201601 LabOrderLabReport

From HL7Wiki
Jump to navigation Jump to search


Track Name

Laboratory Order and Result

Submitting WG/Project/Implementer Group

Orders and Observations Working Group (Service-oriented Architecture will support a component of this track)


Justification

Implementer need:

  1. The OO workflow resources Order(ActionRequest), OrderResponse(ActionResponse0 are the main focus of DSTU 2.1 adn the main focus of ongoing Workflow Discussions. Along with DiagnosticOrder 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 placer or filler systems might also choose to play the roll of order manager. Below is one scenario.

FHIR Client Order Management Interface (Placer 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,

FHIR Server Order Management Interface (Placer 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 System/LIS ( Filler 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

FHIR Server Fulfillment System/LIS (Filler 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

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 Placer and Filler using REST, but also tests the basic FHIR REST transactions, create, update, and read.
  • 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.
  • Some step below may be optional for systems where it is done in some other way than using FHIR RESTful approach. For example step 1a be done by a non FHIR CPOE system.
  • This track will use XML format
  • Ignoring Specimen collection flow
  • Patient, Organization and Practitioner will be fixed (default)to the following
  • A set of 4 tests in "test catalog" from which to order:
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
  • The Placer and Filler may be combined into a single server or two servers



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

Action: Placer Client posts DiagnosticOrder to Placer Server

Precondition: DiagnosticOrder does not exist in service prior to action

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

Step 1b

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

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

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

Step 1c

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

Filler Client gets Order as part of query response

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

Step 1d

Action: Filler Client posts OrderResponse to Placer 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 1e

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

Precondition OrderResponse does not exist in placer Server prior to action

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

Step 1f

Action: Filler Client posts DiagnosticReport to Placer Server referencing DiagnosticOrder

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

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

Step 1g

Action: Filler 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 Placer Server

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

Step 1h

Action: Placer Client monitors Placer Server for OrderResponse resources pointing to Orders they own via polling. Placer 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 1i

Action: Placer 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 Placer and Filler are clients and Order manager accepts subscriptions.
  • composite order (todo)
  • update (cancel, revise) DiagnosticOrder
  • progression from preliminary to final to corrected results

3. SOA Example Medication Order with Workflow

Scenario Assumptions

Simplest Case: (Short form to determine which ordering system; dynamic discovery via orderables lookup) Using workflow resources

Step 3a

Action: End-user facing form to select a provider organzation (e.g., which ordering system)

Precondition:

Success Criteria:

Bonus point:

Step 3b

Action: Evaluate user form to determine which system and which disease condition hence determining drug class and route

Precondition:

Success Criteria:

Bonus point:

Step 3c

Action: Orchestrator module to call the candidate system doing an orderables lookup for the corresponding drug on formulary

Precondition:

Success Criteria:

Bonus point:

Step 3d

Action: Orchestrator chooses drug. Makes service call to ordering system to place drug order.

Precondition:

Success Criteria:

Bonus point:

Step 3e

Repeat the above, choosing a different organization in the user-facing form resulting in drug order from a different system - no hardcoding.


Precondition:

Success Criteria:

Bonus point:

Bonus Points

Repeat the above, altering disease and hence dynamically adjusting drug ordered.

TestScript(s)

LabOrderLabReport TestScript Resource

stub for now