This wiki has undergone a migration to Confluence found Here
<meta name="googlebot" content="noindex">

Difference between revisions of "FHIR Workflow Minutes CC 20160201"

From HL7Wiki
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 in the 'request' resource
+
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

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]

Adjournment