Dear All,
How may countries impment OpenHIE and how does OpenHIE important for EMR?
Sambath
Cambodia
On Monday, July 15, 2013 at 7:45:27 PM UTC+7, Ryan Crichton wrote:Hi OpenHIE architecture group,I'd like to kick off some fundamental discussion about the direction of OpenHIE. It has become apparent in the Interoperability Layer group that it would be useful to have a common understanding of what we are aiming to support with OpenHIE as a whole.I believe that a lot of context and influence has been transparently carried over from the Rwandan health information exchange project. I think that it is worth us explicitly stating our goals and objectives as largely we haven't spoken of this before and a lot of us are assuming that we are aiming toward goal similar to the Rwandan project but we haven't explicitly stated this.There are a few fundamental questions that I feel we should discuss and express concretely within OpenHIE:
- What are the overall use cases that we expect to support with OpenHIE? What are the cross-cutting interaction where we anticipate co-operation between the different registries?
- What are the common architectural patterns that we wish to follow?
- Is there a common "stack of standards" that we wish to adopt primarily to easy co-ordination between registries?
From the Rwandan project I have some assumptions about each of these. Below, I will share my thoughts on each of these and I'd be very interested to see if other agree or not with my understanding. Hopefully from these discussions we can put together some documentation about our overall direction for OpenHIE.My thoughts on 1My assumption is that we are closely following the Rwandan HIE use cases for OpenHIE. To me that mean that we are looking to support the following use cases in a complete implementation of OpenHIE (all registries, all components). When I say use case I mean the functions that a client systems at the point of care can expect the OpenHIE implementation to perform.
- The storage and retrieval of structured clinical encounters for a patient
- (This involves the querying of facility, provider and terminology data to ensure that the data is valid)
- The storage and retrieval of unstructured (document-based) information for a patient
- (This involves the querying of facility, provider and terminology data to ensure that the metadata around the document is valid)
- The storage and retrieval of patient demographic information
- The querying of information about health facilities
- The querying of information about health providers
- The listing, querying and mapping of clinical terminology
As can be seen here the only use cases that require interaction between the different registries (orchestration) are the storage and retrieval of clinical information.Are these the major use cases that we as the OpenHIE community want to see supported for the first revision?My thoughts on 2My assumptions on architectural patterns are as follows:
- We are embracing a SOA approach to the overall OpenHIE architecture where each of the registries are seen as a service.
- We are generally making use of web services to communicate between services with a focus on the newer REST architectural style but still using SOAP based standards where needed.
- We are using an 'interoperability layer' component to manage all communication between the registries as well as all communication between clients and the overall HIE. This component handles security, logging and auditing globally and can perform transformation and orchestration functions if needed. It acts as an ESB-like component for the SOA.
Do these assumption resonate with others?My thoughts on 3Here I don't believe that we have very good consensus. In places we are creating custom standard to suit our needs, in other places we are using existing standards that we have profiled particularly for our use and in other places we are using existing profiles (such as IHE profiles) to enable communication between systems.Should we look to harmonize much of these efforts to be consistent or accept the fact that a mish-mash of multiple standards will give us what we need? Under the Rwandan HIE we made use of HL7 v2 for all interfaces used by external systems but inside the HIE we used a combination of custom formats and profiled standards.ConclusionI'd love to hear other thoughts on each of these and perhaps we can tackle each one in more detail. I think it would be great if we could write some of this down concretely so that each of the communities can work towards an overall goal within OpenHIE. Please let me know what you think, these are only my assumptions and they are probably wrong and don't reflect everyone's feelings. Does anyone have some additional points that we need to consider to help guide the direction we all take with OpenHIE?Apologies for the lengthy email :)Cheers,Ryan--Ryan Crichton
Software Developer, Jembi Health Systems | SOUTH AFRICAMobile: +27845829934 | Skype: ryan.graham.crichton
E-mail: ry...@jembi.org
For more options, visit https://groups.google.com/d/optout.--
You received this message because you are subscribed to the Google Groups "OpenHIE Architecture" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ohie-architecture+unsubscribe@googlegroups.com.
--
You received this message because you are subscribed to the Google Groups "OpenHIE Implementers Network (OHIN)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ohie-implementers+unsubscribe@googlegroups.com.
To post to this group, send email to ohie-implementers@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ohie-implementers/CAFNRjWi2%2BQLmeO7W0OM79PFEVcoX8_e%3D%2B6e9K9SUmO5rtB0hKw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Alvin – this approach usefully de-couples OpenHIE’s two key “products” from each other:
1. Product #1 is a community of practice supporting an architectural specification and standards stack that operationalizes a growing family health-related workflows.
2. Product #2 is a community of practice and a growing family of interchangeable software products that provide a reference implementation of Product #1.
The OpenHIE Implementer’s Network is focused on country-specific implementations of product #1 that may (or may not) employ software solutions from the community represented in product #2. Importantly, REACH can play a role in guiding adherence to the architectural blueprint whether or not the software solutions are from the OpenHIE reference technology stack. That is a really important service!
I hope, also, that the REACH team will actively contribute to OpenHIE’s evolving architectural design. We need to hear those MOH voices; we need OpenHIE to be usefully addressing the real needs on the ground. :-)
Derek Ritz, P.Eng., CPHIMS-CA
ecGroup Inc.
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.
1. What are the overall use cases that we expect to support with OpenHIE? What are the cross-cutting interaction where we anticipate co-operation between the different registries?
2. What are the common architectural patterns that we wish to follow?
3. Is there a common "stack of standards" that we wish to adopt primarily to easy co-ordination between registries?
From the Rwandan project I have some assumptions about each of these. Below, I will share my thoughts on each of these and I'd be very interested to see if other agree or not with my understanding. Hopefully from these discussions we can put together some documentation about our overall direction for OpenHIE.
My thoughts on 1
My assumption is that we are closely following the Rwandan HIE use cases for OpenHIE. To me that mean that we are looking to support the following use cases in a complete implementation of OpenHIE (all registries, all components). When I say use case I mean the functions that a client systems at the point of care can expect the OpenHIE implementation to perform.
· The storage and retrieval of structured clinical encounters for a patient
o (This involves the querying of facility, provider and terminology data to ensure that the data is valid)
· The storage and retrieval of unstructured (document-based) information for a patient
o (This involves the querying of facility, provider and terminology data to ensure that the metadata around the document is valid)
To unsubscribe from this group and stop receiving emails from it, send an email to ohie-architect...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "OpenHIE Implementers Network (OHIN)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ohie-implement...@googlegroups.com.
To post to this group, send email to ohie-imp...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ohie-implementers/CAFNRjWi2%2BQLmeO7W0OM79PFEVcoX8_e%3D%2B6e9K9SUmO5rtB0hKw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "OpenHIE Implementers Network (OHIN)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ohie-implement...@googlegroups.com.
To post to this group, send email to ohie-imp...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ohie-implementers/CAHL8W3z%3DuJrCdK64rUxW-k70eTd93%2B04XtkpdP3kjgWvFoTj3A%40mail.gmail.com.
Dear All,First thanks for all responses—very interesting and useful. Second, I would like to know more when OpenHIE start (first country)—and so far any documentation on the OpenHIE implementation at each country. Any best way that each country can connect to OpenHIE community—One model is through AeHIN for Asia country……To get MoH voice as Derek mention, we may need to have clear guidance and what are benefits of using OpenHIE and how MoH handle it if no support from partners?ThanksSambathCambodia
To unsubscribe from this group and stop receiving emails from it, send an email to ohie-architecture+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "OpenHIE Implementers Network (OHIN)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ohie-implementers+unsubscribe@googlegroups.com.
To post to this group, send email to ohie-implementers@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ohie-implementers/CAFNRjWi2%2BQLmeO7W0OM79PFEVcoX8_e%3D%2B6e9K9SUmO5rtB0hKw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "OpenHIE Implementers Network (OHIN)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ohie-implementers+unsubscribe@googlegroups.com.
To post to this group, send email to ohie-implementers@googlegroups.com.