Delivering Consumer-friendly Healthcare Transparency in Coverage On AWS

Consumers play a crucial role in healthcare cost management, but they must have relevant information in order to produce the market forces needed to achieve reduced healthcare prices.

The Transparency in Coverage (TCR) rule requires health insurers (payors) and hospitals disclose their pricing agreements. This empowers consumers to shop and compare costs between specific providers before receiving care.

TCR phase 1 required payors and providers to publish machine-readable files with pricing information by July 1, 2022. For additional information on TCR phase 1 compliance please read Healthcare Transparency in Coverage Rule – Cost-effectively Hosting Machine-Readable Files On AWS.

A consumer-friendly price comparison tool required for TCR phase 2 must provide cost information for 500 of the “most shoppable” services. By 2024, all services will be subject to the regulation. It must also include costs that are typically bundled with a specific service.

For example, a knee replacement estimate should show the cost for the anesthesiologist, surgeon, and all related hospital stay costs. The cost should include:

• In-network agreement rate
• Out-of-network allowed amount
• Prescription drug prices
• Bundled payment services
• Cost-sharing which includes provider liability
• Member liability
• Family and member accumulator
• Other supporting legal documents

The price comparison tool must allow for searching based on:

• Service descriptions
• Medical and billing codes
• Providers
• Location

With the consumer-friendly price comparison tool in place, people will be able to shop around and compare the costs of healthcare services. This will harbor healthy competition amongst the payors, as well as amongst the providers, which can lead to better care for consumers.

Through an example we’ll show how a hybrid payor environment and AWS services can be used to make a full TCR phase 2 solution. The exact solution implementation for TCR phase 2 will depend on how well existing assets can be used in a payor’s technology environment.

Solution Approach

Payors offer members a web portal for a variety of purposes, including viewing benefits, comprehending recent claims, and locating in-network care. We envision payors expanding their current member portals with a user-friendly price comparison tool. It would allow the members to search for specific services and retrieve a cost estimate, in order to comply with the TCR phase 2 mandates. The search capabilities of the price comparison tool would make use of an architecture to return a list of providers and the associated costs for a particular healthcare service or procedure.

In a majority of cases, we anticipate payors to supplement the search results with current technological capabilities that give their members a more individualized experience. We suggest a method that successfully scans the machine-readable files from the TCR phase 1 and indexes the data. This way, searches for the price estimates can be carried out in order to activate the delivery of TCR phase 2.

A substantial amount of data, that needs to be highly performantly searchable, accounts for a large portion of the complexity involved in developing this solution.

We’ve collaborated with payors and facilitated a solution to this problem. We recommend using Amazon OpenSearch Service (OpenSearch Service) as a key element of the solution approach. OpenSearch Service is an AWS managed service that lets you run and scale OpenSearch Service clusters. With OpenSearch Service, you only pay for what you use based on the number of instance hours, the amount of storage, and the amount of data transferred. This keeps costs low. We also built the solution using AWS serverless technologies, which help the solution scale automatically and relieves the need to manage the core infrastructure.

Overall, our solution focuses on enabling the back-end search capability. However, in order to meet the TCR phase 2 requirements, it will be necessary to interface an API with an OpenSearch Service collection that contains the data in order to provide the pricing information to the member portal.

In short, for TCR phase 2 compliance our solution addresses the following key challenges:

• The ability to search a large number of machine-readable files in a cost-effective way.
  • There are terabytes and petabytes of machine-readable files today and that number is only expected to grow.
• Able to deal with the complexity and variety of the data structures in the machine-readable files for a given payor.
• The consumer-friendly price comparison tool should respond quickly to search queries for the best user experience.

Architecture

Our architecture requires that machine-readable TCR phase 1 files are stored in Amazon Simple Storage Service (Amazon S3) buckets in either JSON or CSV format. We regard these files as the TCR phase 2 system of record, ensuring data consistency and correctness. We recognize that some payor organizations may have used a different strategy for TCR phase 1 compliance. In those circumstances, the data can be relocated to a new Amazon S3 bucket while the rest of the architecture remains the same.

Configuring Amazon OpenSearch Service
We begin creating the solution by configuring Amazon OpenSearch Service. The projected throughput, quantity of files, and frequency of updates are used to set up and size an OpenSearch Service domain. It is critical to carefully evaluate the underlying instance types, storage, and indexing technique for the OpenSearch Service cluster, since they will impact the workload’s efficacy and performance. To avoid data loss and boost search performance implement a storage replica. Each OpenSearch Service domain would have one replica, however additional replicas might be added as your solution grows.

Consider the extra storage costs when sizing the OpenSearch Service domains. When you size the OpenSearch Service domains, think about:

• OpenSearch Service indexing overhead (10% of source data)
• Operating system reserved space (5% of the file system)
• OpenSearch Service overhead (up to 20 GB)

If your use case needs petabytes (PB) of storage, read about Petabyte scale in Amazon OpenSearch Service. We use the following formula to figure out how much storage space is needed:

Minimum Storage Requirement = Source Data * (1 + Number of Replicas) * 1.45

We also use UltraWarm storage and a long-lived index to help the machine-readable TCR phase 1 files get added every month. UltraWarm tiers let you keep large amounts of data in a cost-effective way to improve the search experience. The long-lived index helps with both the initial bulk load and the updates for file changes that happen once a month. TCR machine-readable files can be searched for free-form text by using the right indexing techniques.

Next, we improve the performance of our search domains by determining how many shards are needed to spread the index across all the data nodes. Changing the number of shards in an existing index is hard, so you should choose the number of shards before indexing the file. We suggest that the size of a shard be between 10 and 30 GB, since search latency is a key performance metric for measuring how the user feels. Use the formula below to figure out the number of shards:

Approximate Number of Primary Shards (10 default) = (Source Data + Room to Grow) * (1.1) / Desired Shard Size

To get more threads, and faster search results, use large instance types with higher vCPU counts, and large filesystem cache. OpenSearch Service enables Auto-Tune by default to analyze cluster performance over time and suggests memory-related configuration changes. This includes queue and cache sizes and Java virtual machine (JVM) settings on your nodes.

Schedule a maintenance window to deploy the changes to improve cluster speed and stability.

Next, we use a compute layer to transform the files into a de-normalized structure for optimized querying, perform indexing, and load into the OpenSearch Service using the bulk operation. Given that TCR machine-readable file data structures can be different for each payor, we suggest you test different AWS compute offerings (such as AWS Lambda, Amazon Elastic Compute Cloud (Amazon EC2), or AWS Batch). Amazon EC2 offers granular control for managing your infrastructure with the choice of processors, storage, and networking. AWS Lambda enables you to run code without provisioning or managing servers. AWS Batch enables Payors to run the jobs in batch by provisioning the optimal resources based on the volume and resource requirements.

When testing, use your own machine-readable files and practice an iterative approach to meet performance metrics.

Enhancing search with medical natural language processing (NLP) capabilities
We leverage Amazon Comprehend Medical in our architecture to recognize and provide meaningful information from unstructured input text. It utilizes AWS-trained natural language processing machine learning models to provide an improved free-form text search experience in the consumer-friendly pricing comparison tool.

We anticipate that members may want to search using keywords which may not immediately match OpenSearch Services indexes built from TCR phase 1 machine-readable files. By utilizing Amazon Comprehend Medical to map free text to standardized ontology, a more complete set of search results will be produced. Using Amazon Comprehend Medical’s ontology linking feature, we can recognize entities in text and link those elements to standardized concepts in popular medical ontologies such as ICD-10-CM.

Medical concepts such as medical conditions, anatomy, medical tests, therapies, and procedures may also be detected from text and linked to codes in the SNOMED-CT ontology. Once the ICD-10-CM and/or SNOMED-CT codes have been mapped, they may be utilized against the OpenSearch Service indexes to offer members accurate pricing transparency information in the consumer-friendly price comparison tool.

Figure 1 – Illustrative architecture for TCR phase 2 that shows how Amazon OpenSearch Service and Amazon Comprehend Medical can be integrated with other payor technologies to deliver TCR phase 2 results.

How it works

Here is an illustrated use case of how the architecture shown in Figure 1 would work:

1. In the consumer-friendly price comparison tool, a member looks up a price estimate using a medical service code (ICD/CPT) or the procedure. The member also provides the date of the service and the demographics of the provider. The payor system looks up plan and group information to identify and search the correct machine-readable files.
2. The request comes to the API Gateway, which checks the context and sends the request to the AWS Step Function workflow.
3. The AWS Step Function workflow acts as the orchestration layer and calls an AWS Lambda function that searches for price estimates.
4. This AWS Lambda checks the request criteria, calls Amazon Comprehend Medical to find the specific procedure code from the text input, and decides the search criteria for OpenSearch Service to use.
5. AWS Lambda uses OpenSearch Service SDK to search for pricing data.
   1. OpenSearch Service supports SDK for more than one programming language, so you can choose the programming language you want to use.
   2. OpenSearch Service API returns the pricing information to AWS Lambda.
6. The AWS Step Function workflow collects, sorts, and pages the results from the AWS Lambda function before sending the response.
   1. To personalize the member experience AWS Step Function workflow invokes other internal and third-party API services to the search results. This includes information, such as the patient’s liability and accumulators.
7. The AWS Step Function aggregates data from multiple services and returns the response to the API Gateway’s consumer-friendly price comparison tool interface.

Well-Architected Considerations

The architecture shown in Figure 1 was designed using the AWS Well-Architected framework to facilitate building a secure, high-performing, resilient, and efficient TCR phase 2 solution.

AWS CloudTrail monitors and records account activity across your AWS infrastructure, giving you control over storage, analysis, and remediation actions. Amazon CloudWatch collects monitoring and operational data in the form of logs, metrics, and events, to create a unified view of your AWS resources. We suggest using Amazon CloudWatch and AWS CloudTrail’s monitoring and audit logging features to help you manage how people are using the solution so you can improve it in the future.

As a best practice you should use modern DevOps practices to build this solution. This will lead to faster delivery and better quality overall. AWS CloudFormation lets you model, provision, and manage AWS and third-party resources by treating infrastructure as code. You can automate the process of setting up an environment and recovering from a disaster by using tools like AWS CloudFormation.

There may be additional components which can simplify your TCR phase 2 implementation. However, our solution is from the point of view of our Payor customers. Moreover, the architecture can be used by other healthcare stakeholders, such as Providers, Pharmacy Benefit Managers, and Health Tech companies.

Conclusion

Knowing how to achieve proper compliance for the new Transparency in Coverage (TCR) rule is key for payors. Starting with Amazon OpenSearch Service, we looked at many different CPU, memory, and storage configurations. Since most of the operations are read-only, we chose UltraWarm with up to 3 PB of attached storage because it was the most cost-effective option.

The AWS healthcare team is ready to help payor organizations with design guidelines and well-architected strategies for TCR phase 2 based on their needs. Our AWS account teams are glad to delve into your unique requirements to assist you in determining the optimal strategy for implementing the TCR phase 2 compliance and estimating the costs involved.

Contact your AWS account team for more help on design and to explore private pricing. If you don’t have a contact with AWS yet, please reach out to be connected with an AWS representative.