Skip to end of metadata
Go to start of metadata

Agenda

  • Approve (minutes from previous meeting)

Attendees

  • Lloyd McKenzie (chair/scribe)
  • Bryn Rhodes
  • John Hatem
  • Ricardo Quinano
  • Vassil Peytchev
  • John Moehrke
  • Bas van den Heuvel

Joined late

  • Jose Costa Tiexeira

Minutes Approval

BPMN+

  • Reviewed  FHIR-28410 - ServiceRequest relation to ActivityDefinition and PlanDefinition is ambigue TRIAGED
    • Request:
      1. was generated from (but isn't necessarily conformant with): instantiatedFromCanonical/instantiatedFromUri
        • use Provenance (derivedFrom)
      2. came into being because of: reason? trigger? triggeringCanonical/triggeringUri
        • No consensus on word 'triggering'
      3. request complies with (i.e. statement about the properties of the request and alignment w/ definition): conformsToCanonical/conformsToUri
        • This is hard to evaluate because it's rarely about just the one instance - all of the context around the instance also matters because that drives the if/then/else behavior of the protocol
        • Not clear that anyone wants/needs this?
        • If captured, it would typically be done w/ measures, Observations, etc.
      4. fulfillment shall comply with (i.e. demand about the properties of the fulfilling event(s)): complyWithCanonical/complyWithUri

Discussion: look at merging #1 & 2 and acknowledging intrinsic ambiguity

No need for #3 as a relationship - handle using other resources

Add extension to support #4?

  •  
    • Event:
      • came into being because of: triggeringCanonical/triggeringUri
      • complies with (i..e statement about the properties of the event and alignment w/ definition): conformsToCanonical/conformsToUri
      • ??? instantiatesCanonical/instantiatesUri
  • Adherence - where patient is wrt the pathway - i.e. wrt workflow
  • Compliance - where the patient is at wrt a specific step - typically more protocol driven


Adjournment

15:00 Eastern