Difference between revisions of "201601 LabOrderLabReport"
Line 190: | Line 190: | ||
====Step 1b ==== | ====Step 1b ==== | ||
'''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 --> | ||
− | + | Placer Client posts Order pointing to DiagnosticOrder to Placer Server saying "Do this" (i.e. have a laboratory perform the test(s)) | |
− | |||
Precondition: DiagnosticOrder does not exist in Fulfillment System/LIS prior to action | Precondition: DiagnosticOrder does not exist in Fulfillment System/LIS prior to action |
Revision as of 15:25, 17 December 2015
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:
- 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.
- 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.
- clarify grouping of observations such as components vs related and diagnostic reports.
- 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
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
FHIR Client Order Management Interface (Placer Client)
(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 (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:
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.
- 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.
Scenario Assumptions
Simplest Case:
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: 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)
>>Note: This step is optional for systems where the creation of the diagnostic order is done in some other way than using FHIR RESTful approach
>>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: Placer Client posts Order pointing to DiagnosticOrder to Placer Server saying "Do this" (i.e. have a laboratory perform the test(s))
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:
- the test orders matches test catalog.
- able to identify the patient
- 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:
- payload of updated DiagnosticOrder with status of "accepted" or "rejected"
- 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:
- Successfully searched for DiagnosticOrder
- 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 - patient, order Id, test code matches
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
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