Teams building software that touches health records often treat interoperability regulation as background noise: something for lawyers and compliance officers. In the United States that view is increasingly expensive. The 21st Century Cures Act, signed in 2016, and the rules written to implement it changed what the electronic health record (EHR) systems under your product must expose, and which practices count as obstruction. This article explains the three ideas that matter most to product teams: information blocking, certified APIs and the (g)(10) criterion. It describes how they shape engineering decisions and is not legal advice.
The principle behind the rules
The Cures Act made the access, exchange and use of electronic health information (EHI) the expected norm. Earlier policy had encouraged data exchange. Cures turned it into an obligation with consequences, and it assigned the obligation to specific kinds of organizations rather than to “the industry” in general. For a product team, the first practical question is therefore a role question: which kind of organization are we, and which kind are our customers and data sources?
Information blocking
According to the Office of the National Coordinator for Health IT (ONC), information blocking is a practice by an “actor” that is likely to interfere with the access, exchange or use of EHI, unless the practice is required by law or fits one of the exceptions in 45 CFR Part 171. The actors are three groups: healthcare providers, developers of certified health IT, and health information exchanges and networks. ONC’s information blocking overview sets out these definitions, including the different knowledge standards applied to providers and to developers and networks.
Three consequences follow for product design.
First, the rule is about practices, not only about technology. Contract terms, fees, undocumented limits and deliberate friction in an export flow can all be examined, even when the API itself works.
Second, many software companies are not actors at all, while their customers are. A hospital that is an actor needs its vendors to support lawful access, exchange and use of data. A product that makes that hard creates risk for the customer even when the product’s own maker is outside the definition.
Third, whether a specific company is an actor, and whether a specific practice qualifies for an exception, depends on facts and on legal interpretation. Engineers should surface the question early and leave the answer to counsel.
Certified APIs and why they matter to app builders
The ONC Health IT Certification Program defines technical criteria that certified EHR modules must meet. One of them changed the position of third-party app builders more than any other: §170.315(g)(10), the standardized API for patient and population services. As ONC’s description of the test method lists it, the criterion is built from HL7 FHIR Release 4 as the base standard, the US Core implementation guide, the SMART App Launch framework for authorization and the FHIR Bulk Data Access specification for population-level export.
Before this criterion, connecting to several EHRs often meant learning several proprietary interfaces. A common baseline does not make the systems identical, but it moves a large part of the work from “learn this vendor’s API” to “learn the standard and then handle differences”. For product teams the benefits are practical:
- one FHIR and SMART client implementation can serve many certified systems;
- the data a certified API must return is anchored to the United States Core Data for Interoperability (USCDI), which gives a published answer to the question of what data classes to expect;
- test tooling exists for the same standards, so conformance can be examined with something better than opinion.
The required versions of US Core, SMART and USCDI move on a published schedule. Pin your own targets, record them, and check the current requirements on the ONC pages instead of relying on memory or on an article, this one included.
What stays hard
A standard baseline does not remove integration work. Several problems survive it.
Certification covers a defined scope. Data that falls outside USCDI, such as some specialty workflows or local extensions, may need other mechanisms. Variation also remains within the scope: optional elements, search parameters that are supported but slow, and local interpretation of coded values all still differ between sites.
Rollout is also uneven. A vendor may certify a product version long before every customer has upgraded to it, so the API available at a given hospital depends on what that hospital runs and has enabled. A plan that assumes the newest capabilities everywhere will meet exceptions.
Finally, access is not only technical. Customer organizations still decide how apps are approved, which scopes are granted and how onboarding works. A product team needs time in its schedule for those conversations.
Practical consequences for engineering planning
A few decisions repay early attention:
- build to the standard first and add vendor-specific adapters only where a measured gap requires them;
- keep a capability matrix per integration, listing resources, search parameters, scopes and versions actually observed, not only those documented;
- treat the data model as USCDI-shaped where possible, so that a product feature does not depend on a field only one vendor sends;
- write down which practices of your own platform could be read as restricting access to data, such as export limits or contract terms, and have them reviewed by someone qualified to judge.
Some teams also decide that the interoperability layer is not where they want to spend their scarce engineering time. For those, outside engineering support is a legitimate option, and the useful question is what a provider’s scope actually covers. JetRuby, for instance, offers EHR integration engineering as software work, without clinical or insurance expertise. That is the kind of explicit boundary that makes a comparison between providers possible.
The short version
The Cures framework gives product teams three things to remember. Data access is an expectation, and some practices that obstruct it are regulated. Certified EHRs must offer a standardized FHIR-based API, which gives app builders a common starting point. And the details, from roles to versions to exceptions, are specific enough that engineering and legal review belong in the same plan. Teams that internalize this build products that are easier to connect, easier to explain to customers and less likely to be surprised by the next rule revision.
