Open development of the medical record

To summarize where the medical record is and where it is going, we could say the following. And if we can’t, please tell me why not.

The frontend of current medical records systems simply don’t work in practice. They’re hard to use and are unsuitable to help in ongoing work. The only thing they do is to retrieve old documentation, and they do even that one task very badly. Even if they did do it perfectly, retrieving old documentation is just one little part of what we need to be effective as clinicians. The support we need more, that is knowledge and planning support, is practically entirely absent.

The backends of current medical records are in just as bad a shape. We have a number of smaller and larger incompatible databases holding information and few workable standards to allow interchange of information. There is a constant and unresolvable conflict between building large, unified database systems and small independent systems. None of these extremes work and neither does a mix of them.

So what we can conclude is that current medical records generally collect the wrong kind of data the wrong way, and both storage and interchange is also wrong. So what is right about what we have? Hardly anything.

Why did this come about? Largely because the medical records have been built as if they were some kind of accounting system, but based on kidneys, white blood cells, and sneezing instead of money. But they shouldn’t be.

The reason for this, in turn, is that most of the effort to create the medical records and all the standards that go into them are done by lay people and non-practicing physicians. Clinicians have stayed out of this effort and haven’t the training or assurance they need to convert clinical workflows and thinking into information technology terms. And they haven’t received any help in getting there, either.

What we need to do is to create a movement of developers and clinicians that together build the next, working, generation of medical records. This movement needs to be open to all, use lightweight processes, and modern architectural principles. It needs to be as free of proprietary elements as possible, while allowing linking to those proprietary systems already on the market.

The following items come to mind when thinking about this as an open project:

  • iPad based UI
  • linking to legacy systems containing current medical records
  • a document system that is neither a large or a small database, but independent of such thinking
  • an issue-oriented architecture that uses legacy data to enrich the issues, so that older journal data is not lost but reused
  • reuse of whatever can be used from other open projects, both within IT in general and medical records
  • a minimal dependence on standards, but when the need arises, it should be on open standards

Note that the last point does not mean one should strive for non-standard interconnects, but that one should strive to eliminate need for standards when the interconnect can be usefully encapsulated in such a way that there is no need for agreements. Big difference. Just saying.

Confidentiality of the right thing

If we use “issues” as the top level item in the EHR, instead of the “encounter”, it comes naturally to attach confidentiality attributes to the issue instead of the department, doctor, or encounter. That’s a huge improvement. Let’s take an example to show why.

As things are in current systems, confidentiality walls or borders are located around certain services. The reasoning goes that if a patient doesn’t want his psychiatric problems to be known, then any records entered by the psychiatrist should be confidential and not accessible by other specialities. This is so screwed up. The psychiatrist is usually the one that handles embarrassing psychiatric problems, but this is not necessarily so. The psychiatrist may actually treat the patient for something entirely un-embarrassing like a headache or irregular menstruation or hives, and does that mean that the patient’s hives now are confidential? Of course not, but that’s not how the systems we have reason.

Let’s take another example. If I, as a GP, treat a patient for syphilis, there’s no confidentiality attached to it. If the same patient was treated for the same disease by a venereologist, then there is confidentiality. This is bloody nonsense, but this is how things generally work. In the system I’m working mostly, that is not a problem, since no confidentiality is implemented at all. (Don’t ask…)

It must be obvious to most that it is the “issue” that should have confidentiality attributes attached. If the patient doesn’t want the news about his syphilis to spread, the issue “syphilis” should be confidential, irrespective of which doctor or speciality that treats the patient. It’s up to the patient to decide if he wants any other particular specialist or department to know about this diagnosis.

The danger with all these confidentiality limits is that a disease that normally isn’t important to the treatment of another disease, may occasionally be extremely important, but remains hidden. If confidentiality is attached to issues, and issues to the patient, then there is the possibility of the system warning the user of hidden pathologies that are important, simply since this system actually knows what an issue is, and that other issues may include warnings about the simultaneous presence of these issues, including pharmacological interactions.

For instance, our syphilitic patient has a problem with suspected neuropathy, but the syphilis is hidden from the neurologist examining the patient. If the clinical guideline for “peripheral neuropathies” includes the differential diagnosis “syphilis”, the system is able to warn the physician that there are hidden issues that are related to the workup he is currently performing and that he should take steps to be allowed to unlock this information.

Having issues

In my last post I described the positioning of the SRR record and I also painted it as a form that can either be predetermined in the form of a clinical guideline record or a free form record to which the doctor can add steps, or a mixture of both. Since we don’t want to keep calling this thing an “SRR”, and we can’t call it a “symptom” or a “pathology” or a “disease” for reasons I’ll soon get to, I think we need to call it an “issue”.

It would have been natural to call it a “problem”, but there’s a problem with calling it a “problem”, namely that 50 years ago or so, Wade described the Problem Oriented Medical Record (POMR) which has a lot of the characteristics of what we here describe, but still differs on some crucial points. And since I don’t want to run in to prejudices connected with POMR and get remarks like “it’s old hat”, “we know about that”, “it never worked”, and more, I prefer to call it something else. And “issue” it is for now. Especially since I can’t think of anyone calling this an “issue” up to now.

Recapping, we have a list of “issues” under the entity “patient”. Each “issue” can be a symptom, a disease, a hypothesis, a plan, or even in some cases a therapeutic regimen. Let’s run through a couple of examples just to illustrate what it is, and what it is not.

“Diabetes type 2” is an issue. It has diagnostic criteria, recommended follow-up lab tests, regular checkups and referrals, recommended therapies, diagnostic codes, and contra-indications such as “careful with some diuretics”.

“Migraine” is an issue, and so is “tension headaches”. Interestingly, “headache” is also an issue with its own recommended diagnostic steps, but it also has a list of differential diagnoses, including both “migraine” and “tension headaches”. A “headache” is not a diagnosis but a symptom, but it needs to be a first class “issue” anyway, since that is the “issue” we’re working with until we can replace it with a more definite diagnosis.

So now we encountered the “replacing” of issues. This can happen in the “headache” case, among many others. The patient presents with headaches, and immediatly gets a “headache” issue assigned, which is prefilled with a differential diagnosis including among other things “migraine” and “tension headaches”. As the physician needs to exclude “migraine” first, the issue “migraine” is attached to the main issue “headaches” and you can work through the recommendations in “migraine”. If “migraine” is confirmed, it actually is lifted a level and replaces the main issue “headache” which is then removed from the list. If, on the other hand, “migraine” is excluded after some examination, the “migraine” subissue is removed and it is marked as “excluded” in the list of differential diagnoses in the “headache” issue. And so forth.

Don’t become nervous when you see all this insertion, moving, and deletion. That is how it looks to the user, but behind the scenes, everything is saved, version controlled, listed, and is being audited like there’s no tomorrow. Except we don’t want to actually see any of that unless we ask for it.

What’s this SRR thing, then?

In my last post, I arrived at the conclusion that the main element in the electronic healthcare record should be a list of problems and each of those problems should be an SRR, that is a document that is updated with  the most recent data pertaining to this problem, not a document that gets replaced and shoved out in a queue as in a TAS. (Back up a few posts to find the definition of these terms.)

Ok, fine, if you accept that, we now have a problem of defining the contents of this SRR, this problem document. It could very well start out as an empty document or a document with a few predefined sections such as “Tests”, “Clinical signs”, “Medications”. Under each of those sections, the doctor could then add in the tests and signs he plans on doing or checking and then later check them off or fill in results. That’s certainly one viable method.

But we’ll soon notice that most problems people show up with are pretty common and have established guidelines we can reuse. For diabetes, for instance, we very well know which tests we want to perform, which values constitute diagnostic values for the disease and which follow-up referrals and exams that need to be done. Even criteria for reporting the problem to different tracking databases are pretty clearcut. So it would only be natural to keep these guidelines in a common database so all doctors using the same system will follow up the same disease the same way. Additionally, if the guideline changes at some point in time, the diagnostic and treatment plans of patients already in the system will signal the change to the physician the next time the patient is seen.

But won’t it be prohibitively expensive to set up all these guidelines? Um, no, it’s already been done. All these guidelines exist at least on paper and in most places in the world as PDF documents. But in some places, such as Sweden, we even have them in an almost immediately useful form. Just check out the site viss.nu and there you have them. These guidelines can be used almost without change in an electronic healthcare record system, if checkboxes and input fields are added and a copy of the guideline is linked to the individual EHR patient file.

In conclusion, we actually do have the SRR we need for the medical records. It’s either an empty document the physician can add his planning to, or it is a predetermined guideline adapted for this system, but taken from one of the many excellent repositories of clinical guidelines that already exist. Which then also finally get to be used in real practice.

Data kinds and the medical record

In my previous post, I described the two kinds of data that I think I see in most, if not all, applications. The two kinds are the “state reflecting record” (SRR) and the “transformation additive series” (TAS). Cumbersome names, I admit, but if you have a better idea, let’s hear it.

A medical record, be it on paper or in a computer, is built up of only a TAS, with no SRR in sight. That is, it consists of notes, each by a certain person and on a certain date and time, and added in chronological order. Each note consists of the patient’s complaints, results of examinations, answers from referrals, medication changes, conclusions, plans, or any combination of these. Even if the note contains a summary of earlier notes or a summary of the patient’s current state or history, this summary is still part of the note and thus embedded in a record that is just one element in a TAS.

In some systems you’ll find a summary document about the patient as a whole, and this document is updated with the most important new findings or treatments as you go along, but it has no direct connection to the chronological notes and is usually of such poor quality that it really can’t be considered an SRR.

The list of current medications, however, does qualify as an SRR, but its scope is limited to just medications. Interestingly, there is usually no TAS connected to this medication list, so the chronological information that is very important especially for medications, is missing or very hard to recover.

The most important information for the physician when seeing the patient is not when things happened or who made it happen or recorded whatever happened, but what the current state of the patient and his pathologies is. It used to be, back when patients had the same doctor for many years, that this information was stored inside the doctor’s head. The information he had trouble remembering, such as exactly when he did exactly what, was the only information that was recorded in the medical record.

But today, there generally isn’t any doctor around that knows the patient and the lack of a document describing the patient’s current state is a real problem. Doctors have developed a habit to reconstruct the current state of the patient from the historical records, but this is a very laborious and error prone process. What makes it worse is that it has to be reconstructed at every new encounter, since there is no way to store that current state so it can be reused and expanded upon at the next encounter. There simply is no such mechanism available in the medical records systems.

As a concrete example, let’s assume I see a patient for a general checkup. First, I have to scan through the notes to make a mental list of all the ailments he has or has had, while at the same time figuring out how each of those ailments have evolved and are currently treated. For instance, I may find a mention of a high blood glucose level three years ago, another high level a couple of months later, together with a conclusion that the patient has type 2 diabetes and that medication is started. Half a year later I find a note that the medication was insufficient and that a second product was added. The next three notes are about a stomachache the patient developed, and then I find another note telling me his diabetes is now under control. I haven’t seen any mention of an ophthalmology referral to check the state of the patient’s retinas, so I have to run through the notes one more time looking for that. If I don’t find any, I’ll have to write a referral note for that.

If I had had a form for diabetes type 2 with the medication field containing the current medications and the ophthalmology referral field still empty, I’d known all this in a flash and with a much greater confidence, but there is no such thing, so I’m forced to go through this frankly ridiculous process of reconstructing that form in my mind every time I see a patient.

Oh, and don’t forget, the patient may have several problems, each of which has to be evaluated like this. Some of these problems I don’t even know about until I run across them in some old note. Finally, once I’ve worked myself through this process, only then can I actually start working with the patient.

If we go back to the SRR vs TAS view of data, it’s clear that the SRR is simply missing and I have to reconstruct the SRR every time I see a new patient. This worked back in the time when I still remembered the state of the patient (the SRR) from the last time I saw the patient, but nowadays most patients I see I’ve never seen before, so this system fails abysmally.

A tale of two data kinds

In my neverending quest to straighten out the electronic healthcare record, I have to introduce a view on data that is essential if I’ll be able to explain what’s wrong with the current model and how it should be fixed. As always when we’re in a mess with the design of systems, we climb the abstraction ladder a level of two to find the underlying (“above lying?”) abstractions, just like particle physicists try to find ever smaller components of components.

I’m seeing all applications using two kinds of data, one that is continuously updated to reflect the current state and the other where one adds records to reflect changes to data. I’ll call these, with very unsatisfactory names, the “state reflecting record” (SRR) and the “transformation additive series” (TAS). I’ve intentionally used really unusual terms to make it easier to search for these terms later. By the way, I’m absolutely positive I can’t have invented this view of data, but so far I’ve not come up with any references to literature describing it this way. I’d be really grateful for any pointers to preexisting descriptions. So, lacking any references, I’ll have to describe it here as well as I can.

If we start with the state reflecting records (SRR), this can be exemplified by an image in an imageeditor. Whatever the editor does to the image changes that one image data blob from one state to the next. Whatever you do, it’s just that one blob. A text document, or a blog post like this one, are other examples of SRR. As long as we don’t add any other kind of data structures linking to the SRR, there is no way of telling what the SRR looked like before the most recent change, or even what that change was. The SRR only reflects current state of some object or collection of objects. A relational database is another example of an SRR, by the way (if we leave the transaction log out of consideration).

Transformation additive series (TAS) are quite another animal. A keystroke logger is TAS based, for instance. Every keystroke creates a new record. Even a backspace doesn’t remove a previous record but adds a new record containing the backstroke. A network communication session is a TAS. More and more packets are piled on. The change records in a source control system forms a TAS. In principle, a TAS consists of a growing number of records, each immutable, added in a series, where any subset of the series corresponds to a transformation of some other object. A TAS must in principle always refer to something else, and that “something else” has to be in essence an SRR.

Having these two cleancut types of data, we can now form a number of data design patterns from them. “Patterns” is taken to mean “desirable patterns”, while “antipatterns” is taken to mean “undesirable patterns” that, by implication, are seen in the wild to a disturbing degree and should be avoided if possible.

Patterns

If we start with desirable patterns, or just “patterns”, we can describe a few typical ones easily. Most, but not all, patterns employ an interacting set of SRR and TAS elements. Employing the principle of not duplicating data or relationships, we first find that we have to select either the SRR or the TAS as the primary data and the other as the secondary data. In a functioning pattern, we should require that the secondary data kind should be fully derivable from the primary.

Pattern 1 – SRR only

Typical application: a simple paint program. The image itself is the SRR. The paint program may have a single level undo function, which in a practical sense doesn’t qualify as a TAS, but if it has an unlimited level undo function, it is not any longer a simple SRR pattern. This pattern is clean, there is no possibility of conflict of data since there is just the one instance, the SRR itself.

Pattern 2 – TAS only

A sniffer log of network traffic is a typical TAS only. There is no conflict possible here either, not as long as you don’t try to make sense out of the captured packets, and if you do, it’s not a “TAS only” pattern anymore.

Pattern 3 – TAS primary

Any system that contains both an SRR and a TAS, but where the SRR can be fully reconstructed from the TAS belongs in this pattern. A typical example is version control systems. If you lose your original document, you can still recreate it from just the TAS, the series of change records. An accounting system can also be built this way, but rarely is. If each invoice, payment and other entry is kept in a TAS, you can always reconstruct any general ledger, sum, report, or tax form at any time simply from the TAS. Sadly, most real world accounting systems don’t exploit this idea, leading to the sad apps we see today.

In this pattern, you will often find a single immutable SRR, the start state. I still regard it as a “TAS primary” pattern.

Pattern 4 – TAS primary, SRR cache

A minor, but in practice very important, variation on the previous pattern is when the SRR is fully reconstructable from the TAS and an optional SRR start state, and is kept for performance reasons. Micrografx Paint, may it rest in peace, worked like this if I remember right. Or maybe it was Micrografx Designer. Or both. In this app you modified the image any way you liked, but each modification resulted in a change record in the “history” panel. From this “history” panel you could delete any step and rebuild the image from the beginning with that step omitted. So the current image could be reconstructed from the starting image plus the history. The final image is kept in Micrografx Paint as a cache so the program doesn’t have to rebuild the image constantly. That would have been much too slow. But losing the current image wasn’t a problem. Consistency was guaranteed, only the history record, the TAS, actually had authority over how the image would look. If the TAS and SRR gave different results, the SRR was corrupt. By definition.

This pattern also contains an inherent consistency verification on the TAS, namely that the SRR that is built from a complete TAS must make sense. If the SRR is an image, this is difficult to ascertain, since any image is valid, even if you can’t make sense out of it if you’re a human. Just look at some modern art and you’ll get my drift. But in many other cases, such as accounting or medicine, a TAS can contain records that result in an invalid SRR. Another example is source code control. If the source code change records are invalid, the source code you build up from the change records may not be compilable. This test is only valid if you require all source code to compile before you log it into the source code control system, of course.

Adobe Photoshop also has some of this functionality, but the history record seems not to be sufficient to rebuild the image, so this would form an antipattern.

Antipatterns

Now for the antipatterns. When reading any of these antipatterns, think of real examples in your own environment, and you’ll soon discover that these systems you know and hate are bottomless sources of irritating inconsistencies and bugs. That’s no coincidence. Most of that has as a root cause the unresolved ambiguity between what’s primary and what’s secondary in the data kinds.

Antipattern 1 – SRR primary, derived TAS

A text document in a word processor with the “track changes” function switched on. You still modify a single SRR, the document itself, but every change is causing the creation of a record in a TAS in the background. Since the TAS will never be complete enough in practice to reconstruct the document itself if it’s lost, the TAS can’t be primary. But the SRR can never reconstruct the TAS either, so the TAS isn’t fully secondary.

Audit logging in most applications fit this pattern as well. The secondary TAS is a rather improvised collection of data pointing to datetime, user, kind of records or whatever else popped into the developer’s mind when writing it, usually missing the pieces of data you turn out to really need later. Since the TAS is derived and doesn’t have any function to fill at all during normal system usage, it’s functionality is never put to the test until it is too late.

Antipattern 2 – Undecided primary

Most accounting systems can’t make up their mind what’s primary and what’s secondary. When you input an invoice into the system, it’s not reflected in the general ledger until you “post” it and once you do you can’t change it anymore. There’s no way to “unpost” or to rebuild the general ledger from recorded invoices. It’s as if the invoice series (TAS) rules until you “post” them, and then the SRR rules even though the TAS is still there. There’s no end to the confusion and assbackwardness that results from all this. (Don’t tell me the law requires this, in most countries it doesn’t. The law generally requires that you should not be able to do undetectable changes to your accounting, which is something else entirely. Don’t get me started.)

Conclusion

The only patterns that seem to work consistently are thus either SRR or TAS only, or combinations where the TAS is primary. There seems to be no instances where the SRR is primary and a connected TAS is still useful and reliable. Surprisingly, most real world systems seem to be build in exactly this way, that is with a primary SRR and a tacked on TAS with a confused division of responsibilities. Not so surprisingly, most of these systems have a lot of problems, many of which can be directly tracked to this confused design.

What’s next?

In the next post, I’ll get into how this relates to medical records. I can already divulge that medical records as they are today, are pure TAS based. Think about that in the meanwhile.

Don’t look at us

According to one Swedish trade rag, the US administration is looking admiringly to the Swedish model of IT in healthcare. I can’t find any US sources that confirm any of this admiration, so it may be more wishful thinking than reality. Please correct me if I’m wrong. They’re not mentioning sources, so it’s hard to check.

Anyway, even though Sweden has introduced IT into almost 100% of primary care and almost as much for specialist care, this in itself means very little. Healthcare i Sweden is run by bureaucrats, very few of whom have any real knowledge of direct patient care and not much interest in it either. Their interest is in running an efficient organisation, getting good measurements and statistics and controlling the flow of information and money, and it that they do succeed. The IT systems they purchase and roll out are almost exclusively intended to implement this control more effectively. You have to understand that our IT systems are defined, purchased, and run by these bureaucrats, with very little, if any, input from  the medical professions.

Now, don’t get me wrong. Swedish healthcare is pretty darn good, the numbers speak for themselves. But none of that is due to our IT systems, since these IT systems do practically nothing for the actual patient care.

What this means for the USA is that there is only one single thing the US administration can learn from the Swedish IT initiative and that is how to order a shitload of cheap Dell desktops and roll them out everywhere, but I think the US administration can figure this one out for themselves. None of the software we use for electronic healthcare records (EHR) is of much use to the USA.

In the US, billing is a central function in all EHR systems, and we simply don’t have that in ours. We don’t do billing, it’s as simple as that. A main feature of Swedish systems is a shared EHR between all care givers within a geographical region. The largest systems we have don’t even implement any kind of confidentiality barriers between care givers, so that psychiatric history is visible to all other care givers, whatever the patient may think about it. Interestingly, this implementation is actually against Swedish law, but since it’s rolled out by the government, the government seems reluctant to do much about it. I have a really hard time imagining the US medical profession wishing for unlimited sharing of their EHR contents to everyone within a certain geographical radius without any say in the matter.

The real savings in healthcare will only be realized when EHR systems support doing better healthcare. That is, when these systems are based on decision support, in turn based on evidence based medicine (EBM). Even though Sweden is much further along in the roll out of IT systems in healthcare, Sweden will never actually implement any system that improves actual healthcare since all decisions about which systems to implement are taken by bureaucrats, not medical people. But the good news is that this is not the case in the USA, where these systems will be financed mainly by the physicians or their organisations, so the incentive to create systems that work for better healthcare does indeed exist over there.

So my advice to you is: don’t look at us.

I can’t help it…

…but I have to show you this. I almost wet myself reading it.


	From:     Central Inteligency Agency 
	Subject:  From Central Intelligence Agency
	Date:      8 February 2010 9:22:14 GMT+01:00
	To:         undisclosed recipients: ;
	Reply-To: inteligencyofficer@yahoo.in

Central Intelligence Agency
City in Carter Lane, next to St.Paul's.
https://www.cia.gov/

Att: Beneficiary,

This is letter from the Central Intelligence Agency (CIA) You was

reported in this office last year that you have been dealing with
some Nigeria Hoodlums through the internet, which we have monitored
you and confirm that you have sent so much amount of money to some
Hoodlums in the internet through Western Union and Money Gram all in
the name of transaction.

You have been advice to quit every communication that you have with
all those Hoodlums for the main time because we have marked some
trace on there email address and we are trying to get them arrested
and if you insist and continue with them you will be arrested, So
right now you are advice to disconnect communication with them and
give us details about them.

Get back to us as soon as possible.
Mr. Mualler
Central Intelligence Agency