On January 1, 2008,
GOST R 52636-2006 was introduced - general provisions on the electronic medical history. As usual, this document doesn’t really explain anything, but you need to keep up with the times. And voluntarily-compulsory, this innovation is introduced into medical institutions.
With a cursory search on Habr, you can stumble upon a few articles:
Electronic case history. The theory for practice , affecting the security issues of this enterprise, and the article
Electronic medical records: let's look into the future or let's fantasize a little with offering a look at the problem from the patient.
Unfortunately, I am not an expert on usability, and this is essentially my personal opinion.
Also, I cannot give a comparative analysis of several software products - at the moment electronic medical records are not yet widespread. Here a special case is considered and an attempt is made to make generalized conclusions.
')
Also, this text does not pretend to criticize the professionalism of programmers.
So, to the point.
At the institute I once heard a wonderful phrase from an informatics teacher:
"The ideal medical device should have
just one button."
On the one hand, this phrase ironically describes the average level of computer literacy of medical personnel, on the other hand, it is a reminder that a 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 with respect to medical software.
Currently, there are personal computers in almost any institution, many even have local area networks, as a precursor to an electronic medical history. Without going into details, I just want to say the following: every corner (belonging to a subdivision) 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 word processor, with the exception of, perhaps, quite 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: the threshold of entry
When I first saw this software, my eyes went wide. For one simple reason: the abundance of icons, tabs, drop-down lists, checkboxes and other elements on the toolbar caused confusion, 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 staff of the department looked at it, swore under his breath and refused to use it. For a simple reason: filling in a simple diary (daily examination of the patient) took from 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 diary window, it was possible to examine the list of diagnoses and their ciphers from the
ICD 10 , get a list of the available medical stock, look at their annotations, get data from analyzes and research, and assignments of medicines and various studies were instantly available to nurses on the post and diagnostic staff. offices.
It would seem that all you can only dream of.
Even predictive text input.
By the way, the latter was abolished because it was an impossible task to teach him medical terminology and the richness of drug names.
Omitting a bunch of similar trifles, I want to note: for a year and a half, the program interface has undergone significant simplifications.
The window for creating the notorious diary from one and a half dozen input fields (separate for complaints, for each organ system, etc.) has been reduced to three. Various reference materials became available only from the main screen - because the need for them arose from the force a couple of times a month.
Second: work on convenience
Along with the simplification of the interface, means were also added that made 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 from any workplace in general).
Over time, the ability was added to create your own templates for medical history documents, 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.
Elements of text formatting were also added: working with line spacing, font size, text selection in bold, italic and underlined styles, which allowed printed documents to be readable.
Perhaps the introduction of personalized fish was a turning point when doctors moved from the technology “working with text in a text editor - copying into an electronic medical history” to work in the program itself.
Third: the dialogue between users and developers
Thanks to this important moment, the software has acquired not the form of “hold, use as you wish,” but rather quite good-looking forms and became convenient.
Of course, a certain percentage of doctors continued to work in a text editor, but this is by virtue of 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 “insecure user” level. And, as a rule, they rarely have time to read instructions and master complex software solutions.
In this text, the names, institutions and other exact data are
intentionally not mentioned.
I would also like to express my gratitude to those programmers who were engaged in, engaged and will be engaged in this issue.
Thank you for your attention, I hope that this text will be interesting for you. And at the best - it is useful to someone.