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