This wiki has undergone a migration to Confluence found Here
Difference between revisions of "FHIR Workflow Minutes CC 20160406"
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 | + | *Approve [[FHIR Workflow_Minutes_CC_20160404| Minutes Prior Meeting on 04/04]] |
==Attendees== | ==Attendees== | ||
| − | * | + | *Lloyd McKenzie (chair/scribe) |
| − | * | + | *Andrea Pitkus |
| + | *Reinhard Egelkraut | ||
| + | *Chethan Makonahalli | ||
| + | *Jose Costa Teixeira | ||
| + | *Scott Robertson | ||
| + | *John Hatem | ||
| + | *Julia Chan | ||
| + | *Gary Dickinson | ||
| + | *Thomas Lukasik | ||
| + | *Rob Hausam | ||
| + | *Chris Grenz | ||
| − | == | + | ==Minutes== |
| − | + | Motion to approve minutes of Apr. 4: Jose/Thomas: 8-0-3 | |
| − | == | + | ==Composite Orders== |
| − | + | *Raised the question of whether anyone on the call could think of a use-case for having instances representing the parent order | |
| + | *Looked at the v2 ORC segment. Our notion of parentIdentifier corresponds to ORC.4 (Placer Group Number) and our notion of basedOn corresponds to ORC.8 (Parent Order). So we seem to be consistent with v2 | ||
| + | *Composite orders are orders that have "components". This is different than an order that might spawn reflex orders - those are linked using "basedOn" because they are created to partially fulfill the original order. | ||
| + | *Looked at a diagram put together by Julia. Julia will update it to make use of Task instead of Order/OrderResponse. | ||
| + | ==Future Agendas== | ||
| + | *Monday Apr. 11: Discuss scope and overlap of OrderSet and Protocol w/ Bryn, as well as whether we should use the existing "request" resources to provide the detail or come up with a different approach. (Other options are one "protocol" resource for each request resource, some smaller number of protocol resources or moving the clinical details directly into OrderSet or Protocol.) | ||
| + | *Wednesday Apr. 13: Walk through a lab scenario involving multiple nested panels to ensure that we capture sufficient information to support existing business processes if we only record leaf-level orders and not any "parent" orders | ||
==Adjournment== | ==Adjournment== | ||
Latest revision as of 04:12, 7 April 2016
FHIR Workflow Conference Call 3:00PM Eastern Time (Date above)
Return to FHIR Workflow Minutes
Agenda
- Approve Minutes Prior Meeting on 04/04
Attendees
- Lloyd McKenzie (chair/scribe)
- Andrea Pitkus
- Reinhard Egelkraut
- Chethan Makonahalli
- Jose Costa Teixeira
- Scott Robertson
- John Hatem
- Julia Chan
- Gary Dickinson
- Thomas Lukasik
- Rob Hausam
- Chris Grenz
Minutes
Motion to approve minutes of Apr. 4: Jose/Thomas: 8-0-3
Composite Orders
- Raised the question of whether anyone on the call could think of a use-case for having instances representing the parent order
- Looked at the v2 ORC segment. Our notion of parentIdentifier corresponds to ORC.4 (Placer Group Number) and our notion of basedOn corresponds to ORC.8 (Parent Order). So we seem to be consistent with v2
- Composite orders are orders that have "components". This is different than an order that might spawn reflex orders - those are linked using "basedOn" because they are created to partially fulfill the original order.
- Looked at a diagram put together by Julia. Julia will update it to make use of Task instead of Order/OrderResponse.
Future Agendas
- Monday Apr. 11: Discuss scope and overlap of OrderSet and Protocol w/ Bryn, as well as whether we should use the existing "request" resources to provide the detail or come up with a different approach. (Other options are one "protocol" resource for each request resource, some smaller number of protocol resources or moving the clinical details directly into OrderSet or Protocol.)
- Wednesday Apr. 13: Walk through a lab scenario involving multiple nested panels to ensure that we capture sufficient information to support existing business processes if we only record leaf-level orders and not any "parent" orders
