Minutes - FHIR Validation Group 2021-01-21

Thursday, 21st January 2021, 10:00 CET

Agenda

• Welcome
• Review and Approve Agenda
• AllergyIntolerance (Encounter / RelatedPerson)
• Overall roadmap / upcoming profiles
• Terminology updates
• Process review - WGSE validation - sequential?
• BePatient remarks
• BeHomeCarePlan and BeHomeCareTeam - outstanding issues pointed by Robin/eHealth

• Cookbooks

Participants

• Robin Bosman
• Hanne Vuegen
• Karlien Erauw
• Stefan Beerten
• Anne Nerenhausen
• Dieter Ketels
• José Costa Teixeira
• Ingrid Mertens
• Félix de Tavernier

Minutes

AllergyIntolerance (Encounter / RelatedPerson)

• • By default, all standard FHIR servers support the base FHIR resources, and can validate those resources against profiles, IF we have profiles. If we don't have a profile, the server will support the resource AS IS in the FHIR specification. This is the "normal" behaviour.
  • Example: BeAllergyIntolerance has a reference to Encounter, but there is no BeEncounter. This means:
    • it IS possible to have a VALID BeAllergyIntolerance with a reference to an Encounter. For example
      • http://build.fhir.org/ig/hl7-be/hl7-be-fhir/AllergyIntolerance-allergyintolerance-encounterReference.json.html
      • http://build.fhir.org/ig/hl7-be/hl7-be-fhir/AllergyIntolerance-allergyintolerance-encounterReference-contained.json.html
• Our standardisation approach is:
  • All our resources can use (unless excluded) the FHIR core resources. for example, BeAllergyIntolerance can refer to Encounter.
  • If the reference is not "Must Support", implementers are free to exlcude it from their implementation
  • If the reference is "Must Support", implementers mush support the core FHIR profile
    • This is standard behaviour, see above.
  • We can add a BeXXX (e.g. BeEncounter) not when it is referred by a BeProfile, but when we need to add contraints that must be followed by all implementations - for example if we wanted to make that ALL encounters, contained or not, have a startDate, this might justify a BeEncounter profile.
  • RelatedPerson is in the same situation - it is in .asserter which is "must support". This means that the implementers must support the base RelatedPerson, and we don't need a dedicated profile

BePatient remarks

• We currently have BePatient with a mandatory gender. This is not currently a problem, but we may need to revisit this if we want to make a difference between "Definitional" and "Transactional" patient records - i.e. a definition of a patient SHALL have a gender, but if it's used in a transaction - like a contained resources - maybe it does not need to have gender - would it be another profile, or simply revert to the core Patient. (Maybe this requires that all references should have Patient in addition to BePatient).
  • Gender can be many things - biological, social, etc. In our profile, we make an assumption:

• MustSupport for name: there is no issue with privacy - the current rule for Belgium "Must Support" says that a field may be absent (or may be skippped upon reception), if there are valid reasons for that, for example privacy.
  • To Do: Add this to the beginning or somewhere in every BE Implementation Guide. José + Robin.

Overall roadmap / upcoming profiles

** José to change the page "Procedure Referral" in the wiki top "Referral Prescription"

• • BeProblem is a new profile, and in the future we will have changes - but those changes will be on valuesets, so we don't need to rework the whole Logical Model, profile, etc. Sometimes these values will just be bound - for example by limiting this to "SNOMED descendants of Finding".

Terminology updates

We will setup a meeting to explore the collaboration process, using Allergy as example

BeHomeCarePlan and BeHomeCareTeam - outstanding issues pointed by Robin/eHealth

HL7 Belgium Validation Workgroup