This wiki has undergone a migration to Confluence found Here
Difference between revisions of "FHIR Workflow Minutes CC 20160201"
Jump to navigation
Jump to search
Line 99: | Line 99: | ||
===Decision=== | ===Decision=== | ||
− | We will use explicit elements to identify the desired fulfiller or fulfiller type | + | We will use explicit elements in the 'request' resource to identify the desired fulfiller or fulfiller type |
Then discussed potential naming of the individual or constraints on fulfillment. Will resume there. | Then discussed potential naming of the individual or constraints on fulfillment. Will resume there. |
Latest revision as of 19:09, 3 February 2016
FHIR Workflow Conference Call 3:00PM Eastern Time (Date above)
Return to FHIR Workflow Minutes
Agenda
- Approve Minutes Prior Meeting on 01/27
Attendees
- Lloyd McKenzie (chair/scribe)
- Jose Costa Teixeira
- Oliver Krauss
- Thomas Luaksik
- Yunwei Wang
- Hans Buitendijk
- Marla Albitz
- Rob Hausam
- Don Jorgenson
- Bryn Rhodes
- Garry Dickenson
- John Hatem
Minutes
Motion to approve Jan 27 minutes: Bryn/Jose - unanymous
Workflow Discussion
Discussed the question of where the "desired" fulfiller should be identified when authoring a request.
3 options:
- capture it as an element on the 'request' resource
- capture it within a Task instance contained in the 'request' resource
- have two separate resources - 'request' and Task and use the ability of Provenance to sign two resources to manage the linkage
1. Order fulfillment information (who should do order) as inline elements
<DiagnosticRequest>
<code…/>
<author…/>
<requestedPerformer>
<reference value=”Organization/someLab”/>
</requestedPerformer>
<requestedPerformerType>
<coding>
</coding>
</requestedPerformerType>
…
</DiagnosticRequest>
2. Order fulfillment information as “contained” Task
<DiagnosticRequest>
<id=”request”/>
<contained>
<resource>
<Task>
<subject>
<reference value=”#request”/>
</subject>
<performerType>
<coding>
</coding
</performerType>
<owner>
<reference value=”Organization/someLab”/>
</owner>
</Task>
</resource>
</contained>
<code…./>
<author…/>
…
</DiagnosticRequest>
3. Order fulfiller as independent task instance
<DiagnosticRequest>
<id value=”request”/>
<code…./>
<author…/>
…
</DiagnosticRequest>
<Task>
<subject>
<reference value=”#request”/>
</subject>
<performerType>
<coding>
</coding
</performerType>
<owner>
<reference value=”Organization/someLab”/>
</owner>
</Task>
Decision
We will use explicit elements in the 'request' resource to identify the desired fulfiller or fulfiller type
Then discussed potential naming of the individual or constraints on fulfillment. Will resume there. See: [1]