A History of Computers in Health Records
Erasmus : This page is about the interface for health information. This page does not address the structure of the data in the electronic health record, but does address how we get that information into the electronic health record. It is about how information is entered into medical systems and processed by computer systems using human input.
The GUI one of the current mechanisms of inputting data into health programs.
Kinkajou : A GUI interface for health is not a new concept. There are thousands of programs existing in the world today that use a graphical user interface (GUI) to accept, process and display data. I have certainly seen programs that boast they use a GUI framework, to graphically display data, with clinical functions visually and operationally integrated in a way that is accessible and intuitive to use for users who are comfortable with Windows programs.
Dr Xxxxx : (Wow! If only the reality matched the hype).
Kinkajou : These programs even have elements of customisation built into them. Different facilities using these programs can change the tabs and component arrangements to optimise information presentation depending on the workflow needs of the users.
Erasmus :Aaaaah!
To understand my expletive comment, let’s look at where the electronic health record started.
Computer power has increased exponentially over the last three decades. This has enabled a range of new functions, improved memory capacity and allowed more complex medical record data to be input into a program. This information can then undergo greater tertiary processing and then the information further processed before being displayed.
Type Interface for Desktop Commnand Line
Approximately three decades ago, most computers worked on a simple command line interface. This is a flashing cursor on essentially a largely blank screen. Data would be typed in and recorded in a small text file. This could then be displayed across an entire computer screen when called for. The data was largely unstructured . Processing of the data in terms of database searches or looking for specific information or extracting specific “views” of extracts of the data was essentially impracticable due to memory and processing power limitations of the computers of that generation.
Essentially, the data could be recorded as one big text file and then could be displayed as one big text file.
Erasmus : Look at where we are now. Now the average electronic health record program is capable of accepting input from a keyboard (same as before) and a mouse . The majority of data is still typed in, but may be held in a “structured” format.
This means that data with a common theme (e.g. BP recorded over a period of time), is recorded in a single data box (data base file). So in the average program there would be a file which records the BP of every person who has visited that clinic at any time. This file can be searched to look at group trends in BP.
An individual patient’s data can be extracted from this file to look at trends in individual persons BP.
What is tragic is that other input methods exist and are just not even thought about. eg. Voice recognition works quite well today. Drawing and symbols can be input via tablets without requiring the use of a mouse. Non-standard characters can be input, and typing can be bypassed.
KeyBoard Data Entry Interface
However, text input of unstructured data is still very common. Much information is simply typed into some little box on a computer screen because it is too difficult to code and enter as structured data. So in the above example, data is stored in a text box field for a particular patient on different dates.
The other change that has developed is that we have moved away from having a single command line data entry point. By using the GUI interface, we now have lots of boxes on a screen, each one of which essentially has its “own command line” where data can be typed in.
Erasmus : So, summarise that.
We can look at the progress of medical record computing in the last 30 years is moving from one data entry point to multiple data entry points on a screen. Also we have moved from fully unstructured data to partially structured data. We also now use a mouse for data input.
This does not seem like a huge achievement for the millions of people who have worked to create these programs. However there are many technical issues which we will discuss in this webpage regarding the electronic health record.
Much of the data in clinical packages is tied to a single language, (English for us on this page). However, with data held in structured database files it is possible to translate the recorded data as it generally represents simple data elements: such as for example pulse rate, blood pressure, presence of a cough, presence of a sore throat, presence of yellow green phlegm, presence of a temperature, and/or the presence of a runny nose.
And here is where the problem comes with translation. Much of the data has labels which are external to the boxes where the information is recorded. This means that to translate the data, you must reconfigure a new base webpage with new language labels. So to translate the data into another language, a new display interface must be crafted in that language.
Saving and Translating Data
Learn how Personality is genetically determined and can determine the fate of nations. www.enkcharm.com "Enneagram"
Learn how disease and illness even more so define human behaviour. WWW.ENKpaill.COM "Paill".
Computer Characteristics: InHuman
If you wish to input data into a structured database file, you need to find that database file. This usually means you need to search the screen for the appropriate label, click the label, then search the newly displayed page, then click the input box and perhaps even click sub choices within the input box to enter data. This is a typical cascading menu system of Windows.
Kinkajou : The cascading menu system is a modern invention. What’s got your goat?
Erasmus : It is worthwhile making observation that computers work very well with hierarchical cascading menus. A computer absolutely thrives on navigating to a data entry point/link/button that is for example: 4 lines down the first menu, then the third choice in the second menu, then the second choice in the third menu and finally perhaps the third choice on the fourth menu.
(Summarised as 1.4—2.3—3.2—4.3)
Human minds do not work like this. A human mind can envision what is required and progress straight to that point. A Human mind could look across piles on the desktop, find the pile with the information needed and then rapidly flick through the file to locate the specific item.
A computer program could get you fairly easily to the first pile, but then proceeds to lose you with cascading submenus, whereby you rapidly lose your orientation in the data stack. This makes it very hard to find your way back to your specific item or related items which you may have noticed in your travels.
A numerical way of representing this issue referencing the human mind is that” humans can search easily for information at 1.21” (1.twenty-one).
A numerical way representing how a computer works is to represent this data (above example) is 1.4—2.3—3.2—4.3 or something similar.
If you are searching through this cascading menu stack it becomes very easy to have difficulty finding your way back to an item that you have seen, especially if the navigation path is not intuitive.
An excellent example of this is the Windows 8 program hiding the on/ off button off the front page in a submenu off a side menu. Since there are many branching trees to search, it becomes difficult to find your way to the leaf on the branched tree (i.e. the power button) that you want. You cannot even shut the program down, because you cannot find the shutdown button hidden in the hierarchical menu system.
Cascading Hierarchical Menu Systems
Kinkajou : Okay. But don’t you think modern data entry system using computer keyboard and especially the mouse are a step up from old systems.
Erasmus : Well! The keyboard mouse combo has some advantages (screen wide navigation and menu selection without using pre-programmed keyboard shortcuts like the tabs key), but it also has some disadvantages (requiring removing fingers from the keyboard, requiring concentration to precisely select items from a menu) as well. Tab keys allow you to work in a prescribed order across a selection menu and then to make a selection prior to perhaps repeating the entire process again. Using a mouse allows you to shortcut this process and to go directly to your choice.
The next problem lies in that if you’re using a keyboard, taking your hands off the keyboard to work the mouse is a real time waster. Also mice need to be navigated with precision requiring quite a bit of concentration to activate the correct button, and not to miss or activate a wrong button or choice.
This has the consequence of slowing down workflow and redirecting the doctor’s attention away from the patient and towards the computer (data entry task). Every time you finish using the mouse, you need to reset your hands back to the typing positions on the keyboard. The multiplicity of interactions in a clinical environment means resetting your hands to the typing position can be a problem.
Kinkajou : Do you have any other complaints about keyboards?
Erasmus : Keyboards are noisy. Keyboards give a limited range of options were choices to the user. For example to navigate down the page you must press the down button repeatedly. If you press the page down button you have probably gone too far. This means that navigation is a matter of tapping keys quickly and repetitively to get to where you want to be.
There are a number of shortcuts built into the systems which as often as not means you select the wrong item and need to spend time UN -selecting what the automatic system has selected for you.
Entering data through keyboard demands that you pay attention to spelling out your words, letter by letter. Keyboards have a limited range of data entry symbols. Keyboards have a limited range of shortcuts (i.e. macros).
Keyboards have a very limited range of logic symbols (e.g. arrows), and these can often only be implemented in very text structured ways, (i.e. working across the layout of the page, and not skipping across text to link concepts separated by text).
Mouse Data Entry Interface
Kinkajou : Generally interfaces for clinical programs do exactly what you tell them though. Surely that’s an asset.
Erasmus : Most clinical systems do not have predictive heuristic programming. This means that when you press a button the computer automatically begins to load programming and information relevant to that choice. Although computers are very fast, strangely enough people are faster.
People need to wait for the computer to process its’ information. It would be far better if the computer while resting and perhaps based on information gathered on previous choices, loads data on likely or probable choices that the user will make. Therefore when the choice is made, it can be displayed essentially instantaneously, not making the user wait.
Kinkajou : Yes. But that’s just a computing issue. I think modern computers are more than capable of performing this task.
Erasmus : Perhaps. But modern programmers are still stuck on one task at a time, to be done as each task is ordered to be done. Pre-branch prediction is a computing process that is largely only used in prefetch buffers for the CPU memory.
Kinkajou : But aren’t computer systems a real step forward in comparison to what doctors used to record on paper.
Erasmus : I think many doctors would perhaps disagree with that comment. While the data is entered in a format which is typed and very legible, difficulties in inputting data into a program box means that users take severe shortcuts in choosing what to enter.
The medical industry is generally best seen as a low margin high-volume business. This means that users are not able to spend a lot of time entering data into the system. They need to spend as much time as possible servicing their clients or patients. The less time spent on data recording, the more money is earned.
Paper based records also work differently and can use a range of symbols (abbreviations) and including logic element symbols such as arrows quickly.
Computerised systems have limited capacity to deal with recording symbols representing logic with any rapidity (logic arrows representing thought direction, underlined or highlighted words, thought linking arrows and thought process directing arrows, structuring boxes for input data, and data block identifiers).
Old Medical Records
Erasmus : On computerised records however, much data such as reasoning arrows to direct the reader’s attention, possible diagnoses, and management protocols all tend to be recorded in a very minimalist fashion.
Computer systems also have limited capacity to deal with abbreviations that are not easily represented by text symbols. In human writing, the possible list of abbreviations is only limited by one’s imagination, whereas in a computerised system, keyboard symbols must always be used.
This makes the situation akin to using a simple US layout keyboard to enter Chinese letter symbols on a page. This is not a process that goes well.
What does appear very easily on paper is verbiage. Computer systems are excellent generating verbiage. However it is very easy to bury real information in a cascade of words. In the following example I challenge you to try to get a clear picture of what is happening in less than several minutes.
The Sample Computerised Medical Record vs PICTs
Dr Xxxxx : In our example, a computer system may record clinical observations or medicines prescribed as follows:
History:
CVS: No chest pain. No paroxysmal nocturnal dyspnoea. No palpitations.
Respiratory: No dyspnoea. Cough. Sputum. No haemoptysis. Wheeze. No pleuritic pain. No childhood asthma.
GIT: Nausea. No Vomiting. No diarrhoea. Anorexia. Weight loss. No Heartburn. No Reflux. No haematemesis. No PR bleeding. No constipation. No Abdominal pain.
Examination:
General:
Temp: 37.6
BP (Sitting): 120/80
Pulse (Sitting): 84 Regular
Height: 176cm
Weight: 85kg
BMI: 27.44
Respiratory: No respiratory distress. No recession. Not using accessory muscles. Wheeze. Not peripherally cyanosed. Not centrally cyanosed. No finger clubbing. Nicotine stains. Normal percussion on Right. Abnormal air entry on Right. Normal vocal resonance on Right. Abnormal air entry on Left. Normal percussion on Left. Abnormal vocal fremitus on Left. Abnormal vocal resonance on Left. Creps present. Rhonchi present. No pleural rub.
Right eardrum red. Right ear canal not inflamed. No Right ear discharge. No perforation Right ear. No Foreign body in Right ear. No glue ear on Right. Left eardrum not red. Left ear canal inflamed. No Left ear discharge. No perforation Left ear. No foreign body in Left ear. No glue ear on Left. Inflamed mucosa Right nostril. Inflamed mucosa Left nostril. Discharge from Right nostril. Discharge from Left nostril. No obstruction Right nostril. No obstruction Left nostril. No foreign body Right nostril. No foreign body Left nostril.
Actions:
Prescription added: PARACETAMOL CAPLET 500mg 2 t.i.d. p.r.n.
Prescription added: MAXOLON TABLET 10mg 1 t.i.d. p.r.n.
Prescription added: COVERSYL TABLET 2.5mg 1 daily p.r.n.
MAXOLON TABLET 10mg changed to METOCLOPRAMIDE HYDROCHLORIDE TABLET 10mg
COVERSYL TABLET 2.5mg changed to PERINDOPRIL ARGININE TABLET 2.5mg
Now let’s look at some examples of problems arising from using computerised verbiage.
In the above data list there are some data elements missing in this typical assessment of respiratory tract infection. i.e. Have you realised that no one has asked about a sore throat or looked at throat redness or tonsils.To look at the computerised verbiage, it takes a lot of time to work out what is missing and a long time to put together what is present.
The computerised verbiage also hides what the actual findings were on history or examination of the patient. It is very difficult looking into the above recorded data to work out what is actually going on.
Dr Xxxxx : Let’s PICT code the following data example:
Examination:
Respiratory: No respiratory distress. No recession. Not using accessory muscles. Wheeze. Not peripherally cyanosed. Not centrally cyanosed. No finger clubbing. Normal percussion on Right. Normal air entry on Right. Normal air entry on Left. Normal percussion on Left. Creps present. Rhonchi present. No pleural rub.
=======>>>>>>>
Coding: perhaps:
Erasmus: As you can see this makes a big difference to the usability of the data. Which do you think is a better source from which to to get an impression of what is going on?
Kinkajou : The use of yes / no data entry is also an obvious problem. Computer systems like to think in terms of yes or no.
Erasmus : However real people do not. If you ask someone if they have a cough they may say yes. However if you take into consideration the circumstances of the patient, you may realise that they always have a cough. They smoke and they are sick, they have chronic bronchitis and cough frequently and often and long term. So when they have answered yes to your question, this means that although they do have a cough, it also needs to mean that they do not have any extra cough than they would usually have.
Dr Xxxxx : So a yes/no answer to the question of “do you have a cough?” is an inappropriate representation of the data that needs to be recorded. A proper recording data, it may well be something like “ISQ”.
Data also obviously needs to have volume modifiers, time modifiers, deterioration or improvement descriptors and other descriptors such as witness/dryness/Purulent nature of phlegm/clear nature of phlegm.
You begin to see how quickly a PICT based system moves ahead of standard computer data entry.
Dr Xxxxx : Data can in standard computer systems can only be entered as language text. While drawings can be used and added to language text, computer systems will only accept all descriptors and modifiers to exist in the record only exactly as their input text.
Kinkajou : Why is this problem?
Erasmus : Well if you draw a lump on a screen and put an up going or down going arrow on it, most doctors would recognise this means that the lump is increasing or decreasing respectively.
A simple arrow takes a lot less time to input than does the description that the lesion is increasing or decreasing in size. Entering data direct from the human hand gives much more versatility to type and nature of the data that can be input than simple text entry into a text box on a screen.
Kinkajou : So you believe a picture based data entry and recording system, sort of like Chinese characters is a better way to go to record medical data.
Erasmus : Yes. A PICT recording or data display system can reduce the human search time and human processing time to 10% of what it would otherwise take on a typical computerised electronic health record system.
Kinkajou : Surely computer systems code diagnoses better than individuals?
Erasmus : Data diagnosis coding in computerised medical software package is also unusual. I have seen diagnoses ended as “hand injury, non-fracture, non-toxic envenomation, not spider bite, not snake bite to left hand” to record a Midge bite on the Left hand.
This means it takes a lot of time to enter structured data diagnoses. The humans seem to have a better time of it. Many of the diagnostic coding packages attempt to bypass cascading menu selections by incorporating all the options on a single line. This unfortunately means that some of the menu selections are very complex and non-intuitive.
Humans make a better go of it by allowing multiple conjoining to descriptors to exist as a diagnosis.
PBS Script Australia