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

"HIT Startups suck"

Sort of a response to this article: http://histalk2.com/2013/10/20/monday-morning-update-102113/

Philosophical debates of healthcare IT (HIT) are always interesting. "Mr. H" had a long diatribe, cutting down and lumping all HIT startups into a single group of 30 year old, over confident, abrasive, swaggering, naive, etc. Now, I personally am not a fan of a bulk of startup culture that chases investment instead of actual customers.

So, I agree on the uselessness of many of those attributes. But, to lump everyone into that cookie cutter is quite dismissive.

Being [over] confident, though, is something you have to be to be launching any type of a startup, HIT or not. It takes a lot of gumption to quit a well paying job with a baby on the way, a house, a wife, and start something from scratch [yes this is me]. You must have the confidence you can do it, or else why would you risk it all?

Being humble is something more founders should embrace, my wife knows I hate talking about my accomplishments to anyone.

The state of HIT

In its current state, HIT is broken. EMR deployments are a pretty big indicator of where we stand. There are quite a few hospitals that are hemorrhaging cash deploying EMRs. Physicians by in large hate the EMR at the hospitals they work at. Find a doctor that is part of a group and visits multiple hospitals, he will be using a different EMR at every hospital he visits.

Best of all, none of the EMR systems actually communicate with each other, no matter what we've been promised by CCHIT and the governments free $44,000. Heck, doctors within the same hospital can't get patient records of their own patients.

Don't get me wrong, we need EMRs at hospitals. But, it is a fantastic indicator that the government 1) had to force them on medical institutions and 2) subsidize the purchase of them. Perhaps without #2, we'd actually have EMRs that people want to use and purchase out there, instead of the daily headaches that HIT staff and users have to deal with.

My own vision of IT is it should make the users life easier, make costs go down, and make the business case that it provides a ROI. This is not the case where we stand today.

Startups

But, back to startups in healthcare. There is a massive and distinct separation between what is going on. There are more consumer based digital health startups than you can shake a stick at. The market is flooded with them. But, the number of digital health startups focusing on the enterprise, is a very shallow pool of entries.

The reason for this goes a bit beyond what "Mr. H" claims.

The biggest of all, is compliance. HIPAA and HITECH are immense barriers to entry for those new to the market. Granted, they aren't big hurtles once you actually understand them and know how to properly mitigate them. From my point of view, HIPAA actually isn't all that useful since it is basically a minimum set of what you should do.

Next, are EMRs. Part of the EMR carrot stick was interoperability. Anyone who has done anything with HIT knows what a hilarious joke interoperability is.

With the same EMR issue comes HL7. Out of all things, HL7 has been the biggest headache of all. It is an immense standard that takes a special level of finesse to comprehend. The bigger issue with HL7 is, there really isn't a whole lot of information out there on it that someone in a startup can use to build their own hooks to EMRs. MIRTH is the de facto standard, but as their recent acquisition shows everyone should be looking for alternatives.

Note: I am not saying HL7 isn't useful, it is quite necessary. It is just a lot.

There are no easy to use APIs for HL7, which is the big issue. As a developer by trade, I am used to just dragging a reference library into a project, making a few calls, and being up and running. With HL7, you have to write your own parser. You have to dissect the message, you have to learn the difference between segments, repeating segments, and avoid bashing your face into a desk.

But then, lets assume you develop for yourself the best API out there for HL7 the world has seen. There is no guarantee that it will work from hospital to hospital. In fact, you should assume it won't, at all. This isn't a fault of HL7, it is a problem back to the EMR vendors.

Which, the cynic in me thinks is all by design. If the large EMR vendors can keep any and all competition out, what do they have to worry about as far as challenges?

HIT is fundamentally broken. So, when "Mr. H" talks about writing enterprise systems, there actually is no bar set to hurdle.

Barriers to entry

One of my favorite lines I've heard over and over is

"a low barrier to entry that virtually guarantees that any degree of success can quickly be replicated by competitors."

The author correctly states ideas are a dime a dozen, but it is execution that matters. I know exactly zero founders who are concerned about this.

If anything, it is welcomed because it forces you to push forward.

One more thing

if you are new to healthcare selling a product whose target customer is hospitals, it’s a near-certainty that you’re going to justifiably fail, with your only hope that a better company will buy yours before it splats to the ground. That’s not anti-innovation at work – it’s the reality that healthcare attracts a lot of flaky, poorly thought out startups that don’t deserve to succeed. Come back when you hit $1 million in annual revenue.

This piece is a bit much. The author's stream of conscious diatribe ends on an extremely negative tone. Instead of being a Debbie Downer and hoping for destruction of people pouring their lives into a company, you should offer actual advice to them.

The issue I have here is the two words "justifiably fail." Being new to HIT doesn't mean your idea is bad or you deserve to fail. You should fail only because you are new to the field? Please. That isn't anti-innovation, it is just vitriol.

Sure, the harsh reality is that it isn't easy. But if we want HIT to actually solve issues and make the lives of everyone using it easier, everyone needs to work together.

Yes, there are a lot of bad ideas out there [not just in health care] that deserve to fail. If we applied "Mr. H's" standards for startups to EMR vendors, it would be quite an empty field.

Enough complaining

"Mr. H" is correct about a few things though.

The enterprise sales cycle is quite long. It isn't as simple as buying a few Apps on the App Store and being up and running that instant (But, hint: physicians are doing this anyway and are violating HIPAA and BYOD policies which hospitals have put in place). I come from building secure systems at the Department of Defense and Department of State. A 18 month sales cycle, was considered pretty quick for anything other than a 30 person pilot.

Understanding HIT problems is another. Enterprise class issues that hospitals face aren't out there in the open. I am a silent partner in another HIT startup and the CEO is a physician. He has been an amazing help in getting me to understand the depths of the issues which face physicians and nurses on a daily basis.

As a note, our sales cycle with that product is short and long as it sells to individual physicians, groups, and hospitals. We've been chasing a few hospitals for the last 12 months and they are finally jumping on board. 

Who am I?

I am one of these 30 year old HIT startup founders. I earned my chops building highly secure enterprise systems for the Department of Defense and Department of State.

Since 2011 I've had two software acquisitions, I sold my first piece of mHealth software to Walgreens in 2011. In 2012, a piece of mobile security software I wrote was acquired by the the Canadian mobile security company Fixmo. Since 2009, I have been a silent partner of another mobile health startup that in the last year has gained crazy traction.

I don't give the "Steve Jobs" wannabes the time of day either, but those are few and far between. Or am I just hanging out in the right circles?

But, I have met a lot of great HIT startup folk the last year or two. To dismiss the lot of us because you've met a few immature brats, well, you'll be in for a surprise.

Trusted Partners, verify yourself.

I had submitted a talk for the mHealthSummit to discuss security for mobile health. Sadly the talk wasn't accepted. With that, I wanted to discuss the first point I was going to make: Validate your SaaS (Software as a Service).

I already had an account created to submit a talk, couldn't remember my password, so I performed a password reset request. mHealthSummit uses a third party tool, Precis Central http://www.preciscentral.com to collect presentations.

This is the email that arrived in my inbox after requesting the password.

I was flabbergasted - that in 2013 an organization was still saving passwords in plain text.

Let alone, a health care entity was leveraging a system which stored passwords in plain text. I emailed mHealthSummit and it looks as if they forwarded the issue along to Precis, as today I performed a password reset request and received a link to manually change my password.

Now, this doesn't mean that Precis is now storing passwords in an encrypted fashion. They could have very will "fixed the problem" of emails going out with plain text passwords. So, while seemingly one vulnerability was addressed, we have no idea if the underlying issue of storing plain text passwords was addressed.

Moral of this story is, you need to thoroughly vet any SaaS which you leverage. This is especially true if you are in the medical field.

I tried to buy an American car

When I was a kid, the 1996 Blue/White Viper was the car that got me into cars. When SRT debuted the 2013 Viper in 2012 at the auto show, I wanted one.

I put a deposit down Oct 2012 and an order the first day you could in November of 2012. I had never driven, let alone sat in a Viper before. I liked what I saw and I liked that CEO Ralph Gilles was a real car guy and passionate about his brand and it sold me.

Sad to say, last Monday I canceled my order. A few factors went into this.

Communication was perhaps the biggest problem. I fully understand that ramping up production on what was a 'dead' vehicle would have its issues. My dealer told me that I should have the car built in February and get it in March. Well, it is the end of May and VOTS, last I checked, was still production scheduled. I assume the car will be built mid June and in my driveway July, five months behind schedule. (Which, in reality is amusing coming from a software guy, complaining about delays).

A simple call from SRT explaining what was going on, would have helped a lot. Some communication from the factory, would have meant the world to myself and I assume others that placed orders. Even just an email saying "hey here is what is going on." 

More than anything, I got bored with waiting for the car to be built and delivered. I kept waiting and waiting, checking VOTS and seeing nothing happen. I lost the fun of the process. For a toy, losing excitement in it, before you get it, is a bad thing. The lack of communication fed my boredom, it became a vicious cycle. In reality, just waiting was the biggest factor in tossing in the towel. 

The real poke in the eye was seeing dealers getting custom spec cars, way before those that put deposits down to order custom spec cars. Now, I realize that there are factors into this - SRT can't possibly know that XYZ dealer ordered the car for themselves to sell or a customer ordered it. (Though, that is disputable because VOTS, Chryslers build tracker, showed my name in the order). Again, I realize there maybe legitimate reasons for this - but, being a selfish human being, I simply wanted mine.

Even more infuriating than that is seeing dealers get early custom spec vehicles, then dropping $150,000 markups on MSRP. An example is the terrible Dulles Motorcars in Virginia (local to me).

After seeing this, I'll never do business with Dulles Motorcars, ever. 

It is disheartening, because myself as a customer who put a deposit down, ordered, waited, gets to wait longer while this vehicle goes unsold and collects dust. Gen IV Vipers didn't sell all that great, perhaps these dealers that turned away customers through absolutely moronic pricing didn't help?

I wish SRT the best and hope these are growing pains. Maybe I'll look at them again next year. 

I hope Ralph reads this and takes the feedback. When Motortrend jumped over the Viper last year he took the bull by the horns. Having started businesses myself, feedback is important to success, which I wish the SRT team. 

Harold

Update:

Ralph Gilles contacted me almost instantly, asking me how he could get me excited again. As I told him, I think I'll jump back in the line in 2014. I fully understand why there are delays and custom spec cars take time, especially for new production.

We are still going to checkout a Jeep Grand Cherokee for my wife here soon, so the brand isn't dead to us! I think I am more disappointed in the dealers like Dulles than SRT itself. (Note, my dealer was fantastic through all of this).

It is great to see a CEO that cares about his product!

Quest Diagnostics billing department is a social engineering hack

In January, I had a tick embedded under my skin (gross). I went to the doctor, they removed it and sent it off to Quest to be tested.

Fast forward to last week, I get a call from "Invoice Services" which QD farms out to. Apparently Quest used a former address to send my bill to, which is odd because I recently switched insurance late last year and they never had that address... So, where did Quest get this address from?

Anyway, here is the issue, besides being terrible at sending bills.

I get a call from "Invoice Services" which is apparently a company located in India (not a collection agency) to get me to pay, to which I already did.

"Invoice Services" wants me to confirm my 1) full name 2) date of birth 3) address.

So an Indian based company calls me and wants me to verify my information? Please, that is preposterous. This is a text book social engineering hack used to gain valuable information from people.

Shame on you Quest Diagnostics and your terrible security practices. God knows how you are protecting my ePHI if you are so willing to send information off to India.

Back to jail

Jailbreaking iPhones and rooting Android phones is a fun, popular thing to do for mobile devices. You can extend the functionality of the device, customize, and do pretty much what you want.

It gives freedom to the user.

Woops

The issue here is, it also creates security vulnerabilities. Within the growing trend of Mobile Apps for healthcare, we are loading ePHI onto the mobile device. This can be extremely sensitive information which falls under HIPAA and HITECH.

Anyone who has read Hacking and Securing iOS Applications will instantly realize the problem.

A jailbroken/rooted device is wide open to security exploits. All the data can be seized, malware can be installed, key loggers can be installed, the secure keychain can be tapped. All of your data is open to a hacker.

If data is not software encrypted by a user derived key, if passwords and usernames aren't encrypted, if SSL certificates aren't pinned, you are wide open to exploitation. Further so, if your Apps run on jailbroken/rooted devices, anyone can write simple changes to the underlying OS code to exploit data at runtime.

In short: kill your mHealth Apps running on jailbroken devices - as soon as you can. If users are using jailbroken/rooted devices, leveraging HIPAA/HITECH as a reason for this policy is a simple "sell." It is in their best interest to not run mHealth Apps on rooted devices.

Time to hack medicine

CommonWell is a new "idea" being pushed by the six largest EHR vendors, sans Epic. The idea is "interoperability" - which is in itself a bit strange because one of the "certification" standards behind EHR certification was "interoperability." I use quotes on interoperability and certification for EHR, because as we know they are a complete joke.

Just no

The amusing part about CommonWell is, and by amusing I mean sad, the words "open" don't appear anywhere in the announcement. Open frameworks. Open standards. The word, does not exist.

What is being proposed is just another locked in, vendor specific standard which does not solve the issues in health care. Now that we are digitizing, we need to share data. Now, a vendor can store the data any which way they want. A flat file, relational database, MongoDB - but we must have open API access to interface with the data.

Any proposals or working groups that fail to create open standards is a failure from the start.

Real innovation

What sparked this blog post was reading this article about Phillips crazy expensive lightbulbs. $60 lightbulbs? Are you insane?

Well, maybe - but as with any technology, early adopters pay through the nose. Remember the first cell phones? $3995 for an hour of talk time. Now, you can get cell phones for free.

Back to Phillips

If you read through the Phillips article, you'll see what Phillips did. Well, they didn't do it at first, but someone figured out how to. Two people reverse engineered the API Phillips Hue lightbulbs and wrote their own Apps for Hue. Brilliant. 

Phillips caught on to this and has now decided to open up the API for developers - because - it drives adoption. Even more brilliant. 

So, here we are and we see the free market driving product development. Phillips realized "hey people want this" and delivered. 

EHR vendors, heavily subsidized by tax dollars shoved a product down the throats of doctors (who, didn't really care because hey it was free to them) - which now we realize was a bit of a "woops."

CommonWell talks the talk about interoperability - but they fail to start to address the real issues facing EHR. There are 300 plus vendors for EHR platforms. 300. If we want medical HealthIT to evolve, they ALL need to operate on the same, open standard.

Just imagine

Now, open your eyes to what we could actually accomplish if we had open standards for EHR. We could access data. We could perform analytics on patients. Patients could OWN their data. But instead, our health information, the most important information to our physical well being, is locked up in a proprietary database - which we ourselves paid for.

Imagine if the Silicon Valley innovator could build a product on top of the EHR to figure out who is the highest risk to develop diabetes. The highest risk to have a stroke. What if your taking of your Prevacid once a day was automatically sent back to your doctors EHR so he knew if you were being honest. 

The possibility is there and is real, only if CommonWell actually wants to improve health care.

And yes.

I realize Hue is a closed standard, but it is more to the point of the matter. Phillips realized the demand and adoption of their product could be heavily improved by providing open access to their product.

Hey, EHR vendors, take a hint.

What is Happtique's value proposition?

I'd like to start off this blog by saying - I don't find certification a bad thing. But, I think certification has to be a ROI for all parties involved. And if you read to the end, you'll see what I think about Happtique's standards.

Creating a certification program to simply have a certification program, is a false choice. Which is why, I am skeptical of Happtique at this point in time.

Over the last year Happtique has been building buzz around certification for mHealth Apps. They have enlisted the help of the Association of American Medical Colleges in reviewing content. Right before HIMSS 2013, they finally released their standards and pricing. Their pitch is:

The Happtique Health App Certification Program (HACP) is intended to help healthcare providers and consumers easily identify medical, health and fitness apps that deliver credible content, contain safeguards for user data and function as described.

From what myself and others seem to gather - Happtique is trying to position itself to be the commercial version of CCHIT for mHealth. Now, seeing how much of a disappointment EHRs have been (And to me, specifically with interoperability), that bar is quite low. Just take a gander of the #EHRBacklash  tag on Twitter. Anyone selling medical software will tell you the hesitancy of a doc to pickup a new piece of medical software and start using it.

Seemingly everyone on Twitter is falling over themselves about how great of an idea "certification" is for mHealth Apps. Which begs the question, is there such a problem out there with mHealth Apps that we need a certification program at this point? Are we "treating the patient" before there are any symptoms? Does getting a certification mean a piece of software is of any value?

I'd say, yes there is a need - but are we covering those bases?

There are two main issues I see with Happtique's certification process. The biggest I see at the moment is their pricing structure and the other is security. I also question the model, the Blue Ribbon Panel, and operability.

Show me the money

Happtique's website claims that each version (update) of an App needs to be certified and the certification cost is $2,500 - $3,000. (Which, oddly enough wasn't behind a paywall yesterday).

Now, the world I am familiar with in certifying software is FIPS Certification. FIPS 140-2 is a standard put out by NIST to ensure that your software follows guidelines to produce secure software.

Ideally, you pay for FIPS certification once (and it carries a hefty price tag) to certify your cryptographic modules. This includes data at rest and data in transit.

That is it. If you update your product, add new features, you don't go through certification. But, if you update your cryptography, you have to go through certification again.

What Happtique apparently is proposing to do, is double, triple, quadruple, and so on dip into developers pockets to keep their product certified. From what is published, lets look at drchrono.

Note: Happtique has said they "Pricing strategy hasn't been established" as of yet so this is apparently "conjecture" at this point, but reading their website and press release, they contradict the pricing strategy statement. 

drchrono has put out 14 updates to their iPad App in the last year. Using the published model for Happtique, drchrono would pay them $42,000 in total for certification. But, has drchrono changed their "core" code which handles data at rest and data in transit? Probably not.

So, what value is Happtique presenting to its potential clients it wishes to certify? What value is it to drchrono for their 14 updates of their EHR? What is the ROI for any App going through the process?

$3,000 an update maybe chump change for GE Healthcare or Quest Diagnostics, but an innovative Silicon Valley startup - it is hiring an intern for a month. It is hiring someone to perform PEN testing on their product. It is buying ad space. Imagine if drchrono had an Android client with 14 updates going out a year - they'd be spending $84,000 a year on Happtique certification.

What if your App fails certification? Is it another $3,000? What is you fail a single item on the list? Is it another $3,000?

If the pricing structure isn't complete (Which I still find hard to believe), it was premature to release anything at all. Happtique has left room for interpretation in their offering, which causes confusion for their intended audience which is already inundated with red tape.

Now, security

Happtique has listed seven standards for their security piece of the product, from detecting malicious code to encryption. If we get back to my previous topic, once the security is proven, what good is going through certification again? If nothing changes in managing security, data at rest, and data in transit within your product, then - what are you getting out of Happtique? What is their return on your investment?

From what I can discern from their website and standards, there isn't a whole lot going on to actually test the product to verify it is secure. Now, I could be wrong and I'll gladly say I am wrong if I am, but this is a major missing piece.

If we want to prove that mHealth Apps are secure, what actual security checks are being done besides checking for malicious code? As attacks on mobile devices get more sophisticated mHealth products will become major targets for common attacks - what is Happtique doing to help mitigate this?

Is the model wrong?

I also wonder - is this method of certification incorrect? Consider the Consumer Reports model. Consumer Reports purchases everything they test themselves and relies on those who want the results to foot the bill. 

It boils down to, who is Happtique really serving? If the people they are certifying are paying for certification, they are the clients of Happtique. The people wanting the seal of approval from Happtique aren't the clients in this case. The incentive is for Happtique to approve products with their current model, it isn't for Happtique to provide unbiased results.

Now, some will say "This is how medical certification works!" Well, just because we've been doing something one way in medicine for decades, doesn't mean it is the correct way to do it. Out of control costs are proof enough that medicine is fundamentally flawed in their approaches at the moment.

The Blue Ribbon Panel

Part of Happtique's marketing has been assembling a Blue Ribbon Panel to develop these standards.

The panel is listed as containing

• Howard J. Luks, M.D., M.S. (Chair)
• Franklin A. Shaffer, EdD., RN, FAAN
• Shuvo Roy, Ph.D.
• Dave deBronkart (known as e-Patient Dave)

You can read the bios of these accomplished individuals here.

I point out this Panel because, there is something missing. Dr. Shaffer is an accomplished physician and knows certification. Dr. Luks is an accomplished physician that is involved with social media. Dr. Roy is involved with medical devices, and Dave is an awesome advocate for patients. 

Now, these guys are good at what they do. Where are security experts? Where are the mobile developers that actually develop mobile products? 

Managing a certification program for nurses is an entirely different ballgame from managing a certification program for software. My point being: I wouldn't go to an orthopedic surgeon for a stomach virus. Only one of the four sections of standards put forth by Happtique have anything to do with the actual medical field. Operability, privacy, and security are all related to computing in general - why is the security experts and devs missing from the panel? Simply baffling.

Happtique's website says:

Along with input from health care and information technology organizations and representatives of key Federal agencies

But who?

Operability

One of the biggest things I also have trouble with is their operability standards. Happtique isn't saying they will validate EKG Apps actually work correctly and produce the correct results. That is up to 510(k) certification by the FDA. 

So, again - what value is this certification process? If you are FDA certified, what is the point of getting certified by Happtique? 

All in all, not bad

I'd like to be clear: Happtique's standards aren't bad by any means - in fact many items they list are a great starting ground. Honestly, some things are things that everyone should be doing building software, they are great guidelines to build a foundation off of - from mHealth to even plain old utilities. But to be fair, there are some that I don't see much value in.

mHealth is in its infancy still and introducing more costs into the healthcare market "just because" is a terrible reason to do so.

All I ask is, if I have an mHealth App, what ROI does Happtique provide?

I hope this helps foster a discussion, mHealth needs to move forward and we need the right framework to do so not just a framework.

Tweet #HIMSS

JSON is where it is at

What is old, is still old

Being a C#/Web App programmer for most of my life, SOAP XML Web Services have been a staple of development. Just - it is how you did everything. It was perfect. Visual Studio would build all your classes for you based upon your WSDL and viola - you were up and running within a few clicks of a button.

Which, was nice.

Once I started pushing to "The Cloud" to build Mobile Apps which can communicate with one another or do remote storage - I quickly learned how bad XML based Web Services actually were. To which, my favorite quote:

XML is like violence: if it doesn't solve your problem, you're not using enough of it.

After trying to consume Web Services with iOS - it became painfully obvious that it simply doesn't work well.

My frustrations grew worse when trying to use Microsoft SharePoint Web Services. Which, in their infinite wisdom, returned XML within XML. Yes, brilliant.

There are several factors that come into play with Web Services and mobile development.

Parsing

XML parsing of the Web Service HTTP Response is necessary. This is tedious. In iOS, XML parsing just wasn't fun. You had to build extensive classes to handle and parse out things how you desired. Then, if you want to port that to Android, you have to do the same.

Consumption

Consuming Web Services is expensive. And, this means more than just dollars and cents, but it does mean so in dollars and cents, when you consider metered rates for mobile devices. 

Lets look at this example to get a ticker price of a stock

To send a 3 character stock symbol, we have to send 223 characters in the request body. While, this may not seem like a lot to most - when you are trying to squeeze in efficiency to your product, reducing your payload by 98.5% is pretty dramatic.

Cross Platform Ease

With Web Services, as stated before, XML parsing is a bear. It just isn't fun. With JSON, you can easily port your "Parsing Engine" over from iOS to Android and Windows Phone. In our latest project, going from iOS to Android, converting the parser took a whole 30 minutes of my time. 

What to use

Plus, there are tons of amazing libraries out there for C# and iOS to do JSON. For C#, I love Newtonsoft's JSON library. With iOS, you simply cannot beat JSONKit. With Android, the built in libraries from org.json work perfectly. 

I'll write more on this later, but I just wanted to put it out there, stay away from Web Services if you develop Mobile Apps. Rewrite the Web Services if you have to, just - don't use them. You'll thank me later.