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.
Mostly these products are focussed at non-technology industry small-shops (a doctor's practice is perfect) and sell Stone Soup, and lock-in at every opportunity.
Once again, the outcome of government intervention is money for vested interests, insiders, and enabling a monopoly.
Prove anything by multiplying Huge Number times Tiny Number
Next up? Micropayments to write prescriptions and Prescription Prime where they will ship them to you for free.
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.
Why isn't there a national standard in place for the exchange of medical information?
Shouldn't they have been using HIPAA EDI in the first place? And don't tell me they haven''t had time. The standard has been around for over ten years.
I've been working on office machines, printers and the like for over 30 years. I never knew that I would have to learn so much about the inner working of the (U.S.) phone system that I have had to learn. With the break up of the phone company, VoIp, and the like, it is a PITA to figure out sometimes, why a fax cannot transmit from certain numbers, or receive from certain numbers. Fax machines are analog, and the internet, well is obviously digital. It's like mixing oil & water, and forcing it to mix! Then you have the problem of the ATA adapter, that converts the digital VoIP signal, back into an analog modem signal. For obvious reasons, network techs try to plant all equipment in a central location. Do that with an ATA box and run a (usually) unshielded phone line several hundred feet to a fax machine and you'll be lucky to even have a dial tone, not to mention enough loop current or ring voltage for the fax to even work. Then, even if they do mount the ATA box close to the fax, if it doesn't have the T.38 firmware, don't even bother turning on the V.38 modem features, or some of the MMR/jbig compression features. Sad, that even here it is, 2014, and we are still using technology that was technically patented in 1843, became somewhat usable in the 60's. Time to move on!
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.
EPIC? What kind of failure is this?
...If the summary is right. It would have been right a year ago, and yes we still use faxes in our office much more than any other method: THEY ARE SECURE. However, there is now a new interoperability standard of Direct Mail. Whether vendors charge for it or not is a different question.
I'm more interested in how CMS and ONCIT has managed to get away with making up the rules for what compliance will consist of as they go along. The government is forcing standards without consideration of cost or implementation lead time, all under the cover of offering reimbursements (which, in the long run, will end up costing physicians offices more money than they'll save.)
It's carrot and stick and the patients will pay for it, either way.
(And I've been in it since before Meaningful Use began...)
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.
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 such a project: http://www.open-emr.org/. Not sure how good it is. I agree though. I went to a doctor the other day who is in the same practice group as my primary provider - uses a completely different EMR - the systems don't talk!!!! I keep having to fill out the same information over and over again for doctors that employed by the same hospital-affiliated system - this needs to stop. Of course, the other problem is, now most of my doctors are staring at a computer screen during the whole visit instead of looking at me. Very frustrating!
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 it was only that simple....
The HIPAA EDI standards for Health Care info are very extensive but leave a lot of options open to the individual implementations. Records & Fields that are defined as "optional" in the standard can be required by one specific payer's system and not allowed by another's. So what you end up with are lots of different implementations that technically comply with the standard but will end up causing catastrophic failures if ingested by any system other than the one specific one they are meant for.
I've implemented X12 837 Interchanges for lots of insurance companies. Insurer A may require the Hospital or Doctor's info to be passed in the "Provider Facility" records and not allow the "Billing Provider" segment, while Insurer B requires the exact opposite. And the business logic applied to determine who the primary, secondary, and tertiary payer is for a claimant with multiple coverage can range anywhere from "the order they are listed on the claim" to a novel of advanced lookups on type of service, payer names, and patient information all of which results in massive structure changes to the EDI transaction that is produced.
HL7 is a perfect success. It created the lock-in and consulting hours we paid for it to give us. By the way, your model will implode because it's the only worse one than ours. At least with our model, every EMR is different. With your model, there's a unique EMR system for every single human.
Getting providers to implement CEHRT systems that can transfer medical information and CCDA's via state and federal health information exchanges is precisely what the 2009 HITECH Act was enacted for in a way to make these new EHR technologies "meaningful" to patients. Certain federal requirements are in place to insure, over time, an electronic exchange is possible between platforms. Here in Massachusetts we have the Mass HiWay, an statewide electronic health information exchange. Hospitals with different EHRs that are certified (CEHRT) and registered with the Mass Hiway can share electronic health information. As more states implement their own exchanges as part of the Affordable Care Act they will be able to link them together, creating a national health information exchange. Is it here now? No it is not, but it is coming.
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.
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!
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)
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.
All this is a big headache in the healthcare industry, everything is disjointed, older technology or they force massive fees down your throat for what should be simple features. I just started using a new site developed by my friend who is an orthopedic surgeon and got fed up with all this business as well, its called Medtunnel and has been working fine so far, and it costs nothing...
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?
I work for a company using Cerner, and I worked for another vendor about 15 years ago that interfaced with cerner.
Cerners HL7 interface is OK.. but their system is massivly complex. They have bought a myriad of other add-on applications and anciallary vendors, then poorly integrated them. Cerner tries to be everything, but ends up doing everything badly.
I've also worked with NextGen and a handful of other EMR suppliers. The mid-size vendors are actually better than the larger vendors as far as application integrity and customer service. But they lack in large enterprise experience and support for devices. The device support part is very important for hospitals.
-Anyway, HL7 is a specification that is used to transfer information between hospitals and systems. The HL7 spec is pretty clear in its structure, but many organizations missuse it. For instance, only using the 'admitting doctor' field for the consulting doctor, rendering provider, supervising provider, etc. There is a whole market in HL7 interface vendors -Cloverleaf, Mercator, etc, (I even wrote one myself!). And there are positions available for people who write rules for the interface to massage the data into something normal.
But there are flaws in the interconnectivity of the systems. Two organizations need to agree on the same interconnectivity applications. ("I use SSH and FTP the HL7 messages." -"Oops sorry I only support HTTPS") many of the vendor-supplied interfaces are buggy and crash, or stop accepting messages, etc. -Yes I had to conference in vendors and hospitals and run live tests while sniffing the TCPIP packets in order to resolve issues. This is nothing new.. I was doing that 15 years ago!
Ok here is a thought
They have this new state of the art application called Email. I mean it is really new so maybe the doctors have not heard of it yet since they don't publish new technology's in medical magazines.
Perhaps they can pull a record and then print to PDF. Then email the pdf file of the records to the doctor's office of choice.
Oh my I hope their dial up AOL accounts can handle the data.
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.
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.
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.
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.
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.
You are a complete idiot greenwow. Nobody takes your trolling seriously
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.
The simple solution would be start with a base system which would allow exchange of text, uncoded ascii would be a start. Then a second version with unicode, then a third version with a standard like RTF.
Ideally, these would have titles and be divided into documents. Finally an fancier attempt like HL7 could be sent.
Doctors read these records and use them to take care of patients as the primary use. All the coding information in HL7 is secondary to patient care.
Later this text could then be analyzed and indexed by algorithms
(posting as AC) I work as a sysop at a hospital that is trying to get rid of a bunch of semi-expired McKesson products to be replaced by EPIC. Our entire analyst and informatics teams have been working on its deployment for 8 months or so, and to boot, the server is being run at a hospital outside of our group of hospitals. It's bad enough that we'll have to rely on said outside hospital's almost non-existent support, but if the software is as garbage as you say it is, then it's going to make my department look really bad. Thanks for the warning. I guess I should start job shopping now.
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.
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.
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-...
Judy can afford to lobby to go to war with Canada, and win. She's Elite to the level that is incomprehensible to us reading /.
She hacked the whole healthcare system to her advantage, Epic is just a giant obfuscation filling a need that no one else does... YET...
Are they any better?
The Epic Welcome kiosk (that's what it's called) is a not very good solution for a problem which hasn't happened. It doesn't save money as there's a huge up front cost and the clinic still needs check-in staff as not everyone wants to or is able to use the kiosk, if they get 60% usage they're lucky.
What is the software she's using?
My name is Lawrence, I am from U.K. I want to share my testimonies to the general public on how this great man called Dr Osas cure my sister from Genetic Herpes with the herbal medication gotten from dr. osas, he cures other diseases too herbal is a great medication. To hell with the government and their insane policy, he have a medication that is hundred percent assured to cure genital herpes and you don't need to spend so much money on anymore . I want you to contact dr Osas on: doctorosasherbalhome@gmail.com My family is now a brand new one, so stop your worries and go get your medication and set the family free of the deadly disease that hold no respect to family harmony. Thank you for reading my comment.
THESE ARE THE THINGS DR OSAS DOES
1. HERPES
2. LASSA FEVER
3. GONORRHEA
4. HIV/AIDS
5. LOW SPERM COUNT
6. MENOPAUSE DISEASE
7. EPILEPSY
8. ASEPSIS
9. CANCER
10. ANXIETY DEPRESSION
11. PREGNANCY PROBLEM
12. SHORT SIGHTEDNESS PROBLEM
14. Male menopause
15. Menopause - male
16. Menopause - peri
17. Menstruation problems
18. Mercury Poisoning
19. Migraine
20. Miscarriage
21. Mites (demodex mites)
22. Mites (scabies mites)
23. Motion sickness
24. Mouth ulcer
25. MRSA
26. Multiple sclerosis
27. Muscle cramps
28. Myodesopsia
29. Stroke
30. He can as well cast and remove spell
Your solution is digital.. it's required to be fully HIPAA/HITECH compliant. You miss the exception for it being the old style fax.
For commercial systems there is the EDI (Electronic Data Interchange) standard. You would think the US Govt. would require a standard for medical records also so this sh!t didn't happen!
you cannot sue for HIPAA violations there is no private cause of action, you can file a complaint with the government and they will investigate/prosecute as needed
That used to be the belief. It has been determined inaccurate/incomplete and private suits for HIPAA violations have been successful http://thehealthcareblog.com/blog/2013/09/06/a-new-way-to-sue-health-care-professionals-using-hipaa/
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.
http://www.allscripts.com/
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]
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."
V9733Xa: sucked into jet engine, initial encounter. There is an additional code if it happens again.
V9027XA: This is the initial encounter for "drowning and submersion due to falling or jumping from burning water-skis."
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.