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

FHIR Infrastructure Minutes WGM 201605

From HL7Wiki
Revision as of 02:30, 11 May 2016 by Lmckenzi (talk | contribs)
Jump to navigation Jump to search


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

  • 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.

Adjournment