I think what we are really interested in at this stage are profiles that handle the sending and receiving of a patient encounter. For client information it seem like PIX/PDQ is the defacto standard so I don’t think we need to look into that. Also, the provider registry team is looking into standards for querying provider information. So, lets focus just on encounters for now.
I also get the understanding that IHE profile will tend to be very specific as you say (eg. lab order, maternal summary etc.) so it would be useful to see what are out there that would suit the RHEA use can and take a cursory look at what the general standards are in this space for other use cases (eg, HIV, TB etc). Then we can get an idea if there what sort of standard we would need to support for these profiles.
Thanks Mead, you help will be greatly appreciated! Could you post any progress or finding to the OpenSHR google group: openhie-shr@googlegroups.com so other can comment to.
Thanks,
Ryan
···
On Mon, Feb 25, 2013 at 11:51 PM, Mead Walker dmead@comcast.net wrote:
Hi,
I offered to look up what IHE had to offer to support Open HIE interoperability. I said I would look at what it had for HL7 V2 and for HL7 CDA. It has taken me a while to get around to this, but I am starting now.
But, what do we need? That is still undefined. It seems reasonable to start with what we did for Rwanda.
Here is a list of the transactions we created, or talked about creating – or what I think the list is:
· Query for client/client information response
· Transmit client information
· Query for patient encounter/response
· Query for patient history (multiple encounters)/response
· Transmit patient encounter
· Query for provider/provider information response
· Transmit provider information
Can you think of things to be added?
Note, the key here is to communication the content of the patient’s record. (There will be more stuff in the future, but I think this is the central area for now.) What we are going to find is that HL7 – and consequently IHE – tends to break things down much more finely, e.g., lab order, patient admission, etc.
Mead
–
Ryan Crichton
Senior Software Developer, Jembi Health Systems | SOUTH AFRICA
The most common way an encounter is communicated in environments I’ve worked within is a standard HL7 v2 ORU^R01. This can easily be wrapped in XDS. In fact the original XDS specification used HL7 v2.3.1 as it’s primary example.
The other less common formats I’ve seen inside XDS include CDA v1 and v2. There’s also a European standard called CEN EN13606 that I’ve had limited experience with but seemed to fall upon the weight of itself due to it’s complexity.
The main problem I’ve always had with XDS is the tacit presumption that data is always stored as “documents”, when in reality, there are data best stored as documents, there are data best stored discretely, and there are data that might be stored as both. As long as we start with a presumption that our SHR will have options for storage of both document-based and discrete data, we’ll be fine IMO.
-Paul
···
On Mon, Feb 25, 2013 at 11:51 PM, Mead Walker dmead@comcast.net wrote:
Hi,
I offered to look up what IHE had to offer to support Open HIE interoperability. I said I would look at what it had for HL7 V2 and for HL7 CDA. It has taken me a while to get around to this, but I am starting now.
But, what do we need? That is still undefined. It seems reasonable to start with what we did for Rwanda.
Here is a list of the transactions we created, or talked about creating – or what I think the list is:
· Query for client/client information response
· Transmit client information
· Query for patient encounter/response
· Query for patient history (multiple encounters)/response
· Transmit patient encounter
· Query for provider/provider information response
· Transmit provider information
Can you think of things to be added?
Note, the key here is to communication the content of the patient’s record. (There will be more stuff in the future, but I think this is the central area for now.) What we are going to find is that HL7 – and consequently IHE – tends to break things down much more finely, e.g., lab order, patient admission, etc.
Mead
Ryan Crichton
Senior Software Developer, Jembi Health Systems | SOUTH AFRICA
Thanks for the additions Paul. It seems to us that XDS has got a lot of traction for the handling of documents. However, just as you note some data isn’t always best represented as documents but rather discretely. You are right that it is possible to include HL7 in an XDS but it occurs to us (and Justin mentioned something similar) that XDS isn’t really designed for transmitting messages and there are some problem with treating messages as documents.
So it seems that XDS is a good choice document based data but not for discrete data. So what we are trying to do here is explore some standard methods of transmitting discrete data. I agree CDA seems like a good option. We are hoping to explore some more specific profiles to see if they can suit our use case and perhaps even specify CDA or other standards more clearly.
The most common way an encounter is communicated in environments I’ve worked within is a standard HL7 v2 ORU^R01. This can easily be wrapped in XDS. In fact the original XDS specification used HL7 v2.3.1 as it’s primary example.
The other less common formats I’ve seen inside XDS include CDA v1 and v2. There’s also a European standard called CEN EN13606 that I’ve had limited experience with but seemed to fall upon the weight of itself due to it’s complexity.
The main problem I’ve always had with XDS is the tacit presumption that data is always stored as “documents”, when in reality, there are data best stored as documents, there are data best stored discretely, and there are data that might be stored as both. As long as we start with a presumption that our SHR will have options for storage of both document-based and discrete data, we’ll be fine IMO.
-Paul
On Tue, Feb 26, 2013 at 2:05 AM, Ryan ryan@jembi.org wrote:
Hi Mead,
I think what we are really interested in at this stage are profiles that handle the sending and receiving of a patient encounter. For client information it seem like PIX/PDQ is the defacto standard so I don’t think we need to look into that. Also, the provider registry team is looking into standards for querying provider information. So, lets focus just on encounters for now.
I also get the understanding that IHE profile will tend to be very specific as you say (eg. lab order, maternal summary etc.) so it would be useful to see what are out there that would suit the RHEA use can and take a cursory look at what the general standards are in this space for other use cases (eg, HIV, TB etc). Then we can get an idea if there what sort of standard we would need to support for these profiles.
Thanks Mead, you help will be greatly appreciated! Could you post any progress or finding to the OpenSHR google group: openhie-shr@googlegroups.com so other can comment to.
Thanks,
Ryan
–
You received this message because you are subscribed to the Google Groups “Shared Health Record (OpenHIE)” group.
On Mon, Feb 25, 2013 at 11:51 PM, Mead Walker dmead@comcast.net wrote:
Hi,
I offered to look up what IHE had to offer to support Open HIE interoperability. I said I would look at what it had for HL7 V2 and for HL7 CDA. It has taken me a while to get around to this, but I am starting now.
But, what do we need? That is still undefined. It seems reasonable to start with what we did for Rwanda.
Here is a list of the transactions we created, or talked about creating – or what I think the list is:
· Query for client/client information response
· Transmit client information
· Query for patient encounter/response
· Query for patient history (multiple encounters)/response
· Transmit patient encounter
· Query for provider/provider information response
· Transmit provider information
Can you think of things to be added?
Note, the key here is to communication the content of the patient’s record. (There will be more stuff in the future, but I think this is the central area for now.) What we are going to find is that HL7 – and consequently IHE – tends to break things down much more finely, e.g., lab order, patient admission, etc.
Mead
Ryan Crichton
Senior Software Developer, Jembi Health Systems | SOUTH AFRICA
