|
|
| (3 intermediate revisions by the same user not shown) |
| Line 1: |
Line 1: |
| | | | |
| − | [[Category:201601_FHIR_Connectathon_Track_Proposals|Jan 2016 Proposals]]
| |
| − | __NOTOC__
| |
| − | =Track Name=
| |
| − | Laboratory Order and Result
| |
| − |
| |
| − | ==Submitting WG/Project/Implementer Group==
| |
| − | <!-- Who is asking for this track? -->
| |
| − | Orders and Observations Working Group
| |
| − |
| |
| − | todo: See if any implementors interested
| |
| − |
| |
| − | ==Justification==
| |
| − | <!--Why is this an important track to include in the connectathon - include implementer need, impact on ballot, FMM readiness of the resources, etc. -->
| |
| − | '''Implementer need:'''
| |
| − |
| |
| − | todo - clarify grouping of observations such as components vs related and diagnostic reports.
| |
| − |
| |
| − | '''Impact on ballot:'''
| |
| − |
| |
| − | The OO workflow resourses 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
| |
| − |
| |
| − | '''FMM readiness of the resources:'''
| |
| − |
| |
| − | *Diagnostic Order, 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. Specifically 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.
| |
| − |
| |
| − | *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 thi immature resource and help move it to FMM2
| |
| − |
| |
| − | ==Proposed Track Lead==
| |
| − | <!-- Name, email and Skype id of individual who will coordinate the track at the connectathon -->
| |
| − |
| |
| − | Eric M Haas
| |
| − |
| |
| − | [[mailto:ehaas@healthedatainc.com | Eric Haas]]
| |
| − |
| |
| − | Skype: haas.eric1
| |
| − |
| |
| − | others?
| |
| − |
| |
| − | ==Expected participants==
| |
| − | <!-- List of the individuals and/or organizations that have indicated a desire to attend the connectathon and implement this track -->
| |
| − |
| |
| − | '''Organization: '''
| |
| − | * Labs? (solicit interested parties)
| |
| − | * Vendors?
| |
| − |
| |
| − | ==Roles==
| |
| − | <!-- Roles are sets of functionality (generally defined by a Conformance resource) that a single system can take on -->
| |
| − | ===Role 1 Name===
| |
| − | <!-- Provide a description of the capabilities this role will have within the connectathon -->>
| |
| − |
| |
| − | 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==
| |
| − | <!-- What will be the actions performed by participants? -->
| |
| − |
| |
| − | ===Scenario Step 1 Name===
| |
| − | :Action: <!--Who does what? (Use the role names listed above when referring to the participants -->
| |
| − |
| |
| − | see storybaord and above
| |
| − |
| |
| − | :Precondition: <!-- What setup is required prior to executing this step? -->
| |
| − |
| |
| − | what needs to be in server where etc
| |
| − |
| |
| − | :Success Criteria: <!-- How will the participants know if the test was successful? -->
| |
| − |
| |
| − | requester receive diagnostic report. Has to be some logic or some other party to play the role of fulfiller.
| |
| − |
| |
| − | :Bonus point: <!-- Any additional complexity to make the scenario more challenging -->
| |
| − |
| |
| − | split order, reflex order, cancel/ update order.
| |
| − |
| |
| − | <!-- Provide a description of each task -->
| |
| − |
| |
| − | add storyboard from Order functional model
| |
| − |
| |
| − | glean out roles
| |
| − |
| |
| − | ==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]
| |
| − | -->
| |
