OCL Module isn't working (but boy was it easy to create a Test Results dictionary using OCL for OpenMRS...)

Software Add-on Modules
, ,
1

The MFE Squad is implementing the new Test Results UI, so we wanted to set up sample test data in the SPA environment. First we need a concept library.

We are blocked from adding our new dictionary via the OCL Module, because we can’t seem to get the OCL Module to properly install in https://openmrs-spa.org/openmrs/admin/index.htm

When we add the OCL Module from the Manage Modules page, we wait for a while then get a time-out error; then when we return to the Manage Modules page, the module appears there and shows up on the navigation page, but the options don’t work to click. They show this error: “The origin server did not find a current representation for the target resource or is not willing to disclose that one exists.” OCL OMOD Config Page error

I was able to use the production OCL for OpenMRS webapp to rapidly create a dictionary (check it out here); it only took ~15 mins to find and add over 170 concepts that I wanted! What made this especially nice was that I didn’t have to manually add the Set Members for lab panels (LabSets); when I added a panel, all the corresponding tests were automatically added to my dictionary.

Now we need to use the Subscription link in the Open Concept Lab Module so that I can subscribe to my new Dictionary (this workflow is demo’d in the video here).

@burke @dkayiwa @ibacher do you have any thoughts? Are we missing a step in how to install the OCL Module? We confirmed that the version available in the Add Modules admin page is the same as the latest version available in the Add Ons directory, and we do already have the OWA Module installed. We also tried restarting the server.

@michaelbontyes I know the MSF team just used this workflow recently. What OMRS Platform version are you on?

CC @suruchi @ball @jdick @raff

2

This is quasi-fixed. I say “quasi” because I can now load the pages, but it doesn’t seem to be actually registered with the OWA module. The problem I see in the logs is this:

ERROR - OwaActivator.contextRefreshed(131) |2021-01-14 15:13:22,102| Failed to deploy OWA from zip file: openconceptlab.owa
java.lang.NullPointerException
	at java.io.Reader.<init>(Reader.java:78)
	at java.io.InputStreamReader.<init>(InputStreamReader.java:72)
	at org.apache.commons.io.IOUtils.copy(IOUtils.java:1049)
	at org.apache.commons.io.IOUtils.toString(IOUtils.java:359)
	at org.openmrs.module.owa.impl.DefaultAppManager.installApp(DefaultAppManager.java:95)
	at org.openmrs.module.owa.activator.OwaActivator.contextRefreshed(OwaActivator.java:126)
	at org.openmrs.module.ModuleUtil.refreshApplicationContext(ModuleUtil.java:929)
	at org.openmrs.module.web.WebModuleUtil.refreshWAC(WebModuleUtil.java:866)
	at org.openmrs.web.Listener.performWebStartOfModules(Listener.java:656)
	at org.openmrs.web.Listener.performWebStartOfModules(Listener.java:635)
	at org.openmrs.web.Listener.startOpenmrs(Listener.java:266)
	at org.openmrs.web.WebDaemon$1.run(WebDaemon.java:42)

If anyone wants to dig into that a bit. I “fixed” this just by unzipping the owa file in the owa folder.

3

Alright, I’m more confident in what I’ve done now. It turns out that the OWA manifest wasn’t being copied into the final Zip archive which is why we were getting the NPE above. I fixed this locally on my machine and uploaded that version to openmrs-spa where (at least for me) the UI appears to be working again. I also opened a PR to fix this for the openconceptlab module.

2 Likes
4

FYI @mogoodrich - Burke thought you’d like to know about these updates we had to make to make the OCL Subscription module useable.

5

And it sounds like the OCL subscription module may need to be adapted to ignore retired mappings.

1 Like
6

I’d suggest the rule here might need to be a little more tailored, i.e., presumably we want the subscription module to retire retired mappings when they are retired in OCL so we can’t completely ignore them, but it probably makes sense to skip importing retired mappings that don’t already exist.

The problem here is that when a mapping does not exist, the openconceptlab module assumes that it’s not retired here, here, and here.

This should be pretty straight-forward to address. There are, I think, three options:

  1. The easiest to implement: We create the concept answer / set member / etc., but ensure that the “retired” property and “retired reason” are set properly. We also need to update the Item to ItemState.RETIRED in that case.
  2. We skip actually adding the item to the concept dictionary, but still return the audit-tracking Item from those functions. This is pretty straight-forward, but requires some investigation to ensure that it doesn’t break anything.
  3. We skip adding the item to the concept dictionary and the audit-tracking Item but returning null or some other sentinel value. This will require changes to the upstream code that assumes every call to saveMapping() results in a valid Item.
7

@ibacher, the issue is that OpenMRS does not track retired mappings (there’s no retired properties on concept_reference_map); OpenMRS just deletes mapping when they are not needed any longer, considering sophisticated terminology management out of scope for an EMR and leaving auditing of deleted mappings to dedicated terminology systems. That’s why I suggested we just ignore retired mappings.

Update Reading a little further, I see this isn’t just about mapping to reference terminologies, but other concept relationships (like answers). And, while OpenMRS doesn’t track deleted answers, I see your point that a retired answer “mapping” from OCL that introduces a new concept that itself is retired might be an edge case not properly handled by the module.

Given your choices, I think I’m advocating for option #3 (skipping adding items that are retired). It’s not an option to refactor the upstream code to skip these (i.e., process retired concepts, but don’t process retired mappings)?

1 Like