Skip to end of metadata
Go to start of metadata

Date: 20200409  

Facilitator:  Anthony Julian

Note Taker: Ulrike Merrick

Call Info:


XMayo Clinic
XUnited Healthcare
XKaiser Permanente
XVernetzt, LLC / APHL
X Altarum     
XMichelle BarryAvaility

Create Decision from template

Agenda Topics

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#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:   

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

Supporting Documents

Outline Reference
Supporting Document
Minute Approval2020-03-26 InM WG Agenda/Minutes
DaVinci Notification Block Votes #2

Block Vote 2 Motion to accept as distributed by Riki Merrick / Craig Newman / Sandy Stuart 3-0-1

Jira Issue (Summary) (Reporter) Resolution

  1. J#26633 (fix link from question J#26246) (ehaas) Persuasive
  2. J#26290 ("Move ""Mandatory and Must Support Data Elements"" to a ""Guidance/Framework"" page.") (seanmcilvenna) Not Persuasive
  3. J#26289 ("Suggest removing 0..0 constraints, or clarifying why 0..0 is required for use-case in the profile description") (seanmcilvenna) Not Persuasive with Modification
  4. J#26288 (Limit MessageHeader.focus to Reference(Encounter)?) (seanmcilvenna) Persuasive with Modification
  5. J#26284 ("Great ""Figure 3"" diagram!") (seanmcilvenna) Considered - No action required
  6. J#26265 (fix typo) (RikiM) Considered - Question answered
  7. J#26247 (fix link2) (RikiM) Considered - Question answered
  8. J#26246 (fix link) (RikiM) Considered - Question answered
  9. J#26230 (encounter dx on admit needed?) (rberge) Not Persuasive with Modification
  10. J#26160 (clarify must support rules2) (emmanurse) Not Persuasive
DaVinci Notification Block Vote #3

Jira Issue (Summary) (Reporter) Resolution Riki/Sandy - as adjusted.  3-0-1

  1. J#26268 (I suggest to deprecate the child codes (Level 3) 2) (RikiM) Persuasive
  2. J#26267 (I suggest to deprecate the child codes (Level 3)) (RikiM) Persuasive
  3. J#26226 (terminology urls and VSAC) (rhausam) Considered for Future Use
  4. J#26218 (Exchange of quality data or notifications?) (rquintano) Persuasive with Modification
  5. J#26206 (No Sender in Figure 2) (nradov) Persuasive
  6. J#26204 (Provide graph definition for common ADT transactions) (ioana13) Not Persuasive
  7. J#26202 (clarify must support rules3) (klsalzman) Persuasive with Modification
  8. J#26190 (post receiver steps) (pknapp) Persuasive with Modification
  9. J#26176 (Reliable Delivery - Unreachable Scenarios) (ginocanessa) Persuasive with Modification
  10. J#26171 ("STU Note should reference/address FHIR Subscriptions, not just Argonaut project") (ginocanessa) Not Persuasive with Modification
  11. J#26168 (add and min =1) (ehaas) Persuasive
  12. J#26167 (add contained as aggregatiion option to profiles1.) (ehaas) Not Persuasive
  13. J#26165 (Update Note to Balloters text to guidance) (ehaas) Persuasive with Modification
  14. J#26163 (MH-Discharge profile is too restrictive) (ehaas) Persuasive
  15. J#26162 (MH-Admit profile is too restrictive) (ehaas) Persuasive
  16. J#26158 (Encounter.diagnosis.condition ?) (craig.newman) Persuasive
  17. J#26157 (make Encounter singular) (craig.newman) Persuasive

Both pulled items will be reassigned  to the appropriate Work Group  Riki Merrick / Sandy Stuart.  5-0-0

Pulled: J#26135 (Flesh out the Security page. Use SMART Backend Services. ) (Isaac.Vetter) Considered for Future Use

pulled: J#26134 (Use SMART Backend Services.) (Isaac.Vetter) Persuasive with Modification

Guidance for data sharing

Matrix: Data Sharing matrix

 Data Sharing Google document

Data Sharing Decision Tree

Action items