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.

Certification for the lack of certification

A big swing and a miss.

This is the second iteration of this blog post. I had originally written this and given the App developers involved the traditional "notify and wait to publicly disclose" that White Hat Hackers do. Note: I don't consider myself a hacker by any means. I scrapped the entire article and this is a rewrite.

Happtique created a bunch of buzz earlier this year by pushing the digital health industry to self regulate rather than be forced into regulation by the FDA, ONC, etc. A noble goal, I'd much rather have less regulation in the industry.

Happtique has now released their first class of certified mobile health products. They have certified 19 Apps for a variety of criteria, of which, security interests me the most.

Due to my background of developing secure software within the Department of Defense and various other government agencies and building mobile apps for healthcare, security is priority number one in my mind.

Mobile devices used by physicians and end users will hold an immense amount of ePHI. As often as cell phones are lost by the average consumer, logic dictates that a staggering amount of iPhone and Android phones have been lost by physicians - all that has varying levels of data protection of ePHI stored within the Apps.

I cannot find a single instance of a HIPAA data breach concerning lost cell phones. Lost laptops seem to be the hot item that is lost and triggers notification of a data breach. Either entities are ignoring these data breaches or they are ignorant of them.

Security

Happtique's certification sells itself as:

Happtique believes that in order for mobile health apps to be widely adopted into routine clinical practice and care management, healthcare providers and patients must have confidence in the apps they are using. Happtique developed HACP to help providers, patients, and others easily identify medical, health, and fitness apps that deliver credible content, contain safeguards for User data, and function as described.

I also brought up a host of issues I found with Happtique back earlier this year, communicated them with Happtique, and nothing has seemingly been fixed.

On December 2nd, Happtique announced its first series of Apps which they certified. I at random picked MyNetDiary's Diabetes Tracker

I installed the App on a jailbroken iPhone, which allows me to pull data off of the iPhone and see what I can find.

Case #1

I found two startling things: my username and password where stored in plain text, in a flat text file. The next was all the information I entered into the App was also stored in plain text, in a series of files that had JSON content.

Today I dug into the App again to see what else I could find. I wanted to validate to see if the App was subject to a man in the middle attack (MITM).

Man in the middle attacks are where a nefarious source intercepts your communication from the App to the server. They decrypt the SSL connection, pull out your data, and send the data on to the server. When data comes back, it is decrypted by whomever is doing the MITM attack, re-encrypted and returned to the requesting App. Example: When you walk into Starbucks and connect to an open WiFi connection, a nefarious agent could have setup a fake WiFi hub and can steal all of your data.

To my horror, this App that allows you to input glucose levels, was sending information to the server over HTTP, they didn't even use HTTPS. This means, user glucose readings are stored, sent, all in plain text. This means anyone could steal the data, by either stealing your phone or hijacking your WiFi connection.

I reached out to MyNetDiary on the 2nd and then reached out to them on Twitter a bit later. I haven't heard a single peep from them.

Case #2

Next on Dec 6th, I picked TactioHealth5. I performed the same series of tests on their Apps.

TactioHealth5 also stored username and password in plain text. There was one differentiator, TactioHealth5 stored their information in the iPhone Keychain. But: they debug logged the username and password to a plain text password in the file system.

Update 12/11/2013: Looking over the files again, Tactio stores the password in the keychain, but it also saves it in plain text to a plist file in the App Preferences. Password is still written out to a log file.

All of the user ePHI which was entered was stored in an unencrypted, in plain text, in an SQLite database.

Today I also performed the MITM attack on the App. TactioHealth5 is open to a MITM attack (They do use HTTPS), they send their username and password in plain text to the server to validate the user.

I also reached out to Tactio to inform them of these issues. I heard nothing back from them. I also ran into them at the mHealthSummit in DC and asked them why no one got back to me. Tactio's representative informed me that (summarizing) "The version in the App Store isn't the one certified and they are fixing some issues in January."

I call shenanigans on that, because Happtique's registry certifies version 5.0 as being the valid certified version of TactioHealth5, TactioHealth5 is currently on 5.1. So, why would TactioHealth5 have added logging of credentials, adding the MITM attack, and stored data in unencrypted formats?

The issues

Passwords

The password and username are in plain text. They failed to even provide hashing or encryption server side for the credentials.

The Keychain

In iOS, the keychain is the "safe" place to store data. It encrypts it with AES-256 encryption based on the user PIN. The issue with the keychain is, it is only as safe as the PIN the user enters into the phone. It takes around 20 minutes to brute force crack the PIN on the iPhone, meaning you can derive all the data from the users keychain.

SQLite

SQLite should be the file storage format of choice. Developers can leverage SQLCipher to provide AES-256 encryption for the data at rest. Generally, Apps force the user enter a PIN within the App every time they access the App.

Jailbreak detection

Apps should leverage jailbreak detection to prevent Apps from running on exploited devices, ever.

MITM attacks

Preventing MITM attacks requires a bit of work. There isn't a terribly easy way to do it, but generally it requires leveraging SSL Pinning to validate the SSL certificate returned by the server.

Disappointment 

I changed my mind about waiting to publicly disclose these issues. The fact neither company has reached out to me and Tactio decides to tell me what seems to be nothing more than misinformation - means to me neither company cares.

I'll be very clear: this is a warning to anyone developing mobile products. If someone writes you to say "Hey I found some vulnerabilities within your product" - you contact them as soon as you read the email. Everyone will make mistakes, it is just the way development is. It is how you mitigate those issues that matters.

Both of these products are collecting ePHI, MyNetDiary advertises 2.7 million users. That is quite a bit of vulnerable ePHI sitting on many mobile devices.

Happtique

Now we get to the bigger issue, Happtique. Happtique farms out the validation of the actual software to Intertek.

I cannot comprehend how both Happtique and Intertek failed to catch these litany of issues present in both products. Storing plain text passwords is unreal. Storing unencrypted ePHI is crazy. Sending ePHI over HTTP is inexcusable.

I had met and talked to Happtique's CEO this week at mHealth, but that was before I discovered the HTTP communication issue.

The industry, consumers, and anyone putting stock in Happtique's certification should understand these issues.

Happtique can and I am sure will try to correct these issues, but for the life of me - how did anyone miss such massive security holes? These aren't just things you miss.

Certifying your product so you can have a shiny sticker that says you are certified, is the worst possible reason to go through certification. Certification should mean something. Hasn't HIT learned enough from EHR certification?

Health IT doesn't need yet another entity siphoning off money and providing nothing in return for the investment. There is enough of that already.

I wouldn't put a single App I have developed through their certification process at this point.


Update 12/11/2013:
Files from the MyNetDiary App
Files from TactioHealth5