OpenMRS Development using Concept Dictionary Best-Practices

It's been a long time since I've blogged about an OpenMRS dev hint, so prepare to be hit by the firehose. If you're not a dev, you might want to skip this one. :-)

Are we there yet?

It's a pretty exciting time for the Mirebalais EMR team, as the hospital is going to see its first patients on Tuesday, and we're pushing out our final code fixes and features before "1.0"

I wanted to post a few pictures of the work we've been doing.

Here is our last daily standup before deploying the code. (If I look like I just woke up, well, it's because we moved them to 6am Seattle time for the week while some of the team was doing trainings in Haiti, and I had just woken up.)

Next up, are Mark and Nano pairing on deploying the final* code

* = it was "final" at the time, but of course we needed to make a few tweaks over the weekend :-)

More pics to come, of things that are more visually interesting than software developers. :-) (We may not look very exciting doing our day jobs, but we still deserve a little bit of glory...)

Working Efficiently

Patient Dashboard, current status

We haven't been very good at posting recently (okay...we've been terrible). But it's always a good time to pick up writing again, and since I'm the first poster in a while, I can talk about what we've been up to recently.

In a word, "working." In three words, "working very hard." And in three more, "getting lots done"! :-) But I should say more about how...

Belly of the beast

This week involves installing OpenMRS and PACS systems at Hôpital Universitaire de Mirebalais.  The Picture Archiving & Communication System (PACS) from McKesson will store radiology images from X-ray, CT, and ultrasound machines.  OpenMRS functionality will include patient information (ie.  demographics and radiology orders) and communicate with the PACS system via HL7 and Mirth.  Nick, Casey and I are having a productive week. Nick has a very similar style of mustache to another member of our team.

inline-block

This is probably old hat to css veterans, but, for someone like myself who last did hardcore html work in days of tables, it was a neat trick for me to learn.  On our login page the user is asked to select their location within the hospital.  To start out with, we had a simple selection list with all of the locations.  But, for improved usability, the actual design called for the locations to be grouped into three columns. I was prepping myself for an alignment nightmare when Alex showed me that it could be done simply by setting the "display" attribute to "inline-block".  This allows you to set each element as a fixed width, and, tada, you end up with aligned columns.

To get this...

... all we had to do was this...

<div id="sessionLocation">
       <% locations.each { %>
             <span class="locationOption" value="${it.id}">${ui.format(it)}</span>
       <% } %>
</div>


and

.locationOption {
    display: inline-block;
    font-size: 1em;
    padding: 3px 15px;
    width: 250px;
}

(Then you can just use some simple javascript to mimic selection list functionality)

I found a good article that discusses inline-block in greater detail:

What’s the Deal With Display: Inline-Block?

All right, I'm going to head back to work on the API now and stay out of the web layer as much as possible... :)

OpenMRS Style Tip: standardizing our DAOs, and avoiding data-level services

We've developed a new best-practice way of organizing services and DAOs in OpenMRS, and I wanted to share that here.

1. We should have one DAO class for every domain object, and the boilerplate code should be encapsulated in an abstract base class

2. A service can contain multiple DAOs, for related domain functionality:

3. The service methods should expose higher-level functionality, rather than just CRUD

Below are (long) code samples:

Pretty pictures

For a long time at the beginning of every software project, it seems like you can only really blog about technical stuff, which I'm sure gets boring for all the non-developers out there.

And while I could keep talking about maven modules and behavior-driven development until you fall asleep, we've finally arrived at the phase of the project where we'll start having actual pretty pictures to show. :-)

Here's our first pass at the login screen. Note that we're building in the idea of a "session location," mostly so when you start filling out forms, you don't have to keep saying where you are:

And here's our first pass at the homepage: (note that the list of apps a user actually sees depends on user privileges)

Since I can't end a blog post without some technical content, I should point out that these are much easier to develop now that we've started using Sass and Compass. If you've ever written CSS and you aren't using these tools, you've got to start, stat! (If you look at our omod/pom.xml and search for "compass" you'll see how we incorporated these into the build process.)