Medicine: electronic medical records - a view from the doctor

On January 1, 2008, GOST R 52636-2006 , general provisions on the electronic medical history, was introduced . As usual, this document does not really explain anything, but you need to keep up with the times. And on a voluntary basis, this innovation is introduced into medical institutions.

With a cursory search in Habr, you can stumble upon several articles: Electronic medical history. A theory for practice that touches upon the safety issues of this enterprise, and the article Electronic medical records: take a look into the future or imagine a little bit of imagination offering a look at the problem on the part of the patient.

Unfortunately, I am not an expert on usability, and this is essentially my personal opinion.
Also, I can not give a comparative analysis of several software products - at the moment, electronic medical records are not yet widespread. A special case is considered here and an attempt is made to draw generalized conclusions.

Also, this text does not claim to criticize the professionalism of programmers.

So to the point.

At the institute, from a computer science teacher, I once heard a wonderful phrase:
"An ideal medical device should have only one button."
On the one hand, this phrase ironically characterizes the average level of computer literacy of medical personnel, on the other hand, it is a reminder that the doctor should spend a minimum of time on mastering and working with equipment, and a maximum on the patient.
I am sure that this is quite true in relation to medical software.

At the moment, personal computers are in almost any institution, many even have local area networks, as the forerunner of the electronic medical history. Without going into details, I want to say only the following: every corner (belonging to a unit) of such a network is similar to a desktop - an outsider is unlikely to quickly find the documents he needs. And electronic medical records, from the point of view of the doctor, are designed to simplify and speed up the search for information on the patient.
At the moment, almost any doctor feels confident in any kind of word processor, with the exception, perhaps, of very respectable employees of pre-retirement age.

I had the opportunity to participate in the transition from a local network to an electronic medical history in the middle of the first year of residency. The software was developed by its own staff of programmers.

First: entry threshold

When I first saw this software, my eyes widened. For one simple reason: the abundance of icons, tabs, drop-down lists, checkboxes, and other elements on the toolbar were confused, and the panel itself occupied a third of the screen. It was more like a development environment than something designed to make a doctor’s life easier.
The department staff looked at this, mumbled under their breath and refused to use. For a simple reason: filling out a simple diary (daily examination of the patient) took 20 minutes or more, while filling out the “fish” took about 5 minutes.

The reason for this was an overabundance of potentially useful functionality.
From the window of working with the diary, one could study the list of diagnoses and their codes from ICD 10, get a list of the medicines available at the warehouse, look at their annotations, get analysis and research data, and the prescriptions of medicines and various studies were instantly available to nurses at the post and employees of the diagnostic departments.
It would seem that everything you can only dream of.
Even predictive text input.
By the way, the latter was abolished due to the fact that it was an impossible task to teach him medical terminology and the richness of drug names.

Omitting a bunch of such trifles, I want to note: in a year and a half the interface of the program has undergone significant simplifications.
The window for creating the notorious diary of one and a half dozen input fields (separate for complaints, for each system of organs, etc.) has been reduced to three. Various reference materials became available only from the main screen - because the need for them arose from strength a couple of times a month.

Second: convenience work

Along with simplifying the interface, tools have also been actively added that make life easier for the doctor.
Remark: this software was multi-user. Any doctor, using his account, could work with patient data from any workplace in his department (and later generally from any workplace).
Over time, the ability to create your own templates for medical history documents was added, and in several versions - designed for use by the entire department, a specific doctor or even for a specific patient, tied to a doctor’s account.
Also, elements of text formatting were added: work with line spacing, font size, text selection in bold, oblique and underlined styles, which allowed printed documents to be readable.

Perhaps the introduction of personal fish was a turning point when doctors switched from the technology “working with text in a text editor - copy-paste to the electronic medical history” to working in the program itself.

Third: dialogue between users and developers

Thanks to this important moment, the software did not take on the form of “hold, use as you like,” but rather pretty forms and became convenient.

Of course, a certain percentage of doctors continued to work in a text editor, but this is due to habit.

So, in conclusion, I would like to once again recall the "just one button." Yes, for the most part, doctors own a computer at the level of “uncertain user”. And, as a rule, they rarely have time to read instructions and master complex software solutions.

This text does not knowingly mention names, institution names, or other accurate information.

I would also like to express my gratitude to those programmers who worked, are engaged and will deal with this issue.
Thank you for your attention, I hope that this text will be of interest to you. And at best - it will come in handy for someone.