During the early 1990s I put considerable effort into designing a healthcare management application intended to fit Canadian needs. Prototyped used Unify's Vision/Accell toolset, this assumed a province wide provider network, an informed patient, both outcomes and activity cost information, and a single payor process.
At the time, however, Alberta policy makers had no objective information about health system performance to go on, were caught up in a national urge to blame the patient for cost increases, and took their IT advice from data processing people with billion dollar systems redevelopment ambitions - with the result that "regionalization" beat information as the policy of the day.
What Canadians spend - and what we get | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Canada's three richest provinces are
British Columbia, Alberta, and Ontario. For fiscal 2009/10 their budgeted health care costs
came to:
These nominal budget numbers under-estimate real costs by an unknown amount, most probably in the 15 - 20 percent range for most provinces. Additional monies spent on health care come from sources such as: deficit operations; extra billing (particularly through the collection of health care costs from automobile and liability insurance issuers); capital consumption (particularly through delayed/refused maintenance); hidden subsidy (particularly through infrastructure development and government wide IT); and, the separate health care systems maintained at both the provincial (mainly the Worker's Compensation Systems) and federal levels (e.g. for police, parliamentarians, natives, and the military.). So what do Canadians get for their money? Almost no information about the effectiveness of health care in Canada is published and there is essentially no legal redress for harm caused by the medicare system or people working in it. As a result Canadians must base their trust in the system on their politics or on personal interactions with people and institutions whose professional records and credentials are opaque to them. There is data, however, on how long patients wait for services - compiled annually by the Fraser Institute. Their 2008 report: Waiting your Turn: Hospital Waiting Lists in Canada (PDF), includes a table showing the delays Canadians can expect between diagnosis by a general practitioner and action on that diagnosis in a hospital or other treatment center:
What this means is that about half of all BC residents who have managed to see a GP and been told that they need plastic surgery, then wait for more than 34.9 weeks (244 days) for the actual procedure - while those needing neurosurgery can expect to wait 29.7 weeks (208 days) between diagnosis and action. |
There may soon be an opportunity to reverse all of this - meaning the policy assumptions (see the huge box, below) that led to the present mess.
How things got so bad: a capsule history of medicare's failure in Canada |
"Roemer's law" holds that health care providers create their own markets; i.e. that supply availability is the principal
determinant of health care services demand. There is a lot of empirical evidence for this: make a new service available,
whether that's a doctor's office, a hospital bed, or an operating theater, and pretty soon it will be fully utilized.
The conventional explanation, that lots of people abuse the system, lies at the root of Canadian government response to
health care cost escalation - because if you believe Roemer's observation explained by patient and practitioner
malfeasance, then supply management (aka rationing) is the obvious answer.
When information system failures allowed this to become dogma in the 1980s we immediately got supply management policies like the billing caps and the late 80s and early 90s reductions in Canadian medical and nursing school enrollments driving today's practitioner shortages. In the longer term we got regionalization and program funding: because "health care services" cannot be rationed through the funding system without first defining them at the procedure level, then grouping those services into programs, and finally allocating program responsibility to providers. "Regionalization" meant that bureaucrats pooled the physical and human resources available for healthcare in a region, and then applied program funding to allocate work between them. However, if Site A is funded for this, and Site B is funded for that, then some third party has to decide whether the patient should be sent to A, or B - and so regionalization immediately took the diagnostic role away from hospitals and forced GPs to turn to specialists for diagnostic confirmation and non procedural treatment - thereby creating today's waiting lists. (These were short term adaptations, in the longer run program funding collapses the regions into city sized hospitals where stove pipe funding forces both continual new construction and continual bed closures, concurrent layoffs and hiring, and ever increasing practitioner and administrator reliance on fudging the paperwork in the interest of serving both the institution and the patient.) Supply management has had many other side effects - for example:
|
However, if the policy fixes go through there will be a panic need for a new patient information system -one rather a lot like the one I put together back then. As it happens you can license Vision today to run either the original or an automatically generated java variant, but a lot has changed since then, I'm not sure what rights my then employer might have, and politically? -well, offering the same solution they sniffed at twenty years ago just isn't on.
Back then an overwhelming majority of the code went into fitting practitioner work processes into the HL7 data framework - for those unfamiliar with it, the HL7 standards establish 60s style, data processing oriented, definitions for thousands of individual health record data fields, classes, or messages and are widely considered more or less mandatory for any medical data application.
And this, of course, is the specific issue I'm looking for advice and comment on here: do I need to care about anything like HL7 for a unified, province wide, patient information system? and, if not, why wouldn't modern web tech - specifically SAMP with HTML5 - let me produce a much cheaper, more flexible, system that's easier for everybody to use?
Data standards based applications are "all about" the substitution of a common set of definitions for contextual interpretation - it's really COBOL thinking vs SAMP thinking; structurally: 3274 card image pages vs google.com.
What drove this originally was technological limitation: because the first data processing machines (circa 1920) could do little more than count and sort, you couldn't really use them without very sharp limits on what the data meant and how you could express it. This ended, however, with the emergence of science based computing in the 1940s - thus RAND and others were building contextual search applications for the U.S. Airforce as early as 1956; and today, of course, we can have computers transcribe dictated notes, parse those notes for the bits we need to forward to third parties, and automatically organize notes, results, and scheduling information behind easy to use web pages.
Oddly, the biggest difference is not in how hard these things are to code, it's in how hard they are to use - and the costs of that usage.
Compare Yahoo's original structured search to its latest google like free form search and you'll get the idea, but it's subtler than that because usage costs come in two distinct forms. On the dollar and efficiency side, a doc using a SAMP/5 style system would simply dictate or type notes and the system would pretty much take it from there - where someone using an HL7 style system would face a forms interface whose complexity would vary with the subject: 54 fields or so if the notes recorded a patient interview resulting in several test orders and a prescription. (About 16 fields auto-fill - three others are duplicates - i.e. you type them twice for accuracy, like password set-up)
The more important differences, however, are in the other end of the recording process: when those notes are needed again, the HL7 system is more likely to contain significant errors or omissions, more likely to lead to practitioner "failure to notice" error, and far more constrained in the information it conveys. A SAMP/5 will, in other words, not just cost a lot less to implement and operate, but will produce far better results for the patient - and that's really what counts.
The argument for applying an HL7 like set of standards is that these enable trustable interchange with other applications - including those managed by other provinces, by hospital based IT, by practitioners, and by ex-jurisdictional third parties. The counter-argument, however, is that this application will import lots of data from third party systems (and translating that to HTML is trivial), but the little it exports to third party applications can be relatively easily parsed from text and output in any required form.
So, any thoughts?
(FYI: I'm out of network reach until Monday - and will respond then to any comments received.)