Stream: implementers
Topic: Header
Medi Harsini (Feb 17 2020 at 12:37):
In a multi tenant platform, how one incorporate header information on any given resource. Eg. if the resource in question is an appointment but you also wanted to see the originating system and destination systems as well as the use who initiated the transaction, how would you deliver this? This is similar that the MSH segment we use to have in HLv2.x
Vassil Peytchev (Feb 17 2020 at 14:25):
One approach is to have different base URL for each tenant, and your authorization and authentication mechanisms will take care of identifying the source system and user.
Lloyd McKenzie (Feb 17 2020 at 15:29):
In a RESTful interface, the only destination is the server it gets posted to. (If you're looking for routing, you'll need FHIR messaging.). Information about where a record came from can/should be captured using Provenance.
Medi Harsini (Feb 17 2020 at 16:22):
@Vassil Peytchev I agree thats one way of doing it... I am however after something more scalable for a large scale solution... @Lloyd McKenzie Is using Provenance a common way of doing it? Isnt it better to add extension for that?
Lloyd McKenzie (Feb 17 2020 at 19:02):
Provenance is the standard way of capturing the context for any record - who created it, what organization they did it on behalf of, what location they were in, why they did it, when they did it, who supervised or approved it, etc.
Medi Harsini (Feb 26 2020 at 22:16):
Can you have multiple resources contained in one resource. For example have the provenance which has three resources contained in parallel @Lloyd McKenzie
Lloyd McKenzie (Feb 26 2020 at 22:33):
Resource.contained repeats, so yes you can have multiple contained resources. Just remember that containment is for resources that can't stand alone, it's not a packaging mechanism for simple delivery. If you make a resource contained, you should expect the receiver to keep it contained and not usually support searching on it directly.
Medi Harsini (Feb 27 2020 at 14:16):
@Lloyd McKenzie so if you have a documentReference and wanting to send the patient details as a contained resource, you cannot do it because patient resource can exist separately and is searchable . This is an extreme case where the patient reference cannot be provided in the documentReference
John Moehrke (Feb 27 2020 at 14:33):
In the IHE implementation Guide for document sharing, there is use of contained Patient as known at the source. This is expected use-case. Lloyd is just cautioning to not use contained when one should not use contained, a common warning as it is easy to use it and later be unhappy.
Medi Harsini (Feb 27 2020 at 14:45):
Thanks @John Moehrke .. Cant agree more. My usecase is similar to above example. I have a job description (literally a job/role) and I want to make a request based on that. But the request cannot reference the job always, this is to increase workforce management staff placement enhancement. So I want to send a request whilst I have got the job details contained
Lloyd McKenzie (Feb 27 2020 at 15:34):
It's fine to send the patient info as a contained resource if you've got limited information. E.g. you're just capturing birth year and gender. However, if you've got a contained patient, then you can't expect to be able to subsequently search for all DocumentReferences associated with a given patient.
Medi Harsini (Feb 27 2020 at 15:44):
Thanks @Lloyd McKenzie Technically speaking I dont have any problem with the logic provided, but from what I ve seen in IHE projects, this may not be necessarily the case. I will have to contained in for my example above as I really have to send them all together but they may exist also outside the contained bundle. Thanks again.
Last updated: Apr 12 2022 at 19:14 UTC
