FHIR Chat · HAPI validator error - traversing bundles

Stream: implementers

Topic: HAPI validator error - traversing bundles

Katie Wheatley (Aug 28 2018 at 12:22):

I received this error message when running HAPI 3.4 against the attached xml message instance named ITK-OPL-TEST-019-1.xml. I would like clarification as to why this error appears as I do not understand why HAPI is throwing it out as an error. I would not expect the entries it identifies as problematic in the second document bundle to be reachable from the first message bundle as I believe the two bundles should be separate. Also, there are many entries within the document bundle which cannot be reached from the first bundle and these are not highlighted as errors, so why these ones in particular? Should this error message rather be a warning instead?
The entries which are highlighted as problematic are those in the document bundle which are based on the Practitioner and Organization resources. These resources are also referenced in the message bundle, specifically from the profile ITK-MessageHeader-2, but the profiles are different and differently named to those in the document bundle, e.g. in the message bundle they are named CareConnect-ITK-Header-Practitioner-1 and CareConnect-ITK-Header-Organization-1 and in the document bundle they are named CareConnect-Organization-1 and CareConnect-Practitioner-1.
Below are the links to the raw xml for the relevant FHIR profiles too, as I believe these could be pertinent to solving this issue.

The full details of the errors are:-

ITK-OPL-TEST-019-1.xml FAIL ERROR -- DOCUMENT BUNDLE: Entry isn't reachable by traversing from first Bundle entry * Location: Bundle.entry[12] column: 0
ITK-OPL-TEST-019-1.xml FAIL ERROR -- DOCUMENT BUNDLE: Entry isn't reachable by traversing from first Bundle entry * Location: Bundle.entry[13] column: 0
ITK-OPL-TEST-019-1.xml FAIL ERROR -- DOCUMENT BUNDLE: Entry isn't reachable by traversing from first Bundle entry * Location: Bundle.entry[15] column: 0
ITK-OPL-TEST-019-1.xml FAIL ERROR -- DOCUMENT BUNDLE: Entry isn't reachable by traversing from first Bundle entry * Location: Bundle.entry[18] column: 0
ITK-OPL-TEST-019-1.xml FAIL ERROR -- DOCUMENT BUNDLE: Entry isn't reachable by traversing from first Bundle entry * Location: Bundle.entry[19] column: 0
ITK-OPL-TEST-019-1.xml FAIL ERROR -- DOCUMENT BUNDLE: Entry isn't reachable by traversing from first Bundle entry * Location: Bundle.entry[20] column: 0
Attachments (1) ITK-OPL-TEST-019-1.xml
@James Agnew I wondered if you could help with this issue?

Lloyd McKenzie (Aug 28 2018 at 15:17):

Within the document Bundle, all entries in the Bundle need to be reachable by traversing from the Composition. For example, your PractitionerRole cd734ce9-468d-4a36-8dac-e453aa4747e0 isn't pointed to by anything. And Practitioner 88f1ca61-0200-4943-a066-baf9a1570029 is only pointed to by that PractitionerRole, so it's not connected either.

Lloyd McKenzie (Aug 28 2018 at 15:18):

That's a base rule in the FHIR specification, so it's not an issue with HAPI

Katie Wheatley (Aug 28 2018 at 16:02):

That's a base rule in the FHIR specification, so it's not an issue with HAPI

Thanks very much for your response, Lloyd. Practitioner 88f1ca61-0200-4943-a066-baf9a1570029 is traversable from the Composition entry, but the PractitionerRole entries are not and I believe that is the problem which is generating the error. All the errors I believe relate to Practitioners and Organisations which are referenced in PractitionerRole entries.

Katie Wheatley (Sep 07 2018 at 06:10):

Within the document Bundle, all entries in the Bundle need to be reachable by traversing from the Composition. For example, your PractitionerRole cd734ce9-468d-4a36-8dac-e453aa4747e0 isn't pointed to by anything. And Practitioner 88f1ca61-0200-4943-a066-baf9a1570029 is only pointed to by that PractitionerRole, so it's not connected either.

I have looked into this issue in a little more detail. Within the xml example attached, I don't have any orphaned resources and they are all reachable from Composition either directly or indirectly. This does seem to me to conform to the FHIR documents guidance at https://www.hl7.org/fhir/documents.html where it states that

*The document bundle SHALL include only:
The Composition resource, and any resources directly or indirectly (e.g. recursively) referenced from it*

The HAPI validator error I received above is thrown against the Practitioner and Organization entries where they are referenced within the PractitionerRole entries. Both the Practitioner and Organization entries are referenced directly from Composition within the document bundle. PractitionerRole links to them as it contains references to them - that is how PractitionerRole works in FHIR as neither Practitioner nor Organization hold references to it - the referencing works the other way around.
That is why I believe that the error thrown by the HAPI validator may be because HAPI is not interpreting the FHIR guidance correctly. I would welcome more discussion on this.

Lloyd McKenzie (Sep 07 2018 at 06:42):

In STU3, there was no allowance for reverse-direction relationships. That's fixed in R4. However, you'd still want the Composition to point to PractitionerRole, not Practitioner. If Composition points to Practitioner, you're saying "this was created by Dr. Smith, but I don't know/care what role she did it in or on behalf of what organization she did it; oh and by the way, here's one of the roles that Dr. Smith works". Presumably that's not what you're wanting to say.

Kevin Mayfield (Mar 11 2019 at 14:27):

This is an issue on 3.7 HAPI, we have a message Bundle which has focus of Encounter.

Other entries have context of Encounter, they all come up as 'Entry isn't reachable by traversing from first Bundle entry'

Kevin Mayfield (Mar 11 2019 at 15:30):

Believe this needs to be added to HAPI Validator

Comment in InstanceValidator class

// Todo - check if the remaining resources point to the elements in the referenced set. Any that are still left over are errors

@Lloyd McKenzie can you confirm implementing this TODO is still within FHIR rules?

Lloyd McKenzie (Mar 11 2019 at 15:44):

That comment is no longer in the shared HL7/HAPI code and I seem to recall refactoring it to address the issue, so that problem shouldn't exist in the most recent version of HAPI.