State Medicaid agencies face a daunting challenge to meet federal deadlines for making their data available to third-party developers through standard application programming interfaces (APIs). During a recent presentation, Colorado Medicaid IT officials outlined their planned approach to overcome the obstacles they face, including a budget crisis related to the COVID pandemic.
The compliance deadline for the patient access API and provider directory API provisions is January 2021, just a few short months away. However, CMS has released guidance saying it would exercise enforcement discretion for a period of up to six months with connection to those two API provisions.
Speaking at the 2020 State Health IT Connect Virtual Summit on June 4, the Colorado team said a multi-state collaborative may be part of the solution to meeting the federal deadlines. “To be frank, based on state timelines and shifting resources to mitigate the COVID virus, it will likely be incredibly difficult for many states, Colorado included, to implement by July 1, 2021,” said Micah Jones, health IT coordinator for the Colorado Department of Health Care Policy and Financing. “Accordingly, communication with CMS is important because CMS implied to us, at least, that they would be willing to exercise additional enforcement discretion as long as Colorado was doing everything practicable to implement the rule as close to the deadline as possible.”
Parrish Steinbrecher, director for the Health Information Office for the Colorado Department of Health Care Policy and Financing, spoke about how his office is thinking about overcoming obstacles in order to meet federal deadlines.
“Right now we have a budget crisis and changing Medicaid priorities during COVID-19. We have many uncertainties about our budget now, next year and the year after. HITECH is sunsetting, so we need to meet with CMS to develop transition plans,” he said. “The estimates we received from our current partners are in and this is not going to be an inexpensive project. We need to develop a procurement strategy for long-run sustainability.”
Meeting this requirement during the budget crisis leads to a series of questions, Steinbrecher ran through:
• How can they build requirements that are specific without being too directive? “We can limit innovation with poor contract requirements, but we need to be able to hold vendors accountable to measurable outcomes,” he said.
• How will Colorado add employees to test and project-manage these interfaces? Who is going to manage those new staff members? And what governance process are they going to use? “Colorado began the process of pursuing a system integrator for our MMIS ecosystem early last year, but we have since lost the first-year funding for that project due to the budget crisis,” Steinbrecher said. “How do we create governance and change management processes for different vendors or modules without a systems integrator? After implementing our new MMIS and data warehouse in Colorado, we spent about another 16 months working backwards with our finance team and data team to ensure data was mapped correctly. And that is just one of those outcomes from not having good governance upfront.”
“We have put new staff in new positions and they have been charged with new roles and responsibilities to think through this,” he said, “because we know we are going to have to do more with less in the future.”
• How does Colorado work with its existing state IT infrastructure and use existing technology in the marketplace?
• How does Medicaid harness the innovation of the private sector without pricing out members? And for members, how can the state make sure they understand and get training for the applications and how to use that data in a way that is best for them? How are third-party apps going to use the data, translate the data and charge for it?
• What could be re-used across states? “We want to collaborate with other states where we can,” Steinbrecher said. “We have learned that if we can share best practices on documentation, governance, testing, contract development and service level agreements, it will save us so much time and energy. That is why we are thinking of beginning a multistate collaborative to share this information. The Colorado payer landscape is fragmented, and we know each state has its own unique challenges. But if we work together, we can overcome these challenges.”
Each state will be required to go through the process of building a “Blue Button API” for Medicaid the same way CMS did for Medicare data. “It requires you to think about technology, people and processes,” Jones said. “We will need to map our claims data to the API data format and then need to build the API endpoints to that claims data such as explanation of benefits. Finally, we are going to have to think about how to authenticate the end users of these apps.”
He said system partners IBM, DXC and Deloitte will help with the technology piece of the patient access use cases. The health information exchanges in the state will be vital in helping with additional use cases such as data integration and working with developers.
“We do not see ourselves as the center of this implementation. We understand that this is not where our expertise lies. We are not looking to build some ‘Big Brother’ state-run initiative,” Jones said. “Accordingly, we are looking to our partners to assist us in building this. We do see ourselves as helping to align and steer this initiative. We also see ourselves as the primary funder of implementation and maintenance of this initiative.”
Authentication might be one of the most difficult technical aspects, Jones explained. Their plan is to leverage their existing benefit authentication service called PEAK. A Medicaid member will log into a third-party app. That app will then make an API call to the HIE asking to verify member credentials. The HIE will pass that call through an API provided by Colorado’s Office of Information Technology (OIT), in which it case it will be delivered to the PEAK system. The system will then authenticate the member credentials and sends a call back with a credentialing token back through the OIT to the HIE, which will confirm the member is who they say they are.
Colorado’s MMIS and pharmacy benefit systems send data to the data warehouse. The warehouse will have a dedicated Blue Button environment. “We may bring on a vendor to host a FHIR server and environment outside our warehouse,” Jones said. “Data will be passed using several APIs provided by the Office of Information Technology and our contractor Mulesoft. The Colorado HIEs, including CORHIO, will lead the developer side of implementation including developer support, publishing API documentation, and making EHR data available via API as well. After a member has been authenticated, subsequent API calls with the credentialing token to our data warehouse will occur. The warehouse will push the claims, provider, and other data through our APIs to the HIE, and then the HIE will push it to the member’s app, completing the call.”
Developer Engagement
Kelly Taylor, director of the Colorado Digital Service, was involved in working on the CMS Blue Button API. He says one of the mistakes that many government projects make is having a ‘build it and they will come’ attitude. “You can see how it happens. Government is so large in scope and we have these built-in audiences, so when you launch something new, it might seem like customers and vendors just show up, sometimes because they have to,” Taylor said. “Couple this with a vendor focus that might be mostly on the technology — the API itself — instead of thinking holistically about the developer experience, adoption, and ultimately how the end-users will experience the API. You risk building something developers won’t adopt.”
In 2018 when he was helping to build the CMS Medicare Blue Button 2.0 API, he said the team knew that the Medicare Blue Button API would launch and get really good press but then risked tailing off and not getting developer adoption, which would lead to a sunsetting a year or two later. “So this fear really drove us. Without developers on board, no beneficiaries or members are realizing value. So we prioritized the developer experience.” Mark Scrimshire worked as a developer evangelist for the Blue Button API and the whole team focused on evangelism efforts.
“It is a team effort to drive adoption,”” Taylor said. “One of the big lessons from building Blue Button was to treat it like a product and talk about it that way to our CMS stakeholders. We would report out the number of weekly developer signups or those that had made at least one API call, or those that were making regular API calls – that tells they have built some type of sample app, and finally the number of customers that had requested and been granted production API access.”
“As our own Colorado Medicaid team works on our Blue Button API, I have no doubt that we in partnership with our vendors will successfully map claims data to a FHIR API, and create a secure OATH service, and we’ll build an intuitive OATH flow that makes sense to members when they are connecting their data,” Taylor said. “But what is less certain is how successful our approach will be to developer evangelism and developer adoption. Without developer adoption, you have nothing. That developer adoption and members ultimately using those apps that provide that value.”
