Kinkajou : A health record doesn’t sound like a very important piece of tech. After all we do have lots of them on lots of different forms, including computerised ones already, today.
Erasmus : Having an electronic health record is almost a holy grail of medical science. It’s akin to people taking the first step to writing things down: working out a language to all talk together. But it’s not just about recording pre-existing information. It’s about recording WITH structure, adding intelligence and using structured data to solve real world problems for the group. Accumulating information across providers is also critical, reducing data loss / data partitioning.
Kinkajou : Dr Xxxxx has a different holy grail. His belief is Paill.
Erasmus : Not our topic today.
Dr Xxxxx :In our mobile modern world, people do not stay within a single geographical area for any significant portion of their lives. So when they move from one area to another, the records of their life need to move with them. One significant facet of this, is the movement of the medical information to the new abode to allow the new health providers to care for them.
By utilising pre-existing information, the health system avoids replicating or regenerating information and allows the new medical carers to take advantage of the information that has been painstakingly assembled by teams of health professionals who came before them.
Kinkajou : I’ve heard doctors may refuse to share health records. They are regarded as too valuable to the medical practice.
Dr Xxxxx : The availability of much health information is perhaps overrated. No one probably cares if you have caught an unknown unidentified respiratory virus once a year for the last twenty years. A painstakingly assembled health record which shows that you have had flu vaccines regularly for the last 30 years is useful, but not critically useful information.
Many people really do not have much medical information that is worthwhile recording until such time as they become older or sicker or catch something interesting. It is when complex medical conditions arise, requiring complex care and coordination of care, that the true value of the medical record starts to become obvious.
If conditions have been diagnosed, they will often not need to be retested for and re- diagnosed. The Information exists and is unlikely to have changed. Replication of pathology and imaging testing saves time effort and money for the patient, their carers and the medical system funders.
Kinkajou : The data collected about an individual can be massive.
Stethoscope Medical Data
Dr Xxxxx : Yet most of the medical information even in “computerised” records, is essentially unstructured. Diagnoses are usually recorded in structured format. But if you’ve ever seen a diagnosis like: “Non venomous bite/non poisoning/non burn”, which comes from a recognised diagnosis recording system, you can still end up wondering what on earth in wrong with the person. Also information recorded in a text field can well be lost in terms of structured data/ diagnosis as far as the program is concerned.
As the information recorded becomes more comprehensive, methods of data extraction become important. Data needs to be recorded in a structured format to reduce data volume and enhance data searchability. A single patient is capable of having a file of data approaching the gigabit range if the data is held in an image format.
As databases of health information grow, they easily outstrip the capacity of the “group”-based system to manage. It may work for several medical providers working in a group practice to enter data for individual patients with whom they are dealing. But even at these small practice sizes, if too many doctors / staff enter data on a patient at the same time, (too many being more than one), a bottleneck for data entry can develop, as each patient’s data is entered into system-wide databases.
Every time a single patient file is accessed, up to several hundred databases may need to be updated with newly entered data. (This is because most medical data recording programs put an individual’s data into a cluster of data bases, each database holding a strand of data about a group of people. (Typical data in a single database file could be name, address, sex, phone numbers and DOB.
Another database could record allergies. Another data base holds appointments and another billing data. Another database records smoking status. Another database records past medical history. Another database holds past medical history text. And so it goes).
Kinkajou : So how did we get to where we are today?
Dr Xxxxx : The reason for the pre-eminence of the database structure lies in history. The development of the computer database file structure allowed for a number of technical issues to be solved.
Data corruption could be assessed and repaired.
Commit protocols could ensure that no two people could access the same database at the same time. At any one time only one medical provider would be allowed to update information on one person across all the linked databases relating to that person. This is important because if two people enter data into a data table, any changes in the record line number for an individual are unable to conflict with other entries into other databases.
Problems can arise at two levels. Multiple data entry updates can cause conflicts in different records if they cross-reference incorrect elements in other database files. Deletions in files and additions and files can cause gaps to appear in the database file structure. These need to be sorted out at intervals to maximise the speed of database searches, and to prevent improper cross-references to develop.
Front-end applications often demand specific clusters of data. For example, a medical bookings package requires that all the demographic information of a patient be readily accessed in a single seamless display.
The best way to achieve this is to have a single database file or perhaps a few database files feeding information to the application that produces the display data. Unfortunately this comes at the expense of the individual patient file. Many medical applications are more about front end applications than about the individual’s information.
Kinkajou : So what bits are there in a typical medical record program / file?
Web Medical Software Applications
Dr Xxxxx : Typical medical applications include:
- Recording patient demographic and financial information.
- Patient bookings: appointments with doctors, appointments for group care e.g. day theatre plus surgeon plus anaesthetist plus nurse booking.
- Medical records including history, examination, diagnoses. (Recording the medical consultation).
- Medical problem lists, complex care and management and coordination.
- Recording of various types of medical information including pathology information, imaging or radiology information, medication information, medical letters (outgoing or ingoing).
- Notifications and recalls systems.
- Patient billing information.
- Database queries for purposes such as: recalling patients with particular illnesses to particular clinics; finding patients using particular medications; finding patients with particular complications of care; finding patients with particular pathology results; finding patients lost to care; finding patients requiring chronic disease management.
- Clinical decision support.
- Documentation of immunisations, patient education, general history, diagnoses.
- Coding of medical diagnoses.
- Undertaking referrals, perhaps tracking referrals.
- Processing data from scan inputs or voice inputs.
- Structuring clinical information such as for mental health, pregnancy, complex conditions.
- Communications including data in and data out, mobile data access to tablets or phones,
Control of database corruptibility and ensuring database authenticity (preventing unauthorised updates).
Regional Health Records
Kinkajou : Wow! That’s a lot.
Erasmus : But still one very important principle overrides it all. GIGO. Garbage in, garbage out. It takes time to preen a record. It takes time to keep it tidy- depending on how your program structures stuff.
Recording diagnoses takes time. Accessing stuff can be so difficult and time consuming that it is easier to not bother. I imaging most solicitors would take half an hour to peruse a medical file over say 10 cm thick. Doctors in Australia do not have the time in their consultations to even spend one minute out of a consultation doing this type of familiarisation.
Dr Xxxxx :It is easier and faster to flick through a paper record than to find, isolate, select and wait for record display of an item of correspondence in a record. A “paper record user” can probably achieve a data access of up to five times faster than someone working on an electronic record.
Dr Xxxxx : It’s about who pays. Patients don’t want to pay for time and neither does the government or their insurers. So, in short it is cheapest not to do it at all.
Erasmus : It becomes obvious that the purpose for which the medical application package is designed drives the design of its input data screens/ database.
This unfortunately ensures that medical information cannot be accessed by any other than Proprietal software (i.e. software packages belonging to the same owner that designed the original software package). This then unfortunately ensures that medical information cannot be shared across the system.
What Drives Computerising Medical Records?
Dr Xxxxx : Most medical data record systems do succeed in one area. This single success has essentially destroyed the use of paper records. And it is all about cost. By having an electronic record system, the records are instantaneously filed. This means that you no longer need 1-2 staff per surgery / clinic -- to file and unfile records. Records are lost a lot less often, (by receptionists with dyslexia especially).
Doctors retrieve their own records in less time than it would take them to tell someone to retrieve them for them. Data scanning of letters, documents and correspondence means that information is always kept in order, and is instantly available once “filed” into the system. And modern scanners are fast and capable of OCR processing information quickly, accurately and automatically.
Erasmus : So by reducing filing staff, a clinic could easily save say one hundred thousand dollars annually. They can lose staff, saving money. They almost don’t need whole rooms once devoted to filing, reducing valuable space and rental costs etc. And data /record availability increases.
Dr Xxxxx : Yes. Medical record systems / programs do this well. But it’s probably the only thing they do well. The quality of data and diagnoses going into the systems has decreased. Computerised record systems just don’t let people work in a way that “humans” prefer to work.
Kinkajou : However, I’ve talked to you before about the solutions. We are capable technologically of doing so much better.
Easy Tech Today
Goo : As usual, it’s the social aspects / money aspects that limit development, not the technology.
Kinkajou : We could easily do all the things Dr Xxxxx has suggested. But we need to decide how to do it, what to achieve, what structures are necessary to hold the data, how the data is shared or communicated (between doctors, patients, allied heath carers and competing medical providers}, and how different software program providers can interface with the base system. All people issues and system issues, not technology.
Databases in Computerised Medical Records
Erasmus : I understand that health records can be huge.
Dr Xxxxx : In considering the electronic medical health record, it becomes obvious that for size constraints and access constraints, the electronic medical health record needs to only cover a single patient.
However there are areas within the medical industry where a range of specific information needs to be extracted from the individual patient file and saved as a cluster of related databases. For example the medical bookings package requires specific range of information which must be available at high speed and capable of being updated rapidly.
This means that contradictory constraints exist within medical electronic health records.
Single databases covering a specific range of information covering many patients within the system for a single application such as a medical booking package in one design, work best for these applications.
A single data file covering a single patient is a second design, works best in individual care.
Data File System
Dr Xxxxx : There is no common ground between these two directions. However there are common underlying needs for both groups.
Corruption of databases is a serious problem. If even a bit of data corrupts, it becomes impossible to trust, any of the file. If one bit goes bad, is it a bit you are relying on. Is it an important bit. If your answer is "don’t worry about it", I’d suggest go try it with your financial records. Hopefully, they won’t lose too many decimal points in your loan or credit card statement.
So then the issue may well become to use each database structure as an insurance against the corruptibility of alternate structures.
A billings database line, containing all of a patient’s information, could incorporate a crc corruption check that compares against a single line of data held in an individual patient file database. If this consideration is used it becomes obvious that the contradictory database structure requirements actually generate complimentary functionality against corruption and database damage.
Erasmus : In short, several database structures may well be advantageous. These need to have a common structure to allow portability across different applications and different application providers. Each data system serves as a corruption check for the other system.
Goo : Wonderful. But who untangles the mess when things go wrong? And How? And the data may corrupt itself. For example, people update their addresses. How do you work out which address is the right one when data corrupts? What happens when people tell you the wrong answer to their name or address? If there are a lot of errors, how do you automatically fix things up and to what extent can you use older archived backup stuff to untangle the data snarl?
Erasmus : Yes the idea of cross checks is critical. But when things go wrong, it’s not really good enough just to ditch that data element. Probably what worries me most is when the program has a system issue. There are many instances when data must update. Because typically these instances generate a database element update through an overwrite, the potential for data damage is always lurking within a recording system.
Kinkajou : Yes. I can see almost as a system issue that data should never be overwritten, but only over-layered. If it is recorded, it is recorded. Even on a paper record, you really only add data, not delete it in general. Allow records to be altered opens the system up to a large range of clever abuses and misuses.
Kinkajou : So tell us about how you keep records safe.
Dr Xxxxx : Second issue arises if encryption is introduced into a system. Encryption is a method of security.
Erasmus : If the contents of data file are standardised and educated guesses can be made as to the content of the data encapsulated, it is likely that data encryption can be broken. Data encryption raises a number of difficult issues.
A single encryption structure is likely to allow the entire data file structure or database to become compromised. However, mistakes do occur with encryption. I remember my experiences with computing decades ago. When decrypting an encrypted hard drive, almost invariably one single bit of data somewhere was not able to be decrypted. Perhaps the corruption occurred with the data file, perhaps within the computer processes involved in decryption, or perhaps as a result of data corruption on the actual hard drive itself.
The invariable result is inability to ever again decipher or decrypt that particular bit of data. Also as data is protected, it invariably becomes really hard to get rid of the corrupt bits, as the system insists upon protecting the bad bits just as much as the good bits.
Dr Xxxxx : Data that travels across boundaries needs to be kept secure. And the security is compromised by the nature of the data. Often what is in the data file may be known to some extent. Perhaps a guess can be made as to the bits of data file.
The physical security of the data file cannot be promised in a world without boundaries. Also the patient gives permission for their data to be accessed and perhaps gives a key for this access. Such keys can be used by persons other than those to whom permission for the use was initially intended.
Goo : And as a lowly mammal, I understand how bad it is to lose your keys.
Dr Xxxxx :True. You should never have security so tight that you can never recover your data if something goes wrong.
Data security and data transmissibility across boundaries becomes a substantial design issue. How do you allow access to people who need the data and stop people accessing data who wish to utilise it for their own purposes, and not for the benefit of the individual patient?
Erasmus : The "M and M" model of security beckons.
Dr Xxxxx : What’s that?
Erasmus :Well, the data system has a hard shell to keep the unwanted on the outside. But inside because we’re all one big happy family. All the medical providers being good guys with every thought for the exclusive benefit of the individual. We have a different data protection set up inside. Inside the shell, the protections are much sparser. So the data inside is easy to get or use. The data inside is all soft and chewy, just like the inside of an "M and M".
Dr Xxxxx: An appropriate though rather disturbing picture.
Erasmus :Yes. I once knew a real bad medical egg. I can tell you now; all the bad guys aren’t all on the outside. You need to have protections built on the inside as well.
Kinkajou : Any other data security issues?
Dr Xxxxx : Other issues in security relate to ownership and access.
- Generally as medical professionals generate the medical file, they believe they have ownership of it.
- However, medical professionals work for organisations or companies who by default own the records produced by the professionals who work for them.
- Patients believe they should own the record because it is about them.
- The legal system and insurance companies believe they have a right of access to all records.
- Doctors as ex-employees may require a right of access to the record for purposes of legal defence or medical defence.
(These processes may be invisible to the patient). By default, so many people seek rights of access and ownership to the patient’s medical record, that the patient may be forgotten, as being the focal point of the records in existence.
Many issues arise which have no solution.
Owning Data Diagram
Patients believe that their record may need to be kept confidential even from the health providers.
Health providers believe they have a right to have access to all information available about the patient. Lack of information, after all, can lead to mistakes. Patients generally do not have adequate knowledge to understand the consequences of their denial of information. Alternatively, they may deliberately choose not to pass on their information. For example, a patient may not want their health provided to realise that they carry the HIV virus.
If the data is restricted, there can be severe consequences if decisions are made. Patients are not in a knowledgeable position to understand the consequences of their actions.
However, many decisions about medication scripts may demand that adjustments be made of the medication doses prescribed due to the effects of for example the HIV medications prescribed. The progress of an illness may seem to be atypical. Of course if patient HIV status is known, the unusual progress of an illness may be appreciated as being normal “under the circumstances”.
Health insurers, legal practitioners and the government can all demand access to records, irrespective to any privacy concerns.
Erasmus : The Question of who has what right, for how long, and to what extent needs to be answered. There is probably no right or wrong answer. Most answers to these questions would develop in relation to the history of files growth and development. Who did what, and when, for whom, for how much money, and for how long, will likely be the main factors dictate who owns what right of access, for how long, and to what extent.
Deciding Who Owns Data
Perhaps the patient should have an implanted chip carrying encryption keys enabling data access only to the authorised few. But then the doctor may need a chip, the company they work for may need a chip, and many other people who have a role in the care of the patient may need a chip to give them access to the patient’s medical electronic health record.
Moving Medical Data: The Issues
Kinkajou : The new world demands some degree of information sharing. Any other constraints on moving data apart from security?
Dr Xxxxx : Transporting information also places constraints on the design of databases. Even on gigabit networks, big data files need a finite time to be transmitted. While they are being transmitted operations and access points generally stop.
Data cannot be accessed as it is not theirs to access, (others have right of request priority: like standing in a queue waiting to be served). Data access needs to be fast. If a doctor needs to wait say 20 seconds for a file to appear on his desktop, this is already destroying a substantial proportion of the available consultation time.
System constraints are stopping the doctor from doing his job and stop the patient from receiving the service for which he is paying. So databases need to be capable of being small enough to be moved quickly.
If the likely projected need for database usage requires the use of large databases, it may be a requirement that databases be capable of segmentation to allow operations to continue on partially accessed files. Alternatively the server may need to select and transmit only portions of the database. In short, what you need to move and how much data there is to move are critical constraints on the size and structure of databases / medical networks.
The ability to make the files portable, able to be stored in e- clouds, able to be accessed on tablets or smart phones, versus their ability to be used and fully featured desktop systems or company wide systems impose substantial design constraints on the structure and size of medical health information systems, medical databases and medical database files.
Coding languages are a critical feature of many database structures. An easy example can be seen in pathology results. If two companies perform a full blood count or full blood examination, this data must be coded to the same descriptors to allow the data to be compared between providers. This means that time-based trends can be observed and extracted from available data. This means that searchers can access the same data elements, for example the haemoglobin values across a period of time for a patient with anaemia.
This type of pathology coding is difficult in a complex world because there are many different tests in the world, each can be done by many different methods or techniques, perhaps giving compatible but not identical results, with different reference ranges for populations in different geographical areas or different illness groups.
Different measurements may be generated by different test machines, but these may not be common to different machines essentially performing the same test. While many tests are automated, many tests are not. So many results may exist not in a structured data but simply as text based descriptions.
Kinkajou : So there are lots of issues in designing medical record systems. How do you solve them into one giant package that does it all?
Erasmus :You Don’t. Until we have a singularity that can redesign such a monster into one cohesive whole again and again as things change, without error, we need to look at a different approach. One health record project could well involve hundreds of man years of coding expertise. It becomes obvious that the job has to be broken up into bits that each programmer can do. A situation akin to the ant world, where each ant is responsible for their own role but the hive is responsible for the whole.
Dr Xxxxx : An excellent analogy. Modularity is a word which appears in many computerised medical platforms. It means that medical applications designed for specific purposes by different providers can access the same basic data structures.
It is an excellent concept because it implies that a large number of people can design applications to suit a large number of needs.
Generally, a single company may develop an application which is applicable to a specific market segment. For example, a company may develop a medical recording package useful to doctors. But how about physios, occupational therapists, speech therapists, pharmacists, optometrists, specialist surgeons, specialist physicians, and even nurses and pharmacists?
All these market segments require different structured data to be recorded. These needs are best provided by a number of different companies each programming applications to meet specific niche needs. However to achieve this, there must be common rules for interoperability, and access to common data structures which can be shared and are not proprietal in their organisation and construction.
Modularity is a concept which can only arise when the basic data elements are shared or are owned by someone who is prepared to share at a reasonable cost. This type of communal morality is something which has perhaps eluded many companies in the computer era. The history of the dominance of Microsoft certainly gives a few lessons.
Kinkajou : So all this once solved will get to the holy grail of the common medical record file?
Human Menu Systems and Human Based Data
Erasmus : As we’ve mentioned previously, flat menu structures are desirable by human beings. However computers work quite well with scale hierarchical menu systems. Similarly with database structures. This may mean that in a health record, there is difference between the structure into which a human records data and the receptacle into which a computer places the data to be stored.
I’ll restate what I’ve said before:
Many people think the cascading menu system is an excellent adjunct to computerisation. But, 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).
Dot Points in Data Structure
Goo : So systems for people need to be very different to systems for individuals?
Kinkajou : You’ve talked the issues of updating data records before. Could you elaborate?
Dr Xxxxx :Another issue which plagued many databases is the issue of “change”. For example, if a person changes their address, most computer systems simply update the record. However, it may be important at some stage to know what has previously been recorded. Patients updating their address and phone details often do so because they have moved.
However, their old address and phone details may still be relevant for contact. (At this old address could be relatives or people from previous relationships who may maintain a contact with the person). Also, if the update is incorrect, it may be important to return to old data values e.g. old addresses. For example, a staff member typing and address into the wrong patients file will need to be undone or repaired.
A clever system which updates the patients file and the files of all their family, may well have rendered the patient’s file inaccessible or have caused valuable data to be lost.
The address and phone details have been changed, it may even be impossible to fix them unless the patient arrives at the clinic, learns that the data changes have occurred and initiates a process to update and fix the data. Patients may also seek to falsify data, for example to prevent police and other people to find information about their whereabouts.
In short, data needs to be kept updated. But, sometimes all records need to be able to be accessed. This means databases cannot have a “single field” over-writable structure. (I.e. Every time we record a new entry, the old one is overwritten and effectively deleted or lost). Data elements may well need to be able to grow and branch much like corals on a reef.
Kinkajou : So how do you see the database design evolving, old dog?
Data Reef Structure
Erasmus : If a data structure grows much like a coral reef, it may be amenable to pattern recognition software for data extraction. In the case of an address update, system intelligence acting on a group database being updated by changes in the single person’s data base could alert that there is someone at that address in the known database.
Data records could also grow into a coral like structure as layers of entries are made. New data gives new shots of growth. Replacing old data just makes the data track wider.
PICTS as data input mechanisms demand an evolving regular database structure which would indeed look much like a coral organism as data accumulates. An interesting concept, but hard to know where it may lead. It may lead to some interesting coding developing.
Will such a data structure be amenable to translation across languages? Again the PICT concept of structured data entry suggests that the file could well be very easily translated into many languages, in fact been capable of being read internationally by many people using many different languages in many different places.
Under the GUI interface page, we have mentioned the need for heuristic predictive programming.
Medical applications need to be able to anticipate what the user requires. As records grow larger and contain more data, and networks require more data to be moved, as Encryption keys become ever more complex; the time requirements for processing extraction of interpretable data from encrypted storage and its transfer across the network to the end user become significant.
Even one to 3 seconds of time saved in launching an application can be critical in making an application user-friendly. For human users, even brief time is spent waiting become unacceptable when multiplied by a usage frequency of 20 to 50 times per day. Fast is good. Waiting is bad.
Computer systems will grow with time as the included data grows. Computerised health models taking into account test results and genetics results may well predict drug pharmacokinetics and metabolism better. At critical times, in critical health situations, a better understanding of medication kinetics can well allow a fine tuning of dosage regimens.
We no longer need to follow a “one size fits all” model of dispensing medications. We can tailor medication regimes to the individual based on knowledge of individuals make up/genetics. It is likely that we will use computer systems in the future for many more applications or reasons that we do at the current time. Computer data structures will be required to grow to meet these needs.
Kinkajou : You’ve mentioned graphical input systems for humans. You called these PICTS . Tell us more.
Erasmus : GUI input systems, I call PICTS. PICTS lend themselves to allowing data to be displayed as disease views, system views, or even anatomical views. The data can also be modified for display for different types of user, (general practitioners, specialists, Allied health personnel, and nursing personnel).
It is strange that in this era of fast computers capable of efficiently running a range of data input devices, we still work with a keyboard and a mouse. Few people even seem to have appreciated the possibility of using multiple computer screens to display data to a professional user.
No one has appreciated that different audiences need different data. I.e. Doctors and allied Health personnel want access to similar data but in different formats with different emphasis.
In the modern world, we can take advantage of a computer’s ability to adapt to how different doctors think differently. A PICT system is easily re-translatable to allow different doctors, (even if they are all says GP) s, to have the data displayed in their own individual display format, that they themselves have configured to work for them. Strangely, most computer systems insist on having their one input screen and their one or even a few display screens. PICTS allow a lot lot more individualisation than that.
No single structure will meet our needs forever. If there is one thing that is unchangeable, it is the need for change. Similarly as our usage of multiple data entry technologies grows, whether this be in the form of tools for data entry or data constructs such as PICTS, our databases will need to grow to accommodate these functions.
Goo Give us some examples of Electronic Medical Records (EMR): / PHR = Personal health Records we use today.