Medical Applications – Page 5

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.

More on evidence based

This is a continuation on my previous post, “Evidence based vs anecdotal“.

I wrote an email to the main author of the chapter in “4th Paradigm”, Michael Gillam, and he graciously responded to my criticism by agreeing to everything I said and emphasizing that this is what they wanted to say in that chapter. He suggests that it may not have been clear enough in that regard, and I agree. Anyhow, it’s great to know that smart people are indeed having the right idea of how to handle the knowledge that appears in IT systems, often as a side benefit of having extensive amounts of data in them.

What Michael stresses instead is the benefit of having a real-time monitoring of the performance of treatments in the population. He points to the Vioxx debacle and how a lot less people would have been subjected to the increased risk of myocardial infarctions, had the systems been able to signal the pattern in large data sets. And in this he’s entirely correct, too.

So, in conclusion, we’re in total agreement. A problem remains, however, in that even I, the archetypal skeptic, was easily mislead to read the chapter in question as promoting the discovery of new treatment regimes from dynamic electronic health care data. And I think that is exactly what is happening when some new ill-conceived projects are started in health care. I’ve seen an increasing tendency to dream up projects based on just this, the idea that large sets of health care data will allow our electronic health care record systems to recommend for or against treatments based on the large accumulated set of experience data in the system. And I think the reason is that people like us that reason about how to handle that data and what to use it for and what not to use it for, don’t realize that snippets of our conversations taken out of context, may lead decision makers to take catastrophically wrong turns when investing in new projects. At least, that’s what seems to happen. Time for an anecdote from real life. (Note the strangely ironic twist, whereby I use an anecdote to illustrate why anecdotal knowledge is a bad thing.)

This is an entirely true story, happened to me about 30 years ago, while I was doing my residency in surgery. A trauma patient, comatose, with multiple rib fractures and abdominal trauma, in respiratory distress, was wheeled into the emergency room. I asked the male nurse to administer oxygen through a mask and bladder, while the blood gases got done. As the blood gas results came back, I stood a couple of meters away and quietly explained the blood gas results to an intern, saying something like “see how the oxygen saturation is way down, he’s shunting, while the carbon dioxide is lowered under the normal value, which you may find strange, but it’s because he’s compensating with hyperventilation”, etc. After a minute of explanations, I look up and I see that the nurse is holding the rubber mask over the patient as I ordered, but I see no oxygen line connected, so I tell him it fell off. He says “No, I took it off. You said he’s hyperventilating, so he should re-breathe without any oxygen.” OMG… this guy was actively suffocating the patient after overhearing one word of a half-whispered conversation and applying the only piece of knowledge he possessed that was associated with that word. Which was entirely wrong, as it turns out.

Admittedly, this particular nurse wasn’t the sharpest knife in the drawer; he did this kind of thing with frightening regularity. But still, this illustrates quite perfectly, in my opinion, what politicians and technicians are doing with health care related projects. They catch snippets of conversations, apply some wishful thinking, and formulate a thoroughly sexy project that in their opinion will revolutionize medicine. Except it’s all based on a fundamental misunderstanding. We have to become very much more clear in our discussions about exactly what we can use electronic health care records data for, and what we absolutely must not use it for. Yes, we can use it to provide warning signals to epidemiologists and pharmacologists, and ideas for future studies on new phenomena, but we can definitely not use it to make direct recommendations for or against treatments to doctors while they handle patients. The only recommendations that should be presented to them, are recommendations based on thoroughly and correctly performed studies, nothing else.

It’s up to us to see to it that the people in power get the entire conversation, and understand it, before we let them start projects that have the potential to destroy the advances in medical knowledge we have today. They’re entirely capable of suffocating this particular patient in the name of sexy IT health care projects.

So much knowledge in such a small box

I was doing the rounds at a nursing home out in the sticks the other day, and came to an old (all of them were old) woman with a urinary catheter and bag. Her problem, or rather her worry, was that the bag turned violet from the urine sometimes, but only the last week. The urine itself didn’t change color, only the plastic of the bag.

I already knew that some laxatives can cause the urine itself to turn violet if it’s alkaline, and I’ve heard of this phenomenon of the plastic becoming discolored, but as far as I remembered, it wasn’t alarming, so I just made the regular soothing doctor noises. But the nurse persisted, said she’d heard it could indicate urinary tract infections. iphone

So I pulled out my iPhone, opened Safari, and googled “violet urine bag” and lo and behold, there’s an article about the “Violet urine bag syndrome” from Osaka University, explaining how this happens in some urinary tract infections. Other similar articles taught me which bacteria are usually involved and when to look out for it.

I happily explained this to the nurse and told her she was right and I was wrong. Then the patient said to the nurse: “Amazing how they can get so much knowledge into such a small package” and they both looked with wonder and amazement at my iPhone. I was on the verge of explaining it wasn’t in the phone but on the ‘net, but then I thought: what’s the difference, really? Isn’t that just a technical detail? So I just nodded and said “yes, indeed”.

Zombies…

Like this company X I know, in the vertical application business. Same as company Y and Z I also know in the vertical application business, all of them doing healthcare applications like record systems, pathology systems, etc. Doesn’t matter exactly what they do or who they are, they are all representative of how that entire segment is looking and behaving right now. So when I describe one of them, I describe them all.

Right off the bat, I have to confess that my sudden blinding flashes of the obvious are brought on by an overdose of Seth Godin’s books. I’m on my fifth right now, “Survival is not enough“, with the subtitle “Shift happens“, and I’ve got six more to go. I simply bought all of them, as far as I know. (Seth, shouldn’t you provide for subscriptions?)

Everything he says, I already knew, but I didn’t know I knew until he told me. That’s the best kind of book, the one that digs out something that’s been lurking inside your mind and exposes it to the air. It’s also the easiest kind of book to read for me, since I need no convincing. It comes from me, inside myself, so it must be true (I’m almost serious).

So what about these zombies, what are they doing wrong? Well, they’re challenged, to put it mildly. All of them seem to have sales teams on crack, selling anything to anyone, if it exists or not. Then they’ve got backlogs they can’t handle, increasingly irate customers (some of them trailing lawyers and stuff), development languages and IDEs that are orphaned since years. They try one new development methodology after another, decide they have no time to implement them and abandon them again, after spending monumental amounts of money and time on stuff they never give a chance to deliver a return. They get involved, but they don’t commit (insert favorite farm animal references here).

Once they start losing orders, they abandon even more of the changes they tried out and go back to their old ways, just like a wounded animal curling up in the bushes, hoping the predators will pass them by. The worse everything gets, the more these people grab hold of methods and means that used to work so many years ago, but evidently don’t work anymore. They know it won’t work, but they can’t let go. Amazing.

Look, there’s one message here, that seems not to penetrate, and that is: if your old methods don’t work, change. The worse it gets, the more reason you have to change. The sooner you change, the more capital and time you have to bridge the change and pick up on the other side of the divide. If you wait until there is nothing left, there is, um, nothing left.

But it’s pointless. They will not uncurl and come out from under that bush. Poor bastards.