Stream: ihe
Topic: Handling of resource.ids in IHE Profiles
Reinhard Egelkraut (Jul 24 2018 at 12:51):
During the implementation of IHE Profiles with FHIR like MHD, PIXm or PDQm in Austria the problem came up how to deal properly with the ID of the resources in a efficent way. But since this issue isn't limited to IHE Profiles it was posted in the implementers stream:
https://chat.fhir.org/#narrow/stream/4-implementers/topic/Resource.2Eid.20restrictions
John Moehrke (Jul 24 2018 at 13:03):
I agree this is bigger, and you characterized it well over there... I am not surprised to see MHD stress this limit, as I did expect some would want to just concatenate XDS stuff into the FHIR id. Glad to have this discussion now, not later after they make these things normative and thus non changeable.
Reinhard Egelkraut (Jul 25 2018 at 12:27):
@John Moehrke thanks for the support. I think that no matter what the outcome of the other discussion finally is, it would be useful to consider it and to add some information or even better recommendations for implementation about how to deal with the resource.id in the relevent IHE Profiles. Otherwise this issue will come up again and again. What's your opinion?
John Moehrke (Jul 25 2018 at 12:36):
If I understand the issue is the on that Bill outlined on his github page. Then all of those have been further analyzed, and CP have been filed. All of these can be found with my comments on the MHD wiki page https://wiki.ihe.net/index.php/Mobile_access_to_Health_Documents_(MHD)#Post_Publication_CP
Reinhard Egelkraut (Jul 25 2018 at 13:02):
ah I see, thank you.
it's CP-ITI-1113, isn't it?
So the goal of this CP would be to clarify the proper FHIR compliant URL format for e.g. "Light weight multiple repository support" and therefore also to implicitly provide some guidance on how to deal with resource.id in general, correct?
John Moehrke (Jul 25 2018 at 13:10):
I am not exactly what is not clear.... The url does have some constraints during the Provide transaction, as it must be well formed to support the Binary in the bundle... But that constraint is not applicable during any of the query / retrieve; where there is no constraint.
Reinhard Egelkraut (Jul 26 2018 at 16:09):
It is not so much about that something is still not clear, it's more to provide further guidance for implementers.
When an implementer has already experience with FHIR, it's clear that the logical ID of a resource is a rather important thing (for exact searches, performing updates, deletes, building references, working with contained resources etc.). If confrontend with IHE Profiles like MHD on the other hand the resource.id is hardly mentioned at all. Which could lead to some questions like in our case (which is a specific one I agree but still).
So I am just suggesting to add some lines in the according Profiles to give information about how, when and when not resource.id is used like:
- it's not necessary for query / retrieve transactions because for each transaction specific "Query Search Parameters" are defined
- but it's important for the contained resources in the bundle like patient, practitioner, organization and especially binary
- how to deal with it in special use cases like for CP-ITI-1113 when multiple repositories are in place or there is an other potential situation of making the logical ID longer than 64 characters
It's just an idea that could make the life of implementers easier, especially for those who are confronted with both worlds FHIR and IHE i.e. while implementing components for MHD Document Responder & XDS Document Consumer or the Source equivalents.
John Moehrke (Jul 26 2018 at 16:12):
I understand what you say, but don't know how to translate that into a specific change to the MHD text.
I could see adding a note that the .id element must follow the FHIR requirements... but not anymore than that
John Moehrke (Jul 26 2018 at 16:14):
however that is already true... MHD can not change core FHIR requirements. Restating all of those core FHR requirements is not helpful to the reader. So want to avoid that 'slippery-slope'
Reinhard Egelkraut (Jul 26 2018 at 16:30):
So a "Tips & Tricks" section would come in handy :simple_smile:
No, but I do see your point. I plan to attend the next WGM in Baltimore, so if you are also there we could use it to put our heads together, maybe we can come up with a feasible idea.
Last updated: Apr 12 2022 at 19:14 UTC
