# Profile verse Server Testing/Conformance

**Category:** [FHIR](https://openhealthhub.org/c/fhir/31)
**Created:** 2019-12-11 12:41 UTC
**Views:** 1152
**Replies:** 5
**URL:** https://openhealthhub.org/t/profile-verse-server-testing-conformance/2160

---

## Post #1 by @mayfield.g.kev

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

```json
 "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?

---

## Post #2 by @riksmithies

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

---

## Post #3 by @dunmail

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!

---

## Post #4 by @mayfield.g.kev

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 (https://interopen.github.io/careconnect-base-stu3/) 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.

---

## Post #5 by @dunmail

Yes

(the rabbit-duck makes my head hurt!)

---

## Post #6 by @mayfield.g.kev

need a picture to help

![duckrabbit|183x275](upload://2MYVJ9B3egkxnbRz5PVnfm9Fp1l.jpeg)

---


**Canonical:** https://openhealthhub.org/t/profile-verse-server-testing-conformance/2160
**Original content:** https://openhealthhub.org/t/profile-verse-server-testing-conformance/2160