Cigna Patient Access APIs Hero
Mark Lorenz


In this post:

  • Patient access workflow screenshots.
  • A review of Cigna's patient access APIs.
  • Why you shouldn't let a surgeon pierce your ears.

All you have to do is bring earrings the day of the operation

In 2015 Margaret O'Neill was worried about her 5-year-old daughter[1]. Her speech hadn't developed normally and doctors had diagnosed her with "ankyloglossia"— more commonly know as "tongue-tie".

Tongue-tie is a congenital condition where the lingual frenulum, that little web of skin on the bottom of your tongue, is shorter or wider than normal[2]. This extra tight frenulum quite literally ties the tongue down, making it hard to pronounce words with L or R; "lemonade" comes out as "wemonade". The condition is common, and the treatment is simple— an outpatient procedure to snip the frenulum.

O'Neill scheduled her daughter's surgery. During a pre-op visit with the surgeon she was surprised when the surgeon offered to pierce the child's ears. "It would be a nice thing for the child, all you have to do is bring earrings the day of the operation"[3]

The real "nice surprises" happened when the bill for the frenotomy came.


The best summary of Cigna comes from the their own 10-K filing with the SEC.

Cigna lines of business

Cigna has Medicare Advantage, Part-D, Medicaid, and ACA Exchange plans across a range of states. All of these plans are required to have patient access APIs available by 1-July-2020.

At this time Cigna has their developer sandbox available, but the production environment is not available.

What Cigna got right

The authorization workflow

Cigna patient access authorization workflow

What you need to know about authorizing

Apparently weird stuff in the authorization flow is going to be the norm for patient access APIs. Both Aetna and UnitedHealthcare made their own unique, weird choices. Cigna decided to bring a superfluous fruit cake to the party.

It's not documented, and as far as I can tell, not a standardized OAuth workflow, but when Cigna's server responds to the /authorize request with the authorization URL it also instructs the web browser to set a cookie- this cookie is then checked by Cigna's server during the login process. Here it is with pictures:

Normal OAuth workflow
Normal patient access auth flow

Simple HTTP that can be done client-side or server-side.

Normal OAuth workflow
Cigna's patient access auth flow

Due to the cookie, this flow has to be started in the user's web browser

This is probably designed as a security feature. It would prevent a user from authenticating without directly requesting authorization from Cigna's server. That said, I'm not creative enough to think of how a forged authorization could be an attack vector. The down side to Cigna's approach is that the authorization request must be generated by the user's browser, meaning if there are any errors no one will be alerted, no one will be able to debug.

Like United's API, the redirect_uri parameter needs to match what was configured in the portal or you get an error.

My suggestion is that Cigna either remove this cookie check, or at least document how it works.

Once you get past the authorization workflow, the tokens work as expected

The Explanation of Benefits (EOB)

EOB looks good, exactly as expected.

Wrapping up

Ear piercing is free at just about any mall in America.

Month's later, when the bill for the O'Neill child's frenotomy came it included an expensive line-item: $1,877.86 "operating room services"[4] for the ear piercing. Ear piercing is free at just about any mall in America[5].

If it's having your ears pierced by a surgeon or adding superfluous authorization steps to your API- more complexity is not always better.

One Click Retweet

Do you know someone with an Aetna Medicare Advantage plan? Please send them to the HealthSouse home page. We may also be able to save your friend some money.

Still here? Thanks for reading! You seem like a nice person, who should send me an email: Encouragement and criticism are both welcome!