6 ms·

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 downl

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.

ddw 12y ago
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.
JonathonW 12y ago
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.
- seanwoods 12y ago
  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.
  - floatrock 12y ago
    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.
daveloyall 12y ago
> 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?
kohanz 12y ago
A lot of the problems you describe sound exactly what I've encountered when dealing with DICOM, the "standard" for medical imaging data.
gmarx 12y ago
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
- jarpineh 12y ago
  Please, do elaborate. This is currently happening in Finland's capital region: http://www.helsinkitimes.fi/finland/finland-news/domestic/12026-apotti-a-patient-data-system-that-costs-more-than-a-children-s-hospital.html 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/12026-apotti-a-patient-data-system-that-costs-more-than-a-children-s-hospital.html http://www.helsinkitimes.fi/finland/finland-news/domestic/12... Final tally for the new system is estimated to somewhere around half a billion euros.
  - gmarx 12y ago
    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
iolothebard 12y ago
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.

ddw 12y ago

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.

JonathonW 12y ago

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.

seanwoods 12y ago
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.
- floatrock 12y ago
  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.

daveloyall 12y ago

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

kohanz 12y ago

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

gmarx 12y ago

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

jarpineh 12y ago
Please, do elaborate. This is currently happening in Finland's capital region: http://www.helsinkitimes.fi/finland/finland-news/domestic/12026-apotti-a-patient-data-system-that-costs-more-than-a-children-s-hospital.html 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/12026-apotti-a-patient-data-system-that-costs-more-than-a-children-s-hospital.html http://www.helsinkitimes.fi/finland/finland-news/domestic/12... Final tally for the new system is estimated to somewhere around half a billion euros.
- gmarx 12y ago
  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

iolothebard 12y ago

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.