I imagine that the main SHR database stores traditional text documents (ie, radiology reports) “inline with discrete data.”
That is, the SHR uses its own CLOBSs and large text fields with the SQL database to store transcribed documents.
But, I imagine that the Central Node will/may have a PACS system (using DICOM) that is accessible if we go down that route.
And, if you decide to store the odd Video, then I imagine that the Central node has a huge DISK FARM that can store images until the cows come home. The main SHR would just store some sort of URL/POINTER/IndirectionHandle, and would itself
not have to stress itself with giant content objects.
···
I like to imagine an implementation because it gives me the feel of the performance envelope of what is easy and what is hard.
If we choose a very simple implementation, and it seems to have sufficient performance, then I won’t be scared of the problem.
Confidentiality Notice: The contents of this message and any files transmitted with it may contain confidential and/or privileged information and are intended
solely for the use of the named addressee(s). Additionally, the information contained herein may have been disclosed to you from medical records with confidentiality protected by federal and state laws. Federal regulations and State laws prohibit you from
making further disclosure of such information without the specific written consent of the person to whom the information pertains or as otherwise permitted by such regulations. A general authorization for the release of medical or other information is not
sufficient for this purpose.
If you have received this message in error, please notify the sender by return e-mail and delete the original message. Any retention, disclosure, copying, distribution or use of this information by anyone other than the intended recipient is strictly prohibited
I think what you are getting at here is that the SHR should be simple a store for a patient clinical information. It should not worry about storing of additional or more complex data such as video or massive DICOM images. I am in agreement with this. I think we can imagine a future state where we will have additional services to handle tasks such as storing radiology images or for handling other information domains such as billing, prescriptions or labs. These services could then be accessed by the central mediator component to fetch information for a specific patient across those multiple services.
This is a key concept of a service-oriented architecture. Services should be simple and independent if you deal with differing concerns.
I imagine that the main SHR database stores traditional text documents (ie, radiology reports) “inline with discrete data.”
That is, the SHR uses its own CLOBSs and large text fields with the SQL database to store transcribed documents.
But, I imagine that the Central Node will/may have a PACS system (using DICOM) that is accessible if we go down that route.
And, if you decide to store the odd Video, then I imagine that the Central node has a huge DISK FARM that can store images until the cows come home. The main SHR would just store some sort of URL/POINTER/IndirectionHandle, and would itself
not have to stress itself with giant content objects.
I like to imagine an implementation because it gives me the feel of the performance envelope of what is easy and what is hard.
If we choose a very simple implementation, and it seems to have sufficient performance, then I won’t be scared of the problem.
Confidentiality Notice: The contents of this message and any files transmitted with it may contain confidential and/or privileged information and are intended
solely for the use of the named addressee(s). Additionally, the information contained herein may have been disclosed to you from medical records with confidentiality protected by federal and state laws. Federal regulations and State laws prohibit you from
making further disclosure of such information without the specific written consent of the person to whom the information pertains or as otherwise permitted by such regulations. A general authorization for the release of medical or other information is not
sufficient for this purpose.
If you have received this message in error, please notify the sender by return e-mail and delete the original message. Any retention, disclosure, copying, distribution or use of this information by anyone other than the intended recipient is strictly prohibited
–
You received this message because you are subscribed to the Google Groups “Shared Health Record (OpenHIE)” group.