FHIR Chat · Profiles requiring meta.profile with version · implementers

Stream: implementers

Topic: Profiles requiring meta.profile with version

Corey Spears (Feb 23 2021 at 22:44):

Are there reasons why an IG's profiles shouldn't require conforming instances to include a canonical uri with version in meta.profile?
I am pretty clear on the pros, particularly when dealing with breaking changes across profile versions. I was wondering why it might be a bad idea to require such a thing.

Gino Canessa (Feb 23 2021 at 23:04):

I think the biggest 'con' is in compatibility:

• Even if there are no breaking changes between version current and next, implementers will be forced to explicitly upgrade.
• Given the distributed nature of the systems, it means that implementers will have to put in discovery and selection around 'n' versions even if all the underlying code is the same (e.g., I've added v2, but I have apps that haven't been updated from v1).
• In my experience, knowing that each version must be explicitly enabled lowers the bar for backwards-compatibility (e.g., someone has to opt into this new version, so it's fine if we break 'xyz').

(note, I understand there are pros as well - but you asked only for cons =)

Michele Mottini (Feb 23 2021 at 23:07):

The entire industry is trying to implement and deploy based on the current version, the next version _must be backward compatible_ - including using the same profile URLs

Josh Mandel (Feb 23 2021 at 23:07):

In general, the challenge with IGs requiring instance data to populate meta.profile is a semantic one: applications might start out using that field as a proxy for information that exists in the resource and then over time start attaching additional meaning purely to the presence of the _profile value.

Michele Mottini (Feb 23 2021 at 23:09):

And yes, agreeing with Josh - but that ship has sailed

Josh Mandel (Feb 23 2021 at 23:09):

Which IGs do this?

Michele Mottini (Feb 23 2021 at 23:10):

CARIN BB

Michele Mottini (Feb 23 2021 at 23:11):

(I assume Corey is thinking about CARIN BB)

Josh Mandel (Feb 23 2021 at 23:16):

Huh. Wish I'd noticed this during ballot -- feels like a mistake. And on review: technically I think the CARIN IG only says that .meta.profile needs to be populated, and doesn't say with what. So formally this is a very strange requirement indeed, and almost certainly doesn't reflect intent or good practice.

I'm not sure what "CPCDS data element (190)" is, and after downloading a Word Doc from https://build.fhir.org/ig/HL7/carin-bb/Common_Payer_Consumer_Data_Set.html#common-payer-consumer-data-set I see it doesn't add anything to the definition (element 190 is defined five times in that doc, but doesn't provide any details that aren't already in the FHIR structure definition I linked to above).

Corey Spears (Feb 23 2021 at 23:57):

This is for CARIN BB. Version STU1 (1.0.0) required meta.profile, but did not specify what it had to be populated with. That requirement by itself is not overly helpful.

• There is a proposal now to explicitly require the inclusion of the appropriate CARIN BB profile (https://jira.hl7.org/browse/FHIR-30375).
• During the FM call today, a request was made to require version as well to meta.profile.
• These are trial use standards versions and STU2 will unfortunately not be backwards compatible with STU1.

A decision on regarding this has not been made yet, but will be discussed on Feb. 25 on the CARIN project call at 11am Eastern with a possible vote on the FM call on March 2nd. I am trying to gather data and opinions to bring to the calls.

Josh Mandel (Feb 24 2021 at 00:12):

Thanks for the context!

I was wondering why it might be a bad idea to require such a thing.

It might be revealing to flip this question: what problems are you hoping to solve by adding these constraints to your IG?

Corey Spears (Feb 24 2021 at 00:31):

Addressing an environment where there are multiple incompatible versions may of be interest. The business reasons for it predated my full involvement on the project, so maybe @Amol Vyas , @Mark Roberts, @Pat Taylor could provide some information.

Lloyd McKenzie (Feb 24 2021 at 03:41):

Requiring population of profile is generally bad practice. It increases the cost of interoperability and runs the risk of people using it to infer meaning. Why does BlueButton want the profile declared?

Corey Spears (Feb 24 2021 at 05:37):

I have seen you (@Lloyd McKenzie) mention that in another stream, though I am still trying to figure out exactly why that is. I am also not sure how that statement comports with earlier statements like (https://chat.fhir.org/#narrow/stream/179177-conformance/topic/Requiring.20meta.2Eprofile):

I'm not clear why it doesn't just make sense to have each profile declare explicitly that you must declare it as part of the profile definition.
That's the most likely scenario. "To be compliant with profile X, you must declare profile X"
I have IGs that have some profiles that do that, but haven't had a situation where I'd want all profiles to do that.

and (https://chat.fhir.org/#narrow/stream/179177-conformance/topic/versioning.20profiles):

Client declaration gives a hint as to what validation a server should perform.
It's costly for servers to validate against all possible profiles - or even all possible versions.
A client declaration isn't an indication of everything they're conformant with, but is an indication of what they believe they're
conformant with that they believe recipients are likely to care about/use

Perhaps I am misunderstanding the statements, I am missing a key concept, or perhaps the guidance has changed (it was 2.5 years ago)?

James Agnew (Feb 24 2021 at 11:04):

I have to say I don't understand this guidance either.

I can't fathom how requiring a profile declaration could "increase the cost of interoperability", and people using it to infer meaning is a good thing. A profile tag is an explicit declaration of the purpose for which the resource was created and how artifacts like validators should treat it.

This feels to me like guidance that makes things harder for actual implementers for the nebulous benefit of "modelling purity"

Daniel Venton (Feb 24 2021 at 13:24):

Generally I don't think declaring conformance to a profile helps much, "Look guys I state I conformance to X (but I really don't due to missing Y)."
Profile (CCDA template ids) should never contribute to clinical decisions.
Definitions of attributes should never change, ".billablePeriod means X with profile Yv1, but means Z with Yv2".
Given that what does having a profile tag really tell you? By itself does it prove that the resource conforms to the profile.. No. Does it provide meaning to the data... No. Does it provide bloat to the resource (very light clinical Observation, conforms to 5 profiles, the profile data would be more than the obs data)... Yes.

Unfortunately, in the CARIN case, how do you know if the EOB is an inpatient institutional vs an outpatient institutional? You look at the profile. That's the only way to know. But it does help with validation (provides meaning), if the profile is inpatient then the validator can say "requires admission date".

Assuming the profile values being populated, gleaned from the examples, are the actual profile values expected, which aren't in the conformance rules (as noted by Josh).

I would have expected that either the EoB.type value set would have had 2 values (OUT, INP) rather than just one (institutional) OR there was a supporting info slot that split that attribute.

Thus the validator could say, "EOB declares type = inp, but missing mandatory admission period." Instead of, "EoB has profile =INP but missing admission period." That way all(?) the validation would be based on data not conformance statements.

Does that help with V2, V3... Probably not. Is it important for validators not to complain about not meeting V2 rules when the author didn't intend for the resource to conform V2?

Jens Villadsen (Feb 24 2021 at 14:12):

@Grahame Grieve - it looks like your supposed blog post about meta.profile is about to write itself :point_up:( @Torben M. Hagensen ).

Michele Mottini (Feb 24 2021 at 14:18):

I would have expected that either the EoB.type value set would have had 2 values (OUT, INP) rather than just one (institutional) OR there was a supporting info slot that split that attribute.

There is even a subtype element...

Josh Mandel (Feb 24 2021 at 14:24):

If meta.profile is the only way an IG provides to convey the meaning of a resource (e.g., which type of EoB the resource represents), this feature is being misused in the IG, especially when existing data elements like type/subtype are available. I'd like to know if you agree @James Agnew , or have I lost touch with practicality?

James Agnew (Feb 24 2021 at 15:00):

@Josh Mandel Hmm.. I mean thinking this through obviously using meta.profile as a surrogate for type/subtype seems bad. Clearly if someone is trying to convey a data categorization they should use the fields that are there to satisfy that need (and I see that the CARIN IG profiles don't appear to use the subtype element, this would be a nice thing to fix in a future revision).

I think what gets my hackles up is the suggestion that IGs shouldn't be allowed to require profile declarations, which suggests that they shouldn't be using them. Profile declarations are really useful things for the infrastructure, and I bet that will only intensify when we get to a world where organizations like the payors are required to implement a whole suite of IGs that aren't always mutually compatible and sometimes mandate data for one audience that isn't appropriate for another.

Personally I think the guidance should be that IGs should always require profile declarations (to keep things manageable for the tooling) and that if the profile implies any meaning, the meaning should be conveyed by a fixed value enforced by the profile (e.g. a fixed subtype in the CARIN example).

Lloyd McKenzie (Feb 24 2021 at 15:01):

1. It must always be possible to strip a profile declaration and re-identify what profile(s) the instance is valid against by just checking it against the candidates. If you can't do that, then the profile contains 'extra' information and the implementation is non-conformant. If a profile declaration has any meaning other than "this instance will validate against profile X", that additional meaning must be expressed in some other way (typically by adding an extension).

2. The valid rationale for declaring an extension in an instance is to allow for more efficient validation by the recipient. If you know what a profile claims to be valid against, you can check that instance more efficiently than if you need to check against all possible candidates. However, in practice, there are generally discriminators that allow you to quickly choose a relatively small pool of profiles to evaluate against. (e.g. if I was trying to decide what US Core profile to check an instance against, I'd check resource type and category).

3. Receivers should check instances for profile validity regardless of declaration (unless you're super brave or have really rigorous conformance testing and strict control of change, in which case you're essentially in a closed interoperability environment). Even well intentioned systems will sometimes accidentally ingest bogus data or make minor tweaks that suddenly cause data to no longer be fully conformant. (Changes in the terminology space as codes get added/deprecated can also cause issues.) So the presence of a profile declaration shouldn't usually be taken in substitution of checking that he rules are met.

4. The 'ideal' design objective with FHIR is for systems to emit a single resource instance that subsequently gets consumed by all recipients. I.e. you don't emit different data for different consumers, you emit the same data for everyone (allowing for a security layer that strips elements/responses that the requester isn't allowed to see). Demanding that instances declare desired profiles in order to interoperate imposes a tax on the sender because they have to modify their interface for each consumer who wants a distinct profile declaration (and each consumer will potentially want profile declarations specific to their needs). Imposing such a tax isn't prohibited, but it should be carefully considered in terms of the total cost to the community. Does the savings on the consumer in terms of increased efficiency of routing to appropriate validation outweigh the cost of modifying, testing and long-term maintenance of the profile declaration on the sending systems? The calculation will vary depending on the number of receiving systems vs. sending systems as well as on the volume of candidate profiles the receiver might need to triage against.

5. The risk of mandating profile declaration (and particularly version-specific profile declaration) is that it acts as a barrier to interoperability. "Nope, sorry, can't consume your data because you don't declare profile X, version Y. Please go away and customize your application and then I'll consider consuming your data" (when the data itself already met all requirements for consumption). "You must customize your application" inevitably translates into delay and significant dollars, even if the change is minor. Sometimes it translates into failure of interoperability to occur at all - especially if the receiver doesn't have the leverage of regulation or large $$$ on their side.

In this specific case, if you can't tell if an EOB is institutional or outpatient except by looking at the profile, then the specification is not FHIR conformant. The institutional/outpatient determination must be exposed in some other way - in the worst case, as an extension.

James Agnew (Feb 24 2021 at 15:03):

(....and if we want to fix bad behaviour in current IGs, IMO banning IGs from requiring contained resources would go a whole lot further towards getting us to our eventual interoperable utopia ;) )

Lloyd McKenzie (Feb 24 2021 at 15:07):

Contained resources are fine if it's a situation where the resource genuinely has no independent existence. E.g. a medication recipe that only exists inside the context of a prescription.

Lloyd McKenzie (Feb 24 2021 at 15:09):

One other consideration around profile declarations. If the intention is to use the profiles for subsequent searching, then receiving apps can't ever rely exclusively on receiving profile declarations on inbound data - because at some point a new relevant profile will come along that will be relevant to historical data. That means the system will have to have the ability to go through its data to determine profile applicability, independent of what was already previously declared (whether that's done pre-emptively or at time of query by profile may vary depending on system design and profile complexity.

Lloyd McKenzie (Feb 24 2021 at 15:10):

Contained definitely shouldn't be used with the expectation that the receiver will "un-contain" the resource. Containment is not a transport mechanism.

Eric Prud'hommeaux (Feb 24 2021 at 15:13):

If I store a resource with a contained resource and then get a new version, is there any expectation that contained resources remain contained?

James Agnew (Feb 24 2021 at 15:14):

Not to change the subject here but that example just says to me that the MedicationRequest resource is fundamentally broken, if we have a common scenario like this one that can only be achieved using contained resources. IMO even extensions on the MedicationRequest would be vastly preferable to contained elements, which satisfy the "modelling purity" crowd but are horribly hostile to implementers.

Eric Prud'hommeaux (Feb 24 2021 at 15:15):

psst, @James Agnew , check your private messages -- trying to schedule time with you to work on deepEquals failing on contained resources

Brett Marquard (Feb 24 2021 at 17:16):

The C-CDA requirement of templateIds in instances has tied our hands making new releases - one change at the bottom of the 'chain' ripples through the entire standard. It's a nightmare.

Eric Haas (Feb 24 2021 at 18:29):

If the desire is

The 'ideal' design objective with FHIR is for systems to emit a single resource instance that subsequently gets consumed by all recipients. I.e. you don't emit different data for different consumers, you emit the same data for everyone (allowing for a security layer that strips elements/responses that the requester isn't allowed to see).

The trend seems to be the opposite - slice and dice the data on the sender side for my use case...

Grahame Grieve (Feb 24 2021 at 22:06):

A profile tag is an explicit declaration of the purpose for which the resource was created

That is very much not the case. It's a statement about the rules that resource is believed to meet. That's not the same as an explicit declaration of the purpose

Lloyd McKenzie (Feb 25 2021 at 00:02):

@Eric Haas Receivers are used to that. That's the way things often worked in the document/messaging world. "I define what I want, you write code/tweak your interface engine to give it to me". But in a RESTful space, it doesn't work so well. In REST, you've got one interface and everyone comes along and grabs what they want from it. While there is some degree of search-engine-optimization that goes on, by and large websites don't re-craft themselves when a new browser shows up.

Corey Spears (Feb 25 2021 at 04:01):

@Grahame Grieve , I am reading between the lines here, but the more I think about why people may believe they need the profile expressed in this case, the more I wonder if this is about trying to express purpose, intent, or scope of the communication of the resource. That it is to say that it is a CARIN BB use case resource matching specific parameters that directly align with data that is expressed in other means like claims forms, paper EOBs, and X12 messages.

Grahame Grieve (Feb 25 2021 at 04:09):

this is what attributes like type / class / subtyppe are for

Grahame Grieve (Feb 25 2021 at 04:09):

and profile shouldn't subvert them

Corey Spears (Feb 25 2021 at 05:02):

True, and I agree they need to be used more effectively, but those alone may not be sufficiently unique across IGs and use cases.

I suppose an extension could be defined or perhaps wrapping it in some kind of bundle that has other resources to provide context. That also imposes a tax.

Josh Mandel (Feb 25 2021 at 14:50):

those alone may not be sufficiently unique across IGs and use cases.

Sufficiently unique for what, though? Beyond explaining what kind of EoB this is, what does the type/subtype need to accomplish that requires uniqueness?

Lloyd McKenzie (Feb 25 2021 at 15:40):

@Corey Spears, what is your objective around capturing "purpose" at all? In general, a FHIR interface should work the same way independent of purpose. If you want to move the patient room, you do a PUT to Encounter. If you want to capture where the patient's valuables are, you do a PUT to Encounter. If you want to discharge a patient, you do a PUT to Encounter. There's no coded element that says "this is what I'm doing". The server just checks to see if you're allowed to make changes to the elements you're trying to change (either generally or based on the current state of the resource and related resources).

Lloyd McKenzie (Feb 25 2021 at 15:41):

Receivers don't necessarily need to know what implementation guide someone's read when they construct their instance. Maybe they haven't read any IGs at all. So long as the instance is valid, it shouldn't matter.

Jens Villadsen (Feb 25 2021 at 17:18):

@Lloyd McKenzie are you suggesting that receivers should store or do whatever processing on instances that they receive if they can (just) validate the instance to one (or zero) or more of the SD's known by the reciever? What if such instance contains a modifierExtension that reverses the meaning, but is ignored as the extension happens not to be part of any of the known SD's at time of receivement by the receiver.

Corey Spears (Feb 25 2021 at 17:26):

@Jens Villadsen THe FHIR Spec provides requirements regarding Modifier Extensions (https://www.hl7.org/fhir/extensibility.html#isModifier):

Implementations processing the data in resources SHALL check for modifiers anywhere they could appear,
and if a modifier extension is present on a data element that the application 'processes',
SHALL do one of these things:

1. recognize the modifier extension, and understand the impact of the extension when using the data
2. reject instances that contain the modifier extension
3. treat such instances as "for rendering purposes only" - i.e. check that the narrative status = extensions or generated, display the narrative and don't process the discrete data
4. Ask for a human to check the modifier extension before proceeding to process the data
5. carry a warning concerning the data along with any action or output that results from processing the data to inform users that it has not fully understood the source information

A profile in meta.profile will not do much to safeguard against implementation that do not follow these rules.

Lloyd McKenzie (Feb 25 2021 at 17:27):

When you're processing instances, meaning comes from the base resource, not from profiles. You should be looking for modifierExtensions regardless of what profiles the instance declares (and whether you recognize any of them).

Lloyd McKenzie (Feb 25 2021 at 17:28):

Just because a profile is declared, that doesn't mean there can't be unexpected modifierExtensions (unless the profile has constrained out all modifiers - and the instance actually complies with the profiles it declares...)

Jens Villadsen (Feb 25 2021 at 17:42):

Right - I just only see option 1 and 2 as the ones that are actually computable in the modifierExtension case for a receiever getting resources where the profile is unknown/not stated to the reciever.

Lloyd McKenzie (Feb 25 2021 at 17:50):

Modifier extensions always have the name "modifierExtension". You don't need access to any profiles to know that something is a modifier extension.

Lloyd McKenzie (Feb 25 2021 at 17:50):

(You're never allowed to send modifier extensions in the "extension" element.)

Jens Villadsen (Feb 25 2021 at 18:06):

right- i know

Lloyd McKenzie (Feb 25 2021 at 18:37):

Then I don't understand. Why would profiles matter?

Jens Villadsen (Feb 25 2021 at 21:47):

Conformance to a profile may dictate behaviour in the receiving end. Failure to conform with any profiles in the receiving end may end up being useless for the receiver itself

Jean Duteau (Feb 25 2021 at 21:56):

In one of my guides, I originally had behaviour based on the profile that the Bundle conformed to. I wasn't basing it on what the sender told me but rather which of the three Bundle profiles that it conformed to. Eventually though, I realized that this wasn't a viable way of determining behaviour because I was artificially changing my profiles to ensure that there was a distinction between them. We switched to an operation parameter and then, based on the parameter, we mandate that the receiver has sent us the appropriate profile. That seems to me to be the proper way to do this.

Jens Villadsen (Feb 25 2021 at 21:56):

Conformance to multiple profiles may also dictate behaviour in the receiving end. I haven't yet stumbled upon a FHIR recieving system that's in production that initially checks for 0..* conformances AND then afterwards checks whether the incoming resource also contains 1 or more unknown-to-the-receiver modifierExtensions AND which supports any of the bullets 3, 4 or 5. But that could easily just be me

Lloyd McKenzie (Feb 25 2021 at 23:20):

Profiles don't tell you how to behave. Profiles dictate what must be supported, nothing else. So, for example, if you want to claim conformance to a profile that says "mustSupport display data element X", that doesn't mean that you only display the element if you receive that profile. And most display behavior is driven by CapabilityStatement. It is NON-CONFORMANT to drive behavior purely based on the declaration of a profile that can't also be inferred from data elements that are present in the instance.

Lloyd McKenzie (Feb 25 2021 at 23:22):

Systems are required to check for modifier extensions in all instances. It's one of the key things in the safety checklist. (You should be looking for the presence of other modifier elements like Resource.implicitRules too.) Failure to do that is unsafe. Checking for a profile doesn't bypass the need to check for other things. (And in most cases, you won't be able to count on the profiles you're interested in being declared for you in the first place.)

Jens Villadsen (Feb 26 2021 at 10:50):

Behavior might be a wrong term here in what I'm trying to express. If the recieving end of a system is triggered by the data found in a resource, I agree that it is not the profiling that does the triggering, it is the fact that the specific piece of data exists. That specific piece of data may be present due to the fact that is has been specified as eg. mustSupport in the profile, and the recieving system could require data resources recieved must conform to a profile stating just that. In that sense it is an implicit behaviour due to profile conformance.

Jens Villadsen (Feb 26 2021 at 10:50):

and thats a whole lot of implicitness

Lloyd McKenzie (Feb 26 2021 at 14:30):

Data isn't present due to a profile. Data is present because the system chooses to support it. (It might choose to support it because it chooses to comply with one or more IGs, but that's a design-time expectation, not a run-time expectation.) Profile declaration, at runtime, do not drive behavior. If a system declares a profile or an IG in its CapabilityStatement, that identifies what it will 'support' all the time. What it supports and what it does isn't going to change based on what profiles are or aren't declared in the instance.

I.e. If you comply with US Core, CA Core and AU Core, then you would be expected to handle the mustSupports of all of those, regardless of which profile is declared on inbound - and would support them even if no profiles were declared on the inbound data.

Yunwei Wang (Feb 26 2021 at 15:30):

My understanding from the discussion is that profile may influence design time decision but should not affect runtime behavior/result. Is that correct?

Lloyd McKenzie (Feb 26 2021 at 15:59):

Right

Jens Villadsen (Feb 26 2021 at 16:15):

Agreed

Jean Duteau (Feb 26 2021 at 16:32):

And even if you think you have a new use case where you need the profile to affect runtime behaviour/result, you're wrong. :)

Jens Villadsen (Feb 26 2021 at 17:48):

... is that profile may influence design time ...

@Yunwei Wang - given that you by profile mean stating the meta.profile in the resource, yes. @Lloyd McKenzie I would expect that a suitable case for your FooBar system supporting IG's from 3 different countries to eg. look up demographics on patients from preferable just one of the three MPI's (being US, CA or AU) of any given patient created in that system eventhough any patient resource posted to FooBar could conform to all 3 profiles at the same time (of course without having any meta.profile stated - and having looked at the 3 patient profiles, I'm actually a bit surprised to see that it actually seems possible). If the meta.profile had been stated in such case, it could have provided a suggestion, but it would never be more than a suggestion, to what MPI would the correct one to ask for demographics.

Jens Villadsen (Feb 26 2021 at 17:54):

@James Agnew I guess a nice feature to add to HAPI would be a RequestContextto each ResourceProvider that pr. request (requestScoped) would state what profiles an inbound resource conforms to - (given that one uses the https://hapifhir.io/hapi-fhir/docs/interceptors/built_in_server_interceptors.html#request_and_response_validation already)

Lloyd McKenzie (Feb 26 2021 at 17:59):

The fact it's possible is good. Well-designed profiles should allow multiple other profiles to be satisfied. Constraining cardinality or slices in a way that prohibits sharing other information that might exist and be useful to some consumers is bad practice.

The meta.profile cannot suggest what MPI to ask for demographics. The only thing a profile can do is say "this instance validates against this profile". It isn't allowed to imply any semantics other than that.

Jens Villadsen (Feb 26 2021 at 18:50):

The fact it's possible is good.

I tend to disagree. The fewer constraints and invariants you make, the less specific your system tends to be (or explode in complexity) and the harder it gets to build systems that can actually aid users in using the systems as intended. This comes at the cost of interoperability - that is an obvious consequence.

Jens Villadsen (Feb 26 2021 at 18:58):

In general terms that is. I however understand the design of the 3 patient profiles and I can also see that they won't conflict with the danish core patient profile and I do see the value of that design.

Michele Mottini (Feb 26 2021 at 19:22):

'The US MPI . . .' oh if only

Lloyd McKenzie (Feb 26 2021 at 19:51):

The idea with FHIR is that systems expose the same set of data to everyone. Consuming systems pay attention to the elements they care about and watch for unsupported modifier elements and ignore everything else. We don't generally want interfaces that are carefully tuned to a single recipient. We want general purpose interfaces that clients can grab what they need from - and if they need more over time and the interface supports it, they can just grab the additional information.

Lloyd McKenzie (Feb 26 2021 at 19:52):

Obviously when you design your system, you're not going to add capabilities that neither you nor your known customers need, so we're not saying "you must support absolutely everything". But as you add new capabilities, you don't add them in a profile-view-specific way, you just add them to your base interface.

Jens Villadsen (Feb 27 2021 at 08:11):

Michele Mottini said:

'The US MPI . . .' oh if only

I know .. just for the case of the example ...

Jens Villadsen (Feb 27 2021 at 08:20):

I don't just see FHIR as a glorified version of an OpenAPI. I see it as great tool for expressing differences in a structured homogenized manner in a heterogeneous world. If I were to bring a system to the danish market supporting eg. the core danish IG, I would expect a lot of similarities when I would bring the same system to the norweigian market but I wouldn't expect it to work out of the box. I would still carefully have to inspect eg. the norwegian core IG and cross check it on a semantic level (as well as legislation and so on), but at the very least I would have the differences expressed in the same syntactical language - and to some extend semantics as well.

Jens Villadsen (Feb 27 2021 at 08:21):

@Corey Spears sorry for completely hijacking your thread

Lloyd McKenzie (Feb 27 2021 at 14:12):

I'm not saying it would work out of the box, but any extra elements you add when you adapt your element for the Norwegian market I'd expect show up to your Danish customers. (And the Danish customers would consume/ignore as they wished.) That doesn't mean you have to do things that way, but it's certainly cheaper/easier to maintain a single interface than it is to maintain distinct interfaces for each consuming system. Consuming systems of FHIR interfaces should NOT presume that the sender will trim to only the data elements they care about or support.

Jens Villadsen (Feb 27 2021 at 18:19):

Right

Jens Villadsen (Feb 28 2021 at 08:42):

So ... stating meta.profile shouldn't affect behaviour (except notifying anyone stating it and don't adhere to the stated profile - which is more of a debugging case) - whereas confromance to a profile could affect behaviour. This may also mean that stating meta.profile basically can only be used as an untrusted/untested hint. @Grahame Grieve I believe your blog post now has written itself

Jens Villadsen (Feb 28 2021 at 08:48):

It could even be relevant to have a standardized way for servers to reject clients whenever they would encounter clients that claim conformance by stating meta.profile which was not in line with the server, as such case would reflect that they do not agree on the interpretation of the given profile/IG.

René Spronk (Feb 28 2021 at 10:53):

The client claim may be just that (a claim, whether true or false) - IMHO a server should not reject a resource because a client-side claim Y is found to be false, but only if a server is (contractually) bound to only process resources that conform to profile X. X could be the same profile as Y, but it needn't be. The client-claim could be persisted as part of a Provenance resource.

Jens Villadsen (Feb 28 2021 at 12:51):

Right - if the server knows about claim (profile) x, then this is the special case where the client should be informed that its claim is malformed - at least from the perspective of the server.

Lloyd McKenzie (Feb 28 2021 at 14:53):

An instance declaring a profile in no way mans that the receiver is obliged to support elements marked as MustSupport in the profile. It doesn't even mean that the sender supports those elements. MustSupport is really only meaningful in the context of an IG or other definitional specification. You can use it to document specifications for what you want a system to do (IG, RFP) or even what you can do (published conformance statement for your system). But in an instance, the only thing a profile says is "what constraints does this instance comply with". It says nothing about the capabilities of the sender or the receiver. You can certainly reject an instance that claims to comply to constraints it turns out not to (on the grounds that the instance is non-conformant), but there are no grounds for rejecting an instance because you don't support some of the profiles suggested by one or more of the profiles it declares (or because you don't recognize one or more of the profiles it declares at all).

It's probably worth submitting a change request to make clear that mustSupport is relevant for profiles declared on CapabilitySystem.resource.rest.profile and for profiles declared in IGs, but not for rest.supportedProfile and certainly not for meta.profile.

Jens Villadsen (Feb 28 2021 at 16:03):

An instance declaring a profile in no way mans that the receiver is obliged to support elements marked as MustSupport in the profile. It doesn't even mean that the sender supports those elements. MustSupport is really only meaningful in the context of an IG or other definitional specification.

Noone objected to that, for the record

Lloyd McKenzie (Feb 28 2021 at 16:17):

Jens Villadsen said:

It could even be relevant to have a standardized way for servers to reject clients whenever they would encounter clients that claim conformance by stating meta.profile which was not in line with the server, as such case would reflect that they do not agree on the interpretation of the given profile/IG.

I was responding to this. There is no reason for a server to reject a client based on their claim to conformance - except if the server validates the claim and determines it to be untrue. There is no "interpretation" of a profile. All meaning comes from the data sent, not any specified profiles. Ignoring profiles is always safe and rejecting on the basis of declared profiles only really makes sense if :
a) the system recognizes the declared profile
b) the declared profile makes mandatory an element that the receiving system treats as prohibited
Even then, the rejection should be on the basis of the inclusion of the prohibited element, not the declaration of the profile. (And systems should be cautious about prohibiting (or setting upper-bound cardinality limits) on data - this should generally happen only when it's truly an error for the data to be present, not just when the system doesn't happen to support an element.)

Jens Villadsen (Feb 28 2021 at 16:19):

I was primarily talking about case

a)

Lloyd McKenzie (Feb 28 2021 at 16:22):

Both a & b are required for it to be appropriate to reject.

Lloyd McKenzie (Feb 28 2021 at 16:23):

I.e. the rejection must always be about the fact the instance contains data that is prohibited (or fails to contain data required).

Jens Villadsen (Feb 28 2021 at 18:20):

sure b) is a bit more special. Ain't that the case where the sender hasn't inspected the capabilties of the reciever and yet sends its data anyway?

Lloyd McKenzie (Feb 28 2021 at 18:44):

Senders are never required to inspect the capabilities of the receiver. The normal state is just send whatever the receiver is allowed to receive (whether they're capable of consuming the elements or not).

Lloyd McKenzie (Feb 28 2021 at 18:46):

Some of the sent data may well fall on the floor - and that's ok. The receiver is obligated to check for mustSupport elements they don't recognize. Other than that, they're free to ignore whatever they want - and senders can't presume a receiver will understand anything. On a create/update, they can get a copy back of what was actually stored. On a query response, it's really none of their business what the recipient pays any attention to.

Jens Villadsen (Mar 01 2021 at 13:37):

I would still consider it a bit special/blunt for a sender just to hook up to a receiver and NOT consider what would be supported by the receiver and just assume that stuff would work out of the box without doing any inspection upfront in regards to the capabilites of the receiver. Some receivers might even manipulate what was received or even remove parts of the received in the content returned to the sender. While I can see that it would work in some scenarioes, I can also see that it wouln't work in others.

Vassil Peytchev (Mar 01 2021 at 14:21):

I would still consider it a bit special/blunt for a sender just to hook up to a receiver and NOT consider what would be supported by the receiver and just assume that stuff would work out of the box without doing any inspection upfront in regards to the capabilities of the receiver.

I think there might be slightly different meanings of receiver in this conversation. The server is not the same as the receiver. The server is the receiver on POST and PUT, but the client is the receiver on GET or search. In the latter case, Lloyd's point that Senders are never required to inspect the capabilities of the receiver makes perfect sense. Similarly, with POST and PUT, it is up to the client to determine if it cares about the success or failure of the request.

Lloyd McKenzie (Mar 01 2021 at 14:47):

1. Many servers will have CapabilityStatements that don't declare rest.resource.profile at all - so inspection of what data elements they support won't be possible
2. When a server is responding to a query, there's no way for it to see what the client supports (clients don't expose a CapabilityStatement), so the only way to configure would be out-of-band. Such configuration is very much expected to be the exception, not the norm. What configuration is done will generally be focused on "what is the client allowed to access?", not "what does the client support?". It's not the server's problem if the client doesn't support all of the data sent in a query response.
3. If a server is responding to a post, it'll either store the record or not, depending on whether it meets its business rule. Very few clients will have the ability to configure what they send at runtime based on declared profiles. The POST/PUT will either work or it won't and some of the data sent will quite possibly be ignored. That's normal FHIR operation, not special in any way

It's certainly possible to manipulate what's received on a per sender basis, but that's more the path of the old messaging paradigm where you had to play around with the data with an interface engine. The intention with REST is you expose an interface and spit out what you've got and the receiver can take it or leave it. Any manipulation is focused on access permissions, not profiles.

David Simons (Mar 16 2021 at 18:21):

W.r.t. the run-time use of profiles:
A client is allowed to query for “give me all FHIR Observations that correspond to a particular FHIR profile”, right, and the FHIR Server responding with a result-set of Resources that all (are made by the Server to) conform to said FHIR profile (regardless of how these were uploaded to the FHIR Server)?

GET /fhir/4.0/Observation/?_profile="canonical|version"

e.g. to get all BodyTemperature vital-signs, in a common, interoperable form and coding:
GET /fhir/4.0/Observation/?_profile="http://hl7.org/fhir/StructureDefinition/bodytemp|4.0.1"

This would shift complexity to deal with heterogeneity from the clients to the server - intentionally.
You perspectives?

Lloyd McKenzie (Mar 16 2021 at 18:34):

I client can ask - there's no guarantee a server will support that though. (Not supporting the search criteria at all, not supporting the particular profile or supporting the profile but not checking all inbound and legacy data against the profile - and thus only returning instances that happened to declare the profile rather than finding everything.)

David Simons (Mar 16 2021 at 20:24):

Thank you Lloyd - I also plan to look into how to express those server capabilities in its CapabilityStatement.

Understood that a meta.profile entry on a Resource instance is a conformance _claim_, not a conformance _guarantee_.
Also understood the client is at the mercy of the server behavior/implementation - which can be documented out-of-band, of course.

Lloyd McKenzie (Mar 16 2021 at 20:49):

Things get messy w/ updates too - especially 'patch'.

Last updated: Apr 12 2022 at 19:14 UTC