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
 
(225 intermediate revisions by 3 users not shown)
Line 1: Line 1:
  
 
[[Category:201601_FHIR_Connectathon_Track_Proposals|Jan 2016 Proposals]]
 
[[Category:201601_FHIR_Connectathon_Track_Proposals|Jan 2016 Proposals]]
 +
=Laboratory Order and Result=
 
__NOTOC__
 
__NOTOC__
=Track Name=
 
Laboratory Order and Result
 
  
 
==Submitting WG/Project/Implementer Group==
 
==Submitting WG/Project/Implementer Group==
 
<!-- Who is asking for this track? -->
 
<!-- Who is asking for this track? -->
 
Orders and Observations Working Group
 
Orders and Observations Working Group
(Service-oriented Architecture will support a component of this track)
 
 
todo:  See if any implementors interested
 
  
 
==Justification==
 
==Justification==
Line 16: Line 12:
 
'''Implementer need:'''
 
'''Implementer need:'''
  
# Exercise the Request resource + Action (nee Order) and ActionResponse (nee OrderResponse) resources
+
# 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  [http://wiki.hl7.org/index.php?title=FHIR_Workflow_Discussion|FHIR 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
 
#*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
+
#*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.
# 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.   
+
# 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.   
# clarify grouping of observations such as components vs related and diagnostic reports.
+
# Clarify grouping of observations such as components vs related and diagnostic reports.
 +
# Implement other Order and Observation resources - including DiagnosticReport, Observation and Specimen.
 
    
 
    
  
 
'''Impact on ballot:'''
 
'''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 [http://wiki.hl7.org/index.php?title=FHIR_Workflow_Discussion|FHIR Workflow Discussion]
+
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 [http://wiki.hl7.org/index.php?title=FHIR_Workflow_Discussion|FHIR Workflow Discussion]
  
  
 
'''FMM readiness of the resources:'''
 
'''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.  
+
*''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 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.
+
*''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
+
*''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==
+
===Proposed Track Lead===
 
<!-- Name, email and Skype id of individual who will coordinate the track at the connectathon -->
 
<!-- Name, email and Skype id of individual who will coordinate the track at the connectathon -->
  
Line 45: Line 42:
 
[mailto:ehaas@healthedatainc.com Eric Haas]
 
[mailto:ehaas@healthedatainc.com Eric Haas]
  
Skype: haas.eric1
+
=== Track Skype Chat ===
 +
 
 +
The LabOrder Track has a Skype chat to coordinate preparation and participation in the track:
 +
 
 +
[https://join.skype.com/DySi6EQ57Hsb LabOrder Connectathon Channel]
  
 
==Expected participants==
 
==Expected participants==
Line 51: Line 52:
  
 
'''Organization: '''
 
'''Organization: '''
* National/Regional Labs? (solicit interested parties)
+
* National/Regional Labs
* LIS Vendors?
+
* LIS Vendors
* EHR Vendors?
+
* EHR Vendors
  
 
==Roles==
 
==Roles==
Line 60: Line 61:
 
<!-- Provide a description of the capabilities this role will have within the connectathon -->
 
<!-- Provide a description of the capabilities this role will have within the connectathon -->
  
 +
See [http://wiki.hl7.org/index.php?title=Laboratory_Order_Conceptual_Specification | 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.===
 +
[[Image:FHIRConnectathonLabOrderTract.png]]
 +
 +
===What does the EHR-S do?===
 +
* An information system that receives, processes, and stores information related to the health and health care provided to patients.
 +
* As part of an EHR-S system, used by a Provider (Order Placer) to manage a laboratory order, including generating the laboratory requisition, sending it to a laboratory, and monitoring/tracking of the status of the laboratory order.
 +
**Typically a laboratory order system is an integral part of an order management system that enables users to manage orders for many different types of services, procedures, supplies, etc. Since we only focus on data exchange relative to laboratory orders we are purposely using a very limited definition.
 +
* To meet the requirements of the the Use Case below the EHR-S, at minimum, must have the following characteristics:
 +
** Data model that includes discrete representations of patients, clinician end-users, orgnizations, specimens, laboratory test requisitions/orders, laboratory tests (including panels), and laboratory test results (at the level of individual analytes), and specimens.
 +
** Capability to interface with an LIS using the FHIR RESTful API.
 +
** Capability to update the status and results of laboratory orders that have been ordered.
  
 +
This definition is very minimal and omits many features and capabilities that are typically associated with Electronic Health Record systems.  The minimal nature of the definition by no means excludes EHR-Ss with significantly greater capabilities.
  
See [http://wiki.hl7.org/index.php?title=Laboratory_Order_Conceptual_Specification | Lab Order Conceptual Model]] for details
+
===What does the LIS do?===
 +
* An information system that receives, processes, and stores information related to laboratory processes.
 +
* To meet the requirements of the the Use Case below the LIS, at minimum, must have the following characteristics:
 +
** Data model that includes discrete representations of patients, clinician end-users, laboratory test requisitions/orders, laboratory tests (including panels), and laboratory test results (at the level of individual analytes), and specimens.
 +
** Capability to interface with an EHR-S using the FHIR RESTful API.
 +
** Capability to update the status and results of laboratory tests that have been ordered.
  
 +
This definition is very minimal and omits many features and capabilities that are typically associated with laboratory information systems.  The minimal nature of the definition by no means excludes LIS with significantly greater capabilities.
  
System Actors from the storyboards above may implement one or more contract roles
+
===What FHIR resources does the EHR-S use to do the above things?===
  
[[Image:ActorContractRole.png]]
+
*Patient
 +
*Provider
 +
*Organization
 +
*Specimen
 +
*Diagnostic Order
 +
*Order
  
===FHIR Client ( Lab Order Repository )===
+
===What FHIR resources does the LIS use to do the above things?===
<!-- Provide a description of the capabilities this role will have within the connectathon -->
+
*Organization
*Enable the creation and retrieval of the DiagnosticOrder resource operations using the defined basic CRUD operations: create, history, read, search, update and delete.
+
*Practitioner
*Enable the retrieval of the DiagnosticResponse resource operations using the defined basic CRUD operations:  history, read, search,
+
*OrderResponse
 +
*DiagnosticReport
 +
*Specimen
 +
*Observation
  
===FHIR Client ( Ordering System )===
+
===Who is the client and who is the server and what functions do they they need to offer?===
<!-- Provide a description of the capabilities this role will have within the connectathon -->
+
*EHR-S would be either client or server, or both depending on the function
*Enable the creation and retrieval of the Action/Order resource operations using the defined basic CRUD operations: create, history, read, search, update and delete.
+
**EHR Client functions:
*Enable the retrieval of the ActionResponse/OrderResponse resource operations using the defined basic CRUD operations:  history, read, search,
+
***Create and retrieve and update the DiagnosticOrder resource
*Enable the retrieval of the DiagnosticOrder resource operations using the defined basic CRUD operations:  history, read, search, update and delete.
+
***Create and retrieve and update the Order resource
 +
***Retrieve the OrderResponse resource
 +
****Capability to check for updates to OrderResponse -- e.g. polling
 +
***Retrieve the DiagnosticReport resource and resources referenced by it - Observation, Specimen, Patient, Provider, and Organization
  
===FHIR Client ( Fulfillment System )===
 
<!-- Provide a description of the capabilities this role will have within the connectathon -->
 
*Enable the creation and retrieval of the ActionResponse/OrderResponse resource operations using the defined basic CRUD operations: create, history, read, search, update and delete.
 
*Enable the retrieval of the Action/Order resource operations using the defined basic CRUD operations:  history, read, search,
 
*Enable the retrieval of the DiagnosticReport resource operations using the defined basic CRUD operations:  history, read, search, update and delete.
 
  
===FHIR Client ( LIS )===
+
*LIS would be either client or server, or both depending on the function
<!-- Provide a description of the capabilities this role will have within the connectathon -->
+
**LIS Client functions:
*Enable the creation and retrieval of the DiagnosticReport resource operations using the defined basic CRUD operations: create, history, read, search, update and delete.
+
***Retrieve the Order resource
*Enable the creation and retrieval of the DiagnosticOrder resource operations using the defined basic CRUD operations: history, read, search
+
***Retrieve the DiagnosticOrder resource referenced by the Order and resources it references - Specimen, Patient, and Provider
 +
***Create and retrieve and update the OrderResponse resource
 +
***Create and retrieve and update the DiagnosticReportc and Observation resource(s)
 +
*Server functions:
 +
**Whether there is a distinct EHR-S Server and LIS Server or a single Server filling both roles, at a minimum store the lab order and lab result resources listed above
  
===FHIR Server ( Laboratory Order Repository )===
 
<!-- Provide a description of the capabilities this role will have within the connectathon -->
 
*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: create, history, read, search and update.
 
  
===FHIR Server (Order System )===
+
GG's comments:
<!-- Provide a description of the capabilities this role will have within the connectathon -->
+
* why does the EHR FHIR Client retrieve the DiagnosticReport resource? is this clinical time general access to diagnostic reports? or something more limited? EH: from a connectathon perspective to verify completion of order?  Very broadly EHR-client could be Clinician UI? 
*Support the receiving and processing of the Action/Order resource operations: create, history, read, search and update.
+
* is the idea that EHR would be either client or server, or both depending on the function? EH: I guess so not sure what you mean by both.  the EHR pushes stuff to LIS and maintains/store own stuff. 
*Support the receiving and processing of the ActionResponse/OrderResponse resource operations: create, history, read, search and update.
+
* why does the EHR FHIR Client read and create DiagnosticOrders? Doesn't it have them internally in it's own store, and just send them to the LIS when it wants to tell the LIS something has changed? EH:  I set up the test steps to include creation of order, but yes could be stored as well and would not need this functionality
 +
* what does 'simple polling' mean? EH: me being pedantic since I just wanted to make a note of the need for some way to know when the was an update.
 +
* what about observations and clinical images? EH: Yes I omitted Observations, Specimen and patient and practitioner since they are all referenced in DR, images as attachments or binaries or imaging resources? ... kind of out of scope for my simple use case.
  
===FHIR Server (Fulfillment System)===
 
<!-- Provide a description of the capabilities this role will have within the connectathon -->
 
*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: create, history, read, search and update.
 
  
===FHIR Server (LIS)===
+
GG's comments:
<!-- Provide a description of the capabilities this role will have within the connectathon -->
+
* I'm not sure why an EHR FHIR server should provide create, history, read, search, update. What is the functional outcome for doing these? Is it creating diagnosticOrders internally, and waiting for the LIS to poll for them? _EH:  see changes only expectation is storage right now.
*Support the receiving and processing of the DiagnosticOrder resource operations: create, history, read, search and update.
+
* why is the server list of resources longer than the client list?
*Support the receiving and processing of the DiagnosticReport resource operations: create, history, read, search and update.
+
* what about images? EH: above do you want to be in scope?
  
 
==Scenarios==
 
==Scenarios==
 
<!-- What will be the actions performed by participants? -->
 
<!-- What will be the actions performed by participants? -->
  
== 1. Create Lab Order (Lab Collect) no Workflow resources==
+
== Test Case 1. Create Lab Order (Lab Collect) Simple Case==
 +
 
 +
This is the simplest Case as shown in the diagram below:
  
See [http://wiki.hl7.org/index.php?title=Laboratory_Order_Conceptual_Specification | Lab Order Conceptual Model]] for details
+
[[image:FulfillmentLiteSTM.PNG]]
  
====='''Storyboard (Universal) - Create Lab Order (Lab Collect)=====
+
See [http://wiki.hl7.org/index.php?title=Laboratory_Order_Conceptual_Specification | Lab Order Conceptual Model]] for  more details
 +
====='''Generic Storyboard - Create Lab Order (Lab Collect)=====
  
  Eve Everywoman, a 27-year-old female, presents at Good Health Hospital Outpatient Clinic
+
  Todd Lerr presents at Good Health Hospital Outpatient Clinic
  and is seen by Dr. Patricia Primary. Eve reports a history of Anemia and recent,
+
  and is seen by Dr. Leonard Blooddraw. Todd reports a history and Dr. Blooddraw
  excessive tiredness.  Dr. Primary enters a request to check the iron levels in Eve’s
+
  enters a request into the care system which then sends the test requests to  
blood into her care system.  Dr. Primary’s care system then sends the test requests to  
+
  the lab system at the Acme Laboratory service.  Todd is provided instructions
  the lab system at the Good Health Hospital’s Laboratory service.  Eve receives a paper
+
  for where to find the collection center.
  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
+
  Later, at the Lab Collection Center, the appropriate samples are  
finds the order for her testing in the lab system.  The appropriate blood samples are  
+
  collected and the sample information entered into the information
  extracted, their containers labeled, and the sample information entered into the information
 
 
  in the lab system.  
 
  in the lab system.  
 
   
 
   
 
  The lab performs the analysis on the specimen(s), enters the results into the lab system, and
 
  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
 
  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
+
  results, formulates a treatment, if needed, and notifies teh patient of the results and
 
  treatment.
 
  treatment.
  
  
====Scenario Assumptions====
+
====Assumptions====
Simplest Case:  
+
Simplest Case:
 +
*>>Note: Order/OrderResponse are also known as the ActionResponse/ActionRequest resources
 +
 +
*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 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 | Testscripts]] Section below for source files):
 +
{| class="wikitable"
 +
|-
 +
|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
 +
|}
  
Ignoring Specimen collection flow/cancels or updates
+
====Step 1 Order a new lab test====
  
Direct exchange of resources between LabOrderRepository and LIS i.e. no workflow or fulfillment system actors or resources
+
=====Step 1.1=====
 
+
'''Action:''' <!--Who does what?  (Use the role names listed above when referring to the participants -->EHR Client posts DiagnosticOrder to Server
Non target resources Patient, Organization and Practitioner will be fixed (default).
 
 
 
A limited set of potential tests to order will be provided.
 
 
 
====Step 1a ====
 
'''Action:''' <!--Who does what?  (Use the role names listed above when referring to the participants -->FHIR Client ( Laboratory Order Repository )
 
creates completed DiagnosticOrder request and save to Lab Order Repository
 
  
 
Precondition: DiagnosticOrder does not exist in service prior to action
 
Precondition: DiagnosticOrder does not exist in service prior to action
  
Success Criteria: DiagnosticOrder created correctly on server (use browser to inspect Patient)
+
Success Criteria: DiagnosticOrder created correctly on the server (use browser to inspect)
 
 
Bonus point:
 
* Order with multiple components (roundtrip workflow)
 
* progression from proposed to completed order
 
* 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)
 
 
 
>>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:''' <!--Who does what?  (Use the role names listed above when referring to the participants -->
 
FHIR client (LIS) searches for and pulls the completed DiagnosticOrder from the FHIR Server ( Laboratory Order Repository ) and creates a copy in FHIR server (Fulfillment System/LIS)
 
 
 
Precondition: completed DiagnosticOrder does not exist in service prior to action
 
 
 
Success Criteria: copy of DiagnosticOrder in FHIR Server (LIS) (use browser to inspect)
 
 
 
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)
 
 
 
====Step 1c ====
 
'''Action:''' <!--Who does what?  (Use the role names listed above when referring to the participants -->
 
FHIR Client ( LIS ) creates final DiagnosticReport and saved in FHIR Server (LIS)
 
 
 
Precondition: DiagnosticReport 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 (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)
 
  
====Step 1d ====
+
=====Step 1.2 =====
 
'''Action:''' <!--Who does what?  (Use the role names listed above when referring to the participants -->
 
'''Action:''' <!--Who does what?  (Use the role names listed above when referring to the participants -->
Fullfillment System/LIS returns completed ''DiagnosticReport'' resources are pushed/pulled to lab report Repository
+
EHR Client posts Order containing a reference to DiagnosticOrder to the Server saying "Do this" (i.e. have a laboratory perform the test(s))
 
 
Precondition:
 
 
 
Success Criteria:
 
  
Bonus point:
+
Precondition: Order does not exist in Server prior to action
== 2. Create Lab Order (Lab Collect) using Workflow resources==
 
See [http://wiki.hl7.org/index.php?title=Laboratory_Order_Conceptual_Specification | Lab Order Conceptual Model]] for details
 
  
See Storyboard above
+
Success Criteria: Order created correctly on the server (use browser to inspect)
   
 
====Scenario Assumptions====
 
Simplest Case: (ignoring Specimen collection flow/cancels or updates) Using workflow resources
 
  
====Step 2a ====
+
====Step 2 Accept new lab orders ====
 +
=====Step 2.1 =====
 
'''Action:''' <!--Who does what?  (Use the role names listed above when referring to the participants -->
 
'''Action:''' <!--Who does what?  (Use the role names listed above when referring to the participants -->
Completed Diagnostic Order request stored into lab order Repository
+
LIS Client monitors server for Order resources (and changes to them) assigned to them via polling
  
Precondition:
+
LIS Client gets Order as part of query response
  
Success Criteria:
+
Success Criteria: Copy of Order along with reference to DiagnosticOrder received by Fulfillment Client as part of polling operation.(use client console to inspect)
  
Bonus point:
+
=====Step 2.2 =====
====Step 2b ====
+
'''Action:''' <!--Who does what?  (Use the role names listed above when referring to the participants -->LIS Client posts OrderResponse to Server referencing Order and agreeing to fulfill DiagnosticOrder
'''Action:''' <!--Who does what?  (Use the role names listed above when referring to the participants -->
 
Ordering System polls lab order Repository's for completed Diagnostic Order requests
 
  
Precondition:
+
Precondition: OrderResponse does not exist in service prior to action
  
Success Criteria:
+
Success Criteria: OrderResponse created correctly on the server (use browser to inspect)
  
Bonus point:
+
=====Step 2.3 =====
====Step 2c ====
 
 
'''Action:''' <!--Who does what?  (Use the role names listed above when referring to the participants -->
 
'''Action:''' <!--Who does what?  (Use the role names listed above when referring to the participants -->
Ordering  System creates ''Action'' resource  (Action.details = ''DiagnosticOrder'' resource) are pushed/pulled to Fulfillment System
+
EHR Client monitors Server for OrderResponse resources pointing to Orders they own via polling.   
 +
and gets OrderResponse as part of query response
  
Precondition:
+
Precondition OrderResponse does not exist in Server prior to action
  
Success Criteria:
+
Success Criteria: Copy of OrderResponse received by EHR Client as part of polling operation.(use client console to inspect)
  
Bonus point:
+
====Step 3 Fulfill Lab Order ====
====Step 2d ====
+
=====Step 3.1=====
 
'''Action:''' <!--Who does what?  (Use the role names listed above when referring to the participants -->
 
'''Action:''' <!--Who does what?  (Use the role names listed above when referring to the participants -->
Fulfillment System which responds with  ''ActionResponse'' resource indicating order accepted
+
LIS Client posts DiagnosticReport to Server referencing DiagnosticOrder
 
 
Precondition:
 
  
Success Criteria:
+
Precondition: DiagnosticReport, Observation and Specimen Resources created and stored in Server
  
Bonus point:
+
Success Criteria: DiagnosticReport, Observation and Specimen Resources received and stored in Server. (use browser to inspect)
====Step 2e ====
 
'''Action:''' <!--Who does what?  (Use the role names listed above when referring to the participants -->
 
Laboratory Information System polls Fulfillment System for accepted lab requests
 
  
Precondition:
+
=====Step 3.2 =====
 +
'''Action:''' <!--Who does what?  (Use the role names listed above when referring to the participants -->LIS Client posts OrderResponse referencing the DiagnosticReport and Order and indicating they believe order is fulfilled to the Server.
  
Success Criteria:
+
Precondition: DiagnosticReport, Observation and Specimen Resources created and stored in Server
  
Bonus point:
+
Success Criteria: OrderResponse received stored. (use browser to inspect)
====Step 2f ====
 
'''Action:''' <!--Who does what?  (Use the role names listed above when referring to the participants -->
 
Lab test performed and final Diagnostic report stored in Fullfillment System/LIS
 
  
Precondition:
+
====Step 4 Receive Lab Results====
 +
=====Step 4.1 =====
 +
'''Action:''' <!--Who does what?  (Use the role names listed above when referring to the participants -->EHR Client monitors Server for OrderResponse resources pointing to Orders they own via polling. EHR Client gets 2nd OrderResponse as part of query.
  
Success Criteria:
+
Precondition: OrderResponse exist in Server with status of 'accepted' prior to action
  
Bonus point:
+
Success Criteria: Copy of OrderResponse received by EHR Client as part of polling operation.(use client console to inspect)
====Step 2g ====
 
'''Action:''' <!--Who does what?  (Use the role names listed above when referring to the participants -->
 
Fulfillment System  polls Laboratory Information System  Repository's for completed Diagnostic Reports
 
  
Precondition:
+
=====Step 4.2 =====
 +
'''Action:''' <!--Who does what?  (Use the role names listed above when referring to the participants -->EHR Client retrieves  DiagnosticReport
  
Success Criteria:
+
Precondition: DiagnosticReport exists in Server with status of 'completed' prior to action
  
Bonus point:
+
Success Criteria: Approporate DiagnosticReport with status of 'completed' received stored. (use browser to inspect)
====Step 2h ====
 
'''Action:''' <!--Who does what?  (Use the role names listed above when referring to the participants -->
 
Fulfillment System  creates/updates ''ActionResponse'' resource (ActionRespons.fulfilment = ''DiagnosticReport'' resource ) are  pushed/pulled to Ordering  System
 
  
Precondition:
+
=====Step 4.3 =====
 +
'''Action:''' <!--Who does what?  (Use the role names listed above when referring to the participants -->EHR Client updates DiagnosticOrder to indicate they are completed.
  
Success Criteria:
+
Precondition: DiagnosticOrder exists in Server with status of 'requested' prior to action
  
Bonus point:
+
Success Criteria: DiagnosticOrder with status of 'completed' received stored. (use browser to inspect)
====Step 2i ====
 
'''Action:''' <!--Who does what?  (Use the role names listed above when referring to the participants -->
 
Ordering  System updates patient record, provider notified??,updated Diagnostic Order request.
 
  
Precondition:
+
----
  
Success Criteria:
+
====Scenario 1 RoundTrip Success Criteria: ====
  
Bonus point:
+
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.
 +
*progression from preliminary to final to corrected results
 +
*composite order (todo)
 +
*update (cancel, revise) DiagnosticOrder
 +
*update (cancel, revise) Order
  
 +
==Help Links==
 +
Here are some links to assist implementers:
  
 +
'''link to the HL7 Lab Order conceptual model'''
 +
*[[http://wiki.hl7.org/index.php?title=Laboratory_Order_Conceptual_Specification Lab Order Conceptual Model]]
  
== 3. SOA Example Medication Order with Workflow ==
+
'''Links to the FHIR Standard'''
====Scenario Assumptions====
+
* [http://hl7.org/fhir/http.html/ REST API in the Specification].
Simplest Case: (Short form to determine which ordering system; dynamic discovery via orderables lookup) Using workflow resources
+
* [http://hl7.org/fhir/diagnosticorder.html/ DiagnosticOrder resource in the Specification].
 +
* [http://hl7.org/fhir/order.html/ Order resource in the Specification].
 +
* [http://hl7.org/fhir/orderresponse.html/ OrderResponse resource in the Specification].
 +
* [http://hl7.org/fhir/diagnosticreport.html/ DiagnosticReport resource in the Specification].
 +
* [http://hl7.org/fhir/observation.html/ DiagnosticObservation resource in the Specification].
 +
* [http://hl7.org/fhir/specimen.html/ Specimen resource in the Specification].
  
====Step 3a ====
+
'''FHIR tooling'''
'''Action:''' <!--Who does what?  (Use the role names listed above when referring to the participants -->
+
* [http://fhirblog.com/2015/12/17/orders-in-fhir/ David Hay's blog] for additional information and discussion and a example FHIR client application for ordering
End-user facing form to select a provider organzation (e.g., which ordering system)
+
* [http://52.27.123.132/fhir/baseDstu2/ Rob Hausam's combined Order+Fulfiller test server for testing]
 +
* [http://fhirblog.com/2014/07/31/fhir-connectathon-7-for-java-dummies/ Java client sample].
 +
* [http://fhirblog.com/2014/06/29/c-fhir-client/ .net client sample].
 +
* [http://wiki.hl7.org/index.php?title=Publicly_Available_FHIR_Servers_for_testing Publicly Available FHIR Servers for testing].
  
Precondition:
+
==TestScripts==
 +
<!-- Optional (for initial proposal): Provide links to the TestScript instance(s) that define the behavior to be tested. 
 +
These should be committed to SVN under trunk/connectathons/[connectathon]
 +
-->
 +
The supporting TestScripts resources, corresponding test-case examples resources files, and test plan documents have been committed to the FHIR SVN repository at:
  
Success Criteria:
+
http://gforge.hl7.org/svn/fhir/trunk/connectathons/OrlandoJan2016/Connectathon11/Track7-LabOrderLabReport
  
Bonus point:
+
>> Use an SVN browser such as Tortoise to view files
====Step 3b ====
 
'''Action:''' <!--Who does what? (Use the role names listed above when referring to the participants -->
 
Evaluate user form to determine which system and which disease condition hence determining drug class and route
 
  
Precondition:
+
There are 4 TestScripts definitions - one for each original test order:
  
Success Criteria:
+
* Test Order Number 100
 +
* Test Order Number 200
 +
* Test Order Number 300
 +
* Test Order Number 400
  
Bonus point:
+
FHIR Resource ID Assigned by the Client, 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.
====Step 3c ====
 
'''Action:''' <!--Who does what?  (Use the role names listed above when referring to the participants -->
 
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:''' <!--Who does what?  (Use the role names listed above when referring to the participants -->
 
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)==
 
<!-- Optional (for initial proposal): Provide links to the TestScript instance(s) that define the behavior to be tested. 
 
These should be committed to SVN under trunk/connectathons/[connectathon]
 
-->
 
[http://gforge.hl7.org/svn/fhir/trunk/connectathons/OrlandoJan2016/Connectathon11/TrackN-LabOrderLabReport LabOrderLabReport TestScript Resource]
 
  
stub for now
+
>>todo add bonus testscripts

Latest revision as of 19:19, 7 January 2016

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.

FHIRConnectathonLabOrderTract.png

What does the EHR-S do?

  • An information system that receives, processes, and stores information related to the health and health care provided to patients.
  • As part of an EHR-S system, used by a Provider (Order Placer) to manage a laboratory order, including generating the laboratory requisition, sending it to a laboratory, and monitoring/tracking of the status of the laboratory order.
    • Typically a laboratory order system is an integral part of an order management system that enables users to manage orders for many different types of services, procedures, supplies, etc. Since we only focus on data exchange relative to laboratory orders we are purposely using a very limited definition.
  • To meet the requirements of the the Use Case below the EHR-S, at minimum, must have the following characteristics:
    • Data model that includes discrete representations of patients, clinician end-users, orgnizations, specimens, laboratory test requisitions/orders, laboratory tests (including panels), and laboratory test results (at the level of individual analytes), and specimens.
    • Capability to interface with an LIS using the FHIR RESTful API.
    • Capability to update the status and results of laboratory orders that have been ordered.

This definition is very minimal and omits many features and capabilities that are typically associated with Electronic Health Record systems. The minimal nature of the definition by no means excludes EHR-Ss with significantly greater capabilities.

What does the LIS do?

  • An information system that receives, processes, and stores information related to laboratory processes.
  • To meet the requirements of the the Use Case below the LIS, at minimum, must have the following characteristics:
    • Data model that includes discrete representations of patients, clinician end-users, laboratory test requisitions/orders, laboratory tests (including panels), and laboratory test results (at the level of individual analytes), and specimens.
    • Capability to interface with an EHR-S using the FHIR RESTful API.
    • Capability to update the status and results of laboratory tests that have been ordered.

This definition is very minimal and omits many features and capabilities that are typically associated with laboratory information systems. The minimal nature of the definition by no means excludes LIS with significantly greater capabilities.

What FHIR resources does the EHR-S use to do the above things?

  • Patient
  • Provider
  • Organization
  • Specimen
  • Diagnostic Order
  • Order

What FHIR resources does the LIS use to do the above things?

  • Organization
  • Practitioner
  • OrderResponse
  • DiagnosticReport
  • Specimen
  • Observation

Who is the client and who is the server and what functions do they they need to offer?

  • EHR-S would be either client or server, or both depending on the function
    • EHR Client functions:
      • Create and retrieve and update the DiagnosticOrder resource
      • Create and retrieve and update the Order resource
      • Retrieve the OrderResponse resource
        • Capability to check for updates to OrderResponse -- e.g. polling
      • Retrieve the DiagnosticReport resource and resources referenced by it - Observation, Specimen, Patient, Provider, and Organization


  • LIS would be either client or server, or both depending on the function
    • LIS Client functions:
      • Retrieve the Order resource
      • Retrieve the DiagnosticOrder resource referenced by the Order and resources it references - Specimen, Patient, and Provider
      • Create and retrieve and update the OrderResponse resource
      • Create and retrieve and update the DiagnosticReportc and Observation resource(s)
  • Server functions:
    • Whether there is a distinct EHR-S Server and LIS Server or a single Server filling both roles, at a minimum store the lab order and lab result resources listed above


GG's comments:

  • why does the EHR FHIR Client retrieve the DiagnosticReport resource? is this clinical time general access to diagnostic reports? or something more limited? EH: from a connectathon perspective to verify completion of order? Very broadly EHR-client could be Clinician UI?
  • is the idea that EHR would be either client or server, or both depending on the function? EH: I guess so not sure what you mean by both. the EHR pushes stuff to LIS and maintains/store own stuff.
  • why does the EHR FHIR Client read and create DiagnosticOrders? Doesn't it have them internally in it's own store, and just send them to the LIS when it wants to tell the LIS something has changed? EH: I set up the test steps to include creation of order, but yes could be stored as well and would not need this functionality
  • what does 'simple polling' mean? EH: me being pedantic since I just wanted to make a note of the need for some way to know when the was an update.
  • what about observations and clinical images? EH: Yes I omitted Observations, Specimen and patient and practitioner since they are all referenced in DR, images as attachments or binaries or imaging resources? ... kind of out of scope for my simple use case.


GG's comments:

  • I'm not sure why an EHR FHIR server should provide create, history, read, search, update. What is the functional outcome for doing these? Is it creating diagnosticOrders internally, and waiting for the LIS to poll for them? _EH: see changes only expectation is storage right now.
  • why is the server list of resources longer than the client list?
  • what about images? EH: above do you want to be in scope?

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

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:

  • >>Note: Order/OrderResponse are also known as the ActionResponse/ActionRequest resources
  • 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 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 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 Server saying "Do this" (i.e. have a laboratory perform the test(s))

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

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

Step 3 Fulfill Lab Order

Step 3.1

Action: LIS Client posts DiagnosticReport to Server referencing DiagnosticOrder

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

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

Step 3.2

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

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

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

Step 4 Receive Lab Results

Step 4.1

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

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

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

Step 4.2

Action: EHR Client retrieves DiagnosticReport

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

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

Help Links

Here are some links to assist implementers:

link to the HL7 Lab Order conceptual model

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:

  • Test Order Number 100
  • Test Order Number 200
  • Test Order Number 300
  • Test Order Number 400

FHIR Resource ID Assigned by the Client, 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