FHIR Chat · Validating without conformance claims · implementers

Stream: implementers

Topic: Validating without conformance claims


view this post on Zulip Ward Weistra (Jul 09 2020 at 10:23):

@Grahame Grieve A broad question: I appreciate the point you make, for example at the Sydney WGM, that servers should not rely on meta.profile conformance claims for their validation. A Dutch hospital system should not refuse a patient instance just because it claims to conform to the German Patient profile, it should test whether it conforms to the Dutch Patient profile to see if it has everything it needs to work with it.

However, is there any way around meta.profile conformance claims for the resources that are more likely to have a large number of profiles, like Observation or DiagnosticReport? How would a server know that this Observation instance is meant by the sender as a BP Observation without the conformance claim? How can a Dutch hospital accept a BP observation that only claims conformance to a German BP Observation profile or no profile at all?

Some imperfect ideas:

  1. Test it against any Observation profile and see what validates. This might lead to multiple matches though, besides being costly.
  2. Build a set of rules in the server that will guide instances based on base resource and codes in the instance to the right profile to validate against.
  3. Perhaps IF it has a claim to the German BP profile you could do some 'most recent common ancestor' search to find the best matching profile in my server...

view this post on Zulip Grahame Grieve (Jul 09 2020 at 10:40):

we talked about this an agree that we're going to define an extension for a CapabilityStatement so that a server can declare what properties of a resource map to which profiles

view this post on Zulip Jens Villadsen (Jul 09 2020 at 11:01):

@Grahame Grieve did you ever write that blog post that stated the issues that you believe exists when declaring profiles?

view this post on Zulip Grahame Grieve (Jul 09 2020 at 11:34):

no it's still on my todo list. Don't worry. It's getting shorter by the day

view this post on Zulip Grahame Grieve (Jul 09 2020 at 11:34):

by a negative number

view this post on Zulip Ward Weistra (Jul 09 2020 at 15:09):

@Grahame Grieve Interesting, thanks. So the server is going to declare those rules (with FHIR Path?) I mentioned as 2., like: "If your base resource is Observation and your code is this SNOMED code I'm going to treat you as a BP Observation"?

view this post on Zulip René Spronk (Jul 09 2020 at 15:14):

But even if you have some properties that help a server in determining which profile, or which set of profiles, is likely to apply, one would still have to do Ward's step 1. So that's kind of creating an index to make step 1 less costly.

view this post on Zulip Grahame Grieve (Jul 09 2020 at 20:42):

@Ward Weistra yes
@René Spronk yes, but it's very much less costly

view this post on Zulip Grahame Grieve (Jul 09 2020 at 20:43):

if people have better ideas, we're all ears

view this post on Zulip Richard Townley-O'Neill (Jul 16 2020 at 06:42):

Ward Weistra said:

How would a server know that this Observation instance is meant by the sender as a BP Observation without the conformance claim?

It has to recognise one of the values of Observation.code as a code for BP, if it does not recognise code, it can do little.

How can a Dutch hospital accept a BP observation that only claims conformance to a German BP Observation profile or no profile at all?

It tests every observation with a code that it recognises as being a code for BP against its own BP profile


Last updated: Apr 12 2022 at 19:14 UTC