Not so quick on iOS 3rd party keyboards, Docs.

Playing around with iOS 8 I was going to install SwiftKey. But, ran into an issue with the warning to install the keyboard - they collect every key you type. This creates quite a conundrum for those in the healthcare world.

Why? Simply put you don't have a BAA in place with SwiftKey, nor do you know if their infrastructure is HIPAA/HITECH compliant.

So, while I assume SwiftKey is on the up and up, you simply must avoid it if you are in any type of field that requires any type of compliance.

It's the doctors, silly

There was a lot of hand wringing this week over the delay of ICD10 by Congress. People upset that in its infinite wisdom, Congress did something it didn't fully understand - again.

Interesting was the reaction. Dozens of groups and industry organizations yelled from the rooftops how terrible of an idea it was the Congress delayed ICD10 till 2015. CIOs, consultants, policy wonks, vendors, all screaming mad at Congress.

But, there was one noticeable group that didn't seem to care: providers.

Note: I do feel bad about coders who have shelled out good money on their own to get training and will probably have to do so again, that's a load of bs.

The men and women on the front lines that I've spoken either didn't care or were happy. Now, I'll submit anecdotal evidence is a poor metric, but none of the reported stories over the anger of the delay seemed to quote any providers.

This is the problem with Health Information Technology.

Traditional HIT doesn't seem to be focusing on what can improve the lives of the people on the battle field. Adding more work to the providers day is just a consequence. Disrupting their ability to actually get work done, means little - deal with it.

This disturbs me greatly.

Many reasons why... Coming from a development and architecture perspective, it is insane that information technology should make someones life MORE difficult and have preposterous costs associated along with it.

IT should reduce costs and reduce time. Meaningful Use's impact on EHR has been to create more time wasted sitting in front of a computer for providers. ICD10 means more time for docs to be looking for the right code - all so if they choose the wrong one their payment gets denied.

But what does that all cost? It means that when a doctor is visiting a patient, they spend less time interacting with the patient and more with their computer. It means they are doing more work at the computer after a patient leaves.

All of this means a provider interacts with less patients every single day. We face a world of less doctors - why on Earth is giving them less time a benefit?

The issue here is, ICD10 has a big problem. Providers see it as nothing more than a cost center, a means for payers to deny claims, and more work.

No one has articulated (if they have they have done a terrible job) to providers why ICD10 will benefit them. Everything seems to center around "it will produce better data!" - but if your job is to triage issues in front of you, why would you care about producing better data at the point of care?

Sure, maybe a year later that data point may help solve something, but lets be honest - we humans are greedy animals. There is no immediate payoff (even long term) to the provider caring for the patient when they see them.

For some reason, no one seems to get this issue. It is lost on everyone.

Imagine if someone came along and say "We are going to take off the backspace key from your keyboard, in the end it will be great!"

Sure, there are ways to go about deleting text. Holding the Shift key + the left or right keys highlights text and you can replace it with whatever you want.

But, that is cumbersome. That takes time. There isn't a ROI nor is there a give and take.

Perhaps if we focused on what could improve the day to day activities of the provider, we could improve the "health" of our healthcare system. As it stands now, we keep adding more to the plates of providers and we don't give them anything in return.

We give them more menial tasks, that means they see less patients, and make less money. Who does that benefit?

Personally, I wouldn't be happy either without my backspace key.

So, you want to build a website?

In order to explain the problems with Health Information Technology, let's say you want to build a website and you must do it how Health Information Systems do it.

You code up your website with your favorite text editor and code up your website. You already know HTML so that isn't an issue. But now, you need to host it, upload it, etc.

First things first. You need to write a web server. Wait what? Well, HIT doesn't give you anything for free. So, you must now read the IETF standard for TCP/IP. You spend hours reading over it. Bizarre details which no human should ever care about. After hours, you finally have a grasp on how to serve up simple HTML web pages to anyone making a request to your web server.

But, TCP/IP isn't enough, you need to read the HTTP standard, because depending on which HTTP request is made, you need to do something different.

But, now you've run into a problem. In HIT, every system communicates differently. So, each web browser makes requests differently. Not just with TCP/IP, but with HTTP. So, you start with Chrome since it is the top browser and figure out all the nuances. You must then go to Safari, IE, so on and so forth. You'll spend probably half a year just figuring this out.

Six months later, you have your web server up and running.

Now you need to upload your HTML pages. Well, that isn't easy. No FTP clients exist in this world. So, you no must read the IETF standard on FTP and develop your own FTP client. Since you know TCP/IP already, you may not need to read that spec again. So, you spend a month or so developing your own FTP client and finally get it working.

You have now uploaded your website!

But we have a new problem. No DNS servers exist. So, you go and get the IETF spec on DNS and pour over that. Another month of reading and developing, you have finally developed your own DNS server and people can finally start accessing your website.

Does that all sound crazy? Yes.

But that is how Health IT "works" right now.

How do we fix this?

What HIT misses completely is the fact that the rest of the software world revolves around APIs and SDKs. You don't have to reinvent the wheel every time you want to build a piece of software.

Healthcare Leadership, who have built the system the way it is can't seem to come to terms with the fact this isn't how the rest of the software world works.

Yes, there are major concerns over HIPAA, safety, etc. But, neither of those have anything to do with building out SDKs and APIs.

If I want to communicate with EPIC, I shouldn't be required to read through 1000 pages of proprietary HL7 standards (Which were only made "free" in the last year) and hope it works. If I then want to point that solution Cerner, I should have confidence it works.

The way HIT is now, even pointing to another instance of EPIC probably wouldn't even work.

This is entirely unacceptable.

We will not lower costs, improve care the way things are now. This is a tough issue to tackle, but it won't be solved with more standards and certifications. It will be solved by doing things how the rest of software does it.

Heath IT leadership still doesn't get it

I found this comment by Farzad Mostashari to be quite interesting - and telling of what is going on with Health Information Technology at the moment.

Truth be told, more useful to know 2014 cert standards "@ahier: Digital health APIs every health startup should know http://t.co/KreoMIEFgJ"
— Farzad Mostashari (@Farzad_MD) March 8, 2014

And, therein is the problem. Brian Ahier gets what developers and startups needs. APIs and SDKs. For the life if me, I cannot grasp why the former National Coordinator for Health Information Technology cannot see what is important to startups.

Certifications for an EHR?

Why on Earth would a startup care about that? If you are crazy enough and well funded enough to try and start an EHR from scratch in 2014, perhaps.

But, there is so much going on outside of the EHR world (lets call them EHR work arounds) to solve issues that policy has created within EHRs - that one would be remiss to read mundane details about what people sitting in offices in DC think EHR software needs.

HIT is bigger than EHR vendors.

I do find this all disappointing. This comes a week after Mostashari was at HIMSS and got to see all the technology startups are working on. How they are doing things differently.

If the guy that used to "run HIT" can't see - who can on that level?

Watch out, horse and carriage makers

At HIMSS this week, my business partner and I had lunch with a gentleman who, I guess you could say does things "the old way" which we do in a technology forward way. He has a successful business in medicine that probably will double in the next year.

Our goal was to talk with him about hopefully augmenting what they do and adding us on as a service.

Well, things didn't go so well.

He explained to use we'd go out of business, that we'd never make it, that we must make serious changes to our idea if we want to succeed.

All quite interesting since we are growing rapidly.

Simply warning to all you old vendors of health information and health information technology. 

There are a lot of us startups entering your space and they plan to steam roll you.

This isn't the 1890's where it took 30 years for cars to replace the horse and carriage.

mHealth and HIPAA breaches - where are they?

For the last few years we've seen dozens of HIPAA violations revolving around doctors and lost or stolen laptops. These laptops are either encrypted or unencrypted (more so than nought) that contain patient ePHI.

What we haven't seen, is a single reported HIPAA violation from a covered entity over a lost or stolen mobile device. If it has happened, I have missed it.

Context

Back in December I made news on this blog by showing how easy it was (30 seconds of work) to exploit "Certified" mobile health Apps. These were Apps that paid good money to be certified as one criteria of being "safe and secure" - protecting ePHI.

But with the slightest bit of handiwork I demonstrated what anyone with a computer could have done, I was able to pull off unencrypted ePHI - I was even able to do a man in the middle attack and pull out unencrypted traffic to a cloud server.

Why is this important?

So, even a "Certifying" entity failed to properly validate security within mobile Apps. A certifying entity that was marketing to hospitals as being the "Authority" on recommending mHealth software.

But let's step back and look at some figures.

It has been reported since 2010 that 80% of doctors are now using their mobile phones while seeing patients. If we take the pool of over 500,000 docs out there, that is some 400,000 mobile devices floating around that are being used while seeing patients.

What I haven't found is any information breaking up the actual usage of mobile phones during patient visits. For example, there is a big difference between using a mobile app that is a reference vs one that stores patient ePHI on it.

Though, I have seen a staggering number of physicians that get paged via SMS text message, which include patient ePHI in them... Again, eek.

But, we know for a fact that doctors are using SMS and MMS to communicate with one another. Patient information, pictures, all over unencrypted communication. Which is why we are seeing a surge in "Secure Messaging" products out there (I think half the booths at the mHealthSummit were secure messaging platforms). In reality, doctors are trying to solve a problem and I doubt most of them realize that SMS and MMS are terribly unsafe. Then again, medicine still use miserable fax machines to send ePHI over, so is SMS or MMS any worse? No.

What does this mean?

I'll admit this article is a bit self serving. I am an advisor/partner in a mobile health startup and we have invested a lot of time into building a product that is rather tough to hack.

Note: The concept of an "unhackable" product is a farce. Even the Department of Defense and three letter agencies know this. The idea is that you make your software so time consuming to hack the juice isn't worth the squeeze.

But, our investments in building the technology aren't self serving, they are what mobile health should be. If a doctor has his or her phone stolen, there should minimal risk anything could be compromised.

There are generally a few sets of people building and writing mobile health software at the moment. We have indie developers writing software, we have doctors learning how to program and writing software, there are large companies that are entering the mobile market.

What most of these people writing mHealth software lack is any formal understanding of building secure software. This is where the vulnerabilities are introduced. Security is hard, it is expensive, it isn't easy to tackle. For most, it seems like an afterthought. "The device takes care of it" is a preposterous line of thinking.

With all that in mind, lets get back to the figures...

A reported 4.3% of smart phones are lost a year according to McAfee. That means there are about 17,000 physician devices lost each and every single year. Why is that scary? It gets scary because 57% of devices have no security features enabled. No PIN lock, no passcode, no encryption.

So, it means that there are potentially over 9,000 unencrypted and unprotected mobile phones lost or stolen, every single year. Seeing as BYOD is in full swing (even though most lack decent BYOD policies), many docs aren't hospital employees themselves, the idea of business owned and managed smart phones isn't here really.

Are you scared yet? You should be. A doctor gets a laptop stolen out of his car and reports are filed (as they should be). A doctor has his smart phone stolen and he just goes and buys a new one and no one thinks differently.

What can be done?

First, hospitals should have strict BYOD policies in place. MDM policies should enforce strict password and encryption policies at a minimum. 

But, the issue goes deeper than just that. We are still in the Wild Wild West of mHealth. How do hospitals and doctors offices know any mHealth App off the App Store is safe and secure? Even I don't know a good answer for that. Certification so far has been a complete farce and failure.

With MDM you should be able to view which Apps physicians are using and gauge from that where your risks are.

We have taken the approach of documenting all of our security practices, mainly on the device in a white paper we give to any client that asks. Our goals are to keep ahead of the curve in adding new security features - but it is an ever evolving field. There are more gifted hackers trying to exploit things than there are people who can write good security software.

If you are a doctor, a hospital administrator, you need to start understanding what products are being used by you and your staff and validating internally if they are safe and secure. You are at risk and you don't even realize it.

Lost and stolen mobile devices are a major threat to patient ePHI and it is time people stopped brushing the issue under the rug.

When to disclose to the public?

With my blog post on the Happtique certification shortcomings, the inability to even validate personal health information is sent over unencrypted HTTP - I thought it would be beneficial to discuss when one should disclose security vulnerabilities.

In the past I have disclosed vulnerabilities which I have discovered privately and not peeped a word publicly. The entities involved responded in a timely manner and fixed the issues. This is great.

Once we hit collecting personal health information, I think this starts to become a problem.

I chose to publicly disclose after waiting 8 days in one instance and 3 in another.

Why? 

The first instance I contacted the developer and I heard nothing back from them. I dug deeper into their product and found they were sending information over unencrypted HTTP connections. In my mind, the combination of the fact that they refused to contact me with unencrypted HTTP communication meant the public had to know right away.

The second company, I notified and also heard nothing back. I met a representative of their company at the mHealthSummit yesterday. He all but blew me off when I brought up my concerns. He didn't ask for more information, he didn't ask for my contact info.

With that knowledge, I saw no reason to extend them the benefit of the doubt and assume they would fix the issue.

Reply to people

I'll repeat this again to all developers out there: When someone finds a hole in your product - email them or call them back immediately.

People disclosing exploits are looking to help you. Security isn't easy.

I would have afforded both companies the benefit of the doubt and let them fix the issues if they had made some effort to reach out to me - or had not made such gross security mishaps like not using HTTPS/SSL.