Not all geothermal systems are closed loop. I have an open-loop geothermal system at my house on Cape Cod, MA. It uses the same water pump I use for my domestic water, runs it through the heat pump, and discharges back to the aquifer via another well drilled exclusively for this purpose.
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.
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.
I just want to second this comment. Focus on solving problems no matter what the technology is. Also, HN talks a lot about web apps, as if they are the only apps out there. Don't get me wrong, I prefer writing software for the web, but there is a surprisingly high number of people who don't feel the same way and would rather use Excel or FileMaker or whatever to get the job done.
This article makes it much more complicated than it needs to be. It tries to be all things to all people. In practice you're going to have to sacrifice some functionality for the sake of usability and your own sanity.
When I add a CSV import feature to a project I'm working on, I tell people "this works with MS Excel flavor of CSV." This covers most, if not all, real world cases because in my world the people who want to import data are non-programmer types who all use Excel.
I'll often include the basic rules in the screen that accepts the import. If I ever had to accept data from something that was _not_ Excel I'd probably include a combo box on the web form that lets you pick the dialect. So far I haven't had to do that.
The only thing I might not be totally covering is how Excel handles newlines, but in practice I've never had to deal with that.
If all you care about is Excel compatibility you can add "sep=," on the first line. You can also use the Text Import Wizard. Changing the extension to .txt should cause Excel to show the Wizard upon opening the file.
What is wrong with trying to be all things to all people? If you use a good solid library you don't need to tell people "this works with some versions of MS Excel" And that is the main point of the article.
