Date: 2020-02-27 

Facilitator:  Anthony Julian

Note Taker: Anthony Julian

Join the online meeting:


XMayo Clinic
XUnited Healthcare

Kaiser Permanente
XVernetzt, LLC
X Altarum     
XKnapp Consulting
XScott M. RobertsonKaiser Permanente

Agenda Topics

Agenda Outline
Agenda Item
Meeting Minutes from Discussion
Decision Link(if not child)
Management Minute Approval
  • Minutes from WGM - Q1 and Q2
    • hold on project status
    • accepted by general consent

MethodologyGuidance for data sharing (30 Minutes?)
  • see link to document below
  • added comments from PH persepctive

  • point of this document is trying to describe when to use REST, when to use messaging, when to use communicationRequest etc.

  • VA tried to review the document and found similar issues as PH

  • there were strong assumptions of usage being mixed in with the definititions - working on trying to separate the definitions and then make a more neutral

  • We really like the idea of the intent of the document, but think it needs to make a more clear distinction and be better organized

  • Highlight the difference between the content models and separate that from the exchange mechanisms

  • guidance around buisness situations when a particular exchange method

  • process for task or messaging - that is when information should be processed in all other situations

  • Examples

    • send claim via CRUD - just store

    • send claim to insurer, then I want them to process it = request/response paradigm

  • bundles are packaging mechanism when you need to send multiple things together

  • the viewpoint of this document should be the business view before the techincal approaches, we don't think this is ready for inclusion yet

  • indicate that something needs to happen = task / operation

  • so using task, when sending a claim and expecting the insurer to process them will be too much overhead, while in other more involved actual workflows task is very helpful

  • Conformance is working on how to better check for conformance in FHIR - how to properly express sender and receiver requirements in conformance

  • Exchanging Resources link on the FHIR resource page - that is where this content should eventually live = 
  • in FHIR server can send to client, client cannot send to server, but server cannot send to server (but these are actors), so the same organization must support both servers and clients to act as sender and receiver
  • the only way to use subscription would be to have everyone subscription to everyone, but that is hard to do, hence the use of clearing houses and intermediaries
  • need to make sure we don;t try to use the same tool for ALL business cases, when it doesn't make sense
  • Next steps:
  • should we add comments to the document

  • re-organize the document

  • should we create something different?

    • like a table that shows all the different aspects to consider = Data sharing matrix

    • add on use cases after that that could then have specific guidance = business circumstances

    • trying to find examples for the criteria column:

    • response required - short lived

    • response required - long lived

    • response required - single

    • response required mulitple

    • broadcast

    • processing instructions inclided in communication

    • outside of communication defined processing

  • Created matrix: See Data Sharing matrix
    • to edit the spreadsheet in the confluence page: click on EDIT, make changes in the spreadsheet, make sure you save before closing the spreadsheet and then update the confluence page

MethodologyV2 Quality Criteria ReconciliationPOSTPONED TO NEXT CALL
MethodologyAscii Character set GF25232
  • HL70396 update:
  • Suggest to delete the word ASCI from the description and the comment column and also fix the last sentence, which is not complete for 99zzz or L:
  • In description change: The 'zzz' SHALL be any printable ASCII string.  to: The 'zzz' SHALL be any printable string.
  • In comments change: The 'zzz' may be any printable ASCII string of variable length, but the recommendation is to generally use only numbers and upper
    to: The 'zzz' may be any printable string of variable length, but the recommendation is to generally use only numbers and upper case.
  • There are languages that don't have upper case - so remove the part of the sentence after the comma.
  • Do we need to mention alternative charactersets like unicode, but it could be others? - better not
  • This table is only used as ID datatype so that takes care of allowing white spaces
  • Proposal:
    • Remove ASCII from the description and Comment, and fix the last line of the comment. e.g.
    • The 'zzz' may be any printable ASCII string of variable length as restricted by the ID datatype., but the recommendation is to generally use only numbers and upper case. (Case is added)
  • There is an issue with the HL70396 content in V2.9 vs the webpage - we need a single source of truth
  • Defer to next teleconference and let Ted know to update the web

MethodolodyV2 Mgmt referred: GF15630
  • gForge ticket has the original proposal attached
  • Research and defer to next tcon

Management Next agendaSend email to Tony, if NOT making call in 2 weeks
 Adjourned at 4:01 PM ET

Supporting Documents

Outline Reference
Supporting Document
Minute Approval

2020 InM Sydney WGM Q1 Agenda/Minutes

2020 InM Sydney WGM Q2 Agenda/Minutes

Guidance for Data SharingGuidance for data sharing
Quality Criteria ReconciliationV2 Quality Criteria Ballot Reconciliation
Ascii Character set GF25232
V2 Mgmt referred: GF15630

Action items