Federal Government API
Background + Problem
In 2019, per a federal mandate, the Centers for Medicare and Medicaid (CMS) launched an API known as AB2D. Its purpose was to provide medical claims to insurance companies for their beneficiaries (patients). This was a novel data set for insurance companies and would for the first time give insight into patient’s holistic medical services and medication usage.
This API was one among many in a platform, a suite. The company I worked for at the time was charged with the development of this API while another contractor developed the other three (Blue Button 2.0, BCDA, and Data at the Point of Care).
When I joined both adoption and usage were low. We were being asked to learn why this was case.
Approach
An API project like this one had many moving parts and considerations. By this I mean, approaching a problem like low usage and adoption meant going beyond the end user to looking internally and taking a service design approach. As well it also meant being open to who we considered as end users (especially in the time of PRA). While the end of our stakeholder chain was the patient, speaking with them proved difficult. Developers and insurance agencies were, however, incredibly key stakeholders, and could be tapped.
I used a variety of methods in this project, some of which proved to be more successful than others:
service design blueprinting our internal processes and external touch points
usability studies with developers
in-depth interviews with insurance companies
API log analyses
Team structure
On this project I was the lead and sole Researcher. Internally, I connected heavily with our Engineering team, Product Manager, and Scrum Master. On the client side, I spoke at least weekly with our CMS Product Manager. Because this project was spread across multiple API’s, I also worked with other contractors and their teams of Designers and Engineers.
Findings + Impact
From service blueprinting we identified areas where customer success could be improved due to slow response times and altered our approach to address those issues.
Usability studies with developers uncovered the range of skills and resources among this user group. Our code was not clear to novice developers nor those introducing APIs into their systems for the first time. Again, we altered our approach to include more customer touch points and found there to be less customer confusion through such a small change.
In-depth interviews with insurance companies revealed they needed better framing beyond a mandate. This support would help them with influencing at the highest levels. Gaining this insight led to the development of new partnerships with other agencies within CMS.
