Skip to main content
search

Price transparency compliance deadlines are fast approaching. You may be considering building a solution in-house to meet the mandates. On the surface, there are benefits – you can control the experience, ensure it meets mandates, and doesn’t require vendor coordination. However there are important considerations your team may not be fully evaluating related to the long-term impact of building new vs. buying a solution.

Let’s tackle three myths when building applications in-house that may help your team during planning for 2023 compliance, and beyond.

Myth #1: In-house development will be cheaper. 

It is important to evaluate the long-term software development costs. While upfront development and initial design of a member-facing app is what most people think of, there are infrastructure and ongoing costs and resources to consider.  Gartner outlined the challenges of ensuring price transparency  IT architecture that automatically updates for new contract arrangements. Within your organization there are hundreds of combinations of insurance products and benefit structures. Are there other performance and support considerations?

  • Infrastructure – Reliability, resilience and scalability are important, especially as the experience directly impacts your customers. Will your team be able to maintain internal and external service-level agreements? Your infrastructure should deliver high-availability, and have monitoring in place to support and maintain it.
  • Support – Member support is a key connection to boosting satisfaction score and the first line of defense to help members navigate. Will internal teams and members need training? Who will develop and deliver that training? It is important to plan for an application that will keep up with changing data sets, product benefits, group requirements, and consumer expectations and how will that impact member support.
  • Compliance – CMS plans to iterate their data schema for price transparency. This dataset may provide the foundation for transparency requirements. Can internal solutions support iteration to negotiated rate data requirements? Consider additional compliance needs from  the state and federal level, including section 508 compliance and state-level mandates, which add and expand complexity of a member-facing experience.

Myth #2: You only need one user experience. 

Today’s rapid pace of digital experience evolution means UX can become outdated in a year or two. Consumers have high expectations for personalization and tailored experiences. Due to the complexity of data in healthcare and need for consumer simplification, your development team has more to consider than ever before. Who are all of the users, internal and external? What are all of their use cases? What tangential tasks will they need to complete and how do you guide them there?

  • Personalization – Does your organization require different experience for specific groups or lines of business? Consumers expect a high-level of personalization and connectivity across all of your applications and touchpoints. This isn’t just about personalized member out-of-pocket costs.. What business expectations are there for your application to evolve over time? Consider the ongoing project and product resources must be allocated to support this.
  • Groups – ASOs often expect levels of tool configurability before sharing with employees and their families. Are there additional levels of personalization or segmented experiences by group that need to be supported to align with contractual requirements or expectations? Your groups may expect the experience will be delivered under their brand, so planning for that support is important.
  • Integrations – While your internal data integrations and compliance requirements are on your radar, you need to consider casting a wider net.  Will your application also replace your existing find-a-doctor tool? Are there healthcare shopping financial incentive programs that need to be integrated to support company or group claims savings goals? Other organizational considerations may be to support other processes and interactions, like appointment scheduling, care planning, or member health and condition education to maximize the opportunity to support members and streamline touch points.

Myth #3: Build vs. buy is purely a compliance and IT decision.

As Gartner put it, your compliance implementation is just one piece of the larger business strategy around consumer experience and patient journey. While the integrations mentioned above touch on this, there are other stakeholders and considerations beyond compliance. One critical element is understanding how success will be measured for the member-facing compliance experience, for the tool, and its impact on consumer satisfaction overall.

  • Measurement – How is your effort going to be measured and reported upon? What happens if users don’t see value? What is the cost for user support, NPS or other evaluation metrics?
  • Stakeholders – Outside of digital and innovation teams that may be driving online experience, what other teams have a stake in member-facing efforts? Who else might need to use this product? CSRs? Providers? Nurse lines? Could non-commercial lines of business, like Medicare Advantage, benefit from this application? Can the application support phone and print compliance requirements as well?
  • Products – Custom development means that every time someone makes a change to benefits and benefit design, it could impact the application. Your team will need to account for future changes in your insurance products and their impacts to the application and data used.
  • Analytics – Digital experiences are opportunities to collect data, learn from it and refine experiences. How will that be managed? Will other teams be able to use the analytics to support members in other channels, such as the consumer portal, call center, etc. What types of reporting will need to be generated? Consider if your self-insured groups will also expect reporting.

As industry analyst firm IDC has stated, the price transparency application for members is just the tip of the iceberg for functionality and architectural considerations. HealthSparq has worked with health plans to deliver member-facing experiences through our application and power their own digital experiences using our APIs. While there is no one approach, make sure your organization looks below the surface of the build versus buy decision-making process to select the optimal approach for your short- and long-term needs. Download HealthSparq Tips For Building Transparency Tools here.

Close Menu