Stream: implementers
Topic: DocumentReference.custodian for technical location
Jeffrey Willis (Jul 19 2017 at 16:52):
The documentation for DocumentReference.custodian describes it as "Identifies the logical organization to go to find the current version, where to report issues, etc. This is different from the physical location of the document, which is the technical location of the document, which host may be delegated to the management of some other organization."
I understand that to be a hospital or hospital system, as opposed to a piece of software serving as a repository for the document. If I wanted to express the "technical location" or ownership of a DocumentReference, does anyone have suggestions in the existing specification?
Thank you!
Lloyd McKenzie (Jul 20 2017 at 01:49):
As distinct from the server that's hosting it?
Jeffrey Willis (Jul 20 2017 at 13:42):
If I understand your question, yes, different than the hosting server.
The two scenarios I'm thinking of are:
1. A different technical organization gives my system a document and wants me to hold onto it but not change it. That other technical organization is the "owner" and my system is the repository.
2. A different technical organization gives my system a document and wants me to hold onto it but also own it; the other technical organization is giving up ownership.
In those scenarios, the transfer of the document could be happening within the same hospital.
John Moehrke (Jul 20 2017 at 14:58):
Why is it important to know the physical location? Your examples show why it is important to know the custodian, which is why that element exists. The URL tells you where the virtual location is. I am not understanding the need. Especially in light of 'cloud' where there really is no physical location of the bits. If you can express why that is important, then you could submit a CR. I would suggest that this need would clearly fall outside the 80%; and at best could be a core extension. I would be happy to support it as an extension, with good explanation. I am just not yet understanding why the physical location of bits is important. Seems virtual location (URL) is all that is needed.
Jeffrey Willis (Jul 21 2017 at 14:55):
Hello John, thank you for your question and comments. I'm not necessarily looking for a change of the specification but looking to understand the use of custodian or if there is another element that's suitable.
Why is it important to know the physical location?
It's not the physical location that I'm interested in knowing. My system is trying to store documents from a sending system via POSTs to DocumentReference. Sometimes the sending system wants to retain ownership of the document, other times it wants to relinquish ownership.
I'm looking for an analogous element for DocumentReference.custodian but for the owning system or technical owner.
John Moehrke (Jul 21 2017 at 15:00):
Good discussion. So then why is custodian not effective? What part of the definition of custodian concerns you?
Rick Geimer (Jul 21 2017 at 15:11):
Does DocumentReference.custodian -> Organization.endpoint solve the problem? Perhaps with some extensions to Endpoint?
Jeffrey Willis (Jul 21 2017 at 19:50):
Good discussion. So then why is custodian not effective? What part of the definition of custodian concerns you?
The comments in the documentation say, "This is different from the physical location of the document, which is the technical location of the document, which host may be delegated to the management of some other organization."
To me that seems to say the the organization would be the hospital, not my system (which resides within the scope of the hospital). Otherwise I think custodian is a good fit for what I'm looking to do.
Jeffrey Willis (Jul 21 2017 at 19:52):
Does DocumentReference.custodian -> Organization.endpoint solve the problem? Perhaps with some extensions to Endpoint?
This seems to describe the metadata needed to connect to the organization, I'm not certain this would suit without some further reading.
John Moehrke (Jul 21 2017 at 20:03):
I would expect the hospital holds some authoship, and doesn't bother with custodian. Thus the ONLY time custodian would be used is a case like you decribe.
Jeffrey Willis (Jul 24 2017 at 14:10):
That sounds like just what I need. Thank you for your time and for the discussion!
John Moehrke (Jul 24 2017 at 14:20):
good to hear... so, given this understanding... Can you suggest a wording change to the custodian element definition, description, and/or notes? Seems this is a good opportunity for you to suggest an improvement.
Jeffrey Willis (Jul 24 2017 at 18:30):
I think including some definitions or descriptions to better frame the difference between logical and physical ownership would be helpful.
Here is the current custodian comments. My additions are in bold.
Identifies the logical organization (software system, vendor, or department) to go to find the current version, where to report issues, etc. This is different from the physical location (URL, disk drive, or server) of the document, which is the technical location of the document, which host may be delegated to the management of some other organization.
John Moehrke (Jul 24 2017 at 18:39):
I submitted that as GF#13686
Jeffrey Willis (Jul 25 2017 at 13:58):
Thank you!
Last updated: Apr 12 2022 at 19:14 UTC
