Why ownership terms matter
CMS-0057-F requires impacted payers to offer FHIR APIs for patient access, provider access, payer-to-payer exchange, and prior authorization. January 1, 2027 is a hard date for MA organizations and state Medicaid and CHIP FFS programs; Medicaid and CHIP managed care plans comply by the rating period, and QHP issuers on the FFEs by the plan year, beginning on or after that date (see the compliance timeline). Behind those APIs sits a large amount of implementation work: data mappings to US Core, CARIN Blue Button, and Da Vinci profiles; terminology translation; consent and opt-out logic; adapters into the core administration platform; and the operational procedures that keep it running.
Whether that work stays with the plan depends far less on the software license than on the statement of work. When an SOW describes deliverables as a running service rather than as artifacts the plan holds, the knowledge tends to leave with the team that built it, and the next rule change starts from a smaller base than it should. None of this is a criticism of any vendor: vendors deliver what the SOW asks for. These clauses make sure it asks.
1. Work product ownership
Why it matters: without the license to pre-existing IP, ownership of the deliverables can be hollow when they depend on a vendor library the plan cannot use without the vendor.
2. Source code delivery
Why it matters: tying delivery to acceptance makes it routine rather than an end-of-engagement negotiation.
3. Mappings and configuration, documented
Why it matters: for CMS-0057-F, the mappings to FHIR profiles are much of the real work, and they are what the next mandate will build on.
4. Data access and portability
Why it matters: a plan that has to open a ticket, or pay a fee, to see its own data cannot answer a state or auditor request on its own schedule.
5. Plan-owned environments and credentials
Why it matters: an environment registered to the vendor is an exit cost the plan finds out about at exit.
6. Runbooks
Why it matters: the CMS-0057-F APIs are externally visible once live. If only the build team knows how to restart, monitor, or change them, every outage and every small change routes back through that team.
7. Knowledge transfer with a finish line
Why it matters: “knowledge transfer” without a completion test is a meeting series, not a deliverable.
8. Freedom to use other vendors
Why it matters: ownership of code means little if touching it voids the warranty. This keeps competition available for the next change without asking the vendor to support work it did not do.
9. Exit assistance
Why it matters: exit terms are cheapest to negotiate at signing, when both sides expect the relationship to go well, and most expensive to negotiate at the end.
10. Predictable change orders
Why it matters: new rules and state requirements will arrive during the engagement. This keeps the work they generate under the same ownership terms.
The one-question version
If a vendor will not agree to these terms, ask one question and listen carefully to the answer: “If we part ways in three years, what do we take with us?”
- We receive source code and build configuration at each milestone.
- Mappings, profiles, and code sets are ours, in standard formats.
- Our data is available on request, in standard formats, without a fee.
- Cloud accounts, repositories, and admin credentials are ours.
- Runbooks exist before go-live, and our staff can follow them.
- We can bring in our own team or another vendor without voiding support.
- Exit assistance has a defined duration and rate.
cms-0057-f.com is operated by Aurelianware, Inc., the same company behind Cloud Health Office.