> I hope you like XML documents, flat files, pipes and hats, SOAP, and even CORBA.
Completely true. But that's not really the problem. You can download an HL7 or XML-parsing library and the dirtiness of the representation is converted to JSON or whatever works for you.
The problem is API loopholes.
HL7 does a pretty fair job defining what concepts get put into which fields. However, many implementations ignore the computer-readable fields and literally dump everything as 80-character human-readable console outputs in the "custom text" fields. Want any structured data? You're gonna have to write a text parser specific to the hospital's legacy console systems.
There's also a good deal of standardization over how things SHOULD be presented (ICD-9 etc), but those are ignored. Often times physicians or pharmacists just type the drug into a free-text box. 5 different spellings of Ampicillin are the least of your worries -- it gets bad when the dosage is mixed in with the name, and it gets worse once you get into compounds or mixes. The standard isn't the problem, its the data mapping problem for all the human-inputs.
And then you get into fun stuff where billing people use different codes than everyone else for the same drugs, procedures, admissions, etc (there's a reason billing admins are so highly paid... it's a black art where you get creative how you describe things to the insurance companies).
All of this is to say that I would love to see a RESTful, well-modelled API over HL7 messages, but the problems go far deeper than the protocol spec (and that's just for technical side of things... the politics and business threats of open APIs that the article talks about are completely true as well). It's been a couple of years since I've been in the space and not at all familiar with these new FHIR specs, but I wish that process all the best. If you're looking for a real challenge, it's not picking up Clojure or whatever is the language du jour... a true challenge is doing anything in healthcare.
The data mapping problem's what we're running into as well, and we're just trying to consume a tiny fraction of what's in the EMR for a patient (specifically, we're trying to get medication data into the backend for a service that does some pretty neat patient-specific stuff based on that data).
The service we're interacting with has all the structure we need, but doctors and nurses aren't data entry specialists: for the most part, they seem to ignore all the structured fields that they're given and encode all the information ("Ampicillin 5mg three times daily") as free text in the medication's "Description" field.
The problem's not in the protocol spec here (at least, not for our application). The problem's more a human factors issue-- how do you get the clinics' staff to provide you with the clean, structured data that you actually need? Needs to be something that's lower-impedance than just entering a prescription as plain-text (or they'll continue to circumvent your system), and it needs to require minimal retraining or you're going to get push-back from the staff who are expected to use it.
If convincing people to use a more structured UI is difficult but they're quite happy giving you all the information you need in their own way, why not just accept the data in the format that they want to give it to you in? It seems like a pretty simple NLP problem - you've got a known set of drug names and contractions, a set of timing intervals and a set of dosages. If they're not bothering to provide some of that information that might be an issue (depending on how well you can rigorously determine and encode the context-specific assumptions that they're making), but if they are providing it all to you like that then parsing your clean data out of the text can be done with extremely high accuracy. Potentially higher than the accuracy of a doctor picking from a set of dropdowns, before anyone says "extremely high isn't good enough for healthcare".
I'm sure it's an avenue you've explored - what's been the major challenge?
It's a statement that comes from knowing a lot about the tools and not a lot about the area in which you're applying them. That applies to a lot of startups, rarely the successful ones, and in this instance it certainly applies to me, and probably most of the readers of this thread.
The purpose of the comment is to offer up the strawman solution so that we can hear more about the interesting part of the problem that means it isn't trivial.
That's interesting since e-prescribing through Surescripts requires what's known as a "Discrete Sig", i.e some measurable type of dose, whenever possible. I know of one major health system that still does things the "old way", but discrete sigs are pretty common in 2015 (at least amongst Epic customers).
One problem with most pharmacy dictionaries (e.g. First DataBank) is that it's optimized for pharmacists, not physicians. The docs want to say "give ${x} units of substance ${y}" but they can't do that because their lists are all in dosage forms. Something as simple as tylenol comes in a dizzying array of varieties and often those are presented directly to the user. You can mitigate this problem somewhat by building favorites but the minute the doc wants to order something unconventional they get sucked into the medication cattle shoot again.
You're defining "unconventional" from the point of view of the pharmacist. The doc's would say the pharmacist is being too restrictive.
I think the previous comment had it closer:
> but doctors and nurses aren't data entry specialists: for the most part, they... encode all the information ("Ampicillin 5mg three times daily") as free text in the medication's "Description" field.
When I worked in the field, the user interviews we did said that basically that doctors don't have time to flip through all the menus and dropdowns. Part of it is the ego that comes with a decade of med school, but part of it is that it IS legitimately faster to scrawl "Ampicillin 5mg three times daily" (or some days "5mg Amp 3x daily") on a piece of paper and move on to the next crisis.
This is the part of medicine that could benefit from the silicon valley consumer-centric design mentality. It's not that hard to build something prettier than the average piece of enterprise software. The real test is can your responsive and reactive UI make something that has the accuracy benefits of being electronic while still faster than scrawling "5mg Amp 3x daily" on paper so your user can move on to the next patient.
I am defining "unconventional" from the point of view of the physician...when compared with the common medications he/she prescribes. An outlier, in other words. Generally in a setting like the Emergency Department, which is where I developed products for 7 years, the docs only describe 20-30 meds 90% of the time. Other specialties, like pain medicine, are similar. For those we build a pre-selected set of favorite meds that they could just click.
The doc would say the pharmacist is not being restrictive enough because the doc has to wade through so many permutations of what is medically the same med, or has to sift through medication forms that he/she has no use for.
From the pharmacist's perspective I want a _complete_ database so I can record with very granular accuracy what the order was. Also, the pharmacy database has things like ingredients in it which it factors into allergy and interaction checking.
I agree with your other points, though. Free text entry is faster - especially if you have voice recognition.
The way to design med lookups, in my opinion, is to have a dropdown for the pharmaceutical substance the physician wants, then the dose, then an optional drop-down for the form (tab, injection, suppository, whatever).
A suitable medication form would need to be found between what's medically indicated, what the pharmacist is okay with, and what the hospital has in stock - ideally in a dispensing machine at the point of care.
Agreed, am in the space now trying to isolate the seemingly malicious systemic backwardness from our product logic.
Honestly, I think the best thing to do would be to get a whole shitton of venture capital and start opening brand new hospitals with modern workflows and policies designed to optimize data entry and acquisition.
Bolting that onto institutions with the most amazing sorts of data denormalization possible is kinda painful.
To answer your first question: "Hey, new doctors (or fed up old doctors, are you sick of pulling long hours? Shitty bosses? Political bullshit? Come work here."
Having nurses pull double or triple shifts, having doctors answering their phones at all hours--just because they do it now doesn't mean that that is a good state of affairs. In fact, that's a sign of really shitty management.
To answer your implied second question:
Do you have any idea how many patients are harmed or lost every year because of operational errors? Bad procedures, bad diagnoses, bad drug administrations? All under the existing system?
You realize that, in many cases, hospitals can't even tell you what bed a particular patient is in with a high degree of certainty? Or when, exactly, medications were administered?
"Those policies may lead to patient deaths" is FUD, coming from a place ignorant of operational issues in hospitals today.
Maybe a find-as-you-type/autocomplete search engine running on a free text field would help. Doctors have to type less, and the software would display a giant confirmation of the parsed medication name, dosage, and schedule for them to confirm (instead of the software guessing later).
That depends heavily on what kind of HL7 you're receiving.
A formal grammar to describe the HL7 2.x pipehat format does not exist because there are irreconcilable ambiguities in the definition of the format. (It's something like: "it's impossible to tell the difference between FOO-1.1.2 and FOO-1.1[1]" BUT, that's not it. Sorry, I don't have the details.)
That being said... There are parsers for specific message types. An ADTA08 is defined well enough, you know?
Couldn't agree more. A middleware layer that exposes something like FIHR would be great but there systemic issues within this generation of EHRs that need to be sorted out too. The EHR must be more than the billing tool it is now.
So very correct. I've solved the problem but, unfortunately there is no way to graft it on to current solutions. There is no way to take data from an inherently low resolution, poorly modeled system and turn it reliably into complete, well modeled data with standard terminology codes. You need to use a new system.
Try convincing anyone of that after a painful, multi-year, billion dollar Epic installation
Though CGI did stall the process by suing the project in Market Court, claiming Epic has gotten more favorable treatment. Incidentally, CGI is the provider of the current system, which is reviled, costs 45 million a year to maintain:
I can't tell from the article, is this an Epic installation? I don't know the detailed breakdowns but as I understand it, the bulk of the costs have to do with consultants, reengineering process and training than software licenses.
My solution involves a system which allows you to create clinical data entry forms to document your encounters. All the information goes in as well modeled data with standard terms applied. It is not a complete EMR. I doubt it would require 100s million euros but it would do all the stuff a proper EMR does either. The problem is convincing people who spent so much on an all in one solution to do best of breed for one component
ICD-10 is better. Spelling isn't an issue as much as the hundreds of different NDC codes for each drug and strength.
I worked at a pharmacy company trying to make consultant pharmacist reports to help flag drug interactions that will happen if someone has a diagnosis (ICD-9 at the time) that flags a side effect or condition.
Doing this meant a ton of data normalization on med names and NDCs. Pretty cool shit until our idiot parent company shut our office. Good old bean counters.
"SMART on FHIR takes advantage of a new and powerful set of health data standards called Fast Healthcare Interoperability Resources, or FHIR. By using HL7’s FHIR for the clinical data layer, SMART offers a standards-based platform with broad reach, a rich set of detailed models, and the opportunity to create population-level as well as patient-level apps. SMART on FHIR also uses an updated set of authorization and authentication standards including OAuth2 and OpenID Connect."
Just wanted to chime in here -- I'm the architect for SMART Platforms and happy to answer any questions. Over the past five years I've gotten much more deeply involved the healthcare standards development world than I ever would have imagined. I came at this space from the perspective of wanting to build applications that plug into real-world systems, but in some ways I've been digging lower and lower down the stack trying to lay firm groundwork. There's constant tension between laying groundwork and trying to get "real" work done.
Do you think that there's any chance of getting interop via FHIR (with or without SMART) as a condition of winning the DHMSM deal? My impression (rightly or wrongly) is that a lot of vendors are doing a lip service/wait-and-see approach to FHIR and truly opening up.
I'd like to hope so. I think we've seen this kind of interaction play out on a much smaller scale in the commercial world, and we're seeing more of it. For example, when Intermountain Healthcare selected a Cerner EHR, they did so as part of a multi-year partnership [1], under the condition that Cerner would provide open interfaces to their EHR data so that Intermountain could continue developing (and begin porting their existing) home-grown decision support tools. Part of the arrangement was an innovation fund to support development of the specifications needed. And I think that's actually a great pattern, since we certainly won't have all the answers right out of the gate. With respect to DHMSM, the timeline is long enough that it's very hard to name relevant technologies on the way in, without the concern that they'll be out of date (or at least out of fashion) by the time implementation hits.
The one big problem I see with healthcare information is red tape. Independent developers and small shops do not have the resources to deal with lots of red tape. We saw with the recent VAT changes in Europe that it's really hard for anyone who isn't an enterprise company to deal with lots of regulation.
Before we start talking APIs, I want to know the hoops I'm going to have to jump through before I even git init.
I think FHIR only helps this process if it standardizes/centralizes security. So much of the process of setting up integration is getting whitelisted by an organization and setting up VPNs and other security measures that have nothing to do with HL7 or FHIR or IHE profiles. If startups have to establish credibility and integrity at each hospital they go to, the cycle will continue even with a public API.
There are companies that help with this. Aptible, TrueVault, Accountable, etc. -- the market in healthcare is worth working with partners to get past the regulatory hurdles that various governing bodies impose on ingenuity. As someone about to go start practicing medicine with a background in computing and looking at how humans interact with machines, I hope there's devs out there in places like this who will take on the challenges and make my life easier and my patients' lives longer/better.
Except a huge reason they refuse to conform to standards is because you are asking them to do a lot of extra work for no extra pay. The EMR systems, by and large, are not good. The user interfaces do not make it easy to conform to standards. It is not reasonable to expect docs to do it under those circumstances.
When I say "they" I don't mean the doctors, I mean the hospital administration. They operate on a different set of incentives and motivating factors. The doctors are usually not involved in the process in a very substantive way. It's this fundamental disconnect, which is so common in enterprise software, that's brought us to where we are today.
I know people on HN have fire in their breast to change the world but the rock is harder to move then many think. I tried to do it for almost 5 years and didn't get very far.
You need to motivate them where it counts, the almighty $. I want to add I'm not saying this sarcastically at all. The motivation of hospital administration comes down to a bunch of numbers on paper. If you can _prove_ that they will have _significant_ gains by implementing one of these standards they will move. However, most of them have been around long enough to see the standards come and go and are aware that HL7v2 is still in use 99% of the time. To them it is truly a case of, "If it ain't broke, don't waste the money fixing it." My hope is that FHIR and its approach to solving the problem of a bloated unwieldy standard with extensions will gain ground. If hospital administrations can be convinced to implement a simpler and cheaper standard to start, which has the potential for extension in the long-term. It will go over far better than the current approach of, "We'll implement this new standard for you that will take nearly 2 years, cause budget overruns, and never really see adoption." (The only people that end up benefiting are the consultants implementing the spec.)
Additionally, there's still an emotional component of "You're not getting our data because we don't trust you know how to secure it properly." From the personal experience of having worked with the IT staff at various medical institutions there is often a level of paranoia around their data. Which, in some regards is fully justified given the regulations (HIPPA, HITECH, etc) they are required to meet. The issue is that it often moves beyond meeting the regulations into a place of attempting to exceed the regulations. Which, seems like a smart move until it is too late and you've only succeeded in adding extra bureaucracy into your internal processes. These added burdens are then foisted upon external parties who are attempting to integrate with the system and therefore, by the nature of the regulations, the processes which have been previously set forth by the implementing institution.
All of that said, I agree with your statement, "I know people on HN have fire in their breast to change the world but the rock is harder to move then many think.". However my take is that we are attempting to move the wrong rock. Healthcare institutions need to learn the correct way to introduce and enforce secure yet flexible processes and policies in regards to technology. After that occurs then the technology rock will be much easier to move.
I'm going to add that I've been a Medical Software Engineer for just shy of 10 years and it has been both an extremely frustrating and also extremely rewarding ride.
This article totally misses the mark. The MPH and non-technical Health IT folks get super excited over FHIR, but its probably DOA. Its been mired in committee for years and makes a ton of compromises. If you look at the demo code, it isn't terrible per se[1], but ordering back to the EHR through FHIR is locked into order sets. Order sets for those not in the industry amount to pre set lists of procedure/medication/whatever orders defined on a per hospital basis. Trying to order a specific thing off order set for an individual patient is a be messier.
And honestly, the APIs at Allscripts, EPIC, et al are getting a lot better. The APIs avoid a lot of the free text nonsense that floatrock mentioned. They aren't great, especially around allergies and immunizations, but I think they have legs.
you’ll probably be integrating with a 70’s-era MUMPs-based EMR system, which will be expensive, painful, and slow
The funny thing is, if you study MUMPS even briefly, you will be struck a weird sense of deja vu... It's what we call "NoSQL" now. And it was superseded by RDBMS in the 80's for a reason.
They were going to switch my local hospital to a MUMPS system for something like 27m (or was it 127m, I forget). I looked at the technology and almost cried.
Fortunately they fired that CIO (who literally knew nothing about computers or IT, but hey, the committee appointed him).
If you live outside the US, InterSystems is rapidly getting EMR/EHR contracts with their InterSystems HealthShare® system. I haven't heard how much it uses FHIR, but find it likely that if there is a market that it will become a part of solutions available to purchase.
I knew even before I clicked the link that it would be discussing e-health records :) I worked with them in a small division of McKesson (RelayHealth) a few summers ago as an intern and the company was described to me as "the biggest company no one's ever heard of." Hope there's finally some agreement on the format and information sharing takes off so we can focus on the important things! So much of my work today seems to involve data munging that I'm starting to wonder if this is all a career in data science really has to offer.
Sadly, I don't see this happening without the government making it a requirement that EMR adopt the standard. The resilience to change in healthcare is unimaginable.
Maybe that's because we (software engineers) are not providing them value?
As far as I can tell, the EMR system my surgeons & doctors use is solely a hindrance to his workflow as compared to paper charts. I'm sure it's easier for the people/computers processing paperwork and billing on the backend, but for the doctors and nurses in the room all I've heard so far are complaints. From my observation, the UI/UX of the whole thing is terrible. I'm actually embarrassed by it as a member of the profession.
Sadly, the EMR is not made for your surgeons - it is made for the people doing billing. EMRs are good at capturing the data that is needed to get as many dollars as possible from insurance companies. It is only recently that quality of care metrics have had any impact on billing (Gross oversimplification - Under the ACA Medi[care/caid] payments can be limited for low quality care).
Prior to the ACA the increased costs of making good EMR workflows for providers was a net negative from a hospital revenue perspective.
This is super true. There's not a lot of proof of business models for healthcare IT outside of billing. If you try it you'll quickly learn that a practice or hospital's interaction with insurers is the most important one they have.
I don't know if this is true. Epic has already implemented large parts of FHIR and Cerner has also committed to it as well. You can even play around with Epic's implementation on FHIR here: http://open.epic.com/Interface/FHIR. I'll admit. I was shocked when I found out it connected to a real Interconnect engine.
This makes a lot of sense. IHE profiles and CCDAs are suboptimal ways in 2015 to transfer data between HIEs and Epic/Cerner/Allscripts along with every other EHR vendor either sell them or need to connect with them. It would behoove them to embrace this support in the same way it behooved hospitals to embrace HL7v2 in 1990: it saves them alot of work and money.
Of course, this doesn't help the average patient or app developer. How users will interact with these APIs and whether or not hospitals will have a standard and easy way to open them up is still yet to be seen. I imagine there will still be some work involved there, but I'm optimistic for the future.
> I hope you like XML documents, flat files, pipes and hats, SOAP, and even CORBA.
Completely true. But that's not really the problem. You can download an HL7 or XML-parsing library and the dirtiness of the representation is converted to JSON or whatever works for you.
The problem is API loopholes.
HL7 does a pretty fair job defining what concepts get put into which fields. However, many implementations ignore the computer-readable fields and literally dump everything as 80-character human-readable console outputs in the "custom text" fields. Want any structured data? You're gonna have to write a text parser specific to the hospital's legacy console systems.
There's also a good deal of standardization over how things SHOULD be presented (ICD-9 etc), but those are ignored. Often times physicians or pharmacists just type the drug into a free-text box. 5 different spellings of Ampicillin are the least of your worries -- it gets bad when the dosage is mixed in with the name, and it gets worse once you get into compounds or mixes. The standard isn't the problem, its the data mapping problem for all the human-inputs.
And then you get into fun stuff where billing people use different codes than everyone else for the same drugs, procedures, admissions, etc (there's a reason billing admins are so highly paid... it's a black art where you get creative how you describe things to the insurance companies).
All of this is to say that I would love to see a RESTful, well-modelled API over HL7 messages, but the problems go far deeper than the protocol spec (and that's just for technical side of things... the politics and business threats of open APIs that the article talks about are completely true as well). It's been a couple of years since I've been in the space and not at all familiar with these new FHIR specs, but I wish that process all the best. If you're looking for a real challenge, it's not picking up Clojure or whatever is the language du jour... a true challenge is doing anything in healthcare.