Help needed to communcate with a HIE

Wyclif_Luyima · October 7, 2016, 2:16pm

Hi,

I have a module that I worked on not so long ago with Regenstrief and CDC on case based reporting, the CDC wants us to do a spike on how to integrate the module into the HIE, the idea is that the module gets installed in an OpenMRS instance and will send a case report to the HIE for a given patient in form of a FHIR message when they match a certain criteria, saving it as a document in the SHR should be enough for demonstration purposes. I managed to set up OpenHIM and the console and I’m trying to figure out where to go next, below are some of the questions I have:

1- Can I turn off TLS authentication since this is a demo installation on a dev machine?
2- I understand that the HIE works with CDA documents and not FHIR, do you intend to support FHIR anytime soon? If not, is there a way I can plugin in something that can parse another message format? I also see that there is the concept of a data handler in the SHR, can I add my own FHIR handler to process a FHIR message when it gets to the SHR? Assuming it can go through the transport layer even if the transport layer can’t parse it.
3- Where is the documentation on how to make requests to OpenHIM? I read somewhere that communication is SOAP based, if this is true, what is the URL to fetch WSDL?

Thanks in advance

Wyclif

dritz · October 7, 2016, 3:11pm

Hi Wyclif.

May I ask a couple of questions, please?

is it a requirement from CDC that the outbound message be a FHIR message?
is it OK with CDC that the TLS be turned off?

I’m asking the first question because, if it is a requirement that the message be a FHIR message then I’m hoping there is scope in the spike to adopt a FHIR->CDA component and incorporate this into the OpenHIE interoperability layer. There are a number of products (including open source) that do this. At present, however, only inbound CDA documents can be checked, verified, resolved, and routed to the SHR. The SHR itself is a CDA document store (XDS registry and repository) plus an OpenMRS-based database of discrete data. There is not a FHIR-compatible message handler (in the IL) and there is not, today, a FHIR-compatible SHR (above the IL, in the OpenHIE registry/repository stack).

I’m asking question #2 because failure on the PKI side is, in my experience, one of the most common failure modes for new software that has turned off security during dev. My wholehearted recommendation would be to keep this turned on. It is a design requirement to be able to operate, when the time comes, in the secured environment. Unless CDC expects to operate in an unsecured envrinment – which is unlikely – this is likely something worthwhile to keep.

Re: your question #3, the OpenHIE documentation links through to IHE documentation regarding the standards for communicating XDS.b payloads. There is quite a lot of information at the IHE wiki which is helpful in this regard (e.g. http://wiki.ihe.net/index.php/XDS.b_Implementation). There are also lots of mature open source toolkits for doing XDS.b message management (as you can probably already tell, the XDS spec has been around for ages) – so there is no need to code from scratch.

Warmest regards,

Derek.

PS: the discussions re: support for FHIR in OpenHIE are active and ongoing. Please see the most recent notes, here: https://wiki.ohie.org/display/resources/2016-10-04+SHR+Community+Calls. We would love your inputs, Wyclif, into this important step for the IL and SHR communities.

···

On Fri, Oct 7, 2016 at 10:16 PM, wyclif@openmrs.org wrote:

Hi,

I have a module that I worked on not so long ago with Regenstrief and CDC on case based reporting, the CDC wants us to do a spike on how to integrate the module into the HIE, the idea is that the module gets installed in an OpenMRS instance and will send a case report to the HIE for a given patient in form of a FHIR message when they match a certain criteria, saving it as a document in the SHR should be enough for demonstration purposes. I managed to set up OpenHIM and the console and I’m trying to figure out where to go next, below are some of the questions I have:

1- Can I turn off TLS authentication since this is a demo installation on a dev machine?
2- I understand that the HIE works with CDA documents and not FHIR, do you intend to support FHIR anytime soon? If not, is there a way I can plugin in something that can parse another message format? I also see that there is the concept of a data handler in the SHR, can I add my own FHIR handler to process a FHIR message when it gets to the SHR? Assuming it can go through the transport layer even if the transport layer can’t parse it.
3- Where is the documentation on how to make requests to OpenHIM? I read somewhere that communication is SOAP based, if this is true, what is the URL to fetch WSDL?

Thanks in advance

Wyclif

–

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.

–

Derek Ritz, P.Eng., CPHIMS-CA
ecGroup Inc.
+1 (905) 515-0045
www.ecgroupinc.com

Wyclif_Luyima · October 7, 2016, 4:18pm

Thanks Derek!

The message doesn’t have to be a FHIR message, we can probably switch to sending out a CDA document if FHIR isn’t supported

Turning on/ff TLS has nothing to do with CDC, as I said this is a spike, meaning I’m trying out things on my machine in a VM to present a demo to the CDC folks, so I’ll get rid of the VM after that.

As for the third, I’m fairly new to XDS so I can’t really clearly comprehend what you just said, I’ll do some reading on that. I thought all I had to do was to make a straight forward old style soap based call to OpenHIM to submit a message. I had also assumed XDS is used by the SHR. I guess I was hoping to get the OpenHIM URL that I’d post to a message and how to get the SWDL.

Wyclif

···

On Friday, October 7, 2016 at 11:11:25 AM UTC-4, Derek Ritz (ecGroup) wrote:

Hi Wyclif.

May I ask a couple of questions, please?

is it a requirement from CDC that the outbound message be a FHIR message?

is it OK with CDC that the TLS be turned off?

I’m asking the first question because, if it is a requirement that the message be a FHIR message then I’m hoping there is scope in the spike to adopt a FHIR->CDA component and incorporate this into the OpenHIE interoperability layer. There are a number of products (including open source) that do this. At present, however, only inbound CDA documents can be checked, verified, resolved, and routed to the SHR. The SHR itself is a CDA document store (XDS registry and repository) plus an OpenMRS-based database of discrete data. There is not a FHIR-compatible message handler (in the IL) and there is not, today, a FHIR-compatible SHR (above the IL, in the OpenHIE registry/repository stack).

I’m asking question #2 because failure on the PKI side is, in my experience, one of the most common failure modes for new software that has turned off security during dev. My wholehearted recommendation would be to keep this turned on. It is a design requirement to be able to operate, when the time comes, in the secured environment. Unless CDC expects to operate in an unsecured envrinment – which is unlikely – this is likely something worthwhile to keep.

Re: your question #3, the OpenHIE documentation links through to IHE documentation regarding the standards for communicating XDS.b payloads. There is quite a lot of information at the IHE wiki which is helpful in this regard (e.g. http://wiki.ihe.net/index.php/XDS.b_Implementation). There are also lots of mature open source toolkits for doing XDS.b message management (as you can probably already tell, the XDS spec has been around for ages) – so there is no need to code from scratch.

Warmest regards,

Derek.

PS: the discussions re: support for FHIR in OpenHIE are active and ongoing. Please see the most recent notes, here: https://wiki.ohie.org/display/resources/2016-10-04+SHR+Community+Calls. We would love your inputs, Wyclif, into this important step for the IL and SHR communities.

On Fri, Oct 7, 2016 at 10:16 PM, wyc...@openmrs.org wrote:

Hi,

I have a module that I worked on not so long ago with Regenstrief and CDC on case based reporting, the CDC wants us to do a spike on how to integrate the module into the HIE, the idea is that the module gets installed in an OpenMRS instance and will send a case report to the HIE for a given patient in form of a FHIR message when they match a certain criteria, saving it as a document in the SHR should be enough for demonstration purposes. I managed to set up OpenHIM and the console and I’m trying to figure out where to go next, below are some of the questions I have:

1- Can I turn off TLS authentication since this is a demo installation on a dev machine?
2- I understand that the HIE works with CDA documents and not FHIR, do you intend to support FHIR anytime soon? If not, is there a way I can plugin in something that can parse another message format? I also see that there is the concept of a data handler in the SHR, can I add my own FHIR handler to process a FHIR message when it gets to the SHR? Assuming it can go through the transport layer even if the transport layer can’t parse it.
3- Where is the documentation on how to make requests to OpenHIM? I read somewhere that communication is SOAP based, if this is true, what is the URL to fetch WSDL?

Thanks in advance

Wyclif

–

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.

–
Derek Ritz, P.Eng., CPHIMS-CA
ecGroup Inc.
+1 (905) 515-0045
www.ecgroupinc.com

dritz · October 7, 2016, 4:57pm

Hi Wyclif.

I hope you don’t mind, but I’m cross-posting this to the OpenHIE Implementer’s Network (OHIN) mailing list, too. The issues you’re raising are ones that others have been finding, too. It is not easy, at present, to know “what to do” in order to communicate with the OpenHIE technology solutions.

As a community, we have identified that “implementer’s guides” are needed, with code examples etc., in order to help the dev teams on point-of-service applications (like EMRs) to connect and do message exchanges. The new OHIN community is tasked with helping develop such guides and with other work efforts that will help the whole of our HIE “ecosystem”.

I can also say, Wyclif, that I advocated strongly for the use of mature, existing standards in OpenHIE. One of my reasons for this was so OpenHIE could just “hyperlink” to the underlying standards’ documentation from our wiki site. It is clear to me that this approach comes at an expense. Most developers expect to find all the instructions they need on our OpenHIE wiki pages. It is quite an unpleasant surprise when they find out that they must follow the links and that some of the comprehensive health informatics specs (like for XDS.b for example) are quite lengthy and involved. Clearly, step-by-step implementation guides are needed.

I look forward to following your spike and to helping it in any ways I can. As a start, I’m also cc’ing my colleague from the mHealth and eHealth Development and Innovation Centre (MEDIC), Justin Fyfe. Justin has been a longtime OpenHIE contributor and did a lot of dev work on the OpenSHR software product (which is OpenMRS-based). @Justin – can you point Wyclif to the modules you developed for CDA-based message generation and consumption from OpenMRS?

Thanks and warmest regards,

Derek.

Derek Ritz, P.Eng., CPHIMS-CA

ecGroup Inc.

+1 (905) 515-0045

This communication is intended only for the party to whom it is addressed, and may contain information which is privileged or confidential. Any other delivery, distribution, copying or disclosure is strictly prohibited and is not a waiver of privilege or confidentiality.

···

From: openhie-interoperability-layer@googlegroups.com [mailto:openhie-interoperability-layer@googlegroups.com] On Behalf Of wyclif@openmrs.org
Sent: Friday, October 7, 2016 12:19 PM
To: Interoperability Layer (OpenHIE)
Cc: wyclif@openmrs.org
Subject: Re: Help needed to communcate with a HIE

Thanks Derek!

The message doesn’t have to be a FHIR message, we can probably switch to sending out a CDA document if FHIR isn’t supported

Turning on/ff TLS has nothing to do with CDC, as I said this is a spike, meaning I’m trying out things on my machine in a VM to present a demo to the CDC folks, so I’ll get rid of the VM after that.

As for the third, I’m fairly new to XDS so I can’t really clearly comprehend what you just said, I’ll do some reading on that. I thought all I had to do was to make a straight forward old style soap based call to OpenHIM to submit a message. I had also assumed XDS is used by the SHR. I guess I was hoping to get the OpenHIM URL that I’d post to a message and how to get the SWDL.

Wyclif

On Friday, October 7, 2016 at 11:11:25 AM UTC-4, Derek Ritz (ecGroup) wrote:

Hi Wyclif.

May I ask a couple of questions, please?

is it a requirement from CDC that the outbound message be a FHIR message?
is it OK with CDC that the TLS be turned off?

I’m asking the first question because, if it is a requirement that the message be a FHIR message then I’m hoping there is scope in the spike to adopt a FHIR->CDA component and incorporate this into the OpenHIE interoperability layer. There are a number of products (including open source) that do this. At present, however, only inbound CDA documents can be checked, verified, resolved, and routed to the SHR. The SHR itself is a CDA document store (XDS registry and repository) plus an OpenMRS-based database of discrete data. There is not a FHIR-compatible message handler (in the IL) and there is not, today, a FHIR-compatible SHR (above the IL, in the OpenHIE registry/repository stack).

I’m asking question #2 because failure on the PKI side is, in my experience, one of the most common failure modes for new software that has turned off security during dev. My wholehearted recommendation would be to keep this turned on. It is a design requirement to be able to operate, when the time comes, in the secured environment. Unless CDC expects to operate in an unsecured envrinment – which is unlikely – this is likely something worthwhile to keep.

Re: your question #3, the OpenHIE documentation links through to IHE documentation regarding the standards for communicating XDS.b payloads. There is quite a lot of information at the IHE wiki which is helpful in this regard (e.g. http://wiki.ihe.net/index.php/XDS.b_Implementation). There are also lots of mature open source toolkits for doing XDS.b message management (as you can probably already tell, the XDS spec has been around for ages) – so there is no need to code from scratch.

Warmest regards,

Derek.

PS: the discussions re: support for FHIR in OpenHIE are active and ongoing. Please see the most recent notes, here: https://wiki.ohie.org/display/resources/2016-10-04+SHR+Community+Calls. We would love your inputs, Wyclif, into this important step for the IL and SHR communities.

On Fri, Oct 7, 2016 at 10:16 PM, wyc...@openmrs.org wrote:

Hi,

I have a module that I worked on not so long ago with Regenstrief and CDC on case based reporting, the CDC wants us to do a spike on how to integrate the module into the HIE, the idea is that the module gets installed in an OpenMRS instance and will send a case report to the HIE for a given patient in form of a FHIR message when they match a certain criteria, saving it as a document in the SHR should be enough for demonstration purposes. I managed to set up OpenHIM and the console and I’m trying to figure out where to go next, below are some of the questions I have:

1- Can I turn off TLS authentication since this is a demo installation on a dev machine?
2- I understand that the HIE works with CDA documents and not FHIR, do you intend to support FHIR anytime soon? If not, is there a way I can plugin in something that can parse another message format? I also see that there is the concept of a data handler in the SHR, can I add my own FHIR handler to process a FHIR message when it gets to the SHR? Assuming it can go through the transport layer even if the transport layer can’t parse it.
3- Where is the documentation on how to make requests to OpenHIM? I read somewhere that communication is SOAP based, if this is true, what is the URL to fetch WSDL?

Thanks in advance

Wyclif

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

–

Derek Ritz, P.Eng., CPHIMS-CA
ecGroup Inc.
+1 (905) 515-0045
www.ecgroupinc.com

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

Wyclif_Luyima · October 7, 2016, 5:49pm

Thanks Derek! That was helpful, I was starting to beat up myself for failing to figure out things :), let me keep playing around with things and will get back to you guys in case I run into any issues.

Wyclif

···

On Friday, October 7, 2016 at 10:16:33 AM UTC-4, wyc...@openmrs.org wrote:

Hi,

I have a module that I worked on not so long ago with Regenstrief and CDC on case based reporting, the CDC wants us to do a spike on how to integrate the module into the HIE, the idea is that the module gets installed in an OpenMRS instance and will send a case report to the HIE for a given patient in form of a FHIR message when they match a certain criteria, saving it as a document in the SHR should be enough for demonstration purposes. I managed to set up OpenHIM and the console and I’m trying to figure out where to go next, below are some of the questions I have:

1- Can I turn off TLS authentication since this is a demo installation on a dev machine?
2- I understand that the HIE works with CDA documents and not FHIR, do you intend to support FHIR anytime soon? If not, is there a way I can plugin in something that can parse another message format? I also see that there is the concept of a data handler in the SHR, can I add my own FHIR handler to process a FHIR message when it gets to the SHR? Assuming it can go through the transport layer even if the transport layer can’t parse it.
3- Where is the documentation on how to make requests to OpenHIM? I read somewhere that communication is SOAP based, if this is true, what is the URL to fetch WSDL?

Thanks in advance

Wyclif

Jennifer_E_Shivers · October 7, 2016, 7:13pm

Hi all,
I provided Wycliff with a script that we used for OHIE 1.0 SHR workflow testing. It provided an example of how one fires a transaction at the OpenHim. If this would be helpful to other implementers, this is something simple that I think we can provide with the documentation of the workflows.

Thoughts?

Jennifer

···

On Oct 7, 2016, at 1:49 PM, wyclif@openmrs.org wrote:

Thanks Derek! That was helpful, I was starting to beat up myself for failing to figure out things :), let me keep playing around with things and will get back to you guys in case I run into any issues.

Wyclif

On Friday, October 7, 2016 at 10:16:33 AM UTC-4, wyc…@openmrs.org wrote:

Hi,

I have a module that I worked on not so long ago with Regenstrief and CDC on case based reporting, the CDC wants us to do a spike on how to integrate the module into the HIE, the idea is that the module gets installed in an OpenMRS instance and will send a case report to the HIE for a given patient in form of a FHIR message when they match a certain criteria, saving it as a document in the SHR should be enough for demonstration purposes. I managed to set up OpenHIM and the console and I’m trying to figure out where to go next, below are some of the questions I have:

1- Can I turn off TLS authentication since this is a demo installation on a dev machine?
2- I understand that the HIE works with CDA documents and not FHIR, do you intend to support FHIR anytime soon? If not, is there a way I can plugin in something that can parse another message format? I also see that there is the concept of a data handler in the SHR, can I add my own FHIR handler to process a FHIR message when it gets to the SHR? Assuming it can go through the transport layer even if the transport layer can’t parse it.
3- Where is the documentation on how to make requests to OpenHIM? I read somewhere that communication is SOAP based, if this is true, what is the URL to fetch WSDL?

Thanks in advance

Wyclif

–

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.

**Jennifer Shivers **|***Integration Architect ***** **| Senior Business Analyst

Tel 317-797-1200 | Skype jennifer.shivers

**
1101 West Tenth Street**

Indianapolis, IN 46202

Web and email addresses, and phone numbers will remain the same.

Tel 317-274-9234 | Fax 317-274-9303

Twitter: @Regenstrief | Facebook.com/regenstriefinstitute

www.regenstrief.org

Confidentiality Notice: The contents of this message and any files transmitted with it may contain confidential and/or privileged information and are intended solely for the use of the named addressee(s). Additionally, the information contained herein may have been disclosed to you from medical records with confidentiality protected by federal and state laws. Federal regulations and State laws prohibit you from making further disclosure of such information without the specific written consent of the person to whom the information pertains or as otherwise permitted by such regulations. A general authorization for the release of medical or other information is not sufficient for this purpose.

If you have received this message in error, please notify the sender by return e-mail and delete the original message. Any retention, disclosure, copying, distribution or use of this information by anyone other than the intended recipient is strictly prohibited.

Darcy_Niamh · October 7, 2016, 7:39pm

I think this would be really helpful Jennifer.

Please do share
J

Niamh

···

From: ohie-implementers@googlegroups.com [mailto:ohie-implementers@googlegroups.com]
On Behalf Of Jennifer Shivers
Sent: Friday, October 07, 2016 3:14 PM
To: Wyclif Luyima wyclif@openmrs.org
Cc: Interoperability Layer (OpenHIE) openhie-interoperability-layer@googlegroups.com; ohie-implementers@googlegroups.com
Subject: [ohie-implementers] Re: Help needed to communcate with a HIE

Hi all,

I provided Wycliff with a script that we used for OHIE 1.0 SHR workflow testing. It provided an example of how one fires a transaction at the OpenHim. If this would be helpful to other implementers, this is something simple that I think
we can provide with the documentation of the workflows.

Thoughts?

Jennifer

On Oct 7, 2016, at 1:49 PM,
wyclif@openmrs.org wrote:

Thanks Derek! That was helpful, I was starting to beat up myself for failing to figure out things :), let me keep playing around with things and will get back to you guys in case I run into any issues.

Wyclif

On Friday, October 7, 2016 at 10:16:33 AM UTC-4, wyc…@openmrs.org wrote:

Hi,

I have a module that I worked on not so long ago with Regenstrief and CDC on case based reporting, the CDC wants us to do a spike on how to integrate the module into the HIE, the idea is that the module gets installed in an OpenMRS instance and will send a
case report to the HIE for a given patient in form of a FHIR message when they match a certain criteria, saving it as a document in the SHR should be enough for demonstration purposes. I managed to set up OpenHIM and the console and I’m trying to figure out
where to go next, below are some of the questions I have:

1- Can I turn off TLS authentication since this is a demo installation on a dev machine?
2- I understand that the HIE works with CDA documents and not FHIR, do you intend to support FHIR anytime soon? If not, is there a way I can plugin in something that can parse another message format? I also see that there is the concept of a data handler in
the SHR, can I add my own FHIR handler to process a FHIR message when it gets to the SHR? Assuming it can go through the transport layer even if the transport layer can’t parse it.
3- Where is the documentation on how to make requests to OpenHIM? I read somewhere that communication is SOAP based, if this is true, what is the URL to fetch WSDL?

Thanks in advance

Wyclif

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

**Jennifer Shivers **|***Integration Architect * **| Senior Business Analyst

Tel 317-797-1200 | Skype jennifer.shivers

**
1101 West Tenth Street**

Indianapolis, IN 46202

Web and email addresses, and phone numbers will remain the same.

Tel 317-274-9234 | Fax 317-274-9303

Twitter: @Regenstrief | Facebook.com/regenstriefinstitute

www.regenstrief.org

Confidentiality Notice: The contents of this message and any files transmitted with it may contain confidential and/or privileged information and are intended
solely for the use of the named addressee(s). Additionally, the information contained herein may have been disclosed to you from medical records with confidentiality protected by federal and state laws. Federal regulations and State laws prohibit you from
making further disclosure of such information without the specific written consent of the person to whom the information pertains or as otherwise permitted by such regulations. A general authorization for the release of medical or other information is not
sufficient for this purpose.

If you have received this message in error, please notify the sender by return e-mail and delete the original message. Any retention, disclosure, copying, distribution
or use of this information by anyone other than the intended recipient is strictly prohibited.

–
You received this message because you are subscribed to the Google Groups “OpenHIE Implementers Network (OHIN)” group.
To unsubscribe from this group and stop receiving emails from it, send an email to
ohie-implementers+unsubscribe@googlegroups.com.
To post to this group, send email to
ohie-implementers@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/ohie-implementers/BA4CEBB6-948C-4F0A-83BB-792398DC7D5E%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Wyclif_Luyima · October 7, 2016, 8:16pm

Thanks Jennifer! It turns out Openhim spawns several worker processes each listening on a separate port, it isn’t documented what requests should be forwarded to each port, I had to look at the test to realize that I had to direct my calls to port 5001 and not the same port number used by the console app that I had configured OpenHIM to listen on, I think it would be nice to document these details.
The MongoDB documentation doesn’t seem to mention that one needs to tell the server which folder to use for storage when starting it, so it kept on failing to start because I wasn’t specifying one, It would be nice to add this a side note to the step about installing MongoDB may be it could help others in the future. Otherwise the installation documentation seems pretty good, so good job guys! Keep it up.

Wyclif

···

On Friday, October 7, 2016 at 10:16:33 AM UTC-4, wyc...@openmrs.org wrote:

Hi,

I have a module that I worked on not so long ago with Regenstrief and CDC on case based reporting, the CDC wants us to do a spike on how to integrate the module into the HIE, the idea is that the module gets installed in an OpenMRS instance and will send a case report to the HIE for a given patient in form of a FHIR message when they match a certain criteria, saving it as a document in the SHR should be enough for demonstration purposes. I managed to set up OpenHIM and the console and I’m trying to figure out where to go next, below are some of the questions I have:

1- Can I turn off TLS authentication since this is a demo installation on a dev machine?
2- I understand that the HIE works with CDA documents and not FHIR, do you intend to support FHIR anytime soon? If not, is there a way I can plugin in something that can parse another message format? I also see that there is the concept of a data handler in the SHR, can I add my own FHIR handler to process a FHIR message when it gets to the SHR? Assuming it can go through the transport layer even if the transport layer can’t parse it.
3- Where is the documentation on how to make requests to OpenHIM? I read somewhere that communication is SOAP based, if this is true, what is the URL to fetch WSDL?

Thanks in advance

Wyclif

ryan · October 10, 2016, 7:13am

Hi Wyclif,

There are some tutorials for the OpenHIM that you can follow in the docs that explain things is some more detail - http://openhim.readthedocs.io/en/latest/tutorial/1-getting-started.html

The OpenHIM really just passes through any HTTP request that you send it (much like a reverse proxy), but adds the ability to do authorisation checks, request logging and request orchestration as the request is transferred through the OpenHIM.

For your spike it would probably be best to use XDS.b to send in a document. Although we are currently talking about support for doing this via FHIR. Also, the OpenSHR can store any kind off document that you send it including plain text or a FHIR document, however, CDA would be best as them the OpenSHR can understand it and break the document down further. You are right that a data handler for a FHIR document could also be written if need be.

These system can be complex to get up and running together so should it you need some more help.

Cheers,

Ryan

···

On Fri, Oct 7, 2016 at 10:16 PM wyclif@openmrs.org wrote:

Thanks Jennifer! It turns out Openhim spawns several worker processes each listening on a separate port, it isn’t documented what requests should be forwarded to each port, I had to look at the test to realize that I had to direct my calls to port 5001 and not the same port number used by the console app that I had configured OpenHIM to listen on, I think it would be nice to document these details.
The MongoDB documentation doesn’t seem to mention that one needs to tell the server which folder to use for storage when starting it, so it kept on failing to start because I wasn’t specifying one, It would be nice to add this a side note to the step about installing MongoDB may be it could help others in the future. Otherwise the installation documentation seems pretty good, so good job guys! Keep it up.

Wyclif

On Friday, October 7, 2016 at 10:16:33 AM UTC-4, wyc...@openmrs.org wrote:

Hi,

I have a module that I worked on not so long ago with Regenstrief and CDC on case based reporting, the CDC wants us to do a spike on how to integrate the module into the HIE, the idea is that the module gets installed in an OpenMRS instance and will send a case report to the HIE for a given patient in form of a FHIR message when they match a certain criteria, saving it as a document in the SHR should be enough for demonstration purposes. I managed to set up OpenHIM and the console and I’m trying to figure out where to go next, below are some of the questions I have:

1- Can I turn off TLS authentication since this is a demo installation on a dev machine?
2- I understand that the HIE works with CDA documents and not FHIR, do you intend to support FHIR anytime soon? If not, is there a way I can plugin in something that can parse another message format? I also see that there is the concept of a data handler in the SHR, can I add my own FHIR handler to process a FHIR message when it gets to the SHR? Assuming it can go through the transport layer even if the transport layer can’t parse it.
3- Where is the documentation on how to make requests to OpenHIM? I read somewhere that communication is SOAP based, if this is true, what is the URL to fetch WSDL?

Thanks in advance

Wyclif

–

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

Carl_Fourie1 · October 10, 2016, 8:05am

Thanks all for the great contributions and discussions going on in this list and for bringing in the various communities. I think what we are seeing here is a great example where the OHIE DevOps community could come into play too (in making connecting to OHIE easier).

A few questions to the teams if you wouldn’t mind (I’m really looking for some open and honest feedback – even if it is along the lines of TLDR ;P)

@Wyclif: When looking at OpenHIE and or considering it, what is it to you? Or what do you expect it to be? for example: a deployed stack that allows you to consume services - relatively pre configured? or an architecture designed to let you understand how tools should fit together? etc

How has the IOL not been what you have expected? What are the thoughts about connecting to it?

What does the SHR do in your mind? What do you (as a dev / implementer) envisage you need to do to get it set up?

What top 3 things could we do with our documentation to make life easier? (don’t have to stop at 3 but what are the top things you’d wish you had seen 3 days ago)

@All: please feel free to also answer these questions too.

This is a “step-back” and review the experience and or perceptions of getting started with OpenHIE (please note that there aren’t any wrong answers) and especially looking at making OpenHIE more consumable by others.

···

On Mon, Oct 10, 2016 at 9:13 AM, Ryan Crichton ryan@jembi.org wrote:

Hi Wyclif,

There are some tutorials for the OpenHIM that you can follow in the docs that explain things is some more detail - http://openhim.readthedocs.io/en/latest/tutorial/1-getting-started.html

The OpenHIM really just passes through any HTTP request that you send it (much like a reverse proxy), but adds the ability to do authorisation checks, request logging and request orchestration as the request is transferred through the OpenHIM.

For your spike it would probably be best to use XDS.b to send in a document. Although we are currently talking about support for doing this via FHIR. Also, the OpenSHR can store any kind off document that you send it including plain text or a FHIR document, however, CDA would be best as them the OpenSHR can understand it and break the document down further. You are right that a data handler for a FHIR document could also be written if need be.

These system can be complex to get up and running together so should it you need some more help.

Cheers,

Ryan

On Fri, Oct 7, 2016 at 10:16 PM wyclif@openmrs.org wrote:

Thanks Jennifer! It turns out Openhim spawns several worker processes each listening on a separate port, it isn’t documented what requests should be forwarded to each port, I had to look at the test to realize that I had to direct my calls to port 5001 and not the same port number used by the console app that I had configured OpenHIM to listen on, I think it would be nice to document these details.
The MongoDB documentation doesn’t seem to mention that one needs to tell the server which folder to use for storage when starting it, so it kept on failing to start because I wasn’t specifying one, It would be nice to add this a side note to the step about installing MongoDB may be it could help others in the future. Otherwise the installation documentation seems pretty good, so good job guys! Keep it up.

Wyclif

On Friday, October 7, 2016 at 10:16:33 AM UTC-4, wyc...@openmrs.org wrote:

Hi,

I have a module that I worked on not so long ago with Regenstrief and CDC on case based reporting, the CDC wants us to do a spike on how to integrate the module into the HIE, the idea is that the module gets installed in an OpenMRS instance and will send a case report to the HIE for a given patient in form of a FHIR message when they match a certain criteria, saving it as a document in the SHR should be enough for demonstration purposes. I managed to set up OpenHIM and the console and I’m trying to figure out where to go next, below are some of the questions I have:

1- Can I turn off TLS authentication since this is a demo installation on a dev machine?
2- I understand that the HIE works with CDA documents and not FHIR, do you intend to support FHIR anytime soon? If not, is there a way I can plugin in something that can parse another message format? I also see that there is the concept of a data handler in the SHR, can I add my own FHIR handler to process a FHIR message when it gets to the SHR? Assuming it can go through the transport layer even if the transport layer can’t parse it.
3- Where is the documentation on how to make requests to OpenHIM? I read somewhere that communication is SOAP based, if this is true, what is the URL to fetch WSDL?

Thanks in advance

Wyclif

–

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

–

You received this message because you are subscribed to the Google Groups “OpenHIE Implementers Network (OHIN)” group.

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

To post to this group, send email to ohie-implementers@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/ohie-implementers/CABh-%2BTLzAoEuOaAFiZ9P_5Le0e32TzPeqBV1jdernb445FuFEA%40mail.gmail.com.

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

Regards
Carl Fourie
Senior Program Manager | Digital Health Division

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

Email Disclaimer:

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

Alvin_Marcelo · October 10, 2016, 8:15am

Hi Carl,

Naively, I would be looking for:

software to download and install
configuration instructions for this software (and the others it is supposed to connect with)
a webpage I can visit that tells me if things are working or which ones are broken.

Example:

We just conducted a connectathon for a PACS in our hospital and I would be looking for a similar experience for OpenHIE

After setting up the server on the LAN, the vendor entered the AE title, IP and Port of each node (CT, MRI, ultrasound) and they found each other and started exchanging images…we were up in an hour (most of the time consumed was going around and configuring the machines with the AE title, IP, port)…

Is this use case too simple?

alvin

···

On Mon, Oct 10, 2016 at 4:05 PM, Carl Fourie carl@jembi.org wrote:

Thanks all for the great contributions and discussions going on in this list and for bringing in the various communities. I think what we are seeing here is a great example where the OHIE DevOps community could come into play too (in making connecting to OHIE easier).

A few questions to the teams if you wouldn’t mind (I’m really looking for some open and honest feedback – even if it is along the lines of TLDR ;P)

@Wyclif: When looking at OpenHIE and or considering it, what is it to you? Or what do you expect it to be? for example: a deployed stack that allows you to consume services - relatively pre configured? or an architecture designed to let you understand how tools should fit together? etc

How has the IOL not been what you have expected? What are the thoughts about connecting to it?

What does the SHR do in your mind? What do you (as a dev / implementer) envisage you need to do to get it set up?

What top 3 things could we do with our documentation to make life easier? (don’t have to stop at 3 but what are the top things you’d wish you had seen 3 days ago)

@All: please feel free to also answer these questions too.

This is a “step-back” and review the experience and or perceptions of getting started with OpenHIE (please note that there aren’t any wrong answers) and especially looking at making OpenHIE more consumable by others.

–

You received this message because you are subscribed to the Google Groups “OpenHIE Implementers Network (OHIN)” group.

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

To post to this group, send email to ohie-implementers@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/ohie-implementers/CAFNRjWjgphQBfE26bbvpU6Q1E%2BTk2uzbvcfM9Wdbor6ngraq5g%40mail.gmail.com.

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

–

Regards
Carl Fourie
Senior Program Manager | Digital Health Division

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

Email Disclaimer:

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

On Mon, Oct 10, 2016 at 9:13 AM, Ryan Crichton ryan@jembi.org wrote:

Hi Wyclif,

There are some tutorials for the OpenHIM that you can follow in the docs that explain things is some more detail - http://openhim.readthedocs.io/en/latest/tutorial/1-getting-started.html

The OpenHIM really just passes through any HTTP request that you send it (much like a reverse proxy), but adds the ability to do authorisation checks, request logging and request orchestration as the request is transferred through the OpenHIM.

For your spike it would probably be best to use XDS.b to send in a document. Although we are currently talking about support for doing this via FHIR. Also, the OpenSHR can store any kind off document that you send it including plain text or a FHIR document, however, CDA would be best as them the OpenSHR can understand it and break the document down further. You are right that a data handler for a FHIR document could also be written if need be.

These system can be complex to get up and running together so should it you need some more help.

Cheers,

Ryan

On Fri, Oct 7, 2016 at 10:16 PM wyclif@openmrs.org wrote:

Thanks Jennifer! It turns out Openhim spawns several worker processes each listening on a separate port, it isn’t documented what requests should be forwarded to each port, I had to look at the test to realize that I had to direct my calls to port 5001 and not the same port number used by the console app that I had configured OpenHIM to listen on, I think it would be nice to document these details.
The MongoDB documentation doesn’t seem to mention that one needs to tell the server which folder to use for storage when starting it, so it kept on failing to start because I wasn’t specifying one, It would be nice to add this a side note to the step about installing MongoDB may be it could help others in the future. Otherwise the installation documentation seems pretty good, so good job guys! Keep it up.

Wyclif

On Friday, October 7, 2016 at 10:16:33 AM UTC-4, wyc...@openmrs.org wrote:

Hi,

I have a module that I worked on not so long ago with Regenstrief and CDC on case based reporting, the CDC wants us to do a spike on how to integrate the module into the HIE, the idea is that the module gets installed in an OpenMRS instance and will send a case report to the HIE for a given patient in form of a FHIR message when they match a certain criteria, saving it as a document in the SHR should be enough for demonstration purposes. I managed to set up OpenHIM and the console and I’m trying to figure out where to go next, below are some of the questions I have:

1- Can I turn off TLS authentication since this is a demo installation on a dev machine?
2- I understand that the HIE works with CDA documents and not FHIR, do you intend to support FHIR anytime soon? If not, is there a way I can plugin in something that can parse another message format? I also see that there is the concept of a data handler in the SHR, can I add my own FHIR handler to process a FHIR message when it gets to the SHR? Assuming it can go through the transport layer even if the transport layer can’t parse it.
3- Where is the documentation on how to make requests to OpenHIM? I read somewhere that communication is SOAP based, if this is true, what is the URL to fetch WSDL?

Thanks in advance

Wyclif

–

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

–

You received this message because you are subscribed to the Google Groups “OpenHIE Implementers Network (OHIN)” group.

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

To post to this group, send email to ohie-implementers@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/ohie-implementers/CABh-%2BTLzAoEuOaAFiZ9P_5Le0e32TzPeqBV1jdernb445FuFEA%40mail.gmail.com.

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

Alvin B. Marcelo www.alvinmarcelo.com

Carl_Fourie1 · October 10, 2016, 8:25am

Hi Alvin

Thanks this is great, no not too simple. I think it is something that the DevOps community is happy to hear – @DevOp: looks like we are getting some input towards “What would make OHIE more ‘consumable’ by implementers”.

@All: interesting thought here: How does the OHIE community imagine the SHR (or what clinical data etc) would be configured in a deployment. What I’m getting to is that the use case mentioned is point click configure, I’m wondering how we would manage something (or should we even) from the SHR point of view?

···

On Mon, Oct 10, 2016 at 10:15 AM, Alvin Marcelo admarcelo@up.edu.ph wrote:

Hi Carl,

Naively, I would be looking for:

software to download and install

configuration instructions for this software (and the others it is supposed to connect with)

a webpage I can visit that tells me if things are working or which ones are broken.

Example:

We just conducted a connectathon for a PACS in our hospital and I would be looking for a similar experience for OpenHIE

After setting up the server on the LAN, the vendor entered the AE title, IP and Port of each node (CT, MRI, ultrasound) and they found each other and started exchanging images…we were up in an hour (most of the time consumed was going around and configuring the machines with the AE title, IP, port)…

Is this use case too simple?

alvin

Regards
Carl Fourie
Senior Program Manager | Digital Health Division

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

Email Disclaimer:

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

On Mon, Oct 10, 2016 at 4:05 PM, Carl Fourie carl@jembi.org wrote:

Thanks all for the great contributions and discussions going on in this list and for bringing in the various communities. I think what we are seeing here is a great example where the OHIE DevOps community could come into play too (in making connecting to OHIE easier).

A few questions to the teams if you wouldn’t mind (I’m really looking for some open and honest feedback – even if it is along the lines of TLDR ;P)

@Wyclif: When looking at OpenHIE and or considering it, what is it to you? Or what do you expect it to be? for example: a deployed stack that allows you to consume services - relatively pre configured? or an architecture designed to let you understand how tools should fit together? etc

How has the IOL not been what you have expected? What are the thoughts about connecting to it?

What does the SHR do in your mind? What do you (as a dev / implementer) envisage you need to do to get it set up?

What top 3 things could we do with our documentation to make life easier? (don’t have to stop at 3 but what are the top things you’d wish you had seen 3 days ago)

@All: please feel free to also answer these questions too.

This is a “step-back” and review the experience and or perceptions of getting started with OpenHIE (please note that there aren’t any wrong answers) and especially looking at making OpenHIE more consumable by others.

–

You received this message because you are subscribed to the Google Groups “OpenHIE Implementers Network (OHIN)” group.

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

To post to this group, send email to ohie-implementers@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/ohie-implementers/CAFNRjWjgphQBfE26bbvpU6Q1E%2BTk2uzbvcfM9Wdbor6ngraq5g%40mail.gmail.com.

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

Alvin B. Marcelo www.alvinmarcelo.com

–

Regards
Carl Fourie
Senior Program Manager | Digital Health Division

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

Email Disclaimer:

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

On Mon, Oct 10, 2016 at 9:13 AM, Ryan Crichton ryan@jembi.org wrote:

Hi Wyclif,

There are some tutorials for the OpenHIM that you can follow in the docs that explain things is some more detail - http://openhim.readthedocs.io/en/latest/tutorial/1-getting-started.html

The OpenHIM really just passes through any HTTP request that you send it (much like a reverse proxy), but adds the ability to do authorisation checks, request logging and request orchestration as the request is transferred through the OpenHIM.

For your spike it would probably be best to use XDS.b to send in a document. Although we are currently talking about support for doing this via FHIR. Also, the OpenSHR can store any kind off document that you send it including plain text or a FHIR document, however, CDA would be best as them the OpenSHR can understand it and break the document down further. You are right that a data handler for a FHIR document could also be written if need be.

These system can be complex to get up and running together so should it you need some more help.

Cheers,

Ryan

On Fri, Oct 7, 2016 at 10:16 PM wyclif@openmrs.org wrote:

Thanks Jennifer! It turns out Openhim spawns several worker processes each listening on a separate port, it isn’t documented what requests should be forwarded to each port, I had to look at the test to realize that I had to direct my calls to port 5001 and not the same port number used by the console app that I had configured OpenHIM to listen on, I think it would be nice to document these details.
The MongoDB documentation doesn’t seem to mention that one needs to tell the server which folder to use for storage when starting it, so it kept on failing to start because I wasn’t specifying one, It would be nice to add this a side note to the step about installing MongoDB may be it could help others in the future. Otherwise the installation documentation seems pretty good, so good job guys! Keep it up.

Wyclif

On Friday, October 7, 2016 at 10:16:33 AM UTC-4, wyc...@openmrs.org wrote:

Hi,

I have a module that I worked on not so long ago with Regenstrief and CDC on case based reporting, the CDC wants us to do a spike on how to integrate the module into the HIE, the idea is that the module gets installed in an OpenMRS instance and will send a case report to the HIE for a given patient in form of a FHIR message when they match a certain criteria, saving it as a document in the SHR should be enough for demonstration purposes. I managed to set up OpenHIM and the console and I’m trying to figure out where to go next, below are some of the questions I have:

1- Can I turn off TLS authentication since this is a demo installation on a dev machine?
2- I understand that the HIE works with CDA documents and not FHIR, do you intend to support FHIR anytime soon? If not, is there a way I can plugin in something that can parse another message format? I also see that there is the concept of a data handler in the SHR, can I add my own FHIR handler to process a FHIR message when it gets to the SHR? Assuming it can go through the transport layer even if the transport layer can’t parse it.
3- Where is the documentation on how to make requests to OpenHIM? I read somewhere that communication is SOAP based, if this is true, what is the URL to fetch WSDL?

Thanks in advance

Wyclif

–

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

–

You received this message because you are subscribed to the Google Groups “OpenHIE Implementers Network (OHIN)” group.

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

To post to this group, send email to ohie-implementers@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/ohie-implementers/CABh-%2BTLzAoEuOaAFiZ9P_5Le0e32TzPeqBV1jdernb445FuFEA%40mail.gmail.com.

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

Wyclif_Luyima · October 10, 2016, 1:49pm

Hi,

Thank you all for your responses! @Ryan the getting started page you recommended is really helpful for somebody trying to set up OHIE for the first time.

To respond to Carl’s questions:

OpenHIE is actually what I expected it to be, i.e a deployed stack that allows you to consume services.

The IOL is kind of what I expected it to be, it would be nice to have the getting started tutorial Ryan mentioned on the main documentation page. And as I mentioned in one of my earlier posts, OpenHIM spawns several child processes listening on different ports, it’s not documented what requests each handles.

Thanks!

Wyclif

···

On Mon, Oct 10, 2016 at 4:25 AM, Carl Fourie carl@jembi.org wrote:

Hi Alvin

Thanks this is great, no not too simple. I think it is something that the DevOps community is happy to hear – @DevOp: looks like we are getting some input towards “What would make OHIE more ‘consumable’ by implementers”.

@All: interesting thought here: How does the OHIE community imagine the SHR (or what clinical data etc) would be configured in a deployment. What I’m getting to is that the use case mentioned is point click configure, I’m wondering how we would manage something (or should we even) from the SHR point of view?

–

Regards
Carl Fourie
Senior Program Manager | Digital Health Division

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

Email Disclaimer:

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

On Mon, Oct 10, 2016 at 10:15 AM, Alvin Marcelo admarcelo@up.edu.ph wrote:

Hi Carl,

Naively, I would be looking for:

software to download and install

configuration instructions for this software (and the others it is supposed to connect with)

a webpage I can visit that tells me if things are working or which ones are broken.

Example:

We just conducted a connectathon for a PACS in our hospital and I would be looking for a similar experience for OpenHIE

After setting up the server on the LAN, the vendor entered the AE title, IP and Port of each node (CT, MRI, ultrasound) and they found each other and started exchanging images…we were up in an hour (most of the time consumed was going around and configuring the machines with the AE title, IP, port)…

Is this use case too simple?

alvin

On Mon, Oct 10, 2016 at 4:05 PM, Carl Fourie carl@jembi.org wrote:

Thanks all for the great contributions and discussions going on in this list and for bringing in the various communities. I think what we are seeing here is a great example where the OHIE DevOps community could come into play too (in making connecting to OHIE easier).

A few questions to the teams if you wouldn’t mind (I’m really looking for some open and honest feedback – even if it is along the lines of TLDR ;P)

@Wyclif: When looking at OpenHIE and or considering it, what is it to you? Or what do you expect it to be? for example: a deployed stack that allows you to consume services - relatively pre configured? or an architecture designed to let you understand how tools should fit together? etc

How has the IOL not been what you have expected? What are the thoughts about connecting to it?

What does the SHR do in your mind? What do you (as a dev / implementer) envisage you need to do to get it set up?

What top 3 things could we do with our documentation to make life easier? (don’t have to stop at 3 but what are the top things you’d wish you had seen 3 days ago)

@All: please feel free to also answer these questions too.

This is a “step-back” and review the experience and or perceptions of getting started with OpenHIE (please note that there aren’t any wrong answers) and especially looking at making OpenHIE more consumable by others.

–

You received this message because you are subscribed to the Google Groups “OpenHIE Implementers Network (OHIN)” group.

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

To post to this group, send email to ohie-implementers@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/ohie-implementers/CAFNRjWjgphQBfE26bbvpU6Q1E%2BTk2uzbvcfM9Wdbor6ngraq5g%40mail.gmail.com.

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

Alvin B. Marcelo www.alvinmarcelo.com

–

Regards
Carl Fourie
Senior Program Manager | Digital Health Division

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

Email Disclaimer:

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

On Mon, Oct 10, 2016 at 9:13 AM, Ryan Crichton ryan@jembi.org wrote:

Hi Wyclif,

There are some tutorials for the OpenHIM that you can follow in the docs that explain things is some more detail - http://openhim.readthedocs.io/en/latest/tutorial/1-getting-started.html

The OpenHIM really just passes through any HTTP request that you send it (much like a reverse proxy), but adds the ability to do authorisation checks, request logging and request orchestration as the request is transferred through the OpenHIM.

For your spike it would probably be best to use XDS.b to send in a document. Although we are currently talking about support for doing this via FHIR. Also, the OpenSHR can store any kind off document that you send it including plain text or a FHIR document, however, CDA would be best as them the OpenSHR can understand it and break the document down further. You are right that a data handler for a FHIR document could also be written if need be.

These system can be complex to get up and running together so should it you need some more help.

Cheers,

Ryan

On Fri, Oct 7, 2016 at 10:16 PM wyclif@openmrs.org wrote:

Thanks Jennifer! It turns out Openhim spawns several worker processes each listening on a separate port, it isn’t documented what requests should be forwarded to each port, I had to look at the test to realize that I had to direct my calls to port 5001 and not the same port number used by the console app that I had configured OpenHIM to listen on, I think it would be nice to document these details.
The MongoDB documentation doesn’t seem to mention that one needs to tell the server which folder to use for storage when starting it, so it kept on failing to start because I wasn’t specifying one, It would be nice to add this a side note to the step about installing MongoDB may be it could help others in the future. Otherwise the installation documentation seems pretty good, so good job guys! Keep it up.

Wyclif

On Friday, October 7, 2016 at 10:16:33 AM UTC-4, wyc...@openmrs.org wrote:

Hi,

I have a module that I worked on not so long ago with Regenstrief and CDC on case based reporting, the CDC wants us to do a spike on how to integrate the module into the HIE, the idea is that the module gets installed in an OpenMRS instance and will send a case report to the HIE for a given patient in form of a FHIR message when they match a certain criteria, saving it as a document in the SHR should be enough for demonstration purposes. I managed to set up OpenHIM and the console and I’m trying to figure out where to go next, below are some of the questions I have:

1- Can I turn off TLS authentication since this is a demo installation on a dev machine?
2- I understand that the HIE works with CDA documents and not FHIR, do you intend to support FHIR anytime soon? If not, is there a way I can plugin in something that can parse another message format? I also see that there is the concept of a data handler in the SHR, can I add my own FHIR handler to process a FHIR message when it gets to the SHR? Assuming it can go through the transport layer even if the transport layer can’t parse it.
3- Where is the documentation on how to make requests to OpenHIM? I read somewhere that communication is SOAP based, if this is true, what is the URL to fetch WSDL?

Thanks in advance

Wyclif

–

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

–

You received this message because you are subscribed to the Google Groups “OpenHIE Implementers Network (OHIN)” group.

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

To post to this group, send email to ohie-implementers@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/ohie-implementers/CABh-%2BTLzAoEuOaAFiZ9P_5Le0e32TzPeqBV1jdernb445FuFEA%40mail.gmail.com.

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

Wyclif Luyima
Regenstrief Institute Inc.

Confidentiality
Notice: The contents of this message and any files transmitted with it may contain confidential and/or privileged information and are intended solely for the
use of the named addressee(s). Additionally, the information contained herein may have been disclosed to you from medical records with confidentiality protected by federal and state laws. Federal regulations
and State laws prohibit you from making further
disclosure of such information without the specific written consent of the person to whom the information pertains or as otherwise permitted by
such regulations. A general authorization for the release of medical or
other information is not sufficient for
this purpose.

If you have received this message in error, please notify the sender by return e-mail and delete the original message. Any retention, disclosure, copying, distribution or use of this information by anyone other than the intended recipient is strictly prohibited.

Wyclif_Luyima · October 10, 2016, 1:50pm

Hi,

Thank you all for your responses! @Ryan the getting started page you recommended is really helpful for somebody trying to set up OHIE for the first time.

To respond to Carl’s questions:

OpenHIE is actually what I expected it to be, i.e a deployed stack that allows you to consume services.

The
IOL is kind of what I expected it to be, it would be nice to have the getting started tutorial Ryan mentioned on the main documentation page. And as I mentioned in one of my earlier posts, OpenHIM spawns several child processes listening on different ports, it’s not documented what requests each handles.

Thanks!

Wyclif

···

On Friday, October 7, 2016 at 10:16:33 AM UTC-4, wyc...@openmrs.org wrote:

Hi,

I have a module that I worked on not so long ago with Regenstrief and CDC on case based reporting, the CDC wants us to do a spike on how to integrate the module into the HIE, the idea is that the module gets installed in an OpenMRS instance and will send a case report to the HIE for a given patient in form of a FHIR message when they match a certain criteria, saving it as a document in the SHR should be enough for demonstration purposes. I managed to set up OpenHIM and the console and I’m trying to figure out where to go next, below are some of the questions I have:

1- Can I turn off TLS authentication since this is a demo installation on a dev machine?
2- I understand that the HIE works with CDA documents and not FHIR, do you intend to support FHIR anytime soon? If not, is there a way I can plugin in something that can parse another message format? I also see that there is the concept of a data handler in the SHR, can I add my own FHIR handler to process a FHIR message when it gets to the SHR? Assuming it can go through the transport layer even if the transport layer can’t parse it.
3- Where is the documentation on how to make requests to OpenHIM? I read somewhere that communication is SOAP based, if this is true, what is the URL to fetch WSDL?

Thanks in advance

Wyclif

jthomas · October 12, 2016, 1:08pm

@Ryan and Carl,

I am wondering if the case reporting team could have some time on an upcoming IL or SHR call to discuss details about our use case. Is there time available?

-Jamie

···

On Mon, Oct 10, 2016 at 9:49 AM, Wyclif Luyima wyclif@openmrs.org wrote:

Hi,

Thank you all for your responses! @Ryan the getting started page you recommended is really helpful for somebody trying to set up OHIE for the first time.

To respond to Carl’s questions:

OpenHIE is actually what I expected it to be, i.e a deployed stack that allows you to consume services.

The IOL is kind of what I expected it to be, it would be nice to have the getting started tutorial Ryan mentioned on the main documentation page. And as I mentioned in one of my earlier posts, OpenHIM spawns several child processes listening on different ports, it’s not documented what requests each handles.

Thanks!

Wyclif

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

On Mon, Oct 10, 2016 at 4:25 AM, Carl Fourie carl@jembi.org wrote:

Hi Alvin

Thanks this is great, no not too simple. I think it is something that the DevOps community is happy to hear – @DevOp: looks like we are getting some input towards “What would make OHIE more ‘consumable’ by implementers”.

@All: interesting thought here: How does the OHIE community imagine the SHR (or what clinical data etc) would be configured in a deployment. What I’m getting to is that the use case mentioned is point click configure, I’m wondering how we would manage something (or should we even) from the SHR point of view?

–

Wyclif Luyima
Regenstrief Institute Inc.

Confidentiality
Notice: The contents of this message and any files transmitted with it may contain confidential and/or privileged information and are intended solely for the
use of the named addressee(s). Additionally, the information contained herein may have been disclosed to you from medical records with confidentiality protected by federal and state laws. Federal regulations
and State laws prohibit you from making further
disclosure of such information without the specific written consent of the person to whom the information pertains or as otherwise permitted by
such regulations. A general authorization for the release of medical or
other information is not sufficient for
this purpose.

If you have received this message in error, please notify the sender by return e-mail and delete the original message. Any retention, disclosure, copying, distribution or use of this information by anyone other than the intended recipient is strictly prohibited.

Regards
Carl Fourie
Senior Program Manager | Digital Health Division

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

Email Disclaimer:

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

On Mon, Oct 10, 2016 at 10:15 AM, Alvin Marcelo admarcelo@up.edu.ph wrote:

Hi Carl,

Naively, I would be looking for:

software to download and install

configuration instructions for this software (and the others it is supposed to connect with)

a webpage I can visit that tells me if things are working or which ones are broken.

Example:

We just conducted a connectathon for a PACS in our hospital and I would be looking for a similar experience for OpenHIE

After setting up the server on the LAN, the vendor entered the AE title, IP and Port of each node (CT, MRI, ultrasound) and they found each other and started exchanging images…we were up in an hour (most of the time consumed was going around and configuring the machines with the AE title, IP, port)…

Is this use case too simple?

alvin

On Mon, Oct 10, 2016 at 4:05 PM, Carl Fourie carl@jembi.org wrote:

Thanks all for the great contributions and discussions going on in this list and for bringing in the various communities. I think what we are seeing here is a great example where the OHIE DevOps community could come into play too (in making connecting to OHIE easier).

A few questions to the teams if you wouldn’t mind (I’m really looking for some open and honest feedback – even if it is along the lines of TLDR ;P)

@Wyclif: When looking at OpenHIE and or considering it, what is it to you? Or what do you expect it to be? for example: a deployed stack that allows you to consume services - relatively pre configured? or an architecture designed to let you understand how tools should fit together? etc

How has the IOL not been what you have expected? What are the thoughts about connecting to it?

What does the SHR do in your mind? What do you (as a dev / implementer) envisage you need to do to get it set up?

What top 3 things could we do with our documentation to make life easier? (don’t have to stop at 3 but what are the top things you’d wish you had seen 3 days ago)

@All: please feel free to also answer these questions too.

This is a “step-back” and review the experience and or perceptions of getting started with OpenHIE (please note that there aren’t any wrong answers) and especially looking at making OpenHIE more consumable by others.

–

You received this message because you are subscribed to the Google Groups “OpenHIE Implementers Network (OHIN)” group.

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

To post to this group, send email to ohie-implementers@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/ohie-implementers/CAFNRjWjgphQBfE26bbvpU6Q1E%2BTk2uzbvcfM9Wdbor6ngraq5g%40mail.gmail.com.

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

Alvin B. Marcelo www.alvinmarcelo.com

–

Regards
Carl Fourie
Senior Program Manager | Digital Health Division

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

Email Disclaimer:

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

On Mon, Oct 10, 2016 at 9:13 AM, Ryan Crichton ryan@jembi.org wrote:

Hi Wyclif,

There are some tutorials for the OpenHIM that you can follow in the docs that explain things is some more detail - http://openhim.readthedocs.io/en/latest/tutorial/1-getting-started.html

The OpenHIM really just passes through any HTTP request that you send it (much like a reverse proxy), but adds the ability to do authorisation checks, request logging and request orchestration as the request is transferred through the OpenHIM.

For your spike it would probably be best to use XDS.b to send in a document. Although we are currently talking about support for doing this via FHIR. Also, the OpenSHR can store any kind off document that you send it including plain text or a FHIR document, however, CDA would be best as them the OpenSHR can understand it and break the document down further. You are right that a data handler for a FHIR document could also be written if need be.

These system can be complex to get up and running together so should it you need some more help.

Cheers,

Ryan

On Fri, Oct 7, 2016 at 10:16 PM wyclif@openmrs.org wrote:

Thanks Jennifer! It turns out Openhim spawns several worker processes each listening on a separate port, it isn’t documented what requests should be forwarded to each port, I had to look at the test to realize that I had to direct my calls to port 5001 and not the same port number used by the console app that I had configured OpenHIM to listen on, I think it would be nice to document these details.
The MongoDB documentation doesn’t seem to mention that one needs to tell the server which folder to use for storage when starting it, so it kept on failing to start because I wasn’t specifying one, It would be nice to add this a side note to the step about installing MongoDB may be it could help others in the future. Otherwise the installation documentation seems pretty good, so good job guys! Keep it up.

Wyclif

On Friday, October 7, 2016 at 10:16:33 AM UTC-4, wyc...@openmrs.org wrote:

Hi,

I have a module that I worked on not so long ago with Regenstrief and CDC on case based reporting, the CDC wants us to do a spike on how to integrate the module into the HIE, the idea is that the module gets installed in an OpenMRS instance and will send a case report to the HIE for a given patient in form of a FHIR message when they match a certain criteria, saving it as a document in the SHR should be enough for demonstration purposes. I managed to set up OpenHIM and the console and I’m trying to figure out where to go next, below are some of the questions I have:

1- Can I turn off TLS authentication since this is a demo installation on a dev machine?
2- I understand that the HIE works with CDA documents and not FHIR, do you intend to support FHIR anytime soon? If not, is there a way I can plugin in something that can parse another message format? I also see that there is the concept of a data handler in the SHR, can I add my own FHIR handler to process a FHIR message when it gets to the SHR? Assuming it can go through the transport layer even if the transport layer can’t parse it.
3- Where is the documentation on how to make requests to OpenHIM? I read somewhere that communication is SOAP based, if this is true, what is the URL to fetch WSDL?

Thanks in advance

Wyclif

–

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

–

You received this message because you are subscribed to the Google Groups “OpenHIE Implementers Network (OHIN)” group.

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

To post to this group, send email to ohie-implementers@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/ohie-implementers/CABh-%2BTLzAoEuOaAFiZ9P_5Le0e32TzPeqBV1jdernb445FuFEA%40mail.gmail.com.

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

Carl_Fourie1 · October 12, 2016, 2:53pm

Hi Jamie

That sounds good, I’ve addded Tariro to add this to the comming call agenda

···

On Wed, Oct 12, 2016 at 3:08 PM, Jamie Thomas jamiethomas5670@gmail.com wrote:

@Ryan and Carl,

I am wondering if the case reporting team could have some time on an upcoming IL or SHR call to discuss details about our use case. Is there time available?

-Jamie

Regards
Carl Fourie
Senior Program Manager | Digital Health Division

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

Email Disclaimer:

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

On Mon, Oct 10, 2016 at 9:49 AM, Wyclif Luyima wyclif@openmrs.org wrote:

Hi,

Thank you all for your responses! @Ryan the getting started page you recommended is really helpful for somebody trying to set up OHIE for the first time.

To respond to Carl’s questions:

OpenHIE is actually what I expected it to be, i.e a deployed stack that allows you to consume services.

The IOL is kind of what I expected it to be, it would be nice to have the getting started tutorial Ryan mentioned on the main documentation page. And as I mentioned in one of my earlier posts, OpenHIM spawns several child processes listening on different ports, it’s not documented what requests each handles.

Thanks!

Wyclif

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

On Mon, Oct 10, 2016 at 4:25 AM, Carl Fourie carl@jembi.org wrote:

Hi Alvin

Thanks this is great, no not too simple. I think it is something that the DevOps community is happy to hear – @DevOp: looks like we are getting some input towards “What would make OHIE more ‘consumable’ by implementers”.

@All: interesting thought here: How does the OHIE community imagine the SHR (or what clinical data etc) would be configured in a deployment. What I’m getting to is that the use case mentioned is point click configure, I’m wondering how we would manage something (or should we even) from the SHR point of view?

–

Wyclif Luyima
Regenstrief Institute Inc.

Confidentiality
Notice: The contents of this message and any files transmitted with it may contain confidential and/or privileged information and are intended solely for the
use of the named addressee(s). Additionally, the information contained herein may have been disclosed to you from medical records with confidentiality protected by federal and state laws. Federal regulations
and State laws prohibit you from making further
disclosure of such information without the specific written consent of the person to whom the information pertains or as otherwise permitted by
such regulations. A general authorization for the release of medical or
other information is not sufficient for
this purpose.

If you have received this message in error, please notify the sender by return e-mail and delete the original message. Any retention, disclosure, copying, distribution or use of this information by anyone other than the intended recipient is strictly prohibited.

Regards
Carl Fourie
Senior Program Manager | Digital Health Division

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

Email Disclaimer:

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

On Mon, Oct 10, 2016 at 10:15 AM, Alvin Marcelo admarcelo@up.edu.ph wrote:

Hi Carl,

Naively, I would be looking for:

software to download and install

configuration instructions for this software (and the others it is supposed to connect with)

a webpage I can visit that tells me if things are working or which ones are broken.

Example:

We just conducted a connectathon for a PACS in our hospital and I would be looking for a similar experience for OpenHIE

After setting up the server on the LAN, the vendor entered the AE title, IP and Port of each node (CT, MRI, ultrasound) and they found each other and started exchanging images…we were up in an hour (most of the time consumed was going around and configuring the machines with the AE title, IP, port)…

Is this use case too simple?

alvin

On Mon, Oct 10, 2016 at 4:05 PM, Carl Fourie carl@jembi.org wrote:

Thanks all for the great contributions and discussions going on in this list and for bringing in the various communities. I think what we are seeing here is a great example where the OHIE DevOps community could come into play too (in making connecting to OHIE easier).

A few questions to the teams if you wouldn’t mind (I’m really looking for some open and honest feedback – even if it is along the lines of TLDR ;P)

@Wyclif: When looking at OpenHIE and or considering it, what is it to you? Or what do you expect it to be? for example: a deployed stack that allows you to consume services - relatively pre configured? or an architecture designed to let you understand how tools should fit together? etc

How has the IOL not been what you have expected? What are the thoughts about connecting to it?

What does the SHR do in your mind? What do you (as a dev / implementer) envisage you need to do to get it set up?

What top 3 things could we do with our documentation to make life easier? (don’t have to stop at 3 but what are the top things you’d wish you had seen 3 days ago)

@All: please feel free to also answer these questions too.

This is a “step-back” and review the experience and or perceptions of getting started with OpenHIE (please note that there aren’t any wrong answers) and especially looking at making OpenHIE more consumable by others.

–

You received this message because you are subscribed to the Google Groups “OpenHIE Implementers Network (OHIN)” group.

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

To post to this group, send email to ohie-implementers@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/ohie-implementers/CAFNRjWjgphQBfE26bbvpU6Q1E%2BTk2uzbvcfM9Wdbor6ngraq5g%40mail.gmail.com.

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

Alvin B. Marcelo www.alvinmarcelo.com

–

Regards
Carl Fourie
Senior Program Manager | Digital Health Division

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

Email Disclaimer:

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

On Mon, Oct 10, 2016 at 9:13 AM, Ryan Crichton ryan@jembi.org wrote:

Hi Wyclif,

There are some tutorials for the OpenHIM that you can follow in the docs that explain things is some more detail - http://openhim.readthedocs.io/en/latest/tutorial/1-getting-started.html

The OpenHIM really just passes through any HTTP request that you send it (much like a reverse proxy), but adds the ability to do authorisation checks, request logging and request orchestration as the request is transferred through the OpenHIM.

For your spike it would probably be best to use XDS.b to send in a document. Although we are currently talking about support for doing this via FHIR. Also, the OpenSHR can store any kind off document that you send it including plain text or a FHIR document, however, CDA would be best as them the OpenSHR can understand it and break the document down further. You are right that a data handler for a FHIR document could also be written if need be.

These system can be complex to get up and running together so should it you need some more help.

Cheers,

Ryan

On Fri, Oct 7, 2016 at 10:16 PM wyclif@openmrs.org wrote:

Thanks Jennifer! It turns out Openhim spawns several worker processes each listening on a separate port, it isn’t documented what requests should be forwarded to each port, I had to look at the test to realize that I had to direct my calls to port 5001 and not the same port number used by the console app that I had configured OpenHIM to listen on, I think it would be nice to document these details.
The MongoDB documentation doesn’t seem to mention that one needs to tell the server which folder to use for storage when starting it, so it kept on failing to start because I wasn’t specifying one, It would be nice to add this a side note to the step about installing MongoDB may be it could help others in the future. Otherwise the installation documentation seems pretty good, so good job guys! Keep it up.

Wyclif

On Friday, October 7, 2016 at 10:16:33 AM UTC-4, wyc...@openmrs.org wrote:

Hi,

I have a module that I worked on not so long ago with Regenstrief and CDC on case based reporting, the CDC wants us to do a spike on how to integrate the module into the HIE, the idea is that the module gets installed in an OpenMRS instance and will send a case report to the HIE for a given patient in form of a FHIR message when they match a certain criteria, saving it as a document in the SHR should be enough for demonstration purposes. I managed to set up OpenHIM and the console and I’m trying to figure out where to go next, below are some of the questions I have:

1- Can I turn off TLS authentication since this is a demo installation on a dev machine?
2- I understand that the HIE works with CDA documents and not FHIR, do you intend to support FHIR anytime soon? If not, is there a way I can plugin in something that can parse another message format? I also see that there is the concept of a data handler in the SHR, can I add my own FHIR handler to process a FHIR message when it gets to the SHR? Assuming it can go through the transport layer even if the transport layer can’t parse it.
3- Where is the documentation on how to make requests to OpenHIM? I read somewhere that communication is SOAP based, if this is true, what is the URL to fetch WSDL?

Thanks in advance

Wyclif

–

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

–

You received this message because you are subscribed to the Google Groups “OpenHIE Implementers Network (OHIN)” group.

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

To post to this group, send email to ohie-implementers@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/ohie-implementers/CABh-%2BTLzAoEuOaAFiZ9P_5Le0e32TzPeqBV1jdernb445FuFEA%40mail.gmail.com.

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

jthomas · October 12, 2016, 3:50pm

This call is October 18th at 10am, correct?

**Jamie Thomas **|****Health Information Project Manager/Communications

Center for Biomedical Informatics

1101 West Tenth Street

Indianapolis, IN 46202

Tel 317-274-9218 | Fax 317-274-9305

Email: jt48@regenstrief.org | Skype: jamie.thomas5670 | Twitter: @RegenstriefGHI

www.regenstrief.org

Confidentiality Notice: The contents of this message and any files transmitted with it may contain confidential and/or privileged
information and are intended solely for the use of the named addressee(s). Additionally, the information contained herein may have been disclosed to you from medical records with confidentiality protected by federal and state laws. Federal regulations and
State laws prohibit you from making further disclosure of such information without the specific written consent of the person to whom the information pertains or as otherwise permitted by such regulations. A general authorization for the release of medical
or other information is not sufficient for this purpose.

If you have received this message in error, please notify the sender by return e-mail and delete the original message. Any retention,
disclosure, copying, distribution or use of this information by anyone other than the intended recipient is strictly prohibited.

···

On Wed, Oct 12, 2016 at 3:08 PM, Jamie Thomas
jamiethomas5670@gmail.com wrote:

@Ryan and Carl,

I am wondering if the case reporting team could have some time on an upcoming IL or SHR call to discuss details about our use case. Is there time available?

-Jamie

Regards
Carl Fourie
Senior Program Manager | Digital Health Division

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

Email Disclaimer:

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

On Mon, Oct 10, 2016 at 9:49 AM, Wyclif Luyima
wyclif@openmrs.org wrote:

Hi,

Thank you all for your responses! @Ryan the getting started page you recommended is really helpful for somebody trying to set up OHIE for the first time.

To respond to Carl’s questions:

OpenHIE is actually what I expected it to be, i.e a deployed stack that allows you to consume services.

The IOL is kind of what I expected it to be, it would be nice to have the getting started tutorial Ryan mentioned on the main documentation page. And as I mentioned in one of my earlier posts, OpenHIM spawns several child processes listening on different ports,
it’s not documented what requests each handles.

Thanks!

Wyclif

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

On Mon, Oct 10, 2016 at 4:25 AM, Carl Fourie
carl@jembi.org wrote:

Hi Alvin

Thanks this is great, no not too simple. I think it is something that the DevOps community is happy to hear –
@DevOp: looks like we are getting some input towards “What would make OHIE more ‘consumable’ by implementers”.

@All: interesting thought here: How does the OHIE community imagine the SHR (or what clinical data etc) would be configured in a deployment. What I’m getting to is that the use case mentioned
is point click configure, I’m wondering how we would manage something (or should we even) from the SHR point of view?

–

Wyclif Luyima

Regenstrief Institute Inc.

Confidentiality Notice: The contents of this message
and any files transmitted with it may contain confidential and/or privileged information and are intended solely for the use of the named addressee(s). Additionally, the information contained herein may have been disclosed to you from medical records with
confidentiality protected by federal and state laws. Federal regulations and State laws prohibit you from making further disclosure of such information without the specific written consent of the person to whom the information pertains or as otherwise permitted
by such regulations. A general authorization for the release of medical or other information is not sufficient for this purpose.

If you have received this message in error, please notify the sender by return e-mail and delete the original message. Any retention, disclosure, copying, distribution or use of this information by anyone other than the intended recipient is strictly prohibited.

Regards
Carl Fourie
Senior Program Manager | Digital Health Division

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

Email Disclaimer:

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

On Mon, Oct 10, 2016 at 10:15 AM, Alvin Marcelo
admarcelo@up.edu.ph wrote:

Hi Carl,

Naively, I would be looking for:

software to download and install

configuration instructions for this software (and the others it is supposed to connect with)

a webpage I can visit that tells me if things are working or which ones are broken.

Example:

We just conducted a connectathon for a PACS in our hospital and I would be looking for a similar experience for OpenHIE

After setting up the server on the LAN, the vendor entered the AE title, IP and Port of each node (CT, MRI, ultrasound) and they found each other and started exchanging images…we were up in an hour (most of the time consumed was going around and configuring
the machines with the AE title, IP, port)…

Is this use case too simple?

alvin

On Mon, Oct 10, 2016 at 4:05 PM, Carl Fourie
carl@jembi.org wrote:

Thanks all for the great contributions and discussions going on in this list and for bringing in the various communities. I think what we are seeing here is a great example where the OHIE DevOps
community could come into play too (in making connecting to OHIE easier).

A few questions to the teams if you wouldn’t mind (I’m really looking for some open and honest feedback – even if it is along the lines of TLDR ;P)

@Wyclif : When looking at OpenHIE and or considering it, what is it to you? Or what do you expect it to be? for example: a deployed stack that allows you to consume services - relatively
pre configured? or an architecture designed to let you understand how tools should fit together? etc

How has the IOL not been what you have expected? What are the thoughts about connecting to it?

What does the SHR do in your mind? What do you (as a dev / implementer) envisage you need to do to get it set up?

What top 3 things could we do with our documentation to make life easier? (don’t have to stop at 3 but what are the top things you’d wish you had seen 3 days ago)

@All: please feel free to also answer these questions too.

This is a “step-back” and review the experience and or perceptions of getting started with OpenHIE (please note that there aren’t any wrong answers) and especially looking at making OpenHIE more
consumable by others.

–

You received this message because you are subscribed to the Google Groups “OpenHIE Implementers Network (OHIN)” group.

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

To post to this group, send email to
ohie-implementers@googlegroups.com.

To view this discussion on the web visit
https://groups.google.com/d/msgid/ohie-implementers/CAFNRjWjgphQBfE26bbvpU6Q1E%2BTk2uzbvcfM9Wdbor6ngraq5g%40mail.gmail.com.

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

Alvin B. Marcelo www.alvinmarcelo.com

–

Regards
Carl Fourie
Senior Program Manager | Digital Health Division

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

Email Disclaimer:

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

On Mon, Oct 10, 2016 at 9:13 AM, Ryan Crichton
ryan@jembi.org wrote:

Hi Wyclif,

There are some tutorials for the OpenHIM that you can follow in the docs that explain things is some more detail - http://openhim.readthedocs.io/en/latest/tutorial/1-getting-started.html

The OpenHIM really just passes through any HTTP request that you send it (much like a reverse proxy), but adds the ability to do authorisation checks, request logging and request orchestration as the request is transferred through the OpenHIM.

For your spike it would probably be best to use XDS.b to send in a document. Although we are currently talking about support for doing this via FHIR. Also, the OpenSHR can store any kind off document that you send it including plain text or a FHIR document,
however, CDA would be best as them the OpenSHR can understand it and break the document down further. You are right that a data handler for a FHIR document could also be written if need be.

These system can be complex to get up and running together so should it you need some more help.

Cheers,

Ryan

On Fri, Oct 7, 2016 at 10:16 PM wyclif@openmrs.org wrote:

Thanks Jennifer! It turns out Openhim spawns several worker processes each listening on a separate port, it isn’t documented what requests should be forwarded to each port, I had to look at the test to realize that I had to direct my calls to
port 5001 and not the same port number used by the console app that I had configured OpenHIM to listen on, I think it would be nice to document these details.

The MongoDB documentation doesn’t seem to mention that one needs to tell the server which folder to use for storage when starting it, so it kept on failing to start because I wasn’t specifying one, It would be nice to add this a side note to the step about
installing MongoDB may be it could help others in the future. Otherwise the installation documentation seems pretty good, so good job guys! Keep it up.

Wyclif

On Friday, October 7, 2016 at 10:16:33 AM UTC-4,
wyc...@openmrs.org wrote:

Hi,

I have a module that I worked on not so long ago with Regenstrief and CDC on case based reporting, the CDC wants us to do a spike on how to integrate the module into the HIE, the idea is that the module gets installed in an OpenMRS instance and will send a
case report to the HIE for a given patient in form of a FHIR message when they match a certain criteria, saving it as a document in the SHR should be enough for demonstration purposes. I managed to set up OpenHIM and the console and I’m trying to figure out
where to go next, below are some of the questions I have:

1- Can I turn off TLS authentication since this is a demo installation on a dev machine?

2- I understand that the HIE works with CDA documents and not FHIR, do you intend to support FHIR anytime soon? If not, is there a way I can plugin in something that can parse another message format? I also see that there is the concept of a data handler in
the SHR, can I add my own FHIR handler to process a FHIR message when it gets to the SHR? Assuming it can go through the transport layer even if the transport layer can’t parse it.

3- Where is the documentation on how to make requests to OpenHIM? I read somewhere that communication is SOAP based, if this is true, what is the URL to fetch WSDL?

Thanks in advance

Wyclif

–

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

–

You received this message because you are subscribed to the Google Groups “OpenHIE Implementers Network (OHIN)” group.

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

To post to this group, send email to
ohie-implementers@googlegroups.com.

To view this discussion on the web visit
https://groups.google.com/d/msgid/ohie-implementers/CABh-%2BTLzAoEuOaAFiZ9P_5Le0e32TzPeqBV1jdernb445FuFEA%40mail.gmail.com.

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

Carl_Fourie1 · October 13, 2016, 6:36am

Yes that is correct

···

On Wed, Oct 12, 2016 at 5:50 PM, Thomas, Jamie jt48@regenstrief.org wrote:

This call is October 18th at 10am, correct?

**Jamie Thomas **|****Health Information Project Manager/Communications

Center for Biomedical Informatics

1101 West Tenth Street

Indianapolis, IN 46202

Tel 317-274-9218 | Fax 317-274-9305

Email: jt48@regenstrief.org | Skype: jamie.thomas5670 | Twitter: @RegenstriefGHI

www.regenstrief.org

Confidentiality Notice: The contents of this message and any files transmitted with it may contain confidential and/or privileged
information and are intended solely for the use of the named addressee(s). Additionally, the information contained herein may have been disclosed to you from medical records with confidentiality protected by federal and state laws. Federal regulations and
State laws prohibit you from making further disclosure of such information without the specific written consent of the person to whom the information pertains or as otherwise permitted by such regulations. A general authorization for the release of medical
or other information is not sufficient for this purpose.

If you have received this message in error, please notify the sender by return e-mail and delete the original message. Any retention,
disclosure, copying, distribution or use of this information by anyone other than the intended recipient is strictly prohibited.

From: ohie-implementers@googlegroups.com on behalf of Carl Fourie carl@jembi.org

Date: Wednesday, October 12, 2016 at 10:53 AM

To: “jamiethomas5670@gmail.com” jamiethomas5670@gmail.com

Cc: “wyclif@openmrs.org” wyclif@openmrs.org, Alvin Marcelo admarcelo@up.edu.ph, Ryan <ryan@jembi.org >,
“openhie-interoperability-layer@googlegroups.com” <openhie-interoperability-layer@googlegroups.com >, “OpenHIE Implementers
Network (OHIN)” ohie-implementers@googlegroups.com, Tariro Mandevani tariro.mandevani@jembi.org

Subject: Re: [ohie-implementers] Re: Help needed to communcate with a HIE

Hi Jamie

That sounds good, I’ve addded Tariro to add this to the comming call agenda

–

You received this message because you are subscribed to the Google Groups “OpenHIE Implementers Network (OHIN)” group.

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

To post to this group, send email to
ohie-implementers@googlegroups.com.

To view this discussion on the web visit
https://groups.google.com/d/msgid/ohie-implementers/CAFNRjWgvF%2BRVRBW3DdtQZnXE2KxLo5MV-Krz8tGBgpHxcvyYOA%40mail.gmail.com.

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

Regards
Carl Fourie
Senior Program Manager | Digital Health Division

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

Email Disclaimer:

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

Regards
Carl Fourie
Senior Program Manager | Digital Health Division

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

Email Disclaimer:

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

On Wed, Oct 12, 2016 at 3:08 PM, Jamie Thomas
jamiethomas5670@gmail.com wrote:

@Ryan and Carl,

I am wondering if the case reporting team could have some time on an upcoming IL or SHR call to discuss details about our use case. Is there time available?

-Jamie

On Mon, Oct 10, 2016 at 9:49 AM, Wyclif Luyima
wyclif@openmrs.org wrote:

Hi,

Thank you all for your responses! @Ryan the getting started page you recommended is really helpful for somebody trying to set up OHIE for the first time.

To respond to Carl’s questions:

OpenHIE is actually what I expected it to be, i.e a deployed stack that allows you to consume services.

The IOL is kind of what I expected it to be, it would be nice to have the getting started tutorial Ryan mentioned on the main documentation page. And as I mentioned in one of my earlier posts, OpenHIM spawns several child processes listening on different ports,
it’s not documented what requests each handles.

Thanks!

Wyclif

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

On Mon, Oct 10, 2016 at 4:25 AM, Carl Fourie
carl@jembi.org wrote:

Hi Alvin

Thanks this is great, no not too simple. I think it is something that the DevOps community is happy to hear –
@DevOp: looks like we are getting some input towards “What would make OHIE more ‘consumable’ by implementers”.

@All: interesting thought here: How does the OHIE community imagine the SHR (or what clinical data etc) would be configured in a deployment. What I’m getting to is that the use case mentioned
is point click configure, I’m wondering how we would manage something (or should we even) from the SHR point of view?

–

Wyclif Luyima

Regenstrief Institute Inc.

Confidentiality Notice: The contents of this message
and any files transmitted with it may contain confidential and/or privileged information and are intended solely for the use of the named addressee(s). Additionally, the information contained herein may have been disclosed to you from medical records with
confidentiality protected by federal and state laws. Federal regulations and State laws prohibit you from making further disclosure of such information without the specific written consent of the person to whom the information pertains or as otherwise permitted
by such regulations. A general authorization for the release of medical or other information is not sufficient for this purpose.

If you have received this message in error, please notify the sender by return e-mail and delete the original message. Any retention, disclosure, copying, distribution or use of this information by anyone other than the intended recipient is strictly prohibited.

Regards
Carl Fourie
Senior Program Manager | Digital Health Division

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

Email Disclaimer:

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

On Mon, Oct 10, 2016 at 10:15 AM, Alvin Marcelo
admarcelo@up.edu.ph wrote:

Hi Carl,

Naively, I would be looking for:

software to download and install

configuration instructions for this software (and the others it is supposed to connect with)

a webpage I can visit that tells me if things are working or which ones are broken.

Example:

We just conducted a connectathon for a PACS in our hospital and I would be looking for a similar experience for OpenHIE

After setting up the server on the LAN, the vendor entered the AE title, IP and Port of each node (CT, MRI, ultrasound) and they found each other and started exchanging images…we were up in an hour (most of the time consumed was going around and configuring
the machines with the AE title, IP, port)…

Is this use case too simple?

alvin

On Mon, Oct 10, 2016 at 4:05 PM, Carl Fourie
carl@jembi.org wrote:

Thanks all for the great contributions and discussions going on in this list and for bringing in the various communities. I think what we are seeing here is a great example where the OHIE DevOps
community could come into play too (in making connecting to OHIE easier).

A few questions to the teams if you wouldn’t mind (I’m really looking for some open and honest feedback – even if it is along the lines of TLDR ;P)

@Wyclif : When looking at OpenHIE and or considering it, what is it to you? Or what do you expect it to be? for example: a deployed stack that allows you to consume services - relatively
pre configured? or an architecture designed to let you understand how tools should fit together? etc

How has the IOL not been what you have expected? What are the thoughts about connecting to it?

What does the SHR do in your mind? What do you (as a dev / implementer) envisage you need to do to get it set up?

What top 3 things could we do with our documentation to make life easier? (don’t have to stop at 3 but what are the top things you’d wish you had seen 3 days ago)

@All: please feel free to also answer these questions too.

This is a “step-back” and review the experience and or perceptions of getting started with OpenHIE (please note that there aren’t any wrong answers) and especially looking at making OpenHIE more
consumable by others.

–

You received this message because you are subscribed to the Google Groups “OpenHIE Implementers Network (OHIN)” group.

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

To post to this group, send email to
ohie-implementers@googlegroups.com.

To view this discussion on the web visit
https://groups.google.com/d/msgid/ohie-implementers/CAFNRjWjgphQBfE26bbvpU6Q1E%2BTk2uzbvcfM9Wdbor6ngraq5g%40mail.gmail.com.

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

Alvin B. Marcelo www.alvinmarcelo.com

–

Regards
Carl Fourie
Senior Program Manager | Digital Health Division

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

Email Disclaimer:

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

On Mon, Oct 10, 2016 at 9:13 AM, Ryan Crichton
ryan@jembi.org wrote:

Hi Wyclif,

There are some tutorials for the OpenHIM that you can follow in the docs that explain things is some more detail - http://openhim.readthedocs.io/en/latest/tutorial/1-getting-started.html

The OpenHIM really just passes through any HTTP request that you send it (much like a reverse proxy), but adds the ability to do authorisation checks, request logging and request orchestration as the request is transferred through the OpenHIM.

For your spike it would probably be best to use XDS.b to send in a document. Although we are currently talking about support for doing this via FHIR. Also, the OpenSHR can store any kind off document that you send it including plain text or a FHIR document,
however, CDA would be best as them the OpenSHR can understand it and break the document down further. You are right that a data handler for a FHIR document could also be written if need be.

These system can be complex to get up and running together so should it you need some more help.

Cheers,

Ryan

On Fri, Oct 7, 2016 at 10:16 PM wyclif@openmrs.org wrote:

Thanks Jennifer! It turns out Openhim spawns several worker processes each listening on a separate port, it isn’t documented what requests should be forwarded to each port, I had to look at the test to realize that I had to direct my calls to
port 5001 and not the same port number used by the console app that I had configured OpenHIM to listen on, I think it would be nice to document these details.

The MongoDB documentation doesn’t seem to mention that one needs to tell the server which folder to use for storage when starting it, so it kept on failing to start because I wasn’t specifying one, It would be nice to add this a side note to the step about
installing MongoDB may be it could help others in the future. Otherwise the installation documentation seems pretty good, so good job guys! Keep it up.

Wyclif

On Friday, October 7, 2016 at 10:16:33 AM UTC-4,
wyc...@openmrs.org wrote:

Hi,

I have a module that I worked on not so long ago with Regenstrief and CDC on case based reporting, the CDC wants us to do a spike on how to integrate the module into the HIE, the idea is that the module gets installed in an OpenMRS instance and will send a
case report to the HIE for a given patient in form of a FHIR message when they match a certain criteria, saving it as a document in the SHR should be enough for demonstration purposes. I managed to set up OpenHIM and the console and I’m trying to figure out
where to go next, below are some of the questions I have:

1- Can I turn off TLS authentication since this is a demo installation on a dev machine?

2- I understand that the HIE works with CDA documents and not FHIR, do you intend to support FHIR anytime soon? If not, is there a way I can plugin in something that can parse another message format? I also see that there is the concept of a data handler in
the SHR, can I add my own FHIR handler to process a FHIR message when it gets to the SHR? Assuming it can go through the transport layer even if the transport layer can’t parse it.

3- Where is the documentation on how to make requests to OpenHIM? I read somewhere that communication is SOAP based, if this is true, what is the URL to fetch WSDL?

Thanks in advance

Wyclif

–

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

–

You received this message because you are subscribed to the Google Groups “OpenHIE Implementers Network (OHIN)” group.

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

To post to this group, send email to
ohie-implementers@googlegroups.com.

To view this discussion on the web visit
https://groups.google.com/d/msgid/ohie-implementers/CABh-%2BTLzAoEuOaAFiZ9P_5Le0e32TzPeqBV1jdernb445FuFEA%40mail.gmail.com.

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