OHIE - eCODIRS integration

Skip to first unread message


Nov 4, 2014, 11:20:14 PM11/4/14
to ohie-ihe-s...@googlegroups.com
Hi all,

I am Maimoona from IHS working to integrate our OpenMRS based application with OHIE. We are extending CDA Generator module of openmrs to produce CDA documents and integrate it with RHEA SHR module to sync with OHIE. Our scope is Converting Birth , Death Reports and send it to OHIE. Attached is a sample document that our extended OpenMRS module has produced.

The document also mentions missing observations in text format. But looking into template document it appears that missing data does not need to be specified in CDA document. (http://www.ihe.net/uploadedFiles/Documents/QRPH/IHE_QRPH_Suppl_VRDR.pdf) .

We are also collecting data for Verbal Autopsies, and Cause of Death calculated from different external softwares (IRIS, InterVA). How would we share this data with OHIE.

Is there any document we can use to verify if our generated CDA doc is correct?

Your help would be appreciated.


Carl Fourie

Nov 5, 2014, 12:10:34 AM11/5/14
to ohie-ihe-s...@googlegroups.com, openhie-interop...@googlegroups.com, Ryan Crichton, Linda Taylor, Chris Seebregts, Hannes Venter
Hi Maimoona,

Thank you for reaching out, while I will leave space for friends to respond on this thread I would like to invite you to the OpenHIE Interoperability Layer group and as part of that our new initiative of Point of Care and Service application community. Our goals are to aid and support the adoption of openHIE workflows by tools such as OpenMRS and other POC / POS applications.

I have included a few of our technical team on this mail (Ryan and Hannes) to aid in supporting but would also invite you to use the interoperability layer mailing list for questions and support.

@Ryan C & @Hannes: any initial comments and responses to the questions in the mail?


Carl Fourie
Assistant Director of Programs, Jembi Health Systems |  SOUTH AFRICA
Mobile: +27 71 540 4477 | Office: +27 21 701 0939 | Skype: carl.fourie17
E-mail: carl....@jembi.org

You received this message because you are subscribed to the Google Groups "OHIE IHE SDO" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ohie-ihe-standar...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Ryan Crichton

Nov 5, 2014, 4:08:10 AM11/5/14
to Carl Fourie, ohie-ihe-s...@googlegroups.com, openhie-interop...@googlegroups.com, Linda Taylor, Chris Seebregts, Hannes Venter
Hi Maimoona,

Sounds like an interesting use case that you have. It seems like you are on the correct path. Although for the SHR, the RHEA SHR module won't work for you as it uses a custom format instead of CDA documents. Currently in OHIE we are using the IHE XDS.b profile to send and retrieve documents from the SHR. We have been (and are currently) developing modules for OpenMRS to support this standard. Have a look at the following modules:
By default the documents will be stored as blobs but you may want to import the data discretely. To do this you will have to write a new cdahandler module to import the documents that you are using. You can take a look at the cdahandler module above to get an idea of how this should work. 

For verbal autopsies and cause of death I'm sure you can use CDA documents to for these as well. It seems that the Vital Records Death Reporting (VRDR) profile that you linked to may help define some of this.

For validating your CDA I don't think there is anything to validate a VRDR completely but you could try the NIST CDA validation tool to get any idea if anything is out of place: http://cda-validation.nist.gov/cda-validation/validation.html

Hope this helps,

Ryan Crichton
Lead Developer, Jembi Health Systems  SOUTH AFRICA
Mobile: +27845829934 | Skype: ryan.graham.crichton
E-mail: ry...@jembi.org

Maimoona Kausar

Nov 6, 2014, 2:29:55 AM11/6/14
to ohie-ihe-s...@googlegroups.com, Carl Fourie, openhie-interop...@googlegroups.com, Linda Taylor, Chris Seebregts, Hannes Venter
Hi Ryan,

Thanks for the validation link, it helped identifying few repetitions in generated document.

I tried compiling and installing cda-handler and content-handler modules. For XDS.b I am assuming it is to make SHR repository and client applications donot need it.

content-handler doesnot show any effect in application while cda-handler allows to import a document which throws error attached.
Looking at the code it appears that cda-handler imports/parses a CDA doc sent I could not find and generator part there.OpenMRS CDA module generates (https://wiki.openmrs.org/display/projects/CDA+Generator+Module+Documentation) CDA doc similar to one I have shared before. What I am confused about is the role of client application and SHR itself. What we had in plan was to use OHIE as it is and send our data into OHIE repository so that it could be used across districts and could be integrated with other softwares if required in future.

http://srplite.ihsinformatics.com:6802/openmrs/admin/index.htm Our sample test app has CDA module installed here.

Thanks for your feedback.


You received this message because you are subscribed to a topic in the Google Groups "OHIE IHE SDO" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/ohie-ihe-standardsdev/u9XrpZHr5dU/unsubscribe.
To unsubscribe from this group and all its topics, send an email to ohie-ihe-standar...@googlegroups.com.

Ryan Crichton

Nov 12, 2014, 9:44:58 AM11/12/14
to ohie-ihe-s...@googlegroups.com, Carl Fourie, openhie-interop...@googlegroups.com, Linda Taylor, Chris Seebregts, Hannes Venter
Hi Maimoona,

Sorry for the late response. You are correct, those module that I linked you to are what are used in the OpenHIE SHR. You won't need those on the client side. The CDA generator module  that you are working with is the right thing to base your work off. You can use the OpenHIE SHR as is to store your data, however if you want the data to be stored discretely (optional) a new handler will have to be developed for the SHR to handle the specific type of document that you are sending to the SHR. At the moment we are working to support the APS documents discretely.

I hope this is clearer. Let us know if you have any more questions.

Reply all
Reply to author
0 new messages