Enhance profile definitions for slicing

Description

Veel FHIR profielen hebben meerdere waardenlijsten gekoppeld aan één concept in FHIR. Of de profielen specificeren één waardelijst en laten de mogelijkheid open om andere waardenlijsten te koppelen. Om dit mogelijk te maken word in het FHIR profiel het concept gesliced en zodoende per waardelijst gespecificeerd. De validator moet op basis van de descriminator de slices uitelkaar kunnen houden bij het valideren van de daadwerkelijke FHIR resource/instance. De huidige discriminators staan momenteel niet goed ingesteld en moeten rekening houden met de gekoppelde waardenlijsten. In 2015/2016 was hier nog onvoldoende steun voor binnen de beschikbare tooling. Dit lijkt nu te zijn opgelost, zie voor meer informatie de zulip chat op fhir.org.

https://chat.fhir.org/#narrow/stream/179177-conformance/topic/Slicing.20and.20value.20sets

Het gaat om een aanpassing van de discriminator.path met een waarde van system naar $this. 

Dit staat fout bij de volgende profielen:

  • zib-Product

  • zib-AllergyIntolerance

  • zib-FunctionalOrMentalStatus

  • nl-core-careplan

  • zib-BloodPressure

  • gp-DiagnosticResult

  • zib-LaboratoryTestResult-Observation

  • zib-LaboratoryTestResult-DiagnosticReport

  • zib-MedicalDeviceRequest

  • zib-NursingIntervention

  • zib-Procedure

  • zib-ProcedureRequest

  • zib-TextResult

  • zib-Vaccination

  • zib-VaccinantionRecommendation

  • eAfspraak-Appointment

 

Verduidelijking van Impact

Dit zou geen impact moeten hebben op de implementatie van de standaarden bij leveranciers. Het gaat om technische verbeteringen die ervoor moeten zorgen dat de profielen beter gebruikt kunnen worden om te valideren. De validator gaat nu voor fouten wel meldingen geven waar dit eerst mogelijk nog niet zo was. Als echter conform het profiel / specificaties is geimplementeerd zal deze wijziging niets raken.

Proposed solution (NL)

  • Aanpassen incorrecte discriminator.path

  • Aanpassen discriminator.type = pattern

  • Gebruik van patterns op hetzelfde niveau als de discriminator.path in plaats van fixed values

  • Aanpassen ValueSet binding strenght naar required voor coding slices

Proposed solution (EN)

None

Release notes (NL)

Many slicing definitions were incorrect or not working properly, especially slice definitions that are differentiated by bound ValueSets. These slice definitions are now fixed and improved, allowing validators to correctly validate instances.

Release notes (EN)

None

Activity

Show:

Ardon Toonstra July 17, 2020 at 1:48 PM

Former user,

Ik ben alle slicing definities nagelopen. Nog twee foutjes gevonden en deze opgelost in de branch. 

Verder staat het m.i. goed voor de zomerrelease. De slice definities staan nu zo dat er waar mogelijk eerst op basis van system wordt gediscrimineerd wanneer meerdere codesystemen gedefinieerd worden. Wanneer dit niet mogelijk is wordt een slicedefinitie o.b.v. valueset binding gebruikt. Dit lijkt mij zeer goed, aangezien de eerste 'goedkoper' is voor een validator. Dit heb ik ook probeerd te beschrijven in de Profiling Guidelines: https://informatiestandaarden.nictiz.nl/wiki/FHIR_Profiling_Guidelines#Slicing_definitions

Weet jij hoe het nu staat met bovenstaande twee eerdere meldingen?

Als laatste punt kunnen de slice definities verbeterd worden door waar mogelijk naast de code ook het system mee te nemen doormiddel van een pattern slice. Hiervan hebben we besloten dat deze wijziging niet meer voor de zomerrelease te behalven valt. Daarom heb ik die wijzigingen ondergebracht in om met een latere patch release mee te nemen.

Groet,
Ardon

Pieter Edelman July 2, 2020 at 3:22 PM

Feedback van de IG Publisher:

DiagnosticReport/zib-laboratorytestresult-diagnosticreport-01: DiagnosticReport.category (l45/c15)

information

Profile http://nictiz.nl/fhir/StructureDefinition/zib-LaboratoryTestResult-DiagnosticReport, Element 'DiagnosticReport.category.coding[laboratoryTestResultCode]'": Unable to check minimum required (1) due to lack of slicing validation

Pieter Edelman July 1, 2020 at 9:43 AM

Wb. vitalsigns-bloodglucose produceert de IG Publisher de volgende foutmelding op de example instance:

Observation/vitalsigns-bloodglucose-01: Observation.category[0] (l57/c15)

information

None of the codes provided are in the value set http://hl7.org/fhir/ValueSet/observation-category (http://hl7.org/fhir/ValueSet/observation-category), and a code is recommended to come from this value set) (codes = http://snomed.info/sct#49581000146104)

Observation/vitalsigns-bloodglucose-01: Observation (l2/c87)

information

Profile http://nictiz.nl/fhir/StructureDefinition/vitalsign-bloodglucose, Element 'Observation.category[LaboratoryTestResultCode]'": Unable to check minimum required (1) due to lack of slicing validation

Ardon Toonstra March 3, 2020 at 1:48 PM

  • Issue is afgehandeld door FHIR-I : https://jira.hl7.org/browse/FHIR-25206

  • De .NET API wordt momenteel door Ewout Kramer hiervoor ook aangepast. Dit duurt nog wel een aantal maanden voordat het in de validator van Simplifier zit.

  • Nog niet bekend hoe snel dit in de JAVA validator zit.

  • Touchstone heeft aanpassingen in de validator gemaakt.

Volgens mij wordt het tijd om de discriminators en slicing aanpassingen door te voeren. 

Ardon Toonstra December 6, 2019 at 1:32 PM

Besproken op DevDays Amsterdam 2019 met Grahame:

  • Disciminator types value en pattern zullen samengevoegd. Dat wil zeggen, beide types zullen dezelfde functionaliteiten bevatten. Dus een validator check op een fixed, pattern of binding value. 

  • Tooling voor vorige FHIR versie (STU3, R4 ect.) zou dit ook kunnen ondersteunen.

  • Testscases voor de JAVA validator aangeleverd

  • Issue voor de .NET validator: https://github.com/FirelyTeam/fhir-net-api/issues/1185

Resolved
Pinned fields
Click on the next to a field label to start pinning.

Details

Assignee

Reporter

Classification

Informatiestandaard onderdelen

FHIR-package

Information standard

Alle

Priority

Better Excel Exporter

Created August 6, 2019 at 11:31 AM
Updated January 12, 2024 at 12:54 PM
Resolved August 11, 2020 at 2:09 PM