Adventures In Health Insurance Part 3: Getting Covered

(Part 3 in a series, a continuation of Part 1 and Part 2)

To be honest, when I said I want to keep my doctor it was just an experiment.

I've never been able to keep my doctor. Continuity of care seems like a great concept but it's something I've never experienced. I've seen my current doctor a total of 3 times in the 3 years he's been my doctor. I got this doctor l like I got all my doctors: my health coverage changed when my employment situation changed. Optum, the Health IT company and United Healthcare subsidiary, bought Axolotl, the HIE company where I worked. They gave me this new high deductible HSA PPO they believe is the wave of the future and will ultimately bring down the cost of health care by putting the first few thousand dollars of cost on me, motivating me to spend more wisely. That's the theory anyway, as I saw it pitched by Tommy Thompson (HHS Secretary under President Bush) and UHC executives.

I left in July to join a small consulting firm. I'm still working in the HIE field but now I'm buying my own insurance. My intention was to pay for COBRA until the end of the year, then buy either an exchange plan or a private one, depending.

United Health is not on the exchange and is in fact pulling out of California's individual market altogether. They were never big here anyway and the number of individual subscribers probably didn't justify the administrative expense.

I checked out the exchange plans, and I have my choice there. It's not everything I want but it's darn close, a bit cheaper, and feels safer. If I ever feel slighted or wronged by the exchange in any way, I know I'll have an army of Angry Republicans marching to my defense as they have been wont to do of late.

Now it's time to explore the individual private market, that vast free market jungle out there. I feel like I should be wearing a pith helmet.

As with many things, it started with Google, which showed me a paid ad for eHealthInsurance.com

It asked me basically the same questions through the same procedure - the doctor search worked - and it sent me to the Blue Shield of California web site, where I saw the same plans for the same price. The UI is more polished, and you can see how the cheaper plan may be great if you're healthy and nothing happens, but paying 40% of an emergency room visit instead of a simple $250 copay, that could hit pretty hard I imagine, and could lead to some interesting negotiations on the operating table ("What's that machine, doc? It looks expensive").

The cheapest plan on the exchange was $263 and the cheapest plan on eHealthInsurance.com was $294. I could get an HSA for around three hundred bucks, and with that I would have a $4500 deductible and a 40% copay beyond that, up to my yearly maximum of $6250. With the HSA I could contribute to $3300 a year tax free. The idea with an HSA is to start young so when your health fails and you start paying out that yearly maximum, you have enough to cover it. Rich people love it because you can contribute pre-tax dollars and invest it in the stock market, like a 401k. Unlike a 401k, you also withdraw it tax-free as long as you spend it on medical expenses. Like the individual mandate, the high-deductible HSA plan was another conservative idea embraced by insurance companies and incorporated into the ACA. 

The non-HSA plans have a $2000 deductible. Between that and the lower copays, it seems like a less risky choice. I'll pay a bit more per month but a lot less if something happens.

Also, the exchange site is more responsive than it was last time. It's 7:21pm and I'm navigating through as fast as I can click. It wasn't like that the first week.

Buying insurance isn't as scary as I imagined. There is comfort in knowing whatever I buy will have a minimum level of coverage and no lifetime limits. The horrendous industry practice of rescission (actuaries actively looking for reasons to drop sick and expensive patients from their plans) is a thing of the past. I can buy any plan available without fear of hidden "gotchas" that might hurt me later when I need serious health care.

So starting January 1st, I'm off COBRA and on my new plan with the same doctor, the same benefits, and the same costs. I went back to CoveredCA.org to do the actual enrollment, and with another login and a few more clicks, I am signed up! My new coverage starts January 1st.

Adventures in Health Insurance, Part 2: CoveredCA Here I Come

So let's see if I got this right. The original contractor blows a high profile rollout, everyone - and I mean everyone - is screaming mad about the lousy software, management panics, and an elite tiger team swoops in to save the day. In the world of health IT, we call that Tuesday.

As I mentioned before, I am actually shopping for insurance right now. I'm in good health and could probably buy insurance on the private market for a bit less than what I've been paying COBRA for the past several months, but I thought I'd wait to see what the exchanges had to offer. This is the story of my adventure on CoveredCA.

I signed up early, was able to compare prices somewhat and already had a login before the October 1st rollout. I finally found the time and motivation to do some for real shopping. It's 7:17pm and I'm logging in.

It's showing the strain of prime time load, the poor thing.

Waiting ten seconds and clicking didn't seem to help, but the APPLY button did take me somewhere useful. The login worked. I was in.

 My first impression is that of a nice, clean layout. I can see right away I've already filled in all the forms (there aren't that many), but then none of the things I want to click are hyperlinked. I'm a very nonlinear user and I like to click on everything. I suspect there's a NEXT button hiding in the corner somewhere, and there is.

It turns out to be a very linear navigation, and by "very" I mean "exclusively." It's next-next-next until you see at least three text regions overlapping each other, like an HTML panel editor threw up in the corner. 

It looks terrible but I just need to click Select Health / Dental Plan so I move on.

I get to my selection of 26 plans, of which I can view exactly three at a time. There's too much real estate at the top being used by navigation links I don't care about right now, leaving precious little room at the bottom for a ridiculously constrained scrolling region containing all the information I really want. In this picture you can see two rows of that.

And here's a collapsed list of all the information you can scroll through down there. If you count you'll see there's a lot. It's all useful and I wish I could view it more easily.

Here's a tip for all you twelve year old kids who want to build web applications like this one: The ideal number of scroll bars on a given page is zero. One is marginally acceptable but if you have two or more they interfere with each other and that's bad. Very bad.

Let's get to the part where I search for my doctor. He's not there. I hope he hasn't left town but when I search by name this is what I get.

And this is what I get when I search for "S"

I point this out not because it's broken, in fact it works perfectly fine. However, that NextLast bugs me. It makes me want to open a text editor and fix it, but I can't, so it's just annoying.

Let me show you a brilliant health care web site.

This is Palo Alto Medical Foundation. They've been pioneers in health web applications from the very beginning so when I say it's a brilliant site I mean it. It's been polished by years of heavy use, tweaks, and overhauls. Notice the clean layout containing lots of information. Everything you think you should click on, you can. From here you can do any number of things, whether logging in or checking urgent care wait times. And what's that at the top of Special Notices? A list of ACA plans. Just what I need!

However, on the CoveredCA site, I can't search by plan name, or much of anything really. I can browse and find the plans easily enough. It browses side to side with lots of stuff to read, here's an example of some of the mouse overs.

Oops, that's no mouse-over. I'm guessing some of the javascript events aren't being picked up by the timeout mechanism. In any case, I have most of what I need so I can call it a day. I know what plan I want and it's a bit cheaper than what I'm paying now. I would like to make double sure all my providers are in network along with a few other minor questions, as is true with any health insurance plan. However it didn't crash, annoyances were constant but didn't stop me, and I'll probably have to talk to someone in person before making a purchase anyway.

In other words, it's working just as well as your average brand new health IT system.

UPDATE:

The automatic timeout works, and it is nothing if not secure.

Adventures in Health Insurance Exchange Part I: Doctor, Doctor

The insurance exchanges are online and I need insurance.

A little background on me: I was a software architect at Optum (the IT arm of United Healthcare) building Health Information Exchange (HIE) systems until recently. I left to join a very small consulting company (there's 3 of us) and lot of exciting stuff is happening in health care: HIEs, ACOs, NwHIN, FHIR, Blue Button, all these amazing things coming into existence right now.

I'm not without coverage. I have a UNH plan, high deductible with HSA, which is fine. I like my doctors. I'm on COBRA which is $500 a month but I get $100 off for being in good health (rockin' all the vital signs - oatmeal and half marathons yo). Not a bad deal, in relative terms. The individual private plan is about the same but I've been waiting for the insurance exchange to come online and now I get to put it to the test.

Being a Silicon Valley kind of guy, I went to CoveredCA.com - I actually signed up months ago and the "window shopping" part of the site has been up for quite some time so I know my rates are going to be similar. Turns out that's just what they cost.

I have a few requirements for my next health insurance plan:

1. I want to keep my doctors - all of them. PCP, eye doctor, dentist, everyone because I want to live as long as humanly possible and that involves watching the progression of my health very carefully as I age. I stand on the principle that continuity makes better care.
2. I kind of like my health savings account (HSA), I'd like a plan with an HSA. You pour money in tax free and when it's time to pay that high deductible it doesn't feel nearly as painful as pulling that same amount of money out of a savings account. I also figure when I'm old and feeble I'll be paying the yearly max every year, so there's that.
3. If they have high tech wellness tools, like a really killer mobile app, that's a plus.

At first, I didn't know if I could keep my doctor. A tool to search for providers was added October 7th, and with it I was able to find my care organization - Palo Alto Medical Foundation - but not my doctor. I had to go to PAMF's web site to see what plans they accept. PAMF was an early pioneer in this technology and their tools are very, very good. I not only saw what plans I could pick from the exchange, I saw this:

How about that. If I don't switch plans, there's a chance I won't be able to keep my doctor.

Partisan pundits have asked, "Will I get to keep my doctor under ObamaCare?" I think the real answer to that question is, "Were you ever able to keep your doctor?" I had to switch doctors every time I changed jobs, and sometimes just because my insurance company decided to change its "network" for no reason I ever knew. If I move to another city I'll find a new doctor, but as long as I live here, walking distance from PAMF, I'm not switching. I shouldn't have to.

With an ACA plan I can keep my doctor. In fact, I need to sign up now if I want to keep my doctor.

In a later post I'll describe my experience navigating the web site, along with a few others, and actually buying insurance. Spoiler alert: I'm a big, big fan of health IT systems and I'm inclined to like it, but I did run into one or two problems.

Provider Directories at Direct Boot Camp 2.0

The ONC State HIE Program hosted a two-day workshop on NHIN Direct, the health information exchange protocol built on secure email (SMTP/S-MIME). There was quite a good turnout. I'm still fairly new to Direct, so readers will have to forgive (or correct) any innacuracies or misinterpretations on my part, as this is based on notes and conversations I had over the two days. The main areas of focus were scalable trust, security and interoperability, and provider directories. So without further ado, here's a brain dump of my two day dive into Direct.

The Big Question

The workshop opened with a question and crowdsourcing exercise. Everyone was given index cards upon which to write an answer. The cards were distributed and voted on, and the top five read aloud. The top answers were centered on education, outreach, and provider directories.

Provider Directories

This was the hot topic. There's a lot of interest in healthcare provider directories (HPD), trust, and bridging trust authorities. How does a HISP know which HPD to query for authoritative information, and whether the information returned is accurate, up to date, and trustworthy? Since the HPD is used primarily within Direct to look up addresses and certificates, this is a big issue.

At the HPD roundtable discussion a number of different views were brought together. A Federal Bridge was discussed, which using x.500 and x.509 to certify Certificate Authorities (CAs) and provide trust bundle functionality. This would be a distributed system of authoritative directories with the "source of truth" being at the edge of the directory tree, as close to the provider as possible, being that an organization with a direct relationship with the provider would be more trusted. However, how would x.500 deal with system which only use organization-level certificates, and not person-level certificates? What engagement model will motivate physicians to keep their information up to date?

A question was raised about the need for a standard response model supported across the country. It would be nice if states and the DEA supported certificates to verify doctor identities. Provider directories have strong verification and credentialing use cases. For example, in a federated model of authoritative sources, is there a potential for fraud or gaming the system? If a provider license is revoked in one state, what happens when the provider moves to a different state?

Another concern expressed was what information should be exposed publicly. There is a widespread perception that publicly available provider directories might open the door to spam, but the Direct protocol is very difficult to spam. HPD maintainers have a more legitimate concern: if they expose everything via web services, what's to stop a competitor from downloading the entire directory? This is the motivation for mutual authentication, to control who can access what. There needs to be agreement on what information to divulge and what to withhold. Western States Consortium has been studying this problem and is in the process of documenting their findings.

Mod Spec HPD

Direct20: Modular Specifications - Provider Directories from Brian Ahier

Mod Spec (MSPD) is trying to "future proof" the HPD specification and make it more modular. MSPD extended HPD for error handling, federation, and extensibility. The LDAP model is the same, but the WSDL and error handling have been updated. They are looking for pilot projects (contact Farrah Darbouze or Matthew Rahn for details).

ModularSpecs Home Page

AngularJS

"AngularJS is the future" said the guy with a full time job, startup, and weekly speaking engagements who seems to be at every major tech happening and apparently only sleeps between 2AM and 5AM.

"I need the future today," I replied.

So here it is, OmniBinder, an experimental Angular module to bind arrays of objects to a protocol, and RestAngular, a module which automates fetching data from REST APIs.


RestAngular Presentation and the source code used.

RESTful Health and the Internet of Things

In the Internet of Things everything has a URI, and everything that does something has a URI with RESTful services to invoke its functionality. It really is that simple. So what if we apply the same principle to health data? The Internet of Health? What if every element of the health record has a unique URI, standard RESTful interface and predicate ontology to make meaningful connections?

The RESTful Health Record

It isn't far off. The health record may be, and has been, implemented using a RESTful API where every patient, visit, report or event, every element of a medical history has a URI.

http://restfulhealth.com/Patient/123/Visit/456 http://restfulhealth.com/Patient/123/DiagnosticReport/789

The identifier can be any locally unique data, and often it is an internal database key for fast indexing. It may also be a contextual identifier, something referenced in the clinical payload. You could even asign a random UUID or a compound ID with your system's assigning authority. These identifiers will be used in semantic expressions and therefore must be permanent. An indelible audit trail is mandatory, just another fact of life in health care.

FHIR: Health Information as Resources

HL7 is working on a RESTful standard for health records. The HL7 FHIR project aims to provide a convention of URI plus a REST to the standard data structure. It's pretty simple, every entity or event has a base URI plus an identifier. Using the same high level structures as the CCD (better yet, the mercifully simple GreenCCD), you can create a set of services to view, add and update elements of a PHR.

http://restfulhealth.com/Patient/xx-xxx
http://restfulhealth.com/CarePlan/xx-xxx 
http://restfulhealth.com/Observation/xx-xxx
http://restfulhealth.com/DiagnosticReport/xx-xxx

The elements of a patient's health record are not nested inside the patient. Everything is done with references. For example, a care plan will contain references to the patient, all members of the care team, and relevant clinical data and events.

Ontology: Semantic Relationships and Queries

An ontology may be created to describe these connections. You're not bound by the standard data structure of CarePlan/Procedure/DiagnosticReport/Result. You can express your own grouping rules if you define the necessary relationships.

CarePlan hasMember Procedure
Procedure hasReport DiagnosticReport
DiagnosticReport hasResult Observation
hasReport isa hasMember
hasResult isa hasMember
hasMember is Transient

FHIR also includes the concept of resource bundles, so the care plan can include any number of events and they can be grouped in any way the care giver deems useful. The doctor may send you home with a monitoring device (or connect your existing device), and group your device's observations such that a diagnostic report can be run on the aggregate.

CarePlan hasMember Group
Group hasMember DeviceObservation




To help facilitate care coordination, you will need an ontology to describe the relationships between the  care provided and the health data elements with a corresponding set of semantic queries. What queries would be most useful? How would the data be linked? FHIR already has both internal document links and external resource links (attachments), which are essentially simple semantic connections. There's no reason why a more sophisticated model of care coordination can't be expressed in an OWL ontology.

I am now officially a big fan of FHIR.

A Jug of Wine, Facebook Graph Search--and Thou

We all know this Facebook graph search works. It's stalky creepy, but it works.
 


OK fine, so that search works, but this one doesn't? It's only one more parameter!
 
And, unlike searching for single females I went to high school with (which does work, but really who cares), yeah anyway, unlike that, this involves the real world. I'm... ummmm... asking for a friend.

All I'm saying is that some things are better in analog.