Defining our direction for OpenHIE

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:

  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
  • (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 2

My 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 3

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

Conclusion

I’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 :slight_smile:

Cheers,

Ryan

···


Ryan Crichton

Software Developer, Jembi Health Systems | SOUTH AFRICA

Mobile: +27845829934 | Skype: ryan.graham.crichton
E-mail: ryan@jembi.org

Thanks Ryan!
Exciting to see this move forward.

Two things I'd like to suggest at this stage is to take a cue from enterprise integration patterns and plan out the 'capability map' of the HIX even if there aren't services to fill all the spaces yet; and to look at SOA approaches for all crosscutting services in line with trends in enterprise integration --- this should all allow a simpler evaluation and gradual, needs-driven adoption of ohie. This would also allow Ohie to be a true 'suite' of independent services, with a clear role in the national HIS, and working together as a system based on standards.

For example, some pragmatic suggestions on topics to see addressed;

	- Having an acknowledged and purposefully architected link between OLTP services and DSS systems - e.g. how does DHIS (as one example of a DSS system) aggregate dimension information (e.g. facilities, providers) or measure information (e.g. reported maternal deaths).

	- Enabling AuthN,Audit and AuthZ standards to allow crosscutting identity management across OpenHIE. Actually Dykki & Paul may remember me nagging them about this 3+ years ago.  Having the ESB also 'be' the authentication authority is a coupling hopefully to be avoided.

	- Deciding on which standards to use by which services expose events back to the ESB; in order to allow them to trigger complex business logic based on intrinsic state changes (e.g. Provider Registry confirms someone quit, what needs to happen in other services?). We were discussing with Chris Ford and thoughtworks guys what to converge on as it's a pattern we've seen really helpful in SOA environments.

	- Having the ESB in the architecture gives an additional tool for complex & long-running transaction control; but it does not need to be the 'gateway' to every and all services in the HIS. It is useful for complex/long running transactions that are 'requesting' changes in services and pushing transactions into the HIS; and for transactions that are triggered by such services. With good authn/authz/audit services, countries can reap the benefits of each piece as they see fit and incrementally expand into having logic in the ESB as needed.

These are just some examples of things worth discussing and directions worth evaluating in my opinion

~ ej

···

Jul 15, 2013, at 5:45 AM, Ryan Crichton ryan@jembi.org 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:

  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
  • (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 2

My 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 3

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

Conclusion

I’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 :slight_smile:

Cheers,

Ryan


Ryan Crichton

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 “OpenHIE Architecture” group.

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/groups/opt_out.

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:

  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
  • (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 2

My 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 3

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

Conclusion

I’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 :slight_smile:

Cheers,

Ryan


Ryan Crichton

Software Developer, Jembi Health Systems | SOUTH AFRICA

Mobile: +27845829934 | Skype: ryan.graham.crichton
E-mail: ryan@jembi.org

Good Day Sambath

Thank you for your question. I’ve posted it to the OpenHIE Implementers network mailing list too (would suggest that you join that if you haven’t already https://wiki.ohie.org/display/SUB/OpenHIE+Implementers).

There are a few implementations of various configurations of the OpenHIE architecture and we are still coallating as much information as we have. At this stage I can say that there are OHIE based soluions in the following countries that I’m aware of (at either national or project level):

  • South Africa

  • Rwanda

  • Tanzania

  • Zimbabwe

  • Liberia (mHero)

  • Bangladesh

(happy for others to add more).

An HIE (such as OpenHIE) is one way of allowing data to be exchanged within a region/country and is a strong move towards a single patient record. The ability to share information and understand it in a standard way is valuable when there are different information systems trying to read and add to the same data repository. I personally think an HIE is a valuable tool, but it does depend on the circumstances as to how you would want to implement it.

···

On Tue, Jan 10, 2017 at 4:43 AM, Reatanaksambath Mean reatanaksambath@gmail.com wrote:

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:

  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
  • (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 2

My 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 3

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

Conclusion

I’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 :slight_smile:

Cheers,

Ryan


Ryan Crichton

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 “OpenHIE Architecture” group.

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.

Regards
Carl Fourie

Senior Program Manager | Digital Health Division

Jembi Health Systems | SOUTH AFRICA
Mobile: +27 71 540 4477 | Office: +27 21 701 0939 | Skype: carl.fourie17
E-mail: carl.fourie@jembi.org

Physical Address: Unit 3B, 5A-C, Tokai on Main, Main Road, Tokai, Cape Town, South Africa (Map Link)

Email Disclaimer:

This e-mail contains proprietary and confidential information some or all of which may be legally privileged. It is for the intended recipient only. If an addressing or transmission error has misdirected this e-mail, please notify the author by replying to this e-mail and then deleting same. If you are not the intended recipient you must not use, disclose, distribute, copy, print or rely on this e-mail. Jembi Health Systems NPO, its subsidiaries and associated companies is not liable for the security of information sent by e-mail and accepts no liability of whatsoever nature for any loss, damage or expense resulting, directly or indirectly, from the access of this e-mail or any attachments hereto.

Thank a lot , Carl it is very interesting info

Dr Mean Reatanak Sambath

Tel: 855 12 727919

···

On Tue, Jan 10, 2017 at 4:43 AM, Reatanaksambath Mean reatanaksambath@gmail.com wrote:

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:

  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
  • (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 2

My 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 3

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

Conclusion

I’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 :slight_smile:

Cheers,

Ryan


Ryan Crichton

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 “OpenHIE Architecture” group.

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.

Regards
Carl Fourie

Senior Program Manager | Digital Health Division

Jembi Health Systems | SOUTH AFRICA
Mobile: +27 71 540 4477 | Office: +27 21 701 0939 | Skype: carl.fourie17
E-mail: carl.fourie@jembi.org

Physical Address: Unit 3B, 5A-C, Tokai on Main, Main Road, Tokai, Cape Town, South Africa (Map Link)

Email Disclaimer:

This e-mail contains proprietary and confidential information some or all of which may be legally privileged. It is for the intended recipient only. If an addressing or transmission error has misdirected this e-mail, please notify the author by replying to this e-mail and then deleting same. If you are not the intended recipient you must not use, disclose, distribute, copy, print or rely on this e-mail. Jembi Health Systems NPO, its subsidiaries and associated companies is not liable for the security of information sent by e-mail and accepts no liability of whatsoever nature for any loss, damage or expense resulting, directly or indirectly, from the access of this e-mail or any attachments hereto.

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. :slight_smile:

Derek Ritz, P.Eng., CPHIMS-CA

ecGroup Inc.

+1 (905) 515-0045

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.

···

From: ohie-implementers@googlegroups.com [mailto:ohie-implementers@googlegroups.com] On Behalf Of Alvin Marcelo
Sent: Wednesday, January 11, 2017 8:58 AM
To: Carl Fourie
Cc: Reatanaksambath Mean; OpenHIE Implementers Network (OHIN); OpenHIE Architecture
Subject: Re: [ohie-implementers] Re: Defining our direction for OpenHIE

Thanks Carl –

We’ve taken a different but related approach in AeHIN – Rather than look for implementers (who create solutions artifacts), we developed enterprise architects (who approve/select architectural artifacts). There are now 12 TOGAF certified AeHIN members mostly staff of MOHs (6 countries) and together, practicing TOGAF’s enterprise continuum concept, they agreed to adopt OpenHIE as the draft architecture.

I think this group called Regional Enterprise Architecture Council for Health (REACH) could be the stewards for the OpenHIE architectural artifacts – as they do not have any specific solutions but are responsible to ensure that solutions are architecturally compliant –

On Tue, Jan 10, 2017 at 8:31 PM, Carl Fourie carl@jembi.org wrote:

Good Day Sambath

Thank you for your question. I’ve posted it to the OpenHIE Implementers network mailing list too (would suggest that you join that if you haven’t already https://wiki.ohie.org/display/SUB/OpenHIE+Implementers).

There are a few implementations of various configurations of the OpenHIE architecture and we are still coallating as much information as we have. At this stage I can say that there are OHIE based soluions in the following countries that I’m aware of (at either national or project level):

  • South Africa

  • Rwanda

  • Tanzania

  • Zimbabwe

  • Liberia (mHero)

  • Bangladesh

(happy for others to add more).

An HIE (such as OpenHIE) is one way of allowing data to be exchanged within a region/country and is a strong move towards a single patient record. The ability to share information and understand it in a standard way is valuable when there are different information systems trying to read and add to the same data repository. I personally think an HIE is a valuable tool, but it does depend on the circumstances as to how you would want to implement it.

Regards
Carl Fourie

Senior Program Manager | Digital Health Division

Jembi Health Systems | SOUTH AFRICA
Mobile: +27 71 540 4477 | Office: +27 21 701 0939 | Skype: carl.fourie17
E-mail: carl.fourie@jembi.org

Physical Address: Unit 3B, 5A-C, Tokai on Main, Main Road, Tokai, Cape Town, South Africa (Map Link)

Email Disclaimer:

This e-mail contains proprietary and confidential information some or all of which may be legally privileged. It is for the intended recipient only. If an addressing or transmission error has misdirected this e-mail, please notify the author by replying to this e-mail and then deleting same. If you are not the intended recipient you must not use, disclose, distribute, copy, print or rely on this e-mail. Jembi Health Systems NPO, its subsidiaries and associated companies is not liable for the security of information sent by e-mail and accepts no liability of whatsoever nature for any loss, damage or expense resulting, directly or indirectly, from the access of this e-mail or any attachments hereto.

On Tue, Jan 10, 2017 at 4:43 AM, Reatanaksambath Mean reatanaksambath@gmail.com wrote:

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:

  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)

· 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 2

My 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 3

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

Conclusion

I’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 :slight_smile:

Cheers,

Ryan

Ryan Crichton

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 “OpenHIE Architecture” group.
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.

Alvin B. Marcelo www.alvinmarcelo.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/CAHL8W3z%3DuJrCdK64rUxW-k70eTd93%2B04XtkpdP3kjgWvFoTj3A%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. :slight_smile:

Derek Ritz, P.Eng., CPHIMS-CA

ecGroup Inc.

+1 (905) 515-0045

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.

···

Thanks Carl –

We’ve taken a different but related approach in AeHIN – Rather than look for implementers (who create solutions artifacts), we developed enterprise architects (who approve/select architectural artifacts). There are now 12 TOGAF certified AeHIN members mostly staff of MOHs (6 countries) and together, practicing TOGAF’s enterprise continuum concept, they agreed to adopt OpenHIE as the draft architecture.

I think this group called Regional Enterprise Architecture Council for Health (REACH) could be the stewards for the OpenHIE architectural artifacts – as they do not have any specific solutions but are responsible to ensure that solutions are architecturally compliant –

On Tue, Jan 10, 2017 at 8:31 PM, Carl Fourie carl@jembi.org wrote:

Good Day Sambath

Thank you for your question. I’ve posted it to the OpenHIE Implementers network mailing list too (would suggest that you join that if you haven’t already https://wiki.ohie.org/display/SUB/OpenHIE+Implementers).

There are a few implementations of various configurations of the OpenHIE architecture and we are still coallating as much information as we have. At this stage I can say that there are OHIE based soluions in the following countries that I’m aware of (at either national or project level):

  • South Africa

  • Rwanda

  • Tanzania

  • Zimbabwe

  • Liberia (mHero)

  • Bangladesh

(happy for others to add more).

An HIE (such as OpenHIE) is one way of allowing data to be exchanged within a region/country and is a strong move towards a single patient record. The ability to share information and understand it in a standard way is valuable when there are different information systems trying to read and add to the same data repository. I personally think an HIE is a valuable tool, but it does depend on the circumstances as to how you would want to implement it.

Regards
Carl Fourie

Senior Program Manager | Digital Health Division

Jembi Health Systems | SOUTH AFRICA
Mobile: +27 71 540 4477 | Office: +27 21 701 0939 | Skype: carl.fourie17
E-mail: carl.fourie@jembi.org

Physical Address: Unit 3B, 5A-C, Tokai on Main, Main Road, Tokai, Cape Town, South Africa (Map Link)

Email Disclaimer:

This e-mail contains proprietary and confidential information some or all of which may be legally privileged. It is for the intended recipient only. If an addressing or transmission error has misdirected this e-mail, please notify the author by replying to this e-mail and then deleting same. If you are not the intended recipient you must not use, disclose, distribute, copy, print or rely on this e-mail. Jembi Health Systems NPO, its subsidiaries and associated companies is not liable for the security of information sent by e-mail and accepts no liability of whatsoever nature for any loss, damage or expense resulting, directly or indirectly, from the access of this e-mail or any attachments hereto.

On Tue, Jan 10, 2017 at 4:43 AM, Reatanaksambath Mean reatanaksambath@gmail.com wrote:

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:

  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)

· 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 2

My 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 3

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

Conclusion

I’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 :slight_smile:

Cheers,

Ryan

Ryan Crichton

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 “OpenHIE Architecture” group.
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.

Alvin B. Marcelo www.alvinmarcelo.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/CAHL8W3z%3DuJrCdK64rUxW-k70eTd93%2B04XtkpdP3kjgWvFoTj3A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Thanks Carl –

We’ve taken a different but related approach in AeHIN – Rather than look for implementers (who create solutions artifacts), we developed enterprise architects (who approve/select architectural artifacts). There are now 12 TOGAF certified AeHIN members mostly staff of MOHs (6 countries) and together, practicing TOGAF’s enterprise continuum concept, they agreed to adopt OpenHIE as the draft architecture.

I think this group called Regional Enterprise Architecture Council for Health (REACH) could be the stewards for the OpenHIE architectural artifacts – as they do not have any specific solutions but are responsible to ensure that solutions are architecturally compliant –

···

On Tue, Jan 10, 2017 at 8:31 PM, Carl Fourie carl@jembi.org wrote:

Good Day Sambath

Thank you for your question. I’ve posted it to the OpenHIE Implementers network mailing list too (would suggest that you join that if you haven’t already https://wiki.ohie.org/display/SUB/OpenHIE+Implementers).

There are a few implementations of various configurations of the OpenHIE architecture and we are still coallating as much information as we have. At this stage I can say that there are OHIE based soluions in the following countries that I’m aware of (at either national or project level):

  • South Africa
  • Rwanda
  • Tanzania
  • Zimbabwe
  • Liberia (mHero)
  • Bangladesh

(happy for others to add more).

An HIE (such as OpenHIE) is one way of allowing data to be exchanged within a region/country and is a strong move towards a single patient record. The ability to share information and understand it in a standard way is valuable when there are different information systems trying to read and add to the same data repository. I personally think an HIE is a valuable tool, but it does depend on the circumstances as to how you would want to implement it.

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.

Regards
Carl Fourie

Senior Program Manager | Digital Health Division

Jembi Health Systems | SOUTH AFRICA
Mobile: +27 71 540 4477 | Office: +27 21 701 0939 | Skype: carl.fourie17
E-mail: carl.fourie@jembi.org

Physical Address: Unit 3B, 5A-C, Tokai on Main, Main Road, Tokai, Cape Town, South Africa (Map Link)

Email Disclaimer:

This e-mail contains proprietary and confidential information some or all of which may be legally privileged. It is for the intended recipient only. If an addressing or transmission error has misdirected this e-mail, please notify the author by replying to this e-mail and then deleting same. If you are not the intended recipient you must not use, disclose, distribute, copy, print or rely on this e-mail. Jembi Health Systems NPO, its subsidiaries and associated companies is not liable for the security of information sent by e-mail and accepts no liability of whatsoever nature for any loss, damage or expense resulting, directly or indirectly, from the access of this e-mail or any attachments hereto.

On Tue, Jan 10, 2017 at 4:43 AM, Reatanaksambath Mean reatanaksambath@gmail.com wrote:

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:

  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
  • (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 2

My 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 3

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

Conclusion

I’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 :slight_smile:

Cheers,

Ryan


Ryan Crichton

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 “OpenHIE Architecture” group.

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.

Alvin B. Marcelo www.alvinmarcelo.com

Dr Sambath,

Your (Cambodia) resource will be us at the Standards and Interoperability Lab for Asia (SILA). But you can also access INSTEDD and Camlab.

It would be good if MOH could identify a real world problem then MOH can write AeHIN (direct to Dr Boonchai) for help. We already got a request from DOH Philippines. Once we have that request, we’ll start finding solutions for it…

···

On Jan 12, 2017 09:44, “msambath sambath” reatanaksambath@gmail.com wrote:

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?

Thanks

Sambath

Cambodia

From: “Derek Ritz (ecGroup)” derek.ritz@ecgroupinc.com
Date: Wednesday, January 11, 2017 at 10:46 PM
To: admarcelo@up.edu.ph, ‘Carl Fourie’ carl@jembi.org
Cc: msambath sambath reatanaksambath@gmail.com, “‘OpenHIE Implementers Network (OHIN)’” ohie-implementers@googlegroups.com, ‘OpenHIE Architecture’ ohie-architecture@googlegroups.com
Subject: RE: [ohie-implementers] Re: Defining our direction for OpenHIE

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.
    
  1.  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. :slight_smile:

Derek Ritz, P.Eng., CPHIMS-CA

ecGroup Inc.

+1 (905) 515-0045

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.

From: ohie-implementers@googlegroups.com [mailto:ohie-implementers@googlegroups.com] On Behalf Of Alvin Marcelo
Sent: Wednesday, January 11, 2017 8:58 AM
To: Carl Fourie
Cc: Reatanaksambath Mean; OpenHIE Implementers Network (OHIN); OpenHIE Architecture
Subject: Re: [ohie-implementers] Re: Defining our direction for OpenHIE

Thanks Carl –

We’ve taken a different but related approach in AeHIN – Rather than look for implementers (who create solutions artifacts), we developed enterprise architects (who approve/select architectural artifacts). There are now 12 TOGAF certified AeHIN members mostly staff of MOHs (6 countries) and together, practicing TOGAF’s enterprise continuum concept, they agreed to adopt OpenHIE as the draft architecture.

I think this group called Regional Enterprise Architecture Council for Health (REACH) could be the stewards for the OpenHIE architectural artifacts – as they do not have any specific solutions but are responsible to ensure that solutions are architecturally compliant –

On Tue, Jan 10, 2017 at 8:31 PM, Carl Fourie carl@jembi.org wrote:

Good Day Sambath

Thank you for your question. I’ve posted it to the OpenHIE Implementers network mailing list too (would suggest that you join that if you haven’t already https://wiki.ohie.org/display/SUB/OpenHIE+Implementers).

There are a few implementations of various configurations of the OpenHIE architecture and we are still coallating as much information as we have. At this stage I can say that there are OHIE based soluions in the following countries that I’m aware of (at either national or project level):

  • South Africa
  • Rwanda
  • Tanzania
  • Zimbabwe
  • Liberia (mHero)
  • Bangladesh

(happy for others to add more).

An HIE (such as OpenHIE) is one way of allowing data to be exchanged within a region/country and is a strong move towards a single patient record. The ability to share information and understand it in a standard way is valuable when there are different information systems trying to read and add to the same data repository. I personally think an HIE is a valuable tool, but it does depend on the circumstances as to how you would want to implement it.

Regards
Carl Fourie

Senior Program Manager | Digital Health Division

Jembi Health Systems | SOUTH AFRICA
Mobile: +27 71 540 4477 | Office: +27 21 701 0939 | Skype: carl.fourie17
E-mail: carl.fourie@jembi.org

Physical Address: Unit 3B, 5A-C, Tokai on Main, Main Road, Tokai, Cape Town, South Africa (Map Link)

Email Disclaimer:

This e-mail contains proprietary and confidential information some or all of which may be legally privileged. It is for the intended recipient only. If an addressing or transmission error has misdirected this e-mail, please notify the author by replying to this e-mail and then deleting same. If you are not the intended recipient you must not use, disclose, distribute, copy, print or rely on this e-mail. Jembi Health Systems NPO, its subsidiaries and associated companies is not liable for the security of information sent by e-mail and accepts no liability of whatsoever nature for any loss, damage or expense resulting, directly or indirectly, from the access of this e-mail or any attachments hereto.

On Tue, Jan 10, 2017 at 4:43 AM, Reatanaksambath Mean reatanaksambath@gmail.com wrote:

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:

  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?
    
  1.  What are the common architectural patterns that we wish to follow?
    
  1.  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)

· 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 2

My 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 3

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

Conclusion

I’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 :slight_smile:

Cheers,

Ryan

Ryan Crichton

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 “OpenHIE Architecture” group.
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.

Alvin B. Marcelo www.alvinmarcelo.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/CAHL8W3z%3DuJrCdK64rUxW-k70eTd93%2B04XtkpdP3kjgWvFoTj3A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.