What are the Architectural Considerations in a Price Transparency solution for Payers?

Unlock the nine key functionalities needed to enable price transparency access to members
Pinterest LinkedIn Tumblr

Regulations require all healthcare services be estimable by 2025. Legislators, politicians, and advocacy groups have screamed for years about healthcare “price transparency,” and CMS has acted with a “final rule” on hospitals and another set of rules for payers.

Under proposed payer rules, which will be in effect starting 2022, there are proposed requirements for group health plans and health insurance issuers in the individual and group markets to disclose cost-sharing information upon request, including an estimate of such individual’s cost-sharing liability for covered items or services furnished by a particular provider.

Consumers/patients do not only want “out of pocket” price transparency, but they also want a tool that allows them to be educated about condition, care options, and predicted out-of-pocket cost. They also want to be able to act after receiving price predictions by seamlessly going into processes like:

  • Prior authorization
  • Appointment scheduling
  • Patient registration
  • Prepayment of co-pay

Consumers should be able to access these processes via mobile, portal, or website. The major requirement of the patient is to not be surprised by the provider or the payer.

IDC 2021 Price Transparency Access

Source: IDC, Price Transparency Mandate Tests Payer Technology Infrastructure; Mar 2021 | Doc #US47466721

As stated in our report (Price Transparency Mandate Tests Payer Technology Infrastructure; March 2021 | Doc #US47466721), figure 1 depicts the hidden architecture to consider when enabling price transparency access to members. On the surface, it appears that a set of applications needs to be developed, bought, or enhanced and tied to the member portal/website/mobile app, the contact center, and maybe a care management application to estimate price.

This set of user-facing functionalities is just the tip of many icebergs. In short, if the payer is to buy this functionality, minimum requirements involve compliance, API integration, integration with benefit, health, and care education and provider search. The functionality necessary under the surface is significant and outlined in the sections that follow in nine categories.

Customer Experience

As stated in our report (The Individual Health Experience: Framework and Toolkit, Oct 2020 | Doc #US46949220), as the consumer “shops” for a provider, facility, or service, they desire accurate predicted pricing through the website, mobile device, or member portal. The mandate requires payers to publish information at a granular service level. Yet what consumers really want is a “no-surprise experience” where they receive transparent, complete estimates for the full service, not just a component.

They expect that this process of obtaining a bundled forecast price dovetails with the “provider search” process. Shopping for in-network providers that are geographically convenient and allow contrasting between multiple providers leads the consumer from “shopping” into a health, care, and cost education process and eventually to a “selection” process that starts “pre-care administration.” That selection process involves committing to a procedure and a provider, maybe obtaining a prior authorization, scheduling an appointment, and becoming a “patient.”

Post-care, the consumer/patient expects that the charges, the claims, and payment processes indeed are what was predicted as proven by clinical documentation, explanations of benefits, and the entire patient financial engagement experience.

Patient Experience

Again, as stated in our report (The Individual Health Experience: Framework and Toolkit, Oct 2020 | Doc #US46949220) the patient experience is arranging and receiving care with set expectations and observations made about direct patient care events, encounters, interactions, processes, and outcomes. Patient experience begins when a person realizes a need to arrange and receive care, and acts on this based on preexisting knowledge, expectations, communication methods, and access to a service, becoming a “patient”.

Once a member has decided to initiate the process to become a patient, pre-service education is provided to the patient about care and present cost with the price transparency mandate. The appointment is made and scheduled, and the dialogue begins via mobile apps, secure messaging, provider portals, or websites before and after the care service itself.

Post-service, a patient expects seamless payment as the claims adjudication and settlement processes occur. As the patient journey evolves, they expect education and notification about changes in care and cost, should they occur.

Network Configuration and Adequacy

Legislatively, an adequate, diverse, and broad network is desired by consumers and required by ACA and state regulations. “Network adequacy” refers to a health plan’s ability to deliver benefits promised by providing “reasonable access to a sufficient number of in-network primary care and specialty physicians” as well as all healthcare services included under the terms of the contract.

Transparency in pricing merges with this network adequacy demand as a consumer shops for providers and services. Presenting a “list of available providers with detailed pricing” is the desire of consumers. The identified expanse of the network and the geographic availability/density of providers enable that “list” to be consumer friendly. If a network is perceived “inadequate” and only one (or none) price is presented to a consumer, the shopping experience and price transparency goals are compromised.

Provider Network Contract Management

Contract management and pricing software architectures can only handle price transparency requirements if they are rule driven, template driven, and data driven and contain event-driven contract clause and terms generation — easy to report and flex.

Most contract management systems in payers today are Word and Excel based, creating documents with attachments of “fee schedules.” To be able to facilitate price transparency, these contract management systems need to unlock their data via API or another discrete data availability enabler.

Provider System of Record

More than the internal systems backbone for provider network definition and demographic capture, detailed provider data in a system of record is essential for provider search and directories, which consumers perceive as a market differentiator and is the basis for a price transparency application.

A solid quality base of provider data is a challenge well documented in the industry. It is the basis from which all price transparency paradigms and directories start. It must be as accurate as possible.

Product System of Record

Most “product master” databases are built to enable the claim engine for accurate claim adjudication. More sophisticated product configuration engines enable a faster time to market for creation of a product from ideation to realization. Few product systems are at the point where “individualized benefits” are possible. Price transparency requirements effectively instantiate “personalized benefits.” To develop a price estimate for a medical service, an individual’s deductible, maximums, and co-pays must be extracted from the product master to be compared with the current state of these metrics.

Claims Infrastructure

“Real-time claims adjudication” is touted as an answer by some vendors as a way to demystify medical prices. Be careful. Even in closed networks such as Kaiser or UnitedHealth Group/Optum, where all pieces of the puzzle — the care, the location, and the reimbursement — are all under one “roof,” with all employees playing to the same policies and motivations, we historically have not been able to do anything other than “pilot” real-time claims adjudication pilots.


Once the operations around enabling the front office by establishing flexible middle/back-office infrastructures are complete, the payer can turn to doing excellent price estimation through the use of analytics bordering on AI. Payers can:

  • Perform historical claims analysis to model prices for:
    • Specific patients
    • Medically similar patients
    • Geographically similar patients
  • Perform payer/provider contract analysis to determine, analyze, and expose:
    • Price ranges and differences (in both FFS and FFV contracts)
    • Variables in cost-sharing agreements


The CMS interoperability mandates challenged legacy infrastructure to free up data to external sources through member-360 and API strategies. Similarly, the CMS Price Transparency mandates reach into the legacy data maelstrom and force the freeing up of data, this time for internal use to expose data via portal/mobile app and other systems required to calculate the desired prices.

Being consistent as to how data is reengineered and enabled to both internal and external constituencies matter as payers increasingly see point solutions and data warehouses tested for use cases previously unthinkable.

The Four Trends Driving Member 360 Platforms

Price transparency tests the data-sharing culture of the payer/provider/member relationship, the technical architecture of payers, and is too often sold on the user interface layer. In the eBook, The Development of “Payer Member 360 Platforms” is Driven by Four Consumer-Oriented Trends, we discuss price transparency and the other crucial trends in-depth that are driving the necessity to establish a Member-360 platform and the technology needed to undertake the integration. Click the button below to learn more.

In his role, Jeff is responsible for research coverage on payer business and technology priorities, constituent and consumer engagement strategies, technology and business implications for consumer engagement, front, middle and back office functions, value-based reimbursement, risk, and quality-based payment and incentive programs, among other trends and technologies important to the payer community.