The content of an EMR captures data to serve many masters. These include payors, regulators, accrediting entities, researchers and the organization’s managers. Most of all, however, it must serve the work between client and clinician. In my previous blog, I wrote about the need to recruit a workgroup of clinicians with a broad array of clinical skills and homes. Then what? Well, the next step is to educate them about the technical underpinnings of the project, namely about databases.

In my experience the early leadership in software implementations comes from IT professionals. So, since you are reading this blog about electronic medical record implementation, I assume that you are probably pretty computer savvy and technically informed.  But let me plead with you to assume that the clinicians on the design workgroup are neither. Sure they email, write documents, Google and shop online, but most likely they do not understand what a database is. Since clinical documents are one of the main EMR outputs, they think that the EMR is some sort of giant MS Word document.  Thus they make comments such as “Why can’t you spell-check the whole thing at once?” and they expect to read the clinical information that has been entered by accessing the inputs screens rather than by viewing a report.

When considering data capture and, especially, information flow it is essential for the designers to grasp the database basics: that information is captured in various data types in input screens and stored in columns and rows in tables and that reports pull the information from any available table.  

I have shown many clinicians this simple database schematic. The frequent responses have been as if it were a revelation. They told me that now they “got it;” that they felt enlightened and empowered; and that they were eager to get going on the design task. And all it took was about half an hour.