Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.


Agenda Outline
Agenda Item
Meeting Minutes from Discussion
Decision Link(if not child)
Management Minute ApprovalApproved by general consensus
MethodologyV2 Quality Criteria Block vote

postpone to next call

MethodologyDaVinci Notification Block Votes #2

Block Vote 2

MethodologyDaVinci Notification Block Vote #3

Block Vote 3

Discussion around the pulled items:

J#26134 (Use SMART Backend Services.) (Isaac.Vetter) :

  • FHIR’s defacto security layer is SMART’s profile of OATH2
  • Issac wants to have a specific mechanism declared
  • FHIR messaging can use the FHIR RESTful transactions, so then we should be using SMART’s profile of OATH2
    • http will be supported by that
  • But FHIR messaging can be done other ways
  • For http transactions we should point to SMART’s profile of OATH2
  • Since DaVinci is trying to have a combined approach to security
  • Migrate this over to the working group that is working on the overall DaVinci security decision

J#26134 J#26135 (Flesh out the Security page. Use SMART Backend Services. ) (Isaac.Vetter)

  • This security page should point to the broader DaVinci security approach
  • Do the same as above so that that can be addressed there

MethodologyDa Vinci question around messageHeaderEventCode
Suggestion is to rename the code descriptions  in MessageHeaderEventCode = 
the question to InM is that intended to be more like the trigger event in V2 or the entire messagetype +trigger event?
the commenter is looking for descriptions of the business event that trigger the notification, but we currently include notification in the code (essentailly we created a hierarchical code system to represent both the type and the trigger)


Intent of this field MessageHeaderEventCode is to describe the event = so a notification is a different event than the sending of a lab report for example - notification is about something to get awareness, not the same as sending a report for example - so code system can be redued to just notification - drop off the admit / discharge / lab result etc

the reason for the event can be communicated in another field of the messageHeader resource = that is what triggers the notification - the valueset here is externally defined - this would codify the trigger reasons - it is currently optional

There is some discussion around creating a new notification bundle – which will be at the bundle definition, so then we need to no longer worry about the notification being in the event code; or the maybe even a new resource

Zulip chat link:

we need to let people know that we need to stop notification handling be a moving target

The decision tree confirmed use of messaging - see here: 

Google Drive Live Link

MethodologyGuidance for data sharing

Looking at the matrix

Not sure what is meant by “receiver expectations of sender”

CRUDSH = Create – Read – Update – Delete – Search - History


Implicit query by subscription = same as query, except the transaction and the message become the payload

Multiple responses – short lived = similar to ACKs – accept and application level, but not longer than that

Multiple responses – long lived example would be order workflow, where you get updates along the way of the progress on the ordered item

Management Next agenda

Next meeting is in 2 weeks – April 23

Please email the chair at least 6 PM the night before can add to agenda – will share block vote ahead of time

 Adjourned at 3:55 PM ET