Stream: conformance
Topic: Requiring meta.profile
Grahame Grieve (Jun 14 2018 at 02:08):
GF#12138 is recommended for block vote, but contains a potentially controversial disposition. @Mark Kramer @Lloyd McKenzie @Claude Nanjo @Ewout Kramer @Michel Rutten @Chris Grenz @Elliot Silver (for iHE) @Eric Haas @Brett Marquard should all check it
Lloyd McKenzie (Jun 14 2018 at 02:11):
I'm pulling it from the block vote with that resolution
Grahame Grieve (Jun 14 2018 at 02:11):
that just means we'll never get to it. Sorry
Lloyd McKenzie (Jun 14 2018 at 02:11):
No way it's ever ok to prohibit declaration of profiles. There's no justifiable reason to do that.
Grahame Grieve (Jun 14 2018 at 02:11):
yeah there is
Lloyd McKenzie (Jun 14 2018 at 02:11):
Why?
Grahame Grieve (Jun 14 2018 at 02:12):
I've already seen an IG that does just that
Lloyd McKenzie (Jun 14 2018 at 02:12):
Profiles never change the meaning of anything. THey're always safe to ignore.
Lloyd McKenzie (Jun 14 2018 at 02:12):
Then it's a badly designed IG.
Lloyd McKenzie (Jun 14 2018 at 02:12):
No reason we should encourage it.
Grahame Grieve (Jun 14 2018 at 02:12):
well, because we wanted to ensure that people didn't squeeze secrets in there
Lloyd McKenzie (Jun 14 2018 at 02:13):
You can't squeeze secrets in there. If they send a profile and you throw it away and they complain they lost data, the fault is theirs, not yours.
Lloyd McKenzie (Jun 14 2018 at 02:15):
You're forcing well-behaving systems to incur costs to customize their interface to strip out perfectly legal and safe profile declarations to prevent the unlikely and non-conformant situation of someone sending you a profile containing secret information. That's not a good tradeoff.
Grahame Grieve (Jun 14 2018 at 02:16):
you're jumping to a whole pile of assumptions there. We're not forcing well behaved systems to do anything.
Grahame Grieve (Jun 14 2018 at 02:17):
you have no idea what the context is.
Grahame Grieve (Jun 14 2018 at 02:17):
you're bascially saying it could be a bad idea. And yes, it could be
Grahame Grieve (Jun 14 2018 at 02:17):
now: to be clear: if we don't block vote this, it won't get dealt with before R4.
Lloyd McKenzie (Jun 14 2018 at 02:17):
If a system is talking to other systems, then it should be able to spit out the same resource to you as it does to others. If those other systems want a profile declaration, there should be no problem sending it to you too.
Grahame Grieve (Jun 14 2018 at 02:18):
then that would be a bad trade-off in that case. And so that's not the case
Lloyd McKenzie (Jun 14 2018 at 02:18):
That's always potentially the case.
Lloyd McKenzie (Jun 14 2018 at 02:18):
You can't ever know that a system won't need to spit the same resource out to other interfaces.
Lloyd McKenzie (Jun 14 2018 at 02:19):
I'm fine with it going to R5 because you can already enforce constraints on profile appearance in the profiles themselves.
Lloyd McKenzie (Jun 14 2018 at 02:20):
This would just be a more efficient mechanism - and I'm not happy with the proposed options. (I think the option of "must declare a profile of some sort" doesn't make a whole lot of sense either.) In fact, 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"
Lloyd McKenzie (Jun 14 2018 at 02:21):
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.
Grahame Grieve (Jun 14 2018 at 02:23):
well at this point I'll wait and see if anyone else has anything to say
Lloyd McKenzie (Jun 14 2018 at 02:37):
I've pulled it from the block vote and pointed to this thread
Elliot Silver (Jun 14 2018 at 02:56):
Declaring a profile is a (mostly) separate issue from stuffing secrets into the resource. To prevent secrets, you would want to prohibit extensions. So, I’m not sure there’s a reason to ban profile declarations for that reason.
Declaring a profile is also independent of conforming to the profile, so I’m not sure what benefit is gained by requiring or banning the declaration.
I guess there is some advantage to tagging a resource, for example, as “IHE-ABC“ so that the receiver knows to treat it according to the IHE ABC profile rules, instead of the processing for the general resource. But requiring the declaration feels more like a statement for an IG, than a CapabilityStatement.
Lloyd McKenzie (Jun 14 2018 at 02:58):
The capability statement might care if it relies on profile declaration for inbound validation
Elliot Silver (Jun 14 2018 at 03:09):
Yeah, I thought about that, but I'm half tempted to say that's a poor design. I think you should be recognizing a, for example, blood pressure observation based on the observation code, not based on the profile declaration. Once you recognize that it is a BP observation, then you can check it against your BP profile.
Elliot Silver (Jun 14 2018 at 03:09):
Is your argument against the tracker item then only on the "prohibit declaration" part, or is it wider?
Grahame Grieve (Jun 14 2018 at 03:11):
I guess there is some advantage to tagging a resource, for example, as “IHE-ABC“ so that the receiver knows to treat it according to the IHE ABC profile rules
Chris Grenz (Jun 14 2018 at 03:11):
@Elliot Silver no question that the observation code is the source of truth, but I really hope that over time standard profiles will allow for more abstract constructs and that profile will become much more common for semantic interop
Grahame Grieve (Jun 14 2018 at 03:11):
that is what we wanted to prohibit, and we didn't have observations so we just wanted to ensure no one went there. for this use case
Chris Grenz (Jun 14 2018 at 03:13):
I'm with @Lloyd McKenzie at least to the point where this isn't an urgent R4 need and there's a lot of questions remaining. Leave it out...
Lloyd McKenzie (Jun 14 2018 at 06:20):
@Elliot Silver That's the one I'm most violently opposed to. But I don't really understand the utility of some of the other proposed policies either. I think the whole thing needs more thought.
Michel Rutten (Jun 14 2018 at 09:52):
I'm wondering if Mark Kramer's use case could be covered by using ImplementationGuide.global ?
Grahame Grieve (Jun 14 2018 at 09:58):
that's a difference between 'must conform to this profile' and 'must state a profile' - a particularly large difference on observation
Lloyd McKenzie (Jun 14 2018 at 12:43):
Technically, 'must state a profile' could be solved by just sending the FHIR version profile, and I'm pretty sure that wasn't Mark's intent. @Mark Kramer ?
Brett Marquard (Jun 14 2018 at 13:50):
It is not clear to me that 'squeezing secrets' is a good reason to prohibit declaration of a profile.
Brett Marquard (Jun 14 2018 at 13:51):
Unless some believe this is urgent I think waiting till after R4 is appropriate.
Eric Haas (Jun 14 2018 at 18:53):
I don't know what squeezing secrets means - can somebody explain?
Lloyd McKenzie (Jun 14 2018 at 19:13):
Somebody sending a profile in the instance where, if you strip the profile declaration, you've lost information that can't be regained by just re-adding all profiles that the instance happens to comply with.
Elliot Silver (Jun 14 2018 at 21:18):
Ah, I'd interpreted that differently. That's an interesting idea -- the profile declaration itself conveys the secret information, rather than something in the resource that is only understandable knowing the profile.
Grahame Grieve (Jun 14 2018 at 21:25):
yes. people love to do this.... secret society stuff
Ewout Kramer (Jul 02 2018 at 09:48):
Ah, I'd interpreted that differently. That's an interesting idea -- the profile declaration itself conveys the secret information, rather than something in the resource that is only understandable knowing the profile.
Yes, and I remember Grahame had bad experiences with this in the v3 CDA projects, but I can see the current proposal almost seems to ratify doing that ("must have one of these profiles").
I do wish I had some more background on why the options are as they are, since the disposition says "now that we have more experience", but I cannot yet see the usecase for "must have a profile", and at first sight I don't like "cannot have a profile".
We won't have time to discuss this during a call, so we could agree to add this with discussion only taking place on chat.fhir.org. Since this is a change to a draft, non-normative resource (IG), I think procedurally we could put this in R4 to have something to discuss and test with.
Lloyd McKenzie (Jul 02 2018 at 10:54):
Must have one of the profiles allows for efficient validation. It doesn't have to imply secret information. I have a few projects where they use the Java validator as part of their production environment. Life is much easier if the base profile is declared in the instance.
Last updated: Apr 12 2022 at 19:14 UTC
