Let's split this discussion into the different parts of the name
What's this "Issue" thing?
IOTA, as the name says, is centered on the "issue", which is a disease, a symptom, or in some special cases even a particular treatment regime. An "issue" is closely related to what Wade described as a "problem" in the Problem Oriented Medical Record (POMR) 50 years ago, but is sufficiently different to deserve a distinct name. Hence "issue".
The POMR involved more than the definition of "problems". It also tied each encounter to one or more problems, and it also specified a subdivision of the notetaking during an encounter into Subjective, Objective, Assessment, and Planning, giving rise to the "SOAP" style of maintaining encounter notes. Since we don't want to drag in all that into this new model, we had to avoid using the "problem" moniker.
Most, if not all, efforts to improve the medical record until now have concentrated on different ways of improving the encounter notes, with varying levels of success. None of these efforts have in fact had much effect on actual clinical work. This is not so strange, since all that these notes do is record what has happened; they do not assist much in finding out what //should// happen in the future. And this is where our "issues" come in.
Let's forget about encounters and concentrate on what issues the patient has. Let's say our patient has diabetes type 2 and hypertension. If the medical records tell me he's been to Dr Snuffelbridge yesterday and to Dr Rannatag last week, I may be impressed but I'm not learning much about what I'm supposed to do about the patient. Unless and until I read all they've written and figured out what they hadn't got around to doing yet, and that is when I know what to do.
But if I instead saw "Diabetes type 2" and "Hypertension" when I opened the journal, I could check each of those issues to see if the crucial measurements and lab values were taken and were within desirable limits, which followup steps have been taken and which remain, and finally, if I'm interested, what other doctors the patient has visited.
In other words, I want to know, in order of priority:
- Which issues the patient has
- What needs to be done about them
- What has been done
- What to look out for in the way of related diagnoses and contraindications for meds
- And finally, maybe, when and by whom the patient was seen
What our current systems tell me, however, is:
- When the patient was seen and by whom
- What was done then
- When the patient should come back
From that information, I have to derive in my mind what is missing in the story and therefore what I should do. Assuming it wasn't mentioned in another encounter note I didn't read, of course. That is so ass-backwards as to defy belief.
This ass-backwardness was a minor irritation until the medical records took on massive proportions. In Sweden, most medical records are now shared between hospitals and primary care in fairly large regions, which means that the pure volume of encounter notes becomes too large to work through by one physician during a single patient encounter, so a lot of information is lost. It's practically impossible to deduce what ailments any particular patient suffers from, using our current medical records, and that is where the current systems fail totally.
We have to fix this.
Because the top level entity in this system, just under the patient, is a list of "issues". Under each issue you'll find the rest, that is encounters, doctors, medications, referrals, lab requests, etc.
"Tiered" makes me think of DCOMCNFG (shudder)...
Well, before Microsoft came along, that word didn't call up images of swamps and quicksand like it does today, and I think the word deserves to be restored to its original meaning, that is "layered". Say "Layered is good" one hundred times every morning until you get rid of the bad COM taste and all those facade objects and stuff. You'll get there.
Everyone calls everything "architecture" these days. Or themselves "architects". Well, so do I. And I am. And this is.