Updated demo

Sorry for the lack of posts recently. I'm working on too many things simultaneously...

I updated the demo server this morning with the latest code, which includes a lot of UX fixes Bill and I discussed. We don't have the latest forms that Vincent has built in yet. I'll get to that as soon as I can.

Also, the demo server now has a new IP address:

https://69.91.227.20/openmrs
user: demo
pass: demo

Do we want a location hierarchy?

OpenMRS supports the idea of a location hierarchy. Is this something we want to use?

Imagine we do an installation at Amani Hospital. Is there any point in recording that certain encounters take place at different sub-locations? E.g. "Amani Hospital - Outpatient Clinic", "Amani Hospital - Outpatient Pharmacy", etc.

I'm assuming this is not helpful, but someone should let me know if they think it will be. :-)

The only reason I ask at all is because I've always sort-of wanted to use the feature, but never had a chance...

Default encounter dates and locations

A note to everyone who's working on HTML forms: make sure they all have the right default date and location set when being filled out, by doing something like this:

<encounterDate default="now" showTime="true"/><encounterLocation default="GlobalProperty:kenyaemr.defaultLocation"/>

It's important that we include times in our encounters, to support our point-of-care use case, and because if we don't set encounter times, they won't be assigned to visits correctly. (I just described this to Rajib in India on the OpenMRS developers list here.)


Getting the default location from a global property won't actually work until version 1.9.5 of HTML Form Entry is released, since I just made the fix today. (There are a bunch of open tickets in HFE 1.9.5, but I think we're going to need to push the versions back and release something including this specific fix before we deploy anywhere.)

Official Metadata Server

As of recently we have a VM set up to be our "Official Metadata" server. It lives at https://69.91.227.32/openmrs. (At some point this should move to Kenya, and get a real hostname.)

We will create the final "official" versions of all our metadata there. I.e. things like Visit Types, and Forms. The key point is that we'll generate all of our metadata sharing packages from this server, and only this server.

That means you shouldn't do anything on this server unless the item you create or edit is ready to deploy to production. If you need a login (Steven, George, Patrick, Jan) I believe that Jim or I can create one for you.

I've just created the first piece of info. Does it look right?

First-time Setup

We were talking about the facility registry again on Friday, and although we haven't yet decided exactly what subset we're going to load up into the system, we do know that we're building this EMR to run at a single facility, so the first time you run the system after installation, you need to configure that location.

I just added some code so that if the system isn't configured yet, the homepage redirects you to the First-Time Setup page.

At the moment the only setting to configure is what location we're installed at, but in the future we'll probably also want to enable or disable certain apps from there. For example we might want to decide whether or not to enable the "Triage & Vitals" app at installation-time, depending on whether there's a computer at that station in the actual facility.

On the docket for tomorrow is creating htmlformentry module tickets about allowing us to use this selected location in a few places. Like these:

<encounterLocation default="gp:kenyaemr.defaultLocation"/>
<lookup expression="fn.globalProperty('kenyaemr.defaultLocation')"/>

Offhand I'm not actually sure there's any way to access this in an HTML Form, and we're going to need to.

Also tomorrow (known as "today" in Kenya) I'll look at the work Vincent and Steven have done on the MoH 257 encounter form, and see if we can incorporate that into the codebase.

Alerts and the Calculation module

At OpenMRS we're about to release the Calculation module, which is good, because I've never enjoyed working with the Logic module. Today I incorporated the Calculation module and the Reporting module into our Kenya EMR module to dynamically produce our first alert: if the patient hasn't had a CD4 result in the last 180 days, you see a "Needs CD4" flag. (This is just a placeholder, I'm counting on the team in Kenya to decide what alerts we should actually be showing.)

This alert is dynamic!

It ended up taking all day, and I ended up duplicating some work I should have just copied from Mike Seaton's work on the calculation branch of the reporting module. Though it'll be even better when we finish making the reporting module support Calculations.

In any case, adding more alerts should be pretty straightforward.

You can see the commit here.

Apps and Privileges

Since we're about to show our demo to a wider audience, I figured it was about time for the App Framework module to let you limit apps to only certain users. I had originally planned for a table that would allow you to enable apps per-user or per-role, but after the OpenMRS design discussions around our recent Roles and Privileges sprint I decided it's a better idea to just let each app have a privilege, and use the standard Role mechanism to do access control.

Anyway, the ticket for this fix is here, and the code is here. This is now available in version 1.2 of the App Framework module.

Then I created a new version of our core metadata package including Clinician, Registration Clerk, and All Apps roles, only to find that there's a bug with Metadata Sharing and OpenMRS 1.9 when I try to import these into the demo server. I'll create a ticket for that tomorrow.

In the meantime I manually set up a role for the demo user on the demo server so they're no longer a superuser. We won't be showing the role-based apps yet, but at least not everyone will be able to upload modules to our demo server. :-)

Join us on the OpenMRS Developers Forum

Tomorrow (Thursday) we will be describing the project and some of our work to date at the OpenMRS Developers Forum. Join us!

We should be covering:

• About the project (Bill)
• Technical background and OpenMRS modules (Darius)
• MoH 257, the MVP/CIEL dictionary, etc (Steven)

If I knew how to attach a file on blogger, I'd upload my presentation slides...

[ Edit: uploaded to slideshare. ]

Uploading a new Software Version

Since I was working in the Admin section, and I mentioned uploading new versions of the module, I figured I should go implement that functionality.

Our end goal for this is for the system to automatically ping the official release server, download new versions when they're available, and prompt the local sysadmin to do a one-click install once they're in a position where a little downtime is acceptable. Unfortunately we need to do more work on the moduledistro module before we can get there.

For now, here's a quick implementation that lets you do a file upload.

Conveniently I got to fix a little bug along the way about not being able to put a @RequestParam annotation on a method parameter other than the file one.

User Management Screenshots

I still have a horrible cold, so if you don't like what I've done here, blame that! :-)

One of the strategies we are taking with this OpenMRS distribution to keep things maintainable as we scale up is that we will not let you access much of the rich configurability that OpenMRS has under the hood. The software updates we push out over time will contain "opinionated" configuration settings, and the user interface will only let a local system administrator modify the things they really need to locally modify.

So they'll see something like this: (we may add a few more actions, but not many)

I've now finished a first-pass at the user management pages, which also guide you through a limited set of functionality. (For example, you're not allowed to create a user account for an existing patient. A user is only allowed to have a single real name. Things like that.)

the Manage Users page

Creating a new user

Viewing an existing user

You can only edit subsets of a user's details per screen

Back to Work

Hi all, sorry for the radio silence. I was in Chicago all last week doing some planning for a related project. More on this at some future point, I hope.

Anyway, as of today I'm back to coding, though I also have a bad cold which is really killing my productivity. I blame the airplane.

I worked on letting the sysadmin create users, which also involved refactoring the "patientList" fragment into a more generic widget than can be used both for Patients and Users. The create user UI will be simpler and more limited than what OpenMRS provides. In particular I'm limiting the "New User" function to always create a new Person, i.e. it won't let you attach a user account to an existing Patient. Any thoughts on this? Hopefully I'll have this up and running midway through tomorrow.

On Thursday's OpenMRS developer call we'll be talking about the project, and showing our work-in-progress to the broader OpenMRS community. Before then I need to catch up with the Intellisoft devs about how mapping the MoH 257 forms to the MVP dictionary is working, and also see how we've decided to break down the paper form into multiple electronic forms for real-time electronic capture.

Assembling a zip file via Maven

Up until this point I've been manually assembling the distro zip file. It's not really that complicated (just putting the relevant version of OpenMRS module into a zip file) but it would really be better if it were automated, and anyone could do it without having any special knowledge.

I spent some time this weekend getting this scripted. I decided to do it using maven, because it seemed like the "right" thing to do, though, or maybe because I wanted to punish myself...

I added a "distro" maven module to the kenyaemr project.

First off, since the omod files for the modules we depend on are not checked into the maven repository, I used the antrun plugin to get them. (Unfortunately we need a custom build of the metadata sharing module until Rafal releases 1.0.8, so that is commented out.)

Then I use the resources plugin to copy the compiled kenyamr.omod from ../omod/target into a folder with all the downloaded omods, and I use the assembly plugin with a custom descriptor to zip up that folder.

I also wrapped the whole thing up in a profile that is activated when you set buildDistro=true. So the whole build is run as:

mvn -DbuildDistro=true package

I'd welcome any comments on ways to improve what I did. (See the code I checked in.) I'm sure there's a much more "elegant" way to do this with maven. (At the very least I don't need the resources plugin, because I can just have the assembly plugin get that file from ../omod/target.)

Demo is updated

A few days back I posted about having split things up into separate apps for the two different clinician workflows.

This is now up on the demo server:

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

Mapping MOH 257 to CIEL/MVP

I mentioned early on that we want to use the MVP/CIEL concept dictionary, because curating concept dictionary is a lot of work, and we should really be leveraging existing resources and expertise.

IntelliSOFT is just coming on board the project, and they're going to start by mapping the MOH 257 data elements to the MVP/CIEL dictionary. First off, you guys should say hi and introduce yourselves. :-)

It would be great to know if someone out there has already done the work of mapping MOH 257 to MVP/CIEL (or to another OpenMRS dictionary like AMPATH, or to SNOMED/ICD, ...) who could share that work with us. Anybody?

Anyway, I spoke with Andy Kanter today, and he suggested a process for how you should go about the mapping process. After typing it up in a private email, I figured it would be useful to post here, after the jump...

Clinicians have more than one workflow

Something that came up last week when Bill, Jan, and I went over the first demo UI was that clinicians probably need two different workflows for looking at patient charts.

First, there's the scenario where there's a patient standing in front of you in a consultation. You should definitely see existing high-value data items and alerts, but mostly you've got the chart open because you're going to be recording data about the current encounter.

Second is the scenario where you want to review the full history in the patient's chart. Most likely there's no patient physically in the room with you, and you want to see lots of information, but not necessarily record anything.

We'll definitely have to test the assumption that these are the relevant workflows, but for now I've tweaked the Kenya EMR module code to have two distinct apps. I'm calling the first "Medical Encounter" and the second "Medical Chart", though these are definitely subject to change.

Here are some screenshots. (I haven't uploaded this to the demo server yet.)

"Medical Encounter" limits your view to patients who have already been checked in by Registration.

"Medical Encounter" focuses on the current visit, and lets you see data collected so far in this visit.
(Still To-Do: some actual data entry forms for this workflow.)

"Medical Chart" lets you search among all patients (not just those checked in).