Minutes - FHIR Validation Group 2021-01-21
From Health Level 7 Belgium Wiki
Thursday, 21st January 2021, 10:00 CET
- 1 Agenda
- 2 Minutes
- 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
- Robin Bosman
- Hanne Vuegen
- Karlien Erauw
- Stefan Beerten
- Anne Nerenhausen
- Dieter Ketels
- José Costa Teixeira
- Ingrid Mertens
- Félix de Tavernier
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
- 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
- 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".
We will setup a meeting to explore the collaboration process, using Allergy as example