Slashdot Mirror
Arguing For Open Electronic Health Records
mynameismonkey writes "openEHR guru Tim Cook, writing in a guest blog at A Scanner Brightly, discusses why Electronic Health Record developers should use open standards. Why are so few doctors using EHR systems? And, as more and more hospital EHR systems come online across the country, what do we have to fear from proprietary databases? It's one thing to find out your social security number was stolen. Now add your mental health and STD results to those records."
This is Slashdot. An STD would practically be a trophy here.
Frink: Nice try floyd, but you were designed for scrubbing, and scrubbing is what you shall do.
Primahealth: How are they secure with open standards? You can't have security without obscurity! THIS IS MADNESS!!!
Stallman: This is GNU/SPARTAAAAA!!!!
I think much of the problem has to do with legal problems on the storage of data and its dissemination (privacy laws, legal exposure etc) and that doctors have a general distrust of electronic record keeping without a paper backup. Also, arriving at an open standard on storage of health information is very very difficult as it's not a science and there are as many opinions as asses on seats at committee meetings. Everybody quotes easy stuff like pharmacy orders or pathology requests and results, but a health record can come in so many forms, (and if you look at a hospital record, there are so many types of forms in it) that it becomes difficult to come up with a database design that will cope with such diversity and still be usable. Information on a case can be a few scribbles to an exhaustive analysis.
That's not to say it won't happen, but it is taking a very long time and some expensive attempts at standardization (eg: NHS) have failed.
Do it yourself, because no one else will do it yourself. [beta blockade 10-17 Feb]
A better question is who owns your record?
An unsettling issue is that the doctor or hospital generally considers that THEY own your record. Think about that for a second...detailed records of you and your peccadilloes and someone else thinks they own and have the right to do what they want with your data.
In a world where that little vulnerability were straightened out open standards based ways of working with your personal data would come by default. You should be able to store and deploy your data, under your control, will any medical professional only being allowed to access and add to those records with your permissions. The only way to make that work is for hospital systems to use open standards, no more proprietary systems and no corporate data caches.
OpenEHRs are a sideshow next to that.
1. I don't get the article summary. Are my STD results somehow more vulnerable to theft if they are in a proprietary database format rather than an open one?
2. In my practice, we use an EHR (electronic health record) because I'm an employee of a big enough group that has the resources to purchase one of these expensive, bloated, not very well-maintained systems. (They're still working on making cut and paste work, and the group has to pay a bucket of money every month for ongoing support.) When I was a medical student in Ireland, I marveled how the GP I worked with in West Clare had a simple system he paid something like $300 which did everything he needed it to do, like track progress notes and lists, and keep track of drugs. That amount here covers about 30 seconds of use of our current software. Which is barely interoperable even with itself - if we see a patient from an affiliated private group using the same software, interoperability means they can email us a progress note, and then I can spend my afternoon hand-entering the medications and problems from their chart into my state of the art software's database to make sure grandpa doesn't crump over the holiday from a drug interaction with the cardiologist's new pills.
There isn't much incentive to make this software as easy to use as iTunes - the players seem to make plenty of money already with their proprietary storage formats and circa 1991 interface. There is no viable open source alternative (http://oemr.org/ doesn't look quite ready for prime time) - though I think there's an opportunity here for some enterprising Linux loving propellerheads.
At the bottom of the
The question that brought about the guest blog was; "why aren't primary care physicians adopting electronic health records?"
The answer is (primarily) because of misaligned incentives. Open specifications can help solve that problem. Especially ones that are implementable (some specifications are known to be developed in a committee room without being tested in software).
But the above post exposes a truth. Many proprietary companies are making money off of a few customers using the same old "upgrade tax" imposed by some operating system vendors. This is why applications based on truly open specifications can be marketed as being something different.
This is a very complex area with complex issues that vary around the world. However, the two level modeling approach used in the openEHR specs are being used in many places. Are we *brave enough* in the US to use something "not invented here"?
The UK has spent the last 5 years trying to build a common Health Record Database for all NHS patients. Those of you that are aware, the HNS is a public run service that covers the health needs of the entire population, although Private medical Insurance is available if required at extra cost. So far this "Database" has cost the UK Taxpayer £12 billion ($24 US Dollars) and has delivered nothing but chaos, confusion and a lack of investment in frontline databases that are currently in use, meaning that records go missing, data discs with confidential data get lost etc... http://news.bbc.co.uk/1/hi/uk/7158498.stm
The fundamental problem is that politicians think that databases are the answer to everything, being handy for issuing speeding fines, holding criminal records and identity details of everybody in the country, but they haven't quite got round to the concept that the accuracy the data within a database is the most important aspect and it is often the data processing factor that often falls down. They forget the basic fundamental questions like:-
How long does the data take to propagate into the system properly? If I tax my car late on Friday will the computer database not be updated until Monday, meaning that I'm going to be constantly pulled over by the Police and threatened with my transport being impounded for the weekend, even though it is perfectly legal?
What happens if the data is incorrect? Our beloved UK government wants an all encompassing ID card system, which will reference a number of different databases. How can they be absolutely sure that the data is at least 6 sigma (3.4 defects per million records) if not 100% correct (note that the old saying 99.9% doesn't even being to recognise the real accuracy required).
If the data is incorrect who is responsible? If there are many bodies involved, you can guarantee that none of them will agree who is at fault until lawyers get involved, especially if they are civil servants and/or politicians.
Who ensures that the data is secure? We in the UK had ZIP encrypted discs containing details of 25 million people (about 2/5 of the UK population) lost by the HRMC recently. http://news.bbc.co.uk/1/hi/uk_politics/7117291.stm
One the face of it using an open system for designing a database is a good idea in principle, but it is the people that are responsible for these databases that need to know exactly why they are important and why reliance on such databases is a recipe for disaster if proper considerations are not made. Part of the problem is that many of the people choosing these databases probably don't have a first clue in how a database works, that is the problem we face.
I did notice that this week the new Australian Prime Minister Kevin Rudd cancelled a National ID card system that was planed by the Howard Administration. This move appears to come from somebody that appears to understand the complex nature of such a system, its cost and its lack of benefit. There are many ways that can be used to determine somebodies identify (bank cards, passport, birth certificate) and having all of them referenced at the same place isn't the most cost effective solution.
In the UK, the government has invested vast sums of money into a system called "Choose and Book." It's billed on the slim selling point of offering patients greater choice in hospital care but the most cursory look at the technology involved shows that the biggest effect is that of centralising patient's records.
Aside from the fact that patients can be offered a choice in secondary care already (by their doctor referring them to somewhere else), the system is buggy and flawed. The doctors don't want it, there have been national campaigns by the public against it, but the government is doing every single thing they can to force it on people up to and including financially penalising doctor's practices for not using it. The motivations are (a) presumed financial interests in the big companies that are providing the system and (b) a burning desire to get hold of everyone's personal medical data for government and police purposes.
It's not even legal as the responsibility for patient confidentiality belongs to the patient's own GP and if there's a misuse, they will be the ones legally to blame for sharing the data. There's some information on it here
If there's a need for easily transportable medical records, then this can be resolved by putting the data in the patient's hands. Public-Private key technology, or even hashes of the data, could be used to ensure accuracy. The solution is not that complicated, but in the UK we're having a very hard fight getting it.
Aide-toi, le Ciel t'aidera - Jeanne D'Arc.
It's impossible to store in a structured manner health information because it's so complex and individualized. Think about how to store the following.
1) "My arm hurts right here!" "Show me?" "Here!" "Wait, it's here now" "No no, it's here now"
2) "It itches sometimes" "when?, where?, duration? during aligment of planets!?"
3) "You need to take xyz, twice a day for two weeks. Come back in 3 month, and let's do another check up."
If anyone wants to know how complex it is, try reading the DICOM standard which is just for medical *image* storage and exchange. It's about 3500 pages. The code for medical billing, which the article mentions, is already the size of a dictionary. And all it contains is entries for a simple code and a one or two sentence description.
Realistically, the best approach may be PDF's and full text search. Anything else is just not going to capture the full extent of the medical history.
You probably know that big IT projects often fail. But for some reason patient record projects tend to fail more than other projects. Administrative systems for setting appointments work. Automation for lab tests works. But projects for actual patient records keep failing.
I have a friend in the healthcare IT business who claims that they are actively sabotaged. Many more are derailed before they ever get started. Doctors prefer paper records that cannot be efficiently mined for malpractice lawsuits. Paper records that can be conveniently lost.
Stop worrying about the risks of nuclear power and start worrying about the risks of not using nuclear power.
Google "HIPAA" and/or X12 EDI
It's a data exchange format that *all* health care insurers and providers must accept or provide when exchanging patient data. It's trivial to add to the spec rules for additional subloops containing text. There are codes and modifiers enough to cover damned near any medical situation.
Many small doctors avoided electronic data altogether by doing as they'd done for years, namely keep paper records. That is until insurance companies began deprecating paper... by not accepting paper claims at all, charging a premium for processing paper forms, or cutting staff levels in their data entry pool which has the effect of seriously delaying payment to the physician.
I'm a doctor who joined a small practice a few years ago. The senior partner of the practice created his own EMR system. It's actually quite good and we use it exclusively. Our office isn't paperless, but everything coming into the office is scanned in or phoned into the virtual fax and never printed. We are able to access it from different offices and from the hospitals we go to via a VPN setup, and it significantly improves our efficiency.
Now the senior partner left. He didn't use a standard database format (but fortunately used Microsoft SQL), and we'll probably have to pay a fortune to have it converted to an open format. Fortunately he's being good about not charging the office for a license for his code, so we have time for the transfer.
Help! I'm a slashdot refugee.
The oldest medical database systems are based on MUMPS, now called M by some, which is still used by the VA. They have
updated it to "VistA", which predated Microsoft Vista (wonder if Microsoft chose that name for a medical reason?).
VistA® / CPRS Demo Site:
http://www1.va.gov/CPRSdemo/
The code:
http://www1.va.gov/CPRSdemo/page.cfm?pg=1
http://www.innovations.va.gov/innovations/docs/InnovationsVistAFAQPublic.pdf
http://www.va.gov/VISTA_MONOGRAPH/index.asp
http://www.va.gov/vdl/ is the library.
http://www.va.gov/vdl/section.asp?secid=3 covers your Financial question.
http://www.va.gov/vdl/application.asp?appid=144
VistA Data Extraction Framework (VDEF).
http://openvista.sourceforge.net/
"OpenVista is the open-source version of VistA, which is an enterprise grade health care information system developed by the
U.S. Department of Veterans Affairs (VA) and deployed at nearly 1,500 facilities worldwide."
1,500 is not all that many considering the market.
Intersystem's Cache' http://www.intersystems.com/cache/ is the contemporary equivlent to MUMPS, a database that claims it can
run rings around things like MySQL in the number of transactions per second.
There are a number of Open Source Medical Databases,they are summarized here:
http://www.linux.com/base/ldp/howto/Medicine-HOWTO/record.html
My very first job was writing medical software, this is when few people even knew what computers were in 1977. Still have my DEC
MUMPS badge that I got at the very first MUMPS conference in DC. Have always felt I should get back into that field. To bad
Dr. Armor and I didn't patent what we were doing then. The pharmacists called up the office in disbelieve asking if these
computer printed prescriptions were real, because *THEY COULD READ THEM*.
The other side:
"VA DATA AND INFORMATION SYSTEMS:
1. FY07 Year-End Med SAS and DSS CNDE Files Available
The fiscal year 2007 (FY07) year-end Medical SAS (Med SAS)
Inpatient and Outpatient files are now available."
http://www.virec.research.va.gov/References/DataIssuesBrief/2007/DIB-0712er.pdf
Requesting Access to VA Data:
http://www.virec.research.va.gov/Support/Training-NewUsersToolkit/ACRSrequest.htm
"Click this button for information, guidance, and FAQs relating to the VA Research Data Security and Privacy initiative."
http://www.research.va.gov/resources/data-security
You need to go down into the records storage area and just look at the physical mess there. Some of the forms are flimsies and are going to disintegrate long before the AMA/ADA HIPPA/OSHA specified 30 years are up and those radiographs are most likely to fixer stain into unreadability as well. Most offices pull inactive records and shove them into a "bankers box" which are then shoved into a storage area that isn't climate controlled and keep the boxes in chronological order by date pulled and the internal chart in alphabetical order usually in a rental storeage unit so vermin can nest in the nice warm paper! Now imagine the FBI calling and saying one of your patients from ten years ago got fed to the alligator, please send dental records for ID; you can spend $2,000.00 in wages doing a futile search! Sooner or later we're going to have to do it, paper and film is just to expensive to store for that long.
Apocalypse Cancelled, Sorry, No Ticket Refunds
EMRs are a great idea, but the medical world is poorly adapted to build them and integrate them. Its dysfunctional system where billing is becoming increasingly critical, while what you get for is divorced from what you actually do. So we wind up with schizophrenic EMRs that can't decide whether they are generating billing tickets, documenting patient care or preventing a lawsuit.
1) They are expensive for a small practice - think that a primary care docs office is rolling in cash? Think again. Most of them are barely scraping by, which is why your doc needs to see 30+ patients a day. Otherwise the rent doesn't get paid and he/she can't make payroll. If a new tool doesn't make the office more efficient, it can't be justified. Sound odd? Next time you visit your doc, ask him who determines how much he/she gets paid. Its not you, its not the market and its not actually the insurance companies. Its the federal government when they set payment guidelines for Medicare/Medicaid which the insurers follow. Free market my ass.
2) They are slower than paper - few docs can type as fast as they can dictate or write. Most of us can take notes on a piece of paper while interviewing a patient - no one I know can talk to a patient and type into a form.
3) Many are designed to maximize billing, not care - we get paid based on how many indicators of complex care we hit. How many "systems" asked about, how many organs examined etc etc - not by our time or skill. So in order to bill we have to document all of these. Some EMRs are designed to force the MDs to check many boxes for billing and audit purposes. Unpleasant and slow.
4) Many are slow and perform poorly - my hospital switched recently from a physician designed an written EMR from the 80s that was text/terminal based and blindingly fast, to a web-based system. The new system is slow, and doesn't really do much that the old system did. The difference was that the first system was built by MDs who ate their own dog-food, the second by teams of very smart, very committed programmers who don't practice medicine.
5) They are the camel's nose under the tent - my hospital based practice was recently instructed to begin doing "medication reconciliation" on all outpatients. That means at the start of the visit I have to type in all of a patient's medications into the EMR. Sounds fine for you, right? Now imagine your grandmother. As a sub-specialty consultant I see most of my patients once to twice a year and they are on 20+ medications, over the counters, vitamins and herbal supplements. It can take 6-7 minutes out of an already short 30 minute visit. Sure its great for safety, but it means we are running an additional 45 minutes late at the end of the day. Not so great for you if you have a late afternoon appointment.
+--------------------- You idiot! I told you we were facing the wrong way!
Every week I have some patients who have come in from far away to see me with some X-rays, MRI, CT scans. Often they are on a CD with some strange proprietary program used to display the images. Often I cant open them up and look at them, and the person has made a several hour trip almost for nothing.
In that way old fashioned plain images are better.
Having open source images/records would also eliminate that problem too, as I could display the images, and not have to find/buy/ download some strange/clunky program.
Most radiologists and newer surgeons really like electronic imaging, but it can backfire on you as well.
..........FULL STOP.
At least in the US, HIPAA says the contents of your medical record are yours, and the healthcare provider is a custodian of that data. That said, there are some caveats.
* Not all data in an EHR system relating to you is actually part of your medical record. There may be - probably is - some internal clinical communication attached to your chart in the course of clinical operations. Basically an EHR system usually tracks both your record and the providers' own record about you. These different classes of data are pretty straightforward to distinguish most of the time; you own the former and you don't own the latter.
* Providing you with a copy of your record has some cost, and custodians of records are allowed to recover reasonable costs from you to cover those expenses.
* Some data about your records may be disclosed as necessary for Treatment, Payment, or healthcare Operations; these disclosures are limited to the minimum necessary and (generally speaking) are also limited to other entities coveredby HIPAA.
* The government can get what it wants, when it wants, and you and your records custodians have f--k all to say about it.
Within those broad costraints, though... it's yours and your provider should treat it as such.
With reasonable men I will reason; with humane men I will plead; but to tyrants I will give no quarter. -- William Lloyd
There are two standards called DICOM and HL7. DICOM handles binary data, and HL7 handles more of the process and is the primary integration point with EMR.
With these a PACS (Picture Archive Communication System) forms the "database" of data. The PACS is actually more work-flow based which then stores the actual data on some type of highly-reliable data storage system.
These two protocols make up the totality of your health care experience at a hospital. Your hospital certainly uses these two protocols, so why invent a new one?
The problem isn't impossibility but infancy. There are good systems around but making them work across the board has been the problem. For example, in my neck of the woods the big problem is ignorant and territorial IT departments in both the public and private health systems which do not want to do any work but see their job as shopping around for people to outsource their work to. And because they get taken to expensive dinners by big companies with crappy solutions, they create 'guidelines' which exclude everybody but the companies that pay for their dinners.
And because everybody hates the IT departments, nobody cooperates with IT and all their projects, aside from fixing broken mice and installing windows XP updates, fail.
Do it yourself, because no one else will do it yourself. [beta blockade 10-17 Feb]