This wiki has undergone a migration to Confluence found Here
Difference between revisions of "FHIR Infrastructure Minutes WGM 201605"
Jump to navigation
Jump to search
Line 10: | Line 10: | ||
==Attendees== | ==Attendees== | ||
− | See [ | + | See [[File:FHIR-I_Attendees_20160509.pdf]] |
*Chair/Scribe for Q1/Q2: Ewout | *Chair/Scribe for Q1/Q2: Ewout |
Revision as of 02:30, 11 May 2016
FHIR Infrastructure Conference Call 3:00PM Eastern Time (Date above)
Return to FHIR Infrastructure Minutes
Agenda
- Mon Q1 - FHIR Tracker items
- Mon Q2 - FHIR Tracker items
- Mon Q3 - FHIR Workflow
- Mon Q4 - FHIR Workflow
Attendees
See File:FHIR-I Attendees 20160509.pdf
- Chair/Scribe for Q1/Q2: Ewout
- Chair/Scribe for Q3/Q4: Lloyd
Mon Q1/Q2
- 9864
- Discussion of use case for reverse chaining queries; syntax; and our process for adding new features to the search API. Decision: some server developers will try this out, seek input from client developers, and see what the experience shows.
- 9814
- 9168
- 9965
- 9108
- 9801
Mon Q3/Q4
- Lloyd presented the outcomes of the FHIR Workflow task force to date
- Discussion:
- Keith: Rename "category" to "stage" when we're talking about requests
- Why are we combining proposal/plan/order?
- Not thrilled with xxxRequest as a name when it's not actually the request, it's the authorization
- Can't call it xxxAuthorization because plans and proposals aren't really authorizations. Open to a better name, but haven't come up with one. Feel free to suggest
- Why do we need a tag?
- Tags are needed to distinguish from request instances that are there as supporting information, background, no-longer actionable from those that are actionable?
- Why not tag the ones that aren't actionable?
- The safest thing is for instances to be non-actionable. Lots of instances will be passed around, situation where they need to be actionable is limited.
- Will the simple "tag-based" approach be considered as valid as using Task?
- Yes. All 4 mechanisms are valid
- Will we define standard operations and messages for doing this?
- Maybe - we haven't really looked at those yet
- We will need lots of examples
- Yes we will. Supplying use-cases and assisting would be appreciated
- Why is reason 0..1 instead of 0..*?
- Could increase. Most existing models use 0..1 - what's 80% for your resource?
- "failed" isn't an ideal status name. Perhaps "aborted"?
- Need to capture reason for statuses other than failure
- Where are things with combining Protocol & Orderset?
- CDS is evaluating it. Lloyd & Bryn think it's a good idea
Worked through slides 5-7 and, after discussion, had no objections other than the ones discussed/addressed above.