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.

AWS Elastic Load Balancer, ugh?

This post is intended to help with setting up HTTPS enabled ELB on AWS

Amazon Web Services

Being more of a "brogrammer" than a network guy, AWS is a bit to wrap my head around. Completely doable, but I assume someone with the correct skill set would have no time at all trying to do what I was trying to. (And, we will have someone designing our networking layout for us, but in bootstrap mode, pre-launch, you must do everything for yourself!)

First, we are in the "stress testing" phase of our product. Spent all weekend generating millions of records of data. Seeing how poorly queries performed, adding an index, rewriting stored procedures, and ending up with blazing fast results.

Then, comes the stress testing. Seeing what the server can handle.

We've been running a "Small" Windows Server 2008 R2 instance in AWS for awhile now for beta testing. It runs perfect with SQL Server and IIS installed. But of course, that doesn't get you too far.

Elastic Load Balancing and AWS

EBS is another outstanding feature of AWS. You can setup load balancers to handle traffic and push it off to however many servers you have setup. Seems simple. Well it is.

But not everything is.

Configuring for HTTPS and HTTPS forwarding

Since we are building a platform that has to be HIPAA compliant, SSL is mandatory. Everything must be encrypted. 

Setting up the ELB for this is, sort of simple, but if you are feeling your way through it some things maybe confusing. Well, really confusing for me.

AWS documentation kept referring to "the public key" but never once defined where you get that public key from.

So, lets setup an ELB

Step one: Set the HTTPS traffic and HTTPS forwarding

Next, move on to setting your SSL information. This was the first "tricky" part for me, but simple enough to get through. 

To get this information, I'll assume you are using IIS and have an SSL certificate from a trusted CA installed in IIS. First, you'll need to export the Certificate. Open up Server Manager, navigate to Roles and down to IIS. Tap on your server and find the "Server Certificates" panel. Double tap it and it will list your SSL certificate. 

Select the certificate and "Export" it in the PFX format (The only option). Now, copy it to your local machine.

I am using OS X, so - these directions on how to get the public and private key only apply here. I don't know how to get them on Windows. 

Using Terminal, use the command

openssl pkcs12 -in mysslcertificate.pfx -out keydata.txt -nodes

Use that output for the fields above.

The final part was the hardest, the "public key"

To get the public key, you need to do a bit more work. First, save your exported SSL certificate somewhere safe.

Next, delete it from IIS and generate a self signed SSL Certificate for your domain. (Follow this blog for information on how to clean up the certificate a bit, if you want to - but it isn't necessary).

Once you have generated that, you'll need to export it.

On your server go Start > Run > mmc. Go File > Add New Snap in > Certificates (Computer Account)

Navigate to Trusted Root Certificate Authority > Certificates and find your self signed certificate.

Right click on it All Tasks > Export

Do not export the private key, and export as Base-64 Encoded X.509.

Save it to your machine and run this OpenSSL command to get the public key

openssl x509 -in self_signed_509x.cer -pubkey -noout

Simply paste that in your "Enable Backend Authentication" public key box and you are good to go. Your encryption will now be end to end for your ELB and your backend instances.

One side note

We wanted to use a "naked" domain name (eg: http://example.com instead of http://www.example.com) - but you cannot do this with Route 53 in AWS. You have to have a subdomain. This is because, you set your www.example.com to use a CNAME record for the ELB, and you can't set the root domain to use a CNAME.

So, don't get cute with your domain names like we were, you need a full subdomain for ELB to work correctly.