Issue Oriented Tiered Architecture for Medicine
An open project built on modern principles, intended to create the medical records systems that serve primarily to improve the diagnostic and therapeutic workflow in clinical practice.
Introduction
Yet another open project... as if we didn't have enough already. But we really do need this one. This open project is initiated by one very disillusioned physician/developer who is going totally crazy trying to use really poor software to do his job, while knowing full well that it needn't be so.
The software we have today is built to document everything you do, but it doesn't help you one bit to find out what you need to do in the future, and that is what we really need the software to assist us with. But, as I said, it doesn't. Do you know that the medical records software we use today don't even have the concept of "disease" in them? That's like having accounting software that doesn't have the concept of "money". And about as useful.
Typically, a medical record system looks like this, seen from an entity relationship standpoint:
Clearly, the designers must have thought that we doctors are extremely interested in knowing which other doctors the patient has met and exactly when, but this is a huge misunderstanding. That may be interesting for people arranging cocktail parties, but has very little to do with medicine. What we do want to know, though, is what ails the patient, that is what health issues he has, so a few of the entities at the top should be related as follows:
vacances
This little change in the basic domain analysis has wide-ranging consequences. First is that the medical record finally starts to work for us instead of against us. Secondly, that we have a channel to feed new scientific discoveries and guidelines to the doctors that need them, and at the right time and place when they need them.
Note that the second diagram doesn't even contain the entities "doctor" and "encounter". By that I don't mean that they aren't kept somewhere in the system, of course they are, but that they're not important enough to qualify for a top level diagram.
The people
The people involved are you and me.
Background
The evolution of medical records
How current systems work
How medical records should work
Evidence Based Medicine vs Experience Based Medicine
Frequently Asked Questions and Frequently Misguided Solutions
The problems we solve with iotaMed
Critical Success Factors
Presentation Outline
The parts
The basics of Iota
The Iota Medical Journal project
The Iota Apple iPad project
The Iota Desktop project
The Iota data interchange project
Related projects
OpenEHR
OpenEMR
Related sites
Ursecta - English language blog on tech and medicine
Vård IT - Swedish language blog on IT in healthcare
Vård IT Forum - Swedish language forum on IT in healthcare
List of links to other blogs and sites with some relevance to this subject
The plan
This is about how to make this come true.
The business plan
How to register and contribute
This is a wiki, so all you need to do is to register and start adding pages or changing the ones that already exist. One thing can't be done by just anyone, and that is uploading files such as images, since the ability to add actual files to the wiki isn't without risk.
If you need to upload an image, please send it to me and I'll do it for you. If you put in a marker on a page where it needs to go, I'll add the link, too. If you need to do this regularly, tell me and I'll enable your account for uploads.
Invitation code for user registration
Spam in the form of page spam and comment spam is with us, so I had to limit both edits and comments to registered users. Then I had to limit registration to users who can present an invitation code. That invitation code is not individual, it's just one word, namely 'iotaRulez'. I'm figuring the spambots aren't smart enough to read this paragraph, then go register themselves, but I do figure the average user gets the idea.
There are no comments on this page. [Add comment]