Profile verse Server Testing/Conformance

FHIR
1

In FHIR we talk a lot about profiles and the specs suggest we put add the profile to our resource

 "meta": {
    "lastUpdated": "2018-09-14T08:44:09.570+00:00",
    "profile": [
      "https://fhir.hl7.org.uk/STU3/StructureDefinition/CareConnect-Observation-1"
    ]
  },

That is meant to show I have built a resource conforming to that profile. It’s also a nice convenient way of testing using the FHIR Validator. Some systems may choose to act on the profile, maybe routing?

But if I don’t make this profile claim it doesn’t mean my resource isn’t valid or it isn’t a CareConnect-Observation-1 resource. I’ve just not made the claim.

On my server that’s receiving this resource I would want to make sure I am getting valid input. I’d probably have a policy that all incoming Observation resources MUST be CareConnect-Observation-1. I may even go further on some servers, lets say my server doesn’t support LOINC and the code has to be SNOMED or OPCS-4, I’d create a profile MyServer-Observation-1 that enforces this and want to check all Observations follow this rule.

Anyway it seems the conformance claim is an optional requirement as systems will test/validate themselves (or should be recommended to).

I’ve just built a system that follows this rule but I’m aware of people pushing for the profile rules to be in the resource. Who is correct?

2

There are problems if you say “things are only valid to X if they state they are valid it X”.

When Y comes along (with a similar rule), which is 100% compatible with X, all your instances won’t be valid to Y, even though they are.

You would either have to re-visit every instance to update it (add the declaration of Y), or admit this is pointless and just check whether things really are valid to X or Y as needed.

Given that the assertion of “valid against X” is just that - an untested assertion - it doesn’t mean much anyway.

So it seems mandating the declaration adds little and causes problems (of valid things appearing to be invalid).

3

Recommendation from GG re: environment containing multiple FHIR versions is that it is much harder to manage if you assert conformance to particular profiles so don’t do it unless you need to.

I would echo Rik’s comments around the difference between conformance with a profile and an assertion of conformance with a profile. There is practical value in duck-typing!

4

So from a FHIR Implementation (Guide) perspective I would be saying my server conforms to both:

careconnect.api.stu3#3.0.0 (or visually this page https://kevinmayfield.github.io/careconnect-api-stu3/CapabilityStatement-pas.html )

careconnect.base.stu3#3.0.0 conformance (CARECONNECT-BASE\Care Connect Base STU3 Implementation Guide - FHIR v3.0.2) as the previous guide dependsOn this.

My server would check this. So even if resources I receive say they are a rabbit.

If it walks like a duck, swims like a duck, and quacks like a duck, then it probably is a duck.

5

Yes

(the rabbit-duck makes my head hurt!)

6

need a picture to help

duckrabbit

1 Like