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.