Re: OpenHIE--Latency

[msambath sambath]

Dear All,

Does OpenEPMI or OpenHIM is deal with larger medical record data about 4M record? Or more?

Thanks

Sambath

From: Carl Fourie <ca...@jembi.org>
Date: Friday, March 10, 2017 at 2:14 PM
To: msambath sambath <reatana...@gmail.com>
Cc: Ryan Crichton <ry...@jembi.org>, Pierre Dane <pie...@jembi.org>, Tash Sundar <tash....@jembi.org>, Trevor Gowing <trevor...@jembi.org>
Subject: Re: OpenHIE

Good Day Dr Sambath

I have reached out to our team in South Africa and have synthesised the response to the questions below:

1, how OpenHIE overcome latency ? since its contain many path of different app (I very consent about overhead processing) I mean overall delay for response to a request for client. since my team have testing implement OpenHIM with OpenEMPI a simple request ADR_A19 and return two ADR_A19_QUERY_RESPONSE it take about 2.5 s it is very slow.

It is difficult to fully understand without knowing more details but some thoughts around this: The OpenHIM has been performance tested before and only adds about 80ms of overhead on a request under load. A general pattern that we employ to manage any latency is when handling with HTTP requests, we use the asynch file queuing system and our asynchronous http response chaining. This means that the client may get an immediate "200" response, indicating 'request has been received' and the response may be updated to a different status later on within the OpenHIM depending on the results of the mediators and if there are any issues with processing of the message. This strategy works well for systems that use a "fire and forget" approach to sending data in. However if the client depends on a synchronous response, the only way to deal with this is to set a long timeout and wait for the response.

But more to the question on OpenEMPI: the first thing we would need to do is see which system is causing the slow down, do requests directly to OpenEMPI take this long? Or is the OpenHIM causing the delay? There have been some known issues using HL7 v2 messages with the OpenHIM because of the way some systems handle sockets that doesn't fit well with the OpenHIM's request response model. We would be very interested in understanding your experience here

2, if any document about implementation best practic please provide links ?  
Around best implementation practice, there is the data and link to the implementation guide found at: https://ohie.org/client-registry/#implementor and I would also suggest looking at the OpenHIE Client Registry Community pages and calls:
OHIE Client Registry Wiki Home Page: https://wiki.ohie.org/display/SUB/Client+Registry+Community
OHIE Client Registry Wiki Meeting Page: https://wiki.ohie.org/display/resources/Client+Registry+Community+Call

If there are questions that are more about linking tools together and getting setup I would really encourage you and your team to join the OpenHIE Implementers Network where we discuss and answe questions that implementers and team exploring OpenHIE have. The page and joining details are below:

Wiki page: https://wiki.ohie.org/display/SUB/OpenHIE+Implementers
Subscribe: ohie-implemen...@googlegroups.com
Post: ohie-imp...@googlegroups.com

I hope this has been helpful and we would encourage your team to reach out to us on the mailing list and or the team on this email too.

Regards

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....@jembi.org

Physical Address: Unit 3B, 5A-C, Tokai on Main, 382 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 Fri, Mar 10, 2017 at 8:09 AM, Mean R Sambath <reatana...@gmail.com> wrote:

Dr Mean Reatanak Sambath

Executive Director at Partnership for Better Health/Cambodia

Expertise and lecturer on health informatics

Tel: 855 12 727919

Sent from my iPhone 6 plus

Dr Mean Reatanak Sambath

Tel: 855 12 727919

Sent from my iPhone 6 plus

Begin forwarded message:

From: "noty.open.org.kh" <no...@open.org.kh>
Date: March 9, 2017 at 9:38:26 AM GMT+6:30
To: msam...@pbhcam.org
Cc: Roith Hong <hroit...@gmail.com>, Tapley Jordanwood <tjord...@URC-CHS.COM>
Subject: Re: OpenHIE

Dear Dr. sambath

I have two question about OpenHIE.

1, how OpenHIE overcome latency ? since its contain many path of different app (I very consent about overhead processing) I mean overall delay for response to a request for client. since my team have testing implement OpenHIM with OpenEMPI a simple request ADR_A19 and return two ADR_A19_QUERY_RESPONSE it take about 2.5 s it is very slow.

2, if any document about implementation best practic please provide links ? 

Regards,
Sovannoty

---------- Forwarded message ---------
From: MeanSambath PBH <msamba...@gmail.com>
Date: Thu, Mar 9, 2017 at 2:49 AM
Subject: OpenHIE
To: Hong Roith - PBH <hroit...@gmail.com>
Cc: Tapley Jordan <tjord...@urc-chs.com>, Sam Eng <se...@urc-chs.com>, Christophe Grundmann <cgrun...@urc-chs.com>, Mean R Sambath PBH <msam...@pbhcam.org>, Reatanaksambath Mean <reatana...@gmail.com>

Hi Roith,

Greeting from Nai Pyi Taw, Myanmar, 5th AeHIN General meeting, achieving SDGs with ICT

Yesterday, we have a half day session on OpenHIE, and we have OpenHIE folks (about 10 experts) here, more than 100 people talk about OpenHIE and its architecture, and next agenda is about patient master index. Both MoH HIS consultants also here with me. A consultant on standard (Platinir, hired by US CDC/MoH) will use OpenHIE architecture as principle for his document of standard and interoperability for MoH.

Please send me questions if you have any concerns/problems or any thing that you want to check about OpenHIE…..Paul is father/founder of OpenHIE/OpenMRS  is here too (who we met in Rwanda). It will be great if you could share a link that you host OpenHIE? in Myanmar, they used MEDIC CR as client registry—most of concern of using OpenHIE is about GOVERNANCE NOT TECHNOLOGY , experience from country who implement OpenHIE.

OpenHIE will conduct first OpenHIE conference this year In Tanzania 

A brief on OpenHIE

OpenHIE has a set of standard workflows (https://wiki.ohie.org/display/documents/OpenHIE+Workflows) 

OpenHIE Implementers network mailing list  https://wiki.ohie.org/display/SUB/OpenHIE+Implementers). 

OpenHIE = Open Health Information Exchange = One of health information exchange framework which AeHIN adopted. Health Information can be exchanged when systems are interoperable. (ohie.org.) 

OpenHIM = Open Health Information Mediator is an application or a set of applications (a middleware component) (http://openhim.org/) that works at the "Interoperability Layer" of the OpenHIE architecture.

 OpenHIE is architecture. That architecture has 8 components:

 1  - a client registry (think of a database of people where there is one unique number for every person)

2  - a health worker registry (a database where there is one unique number fo every health worker)

3  - a facility registry (a database where there is one unique number for every health facility)

4  - a terminology service (a database of all terms used in the health information system; one unique number for every term AND relationships of these terms to each other)

5  - a health management information system (a special system where you can aggregate health data for purposes of decision-making)

6  - a shared health record (a special database of services rendered to patients) -- this may be similar to the patient's Electronic Health Record

7  - an interoperability layer that connects all of the systems above with the systems below

8  - edge system (any software that connects to the interoperability layer that is not yet mentioned above). It is called edge because it is at the periphery of the architecture (example are electronic medical records running in health facilities)

 

There are open source software for each of the 8 components:

1  OpenEMPI and MEDIC-CR for client registry

2  iHRIS for worker registry

3  Facility Registry for facility registry

4  Apelon for terminology service (container) and SNOMED, ICD10, LOINC (whats inside the container)

5  HMIS (=DHIS2)

6  shared health record = OpenMRS data structure

7  OpenHIM

8  OpenMRS, OpenEMR, GNU Health, CHITS, etc

The AeHIN Interoperability Lab are supposed to connect these 8 components to each other.

Sambath

[Carl Fourie]

Thank you for the questions Sambath

The OpenHIM is built to allow it to scale to the needs of the implementation. The OpenHIM deployment would be designed around the number of requests a second and the expected response times. What I mean by this is there is a big difference with the OpenHIM needing to handle 1 request every 5 seconds versus 500 requests every second etc (@Jembi team (RC, PD etc) any thoughts?). As for OpenEMPI I know that the software has been deployed in the USA as implementations (@Shaun G any thoughts?).

MedicCR is an alternative CR too and the Mohawk team have done some scalling and testing with I believe over 10 million patients. I wonder if they have some insight to share with this.

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....@jembi.org

Physical Address: Unit 3B, 5A-C, Tokai on Main, 382 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 Mon, Mar 13, 2017 at 6:55 AM, msambath sambath <reatana...@gmail.com> wrote:

Dear All,

Does OpenEPMI or OpenHIM is deal with larger medical record data about 4M record? Or more?

Thanks

Sambath

From: Carl Fourie <ca...@jembi.org>
Date: Friday, March 10, 2017 at 2:14 PM
To: msambath sambath <reatana...@gmail.com>
Cc: Ryan Crichton <ry...@jembi.org>, Pierre Dane <pie...@jembi.org>, Tash Sundar <tash....@jembi.org>, Trevor Gowing <trevor...@jembi.org>
Subject: Re: OpenHIE

Good Day Dr Sambath

I have reached out to our team in South Africa and have synthesised the response to the questions below:

1, how OpenHIE overcome latency ? since its contain many path of different app (I very consent about overhead processing) I mean overall delay for response to a request for client. since my team have testing implement OpenHIM with OpenEMPI a simple request ADR_A19 and return two ADR_A19_QUERY_RESPONSE it take about 2.5 s it is very slow.

It is difficult to fully understand without knowing more details but some thoughts around this: The OpenHIM has been performance tested before and only adds about 80ms of overhead on a request under load. A general pattern that we employ to manage any latency is when handling with HTTP requests, we use the asynch file queuing system and our asynchronous http response chaining. This means that the client may get an immediate "200" response, indicating 'request has been received' and the response may be updated to a different status later on within the OpenHIM depending on the results of the mediators and if there are any issues with processing of the message. This strategy works well for systems that use a "fire and forget" approach to sending data in. However if the client depends on a synchronous response, the only way to deal with this is to set a long timeout and wait for the response.

But more to the question on OpenEMPI: the first thing we would need to do is see which system is causing the slow down, do requests directly to OpenEMPI take this long? Or is the OpenHIM causing the delay? There have been some known issues using HL7 v2 messages with the OpenHIM because of the way some systems handle sockets that doesn't fit well with the OpenHIM's request response model. We would be very interested in understanding your experience here

2, if any document about implementation best practic please provide links ?  
Around best implementation practice, there is the data and link to the implementation guide found at: https://ohie.org/client-registry/#implementor and I would also suggest looking at the OpenHIE Client Registry Community pages and calls:
OHIE Client Registry Wiki Home Page: https://wiki.ohie.org/display/SUB/Client+Registry+Community
OHIE Client Registry Wiki Meeting Page: https://wiki.ohie.org/display/resources/Client+Registry+Community+Call

If there are questions that are more about linking tools together and getting setup I would really encourage you and your team to join the OpenHIE Implementers Network where we discuss and answe questions that implementers and team exploring OpenHIE have. The page and joining details are below:

Wiki page: https://wiki.ohie.org/display/SUB/OpenHIE+Implementers
Subscribe: ohie-implementers+subscribe@googlegroups.com
Post: ohie-implementers@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/D4EC31BD.7B24%25reatanaksambath%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Reatanaksambath Mean]

Dear Carl,

Thanks for your reply. What are required functions that a patient database system should have to connect with OpenHIM/OpenEPMI (like PMI, HL7...)? does it work without HL7?

Thanks

Sambath

On Mon, Mar 13, 2017 at 1:54 PM, Carl Fourie <ca...@jembi.org> wrote:

Good Day Sambath

To see all posts to the list please visit: https://groups.google.com/forum/#!forum/ohie-implementers there you can see the history. We'll look to answer you question on the main list so that others outside of Jembi can weigh in too.

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....@jembi.org

Physical Address: Unit 3B, 5A-C, Tokai on Main, 382 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 Mon, Mar 13, 2017 at 7:08 AM, msambath sambath <reatana...@gmail.com> wrote:

Dear All,

Greeting from Cambodia

I posted a question in community as below email—how I can see my post in community—I support to get back an email from the group. By the way, please see my question here

Does OpenEPMI or OpenHIM is deal with larger medical record data about 4M record? Or more?

Our PMRS (PHP/MySQL) linked to OpenEPMI/OpenHIM have about 3M records….

Thanks

Sambath

From: msambath sambath <reatana...@gmail.com>
Date: Monday, March 13, 2017 at 11:25 AM
To: <ohie-implementers@googlegroups.com>
Subject: Re: OpenHIE--Latency

Dear All,

Does OpenEPMI or OpenHIM is deal with larger medical record data about 4M record? Or more?

Thanks

Sambath

From: Carl Fourie <ca...@jembi.org>
Date: Friday, March 10, 2017 at 2:14 PM
To: msambath sambath <reatana...@gmail.com>
Cc: Ryan Crichton <ry...@jembi.org>, Pierre Dane <pie...@jembi.org>, Tash Sundar <tash....@jembi.org>, Trevor Gowing <trevor...@jembi.org>
Subject: Re: OpenHIE

Good Day Dr Sambath

I have reached out to our team in South Africa and have synthesised the response to the questions below:

1, how OpenHIE overcome latency ? since its contain many path of different app (I very consent about overhead processing) I mean overall delay for response to a request for client. since my team have testing implement OpenHIM with OpenEMPI a simple request ADR_A19 and return two ADR_A19_QUERY_RESPONSE it take about 2.5 s it is very slow.

It is difficult to fully understand without knowing more details but some thoughts around this: The OpenHIM has been performance tested before and only adds about 80ms of overhead on a request under load. A general pattern that we employ to manage any latency is when handling with HTTP requests, we use the asynch file queuing system and our asynchronous http response chaining. This means that the client may get an immediate "200" response, indicating 'request has been received' and the response may be updated to a different status later on within the OpenHIM depending on the results of the mediators and if there are any issues with processing of the message. This strategy works well for systems that use a "fire and forget" approach to sending data in. However if the client depends on a synchronous response, the only way to deal with this is to set a long timeout and wait for the response.

But more to the question on OpenEMPI: the first thing we would need to do is see which system is causing the slow down, do requests directly to OpenEMPI take this long? Or is the OpenHIM causing the delay? There have been some known issues using HL7 v2 messages with the OpenHIM because of the way some systems handle sockets that doesn't fit well with the OpenHIM's request response model. We would be very interested in understanding your experience here

2, if any document about implementation best practic please provide links ?  
Around best implementation practice, there is the data and link to the implementation guide found at: https://ohie.org/client-registry/#implementor and I would also suggest looking at the OpenHIE Client Registry Community pages and calls:
OHIE Client Registry Wiki Home Page: https://wiki.ohie.org/display/SUB/Client+Registry+Community
OHIE Client Registry Wiki Meeting Page: https://wiki.ohie.org/display/resources/Client+Registry+Community+Call

If there are questions that are more about linking tools together and getting setup I would really encourage you and your team to join the OpenHIE Implementers Network where we discuss and answe questions that implementers and team exploring OpenHIE have. The page and joining details are below:

Wiki page: https://wiki.ohie.org/display/SUB/OpenHIE+Implementers
Subscribe: ohie-implementers+subscribe@googlegroups.com
Post: ohie-implementers@googlegroups.com

[Carl Fourie]

Hi Sambath

That question has a lot of assumptions to address to give an accurate answer. Some of the assumptions are around the architecture, the choice of standards and profiles and the technologies used etc. For a more architectural design answer I would say:

The patient database system would need to be able to send and recieve information as outlined in the OHIE architecture workflows (assuming OpenHIE architecture) for the particular workflows and use cases that you require. I.e. if there is just patient lookup and registration then only the standards and profiles associated to that; however if adding save and query clinical infomration then there is more about the types of data and how taht is profiled etc. For the highlevel set of workflows please see: https://wiki.ohie.org/display/documents/OpenHIE+Workflows

Now for the technologies you refer to OpenEMPI and OpenHIM (again Jembi team and others jump in to correct and ellaborate): A Patient Database (assuming something that exists at a clinic level and wants to connect and communicate with the HIE at a centra level) would need to be able to be able to play the role of POS in the following workflows:

• https://wiki.ohie.org/display/documents/Create+patient+demographic+record+workflow+-+V1.0
• https://wiki.ohie.org/display/documents/Update+patient+demographic+record+workflow+-+V1.0
• https://wiki.ohie.org/display/documents/Query+patient+demographic+records+by+identifier+workflow+-+V1.0

The OpenHIM allows RESTFUL connections to itself and the Patient Database should be able to connect to a RESTFUL service and manage more than just BASIC AUTH (preferably PKI) and then depending on the communication interfaces from OpenEMPI the Patient Database should be able to generate the correct message for create, update patient and consume the correct messgae from Query. The specs of these as per the OpenHIE architecture are in the links shared.

Again I'll shout out to the CR community to chime in and support (@Shaun G and others)

I hope this is adding value Sambath?

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....@jembi.org

Physical Address: Unit 3B, 5A-C, Tokai on Main, 382 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.

--
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/CACMjOH%3Dzcof5CCJbbhV7icurjFz1Hz4C860Oqr9hq_mUO7AOkw%40mail.gmail.com.

[msambath sambath]

Dear Carl

My team si working on testing Medic CR, does this OHIE community help on MEDIC CR or have other Medic CR forum

[Carl Fourie]

Good morning Sambath

Yes Medic CR is one of the EMPI technologies that is being used as part of OpenHIE. It is curated by the Mohawk team (who are members of this community) and some of hte community have expereinces in working with MEDIC CR too. There is a dedicated community: Client Registry community that is involved in the CR work, refinement and definitions and if you have a team member who is really wanting to get deeply involved in the ins and outs of what constitutes a CR etc then I'd recommend joining the community (details below):

Post: client-...@googlegroups.com
Subscribe: client-regis...@googlegroups.com
Unsubscribe: client-regist...@googlegroups.com

(https://wiki.ohie.org/display/resources/Mailing+Lists)

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....@jembi.org

Physical Address: Unit 3B, 5A-C, Tokai on Main, 382 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.

[Cullen, Theresa]

Carl, thanks for this. We have been thinking of putting together a table of different requirements and having that available to sites so that they can figure out what EMPI technology they may want to use. We can share that with you  if you want ( CDC is commenting on it, as it is for our case based reporting need)..

Thanks again for your help. terry

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/CAFNRjWjpBF4Oxww0_HwLvuQQH9HViEay7VJmq4SuKik5R0q6Ng%40mail.gmail.com.

[msambath sambath]

Dear Terry,

Could you share with me a table of different requirements?

Thanks

Sambath

Email: reatana...@gmail.com

Cambodia

From: "Cullen, Theresa" <thcu...@regenstrief.org>
Date: Friday, April 7, 2017 at 10:57 AM
To: Carl Fourie <ca...@jembi.org>, msambath sambath <reatana...@gmail.com>
Cc: "OpenHIE Implementers Network (OHIN)" <ohie-imp...@googlegroups.com>, Ryan Crichton <ry...@jembi.org>, Pierre Dane <pie...@jembi.org>, Tash Sundar <tash....@jembi.org>, Trevor Gowing <trevor...@jembi.org>, "Fyfe, Justin" <justin...@mohawkcollege.ca>

[Steven Wanyee]

Terry:

Please share that with me too. I'm helping out in Tanzania with thinking through a CR with the primary use case being CBS.

Thanks.

On Friday, April 7, 2017, Cullen, Theresa <thcu...@regenstrief.org> wrote:

Carl, thanks for this. We have been thinking of putting together a table of different requirements and having that available to sites so that they can figure out what EMPI technology they may want to use. We can share that with you  if you want ( CDC is commenting on it, as it is for our case based reporting need)..

Thanks again for your help. terry

From: <ohie-implementers@googlegroups.com> on behalf of Carl Fourie <ca...@jembi.org>
Date: Thursday, March 16, 2017 at 2:11 AM
To: msambath sambath <reatana...@gmail.com>
Cc: "OpenHIE Implementers Network (OHIN)" <ohie-implementers@googlegroups.com>, Ryan Crichton <ry...@jembi.org>, pierre dane <pie...@jembi.org>, Tash Sundar <tash....@jembi.org>, Trevor Gowing <trevor...@jembi.org>, "Fyfe, Justin" <justin...@mohawkcollege.ca>
Subject: Re: [ohie-implementers] Re: FW: OpenHIE--Latency

Good morning Sambath

Yes Medic CR is one of the EMPI technologies that is being used as part of OpenHIE. It is curated by the Mohawk team (who are members of this community) and some of hte community have expereinces in working with MEDIC CR too. There is a dedicated community: Client Registry community that is involved in the CR work, refinement and definitions and if you have a team member who is really wanting to get deeply involved in the ins and outs of what constitutes a CR etc then I'd recommend joining the community (details below):

Post: client-registry@googlegroups.com
Subscribe: client-registry+subscribe@googlegroups.com
Unsubscribe: client-registry+unsubscribe@googlegroups.com

(https://wiki.ohie.org/display/resources/Mailing+Lists)

To view this discussion on the web visit https://groups.google.com/d/msgid/ohie-implementers/CAFNRjWjpBF4Oxww0_HwLvuQQH9HViEay7VJmq4SuKik5R0q6Ng%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.

To view this discussion on the web visit https://groups.google.com/d/msgid/ohie-implementers/D50C5BCA.38C4C%25thcullen%40regenstrief.org.

For more options, visit https://groups.google.com/d/optout.

--
Regards,
~Steven Wanyee Macharia~

[Cullen, Theresa]

I will share once we finish our internal review to make sure that what I put together is ok. Should be early next week. Thanks 

Sent from my iPhone

[Steven Wanyee]

Thank you.

[msambath sambath]

Hi all

Could any one help to answer below questions

……….

I have a problem with MedicCR

I send this request 

$adr01_llp="\vMSH|^~\&|NIST_Pearl_PIX_Source^^|NIST^^|CR1^^|MOH_CAAT^^|20141104174451||ADT^A01^ADT_A01|NIST-20141104174451|P|2.3.1\rEVN||20101020\rPID|||RJ-438^^^&2.16.840.1.113883.3.72.5.9.1||JOHNSTON^ROBERT^^^^^L|MURRAY^^^^^^L|19830205|M|||1220 Centennial Farm Road^^ELLIOTT^IA^51532||^PRN^PH^^^712^7670867||||||481-27-4185\rPV1||I\r".Chr(28)."\r";

this below is response

MSH|^~\&|DESKTOP-QPUANNN|Fake Jurisdiction|NIST_Pearl_PIX_Source|NIST|201704061100||ACK^A01|8926ee73-0b4d-4f98-9fbf-1a0bcaa83b03|P|2.3.1 MSA|AR|NIST-20141104174451 ERR|^^^207&Application internal error&&&Object reference not set to an instance of an object.   


this below is log

4/6/2017 11:00:44 AM : ClientRegistry.exe Error: 0 : 4/6/2017 11:00:44 AM : System.NullReferenceException: Object reference not set to an instance of an object.
   at MARC.HI.EHRS.CR.Messaging.PixPdqv2.ComponentUtility.CreatePerson(PID pid, List`1 dtls, OidData aaut)
   at MARC.HI.EHRS.CR.Messaging.PixPdqv2.ComponentUtility.CreateComponents(ADT_A01 request, List`1 dtls)
   at MARC.HI.EHRS.CR.Messaging.PixPdqv2.PixHandler.HandlePixAdmit(ADT_A01 request, Hl7MessageReceivedEventArgs evt)

I think something wrong with my request hl7's string but i don't know where?

Best Regard,

[Pierre Dane]

Hi Msambath,

Have you tried using the Hapi Test Panel to test the format of your messages? You can download it here: http://hl7api.sourceforge.net/hapi-testpanel/

Thanks,

Pierre 

Thank you.

Good morning Sambath

Post: client-...@googlegroups.com
Subscribe: client-regis...@googlegroups.com
Unsubscribe: client-regist...@googlegroups.com

(https://wiki.ohie.org/display/resources/Mailing+Lists)

Wiki page: https://wiki.ohie.org/display/SUB/OpenHIE+Implementers
Subscribe: ohie-implemen...@googlegroups.com
Post: ohie-imp...@googlegroups.com

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/CACMjOH%3Dzcof5CCJbbhV7icurjFz1Hz4C860Oqr9hq_mUO7AOkw%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/CAFNRjWjpBF4Oxww0_HwLvuQQH9HViEay7VJmq4SuKik5R0q6Ng%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/D50C5BCA.38C4C%25thcullen%40regenstrief.org.
For more options, visit https://groups.google.com/d/optout.

--
Regards,
~Steven Wanyee Macharia~

--

Regards,
~Steven Wanyee Macharia~

--

Pierre Dane

Director of Technology

Jembi Health Systems NPC

[msambath sambath]

Dear Terry,

Could you share with us document of Open HIE requirement table?

Thanks

Sambath

From: Steven Wanyee <swa...@gmail.com>
Date: Friday, April 7, 2017 at 7:03 PM
To: "Cullen, Theresa" <thcu...@regenstrief.org>

[Cullen, Theresa]

We haven't finished it yet. I apologize. 

To be clear, the table that we are working on is only to assist in the empi decision.  I will try to get this done this week. 

Thanks. Terry

Sent from my iPhone

[msambath sambath]

Dear Terry

Could share some info on your initiative on OpenHIE at your country? Using Medic CR or OpenEPMI?

Thanks

Sambath