Back To Faxes: Doctors Can't Exchange Digital Medical Records 240
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.
It's time to fine. (Score:5, Informative)
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.
Re: (Score:2)
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.
That's not true at all. As the summary suggests, they just print and fax it over. Simple as that. I've done it... some of the more unfriendly places will charge between $5 and $20 for the effort. But that's not that big of a deal considering infrequently you switch HMOs
The reason it's hard is because all of these medical CRM systems are "in the cloud" If you're in Epics cloud it's easy to transfer data to another company in the same cloud. If they have a completely different system? LOL, good luck. Not only
Re: (Score:2)
As the summary suggests, they just print and fax it over. Simple as that. I've done it.
And then the receiving office has a big pile of paper. If they even bother to do so it is very expensive and error prone to manually enter that stuff into an EMR. But if they don't enter it into the EMR your record is not readily available
GP is partially correct, vendors hate to provide interfaces and custom reports. Not just for lock in, but mostly because they never get paid enough to support them. Even a fairly small system could end up with dozens or hundreds of reports and interfaces; forget about eve
Re:It's time to fine. (Score:4, Interesting)
No, the reason it's hard has nothing to do with "cloud", and everything to do with "no adherence to a common data schema". If the data was forced to follow a standardized schema, and if standardized service interfaces were required for participating in the government health plan, transferring it would be dead easy. But because different systems have evolved differently over time, the schemas are different, and so transfers remain painful. And because the government funded EPIC without demanding the creation or implementation of industry standards, we crapped away all that money strictly to make one company very, very rich.
The lesson here, kids? If you've got a shot at an upcoming government contract, your best investment dollar is spent on a Congressman. Donate lots of money to his campaign, and you could easily see a 1000 X return on investment. You won't get odds like that gambling on Wall Street.
Re: (Score:2)
I should correct that: "no adherence to a common data schema" should probably be "proprietary, secretive, incompatible tweaks to the overly complex schema in order to proclaim compatibility." Because there's a difference.
Re:It's time to fine. (Score:4, Informative)
But because different systems have evolved differently over time, the schemas are different, and so transfers remain painful.
It's not even that. One thing I learned while working on a project that wanted to pull EMR data was that different hospitals could have their own schemas. One division in the hospital found that the standardized codes for what they were doing weren't robust enough and invented their very own coding system which was used in that single division of that single hospital and nowhere else.
Good luck translating that to any other coding system anywhere else.
I'm not sure I can even blame them for creating their own coding system. They're doctors who found that the tools available didn't meet their needs and found a solution. Down the line it makes data transfer more difficult, but is that something doctors should really be concerned about when they're trying to accurately record medical information about their patients?
Re: (Score:2)
Re: (Score:3)
It has nothing to do with the cloud. The problem here is that Vendor X really has no incentive to create interfaces to communicate with Vendor Y, beyond a customer willing to pay them to create said interface. And even then, the customer is only paying Vendor X, and not Vendor Y, so any assistance Vendor X gets from Y will be spotty at best.
And nothing about that is going to change until the federal government steps in and forces these vendors to play nice using a set of standards. It's a slow, messy, ugly,
HL7? (Score:3)
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...
Re:HL7? (Score:5, Insightful)
The primary purpose of HL7 seemed to be enabling massive consulting hours clarifying the poorly-defined HL7 standard.
HIPAA is like HL7 version 2.0. They've dispensed with "poorly-defined" and moved up to "completely arbitrary". The boon this provides... for lawyers... cannot be underestimated.
Re: (Score:2)
Re: (Score:2)
The primary purpose of HL7 seemed to be enabling massive consulting hours clarifying the poorly-defined HL7 standard.
Which HL7 standard do you mean? V2 or V3? (So HIPAA can't be HL7 2.0, since HL7 is already up to 3.0.)
Or FHIR, the amazing new standard from the people who brought you HL7 that brings the amazing bewildering complexity of HL7 to you in a nice new XML-based format?
Re: (Score:2)
Re: (Score:2)
The boon this provides... for lawyers... cannot be underestimated.
I suspect you mean
cannot be overestimated.
Re: (Score:2)
Hmm... but this is a boon -for lawyers-.
I stand by my original statement. There is no limit to how negative this could go.
Re: (Score:2)
The Meaningful Use (MU) requirements that are alluded to in the original post are pushing Continuity of Care Records (CCD) for this type of data exchange. And all the major EMRs and Practice system support some flavor of CCD. Just how much is the question. As it is XML, the CCD is finally a healthcare standard thats useful, in contrast to the not so standard standard of HL7. Epic is bad though about sharing data. Many others are much better.
Re: (Score:2)
Re:HL7? (Score:4, Insightful)
Complying with HL7 is right next to pointless. The HL7 standard is (despite its name) is NOT standard. One would think that patient demographics would be very easy to assign codes to. Unfortunately, there are many places the information can go and still be considered HL7 compliant. So if one system uses one of these sections and the other system uses another for the same data, they will be unable to effectively exchange information. Each of theses systems' companies will blame the other and insist the other one change their system or, better yet, that the facility using these systems dump the other and purchase their similar system. I believe this is intentional.
You don't see similar problems with electronic banking. As I am fond of saying: You can mess with peoples health and lives, but don't you dare mess with their money.
Re: (Score:2)
Makes one think none of these programmers ever encountered the adapter pattern [wikipedia.org].
Re: (Score:2)
Re: (Score:3)
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...
It was the point of HL7, but is a fail in a lot of circumstances. Saying "HL7" is a bit like saying "XML" combined with "TCP." That's great to be able to exchange XML over TCP, but without all the details being included it doesn't mean any two systems that can exchange XML over TCP and have it be meaningful.
Most EMR systems are flaming piles of crap, especially the big players like Epic. That's because they are designed to satisfy bureaucrats who have a checklist of features. Unfortunately, being usable
I Maintain an EMR System (Score:2, Insightful)
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 a
Re: (Score:3)
Well, the feds did manage to put a man on the moon in under a decade, when the technology didn't exist. One of the spin-offs of that project led to the computers we take for granted today.
And they did this while waging a proxy war with the Soviets in Asia, and not having the whole mess devolve into MAD, which was a real risk at the time.
A lot of the problems with the health care system can be laid at the feet of lobbyists.
Re: (Score:2)
The entire Apollo program was filled with near misses and serendipitous moments. Kinda scary to read about now.
Re: (Score:3)
"A lot of the problems with the health care system can be laid at the feet of lobbyists."
No, it can't, unless and until lobbyists vote on the floor of the House and the Senate.
They already do, by proxy. They have the economic clout to have better access to members of both the house and senate than the constituents they are supposed to represent, and thus can lobby for things that are beneficial to them as opposed to the general public.
Re: (Score:2)
I would settle for lobbyists BLEEDING on the floor of the House and Senate.
Eminent domain (Score:3, Interesting)
Invoke eminent domain to seize the right to share the data, for the common good of citizens health and safety
The genius of EPIC (Score:5, Insightful)
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.
Re: (Score:2)
Re: (Score:3)
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...
GOOD (Score:5, Interesting)
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.
It is your legal right under HIPAA (Score:4, Informative)
So, yes, you may demand some information be removed by law, and they are legally obliged have a procedure in place for it.
Re: (Score:3)
But, it's not their data. Its from other clinics, hospitals. According to them, they do not know which ones. I've asked numerous times. Yet, every time I go in, it's still there. They want to merge the records and it prompts them to do so, but I refuse to allow it. Is this Epics fault or the clinics? I Don't know. All I know is that the system as a whole refuses to give me enough information to fix it.
Re: (Score:2)
I should get to chose which records are kept about my health.
Agreed. I don't understand what is so difficult about giving the patient their own electronic healthcare records and letting them be responsible for providing that information to healthcare providers.
Why does a patient need their medical records in a form that can be be instantly transmitted on a global computer network? Also, I would think that you shouldn't need a detailed medical history to treat most acute things, chronic illnesses excluded. Does knowing that I had my adenoids removed as a child, o
Bruce Perens (Score:3)
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.
Re: (Score:2)
When Bruce Perens was getting questions from slashdot, I asked whether Obamacare should have mandated the use of open source software....
Easy to ask, difficult to do.
.
Obamacare barely passed when Congress considered it. If such an open-source requirement were in the law, then lobbyists from EPIC-type companies would be all over Congress, and Obamacare would have never passed.
Companies pay lobbyists to make sure Congress passes laws that put money into the companies' coffers. Things like cost-efficiency are not part of that equation.
Re: (Score:2)
So he is a Democrat and they getting elected is all that matters. BTW I also have no tolerance for devout Republicans.
Actually this could have easily been solved by FOSS.
http://en.wikipedia.org/wiki/V... [wikipedia.org]
Re: (Score:3)
It is time to stop looking at (R) and (D) labels, and making kneejerk judgements regarding them. I agree with parts of both (D) and (R) platforms and positions their politicians take. But in aggregate, I hate them equally, but for different reasons.
In the case of ObamaCare/ACA, it is the idea that we can fairly equalize access to health care simply by mandating it, with NO OTHER changes being made (not really). The whole idea of mandated coverages, and whatnot skirt the real issue, scarcity of healthcare re
Re: (Score:2)
That is just it. The VA has already developed the software to do all this and it is in the Public domain.
http://en.wikipedia.org/wiki/V... [wikipedia.org]
All you have to do is state that if you take medicare you must use a system compatible with VistA.
It has been used for decades and has been updated as well. A lot of companies even use it as a base for their products.
I would love to see the US government move it from public domain to GPL but I doubt that is possible legally.
Re: (Score:2)
Linux never did (yet) conquer the enterprise; instead they found interoperability by converging on Microsoft. Similarly, Internet standards bodies are increasingly irrelevant as most users flock to proprietary solutions, e.g. using Facebook instead of email to communicate with family and friends. And mobile computing (smartphones) never found mass adoption at all until it was packed into a mana
Re: (Score:2)
Open Standards and Protocols are what this space needs, along with regulations requiring vendors to allow interoperability for free or a nominal fee.
Open Source software, on the other hand, won't really solve any problems. Someone has to write the software and vet it. EHR software isn't an itch people typically want to scratch. Of course, an EHR platform could leverage Open Source software for development. A Web-based EHR could use an entire Open Source stack and even contribute libraries for protocol suppo
Re: (Score:2)
I work at a hospital that uses Epic. I do back-end databasery, and I can tell you, an open source replacement for Epic would never, ever be adopted here.
First, when you're dealing with HIPAA you need to make sure your t's are dotted and your i's are crossed, and you need somebody to blame if they're not. When your open source system is breached and health data made publicly available, who are you going to blame? "But, we thought it was secure because a bunch of random guys working their basements said it wa
Re: (Score:3)
It could be worse, you could have a dozen different McKesson applications that use different platforms (some .NET/SQL Server, some Java/Oracle), don't do everything promised, are way overpriced, pathetic support, and technology that was state-of-the-art back when Clinton was president (two-tier fat apps? really!?!?)
Re: (Score:2)
Yes you could.
http://en.wikipedia.org/wiki/V... [wikipedia.org]
It has been fully tested and used in all the VA hospitals. BTW the problems in VA hospitals where not caused by software.
Having tried to pull in medical data from an EMR (Score:3)
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.
Re: (Score:2)
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 softwar
Re: (Score:2)
The great thing about standards are that there are so many to choose from!
Change the model (Score:2)
Should have done this at the start... (Score:3)
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.
There's no W3C or IETF for healthcare (Score:2)
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.
Re: (Score:2)
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.
RS232 didn't have packets. It had wires. It didn't have ACK/NACK either. It had CTS/RTS and DCR/DTR. There were some secondary signals (STD, SRD etc) that were rarely implemented after 1980.
Re: (Score:2)
Every protocol that runs over RS232 has packets and some kind of ACK/NAK system on top. CTS,RTS,DCR,DTR, etc. are rarely used since most implementations are 3-wire RS232. ASTM is an example of such a protocol.
Re: (Score:3)
>Every protocol that runs over RS232
Protocols that run over RS232 are not RS232. RS232 is the interface spec.
"Proprietary vendor sets up to screw customers" (Score:2)
Gets worse than that with applications (Score:2)
What does Canada, UK, EU etc. use? (Score:3)
(No, seriously.)
.
The problem is the market, not the maker (Score:5, Informative)
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.
Ophthamologist (Score:2)
The ophthalmologist that spent half a million on a system is a complete moron.
Billionaire Computer Science Major Judith Faulkner (Score:2)
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 clinicia
Fax (Score:2)
A Self Imposed Mess... (Score:3)
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.
Why does everyone use Digital? (Score:2)
It's very likely (Score:2)
What they really need is someone that's good at reverse engineering.
EMR / EPIC is just one big cluster (Score:2)
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 m
Don't worry, everyone (Score:2)
The Free Market shall Provide a binding and comprehensive solution.
Judith Faulkner (Score:5, Interesting)
Ah, yes, Judith Faulkner:
http://dailysignal.com/2011/08... [dailysignal.com]
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.
Health Data Exchange Format? (Score:4, Insightful)
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.
Simple Solution (Score:5, Funny)
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.
10 Year Vision Statement (Score:4, Funny)
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.
It's coming (Score:2)
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... [healthit.gov]
The data input side of EMR is just as bad. (Score:3)
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.
My story with Epic (Score:2)
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
sounds like a job for (Score:3)
Google care or appleMed
Re:sounds like a job for (Score:4, Funny)
Considering that it is the informational infrastructure of a hospital system that is the weak point, not the care itself, Google is clearly pretty damn good at that.
AppleMed on the other hand would suck. Have fun paying 3x for premium couture band-aids. They'd likely excel in plastic surgery.
Re: (Score:2)
Re:sounds like a job for (Score:4, Informative)
EHR giant Epic explains how it will bring Apple HealthKit data to doctors
http://venturebeat.com/2014/09/17/ehr-giant-epic-explains-how-it-will-bring-apple-healthkit-data-to-doctors/
Epic Systems, the dominant EHR provider in hospitals and large medical groups, has been working with Apple on its HealthKit consumer health data initiative. But until now, the famously media-shy Epic and the famously secretive Apple have said very little about how the HealthKit ecosystem will work to the benefit of clinicians. But Epic has begun to talk.
Apple launched its new iOS 8 mobile operating system today, and a significant feature in that release is the Health app, which stores various types of our health data. You can think of HealthKit as a consumer health-information cloud data repository that connects to, and receives information from, a variety of consumer devices (connected scales, fitness trackers, smartwatches, etc.) and apps (food diaries, calorie counters, workout journals, and so on).
People in the health care industry hoped for more from Apple’s HealthKit platform than just amassing and sharing wearables data among app and device makers. They wanted HealthKit to make a difference. They wanted it to make people healthier.
A large platform collecting billions of data points about hundreds of aspects of our health on a daily basis might create a powerful information resource for health care providers and researchers. But in order for that to happen, the data will have to find a way into clinical systems, like the electronic health record (EHR).
“Apple’s HealthKit has tremendous potential to help close the gap between consumer collected data and data collected in traditional healthcare settings,” said Epic president Carl Dvorak in an email to VentureBeat. “The Epic customer community, which provides care to over 170 million patients a year, will be able to use HealthKit through Epic’s MyChart application—the most used patient portal in the U.S.”
The “customer community” Dvorak refers to is the hundreds of clinics and hospitals that use the Epic EHR. Patients use the Epic MyChart app to access elements of their own patient record from the Epic EHR. But note that the EHR accesses HealthKit data from the MyChart app, not via a direct integration with the HealthKit platform.
“While Apple will never mirror your Health data to iCloud (or allow another app to do that), once you provision access to another app, they may transport it elsewhere (e.g., to your provider’s EHR), but only if that particular endpoint allows access,” said Malay Gandhi of the accelerator Rock Health.
This may have been by design to avoid regulatory or privacy issues that might have arisen from Apple storing personal health data on its servers and then transmitting it past a health provider’s firewall and into clinical systems within. Here’s how Epic spokesman Brian Spranger describes the movement of data starting at the consumer device and ending at the Epic EHR.
“A consumer health app, like the Withings Scale, will notify HealthKit that it has a new weight and ask HealthKit to store that weight in the database on the iPhone,” he said.
Notice that the weight data that the scale collects doesn’t sit in the HealthKit cloud; it’s on the user’s phone.
“If the patient has given permission for the MyChart app on their phone to know about that data, HealthKit “wakes up” the MyChart app and tells it there’s new data,” Spranger said.
So in this regard, HealthKit acts more like a traffic cop, connecting to devices and directing them to send or store data, all guided by privacy rules.
“The MyChart app on the phone then transmits that weight back to the EpicCare EHR system where it
Re: (Score:2)
Um, Google tried the whole GoogleHealth thing a few years back and gave up: http://en.wikipedia.org/wiki/G... [wikipedia.org]
This is not an easy space to play in. Hospitals and doctors are slow to change. Once an investment has been made in a particular platform it's very difficult to replace it.
-Chris
Re: (Score:2)
Re: (Score:2)
Said like a true MSNBC fan!
Re: (Score:3)
The one thing the Feds can and should do and they are asleep at the switch.
Re: (Score:3)
Re: (Score:2)
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 d
Re: (Score:2, Interesting)
"HIPAA EDI" is ANSI ASC X12 (specifically committee "N") [x12.org] 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 [hl7.org] 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 suppor
Re: (Score:3)
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.
Re: (Score:2)
>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.
Re: (Score:3)
Re:Like SAS etc (Score:4, Interesting)
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 [wikipedia.org] for most of what they did... not much interconnectivity there.
Re: (Score:3, Funny)
they used M for most of what they did...
No wonder this is screwed up. What does M [wikipedia.org], head of the British intelligence agency, got to do with American health records?
Re: (Score:2)
Re: (Score:2)
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).
Re: (Score:2)
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 h
Re: (Score:2)
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 t
Re: (Score:2)
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!
Re: (Score:2)
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!
Re: (Score:2)
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.
Re: (Score:2)
Forgot the link, awesome. http://www.connotech.com/FAXBI... [connotech.com]
Re: (Score:2)
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... [securitymagazine.com]
Re: (Score:2)
No. The software isn't the hard part. The hard part is the requirements gathering for the data schemata (aka archetypes). For example, suppose you want to create an archetype for blood samples. At a minimum you need to talk to phlebologists and GPs, but you probably also need input from other specialists who might refer someone for a blood sample to see what they need from the data. Then you work out the indivisible chunks of data, run them past your domain experts, fix any bugs they spot, repeat. And even
Re: (Score:3)
Re: (Score:2)
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