Today, after a looooong weekend driving around the country, I was cruising around, back to my usual, when I came across this
at EMR and HIPAA. The
article details the hubbub around the new FHIR (they pronounce it "FIRE" I think "FEAR" is far more appropriate) standards. Basically, FHIR is a web
service that allows the remote user to log in and add/update/delete medical information.
You know there is a ‘but' coming. Yes, but
where is the data housed? Who writes the application, the web service, to manage the data? What
kind of security does it have? We'll discuss those in a second, but first, let's dig into who came up with this.
More than a decade ago, the now defunct LivingWell Health Solutions, that I worked for, was looking for a way to import medical information. The protocol
of the day was called HL7. They were going to buy a tool called Iguana
$20,000 to get five channels
of data. Don't ask what a channel is, it's just more of the HL7 "standard's" stupidity. To read medical data
you had to buy an amazingly expensive product. So I went looking at the HL7 standard. You have got to be kidding me. The "standard" mixes several types
of data in one file and just ships it off in a pipe delimited format. Each line in the file has an identifier as to what type of data is in the line, then
you just hve to know what data elements each of the delimited elements maps to. If you've had any exposure to database design, this is just insane, but at
least we see why Iguana's data transfer application is/was so expensive. Sentia's Information Integrator was modified at that time to handle this
"standard" because we were forced to. The rest of the world, even a decade ago, was using XML (look it up) and doing just fine, but this
organization came up with this amazingly stupid set of rule for this one subset of data
transfer. The mind boggles at not only the stupidity, but the arrogance.
Flash forward to 2016 and this same organization brings us FHIR. I'm going to go ahead and pronounce if FEAR. I have some questions about FHIR. First,
who writes it and in what language? Web services are supposed to be like an egg. You don't know how eggs are produced, you don't know what eggs are going
to be used for. You need an egg you go to the chicken and get one. Who builds the chicken though? Down the line, someone may boil it for egg salad or
scramble it for breakfast. Heck they may even keep it warm and make a new chicken. You don't care. This is good, but this web service is going to be
brought to you by the same people who bring you the current crop of stupendously expensive, astoundingly difficult to maintain and use EMR software like
Cerner and Epic. These are the same people that can't do something that our new insurance company is giving away for free. (if that sentence didn't make
sense, go read the previous blogs)
First and foremost, if you are going to write a new application for add/update/delete functionality, it's going to be onesies and twosies. That means that
people are going to be typing in searches and getting back a list of results, not a wholesale transfer of data. If that is that case, put a user interface
on it and let them do the typing, instead of hiring a programmer, designing and building an interface, testing, rewriting, retesting, buying servers, buying
bandwidth, deploying this new application and THEN
having them type searches and get results using this dumb web service.
Who writes this new web service? Who hosts this new web service? How is security managed? Nope, this is going to be an unmitigated train wreck.
The better way to do it, and we Sentia have meetings scheduled to discuss this very topic with five major hospitals/hospital systems in North Carolina, is
to let the data reside where it sits and transfer the changes only to a new format (in our EMR of course) that has an interface for looking up and viewing
data. That way, whatever system your hospital uses, we just install one little desktop box to transfer your data to our EMR. Securely. All the pices are
already built and deployed. We will probably even supply the desktop. This isn't the new insurance company we have been talking about, but it is a start,
and a step toward it. This isn't a mandate. This isn't a new protocol or standard. We have already done the work in the best way possible without having
a bunch of rules and regulations that everyone ignores anyway. Actually doing the work