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.
