Slashdot Mirror
Back To Faxes: Doctors Can't Exchange Digital Medical Records
nbauman writes: Doctors with one medical records system can't exchange information with systems made by other vendors, including those at their own hospitals, according to the New York Times. One ophthalmologist spent half a million dollars on a system, but still needs to send faxes to get the information where it needs to go. The largest vendor is Epic Systems, Madison, WI, which holds almost half the medical records in the U.S. A report from RAND described Epic as a "closed" platform that made it "challenging and costly" for hospitals to interconnect.
The situation is bad for patients and costly for medical works: if doctors can't exchange records, they'll face a 1% Medicare penalty, and UC Davis alone has a staff of 22 dedicated to communication. On top of that, Epic charges a fee to send data to some non-Epic systems. Congress has held hearings on the matter, and Epic has hired a lobbyist. Epic's founder, billionaire computer science major Judith Faulkner, said that Epic was one of the first to establish code and standards for secure interchange, which included user authentication provisions and a legally binding contract. She said the federal government, which gave $24 billion in incentive payments to doctors for computerization, should have done that. The Office of the National Coordinator for Health Information Technology said that it was a "top priority" and just recently wrote a 10-year vision statement and agenda for it.
The situation is bad for patients and costly for medical works: if doctors can't exchange records, they'll face a 1% Medicare penalty, and UC Davis alone has a staff of 22 dedicated to communication. On top of that, Epic charges a fee to send data to some non-Epic systems. Congress has held hearings on the matter, and Epic has hired a lobbyist. Epic's founder, billionaire computer science major Judith Faulkner, said that Epic was one of the first to establish code and standards for secure interchange, which included user authentication provisions and a legally binding contract. She said the federal government, which gave $24 billion in incentive payments to doctors for computerization, should have done that. The Office of the National Coordinator for Health Information Technology said that it was a "top priority" and just recently wrote a 10-year vision statement and agenda for it.
Google care or appleMed
Some drink at the fountain of knowledge. Others just gargle.
Working with EMR systems for small clinics has shown me that unless fines are given out to these companies developing this software they will make it as difficult and expensive to exchange records with different systems as possible. It is far more profitable for them to make it hard to exchange and then make their clients convince other offices to use the same software if they want to make it easy.
I thought this was the point of HL7?
When I worked for a major medical practice software company we spent a lot of time insuring HL7 support for hospitals...
We take the penalties. It's not worth dealing with all of the requirements the Feds throw at the small practice to try and comply.
The owner / primary provider has attempted to cut back on the number of federally insured patients in order to avoid dealing with all the crap they attach to their payments. Private insurance is easier to deal with.
As far as I'm concerned, the Federal government hasn't been able to effectively manage a large project since about the Second World War. I'm not entirely certain why anyone thinks they can manage health care, looking at all Federal projects past about the time of the Interstate Highway System.
Health Level Seven (HL7) and especially the Clinical Document Architecture (CDA) are insanely complex.
Invoke eminent domain to seize the right to share the data, for the common good of citizens health and safety
Note that the feds gave docs/hospitals $24 billion to digitalize, of which over half of went either directly to EPIC or to epic contractors.
And this is the source of success of EPIC. Their software is pretty much crap. They hire fleets of college grads, work them for 60+ hour work weeks, burn them out in under 2 years, and replace them with the next lot of inexperienced automatons. The genius isn't in the code, it's in cornering the market of a federally subsidized effort.
"Most people in the U.S. wouldn't know they live in a tyrannical state if it walked up and grabbed their junk." - MyFirs
I live in Madison, Right next to Epic actually. Pretty much all medical facilities in the area use them of course.
The problem is, every time I go into the doctor they tell me about how they can now pull in all my medical history from every other system. It's so great! Yay! The doctors are sooo giddy and I roll my eyes because I know what's coming...
So according to this you have Herpes... no? Strange...
And multiphasic drug abuse? No?
Open heart surgery? Really? No?
and on an on it goes.
EVERY time I go in, all that stuff shows up under my name. No, I do not have a common name like John smith. My real name is very unique. Yet, records that have nothing to do with me get pulled in every time. But the only data transferred is the diagnoses. There is no info on where the data came from, when it happened... nothing. I'm pretty sure I'd remember heart surgery or herpes.
People lie about their names at hospitals all the time to avoid billing, law enforcement, etc... I suspect that's what happened to me. I had a rather unsavory roommate in college. But since the system lacks all detail of the event, I cannot even get it removed. This needs to die... and die theroughly. I should get to chose which records are kept about my health.
Surely this is the sort of thing that could be solved once and for all by paying a few hackers to write some open source software? Hell, I bet you could raise all the money you needed from a Kickstarter project: this is the sort of problem that I know other countries apart from the USA face. The UK's NHS has had terrible IT problems for at least a decade. Solve it once, solve it internationally, and force the competition to (open) up their game or go out of business.
The one thing the Feds can and should do and they are asleep at the switch.
When Fascism comes to America, it will call itself Anti-Fascism, and tell you to give up your guns.
When Bruce Perens was getting questions from slashdot, I asked whether Obamacare should have mandated the use of open source software.
He replied with some BS answer about how great Obamacare is because his children with preexisting conditions can now become independent contractors.
I admit that modifying the system so that healthcare is not tied to your job is a good thing, but it shows how pathetic and how much greed has pervaded politics.
He should have instead focused on what the question was about: requiring open protocols, and open software as a part of Obamacare would go a great way to alleviating cost problems in certain sectors.
Make no mistake that I think that companies should not make money developing medical software, but they should not be making artificially large amounts of money by erecting proprietary walls.
A lot of these vendors are locked into their own technologies.
I had interviewed at Epic once (didn't feel like moving to Wisconsin... sorry) and realized that they used M for most of what they did... not much interconnectivity there.
Quo usque tandem abutere, Nimbus, patientia nostra?
I worked on a project that wanted to take in a bunch of data from a hospital's EMR and essentially do some analysis on it. The project was canceled before we ever managed to get data out of an EMR because it turns out to be nearly impossible.
"But aren't there EMR data export standards?"
Why, yes, yes they are! Multiple ones, in fact!
Unfortunately, the formats are complex enough that basically every single EMR has the ability to format a perfectly standards-compliant document representing the exact same data in an entirely different way.
And that's ignoring that, as I recall, we discovered that ultimately the data we were looking for were entered into the hospital's EMR as PDFs. The EMR could locate the PDFs, but it didn't "know" the data they contained.
So I'm not at all surprised to learn that doctors are resorting to faxing records. It's almost certainly easier than trying to exchange them digitally.
You are in a maze of twisty little relative jumps, all alike.
HL7 lacks a lot of features and the upgrade model is expensive. The larger problem is the smaller disparate medical offices that can't stay compliant or afford to invest in a comprehensive IT infrastructure. Microsoft tried to come out with an XML based standard but couldn't get enough widespread support. There is also still a major problem with the taxonomy between specialists and generalist, hand written documents (so we need better improvements in Natural Language Processing). A top down approach has been tried time and time again. Its time to explore a distributed solution where the patients take ownership of the data.
There is a standard in place (HIPAA EDI). That they aren't using it seems to be on EPIC.
"A person is smart. People are dumb, panicky dangerous animals and you know it." - K
they used M for most of what they did...
No wonder this is screwed up. What does M, head of the British intelligence agency, got to do with American health records?
Ooo, thanks for that! I long ago realized that the only actual value SAS provides is forcing companies to get a bunch of people together to agree on a common data schema, because the rest of their software is dirt simple, and even much of that is of shitty quality. But I didn't recognize the analogy to Stone Soup, and that's perfect!
John
that is exactly what those of us who have to use EPIC refer to it as, an EPIC failure!
The interface was obviously written by people who have not worked in a medical office, and all the staff complain about it, but we're stuck. It would be too expensive to get another one and retrain everybody to use a new system and transfer information etc...
The Feds made a big mistake by not specifying and requiring interoperability as the very first item.
Now that they have paid for people to install all of these different systems, it's very difficult (expensive, time consuming, kludgy) to bolt on interoperability to the installed base.
Big mistake.
I don't read your sig. Why are you reading mine?
>If anything, this is nothing more than an industry standards issue.
Get IEEE 802 to do it.
You'd be able to pass your medical records through an 802.1D compliant bridge transparently, with or without Q.
I should use this sig to advertise my book ISBN-13 : 978-1501515132.
I've worked on-and-off in healthcare and the standards for transmitting *anything* are ancient and bad. Formats like HL7 and ASTM are ancient delimited-text formats with no UTF-8 support, no encryption, and even have RS232 ACK/NAK packets in the standard.
Sounds un-American.
(Full disclosure: I am not American.)
Linux is for people who don't mind RTFM.
is this news? No. Surprising? No. How come it was so easy for them to set up? That's the interesting question. Who outside the company itself profited from the health industry's failure to create a single mandated standard? Poliician somewhere blocking the iniatives? What a surprise.
"Cock Up Your Beaver" does not mean what you think. This sig is intended to clog filters and annoy do-gooders
I did a PC refresh project for a local hospital a few years ago, replacing old WinXP systems with new Win7 systems. The pharmacy department for the poor clinic were running a DOS-based application for managing prescriptions. The last tech who installed this application was long gone for six years. There was no documentation. The developer no longer supported the application. The hospital didn't want to buy a new application with an incompatible data format. And the old computers were ready to die. Somehow I managed to get the application working on Win7.
Surely nations that have universal healthcare have this stuff worked out!
(No, seriously.)
.
Prisencolinensinainciusol. Ol Rait!
Because if the government had not mandated EMR, the various EMR systems would have had to convince health care providers that what they were offering made their jobs easier or improved the care they gave their patients in order to get adopted. As problems like this cropped up, those health care providers would have pressured the vendors they dealt with to resolve it. There would have been one of two outcomes: everybody would have ended up using the same company, or everyone would have ended up using those companies who made it easiest to build a system that could talk to other EMR setups. If the Feds did their job enforcing Anti-trust laws, it would have been the latter.
The truth is that all men having power ought to be mistrusted. James Madison
http://xkcd.com/927/
Dunno there's anything more to be said.
I've done some consulting in the realm of medical software and while I don't know every major in-and-out, the real problem is the market.
Here's an example of bringing a piece of software to the medical market:
- Come up with the idea for some software, write, debug, document it. **This is not the problem**
- Find a hospital or clinic, meet with the board (3+ months wait) to see if you can petition it's doctors/nurses/whomever to use your software.
- Find a group of medical staff that is willing to use said software, free of charge, on the side. You probably have to 'pay' them to do it somehow - give it away for free, or discount, when you actually start selling the software, or just a lot of business lunches. These people cannot legally use your software for actual medical purposes. They're just doubling their workload by using your system next to whatever the current mechanism they use.
- 6+ months go by. Now it's time to approach the board of directors of the hospital - make a presentation with the recommendations of the software users
- Now, hire an independent software analyst to review your software, while working with a lawyer - who themselves will work with one or more of the hospital's lawyers - to ensure that you're following all the legal requirements and hopsital software requirements. 1-6 months before you're certified for that hospital.
- Unfortunately, there may be other requirements that supersede the hospital's individual requirements, usually municipal, state, federal regs. You'll need to get certified on these (0-3 years duration).
- Finally get it rolled out to the hospitals and sold in the wild (note: repeat the certification steps for each new hospital/hospital group, but they'll be expedited)
Okay, so that's the general process. One part software development, 82 parts legal wrangling, red tape, and butt kissing.
You're also not going to make this thing very open. You won't use public libraries, because they need to be certified. You won't have common data, because every hospital wants different things. You're not going to use new technology or standards because it takes years to get it live, and when you make changes like that you have to start over.
You're also not being paid to add the features to make this externally accessible to god knows what.
Imagine the extra requirements involved in providing legal access to medical records to third parties. It's not a technological barrier; it's almost all legal. They must be certified, the two must have a contract, etc, etc. You can't just give it to anyone who asks - you have to have a legal relationship with each asker. That will have to be signed off on by the board too. And so on, and so on.
The project I did some consulting on? They're basically a sort of spreadsheet with calculations. It's been ~4 years, and it's still bouncing around, not yet fully certified and ready to open for sale. If they went back and added 3'd party export functionality, it'd be another 4.
The ophthalmologist that spent half a million on a system is a complete moron.
billionaire computer science major Judith Faulkner
What? Who says things like that? Is there even any semantic meaning in context of the issue? </aside>
My understanding, especially from friends still-on-the-inside (of clinical information systems), is that EPIC's main product is a SEP field.
I used to work on what was once hailed as a model clinical information system, but it was killed by beancounter CIO-types, angling for bonuses on unspent budgets, and eventually they were replaced by the clinicians who just wanted something where they felt they could get features and reliability (internal requests for such were almost always turned down by management because of perverse incentives).
Not being qualified to make technical decisions, [as I understand it] the clinicians went for big & popular, as it was felt that at least that stood a good chance of being decent. But more importantly, the internal bureaucrats were always angling for budgets and lawyers while the outside vendor is able to offer relief from all of that for merely a mountain of money. Clinical functionality is somewhere down the list in terms of required features.
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
What on earth could you possibly have against M??? A Case of the MUMPS
Faxes are secure? Not likely. It would be easy to tap into the phone line of a hospital or a lawyer, run the receive pair to a fax machine, and print off a copy of every fax that comes through. See here for a more detailed overview.
09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0
Forgot the link, awesome. http://www.connotech.com/FAXBI...
09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0
I am pretty sure FAX is still digital. Regardless of if it automatically prints the digital record or not, is likely not in the law.
Troll is not a replacement for I disagree.
This is pretty standard in most established industries.
In banking, for example, one of the most popular formats for representing ACH transactions is defined in 2 pages. It takes a 2 volume set of books to explain what each field means, in relationship to the rest, and there's STILL room for interpretation.
I mean, they're usually not PDF format bad, but it's pretty awful. Worse, since these sorts of protocols are used by a relatively small subset of development houses who are not paid to make their software interchangeable - so there's no business reason to spend the money (via time and effort) to collaborate like that. Obviously there's also no open source or free libraries, it's all proprietary.
My experience in studying Medical Informatics is that they had no idea on how to create an ecosystem. Firstly, they were wrongly insistent on the need for everything to be coded. Take a look at things like SNOMED and LONIC as an example.
HL7 is a completely over engineered mess and it's a standards process driven by too many doctors and other health professionals and way too few computer scientists. It tries to capture the process of health care as a protocol. Completely wrongheaded. By the way, I worked on the UML 2.0 standard committee, which I think is reasonable by comparison to HL7, which is a major user of UML. Let that sink in.
HIPAA also has completely outdated and overly complex requirements as well. It was well intended, but it needs replacement. The law standardized technology, not requirements and that's a mistake.
Epic is a total mess. A local hospital system in my state adopted it and (surprise), it was horribly over-budget and there are still issues. And it's legacy code out of the box. It's all based on MUMPS and bits and pieces hacked on top of it.
Overall, the main problem is insisting that the problem be solved all at once, versus step by step. Step one, establish a system for identification for health providers and patients. This includes a system to get a identity of a patient via known data while providing a high level of confidence that the requestor of information is a health provider. Solve this, and then you can start talking about interchange. And start simple. Forget highly coded documents. Exchange vital history, procedure history, problem list and notes. That's it. Then move forward based on actual user demands.
Frankly, Clinton had the right idea with the national health id. If we could create an ID that everybody had that was only used for medical identification, that'd be great. But I doubt that'll happen, so we will be stuck with a huge data deduplication problem.
It's not easy, but it's more doable than people think. And heck, open source as a means of standardization is a fine part of this equation that is completely ignored.
Does the law actually differentiate between how the electronic records are stored? If the system used ternary numbers doctors would be in the clear?
Troll is not a replacement for I disagree.
That underneath it all is a flat file structure and a database product like MS-SQL, MySQL or even PostgresSQL.
What they really need is someone that's good at reverse engineering.
Problem # 1 - Whomever thought that a self-service machine for check-in with a bunch of old people trying to use it needs to be shot. They had a paid employee babysitting the machine because most of the people trying to use it were clueless.
Problem 2 - Even when you're knowledgeable about technology, it's still not easy. You type your first and last name, and then click the button. Fine, seems easy enough. Except once you click the button, the screen refreshes, and it gives you no indication whatsoever that you successfully checked in. The only reason I knew was because the babysitter told me that it went through.
It all really scares me. Human error is limited in scope, but human error with a technology multiplier (and probably will) wipe all of us out.
>yes we still use faxes in our office much more than any other method: THEY ARE SECURE.
Regular faxes are absolutely NOT secure, though a secure "fax" server can be. It's unusual for anyone who needs to be HIPAA compliant to use unencrypted means to send patient data. Leaving patient data in a fax receiving bin would result in fines if you're caught.
http://www.securitymagazine.co...
The Free Market shall Provide a binding and comprehensive solution.
If you were me, you'd be good lookin'. - six string samurai
Ah, yes, Judith Faulkner:
http://dailysignal.com/2011/08...
A major donor to the Democratic Party has received favorable treatment from the Obama administration, including a choice appointment to a federal advisory committee, and lavish praise from the president himself.
Yet health information technology vendor Epic Systems Corp. opposes a key administration position on health IT. Its founder, Judith Faulkner, has spoken out on numerous occasions against “interoperability” in electronic medical records technology.
So why was Faulkner appointed to a 13-member panel charged with recommending how $19 billion in stimulus money be spent? One can’t help but notice that Faulkner and other epic employees have given nearly $300,000 to Democrats since 2006.
Read the rest of it.
Do you have ESP?
This is how the entire medical device/tech industry works. Take a look at the DICOM (Digital Imaging and Communications in Medicine) standard some time. It was developed so that you could move images from scanners to storage or diagnostic work stations and be able to analyze the images no matter what vendor hardware was at the other end. Sounds great, doesn't it?
So what happened was all of the major vendors (Siemens, GE, Philips, Toshiba, etc) got together with others and "standardized" all of the metadata (DICOM tags) in images. So things like the patient name, date of scan, what model/type of scanner was used, pixel/voxel size, etc. would be in the same tag no matter what vendor created the images. But what ended up happening was that everyone added the tags they wanted, so each vendor can keep using a different tag for the same field. Though this has gotten better.
But the real fun is that each vendor also has "private" or "shadow" tags. So they can make a software change on a scanner and suddenly a value that used to be in one of the standard tags is now somewhere else. And if you are lucky they left the tag you were expecting it to be in empty. But not always.
On the communications side of things, some of the older PACS archives can only accept a series one image at a time sequentially. But newer systems will send 8 or 32 images at once. So the older systems can choke, or in some cases simply accept only the fist image that gets sent in each batch. So if 8 images come at once, it'll only accept the first image of that batch and ignore the other 7. Most systems check for this now and send images as the other device wants them to, but there were some fun times a few years back.
Basically none of the vendors wanted this. They want medical institutions to purchase only their hardware. It was grudgingly that they agreed to the DICOM standard, and they do everything they can to make it difficult for other companies systems to talk to theirs. But they have to be careful to not go too far. Basically you get pecked to death by ducks.
Or the fact that it is a major pile of confusing fail, with moving goalposts and targets. Coupled with Medicare's Meaningful Use criteria (a semi random and, again, constantly changing set of requirements for an EHR) and you have the typical US Government Official Mess.
While Epic hasn't been particularly helpful - think of them as a Microsoft wannabee in terms of hoping to define the criteria and technology used for EHRs - it's really much more complex than simply a recalcitrant vendor. It has little to do with the underlying technolgy / language / data structure - it's just data, mostly text and some simple numerical info. The problem is organizing what data gets sent so the receivers can understand it.
This was supposed to have been solved decades ago with SNOMED, but alas, too many standards, too many cooks and too much potential for making lots of lots of money for some folks.
We're doomed.
Faster! Faster! Faster would be better!
This is all worse than whatever you think. There are maybe, one million laws telling me how I can use patient records. There are a million more for billing. And a million more for Medicaid and medicare.
Almost all software designed to be an Electronic medical record is really an electronic medical billing record. Because of the Feds and insurance companies insanity the electronic medical record was mostly invented to help hospitals and "coders" (people who look through my work and decide how to bill based on ill defined arbitrary changing ever year diagnostic or work codes).
As far as helping doctors - its horrible. Paper charts are probably better. Helping patients? HAHA. No one is thinking about that sadly. The EMR creates distance between me and my patients. It turned most doctors into part time secretaries where I spend as much time documenting the patient as I do actually taking care of them so that I can prove to some agency I did something.
Also - for conspriacy. EPIC is a big Obama supporter and essentially have profited off of the government mandated EMR. I am sure they will support Republicans as well to keep the gravey train. Obama also put the head Epic lady on the committee deciding how to implement EMRs. Not suspicious at all.
Very few physicians would by choice adopt and EMR because mostly they get in the way not help me treat pts better. I wish I was in a cash based specialty. You have no idea how messed up it all is.
Oh - by the way - the government has their own EMR. VistA/CPRS used by the VA.
It's written in MUMPS too - and can't inter-operate with anything without an act of congress.
"Newspapers: A tiny little part of the internet, printed out yesterday, and delivered to your house"
No, EPIC is absolutely not the "small shop" solution, EPIC is what you get when you walk into a large hospital. They have been trying hard to push their hospital software onto the small docs, and a few suckers buy in to their exorbitant prices (compared to, say, eClinicalWorks, which is actually designed and priced for clinics) perhaps in the vain hope that they can interface with their hospital if they use the same software.
Under HIPAA regulation (The Privacy Rule to be exact), you have the right to make changes to innacurate information of any PHI (Protected Health Information) they have about you.
So, yes, you may demand some information be removed by law, and they are legally obliged have a procedure in place for it.
The shiny side of the foil needs to be on the outside of the hat. The problem here isn't government intervention, rather a lack of same. The problem is corporate sociopathy and lack of standards. The standards should have been set up before anybody started building equipment. Where government fell down was not mandating that. Not a surfeit of regulations but a lack of them.
And had there been a monopoly there would have been no compatibility problems, but would have caused worse problems.
Free Martian Whores!
I have read a fair number of the comments posted here. And, the prevailing consensus is that there really isn't a standard when it comes to sharing health data and medical records between EMR systems.
Somebody mentioned HIPAA EDI in a previous post - those standards, however, are for passing information between entities for claims and not medical records. Why are the records themselves not specified in a publicly published format?
When I worked in the public safety software business, we were involved in many data sharing initiatives across the country. Many states had established their own platforms (Ohio and Wisconsin were pretty far along). But, on the federal level, they introduced GJXDM followed by the more comprehensive NIEM (National Information Exchange Model). The states moved towards this standard. While fairly big and deep, it make it fairly easy for NIEM compliant system to share data with one another. And, while the states built their own "free" records management systems, LE wanted their preferred vendors and the platforms with all the bells and whistles to support NIEM. So, we did.
Outside of this arena, we have HR-XML (for use by Human resources and NOT free). But, if you want to play in that game, you join the group and write systems compliant with it. At least there IS a standard.
What is criminal, in my mind, is that health care systems do not have a standard for describing this information. Nor, do they have a secure infrastructure for passing EMR data even if they did. It should have explicitly detailed as a provision in the ACA (aka Obamacare) so that healthcare providers and insurance carriers to interoperate. EMR vendors and insurance carriers should be REQUIRED and their software certified to comply with data interchange standards (which, may need to be formulated).
EPIC is in a position to set the standard. But, they won't because it means other vendors can get in the pool. So, somebody with really deep pockets and altruistic mindset needs to fund the development of a public standard, set the certification standards, and make it happen.
Change the penalty terms.
if doctors can't exchange records, they'll face a 1% Medicare penalty,
Make that read "If records produced by a medical record system cannot be read by another system, the vendors of the producing and reading systems will face a 1% Medicare penalty".
We could probably get that change legislated by slipping it in a farm subsidy bill someplace.
Have gnu, will travel.
A lot of these vendors are locked into their own technologies.
But nobody is locked in to faxes. To get info from one digital format to another, a read-type-print-fax-print-read-type cycle is never preferable to email. As a last resort, you can scan a document and email the scan. Fax machines need to die. Other than doctors, lawyers, and bureaucrats, they are already dead. They are still used in those three areas because all three can push the cost of the inefficiency onto someone else (patients, clients, and taxpayers).
The Office of the National Coordinator for Health Information Technology said that it was a "top priority" and just recently wrote a 10-year vision statement and agenda for it.
Sorry. Vision isn't covered by the ACA.
Have gnu, will travel.
"HIPAA EDI" is ANSI ASC X12 (specifically committee "N") which is a collection of file formats for communicating business transactions (in this case, generally submitting charge or payment information among providers and insurers), and has very little to do with medical records.
HL7 has created the Consolidated Clinical Document Architecture which hopes and dreams to one day capture provider documentation in an electronic format. The government incentives mandate certain pieces of this document to be supported by certified software, with the pieces differing between the phase 1 (now "2011 Edition") and phase 2 ("2014 Edition") certifications.
These pieces are nowhere near enough to actually transmit something resembling a legal patient record.
Deep down, though, the problem with communication is that every provider has their own style, from the wet-behind-the-ear doc who writes out all their SOAP notes long form over two pages mentioning every little thing like they're still trying to impress their professor, to the 40 year old doc who has made up a single page template with 40 checkboxes for the most common exam findings, a few checkboxes for diagnosis, and a box to write a plan, to the 60 year old who writes "ros/pe:wnl,pt well,flu shot,rtc 1y" on the line below where the nurse wrote the vitals and calls it a day.
What all of the above doctors have in common is that they do NOT want to deal in "structured data". They do not want to deal with SNOMED (or ICD-10, or hell, most of them don't even use ICD-9 that's what they hire billers for). Nobody deals with LOINC (good luck finding out the process used for your urinalysis dipstick so you can code the results correctly. I've got two major national labs that use LOINC for their test results, zero local labs, and zero labs that use LOINC order codes at all. For vitals at least someone in the government bothered to arbitrarily pick codes for height, weight, blood pressure and a few others out of the list of different ways of measuring each of them).
That would be illegal. Ted Kennedy made it so in the "Patient's Bill of Rights" known as HIPAA
That's the key - mandating a common schema (XML or otherwise). I talked with DC staffers several years ago that were working on healthcare law, but they disregarded it because the doctor's didn't understand it. And that leads to the other failure of healthcare... doctor's don't make good managers!
There is a certification process for Electronic Medical Records systems called "Meaningful use". Stage 2 certification requires vendors to be able to exchange information whether or not the doctor or practitioner is a subscriber to that particular system.
Certification is a critical component as to whether an EMR is certified to use for submitting claims to government. Vendors are going to have to get their "stuff" together if they want to remain viable.
http://www.healthit.gov/provid...
In addition, The IT support staff told her that the vendors "super secure" remote access software would only run on a Windows PC. When she's on-call she has to update patient records. Their plan is BYOD, of course. So... she took her old, crappy Vista Netbook in. All they set up was the RDP client, defaulting to their server on the public internet. She clicks the link, Remote Client starts, 2 user/passwords and she gets a 800x600 Windows desktop. It's got a solitary icon which starts the native application. Yup... Super secure. Scrolling, mousing, cursoring and clicking to get to the form elements take more than half her time charting. It was painful to watch.
She prefers to use her Mac laptop, so I set up a Mac RDP client to use their URL and she was able to login. I watched her for a few minutes and noticed that all the controls and text were low contrast and used tiny, fuzzy fonts in the tiny 800x600 window.
I asked her; "Why do you have it configured to be so small with tiny fonts?" "That's the way it's always been. Everyone complains about it at work". Sigh.
I show her how she can expand the desktop by increasing the size of the client window and full-screen the app window to expose more of the forms. "Wow! we didn't know you could do that. That will really help! Critical stuff is always hiding off screen" Control Panel is available so I select a high contrast theme and larger, default fonts. "Wow, now I'll be able to read what's on the charts from my exam stool." Their clinic had lots of training and "experts" on site to help them learn and use the system in the first weeks, so there's no excuse for the poor default configuration they gave them.
I don't understand what has happened to the software industry. We seem to have forgotten the basics and now make the people serve the tools.
It must be truly horrendous software if the data store is slaved to the UI.
In a system like this, the interface should be easily rewritten by anyone who wants to, and just talk to the back end using a Standard Query Language.
This is a problem that has been solved many times, and yet you STILL get companies like this who have cornered the market with a solution that's 30 years out of date.
When a replacement system is created, it should at least be backed by a public key infrastructure and use two-factor authentication. It should use a standard back-end database with an open tokenization system, a validation system, and logical data typing.
Otherwise, it's really not much better than digital faxes or email with some analysis software tacked on the front with a pretty UI.
So I'm not at all surprised to learn that doctors are resorting to faxing records. It's almost certainly easier than trying to exchange them digitally.
I thought all faxes were transmitted and received digitally... for the past 20 years. Are there still people storing them on paper?
Normal Facsimile workflow is like this:
1) person pulls up the records, saves them as PDF
2) Person "prints" PDF to fax
3) PDF is converted to CCITT-compatible TIFF format, which is then
4) transmitted as a high quality fax (we're not talking the old 30dpi ones anymore)
5) Recipient's fax machine gets the fax with header info, saves it as PDF and emails it to the appropriate local recipient
6) PDF is saved from email, possibly printed if needed, and filed via the local EMR.
And this is why the data you're looking for is in the hospital's EMR as a PDF: it was received by fax.
Any solution that's going to change this workflow is going to need to handle TIFF and PDF formats, with ClearText-style OCR. That way, people can still use the fax workflow as an alternative to digital data transmission. The system also has to have the ability to pull up the original PDFs in the cases where the OCR failed.
It'll then take at LEAST 5-10 years for the new digital transmission system to work out the kinks and gain enough momentum to retire the old workflow completely.
Finally! An agenda has been created..
We must not proceed without an agenda and a 10 year vision.
One question: Was this vision stated or was it just written down?
I can't believe you cited Total Recall as a reliable source of science. I just. Wow. I'm flabbergasted.
Huh. Which of those do I use to order a CBC? Which one sends a history and physical to the hospital? Which one does the MRI machine use to send me the picture of your brain? (trick question!)
Everyone's been using these transactions for years, but they are not relevant to the issue being discussed here.
If I have been able to see further than others, it is because I bought a pair of binoculars.
Some years ago after being laid off from one programming job, my old CS prof from college suggested I stop by to interview with the Epic recruiter who was visiting the campus. I was told to block out about four hours time, and that it would be a very in-depth technical interview. It turned out to be nothing of the sort: it was maybe ten minutes of talk with a human being, and hours and hours of filling out a badly-written "technical exam". Allegedly it involved seeing how well the taker could think about programming languages and programming language concepts by giving us a toy language to write a parser and compiler for, but ... holy toledo, was it a stinker.
First, the language was defined in plain English. There was no BNF. When ambiguities of English occurred (as they always do), the Epic rep was unable to give any resolution as to what the language was supposed to do. My protest of, "Well, if you don't know what it's supposed to do, how can you expect me to write a parser or compiler for it?" fell on deaf ears.
Second, certain mathematical operations were supposed to be supported ... but the language was vague: they were supposed to have their "conventional" meanings. But some mathematical operators are defined sort of vaguely: for instance, it's not really well-defined mathematically what the modulo of two negative numbers are. As a result, different programming languages tend to implement it differently. (For instance, C++03 says it's implementation-dependent, while C++11 has a strict policy on it.) How did they want the modulus operator implemented? They had no idea.
Ultimately, when it came to writing a parser and compiler for their toy language I decided to do it the right way as opposed to their way. Instead of having an ad-hoc thing, I turned the exam over and started writing a formal BNF and lex/yacc rules on the back of the pages. I took the full four hours to do the technical exam, turned it in, told them that my work was on the *back* of the exam and not the front, and walked out.
Six weeks later, not having heard a thing from Epic, I sent them a politely-worded email saying, "If I'm going to spend four hours on a Saturday on an interview for Epic, I would appreciate the courtesy of being told whether I would be receiving a job offer or not."
A week after that I received a one-line email: "We regret to say that we're going with other candidates."
Anyway. That's my experience with Epic. Take it for whatever it's worth. I didn't think much of their interview process, and they sure didn't think much of me.
I'm not recommending that every person have their own format. What I'm suggesting is more along the lines of a few vendors creating client/server applications to be installed locally (not the cloud). Many organizations are tackling the unstructured data problem present in medical records. There should be a standard for conversion (reading) but not necessarily for record submission (writing). If every patient is responsible for his/her data, then the requirement to convert information is left to the person that cares about it the most. Furthermore, this model leaves the door wide open for companies/consultants that are good at converting unstructured data to a standard format. The difference here is that it won't be one or two consulting firms converting Terabytes of data that can't really be verified, it'll be a business to consumer relationship where the customer drops off (or electronically submits) his/her medical data in various formats and the result is the same data in several of the most widely accepted data formats. Naturally, some people will be able to convert their own records. The relationship would work much like a tax agent. After the records are in one or more acceptable formats, they can be made available on the client/server application. Users could control read access at the click of button. I'm sure there are a lot of hurdles but the reality of the current situation is that this semi-centralized method for converting data to a standard that has been coupled with expensive software/hardware has to go. There must be competing standards to force evolution of existing data structures. The standards to read must be decoupled from the ability to obtain data in its raw format (major failure of HL7). The most important stakeholders (the patients) should own, maintain and share the data. You might think that this would just create a bunch of different standards but if we assume that this process is built on a business to consumer relationship-- the market would easily weed out the losers. I've worked with OpenMRS and a few other EMRs. These applications are not good at converting unstructured/raw data. There are companies that can transform data, but EMRs don't integrate the right technology. Once you have the data in a structured format, EMRs do a decent job of switching between formats. Lastly, they're bloated and clunky and the business model is geared towards installing a suite of tools or even a hardware setup.
Frankly, Clinton had the right idea with the national health id. If we could create an ID that everybody had that was only used for medical identification, that'd be great. But I doubt that'll happen, so we will be stuck with a huge data deduplication problem.
It's not easy, but it's more doable than people think. And heck, open source as a means of standardization is a fine part of this equation that is completely ignored.
This works well, with no problems, and has since the 90s. Before it was launched it was very thoroughly checked out by the Privacy Commissioner. All data held on the national database is encrypted. http://www.health.govt.nz/our-...
Why are you blaming the doctors, lawyers, and bureaucrats? There's no way to universally extract data from these proprietary systems and transmit it via e-mail to someone else, and certainly not securely. It's obviously a kludge, and everyone is starting to recognize this, which is why it's generating headlines - that's a start. Fax machines will die as soon as there's no actual use for them. We're obviously not at that point yet, so it's a good thing we have these older systems in place. The current headlines are far preferable to "Doctors are unable to exchange medical records with colleagues".
Scanning and e-mailing a document is semantically *exactly the same* as faxing it, only it's likely harder for the average office worker to do. What's the point of that? The solution is to create actual digital interoperability, not simply to arbitrarily remove the *one* solution that is actually solving the current problem, however clumsily.
Irony: Agile development has too much intertia to be abandoned now.
Place sounded like a borderline scammy place to work. The kind of company that grew too big to keep being managed by its founder and initial employees (not that it can't be done, but it can lead to a lot of personnel decisions being made based on things other than employee merit). Seemed like they thrived on overworking visa-holders since it was almost impossible for them to leave the firm (can't just quit, but can't easily find new work when you are travelling to client sites, working long hours, and returning back to home on the weekends to the middle of Wisconsin where it is hard to find another sponsoring employer).
I didn't return for the second interview...
Bottles.
MUMPS is pretty special. You can write clean code in it, but the language and culture around don't exactly lend itself to it. That example at DailyWTF is pretty typical of what you see in OpenVista based systems (which I assume Epic uses).
It looks like Epic isn't based on Vista as I assumed - but still uses the same M(UMPS) based technology. A comparison of the two systems can be found in a Healthcare IT News blog article.
Vista has an interesting history. Because it was built using US Federal Government money, the "Hard Hats" who worked on it originally successfully argued for the release of its source code into the public domain. It's essentially open source, paid by the public purse and - despite the M language - a successful example of where interoperability between healthcare IT systems can really work.
We've had decades of development in open standards. HL7 for all its ugliness is a great system and has really driven interoperability. For Epic to "go it alone" seems a real shame. And patently stupid - but then we've had similar stupid in my country (Australia).
The problems is there is a special exception in HIPAA case law for faxes.
As long as the fax machine is in a secure location that only authorized personnel can access you are good.
Contrast that with any other form of electronic communication that accesses PHI (name, initials, DOB, address, room number). These are all required to authenticate anyone who even glances at a document and keep an auditable log of all those glances. Sound straight forward, SMIME email with attachements right. Except who's server do I trust. I end up having to hire a lawyer to get business associate agreements with any doctor I want to send a email to. And then I have to keep an auditable log of all the employees at the other Doc's office who received an email from me. They add a new employee...I have to update my authentication server with the other Doc's emplyee's certificates. OK maybe you can do this with a few offices of 50 employees. Try sending email to the hospital...that means I have to sync with thousands of their certificates and deauth those certificates when THEY fire one of THEIR employees.
So lets see, my 20 employee office now needs a full time sysadmin just to use email someone at the hospital.
No thanks. Ill stick with two fax lines, a digital fax server and a secretary@$35k/year to file those faxes into the EMR.
Its just so much cheaper than the hoops you have to jump through to send HIPAA compliant email.
should of tryed raven software in the same area.
Exchanging records between two Epic systems is trivial.It is as easy as Judy's quote suggests, a few clicks from the clinic or hospital registrar. Also, since as the article points out over half the country's medical records are on an Epic system, it is extremely relevant that exchanges between Epic systems are so simple.If the New York Times were trying to accurately depict the record exchange situation as it stands, they would have mentioned this. It shouldn't have been necessary for Epic's customers to come to Epic's defense.
The article and many comments in this thread trash Epic for not supporting open standards like HL7. Fact: Almost every single Epic system has HL7 interfaces to non-Epic systems within the same organization. HL7 is only part of the solution needed for exchanging records between disparate systems at distinct organizations. There is still the problem of how to find the other systems, how to determine whether they have information on the patient in question, and how to ensure that the requesting organization has appropriately met the privacy requirements of the organization holding the desired data. These are problems Epic has solved for its own customers. The article does not mention how many Cerner, Meditech, Siemens, or GE systems are able to exchange data with like systems at other organizations. In any case, it seems that if the government is going to require any one of these organizations to share records with any other, they should be doing something to facilitate that, whether it be a clearinghouse system that routes requests from one organization to the next, or a set of standards that gives each EHR company something to use as a basis for interoperability development.
Finally, I fail to see what Epic's decision not to hire some of the commenters here says about the openness of their system, or how said commenters would be able to judge the openness of the system based only on knowledge of the language in which it was implemented. I guess was under the impression that the whole point of interfaces was to abstract a system's implementation details away from the developer coding an application against them.
Full disclosure: I am a former Epic employee.
As a physician who was dragged screaming and kicking into having to use EPIC, I have to agree.
I never knew I could hate a company more than Microsoft. Their client is a bloated horror that nevertheless acts like the thinnest client in the world: "Oh, look, the doctor pressed the Shift key ... I guess I'll send that over the network, and wait for a response ... oh look, s/he released the Shift key now -- I guess I'll send that over the network, too..." Apparently it's based on the Internet Explorer library, so there is no Mac version (at least not when I was using it)...
The interface was so bad that I learned how to program in AutoHotkey and probably spent in excess of 200 hours over a year to automate things. AutoHotkey was a lifesaver: open source and powerful. (In fact, the pitiful xdotool we have for Linux doesn't even come close to AutoHotkey for windows, and even if I weren't forced to use Windows for my work, I might have ended up choosing it over Linux just because of AutoHotkey and its ecosystem of experienced developers.)
At the time I was with a large clinic chain that had about 40% of the market in our large sprawling metropolitan supercluster location. They surveyed the doctors, who said that on average they were spending an extra hour per day using Epic. And in the end, it was a lot of *data*-generation and not a lot of *information*. Our specialists complained that everything was being crammed into a template form, and they really couldn't tell what we were thinking, just checklists of what the patient did/did not have.
Having vendor lock-in, they have no incentive to improve. They can do whatever they want... if the clinic/hospital is already stuck using Epic, why would they spend money on fixing their problems instead of recruiting more clients?
Having said all that, even Epic is better than what I'm stuck using right now ... eClinicalWorks. That's even worse than Epic. All the problems of Epic, plus even worse interface. Right now I type my notes in a plain text editor and then use AutoHotkey to cut-n-paste it into eClinicalWorks. What a nightmare.
OpenEMR all the way!
404555974007725459910684486621289147856453481154 in hex is "You sank my Battleship?"
[GPG key in journal]
Right, since few people know M then it must be impossible to provide interconnectivity. We all know that programming languages can't communicate with each other.
I just couldn't pass by saying this one. Even networks were not compatible at one time. IMHO, this compatibility can be addressed by having an open standard for minimal communication interface, and allow some folks that know how and can do the secure communication ( I have seen and worked with the SWIFT network. It is very secure an could be used for data transmission or store and forward. It is used internationally for banking now. It is a private network set up by banks based in Beljum, and is very secure IMHO. see https://www.swift.com/ for information on their products. I am just a happy former user. It ain't cheap, it is good.)
... "When you pry the source from my cold dead hands."
A lot of these vendors are locked into their own technologies.
I had interviewed at Epic once (didn't feel like moving to Wisconsin... sorry) and realized that they used M for most of what they did... not much interconnectivity there.
We in Quebec use the Quebec Government's standard. The local Jewish General Hospital uses it's home grown software and a bridge to the Quebec Government one too.
And there is a hospital in Austrailia that uses the same software as the JGH, It works out well. For example, At night (daytime in Austrailia), digital xray readings for the JGH are done there, and results sent back almost as immediately as transmission allows.
In the daytime at the JGH, they handle the digital xrays of the Aussie hospital.
No, Epic is not in the picture.
Leslie Satenstein Montreal Quebec Canada
that's still the law, if you read your source you would see that the HIPAA violation was the offense for other types of suit, such as a privacy violation.
Snowden and Manning are heroes.
ANSI X12 healthcare-related formats (837, 835, 277U, 277CA, etc.) are oriented around insurance claims, but some include actual medical information (diagnosis codes, dates of service, etc.). The diagnosis codes were to change from ICD-9 to the somewhat less antiquated ICD-10 on October 1, 2014.
Supposedly, one of the benefits of ICD-10 will be that more automation of acceptance/rejection decisions will be possible. ICD-10 codes are more granular, with a hierarchical taxonomy, and the subfield of the codes are more orthogonal. A possibly inaccurate example: the broken limb code is short, followed by one or more subfields that indicate left/right, upper (arm)/lower (leg), proximal/distal. And for those subfields, "unspecified" is an option. The subfields aren't necessarily about location, but also might include severity, apparent cause, chronic/temporary, etc.
How granular and orthogonal? There's a code for "burns suffered while operating a personal watercraft", for instance. When I heard that, I was skeptical, so I went looking. Google found it. Also, one for an injury resulting from stepping on a turtle, or something like that. And so on.
Naturally, there's no automatic conversion of codes from ICD-9 to ICD-10, or the other way. There are "crosswalk tables" that will list for a code the possible equivalents in the other, with a short textual description to help figure out which one is the best match.
The mandated switchover from ICD-9 to ICD-10 was delayed a year by an amendment attached to the annual "boy did we screw up Medicare reimbursement decades ago" fix. Apparently a lot of folks in health care and supporting industries who will be negatively impacted wanted more time to prepare: update software, install updated software, train claim coders the bazillion new and different codes in ICD-10, arrange a line of credit to cover the temporary loss of revenue as claim rejections rise during the first months of the switch-over, etc.
Line of credit? Yep. A previous ANSI X12 change caused a lot of payments to be delayed while providers corrected a larger-than-normal number of claim rejections. Or punted, because the effort of correcting and resubmitting smaller claims wasn't worth the effort. ICD-10 will have a similar effect on doctors, hospitals, dentists, chiropractors, ambulance services, etc.
Expect ICD-10 to be required in October 2015. (Unless it gets delayed again.)
There's no time like the present. Well, the past used to be.