.png)
Patient Access API: CMS-regulated payers, specifically MA organizations, Medicaid Fee-for-Service (FFS) programs, Medicaid managed care plans, CHIP FFS programs, CHIP managed care entities, and QHP issuers on the FFEs, excluding issuers offering only Stand-alone dental plans (SADPs) and QHP issuers offering coverage in the Federally-facilitated Small Business Health Options Program (FF-SHOP), are required to implement and maintain a secure, standards-based (HL7 FHIR Release 4.0.1) API that allows patients to easily access their claims and encounter information, including cost, as well as a defined sub-set of their clinical information through third-party applications of their choice. Claims data, used in conjunction with clinical data, can offer a broader and more holistic understanding of an individual’s interactions with the healthcare system, leading to better decision-making and better health outcomes. These payers are required to implement the Patient Access API beginning January 1, 2021 (for QHP issuers on the FFEs, plan years beginning on or after January 1, 2021). (CMS Payer Interoperability Fact Sheet)
To help our users and others in the health system understand how our products — Corepoint and Rhapsody — meet the requirements in the CMS rule, we’ve developed these FAQs.
Q: Do your products directly address the needs of payers working to comply with the API requirements outlined in the CMS Interoperability Rule?
A: Yes. While the FHIR standard may be a new implementation model to the payer segment of the market, it has been used in clinical healthcare transactions for some time now. Our suite of interoperability products (Rhapsody and Corepoint) were the first engines on the market to feature built in FHIR capabilities. We currently have the tools and features in the products to build fully compliant resources that satisfy the CMS rules.
We will continue to build upon our current native FHIR capabilities, ensuring that we can meet any future compliance rules which may emerge. This will allow payers to use our engine(s) to ensure they are always meeting the requirements of the CMS interoperability rules.
All the functionality payers need to meet the rules is already contained within the product. And over the course of the next few releases, we will continue enhancing FHIR functionality to make it easier to use out of the box.
Q: What systems do your products integrate with?
A: Our products can fit into virtually any infrastructure footprint. We specialize in healthcare interoperability, which allows us to support interaction with virtually any other system you would find in a standard healthcare IT ecosystem.
The features that enable CMS compliance are already available in our standard product releases. These features are available to all customers via one standard product release, regardless of market segment.
Q: What’s the pricing model for your products?
A: Currently, the pricing model is the same for both engines. It scales based on the number of connections you need to make to external systems for data exchange.
For payers, we would be willing to explore other potential cost models which can be mutually negotiated, such as number of covered lives or a transaction-based model.
Q: What’s the typical implementation timeframe that payers should anticipate from signing a contract to being live?
With our suite of FHIR native tools these, implementations can be built quickly and efficiently. Ultimately, the timeline for implementation varies greatly depending on the project requirements, internal team-availability, and data quality. We have the best in KLAS services team for the interoperability market and can provide you the resources you need to help meet tight implementation timelines.
For further reading:
