Comment by floatrock | Hacker News Reader

Comment by floatrock | Hacker News Reader

ah HL7.

> 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.

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.

And you would get your trained staff from where ?

"policies designed to optimize data entry and acquisition"

Those policies may lead to patient deaths. But hey, I guess that you don't have to worry about that...

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.

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).

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 seems like a pretty simple problem" is why the startup community makes more or less zero headway against enterprise problems.

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.

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).

> You can download an HL7 or XML-parsing library

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.

A lot of the problems you describe sound exactly what I've encountered when dealing with DICOM, the "standard" for medical imaging data.

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

Please, do elaborate.

This is currently happening in Finland's capital region: http://www.helsinkitimes.fi/finland/finland-news/domestic/12...

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:

http://www.helsinkitimes.fi/finland/finland-news/domestic/12...

Final tally for the new system is estimated to somewhere around half a billion euros.

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.

Reply on news.ycombinator.com