Fixing an OpenMRS module-loading bug (and the awesomeness of the UI Framework)

First off, I should say that developing the Kenya EMR module using the UI Framework has been awesome. Being able to add and modify controllers and views without having to redeploy the module is just a massive productivity boost. Particularly when it comes to adding ajax functionality, which is really not one of my fortés, it's great to be able to quickly add a method that returns some json, write some javascript to call it, and quickly tweak the json output because I got it wrong at first. :-)

However, since the UI Framework module is still beta, I occasionally need to make some tweaks. And I've been running into a really annoying OpenMRS bug (TRUNK-3384) where whenever I update the UI Framework module, it tries to restart other modules in the wrong order, and I end up having to manually restart the App Framework and Kenya EMR modules.

So, I finally got fed up, and decided to fix it. And I hope the couple of hours I spent on it pays for itself in reduced annoyance. :-)

Master Facility List

I don't love Wednesdays, because I have 4+ hours of scheduled calls. There's nothing wrong with any individual call, it's when you put them together...

Anyway, after 6 hours on the phone today, I figured I'd look into a smaller task, namely writing some code to upload the master Kenya Health Facilities List into OpenMRS so I could include it in our distro as a Metadata Sharing package.

So I opened the spreadsheet up for the first time and really looked at it. It's amazing to see that all this data is codified at all. But for some reason (lack of imagination I guess) I wasn't expecting to find 8110 facilities. So, pretty awesome. But I guess I'll need some guidance about what fraction of the facility list we actually include in the database...

Reworked the Registration App

I spent most of today reworking the registration app based on Bill and Jan's feedback from Friday. Originally I had devoted too much code and screen real estate to showing a patient's complete visit history, which is really not relevant to the main workflow of the front desk clerk. So I've simplified things.

Also I added a header bar that we'll use whenever there's a patient selected.

I updated the demo server--comments are welcome.

url: https://69.91.227.134/openmrs
user: demo
password: demo

The main To-Dos that I already know about are that:

1. the Create Patient page needs to be based on the MoH 257 form
2. we need Edit buttons on the patient and visit boxes on the left side

Here's a screenshot:

Check out our first demo!

Want to see a demo of the work we've been doing? Well, now you can!

url: https://69.91.227.134/openmrs
username: demo
password: demo

This is a first pass at wiring everything together. Bill, Jan, Jim, and I had some discussions today, and we have a list of UI changes that I'll work on next week. One key realization is that we probably want to split what I'd previously been thinking of as one "Medical Chart" app into two: one for the clinician to document the current visit, and another for in-depth review of a patient's full history.

Another next step is to actually incorporate the MoH 257 data points, rather than the placeholder ones (weight, height, BP) I put in.

Also, sadly, setting up the demo server wasn't quite as easy as I hoped. For some reason the metadata sharing package that included the HTML Form didn't install when I uploaded the distro zip, and I had to manually create it. I'll need to look into that soon, so that others can install this demo locally just by using OpenMRS standalone plus this zip file. :-)

Viewable progress! Development Site Now Hosted

As of yesterday, we now have a site hosted with a base installation of OpenMRS 1.9 RC4 and the MVP concept dictionary (pre-customization for the national Kenya implementation).  To be updated by Darius soon with the Kenya development.


Check it out at https://69.91.227.134/openmrs/

(Username and password coming shortly)

Overriding the OpenMRS homepage

I've seen some pretty ugly attempts to override the page you see when you go to .../openmrs/index.htm. And I was in the middle of doing yet another of those ugly attempts when I remembered "Mike has done this recently...".

And good thing I asked. It turns out to be as trivial as just doing this:

/**
 * Takes over /index.htm so users don't see the legacy OpenMRS UI
 */
@Controller
public class HomepageOverrideController {
 
 @RequestMapping("/index.htm")
 public String showOurHomepage() {
  return "forward:/pages/kenyaHome.page";
 }
 
}

No need to do a homepage portlet that does a client-side redirect, or any of the other ugly things I've seen done.

Thanks, Mike, for saving me time, and preventing ugly code.

PS- If you're doing this you should also override the login page at /login.htm

Let's do some User Interface!

Just a quick note to say that after doing a lot of back-end framework-y work for the last couple of weeks, this week I'm going to be working on some front-end user-facing workflows.

Eric is working on setting up a VM suitable for OpenMRS hosting, so hopefully by the end of the week you'll be able to see a non-wireframe demo of this image.