Implementing an EPR in a Hospital

Authors

Dr. Michael A . Shifrin

Title: Head of Medical Informatics Lab

Institution N.N Burdenko

Neurosurgerical Institutu, Russia

Email: [email protected]

Website: www.mml.ru

Principal Goals of EPR Implementation

There are different ways to develop best practices on the basis of specific knowledge and experience. One of them may be considered statistical. Its essence is to study similar cases in order to find general conclusions 'averaging' acquired knowledge. An alternative is to investigate only one, very complex and sophisticated case, to find general conclusions logically. The validity of these conclusions may then be guaranteed by the complexity of the case under investigation.

In the context of Medical Information Systems (MIS), this reasoning has been applied to present some best practices based on the experience of developing and implementing an isolated instance of an MIS: an EPR system for the N.N. Burdenko Neurosurgical Institute (EPR / NSI). The complexity of the implemented system is a result of the structure of NSI and the goals of the EPR project. As background information, the NSI has 300 neurosurgical beds; 40 intensive care beds; an outpatient department; a complete set of laboratory and diagnostic facilities and radiology and rehabilitation departments. The principal goals of implementing the EPR system for NSI were the following2-4:

+ to deliver information support for diagnostic and treatment process;

+ to deliver information support for numerous scientific investigations carried out by the NSI, and

+ to build the core of the future MIS intended to support all business processes in the institution.

Lesson One: Integrating Technology Support in the Life Cycle of the Information System

Any MIS project on a hospital-wide scale must be guided by integrated technology support throughout all stages of the life cycle of the Information System (IS), thus guaranteeing the evolutional development of the system. A technology solution of this kind – MEDSET – was developed as a part of the EPR / NSI project2-4.

Strictly speaking, this was not a lesson learned from the EPR / NSI project. It was rather an axiom for developers that was confirmed in the process of the EPR implementation.

Lesson Two: Data Organisation is Crucial for the Diagnostic & Treatment Process

Any MIS intended to support the diagnostic and treatment process in a hospital should preferably have a generation-oriented, rather than data use, organisation of data. This statement is based on the fact that internal data flows in a clinical environment are dramatically more intensive than in-and out-going flows and therefore play an extraordinary role in the self-organisation of the diagnostic & treatment process. From this point of view, medicine is an information-dependent type of human activity.

Another argument in favour of a generation oriented organisation of data is that the alternative, data-use oriented approach, is more adequate for institutions with advanced regulation of personnel activities, when main business processes are organised by regulatory documents rather than by internal data flows.

Lesson Three: Identify Business and Activity Processes

It is worthwhile to separate two kinds of processes running in medical institutions: business processes and activity processes. Business processes and their data organisation reflect an outer view on the activity of the institution. For example, every clinical institution has to admit patients, deliver basic and advanced blood tests, deliver plenty of diagnostic procedures, etc. These processes are common for many institutions and may be considered relatively stable.

On the other hand, activity processes and their organisation reflect an inner view on the activities of the institution – the organisation of personnel activities. Activity processes may be organised in many different ways they are unique for different institutions and are rather flexible.

Thereafter, the business process structure, a relatively stable one, may be represented in the IS by the database model as it is the component of an IS that has to be the most stable. The activity process structure, as a rather flexible one, may be represented in the IS by the interface model2-4 and program code – as they are the more flexible components of an IS.

Lesson Four: Formalise End-User Activities

MIS is the formalisation of end-users’ activities in their professional fields. This helps the developer to ensure that the end product will be accepted by the user. At the same time, developers have to realise that users are not informatics professionals and therefore will need to select ways of formalisation adequate to the users' goals.

Formalisation may concern different aspects of user activity. The developing of screen forms for data input requires searching for a balance between the parts of free-text fields and fields with a fixed list of allowed values. While a fixed list of values guarantees easy reporting and data analysis, the former ensures the completeness of patient descriptions. The most important consideration of these aspects is that the form must be usable. Another consideration in the formalisation process is the representation of real world workflows as a set of users' functions, as an inadequate set of users' functions may result in recording conflicting data to the database and, in the most severe cases, a rejection of the system.

Lesson Five: End-User Activity Determines MIS Development

The implementation and evolution of MIS is a "non-linear" process. This means that implementing and running MIS changes the informational environment that exists in the institution. These changes require, almost inevitably, changes in the MIS – and so on. Therefore, the development and implementation of any MIS is a "non-linear” process in its most profound sense – meaning it modifies its environment.

Combining lessons three and four, it may be said that end-user activity is the determining factor of the vector of MIS development. At the same time, it is necessary for system developers to predict users' requirements to some degree and to be ready to realise them. User requirements may be of various types. On one pole are placed minor – from the developer's viewpoint, but sometimes critical for the user – changes of screen forms. On the opposite pole, the developer may find requests for new user functions or even a family of connected functions. In any case, the base for the successful realisation of user requirements lies in integrated technology for systems development (as demonstrated in lesson one).

Lesson Six: EPR Implementation Should not Adversely Affect the Patient Treatment Process

The deployment of an EPR system may be considered as a "technological intervention" in the diagnostic and treatment process. Every medical institution has a unique diagnostic and treatment process, in which medical record-keeping is an integral feature. The use of an EPR system dramatically changes this, making it essential for it to be introduced in such a way that it has no adverse effects on the treatment of any patient.

An EPR should only have an indirect influence on medical technologies, changing organisational aspects of the diagnostic & treatment process, Such changes may both improve and impair the quality of treatment. Examples of "bad practices" may be found at the website of the EVAL working group of the European Federation for Medical Informatics (http://iig.umit.at/efmi).

Lesson Seven: Developers Must be Aware of Problems Affecting the Lifecycle of an IS

There are three main categories of problems arising in the lifecycle of an IS: technical, organisational and psychological – and developers are expected to resolve problems of all three. At every moment, one of these categories plays a key role in the IS. As a result, developers have to recognise and concentrate their efforts on them, while at the same time maintaining the balance between them.

Technical problems may be prevalent during the early stages of an EPR project, particularly at moments of rapid expansion ofthe system or in developing new options. Psychological problems become prominent during moments involving users with low computer literacy. Organisational problems dominate at instances involving a large body of new users, especially when users have no direct benefit of the use of the system. Therefore, developers should observe for possible tensions and take appropriate steps to resolve them if they do occur.

The Final Lesson:

♥Love the user! This lesson is the most important because it must be present on any list of best practices and recommendations for IS developers and because it integrates all of the other lessons learned.

Conclusion

These best practices; though non-exhaustive, are the most important lessons learned while developing and implementing the EPR system for the N.N. Burdenko Neurosurgical Institute. The validity of these lessons was evidenced by the complexity of the project. All of them were apparent in the development of the project and by the fact that the EPR / NSI has been successfully running and evolving since March 2000.