Can Pen and Paper Help Make Electronic Medical Records Better?

I spotted this item in ACM TechNews. I thought it interesting because it resonates quite strongly with some of the ideas that led to the formulation of Shuffl.

---

Can Pen and Paper Help Make Electronic Medical Records Better?

IUPUI News Center (07/20/09) Aisen, Cindy Fox Using pen and paper occasionally can make electronic medical records even more useful to healthcare providers and patients, concludes a new study published in the International Journal of Medical Informatics. The study, "Exploring the Persistence of Paper with the Electronic Health Record," was led by Jason Saleem, a professor in the Purdue School of Engineering and Technology at Indiana University-Purdue University Indianapolis. "Not all uses of paper are bad and some may give us ideas on how to improve the interface between the healthcare provider and the electronic record," Saleem says. In the study of 20 healthcare workers, the researchers found 125 instances of paper use, which were divided into 11 categories. The most common reasons for using paper workarounds were efficiency and ease of use, followed by paper's capabilities as a memory aid and its ability to alert others to new or important information. For example, a good use of paper was the issuing of pink index cards to newly arrived patients at a clinic who had high blood pressure. The information was entered into patients' electronic medical records, but the pink cards allowed physicians to quickly identify a patient's blood pressure status. Noting that electronic systems can alert clinicians reliably and consistently, the study recommends that designers of these systems consider reducing the overall number of alerts so healthcare workers do not ignore them due to information overload.

-- http://technews.acm.org/archives.cfm?fo=2009-07-jul/jul-27-2009.html#421468

Full article: http://newscenter.iupui.edu/4121/Can-Pen-and-Paper-Help-Make-Electronic-Medical-Records-Better

Agile modelling and development

It has often bothered me a little that the early stages of a project seem to fly in the face of the "normal" agile mantra that all effort should be directed to satisfying a user story. But in early project stages, I find myself spending time on high-level design activities activities, and creating technical infrastructure, that of themselves do not directly contribute to a user story. I find myself wondering if that's because I'm too technically motivated to be a really effective agile developer. Recently, a colleague pointed me to an essay, Agile Model Driven Development (AMDD) [1], from which I take some considerable comfort. What is recognized here is that even for agile development, it can be appropriate to take some time (but not too much!) to perform "requirements envisioning" and "initial architecture envisioning", to "get a good gut feel what the project is all about" and to "identify an architecture that has a good chance of working". As always with agile development, the goal is "to get something that is just barely good enough so that your team can get going". This essay also says "For your architecture a whiteboard sketch overviewing how the system will be built end-to-end is good enough" - it seems to me that the important thing here, to be emphasized, is end-to-end (or: front-to-back). That is, to sketch a system that connects all the way from a front-end user to a back-end storage or service. Without really planning it, this approach is broadly what I've been doing in the early stages of Shuffl. In the light of this article, time I have spent, e.g., evaluating back-ends, even though the first iteration does not call for any persistence, does seem to be appropriate. As I near the end of the first iteration, I think I can say that having a view of what the back end may look like does help me to make decisions about how to structure aspects of the user interface code. An area where I've found my own practice of agile development has fallen down is poor estimation of effort and tasks. Getting the balance of granularity right for estimating is, I think, critical: too coarse a granularity and key elements are overlooked; too fine and the plans made don't reflect the actual development process when code has to be cut. Part of the problem here may be working alone, rather than part of a team, so that valuable discussion and review elements of the process are absent. Recommended reading! [1] Agile Model Driven Development (AMDD), by Scott Ambler. http://www.agilemodeling.com/essays/amdd.htm

Shuffl back-end selected

The initial back-end software for Shuffl has been selected and checked out. I'm planning to use AtomPub for the back-end protocol, and eXist as the back-end database. Rationale for the choice can be seen at http://code.google.com/p/shuffl/wiki/BackendSystemsSurvey. I've installed eXist (piece of cake!) and run a series of tests against the out-of-box installation to demonstrate the identified capabilities are all present. See http://code.google.com/p/shuffl/source/browse/#svn/trunk/spike.

Shuffl project lift off!

Shuffl takes off...

The project proposal, project plan, effort schedule, first sprint plan, and an initial draft of an open source sustainability are now online.

Read more at http://code.google.com/p/shuffl/w/list