Stream: implementers
Topic: Tasks of Significance
Grahame Grieve (Sep 18 2016 at 16:23):
Changing reference to allow logical links: #GF10354 and #GF10659
Grahame Grieve (Sep 18 2016 at 16:23):
Josh Mandel (Sep 18 2016 at 16:25):
@Grahame Grieve Can you add a blog post link to the issue?
Grahame Grieve (Sep 18 2016 at 16:52):
Actually, I didn't post it :-(
Chris Grenz (Sep 18 2016 at 17:25):
(deleted)
Grahame Grieve (Sep 18 2016 at 18:09):
http://www.healthintersections.com.au/?p=2557
Josh Mandel (Sep 18 2016 at 18:38):
Thanks! That was a super-helpful writeup.
Chris Grenz (Sep 18 2016 at 18:39):
Ditto...we've been fighting this issue since the beginning, but it also rocks the world of anyone with a running implementation!
Josh Mandel (Sep 18 2016 at 18:43):
Agreed @Chris Grenz. I commented after you -- agree it's a huge upset.
Grahame Grieve (Sep 18 2016 at 18:48):
Josh, I had a technical issue with your comment. I too am conerned about the impact of the idea
Grahame Grieve (Sep 18 2016 at 18:48):
but I'm not sure how different it really is when you can just refer to a contained resource that contains the identifier. What's the difference?
Josh Mandel (Sep 18 2016 at 18:49):
The difference is that contained resources are clearly demarcated as "avoid this if you can".
Josh Mandel (Sep 18 2016 at 18:49):
We've made it difficult because we don't think it should be common.
Josh Mandel (Sep 18 2016 at 18:50):
Bringing this up to a first-class reference mechanism changes that stance.
Simone Heckmann (Sep 18 2016 at 18:50):
Um. Isn't this already resolved with the introduction of the conditional reference...?
Chris Grenz (Sep 18 2016 at 18:50):
2 cents - we're using contained resources as the primary method of doing this today (prior to conditional reference).
Grahame Grieve (Sep 18 2016 at 18:50):
well, we can still say to avoid it. I't not really more first class - just a little more convenient?
Chris Grenz (Sep 18 2016 at 18:50):
@Simone Heckmann I think so, except that the reference must be converted on write today.
Grahame Grieve (Sep 18 2016 at 18:50):
yes. this can persist.
Josh Mandel (Sep 18 2016 at 18:52):
More convenient == better supported. People will start using this kind of reference just because it looks good/fine/useful. Even if they don't need the use case it was designed for.
Grahame Grieve (Sep 18 2016 at 18:52):
that's what we said when contained resources were included. But it pretty much didn't turn out to be that much of a practical problem.
Grahame Grieve (Sep 18 2016 at 18:53):
not as much as people were concerned anyway
Josh Mandel (Sep 18 2016 at 18:53):
Because most people don't see/understand contained resources.
Josh Mandel (Sep 18 2016 at 18:53):
You have to go out of your way.
Josh Mandel (Sep 18 2016 at 18:55):
Anyway, I still think I prefer breaking out a separate .identifier better than overloading the .reference property — at least clients don't have to parse strings to figure out what's happening.
Simone Heckmann (Sep 18 2016 at 18:55):
GF#10659 should be satisfied with conditional reference. There's no particular request that the logical references have to be persitant.
Grahame Grieve (Sep 18 2016 at 18:55):
the intent is that it will be. The common case is where there isn't a server at all - SSN, etc.
Grahame Grieve (Sep 18 2016 at 18:56):
I've always argued to use contained resource for that, but one problem there is that sometimes they have mandatory elements you can't know
Chris Grenz (Sep 18 2016 at 18:56):
(deleted)
Josh Mandel (Sep 18 2016 at 18:57):
I thought we'd said that in the context of contained resources, all field were optional. I guess I just remember that as a discussion topic rather than a decision.
Grahame Grieve (Sep 18 2016 at 18:58):
definitely not a decision. And not easy to make that happen either, except to make nothing mandatory at all
Josh Mandel (Sep 18 2016 at 18:59):
It's a relatively small step ;-)
Grahame Grieve (Sep 18 2016 at 19:00):
I think you might get some pretty strong comments about that
Josh Mandel (Sep 18 2016 at 19:00):
Yeah, hence the wink.
Chris Grenz (Sep 18 2016 at 19:01):
I'd rather write the code to loosen up my contained resource validation than change how Reference works!
Chris Grenz (Sep 18 2016 at 19:01):
Is there some reason allowing conditional references to persist would _not_ meet the requirement?
Josh Mandel (Sep 18 2016 at 19:02):
I think it must meet the functional requirement, because it maps 1:1 syntactically with what Grahame's blog post proposed.
Josh Mandel (Sep 18 2016 at 19:02):
My concern is about confusing clients.
Simone Heckmann (Sep 18 2016 at 19:03):
I believe that there are in fact very few resources that still have mandatory elements. Wouldn't it be easier to remove these few that still remain? Deciding what's mandatory is the concern of profiles IMHO
Brian Postlethwaite (Sep 18 2016 at 21:35):
What about cases where a reference can be to multiple types?
You are able to differentiate based on the reference url, but which resource would the identifier come from?
Lloyd McKenzie (Sep 18 2016 at 21:40):
It'd be the same issue as if the reference was a urn:uuid. You can't necessarily look at the reference and know the resource type.
Brian Postlethwaite (Sep 18 2016 at 21:43):
In the case of the urn:uuid this is referencing a resource that is within the bundle, the indentifier is referencing a resource NOT in the bundle. (the receiving system is expected to already know about the resource with the identifier)
Ewout Kramer (Sep 19 2016 at 12:50):
Yes, that's what I was wondering about too. Is there an expectation (since Message and Document were mentioned) that the reference is always resolvable in the context of the Bundle?
Grahame Grieve (Sep 19 2016 at 13:01):
well, the existing rules would still apply, no?
Brian Postlethwaite (Sep 19 2016 at 13:40):
The urn:uuid can work out the type as it will resolve within the bundle you are processing (not exteral reference)
The relative or full URI will have the resource type in it so you can work out which it is also.
Just including an Identifier won't let you choose which resource type to scan for the identifier, so do you scan all permitted types in the reference choice list? (Such as with observation.subject, which is in the example on grahame's blog, which resource type do I search for that identifier?)
Grahame Grieve (Sep 19 2016 at 13:45):
Just to let everyone know, this will be discussed face to face Tues Q3 in 'MnM' (which owns the data types) (aka Modelling and Methodology)
Ewout Kramer (Sep 19 2016 at 18:12):
What I don't like about just using an identifier here is that it changes the concept of reference in two ways:
- It no longer refers to something that is unique and unmuteable, a reference may now refer to multiple things and worse, the identifier referred to is muteable. That means that systems storing this data may no longer resolve this link at storage time and convert it to e.g. a foreign key internally. As well, as time progresses, a reference to an identifier that was once unique, may become ambiguous, since another resource with a duplicate identifier may have been added to the system.
- A client does no longer know how to resolve the reference. It requires additional knowledge to know what system or architecture it is operating in to interpret the identifier and resolve the reference.
Elliot Silver (Sep 19 2016 at 18:16):
(deleted)
Simone Heckmann (Sep 19 2016 at 18:17):
We recently had a discussion here about how to handle merges: https://chat.fhir.org/#narrow/stream/implementers/topic/client.20responsibilities.20on.20reading.20merged.20patients
Bottom line was so far, that it might be useful to have add the "new" identifier to the merged resource, resulting in two resources with the same identifier, one active, one inactive.
I can handle that with the conditional references by adding ...&active=true to the url. But how does that work with the logical reference proposal?
Michel Rutten (Sep 19 2016 at 18:30):
I'm inclined to think that the proposed change does not apply to references to conformance resources. If these references cannot be resolved, then the system can't guarantee correct snapshot generation, validation etc.
Grahame Grieve (Sep 19 2016 at 18:40):
why are they different? why isn't that the same for any other reference?
Ewout Kramer (Sep 19 2016 at 18:45):
Actually, the conformance resources are a good example of where a Reference.identifier might be used, but where the client needs to know the context of the identifier to be able to resolve it. If we would have "identifier" on Reference, the reference would probably the canonical url for the conformance resource, not the actual endpoint where the conformance resource could be found. To resolve such an identifier, the client would have to go out to a (local) registry and resolve the identifier by searching on URL.
Grahame Grieve (Sep 19 2016 at 18:51):
only, it's not the right identifier
Lloyd McKenzie (Sep 19 2016 at 23:40):
@Ewout Kramer Reference doesn't necessarily refer to something unique (you can have <display = "John Smith"/>) and unless you specify version in your URL, it doesn't reference something immutable either. Plus, we can send identifier inside an extension now. So this is not changing what can be done in Identifier, merely recognizing what can be "common" in identifier, recognizing that what's common in REST and what's common in messaging/documents.
Lloyd McKenzie (Sep 19 2016 at 23:42):
Making this change *should* not change how any RESTful servers operate. And it reflects how external references are (and must) be handled in non-RESTful systems. And there are going to be a sizeable number of non-RESTful systems. FHIR Documents and FHIR Messaging may not have been first out of the block, but they're not going to be rare.
Grahame Grieve (Sep 19 2016 at 23:46):
how do you figure that it won't make any difference? All of us who maintain servers are looking at this change with extreme distaste
Lloyd McKenzie (Sep 19 2016 at 23:57):
How does it make any difference? There are reference instances now with "display" that you can't resolve. A reference with "identifier" would just be another type of reference you can't resolve.
Lloyd McKenzie (Sep 19 2016 at 23:58):
You couldn't resolve it any more if it was a reference with an extension or a reference to a contained resource with a bare id
Lloyd McKenzie (Sep 19 2016 at 23:59):
Yes, it's possible the *some* servers could choose to implement a way to resolve identifier references, but that would be specialized (and context-based) behavior. It's certainly not something the reference implementations would be expected to (or even should) do. And servers that only care about REST generally would have no need to do that sort of thing.
Grahame Grieve (Sep 20 2016 at 10:05):
I think you are saying, that we would document that resolution from an identifier reference (as opposed to a url reference) would be regarded as a broken link except by informed business processes that could resolve the association, and we would document it accordingly (e.g. chaining is not allowed to work)
Lloyd McKenzie (Sep 20 2016 at 12:44):
@Grahame Grieve Yes, that's what I'm saying.
Chris Grenz (Sep 20 2016 at 14:47):
Isn't that what using a contained resource implies? That there isn't enough information to provide the whole resource, but I'll provide what I have. An "informed business process" needn't be limited to resolving identifiers - I may determine that some other combination of elements may suffice to resolve the reference.
Chris Grenz (Sep 20 2016 at 14:49):
We've implemented this in our current messaging, and our server uses a business defined process to convert the contained reference (and contained resource) to a FHIR resource reference when able. Would be nice if there was a better way for a client to inform its intent here, but the process seems reasonable.
Chris Grenz (Sep 27 2016 at 00:40):
In the discussion on GF#12183 @Lloyd McKenzie made the assertion "For the vast bulk of systems, a reference with just 'identifier' won't be treated any differently than a reference with just 'display'." Is that what others were expecting, or were you expecting systems to attempt to resolve identifier based references?
Chris Grenz (Sep 27 2016 at 00:41):
Interested in community insight!
Grahame Grieve (Sep 27 2016 at 01:07):
check the current draft; I documented that resolution is business knowledge dependent
Chris Grenz (Sep 27 2016 at 01:10):
I like the current wording and the conformance choices.
Chris Grenz (Sep 27 2016 at 01:14):
I'm making the argument in GF#12183 that some systems will aggressively try to resolve logical references and in FHIR, that includes the ability to handle validity date ranges (due to the presence of Identifier.period). I guess we don't view period as simply informational but rather as a critical part of understanding the identifier's utility.
Chris Grenz (Sep 27 2016 at 01:14):
@Lloyd McKenzie respectfully disagrees!
Grahame Grieve (Sep 27 2016 at 01:24):
We can rely on Lloyd to disagree, and also to do that respectfully. Lloyd is an equal opportuntity disagreer
Grahame Grieve (Sep 27 2016 at 01:24):
I have no opinion on the date issue right now
Grahame Grieve (Sep 27 2016 at 01:24):
see further comments on the general issuer here:
Grahame Grieve (Sep 27 2016 at 01:24):
http://www.healthintersections.com.au/?p=2575
Chris Grenz (Sep 27 2016 at 01:26):
We're doing this one via the listserv? Like when it was 1985? ;)
Grahame Grieve (Sep 27 2016 at 01:31):
yep. but be nice. like when it was 1995
Grahame Grieve (Sep 27 2016 at 01:32):
but feel free to go off about it on facebook or snapchat or instathingy or whatever ;-)
Chris Grenz (Sep 27 2016 at 01:32):
Sorry...missed that...was reading documentation on how to use listserv...
Alexander Henket (Sep 27 2016 at 11:50):
Sent the first post to the list... let's see
Chris Grenz (Sep 27 2016 at 12:34):
OK...I think that's done...although I'm not 100% sure I did it right.
Chris Grenz (Sep 30 2016 at 22:40):
On the topic of required elements in contained resources...a simple(r) solution may be to defined every profile with 2 levels, one that specializes all the elements (min:0) and one that introduces the required elements:
Resource<-DomainResource<-ContainedPatient<-Patient
Chris Grenz (Sep 30 2016 at 22:40):
Snapshot for Patient is identical to today.
Chris Grenz (Sep 30 2016 at 22:41):
Not so damaging to XSDs...
Chris Grenz (Sep 30 2016 at 22:41):
just spitballing....
Grahame Grieve (Sep 30 2016 at 23:48):
I'll think about that it inevitably heads into covariant restrictions
Chris Grenz (Oct 04 2016 at 16:23):
Blogged about this topic here: https://www.linkedin.com/pulse/fhir-resource-identity-references-chris-grenz
Grahame Grieve (Oct 04 2016 at 19:38):
"Breaks current implementations" - why?
Grahame Grieve (Oct 04 2016 at 19:38):
an existing system working the way the existing system works will continue to work
Grahame Grieve (Oct 04 2016 at 19:40):
I'm also not sure why you're so invested in the idea that this solution 'restricts' you from providing additional details. When I wrote this up in the spec, I made exactly 0 changes to the wording around contained resources
Grahame Grieve (Oct 04 2016 at 19:41):
"But in a not-insubstantial set of cases, the identifier needed to be qualified by a date (identifier re-use) or another attribute (date of birth, email, pager number, location, etc.)."
- identifier has a period.
- I don't understand the other use cases
Chris Grenz (Oct 04 2016 at 19:53):
Breaks I'm concerned about are primarily around information (presumably of value) located in a previously unavailable location.
Chris Grenz (Oct 04 2016 at 19:54):
See GF#12183 for the date issue...
Chris Grenz (Oct 04 2016 at 19:55):
As for additional details, I suppose you could have both reference.identifier and reference.reference with a contained reference for the other stuff. which is really ugly.
Grahame Grieve (Oct 04 2016 at 19:58):
so technically, it breaks *forward* compatibility, not backwards compatibility
Chris Grenz (Oct 04 2016 at 19:58):
Sure, technically.
Grahame Grieve (Oct 04 2016 at 19:59):
btw, you won't get any traction for saying that we shouldn't do that. (but we should always consider the cost, which is why we have this process now)
Chris Grenz (Oct 04 2016 at 19:59):
I'm not against change, that's just one point to consider.
Grahame Grieve (Oct 04 2016 at 20:00):
I agree that it would be bad to have both reference.identifier and reference.contained.
Chris Grenz (Oct 04 2016 at 20:01):
I'm concerned that the identifier solution add a half-solution to a half-solution (contained) resulting in something less than elegant
Grahame Grieve (Oct 04 2016 at 20:01):
well, there's no elegance in this space anyway, because the problem is (pretty much) lack of elegance
Chris Grenz (Oct 04 2016 at 20:01):
Doesn't mean we shouldn't try!
Chris Grenz (Oct 04 2016 at 20:02):
I actually think that the contained option isn't as bad as all that and could be massaged a bit...
Chris Grenz (Oct 04 2016 at 20:03):
I'm very concerned that the client server interaction lacks clear communication about intent and result
Grahame Grieve (Oct 04 2016 at 20:04):
what's not clear?
Chris Grenz (Oct 04 2016 at 20:07):
Whether the client would like the server to attempt to resolve the reference.
Chris Grenz (Oct 04 2016 at 20:08):
Also, should the server be able to communicate resolution rules per-resource?
Lloyd McKenzie (Oct 04 2016 at 20:43):
I think there's a significant difference between a Reference with a bare identifier and a reference to a contained resource. With a contained resource, there's no expectation for any resolution at all. You'd have to have special business rules to decide if and how resolution might occur. With an identifier, there's an expectation for resolution at the business level, if needed.
Brian Postlethwaite (Oct 04 2016 at 20:46):
Bad to have both identifier and reference populated?
I would have thought this would be desired. If I received a resource in with the identifier reference populated, then resolevd it and set the reference, should I then discard the identifier link too?
(as that would contain the information that was used to resolve the link, incase things changed)
(We would also need to document how that could change things if patient link/merge was done)
Chris Grenz (Oct 04 2016 at 20:56):
@Lloyd McKenzie I'm not sure that assumption is going to hold, especially if the guidance is that contained is the place where we store everything that's not explicitly an identifier.
Chris Grenz (Oct 04 2016 at 20:57):
I see a very similar/parallel issue in the messaging space when a known patient record is send in the message bundle with the clinical payload.
Chris Grenz (Oct 04 2016 at 20:58):
What does the receiver do with that data? Match to the existing?
Brian Postlethwaite (Oct 04 2016 at 21:14):
In the messaging, its the case of deciding is the a patient for storing, or for matching.
Chris Grenz (Oct 04 2016 at 21:14):
Which the server is certainly free to decide.
Chris Grenz (Oct 04 2016 at 21:15):
However, in some cases, I'd like to be able to communicate that my *only* intent in providing a record is solely for matching
Chris Grenz (Oct 04 2016 at 21:16):
I'm not trying to update anything or even communicate that my data is reliable for anything other than matching
Brian Postlethwaite (Oct 04 2016 at 23:27):
Was there a reason we only had a cordiality of 0..1 on the reference and not 0..*
Last updated: Apr 12 2022 at 19:14 UTC
