Feedback on the SHR

Hi,

First of all, thanks for all the great work you’re doing, I’d also like to specifically thank Ryan for helping me with OpenHIE set up details in our efforts here at Regenstrief with CDC to evaluate and demonstrate integration of case-based surveillance with an HIE. A while back I was able to setup an OpenHIE instance that has OpenHIM and OpenSHR (OpenMRS+SHR modules+OpenXDS), recently I was also able play around with submitting and querying documents to and from the repository when am channeling my requests through OpenHIM. Of course I ran into some issues that I wanted to share with the community.

  • The current versions of the SHR modules were built on top of a ‘ghost’ OpenMRS version, i.e the revision the api and war files were build from is doesn’t exist in the OpenMRS github repository. I had to make fixes to some of the module to run on a released version version (I think 1.11.5 being the maximum required). Of course I ended making changes to all 5 modules to change versions of their dependencies since some depend on others. I issued pull requests that you can find in their respective github repos, it would be nice to have these pull requests reviewed and if all is well get merged so we can have new versions released.

  • I couldn’t seem to find any documentation on what typeCode-formatCode combinations in the xds.b provide and register transaction that I needed to set in order for the submitted cda documents to be parsed by the cda handler, I needed to peek at this code to find them, it would be nice to document them. Also one of those typeCode-formatCode entries has an asterisk for the typeCode which one can interpreted as match on any code in the given coding scheme but didn’t work unless I set my code to actually being an asterisk which I found strange, one of my pull requests has a fix for this to treat it as match on anything, can you confirm what if this was the intended behavior?

  • The cda handler module has a list of possible processors for each element in a cda document and they are matched to specific templates and codes, again I had to peek at the code to know the template ids to set and what the structures of my generated cda elements should look like, I think it would be nice to document the supported template ids and codes along with example templates.

  • Sometimes one might want to submit observations that have numerics values that are floating point numbers with no units, REAL seems like a fitting datatype in the everest library which is used by the cda handler module but isn’t currently supported, I ended up using INT because anyways I was submitting values that are not floating point but actually in OpenMRS obs numeric values are recorded as doubles and the digits after the decimal point can be of high significance sometimes so it wouldn’t be an option to discard them, I can create a pull request to support REAL, what do you think?

I know some of these might be because I didn’t do enough searching for the relevant documentation.

Otherwise thanks again for the great work!

Wyclif

Hi Wyclif,

I believe this was posted a while back, but it probably got lost in the thread. The attached spreadsheet has the terminology references, templates (document, section and entry). Those in green are level 3 import, those in orange are level 2 only.

Also there is a PDF which documents the SHR module. I have attached it as well.

Cheers

-Justin

Templates and RMIMs.xlsx (2.42 MB)

Clinical Document Architecture Support for OpenSHR.pdf (1.78 MB)

···

On Wednesday, February 22, 2017 at 6:42:12 PM UTC-5, wyc...@openmrs.org wrote:

Hi,

First of all, thanks for all the great work you’re doing, I’d also like to specifically thank Ryan for helping me with OpenHIE set up details in our efforts here at Regenstrief with CDC to evaluate and demonstrate integration of case-based surveillance with an HIE. A while back I was able to setup an OpenHIE instance that has OpenHIM and OpenSHR (OpenMRS+SHR modules+OpenXDS), recently I was also able play around with submitting and querying documents to and from the repository when am channeling my requests through OpenHIM. Of course I ran into some issues that I wanted to share with the community.

  • The current versions of the SHR modules were built on top of a ‘ghost’ OpenMRS version, i.e the revision the api and war files were build from is doesn’t exist in the OpenMRS github repository. I had to make fixes to some of the module to run on a released version version (I think 1.11.5 being the maximum required). Of course I ended making changes to all 5 modules to change versions of their dependencies since some depend on others. I issued pull requests that you can find in their respective github repos, it would be nice to have these pull requests reviewed and if all is well get merged so we can have new versions released.
  • I couldn’t seem to find any documentation on what typeCode-formatCode combinations in the xds.b provide and register transaction that I needed to set in order for the submitted cda documents to be parsed by the cda handler, I needed to peek at this code to find them, it would be nice to document them. Also one of those typeCode-formatCode entries has an asterisk for the typeCode which one can interpreted as match on any code in the given coding scheme but didn’t work unless I set my code to actually being an asterisk which I found strange, one of my pull requests has a fix for this to treat it as match on anything, can you confirm what if this was the intended behavior?
  • The cda handler module has a list of possible processors for each element in a cda document and they are matched to specific templates and codes, again I had to peek at the code to know the template ids to set and what the structures of my generated cda elements should look like, I think it would be nice to document the supported template ids and codes along with example templates.
  • Sometimes one might want to submit observations that have numerics values that are floating point numbers with no units, REAL seems like a fitting datatype in the everest library which is used by the cda handler module but isn’t currently supported, I ended up using INT because anyways I was submitting values that are not floating point but actually in OpenMRS obs numeric values are recorded as doubles and the digits after the decimal point can be of high significance sometimes so it wouldn’t be an option to discard them, I can create a pull request to support REAL, what do you think?

I know some of these might be because I didn’t do enough searching for the relevant documentation.

Otherwise thanks again for the great work!

Wyclif

Thanks Justin, those documents are really helpful to someone new to OpenSHR, why are they not included in the documentation pages on the wiki?

···

On Wednesday, February 22, 2017 at 9:51:49 PM UTC-5, Justin (Mohawk College) wrote:

Hi Wyclif,

I believe this was posted a while back, but it probably got lost in the thread. The attached spreadsheet has the terminology references, templates (document, section and entry). Those in green are level 3 import, those in orange are level 2 only.

Also there is a PDF which documents the SHR module. I have attached it as well.

Cheers

-Justin

On Wednesday, February 22, 2017 at 6:42:12 PM UTC-5, wyc...@openmrs.org wrote:

Hi,

First of all, thanks for all the great work you’re doing, I’d also like to specifically thank Ryan for helping me with OpenHIE set up details in our efforts here at Regenstrief with CDC to evaluate and demonstrate integration of case-based surveillance with an HIE. A while back I was able to setup an OpenHIE instance that has OpenHIM and OpenSHR (OpenMRS+SHR modules+OpenXDS), recently I was also able play around with submitting and querying documents to and from the repository when am channeling my requests through OpenHIM. Of course I ran into some issues that I wanted to share with the community.

  • The current versions of the SHR modules were built on top of a ‘ghost’ OpenMRS version, i.e the revision the api and war files were build from is doesn’t exist in the OpenMRS github repository. I had to make fixes to some of the module to run on a released version version (I think 1.11.5 being the maximum required). Of course I ended making changes to all 5 modules to change versions of their dependencies since some depend on others. I issued pull requests that you can find in their respective github repos, it would be nice to have these pull requests reviewed and if all is well get merged so we can have new versions released.
  • I couldn’t seem to find any documentation on what typeCode-formatCode combinations in the xds.b provide and register transaction that I needed to set in order for the submitted cda documents to be parsed by the cda handler, I needed to peek at this code to find them, it would be nice to document them. Also one of those typeCode-formatCode entries has an asterisk for the typeCode which one can interpreted as match on any code in the given coding scheme but didn’t work unless I set my code to actually being an asterisk which I found strange, one of my pull requests has a fix for this to treat it as match on anything, can you confirm what if this was the intended behavior?
  • The cda handler module has a list of possible processors for each element in a cda document and they are matched to specific templates and codes, again I had to peek at the code to know the template ids to set and what the structures of my generated cda elements should look like, I think it would be nice to document the supported template ids and codes along with example templates.
  • Sometimes one might want to submit observations that have numerics values that are floating point numbers with no units, REAL seems like a fitting datatype in the everest library which is used by the cda handler module but isn’t currently supported, I ended up using INT because anyways I was submitting values that are not floating point but actually in OpenMRS obs numeric values are recorded as doubles and the digits after the decimal point can be of high significance sometimes so it wouldn’t be an option to discard them, I can create a pull request to support REAL, what do you think?

I know some of these might be because I didn’t do enough searching for the relevant documentation.

Otherwise thanks again for the great work!

Wyclif

From the templates doc you attached specifically the documents types sheet, I can see that some rows don’t define a typeCode nor a formatCode, in fact some don’t define any of them, how are these bank values supposed to be interpreted by the SHR? My guess was to match on any value but when I tested it doesn’t seem to be the case.

···

On Wednesday, February 22, 2017 at 9:51:49 PM UTC-5, Justin (Mohawk College) wrote:

Hi Wyclif,

I believe this was posted a while back, but it probably got lost in the thread. The attached spreadsheet has the terminology references, templates (document, section and entry). Those in green are level 3 import, those in orange are level 2 only.

Also there is a PDF which documents the SHR module. I have attached it as well.

Cheers

-Justin

On Wednesday, February 22, 2017 at 6:42:12 PM UTC-5, wyc...@openmrs.org wrote:

Hi,

First of all, thanks for all the great work you’re doing, I’d also like to specifically thank Ryan for helping me with OpenHIE set up details in our efforts here at Regenstrief with CDC to evaluate and demonstrate integration of case-based surveillance with an HIE. A while back I was able to setup an OpenHIE instance that has OpenHIM and OpenSHR (OpenMRS+SHR modules+OpenXDS), recently I was also able play around with submitting and querying documents to and from the repository when am channeling my requests through OpenHIM. Of course I ran into some issues that I wanted to share with the community.

  • The current versions of the SHR modules were built on top of a ‘ghost’ OpenMRS version, i.e the revision the api and war files were build from is doesn’t exist in the OpenMRS github repository. I had to make fixes to some of the module to run on a released version version (I think 1.11.5 being the maximum required). Of course I ended making changes to all 5 modules to change versions of their dependencies since some depend on others. I issued pull requests that you can find in their respective github repos, it would be nice to have these pull requests reviewed and if all is well get merged so we can have new versions released.
  • I couldn’t seem to find any documentation on what typeCode-formatCode combinations in the xds.b provide and register transaction that I needed to set in order for the submitted cda documents to be parsed by the cda handler, I needed to peek at this code to find them, it would be nice to document them. Also one of those typeCode-formatCode entries has an asterisk for the typeCode which one can interpreted as match on any code in the given coding scheme but didn’t work unless I set my code to actually being an asterisk which I found strange, one of my pull requests has a fix for this to treat it as match on anything, can you confirm what if this was the intended behavior?
  • The cda handler module has a list of possible processors for each element in a cda document and they are matched to specific templates and codes, again I had to peek at the code to know the template ids to set and what the structures of my generated cda elements should look like, I think it would be nice to document the supported template ids and codes along with example templates.
  • Sometimes one might want to submit observations that have numerics values that are floating point numbers with no units, REAL seems like a fitting datatype in the everest library which is used by the cda handler module but isn’t currently supported, I ended up using INT because anyways I was submitting values that are not floating point but actually in OpenMRS obs numeric values are recorded as doubles and the digits after the decimal point can be of high significance sometimes so it wouldn’t be an option to discard them, I can create a pull request to support REAL, what do you think?

I know some of these might be because I didn’t do enough searching for the relevant documentation.

Otherwise thanks again for the great work!

Wyclif

Hi Wyclif,

Thanks for posting this. I agree those document would be super useful to have more visible. I’ve added these to the github repository and added some text in the readme to point to these - https://github.com/jembi/openshr#cda-implementation-documentation

If you note any point where the documentation is lacking or missing add to it if you are able. It would be great to be able to build out the documentation a bit more.

I have also gone through your PRs and they mostly look good. Just one comment here - https://github.com/jembi/openmrs-module-shr-odd/pull/12#discussion_r102901451

Cheers,

Ryan

···

On Thu, Feb 23, 2017 at 5:21 PM wyclif@openmrs.org wrote:

From the templates doc you attached specifically the documents types sheet, I can see that some rows don’t define a typeCode nor a formatCode, in fact some don’t define any of them, how are these bank values supposed to be interpreted by the SHR? My guess was to match on any value but when I tested it doesn’t seem to be the case.

On Wednesday, February 22, 2017 at 9:51:49 PM UTC-5, Justin (Mohawk College) wrote:

Hi Wyclif,

I believe this was posted a while back, but it probably got lost in the thread. The attached spreadsheet has the terminology references, templates (document, section and entry). Those in green are level 3 import, those in orange are level 2 only.

Also there is a PDF which documents the SHR module. I have attached it as well.

Cheers

-Justin

On Wednesday, February 22, 2017 at 6:42:12 PM UTC-5, wyc...@openmrs.org wrote:

Hi,

First of all, thanks for all the great work you’re doing, I’d also like to specifically thank Ryan for helping me with OpenHIE set up details in our efforts here at Regenstrief with CDC to evaluate and demonstrate integration of case-based surveillance with an HIE. A while back I was able to setup an OpenHIE instance that has OpenHIM and OpenSHR (OpenMRS+SHR modules+OpenXDS), recently I was also able play around with submitting and querying documents to and from the repository when am channeling my requests through OpenHIM. Of course I ran into some issues that I wanted to share with the community.

  • The current versions of the SHR modules were built on top of a ‘ghost’ OpenMRS version, i.e the revision the api and war files were build from is doesn’t exist in the OpenMRS github repository. I had to make fixes to some of the module to run on a released version version (I think 1.11.5 being the maximum required). Of course I ended making changes to all 5 modules to change versions of their dependencies since some depend on others. I issued pull requests that you can find in their respective github repos, it would be nice to have these pull requests reviewed and if all is well get merged so we can have new versions released.
  • I couldn’t seem to find any documentation on what typeCode-formatCode combinations in the xds.b provide and register transaction that I needed to set in order for the submitted cda documents to be parsed by the cda handler, I needed to peek at this code to find them, it would be nice to document them. Also one of those typeCode-formatCode entries has an asterisk for the typeCode which one can interpreted as match on any code in the given coding scheme but didn’t work unless I set my code to actually being an asterisk which I found strange, one of my pull requests has a fix for this to treat it as match on anything, can you confirm what if this was the intended behavior?
  • The cda handler module has a list of possible processors for each element in a cda document and they are matched to specific templates and codes, again I had to peek at the code to know the template ids to set and what the structures of my generated cda elements should look like, I think it would be nice to document the supported template ids and codes along with example templates.
  • Sometimes one might want to submit observations that have numerics values that are floating point numbers with no units, REAL seems like a fitting datatype in the everest library which is used by the cda handler module but isn’t currently supported, I ended up using INT because anyways I was submitting values that are not floating point but actually in OpenMRS obs numeric values are recorded as doubles and the digits after the decimal point can be of high significance sometimes so it wouldn’t be an option to discard them, I can create a pull request to support REAL, what do you think?

I know some of these might be because I didn’t do enough searching for the relevant documentation.

Otherwise thanks again for the great work!

Wyclif

You received this message because you are subscribed to the Google Groups “Shared Health Record (OpenHIE)” group.

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

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

Ryan Crichton

Lead Developer, Jembi Health Systems | SOUTH AFRICA

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

Hi Ryan,

Thanks for merging the code, I have responded to your comment on the PR, how about the issue of the asterisk for typeCode used in the formatCode+typeCode map entry? See the code in the cda handler’s activator.

I’m also trying to add a CR, HW and possibly a FR to my OpenHIE demo, I understand that you’ve been working on setting up an OpenHIE demo yourself with these pieces, is there any package you’ve created that I can use? If not, which implementations of these would you recommend? I’m more interested in something simpler to setup and better documentation than a feature rich one but complex or not well documented.

Thanks!

Wyclif

···

On Fri, Feb 24, 2017 at 4:00 AM, Ryan Crichton ryan@jembi.org wrote:

Hi Wyclif,

Thanks for posting this. I agree those document would be super useful to have more visible. I’ve added these to the github repository and added some text in the readme to point to these - https://github.com/jembi/openshr#cda-implementation-documentation

If you note any point where the documentation is lacking or missing add to it if you are able. It would be great to be able to build out the documentation a bit more.

I have also gone through your PRs and they mostly look good. Just one comment here - https://github.com/jembi/openmrs-module-shr-odd/pull/12#discussion_r102901451

Cheers,

Ryan

On Thu, Feb 23, 2017 at 5:21 PM wyclif@openmrs.org wrote:

From the templates doc you attached specifically the documents types sheet, I can see that some rows don’t define a typeCode nor a formatCode, in fact some don’t define any of them, how are these bank values supposed to be interpreted by the SHR? My guess was to match on any value but when I tested it doesn’t seem to be the case.

On Wednesday, February 22, 2017 at 9:51:49 PM UTC-5, Justin (Mohawk College) wrote:

Hi Wyclif,

I believe this was posted a while back, but it probably got lost in the thread. The attached spreadsheet has the terminology references, templates (document, section and entry). Those in green are level 3 import, those in orange are level 2 only.

Also there is a PDF which documents the SHR module. I have attached it as well.

Cheers

-Justin

On Wednesday, February 22, 2017 at 6:42:12 PM UTC-5, wyc...@openmrs.org wrote:

Hi,

First of all, thanks for all the great work you’re doing, I’d also like to specifically thank Ryan for helping me with OpenHIE set up details in our efforts here at Regenstrief with CDC to evaluate and demonstrate integration of case-based surveillance with an HIE. A while back I was able to setup an OpenHIE instance that has OpenHIM and OpenSHR (OpenMRS+SHR modules+OpenXDS), recently I was also able play around with submitting and querying documents to and from the repository when am channeling my requests through OpenHIM. Of course I ran into some issues that I wanted to share with the community.

  • The current versions of the SHR modules were built on top of a ‘ghost’ OpenMRS version, i.e the revision the api and war files were build from is doesn’t exist in the OpenMRS github repository. I had to make fixes to some of the module to run on a released version version (I think 1.11.5 being the maximum required). Of course I ended making changes to all 5 modules to change versions of their dependencies since some depend on others. I issued pull requests that you can find in their respective github repos, it would be nice to have these pull requests reviewed and if all is well get merged so we can have new versions released.
  • I couldn’t seem to find any documentation on what typeCode-formatCode combinations in the xds.b provide and register transaction that I needed to set in order for the submitted cda documents to be parsed by the cda handler, I needed to peek at this code to find them, it would be nice to document them. Also one of those typeCode-formatCode entries has an asterisk for the typeCode which one can interpreted as match on any code in the given coding scheme but didn’t work unless I set my code to actually being an asterisk which I found strange, one of my pull requests has a fix for this to treat it as match on anything, can you confirm what if this was the intended behavior?
  • The cda handler module has a list of possible processors for each element in a cda document and they are matched to specific templates and codes, again I had to peek at the code to know the template ids to set and what the structures of my generated cda elements should look like, I think it would be nice to document the supported template ids and codes along with example templates.
  • Sometimes one might want to submit observations that have numerics values that are floating point numbers with no units, REAL seems like a fitting datatype in the everest library which is used by the cda handler module but isn’t currently supported, I ended up using INT because anyways I was submitting values that are not floating point but actually in OpenMRS obs numeric values are recorded as doubles and the digits after the decimal point can be of high significance sometimes so it wouldn’t be an option to discard them, I can create a pull request to support REAL, what do you think?

I know some of these might be because I didn’t do enough searching for the relevant documentation.

Otherwise thanks again for the great work!

Wyclif

You received this message because you are subscribed to the Google Groups “Shared Health Record (OpenHIE)” group.

To unsubscribe from this group and stop receiving emails from it, send an email to openhie-shr+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

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.

Hi Wyclif,

Sorry, I saw there was a question earlier about CDA document types with no format or type codes … The two document types medical summary and medical documents aren’t really useful templates to be “all on their own” usually a document (that I’ve seen) will be a higher level template.

Also, I think there was a fallback on the CDA handler module for templates (I believe it tries to import section level, I can’t recall).

Finally, there is a client module which I had started which can generate CDAs from OpenMRS. Recently (by stripping out CDA importing) I was able to get it to work on OpenMRS 1.8.2 and have basic client connectivity to MEDIC CR and ATNA from a vanilla OpenMRS system as well as an EMR deployed in PH. It was purely proof of concept, but it did reinforce the need for a cleaner set of client tools. In my spare time I will look at cleaning this code up and providing as a sample as well as providing a drop-in omod file.

Cheers

-Justin

···

On Friday, February 24, 2017 at 10:54:27 AM UTC-5, Wyclif Luyima wrote:

Hi Ryan,

Thanks for merging the code, I have responded to your comment on the PR, how about the issue of the asterisk for typeCode used in the formatCode+typeCode map entry? See the code in the cda handler’s activator.

I’m also trying to add a CR, HW and possibly a FR to my OpenHIE demo, I understand that you’ve been working on setting up an OpenHIE demo yourself with these pieces, is there any package you’ve created that I can use? If not, which implementations of these would you recommend? I’m more interested in something simpler to setup and better documentation than a feature rich one but complex or not well documented.

Thanks!

Wyclif

On Fri, Feb 24, 2017 at 4:00 AM, Ryan Crichton ry...@jembi.org wrote:

Hi Wyclif,

Thanks for posting this. I agree those document would be super useful to have more visible. I’ve added these to the github repository and added some text in the readme to point to these - https://github.com/jembi/openshr#cda-implementation-documentation

If you note any point where the documentation is lacking or missing add to it if you are able. It would be great to be able to build out the documentation a bit more.

I have also gone through your PRs and they mostly look good. Just one comment here - https://github.com/jembi/openmrs-module-shr-odd/pull/12#discussion_r102901451

Cheers,

Ryan

On Thu, Feb 23, 2017 at 5:21 PM wyc...@openmrs.org wrote:

From the templates doc you attached specifically the documents types sheet, I can see that some rows don’t define a typeCode nor a formatCode, in fact some don’t define any of them, how are these bank values supposed to be interpreted by the SHR? My guess was to match on any value but when I tested it doesn’t seem to be the case.

On Wednesday, February 22, 2017 at 9:51:49 PM UTC-5, Justin (Mohawk College) wrote:

Hi Wyclif,

I believe this was posted a while back, but it probably got lost in the thread. The attached spreadsheet has the terminology references, templates (document, section and entry). Those in green are level 3 import, those in orange are level 2 only.

Also there is a PDF which documents the SHR module. I have attached it as well.

Cheers

-Justin

On Wednesday, February 22, 2017 at 6:42:12 PM UTC-5, wyc...@openmrs.org wrote:

Hi,

First of all, thanks for all the great work you’re doing, I’d also like to specifically thank Ryan for helping me with OpenHIE set up details in our efforts here at Regenstrief with CDC to evaluate and demonstrate integration of case-based surveillance with an HIE. A while back I was able to setup an OpenHIE instance that has OpenHIM and OpenSHR (OpenMRS+SHR modules+OpenXDS), recently I was also able play around with submitting and querying documents to and from the repository when am channeling my requests through OpenHIM. Of course I ran into some issues that I wanted to share with the community.

  • The current versions of the SHR modules were built on top of a ‘ghost’ OpenMRS version, i.e the revision the api and war files were build from is doesn’t exist in the OpenMRS github repository. I had to make fixes to some of the module to run on a released version version (I think 1.11.5 being the maximum required). Of course I ended making changes to all 5 modules to change versions of their dependencies since some depend on others. I issued pull requests that you can find in their respective github repos, it would be nice to have these pull requests reviewed and if all is well get merged so we can have new versions released.
  • I couldn’t seem to find any documentation on what typeCode-formatCode combinations in the xds.b provide and register transaction that I needed to set in order for the submitted cda documents to be parsed by the cda handler, I needed to peek at this code to find them, it would be nice to document them. Also one of those typeCode-formatCode entries has an asterisk for the typeCode which one can interpreted as match on any code in the given coding scheme but didn’t work unless I set my code to actually being an asterisk which I found strange, one of my pull requests has a fix for this to treat it as match on anything, can you confirm what if this was the intended behavior?
  • The cda handler module has a list of possible processors for each element in a cda document and they are matched to specific templates and codes, again I had to peek at the code to know the template ids to set and what the structures of my generated cda elements should look like, I think it would be nice to document the supported template ids and codes along with example templates.
  • Sometimes one might want to submit observations that have numerics values that are floating point numbers with no units, REAL seems like a fitting datatype in the everest library which is used by the cda handler module but isn’t currently supported, I ended up using INT because anyways I was submitting values that are not floating point but actually in OpenMRS obs numeric values are recorded as doubles and the digits after the decimal point can be of high significance sometimes so it wouldn’t be an option to discard them, I can create a pull request to support REAL, what do you think?

I know some of these might be because I didn’t do enough searching for the relevant documentation.

Otherwise thanks again for the great work!

Wyclif

You received this message because you are subscribed to the Google Groups “Shared Health Record (OpenHIE)” group.

To unsubscribe from this group and stop receiving emails from it, send an email to openhie-shr...@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


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.

Thanks everyone for your responses, I guess what I wanted to know was the meaning of this entry in the format-typeCode mappings, why an asterisk? My guess was that it would match on any typeCode as long as the formatCodes match, which isn’t really the case.

Scott, when I get to the FR I’ll for sure reach out to you guys for help if needed, thanks!

Wyclif

···

On Wednesday, February 22, 2017 at 6:42:12 PM UTC-5, wyc...@openmrs.org wrote:

Hi,

First of all, thanks for all the great work you’re doing, I’d also like to specifically thank Ryan for helping me with OpenHIE set up details in our efforts here at Regenstrief with CDC to evaluate and demonstrate integration of case-based surveillance with an HIE. A while back I was able to setup an OpenHIE instance that has OpenHIM and OpenSHR (OpenMRS+SHR modules+OpenXDS), recently I was also able play around with submitting and querying documents to and from the repository when am channeling my requests through OpenHIM. Of course I ran into some issues that I wanted to share with the community.

  • The current versions of the SHR modules were built on top of a ‘ghost’ OpenMRS version, i.e the revision the api and war files were build from is doesn’t exist in the OpenMRS github repository. I had to make fixes to some of the module to run on a released version version (I think 1.11.5 being the maximum required). Of course I ended making changes to all 5 modules to change versions of their dependencies since some depend on others. I issued pull requests that you can find in their respective github repos, it would be nice to have these pull requests reviewed and if all is well get merged so we can have new versions released.
  • I couldn’t seem to find any documentation on what typeCode-formatCode combinations in the xds.b provide and register transaction that I needed to set in order for the submitted cda documents to be parsed by the cda handler, I needed to peek at this code to find them, it would be nice to document them. Also one of those typeCode-formatCode entries has an asterisk for the typeCode which one can interpreted as match on any code in the given coding scheme but didn’t work unless I set my code to actually being an asterisk which I found strange, one of my pull requests has a fix for this to treat it as match on anything, can you confirm what if this was the intended behavior?
  • The cda handler module has a list of possible processors for each element in a cda document and they are matched to specific templates and codes, again I had to peek at the code to know the template ids to set and what the structures of my generated cda elements should look like, I think it would be nice to document the supported template ids and codes along with example templates.
  • Sometimes one might want to submit observations that have numerics values that are floating point numbers with no units, REAL seems like a fitting datatype in the everest library which is used by the cda handler module but isn’t currently supported, I ended up using INT because anyways I was submitting values that are not floating point but actually in OpenMRS obs numeric values are recorded as doubles and the digits after the decimal point can be of high significance sometimes so it wouldn’t be an option to discard them, I can create a pull request to support REAL, what do you think?

I know some of these might be because I didn’t do enough searching for the relevant documentation.

Otherwise thanks again for the great work!

Wyclif