It is out of doubt that projects related to the electronic medical record (EMR) are the most difficult to realize. The digital replication of the paper-based file or the replacement of old systems with others following the same method do not create added value for doctors and nurses; on the contrary it requires a lot of engagement and time.
The aim of EMR software is to document doctors’ and nurses’ activity, either by inserting coded data and text and through specific functions such as the medicine prescription, their administration, the collection of vital parameters. Those softwares are composed of basic functions and a series of pages generally customised relating to context and specialisation, and users’ requirements.
Since an EMR can embrace several application areas, either in terms of medical specialisation and therapy field (admission, outpatient, territorial, chronic), designers and developers approach the matter by realising application platforms able to manage different types of information allowing easy and rapid configuration of pages, also thanks to the abstraction concept. Often, real “page designer” are employed by the technicians to realise the EMR forms.
The main limit of this approach is inherent the adopted concept of abstraction and generalization, which reflects the used programming technics. The EMR so becomes a “neutral” instrument which manages information without go inside the data. From the point of view of the clinical relevance, the laboratory tests are all identical, while drugs are “objects” with a code, an ATC code and one description.
The EMR does not include – with some exceptions – clinical concepts and then it is unable to actively supports doctors and nurses in their work. The user accesses the system, selects the patient he/her is caring, look for needed information and proceeds with his work. The EMR is a passive tool, where the user pulls what he needs from and reports what he is doing in.
Rarely the software manages a read data attribute, so evidencing which new data and information have been inserted, even from other users, as it happens in every email client. The lack of clinic knowledge, except few cases such as the allergies, make the software unable to evidence the most critical information from the others.
The main functions don’t consider the patient clinic conditions. During a medicine provision, for example, the system does not advise or evidence those parameters the doctor should consider for the medicine choice or dose, as the kidney insufficiency or the blood pressure.
The EMR is really effective when it is able to support the doctors’ or nurses’ work in a “proactive way”, signalling in a push mode the useful information, suggestions and advices on risks and help take the right choose with the patient health status. To obtain this result, the EMR “neutrality” has to replaced by a concept of “medicine inside” by inserting in the EMR the basic clinic concepts, differentiate the information, corelate them and make them available when needed.
Moreover, clinic decision support systems (CDSS) should be natively integrated at the most important functions level, in order to make available at the point of care all the medical evidences, guide lines and protocols contextualised on the patient health status.
All that means that EMR designers and developers should understand doctors, nurses and pharmacists needs. Only those professionals can supply for the necessary skills to evolve the software and make it a real supporting tool. In this case the EMR use, instead of being only an obligation for users, it can represent a precious “ally” to work better and avoid the risks of this work.
Digital-health 