Profile verse Server Testing/Conformance

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?

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).

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!

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 CARECONNECT-API-STU3\PAS FHIR RESTful Base Conformance - FHIR v3.0.2 )

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.

Yes

(the rabbit-duck makes my head hurt!)

need a picture to help

duckrabbit

1 Like