Stream: IG creation
Topic: Message bundle validation issue
Tim Blake (Nov 28 2019 at 03:32):
I have a bundle of type="message", with a MessageHeader as the first entry in the bundle. An example bundle in the IG is getting several of the following errors in qa.html:
"Entry isn't reachable by traversing from first Bundle entry"
Should that constraint be triggered for a message bundle? Not sure how a MessageHeader could cause the other entries to be reachable?
Grahame Grieve (Nov 28 2019 at 04:04):
oh. this is the contexst
Grahame Grieve (Nov 28 2019 at 04:05):
I thought we said this somewhere
Tim Blake (Nov 28 2019 at 04:05):
Sorry, my bad
Grahame Grieve (Nov 28 2019 at 04:06):
well, I can't find it. @Lloyd McKenzie ?
Lloyd McKenzie (Nov 28 2019 at 05:50):
The MessageHeader.focus should point to something and everything else should be linked by some path to that.
Eric Haas (Nov 28 2019 at 06:57):
see this error #2. the reverse link causes this error in my case: https://chat.fhir.org/#narrow/stream/179252-IG-creation/topic/link.20errors.20for.20uuids.20in.20a.20bundle/near/180897993
Lloyd McKenzie (Nov 28 2019 at 15:49):
It's possible that reverse links aren't well-handled by the code, though the algorithm should find them...
Tim Blake (Nov 28 2019 at 21:53):
I'm getting "Entry isn't reachable by traversing from first Bundle entry" for all of the reverse links...
Grahame Grieve (Nov 29 2019 at 01:20):
@Lloyd McKenzie
The MessageHeader.focus should point to something and everything else should be linked by some path to that.
I can't find this written anywhere?
Grahame Grieve (Nov 29 2019 at 01:30):
@Lloyd McKenzie this code must be wrong:
List<String> references = findReferences(unusedResource); for (String reference: references) { if (!visitedResources.containsKey(reference)) { visitedResources.put(reference, unusedResource); reverseLinksFound = true; } }
Grahame Grieve (Nov 29 2019 at 01:31):
if you find a reference in an unlinked resource.. then if it doesn't point to a resource already linked, call it a new link... surely the ! is wrong?
Grahame Grieve (Nov 29 2019 at 01:32):
also, that code generally doesn't use the bundle resolution algorithm
Grahame Grieve (Nov 29 2019 at 02:11):
I rewrote it from scratch
Grahame Grieve (Nov 29 2019 at 02:13):
fixed next release
Grahame Grieve (Nov 29 2019 at 02:14):
btw, issues related to message interlinking of resources are warnings until @Lloyd McKenziecan point to where in the spec it says that this isn't allowed
Tim Blake (Nov 29 2019 at 02:46):
Thanks. I can't find it in the spec either, nor understand the reason why this would always need to be the case...
Lloyd McKenzie (Nov 29 2019 at 03:38):
It makes no sense for a message to contain content that isn't linked (somehow) to the MessageHeader. Sending content with no connection means the content has no meaning relating to the message event or to the message focus. As well, the MessageDefinition resource provides two mechanisms for defining the content - profile (which allows you to trace only forward-path relationships) and GraphDefinition which allows you to trace both forward and reverse path references. Both Document and MessageHeader start with a special resource and the remainder of the Bundle contains related resources. Document has clear language requiring that. I thought we'd approved a change request to add the same for messaging, but I can't find it.
Lloyd McKenzie (Nov 29 2019 at 03:39):
@Tim Blake What's your use-case for sending unconnected content in the message? What sort of event code are you using? What is the focal resource for the message?
Tim Blake (Nov 29 2019 at 03:41):
I don't have one in mind. I was just wondering why this constraint exists? Why does it matter if you can't reach every resource?
Lloyd McKenzie (Nov 29 2019 at 03:51):
If the resources aren't reachable, then they have no relevance to the message - at least as far as the recipient can tell...
Grahame Grieve (Nov 29 2019 at 05:35):
@Lloyd McKenzie I didn't ask for an explanation I asked where we said this
Lloyd McKenzie (Nov 29 2019 at 14:28):
As far as I can tell, we don't. Do you disagree that we should? If we're in agreement, I'll submit a tracker item
Vassil Peytchev (Nov 29 2019 at 14:46):
The closest thing to this requirement being mentioned is in the definition and comments to MedsageHeader.focus. I agree that's not sufficient, and needs to be made explicit.
Vassil Peytchev (Nov 29 2019 at 14:47):
http://build.fhir.org/messageheader-definitions.html#MessageHeader.focus
Grahame Grieve (Nov 29 2019 at 17:36):
we should certainly have a task. I'm less persauded it should be a rule. A FHIR equivalent of a records management message for instance - why should it have to reference every resource in the .focus?
Vassil Peytchev (Nov 29 2019 at 17:40):
It is not that you reference every resource in .focus, quite the opposite - more than one reference in .focus is only for special messages like merge.
The "rule" is that, starting from .focus, you can (indirectly) reach every resource in the message bundle.
Grahame Grieve (Nov 29 2019 at 17:48):
so you would need a lit to list all the resources in a ,say , Master Files message? just because we wanted to make this rule? Or in a query response message? I think that is not a value proposition.
OTOH, I firmly agree that dropping random unlinked and undescribed resources into a message is a bad thing. But I think it depends on the event
Lloyd McKenzie (Nov 29 2019 at 18:06):
If you have a MasterFiles message, then yes, the MessageHeader would point to each of the providers or ObservationDefinitions that are included. (Because there may be some situations where Practitioners are included in the message that aren't "focuses" of the event but are included for other reasons.) Traversing the relationships or being pointed to by 'focus' is the only way you know how to interpret a particular instance in the message.
Grahame Grieve (Nov 29 2019 at 18:07):
the MessageHeader would point to each of the providers
Doesn't seem like a value proposition to me. A master files message only containing practitioner resources to update?
Lloyd McKenzie (Nov 29 2019 at 18:09):
Lloyd McKenzie (Nov 29 2019 at 18:10):
The value proposition is clarity about what's happening. You can't know that the only content in the message will be practitioners that are the focus of the update - there could be practitioners they're being linked to or that are authoring the change, etc.
Lloyd McKenzie (Nov 29 2019 at 18:11):
All meaning in FHIR comes from relationships. If you don't have relationships, you have no idea what's going on.
Grahame Grieve (Nov 29 2019 at 18:11):
it depends on the definition of the event. I think that we have to consider that in the rule
Lloyd McKenzie (Nov 29 2019 at 18:11):
Furthermore, there's no capability to define the content if it's not connected. MessageDefinition can't handle that.
Vassil Peytchev (Nov 29 2019 at 18:18):
FWIW, the V2 master file messages have an MFI segment to identify what "Master File" is being updated, and MFE segments to contain the records for the master file that are changed. The specific purpose v2 messages have even more complicated structure, which leads me to think that a FHIR Master File message will be unlikely to just have a header and 1..n resource[T] as the entries in the bundle. List, or something else will be present.
Kevin Mayfield (Nov 30 2019 at 06:07):
I'm may be off on a tangent but I thought the purpose of graph in MessageDefinition was to define the message (response) content? Even if the GraphDefinition only contains 'nodes', it could still define profiles and cardinality.
Lloyd McKenzie (Dec 01 2019 at 15:51):
The point is that in GraphDefinition, everything has to be connected. There's no mechanism to specify non-connected nodes
Grahame Grieve (Dec 01 2019 at 18:42):
should there be? But that's a different question
Eric Haas (Dec 01 2019 at 23:53):
We had approved a tracker to this in FHIR-I a few weeks back...
https://jira.hl7.org/browse/FHIR-23722
Grahame Grieve (Dec 02 2019 at 00:02):
ok I will make it an error in R5, not a warning
Last updated: Apr 12 2022 at 19:14 UTC
