Minutes - FHIR Validation Group 2021-01-21

From Health Level 7 Belgium Wiki
Revision as of 11:39, 21 January 2021 by Jose Costa Teixeira (talk | contribs) (Created page with "Thursday, 21st January 2021, 10:00 CET = Agenda = * Welcome * Review and Approve Agenda * AllergyIntolerance (Encounter / RelatedPerson) * Overall roadmap / upcoming profiles...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

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)

  • 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

Process review - WGSE validation - sequential?

BeHomeCarePlan and BeHomeCareTeam - outstanding issues pointed by Robin/eHealth

HL7 Belgium Validation Workgroup