Yes, to me that makes sense. We will need some metadata around what sort of data is actually stored so clients know how to present it but I think these sort of thing are covered in the standards such as XDS.b if we choose to use that or we can just borrow the ideas presented in those standards.
There will also need to be some links to show how discrete data relates to ‘document blobs’. Basically just a way to say that certain discrete data is tied to a document.
···
On Mon, Apr 22, 2013 at 11:46 AM, Hannes Venter hannes@jembi.org wrote:
So to ask this explicitely: when we’re talking about storing “documents” (vs discrete),
we’re actually talking about storing “blobs”?
The idea being what you put in, is what you get out, whatever it is.
In which case we can store anything: images, audio, xml docs, whatever, the SHR’s not supposed to care…
(I believe this is inline with the previous suggestions.
It also fits in nicely with something like XDS, which isn’t about the “what”, but rather the “piping” for transport).
–
Ryan Crichton
Senior Software Developer, Jembi Health Systems | SOUTH AFRICA
Mobile: +27845829934 | Skype: ryan.graham.crichton
E-mail: ryan@jembi.org
On Mon, Apr 22, 2013 at 11:34 AM, Ryan ryan@jembi.org wrote:
Hi Suranga,
This is likely for the future SHR implementation, yes.
Ryan
–
You received this message because you are subscribed to the Google Groups “Shared Health Record (OpenHIE)” group.
To unsubscribe from this group and stop receiving emails from it, send an email to openhie-shr+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
–
Software Developer, Jembi Health Systems | SOUTH AFRICA
Hannes VenterMobile: +27 73 276 2848 | Office: +27 21 701 0939 | Skype: venter.johannes
E-mail: hannes@jembi.org
On Mon, Apr 22, 2013 at 11:28 AM, Suranga Kasthurirathne suranga@jembi.org wrote:
Hmm… when we say ‘images’, do we also cover DICOM images, and records used for Radiology etc. ?
–
Ryan Crichton
Senior Software Developer, Jembi Health Systems | SOUTH AFRICA
Mobile: +27845829934 | Skype: ryan.graham.crichton
E-mail: ryan@jembi.org
On Mon, Apr 22, 2013 at 2:55 PM, Ryan ryan@jembi.org wrote:
Ryan
Yes, I think we could. I wouldn’t list this is a priority for now, but it should be considered for the SHR for future use cases.
–
You received this message because you are subscribed to the Google Groups “Shared Health Record (OpenHIE)” group.
To unsubscribe from this group and stop receiving emails from it, send an email to openhie-shr+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
On Mon, Apr 22, 2013 at 11:23 AM, Kari Schoonbee kari@jembi.org wrote:
I think we can extend “Documents” to audio and video too?
–
Ryan Crichton
Senior Software Developer, Jembi Health Systems | SOUTH AFRICA
Mobile: +27845829934 | Skype: ryan.graham.crichton
E-mail: ryan@jembi.org
On Mon, Apr 22, 2013 at 11:10 AM, Ryan ryan@jembi.org wrote:
Hi Mark,
Thanks for the response. Some responses inline:
> We seemed to agreed on one conference call that the overall
> record needs to contain three shapes of clinical data [a] Discrete results (clumped by battery)
> [b] Full Text ascii documents (Human readable, machine parsable)
> [c] Full Fidelity pretty documents & Images (Human readable
> PDF renderings, particularly of tables and diagrams.
>
>
>
>
>
>
>
> Key frame images and snapshots)
> [d] .. and the combination of a full text document(#b),
> with a supplmental pretty rendering(#c),
and also some discrete data (#a) tagged on.
I agree with this. So basically we should commit to storing the following:
- Discrete observational data.
- Documents, in both textual, image or pdf form.
- A combination of discrete data with an document attachment.
Do other agree this captures our thoughts correctly?
[[ “Should” … according to whom? ]]
…
To take advantage of the opportunity to prescribe codes, I think
of the problem as:
What data must people send ?
What data should people send ?
What data may people send ?
I agree with your split, in essence the SHR must be able to store the information that the MoH sees as beneficial for public health reporting. So firstly data that is important for reporting must be sent and as well as data for everyday patient care. These two are essential.
I would envision data that should be collected as information that is being collected routinely at the edge systems. Such as data on forms and data that is currently captured in their systems.
I like your notion that systems may send any information that they have and it should be able to be stored as long as it conforms to the different ‘shapes’ of data that we support. This is something that I think is important, we shouldn’t be throwing away any data. It should be stored within the infrastructure even if it is not fully supported as it may be useful for future use or reporting purposes. One key element of the current buzz word, ‘big data’, is that you store everything you receive as all information received may have value even if it cannot be extracted currently. This may be something important to consider within the architecture.
> [[ What about Codes? ]]
> ...
Agreed, the MoH should be able to decide the codes that are supported. What this means for the SHR is it should be able to import and map to coding systems in a general way. Perhaps a pull for a terminology service to obtain these codes or keep them updated is something the SHR should be responsible for. What do others think of this? Perhaps this is a feature we should add in the SHR use cases.
Thanks Mark for you thoughts!
Cheers,
Ryan
–
You received this message because you are subscribed to the Google Groups “Shared Health Record (OpenHIE)” group.
To unsubscribe from this group and stop receiving emails from it, send an email to openhie-shr+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
On Fri, Apr 19, 2013 at 10:11 PM, Tucker, Mark mtucker2@regenstrief.org wrote:
See attached.
Mark Tucker
Systems Engineer
Regenstrief Institute
(317)423-5552
mtucker2@regenstrief.org
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.
To unsubscribe from this group and stop receiving emails from it, send an email to openhie-shr+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Ryan Crichton
Senior Software Developer, Jembi Health Systems | SOUTH AFRICA
–
Mobile: +27845829934 | Skype: ryan.graham.crichton
E-mail: ryan@jembi.org
