what should be in the SHR ? ... XDS ?

I would like to hear about what XDS is doing!

(PS, Ryan, your summary sounds about right.)

On Behalf Of Ryan

···

Thanks Derek, we will definitely chat with Justin about this as I’m sure he will have some keen insight.

What would be the best way for us to follow along and see what others have done to solve this in the IHE community? It would be interesting for us to know the outcomes and lesson learnt so far.

I think we came to a fair understanding of where we sit on the core concepts of this topic on yesterday’s call. What I heard was we want to store 3 in three ways; store discrete clinical observations; store document based data containing
pure text, images or other blob data; and store relations between discrete and document based data for case such as discrete annotations along side of a radiology image for example. Have I captured this all correctly?

Cheers,

Ryan

On Mon, Apr 22, 2013 at 2:38 PM, Derek Ritz (ecGroup) derek.ritz@ecgroupinc.com wrote:

Hi all.

Excellent threads! We’re really unpacking this issue; nicely done, everyone.

Based on some input from last week, I would like us to consider doing a deep dive regarding how
the “discrete plus document” idea may be supported using the CDA/XDS combination. It is especially opportune for us to explore this while Justin is in Cape Town.

I had some very interesting conversations on this topic “in the coffee line-up” last week at the
IHE Summit meeting. There is, it turns out, a very broad international community working on this exact problem and we have a lot to give/gain by participating alongside them. France, Italy, Switzerland and various US HIEs are all in the process of figuring
this out using various bits of IHE technology stack. There is a wealth of “lessons learned” emerging from these initiatives.

As a side note – our very own Justin and Duane (from Mohawk) were co-leads on the technical program
at this Summit so we definitely have an opportunity to run the inside track on this one. :wink:

Warmest regards,

DJ


**Derek Ritz,**P.Eng., CPHIMS-CA

ecGroup Inc.

+1 (905) 515-0045

www.ecgroupinc.com

This communication is intended only for the party to whom it is addressed, and may contain
information which is privileged or confidential. Any other delivery, distribution, copying or disclosure is strictly prohibited and is not a waiver of privilege or confidentiality. If you have received this telecommunication in error, please notify the sender
immediately by return electronic mail and destroy the message and any attachments.


Le présent courriel et les documents qui y sont joints sont confidentiels et protégés et s’adressent exclusivement au destinataire mentionné ci-dessus. L’expéditeur ne
renonce pas aux droits et privilèges qui s’y rapportent ni à leur caractère confidentiel. Toute prise de connaissance, diffusion, utilisation ou reproduction de ce message ou des documents qui y sont joints, ainsi que des renseignements que chacun contient,
par une personne autre que le destinataire prévu est interdite. Si vous recevez ce courriel par erreur, veuillez le détruire immédiatement et m’en informer.

From:
openhie-shr@googlegroups.com [mailto:openhie-shr@googlegroups.com]
On Behalf Of Ryan
Sent: April 22, 2013 5:35 AM
To: Suranga Kasthurirathne
Cc: Kari Schoonbee; Tucker, Mark; openhie-shr
Subject: Re: what should be in the SHR ?

Hi Suranga,

This is likely for the future SHR implementation, yes.

Ryan

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. ?

On Mon, Apr 22, 2013 at 2:55 PM, Ryan ryan@jembi.org wrote:

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.

Ryan

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?

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

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](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*

--

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](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*

--

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](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*

--

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](https://groups.google.com/groups/opt_out).
 

--
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](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*

</details>