Stream: implementers
Topic: Validating references
Jeremy Chapman (Sep 12 2019 at 15:44):
Many properties in FHIR resources are either literal, relative, internal or absolute references to other resources, and usually they type of resource being reference is constrained based on the source of the reference. For example the MessageHeader.destation.reciever is a reference to a Practitioner or PractitionerRole or Organization, but not other types. In this example, if MessageHeader.destation.reciever references a resource within the same bundle, schema validation can not ensure that the reference is to an allowed resource type. What is the typical mechanism for that level of validation? Are there published schematron rules or other approaches that can validate these constraints?
Grahame Grieve (Sep 12 2019 at 15:45):
there's a mode where you can ask the java validator to validate the type of the target reference
Jeremy Chapman (Sep 12 2019 at 16:06):
What does it use to validate, under the hood? is it schematron?
Grahame Grieve (Sep 12 2019 at 16:07):
no it's java code.
Grahame Grieve (Sep 12 2019 at 16:08):
but it will only work if the validator can actually resolve the reference. Which it can't, for instance, on a production secure interface
Lloyd McKenzie (Sep 12 2019 at 17:53):
There's lots of validation that can't be done by schema and a fair bit that can't be done by schematron. The HL7 java validator is the most complete code we have for checking instances.
Jeremy Chapman (Sep 12 2019 at 18:22):
I don't have a lot of schematron experience, but I do know that it provides a re-usable and componentized set of rules, which can be consumed in a number of environments. I suspect the instance checking is something that schematron just can't do, which is a shame. We're building in a .net environment. is there anything readily available?
Brian Postlethwaite (Sep 12 2019 at 22:19):
Yes, the fhir dotnet client has a vidator too.
It's in the NuGet package HL7.FHIR.SPECIFICATION.R4 or whichever version you need.
Last updated: Apr 12 2022 at 19:14 UTC
