Stream: terminology
Topic: GF#17475
Rob Hausam (Jul 30 2018 at 22:40):
GF#17475 - It would be good to get some opinions on whether we should remove the vsd-5 invariant on ValueSet which says "Value set SHALL contain at least one of a compose or an expansion element", and allow for the possibility of ValueSet resource instances which are "metadata only". It does appear that even with the vsd-5 invariant Yunwei's concern about the burden on a _summary search which returns large numbers of extensionally defined value sets could possibly be mitigated by the fact that the only elements under 'include' that are marked as "summary" are 'system', 'version', 'filter' and 'valueSet', but not 'concept'. That should substantially reduce the burden, so maybe it's not necessary to remove vsd-5? But I'm also not sure what purpose vsd-5 is actually serving? In thinking about it further it doesn't seem like it's protecting against any particular invalid or undesired representation.
And back to "summary" for a moment, I noticed that 'include' is in fact included in the summary but 'exclude' is not - unless it gets included by default because it refers back to 'include'? Even if the latter is somehow the case, it would be less confusing if that was made explicit.
Peter Jordan (Jul 31 2018 at 03:09):
Again, this boils down to definition (class/compose) v instance (object/expand) and one or the other is required. One suggestion for defining extensional value sets is to populate the compose.include.filter element values along these lines...property="Extensional", op=FilterOperator.Equal, value="true". That might denote "Extensional Value Set - contents only available if expanded".
Grahame Grieve (Jul 31 2018 at 06:33):
I think we should remove it and just note about the use cases for having both / either / none in the narrative
Robert McClure (Jul 31 2018 at 14:17):
I'm not convinced that the invariant should be removed simply to make summary retrievals computational. I see no value in a value set resource that is only metadata. I think instead we need to improve how summary retrieval works
Rob Hausam (Jul 31 2018 at 15:31):
@Robert McClure The potential value that I can see (particularly in a summary search) is that you can retrieve a list of all of the value sets that are available, and for any that are of further interest you can then request the full resource(s). I think that's essentially what @Yunwei Wang was looking for.
Robert McClure (Jul 31 2018 at 19:53):
I must be not understanding something. Why not have a parameter allow ValueSet?_summary=true search to bring back only metadata?
Grahame Grieve (Jul 31 2018 at 20:36):
we do indeed have exactly that parameter,but what comes back form that has to be valid, and a value set with metadata only is not currently valid because of that constraint
Robert McClure (Aug 01 2018 at 00:43):
@Grahame Grieve this seems to be a catch22. There must be some way around support for providing a returned "resource view" that is only part of a resource. This can't be the only situation where this issue exists.
Brian Postlethwaite (Aug 01 2018 at 03:50):
That's correct, if properties are masked out for security/redacting purposes, would that still need to conform?
Grahame Grieve (Aug 01 2018 at 04:21):
we've argued about this, and we'd be happy to revisit this, but I don't think now is the time. If we clearly document the SHALLS in narrative, we can come back to a formal constraint like this one as a formal constraint in R5
Brian Postlethwaite (Aug 01 2018 at 06:34):
Maybe in Baltimore
John Moehrke (Aug 01 2018 at 13:07):
The issue of redaction resulting in a valid resource is a broader group discussion. I was always expecting it must be still a valid Resource. This is the way I have written standards/handbook text. It is difficult sometimes, but it has always been considered a non-negotiable. Surely there are specific projects that will drop conformance requirements, but all public standards discussion have always assumed underlying standard conformance is still required.
Brian Postlethwaite (Aug 01 2018 at 13:17):
status is a required property and if it was redacted, what do we do?
Brian Postlethwaite (Aug 01 2018 at 13:18):
But discussion for later.
John Moehrke (Aug 01 2018 at 13:25):
this is why de-identification is a PROCESS. What you do with required fields tends to become obvious when one considers the reason for de-identification. For example, one likely notices that the study already required that all status must already be active... so leaving it as active does not expose anything that isn't already known to the study participants and administrators.
Michael Lawley (Aug 03 2018 at 03:48):
_elements allows for selective retrieval of the ValueSet. I'd like to understand why it is not suitable for @Yunwei Wang 's use case
Grahame Grieve (Aug 03 2018 at 04:10):
it is. the issue isn't summary, the issue is that the invariant means that by whatever means, you have a value set with neither compose or expansion
Michael Lawley (Aug 03 2018 at 04:22):
So the representation doesn't validate, but isn't that (almost) always going to be the case with _elements?
Grahame Grieve (Aug 03 2018 at 04:23):
no you can't eliminate mandatory things, or the server should ignore your request to do so
Michael Lawley (Aug 03 2018 at 04:27):
Hmm, that's not so great for my use-case which has been using _elements to optimise network bandwidth. It's also not how HAPI behaves.
Grahame Grieve (Aug 03 2018 at 04:29):
where would that create a problem?
Michael Lawley (Aug 03 2018 at 04:58):
I might not want ValueSet.status, for instance. But also this very discussion - I don't care about expansion or compose but maybe just name/title, version and URI because I'm populating a UI
Grahame Grieve (Aug 03 2018 at 05:23):
this is a hard problem; we've tried in the past to say that summarised resources don't have to be valid... but discussing where that leads always ges to a place we don't like. So... they have to be valid. but mostly, the things that are mandatory are not big, and it's not a problem.
Brian Postlethwaite (Aug 03 2018 at 05:42):
Maybe just relax the invariant requirements then?
Grahame Grieve (Aug 03 2018 at 05:43):
that's the proposal. it's generating considerable pushback
Brian Postlethwaite (Aug 03 2018 at 05:43):
Gets a +1 from me.
Robert McClure (Aug 03 2018 at 17:34):
To be clear, relaxing an invariant simply to make one use case work is a very bad idea because folks will simply ignore the single use case and stop following the guidance. That invariant exists because a resource without either a compose or an expansion makes NO sense. The use case is about a quick search to find things you want but then you will expect that value set resource to actually have something when you go to use it. So no, I'm not in support of allowing nonsense resources simply because we want searching to be easier.
Grahame Grieve (Aug 03 2018 at 19:22):
so you are picking some use cases to require validity for? And not others? It's pursuing the consequences of that decision that lead us to trouble.... We are certainly not going to change that rule at this point in the process (it would be a global rule that affects all implementers of everything)
Grahame Grieve (Aug 03 2018 at 19:24):
this comes up for many resources: the common uses lead to common sense minimum cardinalities... but the edge cases mean that they have to be optional. Value set is not special in this case.
Lloyd McKenzie (Aug 03 2018 at 20:24):
The core specification's purpose is not to enforce best (or even good) practice. It's simply to provide a standard mechanism to share what data systems have - whatever that is. Any invariants in the core specification should be limited to prohibiting content that is clearly non-sensical. Good practice/best-practice can be flagged using an appropriate invariant type in core or through the creation of profiles.
Lloyd McKenzie (Aug 03 2018 at 20:25):
(Rationale is that good/best practice is always context-specific and resources are always context-independent.)
Michael Lawley (Aug 04 2018 at 07:20):
I see no problem in a metadata-only ValueSet. The very omission of both compose and expansion makes it clear that it's incomplete. +1 from me on removing vsd-5
Brian Postlethwaite (Aug 07 2018 at 00:04):
A unit test for this could be to validate all example resources in the spec with them in their summary format.
Grahame Grieve (Aug 07 2018 at 00:59):
gee let me run out and write that
Rob Hausam (Aug 07 2018 at 02:13):
The proposed resolution has been pre-applied. We discussed it on the Vocab FHIR Tracker Issues call today and had agreement on it and will vote on Thursday.
Grahame Grieve (Aug 07 2018 at 02:16):
great - thanks
Last updated: Apr 12 2022 at 19:14 UTC
