Stream: implementers
Topic: Profile conformance - resource or server controlled?
Kevin Mayfield (Nov 15 2019 at 06:33):
In the UK we are getting a lot of resistance to having many profiles.
As a developer I'm guilty of this, I can easily get lost in profiles and what I want to do is build one resource and use it many times.
So my resource conforms to a UK core profile but in reality its conformant to many more.
When I worked on the uk sandbox (resftul), I followed this and endpoints validated against uk core profiles ignoring the profile stated in the resource.
We also have a lot of message and document based specifications in the NHS in England. This is where I believe the anti-profile comments are coming from. The specs have a focus around profiles, in particular the message appears to be build this and this profile.
Here I feel we have made a mistake and we should be saying this is how you build a message or document (using GrapDefinition) and you resources should validate against these profiles.
Profiles are rules not building instructions.
(building is done in practice using fhir site and uk sandbox)
The last bit goes back to the restful pattern where the resource was validated against the servers requirements. In this latter pattern, the bundle is validated against the profiles listed in graphdefintions (the graphdefintion controls validation).
So validation is not controlled by the resource (it can be, it's useful during early development).
It's also key that a validation service is provided to check conformance to the rules (profiles). This is primarily how a developer discovers they are not following profiles (they are unlikely to trawl profiles, they will use them when they find an error).
René Spronk (Nov 15 2019 at 08:43):
A resource could simply declare conformance to a GraphDefenition and be done with it. Having the server ignore a declared profile/GraphDefintion sounds bad practice to me, as there will surely be multiple version of (e.g. a message) GraphDefenition over time. As such only the client can label the instance with the correct GraphDef url.
Kevin Mayfield (Nov 15 2019 at 08:47):
The server should be able to reject resources that it doesn't support. E.g. a resource may say it supports vital-signs, the server doesn't support LOINC and so enforces a profile that requires SNOMED code to be present.
Kevin Mayfield (Nov 15 2019 at 08:47):
So the the vital-sign resource would be rejected.
René Spronk (Nov 15 2019 at 08:49):
Sure, that's a business rule aspect. But the client is in control in declaring what its instance complies with. As you say that doesn't mean the server has to accept it, it has its own business rules.
Kevin Mayfield (Nov 15 2019 at 08:59):
On a practical level, if I'm building a document or a message. What I would like to do is assemble the bundle from restful servers (with minimal transform) so Patient and Encounter comes from the PAS, Observations from the Obs/EPR, Binaries from the EDMS, etc.
The stated profile in these returned resources is not likely to match what the message/document wants but they should validate according to their conformance rules. Do I need to correct the stated profile in the resources?
Kevin Mayfield (Nov 15 2019 at 09:01):
I feel not as the servers/project business rules take precedence (and will override the resources stated conformance)
Vadim Peretokin (Nov 15 2019 at 09:02):
profile:
An assertion that the content conforms to a resource profile (a StructureDefinition). See Extending and Restricting Resources for further discussion. Can be changed as profiles and value sets change or the system rechecks conformance. The profile can be used to indicate which version(s) of FHIR a resource conforms to.
On the RESTful API: On receiving a write operation, the server MAY elect to remove invalid claims, SHOULD retain claims that are correct or untested, and MAY add additional claims it believes are valid
Vadim Peretokin (Nov 15 2019 at 09:04):
I feel not as the servers/project business rules take precedence (and will override the resources stated conformance)
I think so too, and then the server could add the profiles it thinks the resource conforms to, like the spec says
Vadim Peretokin (Nov 15 2019 at 09:04):
I can easily get lost in profiles and what I want to do is build one resource and use it many times.
This is why one should not build overzealous profiles that 0..0 everything you don't want :)
Vadim Peretokin (Nov 15 2019 at 09:05):
It causes developer pain (and pushback) like this.
Grahame Grieve (Nov 15 2019 at 12:39):
In the UK we are getting a lot of resistance to having many profiles
I get that. Totally. And I get this too, as the actual goal:
what I want to do is build one resource and use it many times.
But hiding hard requirements and not using profiles... doesn't achieve your actual goal. Unless, that is, there's some confusion that because you have a profile, you have to use Resource.meta.profile. A lot of projects knee-jerk into this because of past experience, but I strongly advise against it. I am in favor of defining profiles for your requirements, but I'm very much in favor of using Resource.meta.profile as sparingly as possible.
It tends to get used because lazy validator writers think it's easier for them, but it creates heaps of work downstream
Kevin Mayfield (Nov 15 2019 at 13:13):
Thanks. That matches technical feedback in UK. Their is a push to make Resource.meta.profile mandatory for reasons you've mentioned.
René Spronk (Nov 15 2019 at 13:17):
Why does it create heaps of work downstream? Any declared profiles can be ignored by a server, so what's the extra effort if it's there? One can choose to ignore, but if there are no declared profiles, one can't choose to use the client-specified profiles. And somehow you need to identify the version of the StrucDef or IG one is sending.
Lloyd McKenzie (Nov 15 2019 at 13:22):
You're free to ignore declared profiles inbound, but if you spit them out outbound and they're wrong, your system is non-conformant. More importantly, requiring that profiles be declared means that clients must customize their interfaces to declare all of the profiles for all of the downstream systems that expect that declaration. So rather than just pointing at a new server and having things work, the client needs to change their code every time a new server comes along that wants a different profile (or different profile version) declaration - even though the data being provided hasn't changed and the meaning of the instance hasn't changed. That's a tax on the client community for the convenience of the server and makes costs higher for the system overall.
Kevin Mayfield (Nov 15 2019 at 14:13):
Wouldn't that be covered by the business when establishing the connections? They would establish something like a contract which says which profiles can be used by client and server?
Kevin Mayfield (Nov 15 2019 at 14:15):
[del]
Jenni Syed (Nov 15 2019 at 18:39):
@Lloyd McKenzie that statement (about being non conformant by returning possibly invalid profiles on a resources) doesn't agree with what the spec states about that: "...SHOULD retain claims that are correct or untested, and MAY add additional claims it believes are valid" (emphasis mine)
Jenni Syed (Nov 15 2019 at 18:39):
http://hl7.org/fhir/r4/resource.html#Meta
Jenni Syed (Nov 15 2019 at 18:40):
The documentation for the field even hints a bit that this is something that may slowly get stale over time/not be real time maintained: "It is up to the server and/or other infrastructure of policy to determine whether/how these claims are verified and/or updated over time. The list of profile URLs is a set."
Jenni Syed (Nov 15 2019 at 18:41):
This has always been my understanding of the profile field - it's not guaranteed to be accurate as it's pretty expensive to re-validate on all calls/keep these up to date in all cases
Grahame Grieve (Nov 15 2019 at 19:18):
typically, people write a profile that expresses their requirements, which is reasonable, and then say 'you have to tell me you meet my requirements' (use Resource.meta.profile). Which is the bit that stops re-use, since the requirements are compatible, but the explicit declaration is not. So you can't re-use your existing interface. And then you add the new profile declaration and some other interface suddenly blows up because it doesn't know this new profile you've declared.. and now we're back to one-off interfaces.
yes, servers are allowed to rewrite profile ids.. but the kind of thinking that leads to the scenarios in the previous paragraph... those kind of IGs also prohibit servers changing profiles, etc.
The lesson is that there's really 2 types of profiles (well, there's more sub-types):
- ones that express business rules for conformance purposes
- ones that describes inherent semantics in the resource (exp. Observation)
(yes I'm aware that this is not a clean division)
It's the second ones that are candidates for Resource.meta.profile, and the only reason to do that is to make semantic usage easy to find (it's a denormalization). You should never put the first type of profile in Resource.meta.profile
@David Hay btw, this is why it's important not to require Resource.meta.profile in order to validate
Jose Costa Teixeira (Nov 15 2019 at 19:53):
so (how) can we say and inquire that a resource indicates "this content is declared compatible with the constraints and requirements expresssed by xxx. May (or may not) be compatible with other requirements"?
Kevin Mayfield (Nov 16 2019 at 07:37):
Wouldn't it be more practical for the source/client to say its compatible with xxxx? Probably via documentation (which resembles a capability statement).
Lloyd McKenzie (Nov 16 2019 at 12:49):
@Jenni Syed You're free to strip profile claims. But if you retain them and spit them out in subsequent query responses - and the instance is no longer (or never was) valid against those claims - then you're non-conformant. If an instance declares a profile and isn't valid against that profile, the instance is non-conformant.
René Spronk (Nov 16 2019 at 14:24):
So if you send something (perhaps as a result of a subscription or query, or trigger based) you'd better make sure that whatever profiles you include [if any] were validated by you as a sender ? If (as a server) I receive a profile on a resource, a profile that I don't know about nor care about, then I'd better strop it off as quickly as I can because it serves no purpose. Or at least; strip unknown profiles off incoming resources UNLESS (a) I still know who/what system send the profile to me in the first place [so at least I can send it back to them], (b) the resource hasn't been modified by any other system, and (c) my persistence layer allows me to fully reconstruct all data elements that were originally sent to me. That's a lot of ifs.
Lloyd McKenzie (Nov 16 2019 at 14:25):
Yup. Retaining profiles that you don't verify yourself - ideally on output - is a risky business
David Hay (Nov 16 2019 at 16:35):
Fair enough. So my little validator app should have an option to specify the profile to apply. I'll update the docs as well...
Jenni Syed (Nov 18 2019 at 17:26):
@Lloyd McKenzie do you have links to where that is described in the spec? The doc I linked to doesn't seem to indicate that.
Jenni Syed (Nov 18 2019 at 17:28):
Also, to be transparent, my implementation doesn't currently support this (it would strip profiles sent in on write today). However, we've talked about the profile field in Meta over time and my understanding is that it shouldn't be considered perfectly reliable. I just want to make sure I understand it as this is something that comes up with many IG discussions.
Jenni Syed (Nov 18 2019 at 17:30):
As well as realities of use. IE: querying by a profile, many think they could do this and get only the data they want. But typically, they want data that logically meets a profile rather than strictly conforming. For example, If I query for the US Core vitals profile and it excludes vitals that my system knows about but that don't conform (freetext results, different units, etc), this is surprising to many apps.
Grahame Grieve (Nov 18 2019 at 17:32):
it shouldn't be considered perfectly reliable
It's a claim. It should be considered reliable in the sense that it reliably claims to conform. Whether the claim is reliable or not is testable.
Grahame Grieve (Nov 18 2019 at 17:33):
as for querying, yes, that is a subtle point that we can't stop people being surprised about in either direction
Grahame Grieve (Nov 18 2019 at 17:34):
excludes vitals that my system knows about but that don't conform
But these should not exist...
Jenni Syed (Nov 18 2019 at 17:38):
I have seen heights recorded in something other than cm and inches, or fat fingered in with freetext units. I've seen weights in stones. We know they're height and weight, but spitting it out in a converted unit isn't an accurate representation of how it looks in the system
Jenni Syed (Nov 18 2019 at 17:39):
those are still vitals in our system, and would be shown in our vitals sections, but they don't strictly meet the international profile.
Jenni Syed (Nov 18 2019 at 17:41):
if you queried by the vitals category (not the profile), we would return them
Grahame Grieve (Nov 18 2019 at 18:10):
The intent of the profile is that you do return them in a converted unit. If you are concerned with representation, you have the narrative and/or rendered value extension
Grahame Grieve (Nov 18 2019 at 18:10):
if you think that statement is a problem, then you need to take that up with OO
Jenni Syed (Nov 18 2019 at 18:15):
Yeah, because if I had an app tell me to update it using the same unit, it would probably not make the system owner happy and there are precision issues as well
Jenni Syed (Nov 18 2019 at 18:16):
I thought that was why we had the conversion extensions - specifically for these types of issues/concerns
Jenni Syed (Nov 18 2019 at 18:16):
but now we're drifting :) It could be that it's not just the unit that we don't have/there are issues with
Jenni Syed (Nov 18 2019 at 18:19):
more common one is that we likely recognize it as a vital, may not recognize the underlying coding as weight or height, would return it by category query, and a human being would recognize that it was a weight :)
Jenni Syed (Nov 18 2019 at 18:19):
(but the computer didn't)
Jenni Syed (Nov 18 2019 at 18:20):
I'm more trying to understand how to be conformant if we do use the meta profile fields, because what I see in the spec is that we should try to make those accurate, but a system may choose to not automatically validate or update on every call
Jenni Syed (Nov 18 2019 at 18:20):
And Lloyd seems to be saying that would make the server non-conformant, but I'm not sure I can find the language for that field to back that/understand that
Jenni Syed (Nov 18 2019 at 18:21):
And I think what he is saying is what many people actually expect from that field - that it's supposed to be 100% accurate at all times, but the spec itself seems to not indicate that as a reality
Grahame Grieve (Nov 18 2019 at 18:25):
I think that the text you are looking for is:
Grahame Grieve (Nov 18 2019 at 18:25):
On the RESTful API: On receiving a write operation, the server MAY elect to remove invalid claims, SHOULD retain claims that are correct or untested, and MAY add additional claims it believes are valid
Lloyd McKenzie (Nov 18 2019 at 18:40):
Profile declaration is irrelevant in terms of vital signs profiles. If your system recognizes that an Observation is a height, weight or one of the other core-standardized vital signs profiles, you SHALL comply with the relevant profile (Including converting code or units). You don't have to declare the profile, but you must comply with it.
Jenni Syed (Nov 18 2019 at 19:07):
@Grahame Grieve then that makes it look like that it's ok to be untested/unvalidated. It doesn't look like a must to validate that
Jenni Syed (Nov 18 2019 at 19:07):
And that is the statement I found earlier
Grahame Grieve (Nov 18 2019 at 19:41):
I don't know where you found that. Perhaps in some narrower context where an additional rules was being applied?
René Spronk (Dec 30 2020 at 09:43):
Revisiting this issue: profile seems to be mainly something we need at the communications layer, not at the persistence layer. Therefore, a server should probably use declared profiles [on an inbound resource] in any way it sees fit (validation, optimized processing), but strip it off before actually persisting the resource. Profiles could be retained as part of a Provenance resource if one so chooses.
Before sending a resource, a server could attempt to detect which profiles a resource conforms to, and include any profiles in the meta tag. This could be a forced process if the context of the implementation has implicit rules around the use of profiles. Don't include any profiles in profiles that one hasn't validated as a server, for these may cause problems downstream.
Last updated: Apr 12 2022 at 19:14 UTC
