Chart Search: NullPointerException when loading a patient with simple text observation

Hi,

We currently use a so-called Sticky Note on the Patient Header to attach a text observation to a patient. This observation does not have any encounter nor visit attached to it. It is simply a text note that the care provider can fill in at anytime to show important information on the Patient Header.

This Angular widget uses the Obs REST resource to save this very simple observation (see here)


But as soon as we create a new text obs (sticky note), we can not use the Chart Search which returns the following error:

java.lang.NullPointerException at org.openmrs.module.chartsearch.GeneratingJson.generateProvidersFromResults(GeneratingJson.java:611) at org.openmrs.module.chartsearch.api.impl.ChartSearchServiceImpl.addProvidersToJSONToReturn(ChartSearchServiceImpl.java:340) at sun.reflect.GeneratedMethodAccessor1084.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) …

See full log

This problem occurs with Chart Search: 1.4.1 1.4.2-SNAPSHOT 1.7 1.8-SNAPSHOT

@k.joseph any idea where to start to look at?

1 Like

I have no idea about the error, and haven’t looked, but I just wanted to say that I like this feature, and I think we should consider incorporating it in the reference application!

(Ideally we’d do this via an OWA in a way that lets other distros incorporate it too.)

The problem is clearly coming from the fact that the text observation is not associated with any encounter but then the Chart Search tries to read through all search results and retrieve each obs’s encounters

Can we add some custom config to the Chart Search to filter only obs with encounters?

@darius, thanks.

The next iteration of this feature will be extracted from our client customization module into its own OWA. We will also add a Sticky Note history page to let us navigate through all past Sticky Notes.

Actually, now that I think about it, the user could simply use the Chart Search (or any obs reporting system used) to see the history of Sticky Note. As soon as it can handle encounterless observations.

@mksrom can you use the current snapshot version of the module to see if all is well?

@dkayiwa, I haven’t tried on the snapshot version because my local environment was set up with the 1.x core and snapshot requires 2.x. I see that you’re are looking at it now! Thanks. Let me know if I can help in any way.

@mksrom am actually not looking at it now. Am simply waiting for your feedback whenever you will be able to try out the snapshot version of the module.

Thank you! Yes we can definitely do that. Here is what we would like to suggest:

  1. The actual widget, that is: an easy-to-edit text field for valueText-obs, would come as an Angular directive within UI Commons.

  2. The hooking, via a an extension point, of the above in Core Apps.

@ssmusoke, thoughts? I seem to remember that you suggested to deactivate the feature by default, and a GP would toggle it on/off, correct?

If this is an extension, then there’s already a mechanism for users to disable extensions, and we don’t need a GP for this. (This would require RA-923 to be done in the same release.)

Personally I think it’s fine if this functionality defaults to being enabled, if that makes things easier to implement.

When you create the actual ticket for this, make sure to at-mention jteich and burke for their inputs.

@dkayiwa, I have tried the latest snapshot and it seems to resolve the bug ! Thanks.

Chart Search 2.x seems not compatible with lower 1.x versions of the core, therefore I will need to back port in Chart Search 1.x branch. I’ll try and see if this works.

While it works fine now on snapshot, I experience a problem when the obs added contains a carriage return character, which is very often when using Sticky Note. This bug already reported here: CSM-127

When there is a multi-line text obs attached to a patient, the Chart Search fails to load.

It loads blank first:

and then when I hit ‘Search’, load an error page…

As explained on the JIRA issue CSM-127, it is reproducible on the OpenMRS online demo.

Hi @dkayiwa, thanks for having fixed the encounter-less obs problem. I have backported the fix in ealier version of the CS and it works just fine. :thumbsup: (I will create a 1.6.x branch with the fix).

One more thing, I still have the issue mentioned in the previous message: ‘Line break’ in free text observations will crash the Chart Search (CSM-127)

This bug affects all versions of the CS starting from 1.3.x up to the latest and is reproducible on the demo server (see the JIRA issue comments). And because of this, the Chart Search is almost not usable now. Very often the care provider will entrer a multi-line observation (for instance clinical note) and that will crash the CS.

@k.joseph

Hey all,

We are a bit worried about the community responsiveness when it comes to Chart Search. Could anybody come back to us on CSM-127?

@ssmusoke, is this a module that you intend to use in further versions of the Ref App? Is it in use at your implementation sites for instance? In which case it would surprise me if you never hit CSM-127.

@dkayiwa, I have also noticed that CS 2.0+ is only compatible with Platform 2.0+. Is it fair to just upgrade things like that without taking care of earlier versions of the Core/Platform? I thought that this was why compatibility interfaces were introduced. I seem to recall that PIH is still on Core 1.10.x for instance, we are on 1.11.x and are not in a position to upgrade in the short term.

We would be curious to hear your thoughts/comments on this. Thank you.

Thanks @mksd for raising these very important issues!

Last week, i attempted to look into CSM-127 but got distracted by other things. So am going to look at it again today.

As for CS 2.0+, i tried making the same module run on both platform 2.0 and below but did run into lots of class loading complications caused by the fact that platform 2.x uses newer versions of lucene than lower versions of the platform, and chartseach needed to align with a particular version. Therefore, i took the simpler route of bumping the module to version 2.0 and hence requiring lower platform versions to use a 1.x branch of the module. I had used the compatibility interfaces for a number of modules, but chartsearch had unique challenges because it was bundling a vital library which was already used by the platform. I found myself taking too much time without a break through, and hence decided to just keep it simple. If you have a solution to this, it will be awesome! :slight_smile:

Thanks for getting back to us. As long as CSM-127 is fixed… I think we can hold on. This is what renders CS not usable anymore. Your fix will have to be backported on a pre-2.0 branch, but we are happy to take care of that and release the ad-hoc version (I guess it’ll be something like 1.7).

About the Lucene issue: we haven’t looked into that at all. And I wish we could but we just have no time or resources for this kind of unexpected issues right now. As I said, we would like to put CSM-127 behind us and hopefully stick to a stable version of CS for a while.

We’ll be awaiting your feedback on that issue then. Thanks a bunch for prioritising it again! Really appreciated. :thumbsup:

@mksd i have just made a commit to the chartsearch module. Can you check if the bug is fixed?

1 Like