“May the Force be with you”...

In the medical world, the sentence should be “May the relevant medical information be with you, Doctor”! In our medical domain, the “Force” emerges when all critical information is timely available for expert advice. Clinicians are continuously generating data and are surrounded and forced to analyze a great deal of it. Data must be organized, structured and, most importantly, shared. Data sharing is a major component of a good medical practice.

Nevertheless, in real life, many clinicians function with non-optimized solutions leading to frustration: They take a great deal of their time to enter data (and often the same data repeatedly) into different programs and, the data are only used for administrative tasks (mainly printing reports) and archiving.

A modern clinical practice must go beyond simple data sharing through printed records: data are already entered in a computer. A modern practice should also include the ability to perform personal statistics as in-the-field clinical research. These tasks can be easily managed today thanks to available powerful data processing tools/database solutions. It is easy to summarize the interest of working through a well-designed database solution: “one input, multiple outputs”.

Health care administrators frequently advance implementation of such database tools as a modern assistance for physicians. Computerization of medical practice is moreover mandatory in response to the Health Care Administrator’s recurrent demand for continuous quality control. Resources and budget control are often a “masked” but understandable objective.

Electronic Medical Record (EMR) and the correlate, a data processing tool or a “Solution” built through a database application is likely to play an essential role in any modern health care system.¹ A report of the American College of Cardiology/American Heart Association task force on clinical data standards has been published² and highlights the importance of straightforward written communication in our medical field.
Practical benefits of computerization for a cardiovascular practice have previously been described.³ Colleagues already working with such database solutions also report positive experiences.⁴ Nevertheless, at the time of moving to computerization, clinicians are often left alone in face of vendors or administrators when they have to argue for or against implementation of the proposed database solution.

We would like to help by outlining a few principles that must be kept in mind when designing or considering the use of such proposed medical data processing solutions. For illustration purposes, “snapshots” taken from a database designed for in-the-field evaluation of the systematic use of the radial artery access for coronary angiography and interventions will be displayed.

Five “elements” compose the world of a computerized medical business.

1. The “datamed”
2. The database application(s)
3. The institutional Informatics Service (IS)
4. The medical staff (doctors, nurses, technologists, secretaries, etc.)
5. The electronic medical record (EMR)

The last two items will not be specifically discussed but their place will be easily understood from the description of the remaining three.

1. The Datamed

Like converting media from analog to digital, moving from a paper chart system to a true computerized medical record requires conversion of the written information (words/text) to a “digitized” material. This step is fundamental, requires an active professional intervention and is not a simple “copy & paste” process. This elementary step, largely missing in commercially available EMR systems, must be well understood and implemented.

The elementary unit of the digitized material in the imaging world is the pixel. For Medicine, the unit will be what the author calls “a datamed”. The datamed represents one unit or one piece of medical information. Requiring active intervention from the caregiver, the datamed must comply with some characteristics: the datamed is unique, universal, concordant, and has its own utility.

1. Datamed is “unique”

Datamed can be shared, displayed on multiple screens, and be accessed/edited from several locations within the database and by different people. However, a datamed remains unique, indivisible and provides a specific piece of information. It is the elementary unit. Its contents may take multiple forms, from administrative (like a chart number), to technical (like the wire used for crossing a coronary lesion or the brand name of a vascular sheath), to clinical (like the presence of a cardiac murmur). It can be a number, a text, the result of a calculation or a statistic; it can refer to different fields such as the nursing or billing (Figure 1 & 2).

Figure 1 Ex of datamed : Administrative (chart Number), technical (Text-brand name), Result of a calculation (patient’s age), score for assesment of technical ease during the procedure (number), Medical comment (‘final comments ’, free text).

Figure 2 In a few clicks, specific data are captured : art.accsee, sheath size, hydrophilic or not material, short or not and wrist size ; 8 datamed are ‘check-box like’ allowing direct statistics ; each datamed is unique and ‘universal’.

2. Datamed is universal

Datamed, as much as possible, must be universal and self-explanatory within the medical field. This property allows the datamed to travel within institutions and from country to country: being universal, datamed is easy to understand, self-explanatory and should not require definition or explanation. Benefits of a universal datamed could result in shorter learning curves (for new workers), an easy way for standardizing working flow through different services/institutions, and ultimately easy data sharing.

3. Datamed has its own and specific utility

Whatever its nature, datamed must always be useful and pertinent to the global composition. If a piece of “information” is not to be used at all in the real professional world, workers should not be encumbered with this data. This characteristic represents the best way to obtain record completeness and data consistency. The utility of the datamed must evidently relate to the medical task to be computerized and has to be edited by the most appropriate worker for that piece of information. Simply said, the datamed must be useful and as useful as the database to which it belongs (principle of utility).

In the same order of idea, we introduce another principle: the principle of equivalence. This principle relates to the general “workload” of a given task. When computerizing a medical activity, the new solution may not add to the usual (or previous) workload. Furthermore, if an additional new task is put forward (e.g., a database for assessing the ease of radial access for coronary angiography and intervention), it is better to provide a good justification (principle of utility) for the extra work required. In the same way, it is also better to make the new editing process as efficient and as effortless as possible. In our example, adding the task of editing a new record in the radial access database takes less than 2minutes and allows the clinician to review the data at any time. This gives a personal benefit and is a good way to enhance motivation and thereby increase report completeness.

The datamed utility must relate to the final purpose of the database. For example, presence of an S3 is probably not the first datamed to be included in a solution build for general practitioners practicing in an emergency department but it is of prime importance for a heart failure clinic database solution.

4. Datamed is “concordant”

“Natural” agreement between colleagues or “concordance” is obtained when the process of editing the right value/data for a given datamed is straightforward: the choice must be easy, keeping subjective appreciation as minimal as possible. Agreement or concordance is a prerequisite for the reliability of databases. Reliability thereafter allows strong statistics and eases the process of good clinical decisions.

The design of the user interface or the way the datamed will be displayed on-screen should help to achieve data concordance. For example, a lot of (useful) technical data may be presented as checkboxes (Figure 3), pop-up lists or menus, if the list is not too large (Figure 4). One of the skills of developers relies in their ability to define and group datamed in such a way that the most appropriate person accomplishes with concordance and completeness the editing process. Accordingly, it is easy to understand that such a concordance will be easier to achieve when “developers” have training in the medical field. The medical staff should at the very least be involved in the design of the different working screens.

Figure 3 Concordance obtained by ‘fixed’ choices : check box for assessing radial pulse.

Figure 4 Data entering by a LIST, useful for concordance when only a few choices are present, like the list of workers (tech, nurses, Mds).

2. The database application (“app”)

It is the software used to build an electronic medical record (EMR) system. Large informatics companies sell “solutions” based on their database application running in the background. Many medical devices are bundled with their specific “app”: they are often more problematic than useful from our point of view, firstly because these proprietary app doesn’t “talk” to others (see below). As just described therein, the datamed must remain the main app building resource. The intrinsic capability of an effective “app” is critical and must satisfy strict criteria. The application must be:

1. Network-able

Networking and administration of the solution must be an easy task. It is a prerequisite that database solutions are natural tools for working within groups. Efficiency should be multiplied by the number of collaborators in a group. Everyone shares their work and benefits from coworkers. Furthermore, each person in the practice, from administrators to nurses and doctors each enter their appropriate information and are not required to enter the information from another profession.

2. Multitasking

Allowing people to access information from different sites, as others in the same time are in the editing process or yet others are completing an analyzing task. The network concept may be enlarged to embrace the concept of task sharing and task distribution. Grouping datamed through different layouts according to specific workers and to specific tasks is part of the real skill of developers and again, developers issuing from the field are obviously more efficient (Figure 5 & 6). Whenever as possible, the most appropriate person and only one edits the “datamed”.

Figure 5&6 2 ‘capture’ screens for 2 different tasks : the artery puncture itself (Figure 5) and catheters manipulations (Figure 6).

3. OPEN- DATA compliant

This property is essential but very rarely do medical solutions have this characteristic. In particular, software sold with medical devices (like Echo, electrocardiogram (ECG), and X-Ray equipment) is often proprietary. The “open” nature of the app is nevertheless essential. An open architecture is the way to protect entirely and indefinitely all work (and all previously-entered data). At any time, one can change the application and move all data/datamed to the new app. One is no longer “hostage” to a particular software company. The open architecture allows datamed to be shared with other databases even if they are not managed by the same application (and vice-versa). Protocols for exchanging data between different applications exist and it is better to check if an app is compliant with existing protocols. A major goal of Informatics Service (IS) in institutions should be to bridge the different apps using such protocols. We also state that the confidential nature of medical information should not serve as a pretext for resisting open app architectures because there are other ways to assure confidentiality.

4. Provides a powerfuland user-friendly “Finder”

In the “find/retrieve” mode, the app must provide access at anytime to any datamed, allowing data sorting by any single criterion or multiple criteria, including by grouping records/patients in the same search. Limiting the search function to the level of searching only one patient/one record at a time (which could be called a “point to point” search/access) is truly basic. It is the minimum required for clinical tasks and particularly in academic institutions, does not meet true professional expectations.

The true power of working with a database application relies on the search/find function of the app. The benefits of digitization should not be limited by poor, difficult to use, and limited search/find/sort functions. An easy and powerful “Find” command /function, combined with well designed editing tools for datamed keyboarding (efficient use of “one item check-boxes”) allows easy interpretable, up-to-date, and immediately available statistics (Figure 7a & 7b). These statistics allow quality control at the level of each caregiver, facilitate research, and lead ultimately to better care.

Figure 7a On demand Statistics: for the 1288 cath procedures, direct calculations for all fields designed as ‘one click check-box’, f ex, radial success, M or F, R or L both access… Calculation of mean, as, f ex, age of the population.

Figure 7b Same for the 368 cath procedures, sorting Female patients.

5. Provides user-friendly development tools without the requirement for specialized people

The final user does not need access to the proprietary database code but a good app should allow creation of rich, colorful graphical interfaces. Editing or retrieving datamed must be a functional and pleasant experience. A well-designed database presents datamed efficiently, using different screens/layouts for the different users/tasks, and allows a quick and easy navigation throughout the database. Good databases push users to require inclusion of more medical tasks in their actual computerized solution.

Again let us point out what an enjoyable and satisfying job it should be for IS to help structuring database solutions in collaboration with the caregivers, whatever the app is. Furthermore, the database solution must allow addition of new datamed and must be able to grow and evolve with medicine and informatics.

6. The app is relational

This characteristic is important when considering the need for a global computerized information system (CIS) and complements the concept of network and open architecture. This function allows different databases to be linked and to share datamed within the same institution or outside it. Again the entire group is more efficient, with each sub-group benefiting from others. Dividing the solution into smaller but linked parts has some advantages. There is less chance to halt all work if a crash occurs, more control on smaller databases for research purpose, but also for database development and updates (Figure 8). Relational databases facilitate more complex data sharing between different “worlds” like for example, critical care unit (CCU) Nursing, Cath-lab Nursing or hospital Pharmacy.

Figure 8 Ex of assigning different tasks/screens/databases for a Cardiac Cath Lab Solutions.

The relational function of the app has to be easy to implement and not all apps are developed equally from this point of view. Let us say that it could be a quite complex job as illustrated in Figure 9. In summary, a good database solution includes all the essential datamed for good clinical decision-making processes and strong statistics, with a fast, user-friendly, reliable editing/keyboarding process, and easy-to-retrieve information. The solution will merge datamed issued and edited online and at the point of care by all the people involved in the patient’s care: administrators, technologists, nurses, doctors, pharmacists, etc. Datamed are easy to retrieve at any point of service and the “find” function is not limited to “patient by patient”. The database solution’s architecture should be open and may be linked to existing or to future databases. Evolution is easy: minor developments like adding emerging new datamed is not too complex and most of the time does not require very specialized people. Utility is clear and the general workload of the solution remains in the usual standard (principle of equivalence) (Table 1).

Figure 9 Illustration of the complexity of relations between the different databases required for computerization of a cardiology practice.

3. Institutional Informatics/Information Services (IS) & the EMR

From the aforementioned elements described, it’s easy to understand that the institutional EMR will easily be build thanks to the databases developed in each of the departments: important datamed for the general management of the patient’s health will be shared on line and as soon as they are generated in each medical field. Information only useful for a specific medical department (let’s say for example the datamed pointing to the size or to the special catheter curve used for performing an angiography) will not be visible within the hospital EMR (no utility) but will be retrieved in the department where the datamed belongs to (cath-lab database, procedure technical report and counting report of the used material).

The best way to describe the ideal Institutional Informatics/Information Service is a comparison with the Ministry of Transportation: the role is identical, building and managing a reliable network and defining norms users have to comply with. The Ministry does not impose a specific brand of car, nor where or with whom one drives. In the same way, the ideal Institutional Informatics/Information Service should not hold the responsibility of the decision which data processing solution is good or the best for an specific medical business. IS has to verify that the solution physicians are using is compliant with the institutional standards, whether the solution is open, and whether it can be linked to the other apps. IS has to develop the skills to help physicians tailor the chosen solution and to build the required bridges with the other “compliant” databases used in the institution (or outside it). These tasks are numerous, varied, satisfying and require the collaboration at individual and group levels. They should not anger or frustrate IS peoples. IS, like the app, must stay open. In no way does IS have to be a monopolistic business, ignoring the true alpha and omega of medicine’s computerization: the patient and the doctor.

My gratitude to my daughter Carole Dangoisse, MD, for her advice and support.

Author declares there are no conflicts of interest.

None.

1.  Steven EN, Abdulla MA, Bijoy KK, et al. Working Group 6: The Role of Technology to Enhance Clinical and Educational Efficiency. Journal of the American College of Cardiology. 2004;44(2):256‒260.
2. Martha JR, Paul AH, Steven RB, et al. ACC/AHA 2007 Methodology for the Development of Clinical Data Standards: A Report of the American College of Cardiology/American Heart Association Task Force on Clinical Data Standards. J Am Coll Cardiol. 2007;49(7):830‒837.
3. Taylor GS, Muhlestein JB, Wagner GS, et al. Implementation of a computerized cardiovascular information system in a private hospital setting. Am Heart J . 1998;136(5):792‒803.
4. MUHC, McGill University Health Center, Cardiology Division, Genest J, Beaudry JP, (cath lab Director) and R Haichin, (CCU Director): personal communications.