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
(Created page with "{{subst::FHIR Workflow Template for Minutes}}")
 
 
(2 intermediate revisions by the same user not shown)
Line 5: Line 5:
 
[[:Category:FHIR Workflow Minutes|Return to FHIR Workflow Minutes]]
 
[[:Category:FHIR Workflow Minutes|Return to FHIR Workflow Minutes]]
 
==Agenda==
 
==Agenda==
−
*Approve [[FHIR Workflow_Minutes_CC_yyyymmdd| Minutes Prior Meeting on mm/dd]]
+
*Approve [[FHIR Workflow_Minutes_CC_20160127| Minutes Prior Meeting on 01/27]]
  
 
==Attendees==
 
==Attendees==
−
*??? (chair)
+
*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
  
−
==Agenda Item 1==
+
==Minutes==
−
Goes here
+
Motion to approve Jan 27 minutes: Bryn/Jose - unanymous
  
−
==Agenda Item 2==
+
==Workflow Discussion==
−
Goes here
+
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
 +
 +
<code>
 +
1. Order fulfillment information (who should do order) as inline elements
 +
<DiagnosticRequest>
 +
  <code…/>
 +
  <author…/>
 +
  <requestedPerformer>
 +
    <reference value=”Organization/someLab”/>
 +
  </requestedPerformer>
 +
  <requestedPerformerType>
 +
    <coding>
 +
      <code value=”internal”/>
 +
    </coding>
 +
  </requestedPerformerType>
 +
  …
 +
</DiagnosticRequest>
 +
 +
2. Order fulfillment information as “contained” Task
 +
<DiagnosticRequest>
 +
  <id=”request”/>
 +
  <contained>
 +
    <resource>
 +
      <Task>
 +
        <subject>
 +
          <reference value=”#request”/>
 +
        </subject>
 +
        <performerType>
 +
          <coding>
 +
            <code value=”internal”/>
 +
          </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>
 +
      <code value=”internal”/>
 +
    </coding
 +
  </performerType>
 +
  <owner>
 +
    <reference value=”Organization/someLab”/>
 +
  </owner>
 +
</Task>
 +
 +
 +
</code>
 +
 +
===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: [http://wiki.hl7.org/images/6/6b/Request_resource_template.docx]
  
 
==Adjournment==
 
==Adjournment==

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

Retrieved from "https://wiki.hl7.org/w/index.php?title=FHIR_Workflow_Minutes_CC_20160201&oldid=114620"