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.
I wonder at your juxtaposition of “open” and “iPad.” I can think of no platform nor any manufacturer less supportive of open systems than Apple.
David,
That’s not logical, since by the same reasoning there would be no open projects for Windows. The only thing that is a minor issue is that the actual rollout of the app has to be done by someone with a store account. But nothing stops several people from rolling out different branches or versions. I think.
Also, I don’t even agree with the sentiment, since much of what’s in OSX is open source, such as webkit. I mean, is IE open source? OTOH, even if it was, would we care?
But I’ll say this: once the iPad is out and once “the others” get the idea that it is not just a windows based OS but small and fingered, there’s no reason why the same project couldn’t be ported to new slates. But right now, there aren’t any alternatives.
Very interesting idea and something that’s needed badly. As David says there are some strong IPad alternatives coming, for example this android based freescale pad. http://smartmobiledevices.wordpress.com/2010/02/21/apple-ipad-vs-freescale-tablet/
Android has got a store, and is quite easy to develop for it (Java, Eclipse).
The Freescale seems like a nice idea, and as soon as it runs Objective C and Cocoa, I’ll definitely get one. Seriously, I’ve used tens of major languages over the last 30 years, and most of them have been real obstacles to development. Objective C gives me hope again. I’ve tried Java and can’t say I like it, without going into details. I would hate to have to develop in it.
OTOH, when doing the architecture for iotaMed, I’m certainly not going to try to limit it to the iPad, even though I personally will stick to that, at least for now. I see it as important that the pad, whichever kind, is doing little more than being the presentation layer, leaving the business layer to a fixed machine handling a number of the pads. The protocol between the handheld pad and the desktop “anchor” should be simple enough so that it will not be a problem to develop presentation layers for multiple devices without having to reimplement the business layer. At least, that is what I’d like to see.