Blogger: Lyn Robison
As I have read and pondered our friend and esteemed colleague Joe Bugajski's life-threatening experience, I have come to four related points of conclusion, which I would like to express here. These opinions are mine alone -- other people, including Joe, might look at the facts and reach different conclusions. On a topic as momentous as this, we in the IT need industry need to get this right, so I am eager to hear your opinions on this topic.
Silos are always going to exist because of organizational boundaries – Joe's Allergist, the Urgent Care clinic, the ER, and the ICU all are silos, and to a certain extent, every nurse and doctor was their own silo too. This accounts for Joe having to give his medical history 11 different times, upon entry into each silo.
The lack of access to data residing in the other silos is a fundamental problem -- and not merely type, but instance data. A developer can define an object type and then can create multiple instances of that object, and computer systems must indentify each instance if they are to run properly. A type is defined in the object schema, and an instance of that type is identified by its address in memory. In a relational database table, the columns define the type, and the rows define the instances (and require a primary key to identify the instance). Knowledge of instances is absolutely essential for bridging data silos, because instance data is vital and fundamental to data handling. Doctors say they wish they could have again the paper medical chart hanging at the foot of the patient’s bed. The location of the data – its proximity to the patient – is how doctors used to keep track of the identification of that instance – the data moves with the patient. Given silo-ed IT systems, we need to implement the inverse of that: we need to enable the data to remain in its various silos, let the patient move around independent of the data’s location, and retrieve the patient’s data (based on the patient’s instance) from anywhere, on demand. (An alternative would be to put all of the data about a patient from every silo onto a small storage device that the patient carries with them at all times. This might be useful for identifying the instance, but this approach has several problems with conveying and rendering the information, which I can elaborate if needed.)
Too much structure in a medical data model can be deadly. As Joe has explained, medical terms are highly contextualized and nuanced. It is really, really hard to create a highly-structured model of medical data that is accurate. The oath behind every data model should be, “Above all, do no harm to the meaning of the data.” When data has to go from one doctor, into a computer system, and then on to another doctor, the computer system must above all, do no harm to the meaning of that data. The old-fashioned paper charts were semi-structured, and accomplished their job relatively well. A highly-structured and inadequate data model inside of an IT silo does not do this, as Joe’s experience illustrates. The meaning of medical terms is well-understood by the doctors but the meaning probably does not need to be understood by the computer systems involved. Medical computer systems would do well to just pass the information in an ungarbled manner between medical professionals. (BTW, the world wide web conveys information all of the time without its computer sytems completely understanding the meaning of the data, and the web does not garble the information in the process.)
Channels of information delivery are vital. Medical professionals need easy access to all of the information in every silo based on the patient’s instance, and they need to retrieve that information through multiple channels: tablet PC’s, laptops, PDAs, cell phones, in short, all of the electronic devices that are capable of conveying information. Our friends in Burton Group's NTS content area call this “unified communications”.
Imagine for a moment a medical information system that provides information based on a patient’s URI (uniform resource identifier). A medical professional could view this patient’s information, retrieved from whatever silos the medical professional chooses, on demand. The system could display both structured data such as food alergies, and semi-structured data such as medical charts, on which previous doctors have written important notes. The computer system does not need to understand those notes, but the doctors do. The computer system would need to use a flexible data model so as to never do any harm to the data that must flow between medical professionals. The previous doctor’s URI could be shown on chart to enable any subsequent care providers to easily contact that doctor if the notes they wrote are unclear. Such a system would enable the free flow of medical information, instead of hampering it.