OpenHIE client registry setup

HI all,
I am trying to setup a connection to a client registry from OpenHIM and would appreciate any help in understanding whether there are existing test registry I can use or if I should setup one. I am trying to get an OpenHIE integration setup on AWS instances for test/performance purposes and would like to mimic the OpenHIE workflow 1.0 eventually using the new FHIR mechanisms hopefully getting release early this year. Apologies if this is the wrong group for this. Please let me know.

Thanks,
Dean..

Hi Dean,

Thanks for reaching out. Two key elements here are configuring the OpenHIM and selection of a CR/MPI system. The implementation process will depend in part on your choice of MPI. Can you say what your anticipated software components will be?

Best,

Shaun

···

On Tue, Jan 17, 2017 at 1:58 PM, dchandler@path.org wrote:

HI all,

I am trying to setup a connection to a client registry from OpenHIM and would appreciate any help in understanding whether there are existing test registry I can use or if I should setup one. I am trying to get an OpenHIE integration setup on AWS instances for test/performance purposes and would like to mimic the OpenHIE workflow 1.0 eventually using the new FHIR mechanisms hopefully getting release early this year. Apologies if this is the wrong group for this. Please let me know.

Thanks,

Dean…

You received this message because you are subscribed to the Google Groups “Interoperability Layer (OpenHIE)” group.

To unsubscribe from this group and stop receiving emails from it, send an email to openhie-interoperability-layer+unsubscribe@googlegroups.com.

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


Shaun J. Grannis, MD MS FACMI FAAFP
Biomedical Research Scientist, The Regenstrief Institute
Associate Professor, I.U. School of Medicine
410 West 10th Street, Suite 2000
Indianapolis, IN 46202
(317) 274-9092 (Office)
(317) 274-9305 (Fax)

HI Shaun,

             Thanks for getting back to me.  I am trying to follow the OpenHIE install doc see link below so I can enable some of the v1.0 workflow. I have

pretty much installed everything except the CR services so OpenHIM, OpenSHR, OpenMRS, and OpenInfoMan. My hope is to be able to show the performance/scalability for the interop between the OpenHIM and the CR using latest FHIR implementation .
I am very new to eHealth so any feedback or pointers would be really appreciated.

Dean…

https://wiki.ohie.org/display/resources/How+to+install+OpenHIE+1.0

···

Hi Dean,

Thanks for reaching out. Two key elements here are configuring the OpenHIM and selection of a CR/MPI system. The implementation process will depend in part on your choice of MPI. Can you say what your anticipated software components will
be?

Best,

Shaun


Shaun J. Grannis, MD MS FACMI FAAFP

Biomedical Research Scientist, The Regenstrief Institute

Associate Professor, I.U. School of Medicine

410 West 10th Street, Suite 2000

Indianapolis, IN 46202

(317) 274-9092 (Office)

(317) 274-9305 (Fax)

On Tue, Jan 17, 2017 at 1:58 PM, dchandler@path.org wrote:

HI all,
I am trying to setup a connection to a client registry from OpenHIM and would appreciate any help in understanding whether there are existing test registry I can use or if I should setup one. I am trying to get an OpenHIE integration setup on AWS instances
for test/performance purposes and would like to mimic the OpenHIE workflow 1.0 eventually using the new FHIR mechanisms hopefully getting release early this year. Apologies if this is the wrong group for this. Please let me know.

Thanks,
Dean…

You received this message because you are subscribed to the Google Groups “Interoperability Layer (OpenHIE)” group.

To unsubscribe from this group and stop receiving emails from it, send an email to
openhie-interoperability-layer+unsubscribe@googlegroups.com.

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

Dean,

Are you considering MEDIC-CR (“Mohawk CR” in the document you reference), or OpenEMPI?

Thanks,

Shaun

···

On Tue, Jan 17, 2017 at 4:20 PM, Chandler, Dean dchandler@path.org wrote:

HI Shaun,

             Thanks for getting back to me.  I am trying to follow the OpenHIE install doc see link below so I can enable some of the v1.0 workflow. I have

pretty much installed everything except the CR services so OpenHIM, OpenSHR, OpenMRS, and OpenInfoMan. My hope is to be able to show the performance/scalability for the interop between the OpenHIM and the CR using latest FHIR implementation .
I am very new to eHealth so any feedback or pointers would be really appreciated.

Dean…

https://wiki.ohie.org/display/resources/How+to+install+OpenHIE+1.0

From: Shaun Grannis [mailto:sgrannis@gmail.com]
Sent: Tuesday, January 17, 2017 1:12 PM
To: Chandler, Dean dchandler@path.org
Cc: Interoperability Layer (OpenHIE) openhie-interoperability-layer@googlegroups.com
Subject: Re: OpenHIE client registry setup

Hi Dean,

Thanks for reaching out. Two key elements here are configuring the OpenHIM and selection of a CR/MPI system. The implementation process will depend in part on your choice of MPI. Can you say what your anticipated software components will
be?

Best,

Shaun


Shaun J. Grannis, MD MS FACMI FAAFP

Biomedical Research Scientist, The Regenstrief Institute

Associate Professor, I.U. School of Medicine

410 West 10th Street, Suite 2000

Indianapolis, IN 46202

(317) 274-9092 (Office)

(317) 274-9305 (Fax)

On Tue, Jan 17, 2017 at 1:58 PM, dchandler@path.org wrote:

HI all,
I am trying to setup a connection to a client registry from OpenHIM and would appreciate any help in understanding whether there are existing test registry I can use or if I should setup one. I am trying to get an OpenHIE integration setup on AWS instances
for test/performance purposes and would like to mimic the OpenHIE workflow 1.0 eventually using the new FHIR mechanisms hopefully getting release early this year. Apologies if this is the wrong group for this. Please let me know.

Thanks,
Dean…

You received this message because you are subscribed to the Google Groups “Interoperability Layer (OpenHIE)” group.

To unsubscribe from this group and stop receiving emails from it, send an email to
openhie-interoperability-layer+unsubscribe@googlegroups.com.

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


Shaun J. Grannis, MD MS FACMI FAAFP
Biomedical Research Scientist, The Regenstrief Institute
Associate Professor, I.U. School of Medicine
410 West 10th Street, Suite 2000
Indianapolis, IN 46202
(317) 274-9092 (Office)
(317) 274-9305 (Fax)

Medic CR

···

Get Outlook for Android

From: Shaun Grannis
Sent: Tuesday, January 17, 2:46 PM
Subject: Re: OpenHIE client registry setup
To: Chandler, Dean
Cc: Interoperability Layer (OpenHIE)

Dean,

Are you considering MEDIC-CR (“Mohawk CR” in the document you reference), or OpenEMPI?

Thanks,

Shaun


Shaun J. Grannis, MD MS FACMI FAAFP
Biomedical Research Scientist, The Regenstrief Institute
Associate Professor, I.U. School of Medicine
410 West 10th Street, Suite 2000
Indianapolis, IN 46202
(317) 274-9092 (Office)
(317) 274-9305 (Fax)

On Tue, Jan 17, 2017 at 4:20 PM, Chandler, Dean dchandler@path.org wrote:

HI Shaun,

Thanks for getting back to me. I am trying to follow the OpenHIE install doc see link below so I can enable some of the v1.0 workflow. I have pretty much installed everything except the CR services so OpenHIM, OpenSHR, OpenMRS, and OpenInfoMan.
My hope is to be able to show the performance/scalability for the interop between the OpenHIM and the CR using latest FHIR implementation. I am very new to eHealth so any feedback or pointers would be really appreciated.

Dean…

https://wiki.ohie.org/display/resources/How+to+install+OpenHIE+1.0

From: Shaun Grannis [mailto:sgrannis@gmail.com]
Sent: Tuesday, January 17, 2017 1:12 PM
To: Chandler, Dean dchandler@path.org
Cc: Interoperability Layer (OpenHIE) openhie-interoperability-layer@googlegroups.com
Subject: Re: OpenHIE client registry setup

Hi Dean,

Thanks for reaching out. Two key elements here are configuring the OpenHIM and selection of a CR/MPI system. The implementation process will depend in part on your choice of MPI. Can you say what your anticipated software components will be?

Best,

Shaun


Shaun J. Grannis, MD MS FACMI FAAFP
Biomedical Research Scientist, The Regenstrief Institute
Associate Professor, I.U. School of Medicine
410 West 10th Street, Suite 2000
Indianapolis, IN 46202
(317) 274-9092 (Office)
(317) 274-9305 (Fax)

On Tue, Jan 17, 2017 at 1:58 PM, dchandler@path.org wrote:

HI all,
I am trying to setup a connection to a client registry from OpenHIM and would appreciate any help in understanding whether there are existing test registry I can use or if I should setup one. I am trying to get an OpenHIE integration setup on AWS instances
for test/performance purposes and would like to mimic the OpenHIE workflow 1.0 eventually using the new FHIR mechanisms hopefully getting release early this year. Apologies if this is the wrong group for this. Please let me know.

Thanks,
Dean…


You received this message because you are subscribed to the Google Groups “Interoperability Layer (OpenHIE)” group.
To unsubscribe from this group and stop receiving emails from it, send an email to
openhie-interoperability-layer+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

The Mohawk team has deep experience with creating and implementation. Have you looked at this resource:
https://wiki.ohie.org/display/resources/Client+Registry+Setup ?

···

From: openhie-interoperability-layer@googlegroups.com on behalf of “Chandler, Dean” dchandler@path.org
Date: Tuesday, January 17, 2017 at 5:49 PM
To: Shaun Grannis sgrannis@gmail.com
Cc: “Interoperability Layer (OpenHIE)” openhie-interoperability-layer@googlegroups.com
Subject: Re: OpenHIE client registry setup

Medic CR

Get
Outlook for Android

From: Shaun Grannis
Sent: Tuesday, January 17, 2:46 PM
Subject: Re: OpenHIE client registry setup
To: Chandler, Dean
Cc: Interoperability Layer (OpenHIE)

Dean,

Are you considering MEDIC-CR (“Mohawk CR” in the document you reference), or OpenEMPI?

Thanks,

Shaun


Shaun J. Grannis, MD MS FACMI FAAFP
Biomedical Research Scientist, The Regenstrief Institute
Associate Professor, I.U. School of Medicine
410 West 10th Street, Suite 2000
Indianapolis, IN 46202
(317) 274-9092 (Office)
(317) 274-9305 (Fax)

On Tue, Jan 17, 2017 at 4:20 PM, Chandler, Dean dchandler@path.org wrote:

HI Shaun,

Thanks for getting back to me. I am trying to follow the OpenHIE install doc see link below so I can enable some of the v1.0 workflow. I have pretty much installed everything
except the CR services so OpenHIM, OpenSHR, OpenMRS, and OpenInfoMan. My hope is to be able to show the performance/scalability for the interop between the OpenHIM and the CR using latest FHIR implementation. I am very new to eHealth so any feedback or
pointers would be really appreciated.

Dean…

https://wiki.ohie.org/display/resources/How+to+install+OpenHIE+1.0

From: Shaun Grannis [mailto:sgrannis@gmail.com]
Sent: Tuesday, January 17, 2017 1:12 PM
To: Chandler, Dean dchandler@path.org
Cc: Interoperability Layer (OpenHIE) openhie-interoperability-layer@googlegroups.com
Subject: Re: OpenHIE client registry setup

Hi Dean,

Thanks for reaching out. Two key elements here are configuring the OpenHIM and selection of a CR/MPI system. The implementation process will depend in part on your choice of MPI. Can you say what
your anticipated software components will be?

Best,

Shaun


Shaun J. Grannis, MD MS FACMI FAAFP
Biomedical Research Scientist, The Regenstrief Institute
Associate Professor, I.U. School of Medicine
410 West 10th Street, Suite 2000
Indianapolis, IN 46202
(317) 274-9092 (Office)
(317) 274-9305 (Fax)

On Tue, Jan 17, 2017 at 1:58 PM, dchandler@path.org wrote:

HI all,
I am trying to setup a connection to a client registry from OpenHIM and would appreciate any help in understanding whether there are existing test registry I can use or if I should setup one. I am trying to get an OpenHIE integration setup on AWS instances
for test/performance purposes and would like to mimic the OpenHIE workflow 1.0 eventually using the new FHIR mechanisms hopefully getting release early this year. Apologies if this is the wrong group for this. Please let me know.

Thanks,
Dean…


You received this message because you are subscribed to the Google Groups “Interoperability Layer (OpenHIE)” group.
To unsubscribe from this group and stop receiving emails from it, send an email to
openhie-interoperability-layer+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 “Interoperability Layer (OpenHIE)” group.
To unsubscribe from this group and stop receiving emails from it, send an email to
openhie-interoperability-layer+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Hi Shaun,

Yes we have pinged the Mohawk folks on a separate thread. The link to the MEDIC CR installation from page below is broken so wasn’t able to
make progress.

Dean…

···

From: Grannis, Shaun J [mailto:sgrannis@regenstrief.org]
Sent: Tuesday, January 17, 2017 2:53 PM
To: Chandler, Dean dchandler@path.org
Cc: Interoperability Layer (OpenHIE) openhie-interoperability-layer@googlegroups.com
Subject: Re: OpenHIE client registry setup

The Mohawk team has deep experience with creating and implementation. Have you looked at this resource:
https://wiki.ohie.org/display/resources/Client+Registry+Setup ?

From:openhie-interoperability-layer@googlegroups.com on behalf of “Chandler, Dean” dchandler@path.org
Date: Tuesday, January 17, 2017 at 5:49 PM
To: Shaun Grannis sgrannis@gmail.com
Cc: “Interoperability Layer (OpenHIE)” openhie-interoperability-layer@googlegroups.com
Subject: Re: OpenHIE client registry setup

Medic CR

Get
Outlook for Android

From: Shaun Grannis
Sent: Tuesday, January 17, 2:46 PM
Subject: Re: OpenHIE client registry setup
To: Chandler, Dean
Cc: Interoperability Layer (OpenHIE)

Dean,

Are you considering MEDIC-CR (“Mohawk CR” in the document you reference), or OpenEMPI?

Thanks,

Shaun


Shaun J. Grannis, MD MS FACMI FAAFP
Biomedical Research Scientist, The Regenstrief Institute
Associate Professor, I.U. School of Medicine
410 West 10th Street, Suite 2000
Indianapolis, IN 46202
(317) 274-9092 (Office)
(317) 274-9305 (Fax)

On Tue, Jan 17, 2017 at 4:20 PM, Chandler, Dean dchandler@path.org wrote:

HI Shaun,

Thanks for getting back to me. I am trying to follow the OpenHIE install doc see link below so I can enable some of the v1.0 workflow. I have pretty much installed
everything except the CR services so OpenHIM, OpenSHR, OpenMRS, and OpenInfoMan. My hope is to be able to show the performance/scalability for the interop between the OpenHIM and the CR using latest FHIR implementation. I am very new to eHealth so any
feedback or pointers would be really appreciated.

Dean…

https://wiki.ohie.org/display/resources/How+to+install+OpenHIE+1.0

From: Shaun Grannis [mailto:sgrannis@gmail.com]
Sent: Tuesday, January 17, 2017 1:12 PM
To: Chandler, Dean dchandler@path.org
Cc: Interoperability Layer (OpenHIE) openhie-interoperability-layer@googlegroups.com
Subject: Re: OpenHIE client registry setup

Hi Dean,

Thanks for reaching out. Two key elements here are configuring the OpenHIM and selection of a CR/MPI system. The implementation process will depend in part on your choice of MPI.
Can you say what your anticipated software components will be?

Best,

Shaun


Shaun J. Grannis, MD MS FACMI FAAFP
Biomedical Research Scientist, The Regenstrief Institute
Associate Professor, I.U. School of Medicine
410 West 10th Street, Suite 2000
Indianapolis, IN 46202
(317) 274-9092 (Office)
(317) 274-9305 (Fax)

On Tue, Jan 17, 2017 at 1:58 PM, dchandler@path.org wrote:

HI all,
I am trying to setup a connection to a client registry from OpenHIM and would appreciate any help in understanding whether there are existing test registry I can use or if I should setup one. I am trying to get an OpenHIE integration setup on AWS instances
for test/performance purposes and would like to mimic the OpenHIE workflow 1.0 eventually using the new FHIR mechanisms hopefully getting release early this year. Apologies if this is the wrong group for this. Please let me know.

Thanks,
Dean…


You received this message because you are subscribed to the Google Groups “Interoperability Layer (OpenHIE)” group.
To unsubscribe from this group and stop receiving emails from it, send an email to
openhie-interoperability-layer+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 “Interoperability Layer (OpenHIE)” group.
To unsubscribe from this group and stop receiving emails from it, send an email to
openhie-interoperability-layer+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Hi Dean,

We at Jembi have also been working on setting up an OpenHIE demo which includes MedicCR as the client registry.

We followed this guide to get the server configured - https://mediccr.codeplex.com/wikipage?title=Single%20Server%20Deployment&referringTitle=Documentation

I then used the MedicCR configurator to enable both the FHIR endpoints and the PIX/PDQ endpoints. To get these messages to be passed through the OpenHIM you will need to create channels in the OpenHIM that forwards requests that you send to the OpenHIM to MedicCR. You can find some documentation on setting up channels in the OpenHIM docs - http://openhim.readthedocs.io/en/latest/user-guide/basic-config.html We also have some OpenHIM tutorials if you want a better understanding of how it works - http://openhim.readthedocs.io/en/latest/tutorial/index.html

We are also still getting our demo configuration right and may be able to provide more help as we get further in doing this ourselves.

Cheers,

Ryan

···

On Wed, Jan 18, 2017 at 12:49 AM Chandler, Dean dchandler@path.org wrote:

Medic CR

Get Outlook for Android

From: Shaun Grannis
Sent: Tuesday, January 17, 2:46 PM

Subject: Re: OpenHIE client registry setup

To: Chandler, Dean
Cc: Interoperability Layer (OpenHIE)

Dean,

Are you considering MEDIC-CR (“Mohawk CR” in the document you reference), or OpenEMPI?

Thanks,

Shaun


Shaun J. Grannis, MD MS FACMI FAAFP
Biomedical Research Scientist, The Regenstrief Institute
Associate Professor, I.U. School of Medicine
410 West 10th Street, Suite 2000
Indianapolis, IN 46202
(317) 274-9092 (Office)
(317) 274-9305 (Fax)

On Tue, Jan 17, 2017 at 4:20 PM, Chandler, Dean dchandler@path.org wrote:

HI Shaun,

Thanks for getting back to me. I am trying to follow the OpenHIE install doc see link below so I can enable some of the v1.0 workflow. I have pretty much installed everything except the CR services so OpenHIM, OpenSHR, OpenMRS, and OpenInfoMan.
My hope is to be able to show the performance/scalability for the interop between the OpenHIM and the CR using latest FHIR implementation. I am very new to eHealth so any feedback or pointers would be really appreciated.

Dean…

https://wiki.ohie.org/display/resources/How+to+install+OpenHIE+1.0

From: Shaun Grannis [mailto:sgrannis@gmail.com]
Sent: Tuesday, January 17, 2017 1:12 PM
To: Chandler, Dean dchandler@path.org
Cc: Interoperability Layer (OpenHIE) openhie-interoperability-layer@googlegroups.com
Subject: Re: OpenHIE client registry setup

Hi Dean,

Thanks for reaching out. Two key elements here are configuring the OpenHIM and selection of a CR/MPI system. The implementation process will depend in part on your choice of MPI. Can you say what your anticipated software components will be?

Best,

Shaun


Shaun J. Grannis, MD MS FACMI FAAFP
Biomedical Research Scientist, The Regenstrief Institute
Associate Professor, I.U. School of Medicine
410 West 10th Street, Suite 2000
Indianapolis, IN 46202
(317) 274-9092 (Office)
(317) 274-9305 (Fax)

On Tue, Jan 17, 2017 at 1:58 PM, dchandler@path.org wrote:

HI all,
I am trying to setup a connection to a client registry from OpenHIM and would appreciate any help in understanding whether there are existing test registry I can use or if I should setup one. I am trying to get an OpenHIE integration setup on AWS instances
for test/performance purposes and would like to mimic the OpenHIE workflow 1.0 eventually using the new FHIR mechanisms hopefully getting release early this year. Apologies if this is the wrong group for this. Please let me know.

Thanks,
Dean…


You received this message because you are subscribed to the Google Groups “Interoperability Layer (OpenHIE)” group.
To unsubscribe from this group and stop receiving emails from it, send an email to
openhie-interoperability-layer+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 “Interoperability Layer (OpenHIE)” group.

To unsubscribe from this group and stop receiving emails from it, send an email to openhie-interoperability-layer+unsubscribe@googlegroups.com.

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

Ryan Crichton

Lead Developer, Jembi Health Systems | SOUTH AFRICA

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

Hi Ryan,

Thanks for the pointers. I keep running into an issue with either set of instructions that is preventing me from running the Admin interface
at the following url.

http://127.0.0.1:9999/admin. Any ideas as to why this issue keeps coming up.

Thanks,

Dean…

···

Hi Dean,

We at Jembi have also been working on setting up an OpenHIE demo which includes MedicCR as the client registry.

We followed this guide to get the server configured - https://mediccr.codeplex.com/wikipage?title=Single%20Server%20Deployment&referringTitle=Documentation

I then used the MedicCR configurator to enable both the FHIR endpoints and the PIX/PDQ endpoints. To get these messages to be passed through the OpenHIM you will need to create channels in the OpenHIM that forwards requests that you send
to the OpenHIM to MedicCR. You can find some documentation on setting up channels in the OpenHIM docs - http://openhim.readthedocs.io/en/latest/user-guide/basic-config.html We
also have some OpenHIM tutorials if you want a better understanding of how it works - http://openhim.readthedocs.io/en/latest/tutorial/index.html

We are also still getting our demo configuration right and may be able to provide more help as we get further in doing this ourselves.

Cheers,

Ryan

On Wed, Jan 18, 2017 at 12:49 AM Chandler, Dean dchandler@path.org wrote:

Medic CR

Get
Outlook for Android

From: Shaun Grannis
Sent: Tuesday, January 17, 2:46 PM

Subject: Re: OpenHIE client registry setup

To: Chandler, Dean
Cc: Interoperability Layer (OpenHIE)

Dean,

Are you considering MEDIC-CR (“Mohawk CR” in the document you reference), or OpenEMPI?

Thanks,

Shaun


Shaun J. Grannis, MD MS FACMI FAAFP
Biomedical Research Scientist, The Regenstrief Institute
Associate Professor, I.U. School of Medicine
410 West 10th Street, Suite 2000
Indianapolis, IN 46202
(317) 274-9092 (Office)
(317) 274-9305 (Fax)

On Tue, Jan 17, 2017 at 4:20 PM, Chandler, Dean dchandler@path.org wrote:

HI Shaun,

Thanks for getting back to me. I am trying to follow the OpenHIE install doc see link below so I can enable some of the v1.0 workflow. I have pretty much installed everything
except the CR services so OpenHIM, OpenSHR, OpenMRS, and OpenInfoMan. My hope is to be able to show the performance/scalability for the interop between the OpenHIM and the CR using latest FHIR implementation. I am very new to eHealth so any feedback or
pointers would be really appreciated.

Dean…

https://wiki.ohie.org/display/resources/How+to+install+OpenHIE+1.0

From: Shaun Grannis [mailto:sgrannis@gmail.com]
Sent: Tuesday, January 17, 2017 1:12 PM
To: Chandler, Dean dchandler@path.org
Cc: Interoperability Layer (OpenHIE) openhie-interoperability-layer@googlegroups.com
Subject: Re: OpenHIE client registry setup

Hi Dean,

Thanks for reaching out. Two key elements here are configuring the OpenHIM and selection of a CR/MPI system. The implementation process will depend in part on your choice of MPI. Can
you say what your anticipated software components will be?

Best,

Shaun


Shaun J. Grannis, MD MS FACMI FAAFP
Biomedical Research Scientist, The Regenstrief Institute
Associate Professor, I.U. School of Medicine
410 West 10th Street, Suite 2000
Indianapolis, IN 46202
(317) 274-9092 (Office)
(317) 274-9305 (Fax)

On Tue, Jan 17, 2017 at 1:58 PM, dchandler@path.org wrote:

HI all,
I am trying to setup a connection to a client registry from OpenHIM and would appreciate any help in understanding whether there are existing test registry I can use or if I should setup one. I am trying to get an OpenHIE integration setup on AWS instances
for test/performance purposes and would like to mimic the OpenHIE workflow 1.0 eventually using the new FHIR mechanisms hopefully getting release early this year. Apologies if this is the wrong group for this. Please let me know.

Thanks,
Dean…


You received this message because you are subscribed to the Google Groups “Interoperability Layer (OpenHIE)” group.
To unsubscribe from this group and stop receiving emails from it, send an email to

openhie-interoperability-layer+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 “Interoperability Layer (OpenHIE)” group.
To unsubscribe from this group and stop receiving emails from it, send an email to

openhie-interoperability-layer+unsubscribe@googlegroups.com.
For more options, visit
https://groups.google.com/d/optout
.

Ryan Crichton

Lead Developer, Jembi Health Systems | SOUTH AFRICA

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

Hi Dean,

From what I understand of MedicCR it seems that the admin interface is a soap-based web service interface rather than a user interface. I got the same thing that you are getting. At least that is how the configurator made it sound, I could be wrong. I think all the configuration is done through the configurator app. Can anyone of this list verify this?

Cheers,

Ryan

···

On Tue, Jan 24, 2017 at 12:29 AM Chandler, Dean dchandler@path.org wrote:

Hi Ryan,

             Thanks for the pointers.  I keep running into an issue with either set of instructions that is preventing me from running the Admin interface

at the following url.

http://127.0.0.1:9999/admin. Any ideas as to why this issue keeps coming up.

Thanks,

            Dean..

From: Ryan Crichton [mailto:ryan@jembi.org]
Sent: Sunday, January 22, 2017 11:47 PM
To: Chandler, Dean dchandler@path.org; Shaun Grannis sgrannis@gmail.com

Cc: Interoperability Layer (OpenHIE) openhie-interoperability-layer@googlegroups.com
Subject: Re: OpenHIE client registry setup

Hi Dean,

We at Jembi have also been working on setting up an OpenHIE demo which includes MedicCR as the client registry.

We followed this guide to get the server configured - https://mediccr.codeplex.com/wikipage?title=Single%20Server%20Deployment&referringTitle=Documentation

I then used the MedicCR configurator to enable both the FHIR endpoints and the PIX/PDQ endpoints. To get these messages to be passed through the OpenHIM you will need to create channels in the OpenHIM that forwards requests that you send
to the OpenHIM to MedicCR. You can find some documentation on setting up channels in the OpenHIM docs - http://openhim.readthedocs.io/en/latest/user-guide/basic-config.html We
also have some OpenHIM tutorials if you want a better understanding of how it works - http://openhim.readthedocs.io/en/latest/tutorial/index.html

We are also still getting our demo configuration right and may be able to provide more help as we get further in doing this ourselves.

Cheers,

Ryan

On Wed, Jan 18, 2017 at 12:49 AM Chandler, Dean dchandler@path.org wrote:

Medic CR

Get
Outlook for Android

From: Shaun Grannis

Sent: Tuesday, January 17, 2:46 PM

Subject: Re: OpenHIE client registry setup

To: Chandler, Dean

Cc: Interoperability Layer (OpenHIE)

Dean,

Are you considering MEDIC-CR (“Mohawk CR” in the document you reference), or OpenEMPI?

Thanks,

Shaun


Shaun J. Grannis, MD MS FACMI FAAFP

Biomedical Research Scientist, The Regenstrief Institute

Associate Professor, I.U. School of Medicine

410 West 10th Street, Suite 2000

Indianapolis, IN 46202

(317) 274-9092 (Office)

(317) 274-9305 (Fax)

On Tue, Jan 17, 2017 at 4:20 PM, Chandler, Dean dchandler@path.org wrote:

HI Shaun,

             Thanks for getting back to me.  I am trying to follow the OpenHIE install doc see link below so I can enable some of the v1.0 workflow. I have pretty much installed everything

except the CR services so OpenHIM, OpenSHR, OpenMRS, and OpenInfoMan. My hope is to be able to show the performance/scalability for the interop between the OpenHIM and the CR using latest FHIR implementation. I am very new to eHealth so any feedback or
pointers would be really appreciated.

Dean…

https://wiki.ohie.org/display/resources/How+to+install+OpenHIE+1.0

From: Shaun Grannis [mailto:sgrannis@gmail.com]
Sent: Tuesday, January 17, 2017 1:12 PM
To: Chandler, Dean dchandler@path.org
Cc: Interoperability Layer (OpenHIE) openhie-interoperability-layer@googlegroups.com
Subject: Re: OpenHIE client registry setup

Hi Dean,

Thanks for reaching out. Two key elements here are configuring the OpenHIM and selection of a CR/MPI system. The implementation process will depend in part on your choice of MPI. Can
you say what your anticipated software components will be?

Best,

Shaun


Shaun J. Grannis, MD MS FACMI FAAFP

Biomedical Research Scientist, The Regenstrief Institute

Associate Professor, I.U. School of Medicine

410 West 10th Street, Suite 2000

Indianapolis, IN 46202

(317) 274-9092 (Office)

(317) 274-9305 (Fax)

On Tue, Jan 17, 2017 at 1:58 PM, dchandler@path.org wrote:

HI all,

I am trying to setup a connection to a client registry from OpenHIM and would appreciate any help in understanding whether there are existing test registry I can use or if I should setup one. I am trying to get an OpenHIE integration setup on AWS instances
for test/performance purposes and would like to mimic the OpenHIE workflow 1.0 eventually using the new FHIR mechanisms hopefully getting release early this year. Apologies if this is the wrong group for this. Please let me know.

Thanks,

Dean…

You received this message because you are subscribed to the Google Groups “Interoperability Layer (OpenHIE)” group.

To unsubscribe from this group and stop receiving emails from it, send an email to

openhie-interoperability-layer+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 “Interoperability Layer (OpenHIE)” group.
To unsubscribe from this group and stop receiving emails from it, send an email to

openhie-interoperability-layer+unsubscribe@googlegroups.com.
For more options, visit
https://groups.google.com/d/optout
.

Ryan Crichton

Lead Developer, Jembi Health Systems | SOUTH AFRICA

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

Ryan Crichton

Lead Developer, Jembi Health Systems | SOUTH AFRICA

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

Hi Ryan,

Thanks for the feedback. So does MedicCR store the data for the client or just the transaction info in the local postgresql database? Looks
like I need more info on how the big picture works here. Let me know how your testing goes and any additional pointers to related documentation.

Dean…

···

Hi Dean,

From what I understand of MedicCR it seems that the admin interface is a soap-based web service interface rather than a user interface. I got the same thing that you are getting. At least that is how the configurator made it sound, I could
be wrong. I think all the configuration is done through the configurator app. Can anyone of this list verify this?

Cheers,

Ryan

On Tue, Jan 24, 2017 at 12:29 AM Chandler, Dean dchandler@path.org wrote:

Hi Ryan,

             Thanks for the pointers.  I keep running into an issue with

either set of instructions that is preventing me from running the Admin interface at the following url.

http://127.0.0.1:9999/admin .
Any ideas as to why this issue keeps coming up.

Thanks,

            Dean..

From:
Ryan Crichton [mailto:ryan@jembi.org]
Sent: Sunday, January 22, 2017 11:47 PM
To: Chandler, Dean dchandler@path.org; Shaun Grannis sgrannis@gmail.com

Cc: Interoperability Layer (OpenHIE) openhie-interoperability-layer@googlegroups.com
Subject: Re: OpenHIE client registry setup

Hi Dean,

We at Jembi have also been working on setting up an OpenHIE demo which includes MedicCR as the client registry.

We followed this guide to get the server configured - https://mediccr.codeplex.com/wikipage?title=Single%20Server%20Deployment&referringTitle=Documentation

I then used the MedicCR configurator to enable both the FHIR endpoints and the PIX/PDQ endpoints. To get these messages to be passed through the OpenHIM you will need to create
channels in the OpenHIM that forwards requests that you send to the OpenHIM to MedicCR. You can find some documentation on setting up channels in the OpenHIM docs - http://openhim.readthedocs.io/en/latest/user-guide/basic-config.html We
also have some OpenHIM tutorials if you want a better understanding of how it works - http://openhim.readthedocs.io/en/latest/tutorial/index.html

We are also still getting our demo configuration right and may be able to provide more help as we get further in doing this ourselves.

Cheers,

Ryan

On Wed, Jan 18, 2017 at 12:49 AM Chandler, Dean dchandler@path.org wrote:

Medic CR

Get
Outlook for Android

From: Shaun Grannis

Sent: Tuesday, January 17, 2:46 PM

Subject: Re: OpenHIE client registry setup

To: Chandler, Dean

Cc: Interoperability Layer (OpenHIE)

Dean,

Are you considering MEDIC-CR (“Mohawk CR” in the document you reference), or OpenEMPI?

Thanks,

Shaun


Shaun J. Grannis, MD MS FACMI FAAFP

Biomedical Research Scientist, The Regenstrief Institute

Associate Professor, I.U. School of Medicine

410 West 10th Street, Suite 2000

Indianapolis, IN 46202

(317) 274-9092 (Office)

(317) 274-9305 (Fax)

On Tue, Jan 17, 2017 at 4:20 PM, Chandler, Dean dchandler@path.org wrote:

HI Shaun,

             Thanks for getting back to me.  I am trying to follow the OpenHIE install doc see link below so I can enable some of the v1.0 workflow. I have pretty

much installed everything except the CR services so OpenHIM, OpenSHR, OpenMRS, and OpenInfoMan. My hope is to be able to show the performance/scalability for the interop between the OpenHIM and the CR using latest FHIR implementation. I am very new to
eHealth so any feedback or pointers would be really appreciated.

Dean…

https://wiki.ohie.org/display/resources/How+to+install+OpenHIE+1.0

From: Shaun Grannis [mailto:sgrannis@gmail.com]
Sent: Tuesday, January 17, 2017 1:12 PM
To: Chandler, Dean dchandler@path.org
Cc: Interoperability Layer (OpenHIE) openhie-interoperability-layer@googlegroups.com
Subject: Re: OpenHIE client registry setup

Hi Dean,

Thanks for reaching out. Two key elements here are configuring the OpenHIM and selection of a CR/MPI system. The implementation process will depend in part on your
choice of MPI. Can you say what your anticipated software components will be?

Best,

Shaun


Shaun J. Grannis, MD MS FACMI FAAFP

Biomedical Research Scientist, The Regenstrief Institute

Associate Professor, I.U. School of Medicine

410 West 10th Street, Suite 2000

Indianapolis, IN 46202

(317) 274-9092 (Office)

(317) 274-9305 (Fax)

On Tue, Jan 17, 2017 at 1:58 PM, dchandler@path.org wrote:

HI all,

I am trying to setup a connection to a client registry from OpenHIM and would appreciate any help in understanding whether there are existing test registry I can use or if I should setup one. I am trying to get an OpenHIE integration
setup on AWS instances for test/performance purposes and would like to mimic the OpenHIE workflow 1.0 eventually using the new FHIR mechanisms hopefully getting release early this year. Apologies if this is the wrong group for this. Please let me know.

Thanks,

Dean…

You received this message because you are subscribed to the Google Groups “Interoperability Layer (OpenHIE)” group.

To unsubscribe from this group and stop receiving emails from it, send an email to

openhie-interoperability-layer+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 “Interoperability Layer (OpenHIE)” group.
To unsubscribe from this group and stop receiving emails from it, send an email to

openhie-interoperability-layer+unsubscribe@googlegroups.com.
For more options, visit
https://groups.google.com/d/optout
.

Ryan Crichton

Lead Developer, Jembi Health Systems | SOUTH AFRICA

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

Ryan Crichton

Lead Developer, Jembi Health Systems | SOUTH AFRICA

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

Hi all, thought I would chime in (apparently I wasn’t subscribed to this group apparently, thanks to Derek for bringing this thread to my attention).

The administration interface is indeed a soap based service to which the administration tool connects. The administration tool setup under the bundled installer can be a little bit obtuse to setup, but basically you have to ensure that the web.config file for the admin tool has the same bindings as the configuration for the client registry itself. The administrative interface is bundled with installer and should be in C:\Program Files (x86)\Mohawk College\Client Registry\admin, setup instructions are (at a basic level):

  1. Install IIS with ASP.NET MVC framework 4 or higher
  2. Create a virtual application which points to the C:\Program Files (x86)\Mohawk College\Client Registry\admin directory
  3. Give the IUSR account (or whatever application pool user IIS is using) read/execute access to that directory
  4. Ensure that C:\Program Files (x86)\Mohawk College\Client Registry\admin\web.config matches the service contract for C:\Program Files (x86)\Mohawk College\Client Registry\ClientRegistry.exe.config.
    There may be packaging issue whereby the IIS server will complain about a missing System.Web.Http.dll assembly (it used to be packaged in some ASP.NET MVC installers). If you encounter this, the easiest way to get around it is to hunt down a copy on your machine, or use the 1.2 version installer (which isn’t released yet, it is the version being deployed in Myanmar).

As per the configuration itself, the configuration tool is really just a more user friendly wrapper for the XML based configuration file. You can hand edit the configuration file ClientRegistry.exe.config if you’re comfortable with it, and it does provide additional configuration options. Most of the options for transport/security/etc. are standard .NET WCF configuration options (Configuring Services Using Configuration Files - WCF | Microsoft Learn) however, for most scenarios the UI wraps this complexity sufficiently. I usually use the GUI to get up and running and then hand-edit the XML. The configuration tool shouldn’t mind hand edited config settings and typically leaves them alone (it also makes a backup).

Regarding the question about what the CR stores. The client registry stores various types of data in the data structures it creates (in either separate database instances, or a single database if you selected “simple” or “express” deployment). These are alluded to in section 2.1.3 of the operations guide, but not really in much detail. Basically the types of data stored are:

  • The core CR storage database (defined in /marc.hi.ehrs.cr.persistence.data/connectionManager element)
  • Patient demographics information (name, dob, gender, etc.)
  • Registration event information (in v2 the MSH/EVN segments, v3 the transport/controlAct wrapper and FHIR the best mapping available for those elements)
  • Relationship to non-patient persons (mother, father, etc.)
  • This supports configuration of primary>secondary PostgreSQL streaming replication for large datasets via a write-only primary/read-only secondary(ies). This is really only needed for really really big datasets, or cases where you have lots of application servers or a high number of concurrent clients slamming the CR. For example, the eHealth Ontario innovation lab instance has 1.4 million fake patients and it doesn’t even need this type of deployment (as the response times for queries is still less than 1.2 sec with about 6-8 concurrent sessions).
  • The query tracking database (defined in /marc.ehrs.qm.persistence.data/connectionManager element)
  • Query state information used for query continuation.
  • This is how the V2 RCP segment, the v3 queryId/QUQI_IN100003UV or FHIR _stateId works)
  • The server runs the query once and stores the results, the client can then quickly page through the results in the query set without having the server re-execute the query
  • The message tracking database (defined in /marc.hi.ehrs.svc.messaging.persistence/connectionManager element)
  • Message execution information (exec-once, cached response data, etc.)
  • This is where the CR makes the determination if a message has already been processed in the case of client retry messages. It is triggered off of the MSH-10 field in v2 or the /PRPAXXXX/id element in v3.
  • It is the reason why if you execute a message and then just resend the exact same message without giving it a new message identifier the message is not actually executed.
  • Code reference database (defined in /marc.hi.ehrs…svc.terminology/qdcdb element, you can also use a CTS 1 based server in lieu of this)
  • Provides a basic set of code lookups for things like languages, etc.
    Hope that helps!

Cheers

-Justin

···

On Tuesday, January 24, 2017 at 11:34:03 AM UTC-5, Chandler, Dean wrote:

Hi Ryan,

             Thanks for the feedback.  So does MedicCR store the data for the client or just the transaction info in the local postgresql database?  Looks

like I need more info on how the big picture works here. Let me know how your testing goes and any additional pointers to related documentation.

Dean…

From: Ryan Crichton [mailto:ry...@jembi.org]
Sent: Tuesday, January 24, 2017 3:22 AM
To: Chandler, Dean dcha...@path.org; Shaun Grannis sgra...@gmail.com
Cc: Interoperability Layer (OpenHIE) openhie-interoperability-layer@googlegroups.com
Subject: Re: OpenHIE client registry setup

Hi Dean,

From what I understand of MedicCR it seems that the admin interface is a soap-based web service interface rather than a user interface. I got the same thing that you are getting. At least that is how the configurator made it sound, I could
be wrong. I think all the configuration is done through the configurator app. Can anyone of this list verify this?

Cheers,

Ryan

On Tue, Jan 24, 2017 at 12:29 AM Chandler, Dean dcha...@path.org wrote:

Hi Ryan,

             Thanks for the pointers.  I keep running into an issue with

either set of instructions that is preventing me from running the Admin interface at the following url.

http://127.0.0.1:9999/admin .
Any ideas as to why this issue keeps coming up.

Thanks,

            Dean..

From:
Ryan Crichton [mailto:ry...@jembi.org]
Sent: Sunday, January 22, 2017 11:47 PM
To: Chandler, Dean dcha...@path.org; Shaun Grannis sgra...@gmail.com

Cc: Interoperability Layer (OpenHIE) openhie-interoperability-layer@googlegroups.com
Subject: Re: OpenHIE client registry setup

Hi Dean,

We at Jembi have also been working on setting up an OpenHIE demo which includes MedicCR as the client registry.

We followed this guide to get the server configured - https://mediccr.codeplex.com/wikipage?title=Single%20Server%20Deployment&referringTitle=Documentation

I then used the MedicCR configurator to enable both the FHIR endpoints and the PIX/PDQ endpoints. To get these messages to be passed through the OpenHIM you will need to create
channels in the OpenHIM that forwards requests that you send to the OpenHIM to MedicCR. You can find some documentation on setting up channels in the OpenHIM docs - http://openhim.readthedocs.io/en/latest/user-guide/basic-config.html We
also have some OpenHIM tutorials if you want a better understanding of how it works - http://openhim.readthedocs.io/en/latest/tutorial/index.html

We are also still getting our demo configuration right and may be able to provide more help as we get further in doing this ourselves.

Cheers,

Ryan

On Wed, Jan 18, 2017 at 12:49 AM Chandler, Dean dcha...@path.org wrote:

Medic CR

Get
Outlook for Android

From: Shaun Grannis

Sent: Tuesday, January 17, 2:46 PM

Subject: Re: OpenHIE client registry setup

To: Chandler, Dean

Cc: Interoperability Layer (OpenHIE)

Dean,

Are you considering MEDIC-CR (“Mohawk CR” in the document you reference), or OpenEMPI?

Thanks,

Shaun


Shaun J. Grannis, MD MS FACMI FAAFP

Biomedical Research Scientist, The Regenstrief Institute

Associate Professor, I.U. School of Medicine

410 West 10th Street, Suite 2000

Indianapolis, IN 46202

(317) 274-9092 (Office)

(317) 274-9305 (Fax)

On Tue, Jan 17, 2017 at 4:20 PM, Chandler, Dean dcha...@path.org wrote:

HI Shaun,

             Thanks for getting back to me.  I am trying to follow the OpenHIE install doc see link below so I can enable some of the v1.0 workflow. I have pretty

much installed everything except the CR services so OpenHIM, OpenSHR, OpenMRS, and OpenInfoMan. My hope is to be able to show the performance/scalability for the interop between the OpenHIM and the CR using latest FHIR implementation. I am very new to
eHealth so any feedback or pointers would be really appreciated.

Dean…

https://wiki.ohie.org/display/resources/How+to+install+OpenHIE+1.0

From: Shaun Grannis [mailto:sgra...@gmail.com]
Sent: Tuesday, January 17, 2017 1:12 PM
To: Chandler, Dean dcha...@path.org
Cc: Interoperability Layer (OpenHIE) openhie-interoperability-layer@googlegroups.com
Subject: Re: OpenHIE client registry setup

Hi Dean,

Thanks for reaching out. Two key elements here are configuring the OpenHIM and selection of a CR/MPI system. The implementation process will depend in part on your
choice of MPI. Can you say what your anticipated software components will be?

Best,

Shaun


Shaun J. Grannis, MD MS FACMI FAAFP

Biomedical Research Scientist, The Regenstrief Institute

Associate Professor, I.U. School of Medicine

410 West 10th Street, Suite 2000

Indianapolis, IN 46202

(317) 274-9092 (Office)

(317) 274-9305 (Fax)

On Tue, Jan 17, 2017 at 1:58 PM, dcha...@path.org wrote:

HI all,

I am trying to setup a connection to a client registry from OpenHIM and would appreciate any help in understanding whether there are existing test registry I can use or if I should setup one. I am trying to get an OpenHIE integration
setup on AWS instances for test/performance purposes and would like to mimic the OpenHIE workflow 1.0 eventually using the new FHIR mechanisms hopefully getting release early this year. Apologies if this is the wrong group for this. Please let me know.

Thanks,

Dean…

You received this message because you are subscribed to the Google Groups “Interoperability Layer (OpenHIE)” group.

To unsubscribe from this group and stop receiving emails from it, send an email to

openhie-interoperability-layer+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 “Interoperability Layer (OpenHIE)” group.
To unsubscribe from this group and stop receiving emails from it, send an email to

openhie-interoperability-layer+unsubscribe@googlegroups.com.
For more options, visit
https://groups.google.com/d/optout
.

Ryan Crichton

Lead Developer, Jembi Health Systems | SOUTH AFRICA

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

Ryan Crichton

Lead Developer, Jembi Health Systems | SOUTH AFRICA

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

Oh, I also forgot one additional point.

Once you have your demonstration instance setup, you can share the ClientRegistry.exe.config files with others to replicate the configuration settings across machines/deployments. I may have a few lying around from the various demos we’ve done in the past which we can share. The only real thing that needs to change are the OIDs and database connection strings of course.

Cheers

-Justin

···

On Tuesday, January 24, 2017 at 3:06:32 PM UTC-5, Justin (Mohawk College) wrote:

Hi all, thought I would chime in (apparently I wasn’t subscribed to this group apparently, thanks to Derek for bringing this thread to my attention).

The administration interface is indeed a soap based service to which the administration tool connects. The administration tool setup under the bundled installer can be a little bit obtuse to setup, but basically you have to ensure that the web.config file for the admin tool has the same bindings as the configuration for the client registry itself. The administrative interface is bundled with installer and should be in C:\Program Files (x86)\Mohawk College\Client Registry\admin, setup instructions are (at a basic level):

  1. Install IIS with ASP.NET MVC framework 4 or higher
  2. Create a virtual application which points to the C:\Program Files (x86)\Mohawk College\Client Registry\admin directory
  3. Give the IUSR account (or whatever application pool user IIS is using) read/execute access to that directory
  4. Ensure that C:\Program Files (x86)\Mohawk College\Client Registry\admin\web.config matches the service contract for C:\Program Files (x86)\Mohawk College\Client Registry\ClientRegistry.exe.config.
    There may be packaging issue whereby the IIS server will complain about a missing System.Web.Http.dll assembly (it used to be packaged in some ASP.NET MVC installers). If you encounter this, the easiest way to get around it is to hunt down a copy on your machine, or use the 1.2 version installer (which isn’t released yet, it is the version being deployed in Myanmar).

As per the configuration itself, the configuration tool is really just a more user friendly wrapper for the XML based configuration file. You can hand edit the configuration file ClientRegistry.exe.config if you’re comfortable with it, and it does provide additional configuration options. Most of the options for transport/security/etc. are standard .NET WCF configuration options (https://msdn.microsoft.com/en-us/library/ms733932(v=vs.110).aspx) however, for most scenarios the UI wraps this complexity sufficiently. I usually use the GUI to get up and running and then hand-edit the XML. The configuration tool shouldn’t mind hand edited config settings and typically leaves them alone (it also makes a backup).

Regarding the question about what the CR stores. The client registry stores various types of data in the data structures it creates (in either separate database instances, or a single database if you selected “simple” or “express” deployment). These are alluded to in section 2.1.3 of the operations guide, but not really in much detail. Basically the types of data stored are:

  • The core CR storage database (defined in /marc.hi.ehrs.cr.persistence.data/connectionManager element)
  • Patient demographics information (name, dob, gender, etc.)
  • Registration event information (in v2 the MSH/EVN segments, v3 the transport/controlAct wrapper and FHIR the best mapping available for those elements)
  • Relationship to non-patient persons (mother, father, etc.)
  • This supports configuration of primary>secondary PostgreSQL streaming replication for large datasets via a write-only primary/read-only secondary(ies). This is really only needed for really really big datasets, or cases where you have lots of application servers or a high number of concurrent clients slamming the CR. For example, the eHealth Ontario innovation lab instance has 1.4 million fake patients and it doesn’t even need this type of deployment (as the response times for queries is still less than 1.2 sec with about 6-8 concurrent sessions).
  • The query tracking database (defined in /marc.ehrs.qm.persistence.data/connectionManager element)
  • Query state information used for query continuation.
  • This is how the V2 RCP segment, the v3 queryId/QUQI_IN100003UV or FHIR _stateId works)
  • The server runs the query once and stores the results, the client can then quickly page through the results in the query set without having the server re-execute the query
  • The message tracking database (defined in /marc.hi.ehrs.svc.messaging.persistence/connectionManager element)
  • Message execution information (exec-once, cached response data, etc.)
  • This is where the CR makes the determination if a message has already been processed in the case of client retry messages. It is triggered off of the MSH-10 field in v2 or the /PRPAXXXX/id element in v3.
  • It is the reason why if you execute a message and then just resend the exact same message without giving it a new message identifier the message is not actually executed.
  • Code reference database (defined in /marc.hi.ehrs…svc.terminology/qdcdb element, you can also use a CTS 1 based server in lieu of this)
  • Provides a basic set of code lookups for things like languages, etc.
    Hope that helps!

Cheers

-Justin

On Tuesday, January 24, 2017 at 11:34:03 AM UTC-5, Chandler, Dean wrote:

Hi Ryan,

             Thanks for the feedback.  So does MedicCR store the data for the client or just the transaction info in the local postgresql database?  Looks

like I need more info on how the big picture works here. Let me know how your testing goes and any additional pointers to related documentation.

Dean…

From: Ryan Crichton [mailto:ry...@jembi.org]
Sent: Tuesday, January 24, 2017 3:22 AM
To: Chandler, Dean dcha...@path.org; Shaun Grannis sgra...@gmail.com
Cc: Interoperability Layer (OpenHIE) openhie-interoperability-layer@googlegroups.com
Subject: Re: OpenHIE client registry setup

Hi Dean,

From what I understand of MedicCR it seems that the admin interface is a soap-based web service interface rather than a user interface. I got the same thing that you are getting. At least that is how the configurator made it sound, I could
be wrong. I think all the configuration is done through the configurator app. Can anyone of this list verify this?

Cheers,

Ryan

On Tue, Jan 24, 2017 at 12:29 AM Chandler, Dean dcha...@path.org wrote:

Hi Ryan,

             Thanks for the pointers.  I keep running into an issue with

either set of instructions that is preventing me from running the Admin interface at the following url.

http://127.0.0.1:9999/admin .
Any ideas as to why this issue keeps coming up.

Thanks,

            Dean..

From:
Ryan Crichton [mailto:ry...@jembi.org]
Sent: Sunday, January 22, 2017 11:47 PM
To: Chandler, Dean dcha...@path.org; Shaun Grannis sgra...@gmail.com

Cc: Interoperability Layer (OpenHIE) openhie-interoperability-layer@googlegroups.com
Subject: Re: OpenHIE client registry setup

Hi Dean,

We at Jembi have also been working on setting up an OpenHIE demo which includes MedicCR as the client registry.

We followed this guide to get the server configured - https://mediccr.codeplex.com/wikipage?title=Single%20Server%20Deployment&referringTitle=Documentation

I then used the MedicCR configurator to enable both the FHIR endpoints and the PIX/PDQ endpoints. To get these messages to be passed through the OpenHIM you will need to create
channels in the OpenHIM that forwards requests that you send to the OpenHIM to MedicCR. You can find some documentation on setting up channels in the OpenHIM docs - http://openhim.readthedocs.io/en/latest/user-guide/basic-config.html We
also have some OpenHIM tutorials if you want a better understanding of how it works - http://openhim.readthedocs.io/en/latest/tutorial/index.html

We are also still getting our demo configuration right and may be able to provide more help as we get further in doing this ourselves.

Cheers,

Ryan

On Wed, Jan 18, 2017 at 12:49 AM Chandler, Dean dcha...@path.org wrote:

Medic CR

Get
Outlook for Android

From: Shaun Grannis

Sent: Tuesday, January 17, 2:46 PM

Subject: Re: OpenHIE client registry setup

To: Chandler, Dean

Cc: Interoperability Layer (OpenHIE)

Dean,

Are you considering MEDIC-CR (“Mohawk CR” in the document you reference), or OpenEMPI?

Thanks,

Shaun


Shaun J. Grannis, MD MS FACMI FAAFP

Biomedical Research Scientist, The Regenstrief Institute

Associate Professor, I.U. School of Medicine

410 West 10th Street, Suite 2000

Indianapolis, IN 46202

(317) 274-9092 (Office)

(317) 274-9305 (Fax)

On Tue, Jan 17, 2017 at 4:20 PM, Chandler, Dean dcha...@path.org wrote:

HI Shaun,

             Thanks for getting back to me.  I am trying to follow the OpenHIE install doc see link below so I can enable some of the v1.0 workflow. I have pretty

much installed everything except the CR services so OpenHIM, OpenSHR, OpenMRS, and OpenInfoMan. My hope is to be able to show the performance/scalability for the interop between the OpenHIM and the CR using latest FHIR implementation. I am very new to
eHealth so any feedback or pointers would be really appreciated.

Dean…

https://wiki.ohie.org/display/resources/How+to+install+OpenHIE+1.0

From: Shaun Grannis [mailto:sgra...@gmail.com]
Sent: Tuesday, January 17, 2017 1:12 PM
To: Chandler, Dean dcha...@path.org
Cc: Interoperability Layer (OpenHIE) openhie-interoperability-layer@googlegroups.com
Subject: Re: OpenHIE client registry setup

Hi Dean,

Thanks for reaching out. Two key elements here are configuring the OpenHIM and selection of a CR/MPI system. The implementation process will depend in part on your
choice of MPI. Can you say what your anticipated software components will be?

Best,

Shaun


Shaun J. Grannis, MD MS FACMI FAAFP

Biomedical Research Scientist, The Regenstrief Institute

Associate Professor, I.U. School of Medicine

410 West 10th Street, Suite 2000

Indianapolis, IN 46202

(317) 274-9092 (Office)

(317) 274-9305 (Fax)

On Tue, Jan 17, 2017 at 1:58 PM, dcha...@path.org wrote:

HI all,

I am trying to setup a connection to a client registry from OpenHIM and would appreciate any help in understanding whether there are existing test registry I can use or if I should setup one. I am trying to get an OpenHIE integration
setup on AWS instances for test/performance purposes and would like to mimic the OpenHIE workflow 1.0 eventually using the new FHIR mechanisms hopefully getting release early this year. Apologies if this is the wrong group for this. Please let me know.

Thanks,

Dean…

You received this message because you are subscribed to the Google Groups “Interoperability Layer (OpenHIE)” group.

To unsubscribe from this group and stop receiving emails from it, send an email to

openhie-interoperability-layer+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 “Interoperability Layer (OpenHIE)” group.
To unsubscribe from this group and stop receiving emails from it, send an email to

openhie-interoperability-layer+unsubscribe@googlegroups.com.
For more options, visit
https://groups.google.com/d/optout
.

Ryan Crichton

Lead Developer, Jembi Health Systems | SOUTH AFRICA

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

Ryan Crichton

Lead Developer, Jembi Health Systems | SOUTH AFRICA

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

Hi Justin,

Thanks for getting back to me I know you guys are very busy. Please do forward your examples of the config files and any further documentation
on how MedicCR communicates with HIE components I have setup like OpenSHR and HIIM.

I believe Mohawk also supports the OSCAR demo see link below. Does this demo use the MedicCR or some other service to share patient
data. If it does it would be great if I can replicate it on Path’s AWS instances I have setup for performance testing.

https://wiki.ohie.org/display/resources/OpenHIE+Demo

Also will the new Mohawk components your team is working on be managed by a tool similar to the MedicCR configuration tool? Please let us know.

Thanks,

Dean…

···

Oh, I also forgot one additional point.

Once you have your demonstration instance setup, you can share the ClientRegistry.exe.config files with others to replicate the configuration settings across machines/deployments. I may have a few lying around from the various demos we’ve
done in the past which we can share. The only real thing that needs to change are the OIDs and database connection strings of course.

Cheers

-Justin

On Tuesday, January 24, 2017 at 3:06:32 PM UTC-5, Justin (Mohawk College) wrote:

Hi all, thought I would chime in (apparently I wasn’t subscribed to this group apparently, thanks to Derek for bringing this thread to my attention).

The administration interface is indeed a soap based service to which the administration tool connects. The administration tool setup under the bundled installer can be a little bit obtuse to setup, but basically you have to ensure that
the web.config file for the admin tool has the same bindings as the configuration for the client registry itself. The administrative interface is bundled with installer and should be in C:\Program Files (x86)\Mohawk College\Client Registry\admin, setup instructions
are (at a basic level):

  1. Install IIS with ASP.NET MVC framework 4 or higher
  1. Create a virtual application which points to the C:\Program Files (x86)\Mohawk College\Client Registry\admin directory
  1. Give the IUSR account (or whatever application pool user IIS is using) read/execute access to that directory
  1. Ensure that C:\Program Files (x86)\Mohawk College\Client Registry\admin\web.config matches the service contract for C:\Program Files (x86)\Mohawk College\Client Registry\ClientRegistry.exe.config.

There may be packaging issue whereby the IIS server will complain about a missing System.Web.Http.dll assembly (it used to be packaged in some
ASP.NET MVC installers). If you encounter this, the easiest way to get around it is to hunt down a copy on your machine, or use the 1.2 version installer (which isn’t released yet, it is the version being deployed
in Myanmar).

As per the configuration itself, the configuration tool is really just a more user friendly wrapper for the XML based configuration file. You can hand edit the configuration file ClientRegistry.exe.config if you’re comfortable with it,
and it does provide additional configuration options. Most of the options for transport/security/etc. are standard .NET WCF configuration options (https://msdn.microsoft.com/en-us/library/ms733932(v=vs.110).aspx )
however, for most scenarios the UI wraps this complexity sufficiently. I usually use the GUI to get up and running and then hand-edit the XML. The configuration tool shouldn’t mind hand edited config settings and typically leaves them alone (it also makes
a backup).

Regarding the question about what the CR stores. The client registry stores various types of data in the data structures it creates (in either separate database instances, or a single database if you selected “simple” or “express” deployment). These
are alluded to in section 2.1.3 of the operations guide, but not really in much detail. Basically the types of data stored are:

  • The core CR storage database (defined in /marc.hi.ehrs.cr.persistence.data/connectionManager element)
  • Patient demographics information (name, dob, gender, etc.)
  • Registration event information (in v2 the MSH/EVN segments, v3 the transport/controlAct wrapper and FHIR the best mapping available for those elements)
  • Relationship to non-patient persons (mother, father, etc.)
  • This supports configuration of primary>secondary PostgreSQL streaming replication for large datasets via a write-only primary/read-only secondary(ies). This is really only needed for really really big datasets, or cases where you have lots of application servers
    or a high number of concurrent clients slamming the CR. For example, the eHealth Ontario innovation lab instance has 1.4 million fake patients and it doesn’t even need this type of deployment (as the response times for queries is still less than 1.2 sec with
    about 6-8 concurrent sessions).
  • The query tracking database (defined in /marc.ehrs.qm.persistence.data/connectionManager element)
  • Query state information used for query continuation.
  • This is how the V2 RCP segment, the v3 queryId/QUQI_IN100003UV or FHIR _stateId works)
  • The server runs the query once and stores the results, the client can then quickly page through the results in the query set without having the server re-execute the query
  • The message tracking database (defined in /marc.hi.ehrs.svc.messaging.persistence/connectionManager element)
  • Message execution information (exec-once, cached response data, etc.)
  • This is where the CR makes the determination if a message has already been processed in the case of client retry messages. It is triggered off of the MSH-10 field in v2 or the /PRPAXXXX/id element in v3.
  • It is the reason why if you execute a message and then just resend the exact same message without giving it a new message identifier the message is not actually executed.
  • Code reference database (defined in /marc.hi.ehrs…svc.terminology/qdcdb element, you can also use a CTS 1 based server in lieu of this)
  • Provides a basic set of code lookups for things like languages, etc.

Hope that helps!

Cheers

-Justin

On Tuesday, January 24, 2017 at 11:34:03 AM UTC-5, Chandler, Dean wrote:

Hi Ryan,

             Thanks for the feedback.  So does MedicCR store the data for the client or just the

transaction info in the local postgresql database? Looks like I need more info on how the big picture works here. Let me know how your testing goes and any additional pointers to related documentation.

Dean…

From: Ryan Crichton [mailto:ry...@jembi.org]
Sent: Tuesday, January 24, 2017 3:22 AM
To: Chandler, Dean dcha...@path.org; Shaun Grannis sgra...@gmail.com
Cc: Interoperability Layer (OpenHIE) openhie-interoperability-layer@googlegroups.com
Subject: Re: OpenHIE client registry setup

Hi Dean,

From what I understand of MedicCR it seems that the admin interface is a soap-based web service interface rather than a user interface. I got the same thing that you are getting.
At least that is how the configurator made it sound, I could be wrong. I think all the configuration is done through the configurator app. Can anyone of this list verify this?

Cheers,

Ryan

On Tue, Jan 24, 2017 at 12:29 AM Chandler, Dean dcha...@path.org wrote:

Hi Ryan,

             Thanks for the pointers.  I keep running into an issue with either set of instructions

that is preventing me from running the Admin interface at the following url.

http://127.0.0.1:9999/admin . Any ideas as
to why this issue keeps coming up.

Thanks,

            Dean..

From: Ryan Crichton [mailto:ry...@jembi.org]
Sent: Sunday, January 22, 2017 11:47 PM
To: Chandler, Dean dcha...@path.org; Shaun Grannis sgra...@gmail.com

Cc: Interoperability Layer (OpenHIE) openhie-interoperability-layer@googlegroups.com
Subject: Re: OpenHIE client registry setup

Hi Dean,

We at Jembi have also been working on setting up an OpenHIE demo which includes MedicCR as the client registry.

We followed this guide to get the server configured - https://mediccr.codeplex.com/wikipage?title=Single%20Server%20Deployment&referringTitle=Documentation

I then used the MedicCR configurator to enable both the FHIR endpoints and the PIX/PDQ endpoints. To get these messages to be passed through the OpenHIM you will need to create
channels in the OpenHIM that forwards requests that you send to the OpenHIM to MedicCR. You can find some documentation on setting up channels in the OpenHIM docs - http://openhim.readthedocs.io/en/latest/user-guide/basic-config.html We
also have some OpenHIM tutorials if you want a better understanding of how it works - http://openhim.readthedocs.io/en/latest/tutorial/index.html

We are also still getting our demo configuration right and may be able to provide more help as we get further in doing this ourselves.

Cheers,

Ryan

On Wed, Jan 18, 2017 at 12:49 AM Chandler, Dean dcha...@path.org wrote:

Medic CR

Get
Outlook for Android

From: Shaun Grannis

Sent: Tuesday, January 17, 2:46 PM

Subject: Re: OpenHIE client registry setup

To: Chandler, Dean

Cc: Interoperability Layer (OpenHIE)

Dean,

Are you considering MEDIC-CR (“Mohawk CR” in the document you reference), or OpenEMPI?

Thanks,

Shaun


Shaun J. Grannis, MD MS FACMI FAAFP

Biomedical Research Scientist, The Regenstrief Institute

Associate Professor, I.U. School of Medicine

410 West 10th Street, Suite 2000

Indianapolis, IN 46202

(317) 274-9092 (Office)

(317) 274-9305 (Fax)

On Tue, Jan 17, 2017 at 4:20 PM, Chandler, Dean dcha...@path.org wrote:

HI Shaun,

             Thanks for getting back to me.  I am trying to follow the OpenHIE install doc see link below so I can enable some of

the v1.0 workflow. I have pretty much installed everything except the CR services so OpenHIM, OpenSHR, OpenMRS, and OpenInfoMan. My hope is to be able to show the performance/scalability for the interop between the OpenHIM and the CR using latest FHIR implementation.
I am very new to eHealth so any feedback or pointers would be really appreciated.

Dean…

https://wiki.ohie.org/display/resources/How+to+install+OpenHIE+1.0

From: Shaun Grannis [mailto:sgra...@gmail.com]
Sent: Tuesday, January 17, 2017 1:12 PM
To: Chandler, Dean dcha...@path.org
Cc: Interoperability Layer (OpenHIE) openhie-interoperability-layer@googlegroups.com
Subject: Re: OpenHIE client registry setup

Hi Dean,

Thanks for reaching out. Two key elements here are configuring the OpenHIM and selection of a CR/MPI system. The implementation process
will depend in part on your choice of MPI. Can you say what your anticipated software components will be?

Best,

Shaun


Shaun J. Grannis, MD MS FACMI FAAFP

Biomedical Research Scientist, The Regenstrief Institute

Associate Professor, I.U. School of Medicine

410 West 10th Street, Suite 2000

Indianapolis, IN 46202

(317) 274-9092 (Office)

(317) 274-9305 (Fax)

On Tue, Jan 17, 2017 at 1:58 PM, dcha...@path.org wrote:

HI all,

I am trying to setup a connection to a client registry from OpenHIM and would appreciate any help in understanding whether there are existing test registry I can use or if I should setup one. I am trying to get an OpenHIE integration setup on AWS instances
for test/performance purposes and would like to mimic the OpenHIE workflow 1.0 eventually using the new FHIR mechanisms hopefully getting release early this year. Apologies if this is the wrong group for this. Please let me know.

Thanks,

Dean…

You received this message because you are subscribed to the Google Groups “Interoperability Layer (OpenHIE)” group.

To unsubscribe from this group and stop receiving emails from it, send an email to
openhie-interoperability-layer+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 “Interoperability Layer (OpenHIE)” group.
To unsubscribe from this group and stop receiving emails from it, send an email to
openhie-interoperability-layer+unsubscribe@googlegroups.com.
For more options, visit
https://groups.google.com/d/optout
.

Ryan Crichton

Lead Developer, Jembi Health Systems | SOUTH AFRICA

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

Ryan Crichton

Lead Developer, Jembi Health Systems | SOUTH AFRICA

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

Hi Dean,

I will send the configuration file for the test instance cr.marc-hi.ca (scrubbing database passwords of course), as well as the web.config in a direct
instance. For some reason it feels like a security breach to be sharing configuration files for live services in a public thread
J .

We do support OSCAR, as a matter of fact there are about a dozen patient identity source systems we’ve tested the CR with, the two major open source
EMRs are OpenMRS and OSCAR. Both OpenMRS and OSCAR can be configured to participate in an IHE Affinity Domain (an OpenHIE is one style of deploying an affinity domain, basically you just point the PIX, XDS, and ATNA client at the HIM instead of directly).
Setting OSCAR up can be, an adventure, so I would recommend using OpenMRS if you have a choice.

If you’re interested in performance testing, we can certainly provide guidance on tuning and how to best batch import test patient datasets. For
large synchronization or registration tests, we find the streaming LLP option to be the fastest option (whereby a client opens a single socket to the CR and sends a stream of ADT messages to the CR). For query performance testing, HL7v2 is again the fastest
interface but the v3 and FHIR interfaces just as well. One note though, if you’re running the TCP or LLP connector through the HIM, set the timeout on the client registry to 0 so it doesn’t keep the connection open between itself and the HIM (this will turn
off streaming support but it greatly improves the response times). We also have some tooling for generating large fake (but realistic looking) patient datasets for the CR (it is how we get millions of records into our test instances).

The new version of the MEDIC CR (1.2) is not structurally different than 1.1.2 which is available on the web. There were some major performance enhancements
and cleanup of some of the service core code. As always, there are the XML configuration files as well. We are currently planning a MEDIC CR 2.0 which is quite different and based on our ServiceCore 2 framework (RIM based data model, better privacy & security
controls, better support for business rules authoring, etc.) but that project is still in early planning, and we don’t expect it to hit anytime soon…

Cheers

-Justin

···

From: Chandler, Dean [mailto:dchandler@path.org]
Sent: January 25, 2017 11:58 AM
To: Fyfe, Justin justin.fyfe1@mohawkcollege.ca
Cc: ryan@jembi.org; sgrannis@gmail.com; Taliesin, Brian btaliesin@path.org; Interoperability Layer (OpenHIE) openhie-interoperability-layer@googlegroups.com
Subject: RE: OpenHIE client registry setup

Hi Justin,

Thanks for getting back to me I know you guys are very busy. Please do forward your examples of the config files and any further
documentation on how MedicCR communicates with HIE components I have setup like OpenSHR and HIIM.

I believe Mohawk also supports the OSCAR demo see link below. Does this demo use the MedicCR or some other service to
share patient data. If it does it would be great if I can replicate it on Path’s AWS instances I have setup for performance testing.

https://wiki.ohie.org/display/resources/OpenHIE+Demo

Also will the new Mohawk components your team is working on be managed by a tool similar to the MedicCR configuration tool? Please
let us know.

Thanks,

Dean…

From: Justin (Mohawk College) [mailto:justin.fyfe1@mohawkcollege.ca]
Sent: Tuesday, January 24, 2017 12:16 PM
To: Interoperability Layer (OpenHIE) openhie-interoperability-layer@googlegroups.com
Cc: ryan@jembi.org;
sgrannis@gmail.com; Chandler, Dean dchandler@path.org
Subject: Re: OpenHIE client registry setup

Oh, I also forgot one additional point.

Once you have your demonstration instance setup, you can share the ClientRegistry.exe.config files with others to replicate the configuration settings across machines/deployments. I may have a few lying around from the
various demos we’ve done in the past which we can share. The only real thing that needs to change are the OIDs and database connection strings of course.

Cheers

-Justin

On Tuesday, January 24, 2017 at 3:06:32 PM UTC-5, Justin (Mohawk College) wrote:

Hi all, thought I would chime in (apparently I wasn’t subscribed to this group apparently, thanks to Derek for bringing this thread to my attention).

The administration interface is indeed a soap based service to which the administration tool connects. The administration tool setup under the bundled installer can be a little bit obtuse to setup, but basically you have
to ensure that the web.config file for the admin tool has the same bindings as the configuration for the client registry itself. The administrative interface is bundled with installer and should be in C:\Program Files (x86)\Mohawk College\Client Registry\admin,
setup instructions are (at a basic level):

  1. Install IIS with ASP.NET MVC framework 4 or higher
  1. Create a virtual application which points to the C:\Program Files (x86)\Mohawk College\Client Registry\admin directory
  1. Give the IUSR account (or whatever application pool user IIS is using) read/execute access to that directory
  1. Ensure that C:\Program Files (x86)\Mohawk College\Client Registry\admin\web.config matches the service contract for C:\Program Files (x86)\Mohawk College\Client Registry\ClientRegistry.exe.config.

There may be packaging issue whereby the IIS server will complain about a missing System.Web.Http.dll assembly (it used to be packaged in some
ASP.NET MVC installers). If you encounter this, the easiest way to get around it is to hunt down a copy on your machine, or use the 1.2 version installer (which isn’t released yet, it is the version being deployed
in Myanmar).

As per the configuration itself, the configuration tool is really just a more user friendly wrapper for the XML based configuration file. You can hand edit the configuration file ClientRegistry.exe.config if you’re comfortable
with it, and it does provide additional configuration options. Most of the options for transport/security/etc. are standard .NET WCF configuration options (https://msdn.microsoft.com/en-us/library/ms733932(v=vs.110).aspx )
however, for most scenarios the UI wraps this complexity sufficiently. I usually use the GUI to get up and running and then hand-edit the XML. The configuration tool shouldn’t mind hand edited config settings and typically leaves them alone (it also makes
a backup).

Regarding the question about what the CR stores. The client registry stores various types of data in the data structures it creates (in either separate database instances, or a single database if you selected “simple”
or “express” deployment). These are alluded to in section 2.1.3 of the operations guide, but not really in much detail. Basically the types of data stored are:

  • The core CR storage database (defined in /marc.hi.ehrs.cr.persistence.data/connectionManager element)
  • Patient demographics information (name, dob, gender, etc.)
  • Registration event information (in v2 the MSH/EVN segments, v3 the transport/controlAct wrapper and FHIR the best mapping available for those elements)
  • Relationship to non-patient persons (mother, father, etc.)
  • This supports configuration of primary>secondary PostgreSQL streaming replication for large datasets via a write-only primary/read-only secondary(ies). This is really only needed for really really big datasets, or cases where you have lots
    of application servers or a high number of concurrent clients slamming the CR. For example, the eHealth Ontario innovation lab instance has 1.4 million fake patients and it doesn’t even need this type of deployment (as the response times for queries is still
    less than 1.2 sec with about 6-8 concurrent sessions).
  • The query tracking database (defined in /marc.ehrs.qm.persistence.data/connectionManager element)
  • Query state information used for query continuation.
  • This is how the V2 RCP segment, the v3 queryId/QUQI_IN100003UV or FHIR _stateId works)
  • The server runs the query once and stores the results, the client can then quickly page through the results in the query set without having the server re-execute the query
  • The message tracking database (defined in /marc.hi.ehrs.svc.messaging.persistence/connectionManager element)
  • Message execution information (exec-once, cached response data, etc.)
  • This is where the CR makes the determination if a message has already been processed in the case of client retry messages. It is triggered off of the MSH-10 field in v2 or the /PRPAXXXX/id element in v3.
  • It is the reason why if you execute a message and then just resend the exact same message without giving it a new message identifier the message is not actually executed.
  • Code reference database (defined in /marc.hi.ehrs…svc.terminology/qdcdb element, you can also use a CTS 1 based server in lieu of this)
  • Provides a basic set of code lookups for things like languages, etc.

Hope that helps!

Cheers

-Justin

On Tuesday, January 24, 2017 at 11:34:03 AM UTC-5, Chandler, Dean wrote:

Hi Ryan,

             Thanks for the feedback.  So does MedicCR store the data for the client

or just the transaction info in the local postgresql database? Looks like I need more info on how the big picture works here. Let me know how your testing goes and any additional pointers to related documentation.

Dean…

From: Ryan
Crichton [mailto:ry...@jembi.org]
Sent: Tuesday, January 24, 2017 3:22 AM
To: Chandler, Dean dcha...@path.org; Shaun Grannis sgra...@gmail.com
Cc: Interoperability Layer (OpenHIE) openhie-interoperability-layer@googlegroups.com
Subject: Re: OpenHIE client registry setup

Hi Dean,

From what I understand of MedicCR it seems that the admin interface is a soap-based web service interface rather than a user interface. I got the same thing that
you are getting. At least that is how the configurator made it sound, I could be wrong. I think all the configuration is done through the configurator app. Can anyone of this list verify this?

Cheers,

Ryan

On Tue, Jan 24, 2017 at 12:29 AM Chandler, Dean dcha...@path.org wrote:

Hi Ryan,

             Thanks for the pointers.  I keep running into an issue with either set

of instructions that is preventing me from running the Admin interface at the following url.

http://127.0.0.1:9999/admin .
Any ideas as to why this issue keeps coming up.

Thanks,

            Dean..

From: Ryan
Crichton [mailto:ry...@jembi.org]
Sent: Sunday, January 22, 2017 11:47 PM
To: Chandler, Dean dcha...@path.org; Shaun Grannis sgra...@gmail.com

Cc: Interoperability Layer (OpenHIE) openhie-interoperability-layer@googlegroups.com
Subject: Re: OpenHIE client registry setup

Hi Dean,

We at Jembi have also been working on setting up an OpenHIE demo which includes MedicCR as the client registry.

We followed this guide to get the server configured - https://mediccr.codeplex.com/wikipage?title=Single%20Server%20Deployment&referringTitle=Documentation

I then used the MedicCR configurator to enable both the FHIR endpoints and the PIX/PDQ endpoints. To get these messages to be passed through the OpenHIM you will
need to create channels in the OpenHIM that forwards requests that you send to the OpenHIM to MedicCR. You can find some documentation on setting up channels in the OpenHIM docs - http://openhim.readthedocs.io/en/latest/user-guide/basic-config.html We
also have some OpenHIM tutorials if you want a better understanding of how it works - http://openhim.readthedocs.io/en/latest/tutorial/index.html

We are also still getting our demo configuration right and may be able to provide more help as we get further in doing this ourselves.

Cheers,

Ryan

On Wed, Jan 18, 2017 at 12:49 AM Chandler, Dean dcha...@path.org wrote:

Medic CR

Get
Outlook for Android

From: Shaun Grannis

Sent: Tuesday, January 17, 2:46 PM

Subject: Re: OpenHIE client registry setup

To: Chandler, Dean

Cc: Interoperability Layer (OpenHIE)

Dean,

Are you considering MEDIC-CR (“Mohawk CR” in the document you reference), or OpenEMPI?

Thanks,

Shaun


Shaun J. Grannis, MD MS FACMI FAAFP

Biomedical Research Scientist, The Regenstrief Institute

Associate Professor, I.U. School of Medicine

410 West 10th Street, Suite 2000

Indianapolis, IN 46202

(317) 274-9092 (Office)

(317) 274-9305 (Fax)

On Tue, Jan 17, 2017 at 4:20 PM, Chandler, Dean dcha...@path.org wrote:

HI Shaun,

             Thanks for getting back to me.  I am trying to follow the OpenHIE install doc see link below so I can enable

some of the v1.0 workflow. I have pretty much installed everything except the CR services so OpenHIM, OpenSHR, OpenMRS, and OpenInfoMan. My hope is to be able to show the performance/scalability for the interop between the OpenHIM and the CR using latest
FHIR implementation. I am very new to eHealth so any feedback or pointers would be really appreciated.

Dean…

https://wiki.ohie.org/display/resources/How+to+install+OpenHIE+1.0

From: Shaun Grannis
[mailto:sgra...@gmail.com]
Sent: Tuesday, January 17, 2017 1:12 PM
To: Chandler, Dean dcha...@path.org
Cc: Interoperability Layer (OpenHIE) openhie-interoperability-layer@googlegroups.com
Subject: Re: OpenHIE client registry setup

Hi Dean,

Thanks for reaching out. Two key elements here are configuring the OpenHIM and selection of a CR/MPI system. The implementation
process will depend in part on your choice of MPI. Can you say what your anticipated software components will be?

Best,

Shaun


Shaun J. Grannis, MD MS FACMI FAAFP

Biomedical Research Scientist, The Regenstrief Institute

Associate Professor, I.U. School of Medicine

410 West 10th Street, Suite 2000

Indianapolis, IN 46202

(317) 274-9092 (Office)

(317) 274-9305 (Fax)

On Tue, Jan 17, 2017 at 1:58 PM, dcha...@path.org wrote:

HI all,

I am trying to setup a connection to a client registry from OpenHIM and would appreciate any help in understanding whether there are existing test registry I can use or if I should setup one. I am trying to get an OpenHIE integration setup on AWS instances
for test/performance purposes and would like to mimic the OpenHIE workflow 1.0 eventually using the new FHIR mechanisms hopefully getting release early this year. Apologies if this is the wrong group for this. Please let me know.

Thanks,

Dean…

You received this message because you are subscribed to the Google Groups “Interoperability Layer (OpenHIE)” group.

To unsubscribe from this group and stop receiving emails from it, send an email to
openhie-interoperability-layer+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 “Interoperability Layer (OpenHIE)” group.
To unsubscribe from this group and stop receiving emails from it, send an email to
openhie-interoperability-layer+unsubscribe@googlegroups.com.
For more options, visit
https://groups.google.com/d/optout
.

Ryan Crichton

Lead Developer, Jembi Health Systems | SOUTH AFRICA

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

Ryan Crichton

Lead Developer, Jembi Health Systems | SOUTH AFRICA

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

Woops, I forgot to answer the second part of your first question.

In terms of communicating with other components like the SHR, the CR supports PUSH notifications. These are configured under the PIXv3 notifications
panel (originally it only supported PIXv3). This allows the CR to notify other HIE components in real time when new patients are registered, updated, or merged.

Basically you set up a notification target based on which identity domain/authority you’d like a notification triggered…

image001.png

There are four options:

  • ITI-10 or PAT_ID_X_REF_MGR PIX update notification (the CR will send ADT^A31 messages to
    a recipient)

  • ITI-8 or PAT_IDENTITY_SRC notification (the CR will send either ADT^A01, ADT^A08 or ADT^A40
    messages based on how a record was created/updated/merged)

  • ITI-44 or PAT_IDENTITY_SRC_HL7v3 notification which is the same as ITI-8 only in v3 instead
    of v2 (PRPA_IN201301/PRPA_IN201302 and PRPA_IN201304)

  • ITI-46 or PAT_ID_X_REF_MGR_HL7v3 which is the same as ITI-10 only in v3 instead of v2 (PRPA_IN201302)

Once you configure this the CR will start pushing notifications to the target machine for any new registration event which occurs.

Cheers

-Justin

···

From: Chandler, Dean [mailto:dchandler@path.org]
Sent: January 25, 2017 11:58 AM
To: Fyfe, Justin justin.fyfe1@mohawkcollege.ca
Cc: ryan@jembi.org; sgrannis@gmail.com; Taliesin, Brian btaliesin@path.org; Interoperability Layer (OpenHIE) openhie-interoperability-layer@googlegroups.com
Subject: RE: OpenHIE client registry setup

Hi Justin,

Thanks for getting back to me I know you guys are very busy. Please do forward your examples of the config files and any further
documentation on how MedicCR communicates with HIE components I have setup like OpenSHR and HIIM.

I believe Mohawk also supports the OSCAR demo see link below. Does this demo use the MedicCR or some other service to
share patient data. If it does it would be great if I can replicate it on Path’s AWS instances I have setup for performance testing.

https://wiki.ohie.org/display/resources/OpenHIE+Demo

Also will the new Mohawk components your team is working on be managed by a tool similar to the MedicCR configuration tool? Please
let us know.

Thanks,

Dean…

From: Justin (Mohawk College) [mailto:justin.fyfe1@mohawkcollege.ca]
Sent: Tuesday, January 24, 2017 12:16 PM
To: Interoperability Layer (OpenHIE) openhie-interoperability-layer@googlegroups.com
Cc: ryan@jembi.org;
sgrannis@gmail.com; Chandler, Dean dchandler@path.org
Subject: Re: OpenHIE client registry setup

Oh, I also forgot one additional point.

Once you have your demonstration instance setup, you can share the ClientRegistry.exe.config files with others to replicate the configuration settings across machines/deployments. I may have a few lying around from the
various demos we’ve done in the past which we can share. The only real thing that needs to change are the OIDs and database connection strings of course.

Cheers

-Justin

On Tuesday, January 24, 2017 at 3:06:32 PM UTC-5, Justin (Mohawk College) wrote:

Hi all, thought I would chime in (apparently I wasn’t subscribed to this group apparently, thanks to Derek for bringing this thread to my attention).

The administration interface is indeed a soap based service to which the administration tool connects. The administration tool setup under the bundled installer can be a little bit obtuse to setup, but basically you have
to ensure that the web.config file for the admin tool has the same bindings as the configuration for the client registry itself. The administrative interface is bundled with installer and should be in C:\Program Files (x86)\Mohawk College\Client Registry\admin,
setup instructions are (at a basic level):

  1. Install IIS with ASP.NET MVC framework 4 or higher
  1. Create a virtual application which points to the C:\Program Files (x86)\Mohawk College\Client Registry\admin directory
  1. Give the IUSR account (or whatever application pool user IIS is using) read/execute access to that directory
  1. Ensure that C:\Program Files (x86)\Mohawk College\Client Registry\admin\web.config matches the service contract for C:\Program Files (x86)\Mohawk College\Client Registry\ClientRegistry.exe.config.

There may be packaging issue whereby the IIS server will complain about a missing System.Web.Http.dll assembly (it used to be packaged in some
ASP.NET MVC installers). If you encounter this, the easiest way to get around it is to hunt down a copy on your machine, or use the 1.2 version installer (which isn’t released yet, it is the version being deployed
in Myanmar).

As per the configuration itself, the configuration tool is really just a more user friendly wrapper for the XML based configuration file. You can hand edit the configuration file ClientRegistry.exe.config if you’re comfortable
with it, and it does provide additional configuration options. Most of the options for transport/security/etc. are standard .NET WCF configuration options (https://msdn.microsoft.com/en-us/library/ms733932(v=vs.110).aspx )
however, for most scenarios the UI wraps this complexity sufficiently. I usually use the GUI to get up and running and then hand-edit the XML. The configuration tool shouldn’t mind hand edited config settings and typically leaves them alone (it also makes
a backup).

Regarding the question about what the CR stores. The client registry stores various types of data in the data structures it creates (in either separate database instances, or a single database if you selected “simple”
or “express” deployment). These are alluded to in section 2.1.3 of the operations guide, but not really in much detail. Basically the types of data stored are:

  • The core CR storage database (defined in /marc.hi.ehrs.cr.persistence.data/connectionManager element)
  • Patient demographics information (name, dob, gender, etc.)
  • Registration event information (in v2 the MSH/EVN segments, v3 the transport/controlAct wrapper and FHIR the best mapping available for those elements)
  • Relationship to non-patient persons (mother, father, etc.)
  • This supports configuration of primary>secondary PostgreSQL streaming replication for large datasets via a write-only primary/read-only secondary(ies). This is really only needed for really really big datasets, or cases where you have lots
    of application servers or a high number of concurrent clients slamming the CR. For example, the eHealth Ontario innovation lab instance has 1.4 million fake patients and it doesn’t even need this type of deployment (as the response times for queries is still
    less than 1.2 sec with about 6-8 concurrent sessions).
  • The query tracking database (defined in /marc.ehrs.qm.persistence.data/connectionManager element)
  • Query state information used for query continuation.
  • This is how the V2 RCP segment, the v3 queryId/QUQI_IN100003UV or FHIR _stateId works)
  • The server runs the query once and stores the results, the client can then quickly page through the results in the query set without having the server re-execute the query
  • The message tracking database (defined in /marc.hi.ehrs.svc.messaging.persistence/connectionManager element)
  • Message execution information (exec-once, cached response data, etc.)
  • This is where the CR makes the determination if a message has already been processed in the case of client retry messages. It is triggered off of the MSH-10 field in v2 or the /PRPAXXXX/id element in v3.
  • It is the reason why if you execute a message and then just resend the exact same message without giving it a new message identifier the message is not actually executed.
  • Code reference database (defined in /marc.hi.ehrs…svc.terminology/qdcdb element, you can also use a CTS 1 based server in lieu of this)
  • Provides a basic set of code lookups for things like languages, etc.

Hope that helps!

Cheers

-Justin

On Tuesday, January 24, 2017 at 11:34:03 AM UTC-5, Chandler, Dean wrote:

Hi Ryan,

             Thanks for the feedback.  So does MedicCR store the data for the client

or just the transaction info in the local postgresql database? Looks like I need more info on how the big picture works here. Let me know how your testing goes and any additional pointers to related documentation.

Dean…

From: Ryan
Crichton [mailto:ry...@jembi.org]
Sent: Tuesday, January 24, 2017 3:22 AM
To: Chandler, Dean dcha...@path.org; Shaun Grannis sgra...@gmail.com
Cc: Interoperability Layer (OpenHIE) openhie-interoperability-layer@googlegroups.com
Subject: Re: OpenHIE client registry setup

Hi Dean,

From what I understand of MedicCR it seems that the admin interface is a soap-based web service interface rather than a user interface. I got the same thing that
you are getting. At least that is how the configurator made it sound, I could be wrong. I think all the configuration is done through the configurator app. Can anyone of this list verify this?

Cheers,

Ryan

On Tue, Jan 24, 2017 at 12:29 AM Chandler, Dean dcha...@path.org wrote:

Hi Ryan,

             Thanks for the pointers.  I keep running into an issue with either set

of instructions that is preventing me from running the Admin interface at the following url.

http://127.0.0.1:9999/admin .
Any ideas as to why this issue keeps coming up.

Thanks,

            Dean..

From: Ryan
Crichton [mailto:ry...@jembi.org]
Sent: Sunday, January 22, 2017 11:47 PM
To: Chandler, Dean dcha...@path.org; Shaun Grannis sgra...@gmail.com

Cc: Interoperability Layer (OpenHIE) openhie-interoperability-layer@googlegroups.com
Subject: Re: OpenHIE client registry setup

Hi Dean,

We at Jembi have also been working on setting up an OpenHIE demo which includes MedicCR as the client registry.

We followed this guide to get the server configured - https://mediccr.codeplex.com/wikipage?title=Single%20Server%20Deployment&referringTitle=Documentation

I then used the MedicCR configurator to enable both the FHIR endpoints and the PIX/PDQ endpoints. To get these messages to be passed through the OpenHIM you will
need to create channels in the OpenHIM that forwards requests that you send to the OpenHIM to MedicCR. You can find some documentation on setting up channels in the OpenHIM docs - http://openhim.readthedocs.io/en/latest/user-guide/basic-config.html We
also have some OpenHIM tutorials if you want a better understanding of how it works - http://openhim.readthedocs.io/en/latest/tutorial/index.html

We are also still getting our demo configuration right and may be able to provide more help as we get further in doing this ourselves.

Cheers,

Ryan

On Wed, Jan 18, 2017 at 12:49 AM Chandler, Dean dcha...@path.org wrote:

Medic CR

Get
Outlook for Android

From: Shaun Grannis

Sent: Tuesday, January 17, 2:46 PM

Subject: Re: OpenHIE client registry setup

To: Chandler, Dean

Cc: Interoperability Layer (OpenHIE)

Dean,

Are you considering MEDIC-CR (“Mohawk CR” in the document you reference), or OpenEMPI?

Thanks,

Shaun


Shaun J. Grannis, MD MS FACMI FAAFP

Biomedical Research Scientist, The Regenstrief Institute

Associate Professor, I.U. School of Medicine

410 West 10th Street, Suite 2000

Indianapolis, IN 46202

(317) 274-9092 (Office)

(317) 274-9305 (Fax)

On Tue, Jan 17, 2017 at 4:20 PM, Chandler, Dean dcha...@path.org wrote:

HI Shaun,

             Thanks for getting back to me.  I am trying to follow the OpenHIE install doc see link below so I can enable

some of the v1.0 workflow. I have pretty much installed everything except the CR services so OpenHIM, OpenSHR, OpenMRS, and OpenInfoMan. My hope is to be able to show the performance/scalability for the interop between the OpenHIM and the CR using latest
FHIR implementation. I am very new to eHealth so any feedback or pointers would be really appreciated.

Dean…

https://wiki.ohie.org/display/resources/How+to+install+OpenHIE+1.0

From: Shaun Grannis
[mailto:sgra...@gmail.com]
Sent: Tuesday, January 17, 2017 1:12 PM
To: Chandler, Dean dcha...@path.org
Cc: Interoperability Layer (OpenHIE) openhie-interoperability-layer@googlegroups.com
Subject: Re: OpenHIE client registry setup

Hi Dean,

Thanks for reaching out. Two key elements here are configuring the OpenHIM and selection of a CR/MPI system. The implementation
process will depend in part on your choice of MPI. Can you say what your anticipated software components will be?

Best,

Shaun


Shaun J. Grannis, MD MS FACMI FAAFP

Biomedical Research Scientist, The Regenstrief Institute

Associate Professor, I.U. School of Medicine

410 West 10th Street, Suite 2000

Indianapolis, IN 46202

(317) 274-9092 (Office)

(317) 274-9305 (Fax)

On Tue, Jan 17, 2017 at 1:58 PM, dcha...@path.org wrote:

HI all,

I am trying to setup a connection to a client registry from OpenHIM and would appreciate any help in understanding whether there are existing test registry I can use or if I should setup one. I am trying to get an OpenHIE integration setup on AWS instances
for test/performance purposes and would like to mimic the OpenHIE workflow 1.0 eventually using the new FHIR mechanisms hopefully getting release early this year. Apologies if this is the wrong group for this. Please let me know.

Thanks,

Dean…

You received this message because you are subscribed to the Google Groups “Interoperability Layer (OpenHIE)” group.

To unsubscribe from this group and stop receiving emails from it, send an email to
openhie-interoperability-layer+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 “Interoperability Layer (OpenHIE)” group.
To unsubscribe from this group and stop receiving emails from it, send an email to
openhie-interoperability-layer+unsubscribe@googlegroups.com.
For more options, visit
https://groups.google.com/d/optout
.

Ryan Crichton

Lead Developer, Jembi Health Systems | SOUTH AFRICA

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

Ryan Crichton

Lead Developer, Jembi Health Systems | SOUTH AFRICA

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

Hi Justin,
Just curious if you are working on a FHIR equivalent for ITI-8/44 or ITI-10/46 ?
Cheers,
-carl

···

On Jan 25, 2017, at 11:22 PM, Fyfe, Justin <justin.fyfe1@mohawkcollege.ca> wrote:

Woops, I forgot to answer the second part of your first question.

In terms of communicating with other components like the SHR, the CR supports PUSH notifications. These are configured under the PIXv3 notifications panel (originally it only supported PIXv3). This allows the CR to notify other HIE components in real time when new patients are registered, updated, or merged.

Basically you set up a notification target based on which identity domain/authority you’d like a notification triggered…

<image001.png>

There are four options:
ITI-10 or PAT_ID_X_REF_MGR PIX update notification (the CR will send ADT^A31 messages to a recipient)
ITI-8 or PAT_IDENTITY_SRC notification (the CR will send either ADT^A01, ADT^A08 or ADT^A40 messages based on how a record was created/updated/merged)
ITI-44 or PAT_IDENTITY_SRC_HL7v3 notification which is the same as ITI-8 only in v3 instead of v2 (PRPA_IN201301/PRPA_IN201302 and PRPA_IN201304)
ITI-46 or PAT_ID_X_REF_MGR_HL7v3 which is the same as ITI-10 only in v3 instead of v2 (PRPA_IN201302)

Once you configure this the CR will start pushing notifications to the target machine for any new registration event which occurs.

Cheers
-Justin
<>
From: Chandler, Dean [mailto:dchandler@path.org]
Sent: January 25, 2017 11:58 AM
To: Fyfe, Justin <justin.fyfe1@mohawkcollege.ca <mailto:justin.fyfe1@mohawkcollege.ca>>
Cc: ryan@jembi.org <mailto:ryan@jembi.org>; sgrannis@gmail.com <mailto:sgrannis@gmail.com>; Taliesin, Brian <btaliesin@path.org <mailto:btaliesin@path.org>>; Interoperability Layer (OpenHIE) <openhie-interoperability-layer@googlegroups.com <mailto:openhie-interoperability-layer@googlegroups.com>>
Subject: RE: OpenHIE client registry setup

Hi Justin,
                Thanks for getting back to me I know you guys are very busy. Please do forward your examples of the config files and any further documentation on how MedicCR communicates with HIE components I have setup like OpenSHR and HIIM.

I believe Mohawk also supports the OSCAR demo see link below. Does this demo use the MedicCR or some other service to share patient data. If it does it would be great if I can replicate it on Path’s AWS instances I have setup for performance testing.

Log In - OpenHIE Wiki

                Also will the new Mohawk components your team is working on be managed by a tool similar to the MedicCR configuration tool? Please let us know.

Thanks,
                Dean…

From: Justin (Mohawk College) [mailto:justin.fyfe1@mohawkcollege.ca]
Sent: Tuesday, January 24, 2017 12:16 PM
To: Interoperability Layer (OpenHIE) <openhie-interoperability-layer@googlegroups.com <mailto:openhie-interoperability-layer@googlegroups.com>>
Cc: ryan@jembi.org <mailto:ryan@jembi.org>; sgrannis@gmail.com <mailto:sgrannis@gmail.com>; Chandler, Dean <dchandler@path.org <mailto:dchandler@path.org>>
Subject: Re: OpenHIE client registry setup

Oh, I also forgot one additional point.

Once you have your demonstration instance setup, you can share the ClientRegistry.exe.config files with others to replicate the configuration settings across machines/deployments. I may have a few lying around from the various demos we've done in the past which we can share. The only real thing that needs to change are the OIDs and database connection strings of course.

Cheers
-Justin

On Tuesday, January 24, 2017 at 3:06:32 PM UTC-5, Justin (Mohawk College) wrote:
Hi all, thought I would chime in (apparently I wasn't subscribed to this group apparently, thanks to Derek for bringing this thread to my attention).

The administration interface is indeed a soap based service to which the administration tool connects. The administration tool setup under the bundled installer can be a little bit obtuse to setup, but basically you have to ensure that the web.config file for the admin tool has the same bindings as the configuration for the client registry itself. The administrative interface is bundled with installer and should be in C:\Program Files (x86)\Mohawk College\Client Registry\admin, setup instructions are (at a basic level):
Install IIS with ASP.NET <Error: ASP.net | The ASP.NET Site; MVC framework 4 or higher
Create a virtual application which points to the C:\Program Files (x86)\Mohawk College\Client Registry\admin directory
Give the IUSR account (or whatever application pool user IIS is using) read/execute access to that directory
Ensure that C:\Program Files (x86)\Mohawk College\Client Registry\admin\web.config matches the service contract for C:\Program Files (x86)\Mohawk College\Client Registry\ClientRegistry.exe.config.
There may be packaging issue whereby the IIS server will complain about a missing System.Web.Http.dll assembly (it used to be packaged in some ASP.NET <Error: ASP.net | The ASP.NET Site; MVC installers). If you encounter this, the easiest way to get around it is to hunt down a copy on your machine, or use the 1.2 version installer (which isn't released yet, it is the version being deployed in Myanmar).

As per the configuration itself, the configuration tool is really just a more user friendly wrapper for the XML based configuration file. You can hand edit the configuration file ClientRegistry.exe.config if you're comfortable with it, and it does provide additional configuration options. Most of the options for transport/security/etc. are standard .NET WCF configuration options (Configuring Services Using Configuration Files - WCF | Microsoft Learn) however, for most scenarios the UI wraps this complexity sufficiently. I usually use the GUI to get up and running and then hand-edit the XML. The configuration tool shouldn't mind hand edited config settings and typically leaves them alone (it also makes a backup).

Regarding the question about what the CR stores. The client registry stores various types of data in the data structures it creates (in either separate database instances, or a single database if you selected "simple" or "express" deployment). These are alluded to in section 2.1.3 of the operations guide, but not really in much detail. Basically the types of data stored are:

The core CR storage database (defined in /marc.hi.ehrs.cr.persistence.data/connectionManager element)
Patient demographics information (name, dob, gender, etc.)
Registration event information (in v2 the MSH/EVN segments, v3 the transport/controlAct wrapper and FHIR the best mapping available for those elements)
Relationship to non-patient persons (mother, father, etc.)
This supports configuration of primary>secondary PostgreSQL streaming replication for large datasets via a write-only primary/read-only secondary(ies). This is really only needed for really really big datasets, or cases where you have lots of application servers or a high number of concurrent clients slamming the CR. For example, the eHealth Ontario innovation lab instance has 1.4 million fake patients and it doesn't even need this type of deployment (as the response times for queries is still less than 1.2 sec with about 6-8 concurrent sessions).
The query tracking database (defined in /marc.ehrs.qm.persistence.data/connectionManager element)
Query state information used for query continuation.
This is how the V2 RCP segment, the v3 queryId/QUQI_IN100003UV or FHIR _stateId works)
The server runs the query once and stores the results, the client can then quickly page through the results in the query set without having the server re-execute the query
The message tracking database (defined in /marc.hi.ehrs.svc.messaging.persistence/connectionManager element)
Message execution information (exec-once, cached response data, etc.)
This is where the CR makes the determination if a message has already been processed in the case of client retry messages. It is triggered off of the MSH-10 field in v2 or the /PRPAXXXX/id element in v3.
It is the reason why if you execute a message and then just resend the exact same message without giving it a new message identifier the message is not actually executed.
Code reference database (defined in /marc.hi.ehrs..svc.terminology/qdcdb element, you can also use a CTS 1 based server in lieu of this)
Provides a basic set of code lookups for things like languages, etc.
Hope that helps!

Cheers
-Justin

On Tuesday, January 24, 2017 at 11:34:03 AM UTC-5, Chandler, Dean wrote:
Hi Ryan,
                Thanks for the feedback. So does MedicCR store the data for the client or just the transaction info in the local postgresql database? Looks like I need more info on how the big picture works here. Let me know how your testing goes and any additional pointers to related documentation.

Dean..

From: Ryan Crichton [mailto:ry…@jembi.org]
Sent: Tuesday, January 24, 2017 3:22 AM
To: Chandler, Dean <dcha...@path.org <mailto:dcha…@path.org>>; Shaun Grannis <sgra...@gmail.com <mailto:sgra…@gmail.com>>
Cc: Interoperability Layer (OpenHIE) <openhie-interoperability-layer@googlegroups.com <mailto:openhie-interoperability-layer@googlegroups.com>>
Subject: Re: OpenHIE client registry setup

Hi Dean,

From what I understand of MedicCR it seems that the admin interface is a soap-based web service interface rather than a user interface. I got the same thing that you are getting. At least that is how the configurator made it sound, I could be wrong. I think all the configuration is done through the configurator app. Can anyone of this list verify this?

Cheers,
Ryan

On Tue, Jan 24, 2017 at 12:29 AM Chandler, Dean <dcha...@path.org <mailto:dcha…@path.org>> wrote:
Hi Ryan,
                Thanks for the pointers. I keep running into an issue with either set of instructions that is preventing me from running the Admin interface at the following url.

http://127.0.0.1:9999/admin. Any ideas as to why this issue keeps coming up.

Thanks,
                Dean..

<>

From: Ryan Crichton [mailto:ry…@jembi.org]
Sent: Sunday, January 22, 2017 11:47 PM
To: Chandler, Dean <dcha...@path.org <mailto:dcha…@path.org>>; Shaun Grannis <sgra...@gmail.com <mailto:sgra…@gmail.com>>

Cc: Interoperability Layer (OpenHIE) <openhie-interoperability-layer@googlegroups.com <mailto:openhie-interoperability-layer@googlegroups.com>>
Subject: Re: OpenHIE client registry setup

Hi Dean,

We at Jembi have also been working on setting up an OpenHIE demo which includes MedicCR as the client registry.

We followed this guide to get the server configured - https://mediccr.codeplex.com/wikipage?title=Single%20Server%20Deployment&referringTitle=Documentation

I then used the MedicCR configurator to enable both the FHIR endpoints and the PIX/PDQ endpoints. To get these messages to be passed through the OpenHIM you will need to create channels in the OpenHIM that forwards requests that you send to the OpenHIM to MedicCR. You can find some documentation on setting up channels in the OpenHIM docs - http://openhim.readthedocs.io/en/latest/user-guide/basic-config.html We also have some OpenHIM tutorials if you want a better understanding of how it works - http://openhim.readthedocs.io/en/latest/tutorial/index.html

We are also still getting our demo configuration right and may be able to provide more help as we get further in doing this ourselves.

Cheers,
Ryan

On Wed, Jan 18, 2017 at 12:49 AM Chandler, Dean <dcha...@path.org <mailto:dcha…@path.org>> wrote:
Medic CR

Get Outlook for Android <Bing;

From: Shaun Grannis
Sent: Tuesday, January 17, 2:46 PM

Subject: Re: OpenHIE client registry setup

To: Chandler, Dean
Cc: Interoperability Layer (OpenHIE)

Dean,

Are you considering MEDIC-CR ("Mohawk CR" in the document you reference), or OpenEMPI?

Thanks,

Shaun

----
Shaun J. Grannis, MD MS FACMI FAAFP
Biomedical Research Scientist, The Regenstrief Institute
Associate Professor, I.U. School of Medicine
410 West 10th Street, Suite 2000
Indianapolis, IN 46202
(317) 274-9092 (Office)
(317) 274-9305 (Fax)

On Tue, Jan 17, 2017 at 4:20 PM, Chandler, Dean <dcha...@path.org <mailto:dcha…@path.org>> wrote:

HI Shaun,

                Thanks for getting back to me. I am trying to follow the OpenHIE install doc see link below so I can enable some of the v1.0 workflow. I have pretty much installed everything except the CR services so OpenHIM, OpenSHR, OpenMRS, and OpenInfoMan. My hope is to be able to show the performance/scalability for the interop between the OpenHIM and the CR using latest FHIR implementation. I am very new to eHealth so any feedback or pointers would be really appreciated.

Dean…

Log In - OpenHIE Wiki

From: Shaun Grannis [mailto:sgra…@gmail.com]
Sent: Tuesday, January 17, 2017 1:12 PM
To: Chandler, Dean <dcha...@path.org <mailto:dcha…@path.org>>
Cc: Interoperability Layer (OpenHIE) <openhie-interoperability-layer@googlegroups.com <mailto:openhie-interoperability-layer@googlegroups.com>>
Subject: Re: OpenHIE client registry setup

Hi Dean,

Thanks for reaching out. Two key elements here are configuring the OpenHIM and selection of a CR/MPI system. The implementation process will depend in part on your choice of MPI. Can you say what your anticipated software components will be?

Best,

Shaun

----
Shaun J. Grannis, MD MS FACMI FAAFP
Biomedical Research Scientist, The Regenstrief Institute
Associate Professor, I.U. School of Medicine
410 West 10th Street, Suite 2000
Indianapolis, IN 46202
(317) 274-9092 (Office)
(317) 274-9305 (Fax)

On Tue, Jan 17, 2017 at 1:58 PM, <dcha...@path.org <mailto:dcha…@path.org>> wrote:

HI all,
I am trying to setup a connection to a client registry from OpenHIM and would appreciate any help in understanding whether there are existing test registry I can use or if I should setup one. I am trying to get an OpenHIE integration setup on AWS instances for test/performance purposes and would like to mimic the OpenHIE workflow 1.0 eventually using the new FHIR mechanisms hopefully getting release early this year. Apologies if this is the wrong group for this. Please let me know.

Thanks,
Dean..

--
You received this message because you are subscribed to the Google Groups "Interoperability Layer (OpenHIE)" group.
To unsubscribe from this group and stop receiving emails from it, send an email toopenhie-interoperability-layer+unsubscribe@googlegroups.com <mailto:openhie-interoperability-layer+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 "Interoperability Layer (OpenHIE)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openhie-interoperability-layer+unsubscribe@googlegroups.com <mailto:openhie-interoperability-layer+unsubscribe@googlegroups.com>.
For more options, visit https://groups.google.com/d/optout.
--
Ryan Crichton
Lead Developer, Jembi Health Systems | SOUTH AFRICA
Mobile: +27845829934 | Skype: ryan.graham.crichton
E-mail: ry...@jembi.org <mailto:ry…@jembi.org>
--
Ryan Crichton
Lead Developer, Jembi Health Systems | SOUTH AFRICA
Mobile: +27845829934 | Skype: ryan.graham.crichton
E-mail: ry...@jembi.org <mailto:ry…@jembi.org>

This E-mail contains privileged and confidential information intended
only for the individual or entity named in the message. If the reader
of this message is not the intended recipient, or the agent responsible
to deliver it to the intended recipient, you are hereby notified that
any review, dissemination, distribution or copying of this communication
is prohibited. If this communication was received in error, please
notify the sender by reply E-mail immediately, and delete and destroy
the original message.

--
You received this message because you are subscribed to the Google Groups "Interoperability Layer (OpenHIE)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openhie-interoperability-layer+unsubscribe@googlegroups.com <mailto:openhie-interoperability-layer+unsubscribe@googlegroups.com>.
For more options, visit https://groups.google.com/d/optout.

Hi Carl,

I think we were waiting for the IHE profiles to catch up with the FHIR specification. The notifications were primarily designed because XDS registries
require them to be able to know about patients before getting documents for those patients…. Also, since notifications are based more around events than “resources” it would be a little tricky (ex: merge) given the current notification framework in the CR…
It is also the reason that receiving FHIR resources is a little more tricky in our CR (FHIR used to make the assumption that a receiver could regurgitate any ol’ thing that was submitted).

Cheers

-Justin

···

From: Carl Leitner [mailto:litlfred@gmail.com]
Sent: January 26, 2017 7:52 AM
To: Fyfe, Justin justin.fyfe1@mohawkcollege.ca
Cc: Chandler, Dean dchandler@path.org; Ryan Crichton ryan@jembi.org; sgrannis@gmail.com; Taliesin, Brian btaliesin@path.org; Interoperability Layer (OpenHIE) openhie-interoperability-layer@googlegroups.com
Subject: Re: OpenHIE client registry setup

Hi Justin,

Just curious if you are working on a FHIR equivalent for ITI-8/44 or ITI-10/46 ?

Cheers,

-carl

On Jan 25, 2017, at 11:22 PM, Fyfe, Justin justin.fyfe1@mohawkcollege.ca wrote:

Woops, I forgot to answer the second part of your first question.

In terms of communicating with other components like the SHR, the CR supports PUSH notifications. These are configured under the PIXv3 notifications panel (originally it only
supported PIXv3). This allows the CR to notify other HIE components in real time when new patients are registered, updated, or merged.

Basically you set up a notification target based on which identity domain/authority you’d like a notification triggered…

<image001.png>

There are four options:

  • ITI-10 or PAT_ID_X_REF_MGR PIX update notification (the CR will send ADT^A31 messages to a recipient)
  • ITI-8 or PAT_IDENTITY_SRC notification (the CR will send either ADT^A01, ADT^A08 or ADT^A40 messages based on how a record
    was created/updated/merged)
  • ITI-44 or PAT_IDENTITY_SRC_HL7v3 notification which is the same as ITI-8 only in v3 instead of v2 (PRPA_IN201301/PRPA_IN201302
    and PRPA_IN201304)
  • ITI-46 or PAT_ID_X_REF_MGR_HL7v3 which is the same as ITI-10 only in v3 instead of v2 (PRPA_IN201302)

Once you configure this the CR will start pushing notifications to the target machine for any new registration event which occurs.

Cheers

-Justin

From: Chandler,
Dean [mailto:dchandler@path.org]
Sent: January 25, 2017 11:58 AM
To: Fyfe, Justin justin.fyfe1@mohawkcollege.ca
Cc: ryan@jembi.org; sgrannis@gmail.com ;
Taliesin, Brian btaliesin@path.org; Interoperability Layer (OpenHIE) openhie-interoperability-layer@googlegroups.com
Subject: RE: OpenHIE client registry setup

Hi Justin,

             Thanks for getting back to me I know you guys are very busy.  Please do forward your examples of the config files and any further

documentation on how MedicCR communicates with HIE components I have setup like OpenSHR and HIIM.

I believe Mohawk also supports the OSCAR demo see link below. Does this demo use the MedicCR or some other service to
share patient data. If it does it would be great if I can replicate it on Path’s AWS instances I have setup for performance testing.

https://wiki.ohie.org/display/resources/OpenHIE+Demo

             Also will the new Mohawk components your team is working on be managed by a tool similar to the MedicCR configuration tool?  Please

let us know.

Thanks,

            Dean…

From: Justin
(Mohawk College) [mailto:justin.fyfe1@mohawkcollege.ca]
Sent: Tuesday, January 24, 2017 12:16 PM
To: Interoperability Layer (OpenHIE) openhie-interoperability-layer@googlegroups.com
Cc: ryan@jembi.org; sgrannis@gmail.com ;
Chandler, Dean dchandler@path.org
Subject: Re: OpenHIE client registry setup

Oh, I also forgot one additional point.

Once you have your demonstration instance setup, you can share the ClientRegistry.exe.config files with others to replicate the configuration settings across machines/deployments. I may have a few lying around from the
various demos we’ve done in the past which we can share. The only real thing that needs to change are the OIDs and database connection strings of course.

Cheers

-Justin

On Tuesday, January 24, 2017 at 3:06:32 PM UTC-5, Justin (Mohawk College) wrote:

Hi all, thought I would chime in (apparently I wasn’t subscribed to this group apparently, thanks to Derek for bringing this thread to my attention).

The administration interface is indeed a soap based service to which the administration tool connects. The administration tool setup under the bundled installer can be a little bit obtuse to setup, but basically you have
to ensure that the web.config file for the admin tool has the same bindings as the configuration for the client registry itself. The administrative interface is bundled with installer and should be in C:\Program Files (x86)\Mohawk College\Client Registry\admin,
setup instructions are (at a basic level):

  1. Install IIS with ASP.NET MVC
    framework 4 or higher
  1. Create a virtual application which points to the C:\Program Files (x86)\Mohawk College\Client Registry\admin directory
  1. Give the IUSR account (or whatever application pool user IIS is using) read/execute access to that directory
  1. Ensure that C:\Program Files (x86)\Mohawk College\Client Registry\admin\web.config matches the service contract for C:\Program Files (x86)\Mohawk College\Client Registry\ClientRegistry.exe.config.

There may be packaging issue whereby the IIS server will complain about a missing System.Web.Http.dll assembly (it used to be packaged in some ASP.NET MVC
installers). If you encounter this, the easiest way to get around it is to hunt down a copy on your machine, or use the 1.2 version installer (which isn’t released yet, it is the version being deployed in Myanmar).

As per the configuration itself, the configuration tool is really just a more user friendly wrapper for the XML based configuration file. You can hand edit the configuration file ClientRegistry.exe.config if you’re comfortable
with it, and it does provide additional configuration options. Most of the options for transport/security/etc. are standard .NET WCF configuration options (https://msdn.microsoft.com/en-us/library/ms733932(v=vs.110).aspx )
however, for most scenarios the UI wraps this complexity sufficiently. I usually use the GUI to get up and running and then hand-edit the XML. The configuration tool shouldn’t mind hand edited config settings and typically leaves them alone (it also makes
a backup).

Regarding the question about what the CR stores. The client registry stores various types of data in the data structures it creates (in either separate database instances, or a single database if you selected “simple”
or “express” deployment). These are alluded to in section 2.1.3 of the operations guide, but not really in much detail. Basically the types of data stored are:

  • The core CR storage database (defined in /marc.hi.ehrs.cr.persistence.data/connectionManager element)
  • Patient demographics information (name, dob, gender, etc.)
  • Registration event information (in v2 the MSH/EVN segments, v3 the transport/controlAct wrapper and FHIR the best mapping available for those elements)
  • Relationship to non-patient persons (mother, father, etc.)
  • This supports configuration of primary>secondary PostgreSQL streaming replication for large datasets via a write-only primary/read-only secondary(ies). This is really only
    needed for really really big datasets, or cases where you have lots of application servers or a high number of concurrent clients slamming the CR. For example, the eHealth Ontario innovation lab instance has 1.4 million fake patients and it doesn’t even need
    this type of deployment (as the response times for queries is still less than 1.2 sec with about 6-8 concurrent sessions).
  • The query tracking database (defined in /marc.ehrs.qm.persistence.data/connectionManager element)
  • Query state information used for query continuation.
  • This is how the V2 RCP segment, the v3 queryId/QUQI_IN100003UV or FHIR _stateId works)
  • The server runs the query once and stores the results, the client can then quickly page through the results in the query set without having the server re-execute the query
  • The message tracking database (defined in /marc.hi.ehrs.svc.messaging.persistence/connectionManager element)
  • Message execution information (exec-once, cached response data, etc.)
  • This is where the CR makes the determination if a message has already been processed in the case of client retry messages. It is triggered off of the MSH-10 field in v2
    or the /PRPAXXXX/id element in v3.
  • It is the reason why if you execute a message and then just resend the exact same message without giving it a new message identifier the message is not actually executed.
  • Code reference database (defined in /marc.hi.ehrs…svc.terminology/qdcdb element, you can also use a CTS 1 based server in lieu of this)
  • Provides a basic set of code lookups for things like languages, etc.

Hope that helps!

Cheers

-Justin

On Tuesday, January 24, 2017 at 11:34:03 AM UTC-5, Chandler, Dean wrote:

Hi Ryan,

             Thanks for the feedback.  So does MedicCR store the data for the client or just the transaction info in the local postgresql database? 

Looks like I need more info on how the big picture works here. Let me know how your testing goes and any additional pointers to related documentation.

Dean…

From: Ryan
Crichton [mailto:ry...@jembi.org]
Sent: Tuesday, January 24, 2017 3:22 AM
To: Chandler, Dean dcha...@path.org; Shaun Grannis sgra...@gmail.com
Cc: Interoperability Layer (OpenHIE) openhie-interoperability-layer@googlegroups.com
Subject: Re: OpenHIE client registry setup

Hi Dean,

From what I understand of MedicCR it seems that the admin interface is a soap-based web service interface rather than a user interface. I got the same thing that you are getting. At least that is how the configurator
made it sound, I could be wrong. I think all the configuration is done through the configurator app. Can anyone of this list verify this?

Cheers,

Ryan

On Tue, Jan 24, 2017 at 12:29 AM Chandler, Dean dcha...@path.org wrote:

Hi Ryan,

             Thanks for the pointers.  I keep running into an issue with either set of instructions that is preventing me from running the Admin

interface at the following url.

http://127.0.0.1:9999/admin . Any ideas as to why this
issue keeps coming up.

Thanks,

            Dean..

From: Ryan
Crichton [mailto:ry...@jembi.org]
Sent: Sunday, January 22, 2017 11:47 PM
To: Chandler, Dean dcha...@path.org; Shaun Grannis sgra...@gmail.com

Cc: Interoperability Layer (OpenHIE) openhie-interoperability-layer@googlegroups.com
Subject: Re: OpenHIE client registry setup

Hi Dean,

We at Jembi have also been working on setting up an OpenHIE demo which includes MedicCR as the client registry.

We followed this guide to get the server configured - https://mediccr.codeplex.com/wikipage?title=Single%20Server%20Deployment&referringTitle=Documentation

I then used the MedicCR configurator to enable both the FHIR endpoints and the PIX/PDQ endpoints. To get these messages to be passed through the OpenHIM you will need to create channels in the OpenHIM that forwards requests
that you send to the OpenHIM to MedicCR. You can find some documentation on setting up channels in the OpenHIM docs - http://openhim.readthedocs.io/en/latest/user-guide/basic-config.html We
also have some OpenHIM tutorials if you want a better understanding of how it works - http://openhim.readthedocs.io/en/latest/tutorial/index.html

We are also still getting our demo configuration right and may be able to provide more help as we get further in doing this ourselves.

Cheers,

Ryan

On Wed, Jan 18, 2017 at 12:49 AM Chandler, Dean dcha...@path.org wrote:

Medic CR

Get Outlook for Android

From: Shaun Grannis

Sent: Tuesday, January 17, 2:46 PM

Subject: Re: OpenHIE client registry setup

To: Chandler, Dean

Cc: Interoperability Layer (OpenHIE)

Dean,

Are you considering MEDIC-CR (“Mohawk CR” in the document you reference), or OpenEMPI?

Thanks,

Shaun


Shaun J. Grannis, MD MS FACMI FAAFP

Biomedical Research Scientist, The Regenstrief Institute

Associate Professor, I.U. School of Medicine

410 West 10th Street, Suite 2000

Indianapolis, IN 46202

(317) 274-9092 (Office)

(317) 274-9305 (Fax)

On Tue, Jan 17, 2017 at 4:20 PM, Chandler, Dean dcha...@path.org wrote:

HI Shaun,

             Thanks for getting back to me.  I am trying to follow the OpenHIE install doc see link below so I can enable some of the v1.0 workflow. I have pretty much installed everything

except the CR services so OpenHIM, OpenSHR, OpenMRS, and OpenInfoMan. My hope is to be able to show the performance/scalability for the interop between the OpenHIM and the CR using latest FHIR implementation. I am very new to eHealth so any feedback or
pointers would be really appreciated.

Dean…

https://wiki.ohie.org/display/resources/How+to+install+OpenHIE+1.0

From: Shaun
Grannis [mailto:sgra...@gmail.com]
Sent: Tuesday, January 17, 2017 1:12 PM
To: Chandler, Dean dcha...@path.org
Cc: Interoperability Layer (OpenHIE) openhie-interoperability-layer@googlegroups.com
Subject: Re: OpenHIE client registry setup

Hi Dean,

Thanks for reaching out. Two key elements here are configuring the OpenHIM and selection of a CR/MPI system. The implementation process will depend in part on your choice of MPI. Can
you say what your anticipated software components will be?

Best,

Shaun


Shaun J. Grannis, MD MS FACMI FAAFP

Biomedical Research Scientist, The Regenstrief Institute

Associate Professor, I.U. School of Medicine

410 West 10th Street, Suite 2000

Indianapolis, IN 46202

(317) 274-9092 (Office)

(317) 274-9305 (Fax)

On Tue, Jan 17, 2017 at 1:58 PM, dcha...@path.org wrote:

HI all,

I am trying to setup a connection to a client registry from OpenHIM and would appreciate any help in understanding whether there are existing test registry I can use or if I should setup one. I am trying to get an OpenHIE integration setup on AWS instances
for test/performance purposes and would like to mimic the OpenHIE workflow 1.0 eventually using the new FHIR mechanisms hopefully getting release early this year. Apologies if this is the wrong group for this. Please let me know.

Thanks,

Dean…

You received this message because you are subscribed to the Google Groups “Interoperability Layer (OpenHIE)” group.

To unsubscribe from this group and stop receiving emails from it, send an email toopenhie-interoperability-layer+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 “Interoperability Layer (OpenHIE)” group.

To unsubscribe from this group and stop receiving emails from it, send an email to openhie-interoperability-layer+unsubscribe@googlegroups.com.

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

Ryan Crichton

Lead Developer, Jembi Health Systems | SOUTH AFRICA

Mobile: +27845829934 | Skype: ryan.graham.crichton

E-mail: ry...@jembi.org

Ryan Crichton

Lead Developer, Jembi Health Systems | SOUTH AFRICA

Mobile: +27845829934 | Skype: ryan.graham.crichton

E-mail: ry...@jembi.org


This E-mail contains privileged and confidential information intended

only for the individual or entity named in the message. If the reader

of this message is not the intended recipient, or the agent responsible

to deliver it to the intended recipient, you are hereby notified that

any review, dissemination, distribution or copying of this communication

is prohibited. If this communication was received in error, please

notify the sender by reply E-mail immediately, and delete and destroy

the original message.

You received this message because you are subscribed to the Google Groups “Interoperability Layer (OpenHIE)” group.

To unsubscribe from this group and stop receiving emails from it, send an email to openhie-interoperability-layer+unsubscribe@googlegroups.com.

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