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. :-)