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}}")
 
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
 +
 
 +
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==

Revision as of 18:47, 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

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=114617"