Slashdot is powered by your submissions, so send in your scoop

 



Forgot your password?
typodupeerror
×
Privacy Government Medicine Politics

EHR Privacy Debate Heats Up 182

CurtMonash writes "The New York Times reports on President-Elect Obama's continued commitment to electronic health records (EHRs), which on the whole are a great idea. The article cites a number of legislative initiatives to deal with the privacy risks of EHRs. That's where things start to go astray. The proposals seem to focus on simply controlling the flow of information, but from a defense-in-depth standpoint, that's not enough. Medical care is full of information waivers, much like EULAs, only with your health at stake. What's more, any information control regime has to have exceptions for medical emergencies — but where legitimate emergencies are routine, socially-engineered fake emergencies can blast security to smithereens. So medical information privacy will never be adequate unless there are strong usage-control rules as well, in areas such as discrimination, marketing, or tabloid-press publication. I've provided some ideas as to how and why that could work well."
This discussion has been archived. No new comments can be posted.

EHR Privacy Debate Heats Up

Comments Filter:
  • by Anonymous Coward on Monday January 19, 2009 @09:31AM (#26515009)

    I saw this [case.edu] the other day. Basically, a pair of professors, one in law and another in computer science (specializing in software testing) are trying to bring the problems with EHR to a wider audience.

    They call for testing and certification of EHR systems (Though thankfully not through the FDA).

    It'll be interesting whether anyone listens to them.

  • Unlikely (Score:5, Informative)

    by professorguy ( 1108737 ) on Monday January 19, 2009 @10:38AM (#26515433)
    OK, I run a hospital network, so I see medical data whizzing around more than most people. Here's a typical example:

    .

    A doctor dictates his diagnosis into a microphone on a PC. It becomes a data file. It sits in his output queue. It is then sent to a server to be electronically signed (a Word Macro is run). It sits on it's input queue until done then sits in its output queue. Then it gets sent to an HL7 routing engine where it sits on queues. Then on to our medical database. This generates some billing info which goes to the HL7 router then on to a private company in Tennessee, which sends results to a website....

    Now I'm sure there will be controls on who can get at the medical database. But what about the data whizzing around the network? Tell me about the audit trail that lets me know who saw some of the info generated by that one encounter. Because it sat on at least 7 machines in 3 states for some amount of time.

    And now you want each of those machines to check to see if the patient has signed off on that machine getting the info? Good luck with that.

    And if someone shows up unresponsive in the ER, how do we send the X-ray to the remote radiologist if the patient can't release the data? And if 'emergencies' override that control, expect to see EVERY encounter be an emergency.

  • Great idea? (Score:2, Informative)

    by Mr. Slippery ( 47854 ) <.tms. .at. .infamous.net.> on Monday January 19, 2009 @11:17AM (#26515955) Homepage

    Funny this should come up, considering what I just read last night in the RISKS Digest [ncl.ac.uk]:

    Software glitch causes incorrect medication dosages
    Jeremy Epstein jeremy.j.epstein@gmail.nospamnospamnospam.com
    Fri, 16 Jan 2009 11:51:46 -0500

    ``Patients at VA health centers were given incorrect doses of drugs, had needed treatments delayed and may have been exposed to other medical errors due to the glitches that showed faulty displays of their electronic health records, according to internal documents obtained by The Associated Press under the Freedom of Information Act. The VA's recent glitches involved medical data -- vital signs, lab results, active meds -- that sometimes popped up under another patient's name on the computer screen. Records also failed to clearly display a doctor's stop order for a treatment, leading to reported cases of unnecessary doses of intravenous drugs such as blood-thinning heparin. According to interviews and the VA's internal memos, the glitches began after the VA distributed its annual software upgrade last August [2008].''

    The proposition that EHR are a good idea remains as unproven as the idea that touchscreen voting machines with no paper trail are a good idea. Sometimes electronic documents and records introduce brave new failure methods that outweigh any benefit.

  • Re:Dangers of EHR (Score:2, Informative)

    by KeithConover ( 845226 ) on Monday January 19, 2009 @03:06PM (#26518733) Homepage

    First off it's a good idea to define terms, as the risks for the various flavors of medical record differ. And, given that for the USA, at least, we now have some terms that are official, here's a summary from the document I recently put together for a medical IT conference, referenced at the end of this post.

    EMR vs. EHR vs. PHR?

    Many people use the terms electronic medical record (EMR), electronic health record (EHR) and personal health record (PHR) interchangeably. But arguably they mean very different things.

    There are also a great variety of other terms used to describe electronic records, but EMR and EHR and PHR are now more-or-less accepted as the three real terms. In fact, the US ONCHIT commissioned the NAHIT to develop definitions and so, at least in the USA, these are official.

    An EMR is just that - an electronic record of an episode of medical care, whether inpatient or outpatient or ED. The EHR is both more and less than the EMR - it is those parts of the EMR that are appropriately shared with stakeholders outside the hospital, doctor's office or other EMR source. Parts of the EMR are shared, as the EHR insurance companies, government agencies, patients themselves, and employers. An article in Medical Economics, quoting an Institute of Medicine report, defines the elements of an EHR thusly:

    Health information and data. The system holds what's normally in a paper chart - problem lists, medication lists, test results.

    Results management. An EHR lets you receive lab results, radiology reports, and even X-ray images electronically.

    Order entry. No more prescription pads. All your orders are automated.

    Decision support. An EHR is smart enough to warn you about drug interactions, help you make a diagnosis, and point you to evidence-based guidelines when you ponder treatment options.

    Electronic communications and connectivity. You can talk in cyberspace with patients, your medical assistant, referring doctors, hospitals, and insurers - securely. And your system interfaces with everyone else's. Interoperability is the key word.

    Patient support. Patients can receive educational material via the EHR and enter data themselves through online questionnaires and home monitoring devices.

    Administrative processes. The system lends a hand with practice management. Patients can schedule their own appointments and staffers can check on insurance eligibility.

    Reporting and population health management. How many patients did you treat for tuberculosis in 2003? How many of your diabetics have their HbA1c under 7? An EHR will spit out the answers, thanks to a searchable database.

    A Personal Health Record is just that: personal. It is those parts of the EMR/EHR that an individual person "owns" and controls. Google and Microsoft want to help you with this. (Really.)

    If these definitions seem a bit vague, well, yes, they are, because we're just getting started with this stuff, you know?

    A more complete tutorial on Healthcare IT, with a diagram that might make the above actually make sense, as well as links, may be found in a PDF named

    Healthcare IT in a Nutshell.pdf

    at:

    http://ed-informatics.org/healthcareit/ [ed-informatics.org] [ed-informatics.org]

    (BTW, as a practicing ER doc, when I need EHR info, I need it NOW, often 10 minutes later is useless.)

  • Re:Dangers of EHR (Score:3, Informative)

    by db32 ( 862117 ) on Monday January 19, 2009 @03:27PM (#26518963) Journal
    Well, actually there ARE standardized ways for those databases to share information and it is a huge money maker for most of the various healthcare related vendors. HL7 is a standard that medical systems use to communicate patient data back and forth. When you get checked in and they say you need a MRI, the EMR sends a message to the MRI machine that fills out all of the information about you the MRI machine will need to build the study. Then the MRI tech selects your name (rather than handjaming all of it in based on paper records that may or may not get there in a timely fashion) and proceeds to scan away. The images get sent on to the imaging storage thing and the machine sends messages back to the EMR "ok done". Then the EMR shows the Doctors that will be reading the images say "Hey, Patient X has their images done", they go in and dictate what they see. Then it tells the transcriptionists "Hey, Doctor X finished dictating" so they go listen and type up the report into the EMR. Then it send BACK to the Doctor "Hey, transcriptionists are done, read it and verify then electronically sign that it is correct". THEN! It send a message to the ordering doctor "Hey, your tests are complete". Now In most cases at a minimum the EMR had to communicate with a MRI machine, a Dictation system, and more than likely a PACS (image storage) system all made by different vendors to achieve all of this.

    Now...as far as it being "Easy" or "Standard", yeah it gets a little fuzzy. Vendors tend to "Well we support HL7 v3, but not v2, and we need field 57 to have a value of X" and other strangeness, but ultimately, the pieces required are indeed there to make it all happen and vendors are more than happy to charge a kings ransom for these "interfaces" as they call them.

    I think hospitals have a long way to go to improve IT security, however, on the behavior end I think they are leaps and bounds ahead of the credit industry. I doubt that it is entirely altruistic and "don't be evil", but the penalties for screwing up with medical information are MUCH higher than screwing up with credit info. I can tell you from (rather frightening experience) that most of the US docs I have dealt with have NO love for the money grubbing insurance companies.
  • by EdIII ( 1114411 ) * on Tuesday January 20, 2009 @04:59AM (#26526373)

    The idea of a separate network is a great idea actually. The best I have heard so far. However, it does not need to be air-gapped.

    This can be created with funding and some strict certification programs for manufacturers and service providers. I see no reason that access to these networks cannot be accomplished through VPN circuits offered by local ISPs. The idea being to make it suitably difficult for someone outside the network to hack it. Not so ludicrously difficult it requires Tom Cruise and Ving Rhames to get around the security.

    VPN already offers this. Compromising a properly setup enterprise VPN is no trivial task. If all access goes over these VPN's then that is a fairly high level of security. Air-Gapped is just over board in my opinion here.

    Most theft and unauthorized disclosure of medical records is an inside job anyways. I have never heard of an organized attack to steal medical records as they are pretty hard to sell since the penalties for using them are fairly high. Just who are they going to sell to anyways? Marketers? Great. A marketing campaign that puts everybody in prison.

    A protected nation wide network that results in a paperless environment is a good thing. It does make it more efficient. However, you need to separate this into two distinct areas:

    1) The rules and regulations regarding the infrastructure itself. How it is created, what levels of encryption, authorized providers, etc.

    2) The rules and regulations regarding the information residing on that network. When can data be accessed by terminals. Access records and employ authentications required for every single viewing and modification of the records. Data segregation so that certain parts of a medical record need to be accessed by only certain types of users. Abortion records, VDs', AIDS, HIV, etc. can all have a higher privilege level so that only a doctor can view it.

    I think the real problem with an idea like this is that is a complete overhaul of EVERYTHING. No more paper records, filing cabinets, etc. No more standard PC's operating the interfaces. Every hospital and doctor's office from the smallest to the largest will have to change by federal law.

    That is a huge project. Creating the information system itself is one thing. Populating it with medical records is entirely different. There will be billions spent just on hiring the companies that will convert paper records to electronic ones and they will have to treat it like its asbestos. You can't expect a private practice to undertake this themselves. They will have enough on their hands just adjusting to the new terminals and how you operate them. Doctors will have to take around tablets to enter data.

    Now we face the real problem. Where most of the disclosures occur. It's the end users in the offices themselves and that environment that leads to most of the incidents in the first place. Creating the infrastructure is trivial compared to actually changing that environment on the ground in hospitals and private practices. Population of the data and changing the environment are vastly more difficult steps than creating the infrastructure, but it will have some interesting requirements in order to work.

    Data backups, fail over, and load balancing. There will HAVE to be nodes distributed across the entire US. The whole network itself will have to be redundant. Not impossible. Yahoo, Google, MS, Facebook, they all do it now. However, nobody died because they could not get Google to come up on a browser. In events like Katrina, there will have to be redundant pathways to access a regional node.

    The scope of this project is starting to sound like going to the Moon.

Real Programmers don't eat quiche. They eat Twinkies and Szechwan food.

Working...