201601 LabOrderLabReport

Track Name

Laboratory Order and Result

Submitting WG/Project/Implementer Group

Orders and Observations Working Group

todo: See if any implementors interested

Justification

Implementer need:

1. Exercise the Request resoure + 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 Speicimen, 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 Connectathons 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 Connectathos to help move them forward to FMM4 as well as identify issues surrounding nested grouping of observation for cases such as culture and sensitivies.

• 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

[| Eric Haas]

Skype: haas.eric1

others?

Expected participants

Organization:

• Labs? (solicit interested parties)
• LIS Vendors?
• EHR Vendors?

Roles

Role 1 Name

>

Assumptions -

simplest case

Requestor pushes/pulls to

fullfiller pushes/pulls to

Requestor

Requestor pushes (resource) to intermediary endpoint

Intermediary polls endpoint and pushes action to fulfiller endpoint

fullfiller polls endpoint and fulfils and send report to intermediary endpoint

Requestor polls intermediary endpoint for results

think about pulling vs pushing

Requestor

Role1a: ????Lab Order requestor (server?): USLabOrder requester is the server, in other words, operating in 'Pull' or 'Push/Pull' RESTful interface. The USLabOrder Orderer MUST support querying one or more resources outlined by the USLabOrder Guide. The USLabOrder Orderer MUST use all the vocabularies and value set constraints defined by the individual resource profiles used by USLabOrder. The USLabOrder Orderer MUST implement REST behavior according to the FHIR specification and MUST be able to handle errors gracefully from Query Responders who may not support the submitted query.

Role1b: Lab Order requestor pull result from actionor??(client): USLabOrder requester is the server, in other words, operating in 'Pull' or 'Push/Pull' RESTful interface. The USLabOrder Orderer MUST support querying one or more resources outlined by the USLabOrder Guide. The USLabOrder Orderer MUST use all the vocabularies and value set constraints defined by the individual resource profiles used by USLabOrder. The USLabOrder Orderer MUST implement REST behavior according to the FHIR specification and MUST be able to handle errors gracefully from Query Responders who may not support the submitted query.

actionor

Role2a: Actioner ( Server ): USLabOrder Actioner is the server, in other words, operating in 'Pull' or 'Push/Pull' RESTful interface. The USLabOrder Orderer MUST support querying one or more resources outlined by the USLabOrder Guide. The USLabOrder Orderer MUST use all the vocabularies and value set constraints defined by the individual resource profiles used by USLabOrder. The USLabOrder Orderer MUST implement REST behavior according to the FHIR specification and MUST be able to handle errors gracefully from Query Responders who may not support the submitted query.

fulfiller'

Role3a: :

Role3b: Lab Filler ( Client ):

Scenarios

Scenario Step 1 Name

:Action:

see storybaord and above

:Precondition:

what needs to be in server where etc

:Success Criteria:

requester receive diagnostic report. Has to be some logic or some other party to play the role of fulfiller.

:Bonus point:

split order, reflex order, cancel/ update order.

add storyboard from Order functional model

glean out roles

TestScript(s)

LabOrderLabReport TestScript Resource

stub for now