Minutes - FHIR Validation Group 2020-05-28

Thursday, 28th May 2020, 09:30 CET

Agenda

• Welcome
• Review and Approve Agenda
• Updates on action items
• Profiling discussion on Observations for vital signs
• Updates on Current projects
  • Communication
  • eAgreement
  • RIZIV/INAMI
• Terminologies (server and specifications) plan
• HL7 Belgium publication scope and schedule

Participants

• Robin Bosman
• Anne Nerenhausen
• Stefan Beerten
• Ingrid Mertens
• Karlien Erauw
• Jose Costa Teixeira (scribe)

Excused

• Stijn Longin
• Isabelle Pollet

Profiling discussion on Observations for vital signs

Observation profiles: We have already a BE profile on observation, question is whether we will have several profiles for each type of observation (e.g. BMI, HC, etc). This will impact profiles for example "Problem" in RIZIV/INAMI

In the Vital signs profile, there is a "magic value" that is used to identify the "observable": https://www.hl7.org/fhir/R4/observation-vitalsigns.html Ingrid explains that this is also a terminology problem: we can use LOINC or SNOMED-CT, and we need some answer for Belgium.

• • Proposal for new work item / Project:**
• FOD Terminology Center could define a Value Set and Concept Maps for "authorized" values in Belgium (including LOINC and SNOMED-CT terms).
• This set of ValueSets and ConceptMaps would make it possible to officially support both LOINC and SNOMED-CT;
• An "authoritative" mapping could be published in Belgium and would help systems do any conversion necessary.
• This would be a phased approach, starting with the most common / easy / preferred codes (up to FOD terminologie to decide).
• HL7 Belgium / eHealth can support this phased approach by publishing the resources (ValueSets and ConceptMaps) as they are approved and subsequent updates.
• The project promoter would handle or delegate any necessary articulation with existing projects.

Next Steps:

• Ingrid to confer with other stakeholders and will get back to HL7 BE when a Project proposal is in order.

Decision on profiles:

• We should not do a lot of profiles just because they **might** be needed - this would be a huge maintenance effort.
• Profiling is not necessary for supporting a feature e.g. Apgar Score - it is already possible to transmit Apgar score even without profiling. What profiling is needed for is to have ONE unique way of sharing that information - to ensure semantic interoperability.
• Profiling will also depend on terminologies (you can only have a Apgar score profile if there is a "magic value" for Apgar score.
• This is therefore a matter of priority: Technical interoperability exists without profiling, but semantic interoperability requires profiling - Projects should decide what profiles are needed to ensure consistency, knowing that this means additional effort (one more profile, some examples, test data, and respective maintenance etc.)
• We should as much as possible use the HL7 FHIR Profiles (either simply reusing or sub-profiling as needed): in other words, we should **not** create a new profile for body weight if one already exists in FHIR.
• If in Belgium we need a profile that does not exist in the HL7 standard, we can make our own (but we should always check with the international community if there is anything).
  • Belgium can also propose profiles to become HL7 International standard profiles e.g. if we make a BE Apgar score, we can suggest that to the International community so that it becomes an international standard profile.

Updates on current projects

• Communication - scheduled for next WGSE meeting, no need to update for now.

• eAgreement - work is ongoing - on content and publication, no updates for now.

• RIZIV/INAMI - work is ongoing - on content and publication
  • will be presented to WGSE on 12th June: Addiction, Patient Will, Vaccination.
  • Discussion with ONE on examples will be used to start validating the profiles
  • Vaccination:
    • Value Sets: We will define a value set for Belgium to exclude all the variations of "no consent" e.g. "no consent for pertussis" because this is redundant (if the vaccine is for pertussis the reason not given "no consent" is obvious "no consent for pertussis") and this require us to make a lot of codes.
    • Even sub-codes like "No consent - school exit vaccinations (171286000)" is too detailed and for us "no consent" is sufficient.

There is a SCT concept of "Immunization consent not given" 310376006 - and that is the granularity that we want to use.

• • • The profile will capture that this is a reason for not giving THIS vaccination, but we do not capture whether this is a specific vaccine refusal for this disease or a generic "no vaccination" refusal.
  • Immunization.VaccineCode is too specific in some cases and this can cause issues e.g. if the code is for "intranasal" and the patient takes it orally.
• These "less granular" value sets are useful for sharing information across different applications, and are a good candidate for federal standard value sets.
  • RIZIV/INAMI has a own Implementation Guide, and this is a good approach for all projects to follow, because it is a self-sufficient and self-validating package with all that is needed for a project (without contaminating the Federal or HL7 publications with the project-specific details).
  • Jose will propose the same approach to DZOP

Next meetings

We should stick to Thursday mornings. Next meeting on 11th at 9:30. Jose will send the agenda by June 5th

HL7 Belgium Validation Workgroup