CMS ACCESS: An Engineer's Field Guide
The reimbursement for ACCESS is small and I'm not going to relitigate it here. What I'll say is that this is the first CMS model I've worked on where a technology-enabled care organization is the aligned participant, gets an eligibility answer from the payer directly, reports the instrument answers and scored values rather than a summary measure, and can ask for the claims afterward. Whether that combination pays for itself depends on acquisition and retention, which was the previous post, and on how much of the intake, record, and reporting work carries over to the next program, which I don't know yet. My bet is most of it. This post is the technical half of that bet.
Back in March I built a mock ACCESS FHIR server against a draft of the spec, mostly to find out what a year of this model would look like end to end. Since then we've sent real packets to CMS's test environment and aligned real patients in the MSK track at RevelAI. So this is what the API actually asks of you, what the packets look like, what CMS's test environment taught us, and the system you end up building around it.
If you're not the one writing the client, here's the short version:
- The API is four operations and one poll. Getting a client to talk to CMS is the easy part, and it's mostly done once it can submit and read a result code.
- The hard part is a year of engagement per patient, with a record good enough to bill from and outcomes reported on CMS's clock.
- The thing worth more than the payment is the loop: eligibility from the payer itself, outcomes on a schedule, and claims data you can ask for. I'll come back to that.
