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

201601 LabOrderLabReport

From HL7Wiki
Revision as of 09:55, 10 December 2015 by Ehaas (talk | contribs) (→‎Step 2c)
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)

todo: See if any implementors interested

Justification

Implementer need:

  1. Exercise the Request resource + Action (nee Order) and ActionResponse (nee OrderResponse) resources
    • 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
  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 a separate requests.
  3. clarify grouping of observations such as components vs related and diagnostic reports.


Impact on ballot:

The OO workflow recourses DiagnosticOrder, ActionRequest, 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, Action (nee Order) and ActionResponse (nee OrderResponse) 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? (solicit interested parties)
  • 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

FHIR Client ( Order Management Interface/EHR-S )

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

  • 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/EHR-S )

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

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

(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) no Workflow resources

See | Lab Order Conceptual Model] for details

Storyboard (Universal) - Create Lab Order (Lab Collect)
Eve Everywoman, a 27-year-old female, presents at Good Health Hospital Outpatient Clinic
and is seen by Dr. Patricia Primary. Eve reports a history of Anemia and recent,
excessive tiredness.  Dr. Primary enters a request to check the iron levels in Eve’s
blood into her care system.  Dr. Primary’s care system then sends the test requests to 
the lab system at the Good Health Hospital’s Laboratory service.  Eve receives a paper 
order requisition that serves as a reminder,  provides instructions for where to find 
the collection center, and also details preparation instructions for the patient to 
follow (no food or drink from midnight until collection time on the day of collection).

Later that week Eve presents herself at the Lab Collection Center.  The lab looks up and 
finds the order for her testing in the lab system.  The appropriate blood samples are 
extracted, their containers labeled, 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 Eve Everywoman of the results and
treatment.


Scenario Assumptions

Simplest Case:

FulfillmentLiteSTM.PNG

Ignoring Specimen collection flow/cancels or updates

Direct exchange of resources between LabOrderRepository and LIS i.e. no workflow or fulfillment system actors or resources

Non target resources Patient, Organization and Practitioner will be fixed (default).

A limited set of 4-5 potential tests to order will be provided and corresponding results applied.

Either XML or JSON formats to be supported.

Step 1a

Action: FHIR Client ( Order Management Interface/EHR-S ) creates completed DiagnosticOrder request and save to Order Management Interface/EHR-S

Precondition: DiagnosticOrder does not exist in service prior to action

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

Bonus point:

  • Order with multiple components
  • Progression from proposed to completed order
  • cancel/update order
  • Add Specimen collection

>>Note: the 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.

Step 1b

Action: FHIR Client ( Order Management Interface/EHR-S ) pushes copy of completed DiagnosticOrder request to Fulfillment System/LIS.

Precondition: DiagnosticOrder does not exist in Fulfillment System/LIS prior to action

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

Bonus point:

  • cancel/update order
  • server to server transaction

Step 1c

Action: FHIR Server (Fulfillment System/LIS) receives and stores copy of completed DiagnosticOrder and send a transaction response with payload of updated DiagnosticOrder with status of "accepted" or "rejected" based on a simple criteria of whether:

  1. the test orders matches test catalog.
  2. able to identify the patient
  3. able to identify to placer

Success Criteria: copy of DiagnosticOrder received stored and updated and returned as part of transaction appropriately with status of "accepted". (use browser to inspect)

Bonus point:

  • negative testing - order rejection
  • cancel/update order

Step 1d

Action: FHIR Client ( Fulfillment System/LIS ) retrieves accepted DiagnosticOrder request and creates and stores appropriate DiagnosticReport and Observation and Specimen Resource to FHIR Server (Fulfillment System/LIS)

Precondition: DiagnosticReport and Observation and Specimen Resource do not exist in service prior to action

Success Criteria:

  1. Successfully searched for DiagnosticOrder
  2. Appropriate ( ie matching placer id, patient, order codes) DiagnosticReport and Observation and Specimen Resource created correctly on server (use browser to inspect)

Bonus point:

  • Progression from partial to completed report
  • cancel/update order
  • Add Specimen collection

>>Note: the 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.

Step 1e

Action: FHIR Client ( Fulfillment System/LIS ) Pushes a copy of completed DiagnosticReport and associated Observations and Specimen Resources to FHIR Server ( Order Management Interface/EHR-S )preferably as a 'transaction interaction' .

Precondition: DiagnosticReport and associated Observations and Specimen Resources does not exist in Order Management Interface/EHR-S prior to action

Success Criteria: DiagnosticReport and Observations created correctly on server (use browser to inspect)

Bonus point:

  • cancel/update order
  • Progression from proposed to final to corrected results
  • server to server transaction

Step 1f

Action: FHIR Server ( Order Management Interface/EHR-S ) receives and stores copy of completed DiagnosticReport, Observation and Specimen Resources preferable as a transaction interaction and sends an apporpriate transaction response.

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

Bonus point:

  • cancel/update order
  • Progression from proposed to final to corrected results

Step 1g

Action: FHIR Client ( Order Management Interface/EHR-S ) searches for completed DiagnosticReport using the _include search results parameter to return associated Observations and Specimen resources.

Precondition: none

Success Criteria: Retrieval of appopriate DiagnosticReport, Observation and Specimen Resources matching placer order, patient and ordered test. (use browser to inspect)

Bonus point:

  • Progression from proposed to final to corrected results
  • cancel/update order

Scenario 1 RoundTrip Success Criteria:

DiagnosticReport is appropriate for DiagnosticOrder.

Scenario 1 Round Trip Bonus point

  • Order with multiple components (roundtrip workflow)
  • cancel/update order (roundtrip workflow)
  • split order (roundtrip workflow)
  • reflex order (roundtrip workflow)
  • Culture and Sensitivity (complex grouping,roundtrip workflow)
  • Add Specimen collection (roundtrip workflow)
  • Add polling or subscription to alert clinician when reports available

2. Create Lab Order (Lab Collect) using Workflow resources

See | Lab Order Conceptual Model] for details

See Storyboard above

Scenario Assumptions

Same as Scenario 1 except using workflow resources Order/Action and OrderResponse/ActionResponse.

Step 2a

Same as 1a above

Step 2b

Action: FHIR Client ( Order Management Interface/EHR-S ) creates Order Resource and pushes along with a copy of completed DiagnosticOrder request to Fulfillment System/LIS preferably using a transaction interaction.

Precondition: Order and DiagnosticOrder does not exist in Fulfillment System/LIS prior to action

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

Bonus point:

  • cancel/update order
  • server to server transaction

Step 2c

Action: FHIR Server (Fulfillment System/LIS) receives and stores copy of completed Order and DiagnosticOrder and send a transaction response with payload of updated OrderResponse with status of "accepted" or "rejected" based on a simple criteria of whether:

  1. the test orders matches test catalog.
  2. able to identify the patient
  3. able to identify to placer

Success Criteria: Order and copy of DiagnosticOrder resources received stored and updated and OrderResponse resource returned as part of transaction appropriately with orderstatus of "accepted". (use browser to inspect)

Bonus point:

  • negative testing - order rejection
  • progression from pending to accepted or rejected

Step 2d

Action: Fulfillment System which responds with ActionResponse resource indicating order accepted

Precondition:

Success Criteria:

Bonus point:

Step 2e

Action: Laboratory Information System polls Fulfillment System for accepted lab requests

Precondition:

Success Criteria:

Bonus point:

Step 2f

Action: Lab test performed and final Diagnostic report stored in Fullfillment System/LIS

Precondition:

Success Criteria:

Bonus point:

Step 2g

Action: Fulfillment System polls Laboratory Information System Repository's for completed Diagnostic Reports

Precondition:

Success Criteria:

Bonus point:

Step 2h

Action: Fulfillment System creates/updates ActionResponse resource (ActionRespons.fulfilment = DiagnosticReport resource ) are pushed/pulled to Ordering System

Precondition:

Success Criteria:

Bonus point:

Step 2i

Action: Ordering System updates patient record, provider notified??,updated Diagnostic Order request.

Precondition:

Success Criteria:

Bonus point:

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

Retrieved from "https://wiki.hl7.org/w/index.php?title=201601_LabOrderLabReport&oldid=109799"