Transparency in Healthcare Coverage

January 29, 2020
RE: Public Comment on CMS-9915-P: Proposed Rulemaking on Transparency in Coverage

Thank you for this extensive and detailed rulemaking proposal related to openness of healthcare pricing information. The proposed rules come at a time where many people feel insecure or confused about their healthcare costs, and improving transparency from providers by utilizing technology solutions is an admirable goal. As a software developer working in Silicon Valley, I have over a decade of experience building websites. I am currently on leave from the Mozilla Corporation serving as a fellow for the Aspen Institute’s Tech Policy Hub and submit these comments on my personal behalf. Based on my knowledge of software practices, I offer the following comments on the proposed healthcare pricing transparency rules:

Pricing information for healthcare related services should be accessible publicly and without requiring a user account. This will offer the greatest degree of transparency to patients who are seeking out information about costs of service, and offer a greater degree of user privacy in conducting searches.
The term “internet website” should only be expanded to include other technologies if certain criteria is met. Providers should have the flexibility to provide cost-comparison services through different technical means in order to reach a wide patient audience. However, specific criteria should be set to ensure that this option is not used to circumvent the intent of the transparent pricing mandate.
The Departments should host a hackathon to encourage providers to partner with software developers to voluntarily adopt open, standards-based APIs. The use of open, standards-based APIs provide a greater degree of flexibility in how pricing comparison services and platforms are built. The Departments should consider hosting a hackathon to gather more information about the use and implementation of APIs in satisfying the requirements set forth in the proposed rules.

Pricing information should be made available without requiring an account login

First, the Departments should add a clarification to the proposed rules that requires pricing information be made available without requiring an account for a given provider. While the proposed rules require that information be made cost-free, they only explicitly state that the provider cannot charge a fee to access such information. However, charging a financial access fee is not the only mechanics by which a provider could restrict open access to information about costs of services.

It is important to note that the directive in Executive Order 13877 (3) (b) explicitly notes that this directive is meant to provide patients¹ with transparency in their anticipated out of pocket costs. This phrase should be interpreted to mean that the required transparency rules apply to any person seeking care, as opposed to customers of a given health insurance plan. One example is in cases where patients may wish to use the self-service portals of plans where they are eligible for coverage under a Coordination of Benefits between two healthcare providers².

Furthermore, online platforms are increasingly benefiting from controlling the flow of information of how people use their sites. If a service provider is able to restrict access to the pricing data by requiring an account to log in, it will then have the capabilities to track a user’s searches³ and other site interactions and tie them to an individual account⁴. However, because accounts can provide additional context that may result in more accurate estimates, the regulation should not prohibit accounts from being used altogether.

Appendix A provides suggested language for an amendment that would explicitly prohibit health insurance providers from requiring a personal account to access cost information, and define the term ‘personally identifiable online account.’

The term “internet website” should only be expanded to include other technologies if specific criteria is met

As stated in the proposed rules, the term “internet website” is consistent with existing legislation. However, as detailed throughout the rulemaking guidelines, the term “internet website” excludes the other ways that individuals consume digital information. The rules note mobile applications as an example of non-website content. Technologies like voice assistants, smart home devices, programmable text chat agents (“chat bots”), and automated voice call systems could also be used as interfaces to access pricing data. These interfaces all still rely on online services, but are not presented through a traditional website and can be considered “alternative online services”.

As mandated by Executive Order 13877, the desired impact of these transparency regulations is to have healthcare pricing information easily available through an online service. The primary goal of these rules therefore should focus on making information widely accessible, rather than limiting the form that the data is accessed by users.

At the same time, there are trade-offs in allowing providers to use alternative methods of providing pricing information via an alternative online service when compared to an internet website. One benefit that websites offer is that they are available across different devices. This allows a user to access a page on a laptop, mobile phone, or desktop computer. Websites are usually viewed through an internet browser, such as Mozilla Firefox, Google Chrome, or Apple’s Safari. These browsers equally implement a set of feature recommendations that are set by the World Wide Web Consortium Standards group so that users can view the same content regardless of the device they use. Because pages are accessed through different browsers, websites also provide flexibility to developers by allowing them to target a set of known standards that are supported on different devices.

It is important to consider that alternative online services are not as universally available as websites are. Users who have an iPhone will not be able to use applications that are developed for a Samsung phone, to take one example. However, were alternative online services acceptable as a platform in lieu of a website, it could be argued that by providing a self-service portal for some subset of patients, the proposed rules would be sufficiently satisfied. Without additional clarification as to what a comparable online service would require, insurance companies could theoretically implement a solution that was not comprehensive or equally accessible to all patients.

Appendix B provides proposed language for two possible amendments that would address both of these concerns. This would facilitate an innovative and equitable approach to providing transparency in healthcare costs and provide flexibility in how insurance companies deliver online services while also ensuring fair and equal access by: a) Modifying the proposed regulation text to allow for alternative online services and add an explicit set of rules governing the requirements of such services, and b) Modifying the proposed regulation text to allow for alternative online services, and add a rule that requires insurance providers to demonstrate that any implementation of an alternative service accommodates the same set of patients that an internet website would reach.

The Departments should host a hackathon to encourage providers to partner with software developers to voluntarioly adopt open, standards-based APIs

The Departments should host a hackathon to encourage providers to partner with software developers to voluntarily adopt open, standards-based APIs The proposed rules require that healthcare insurance providers offer a machine-readable file that contains pricing information for both in-network and out-of-network cost estimates (Section VII, 6). This option was selected due to the estimated cost to providers, despite a recognition of the benefits that APIs provide. The issued rulemaking document outlines a number of questions related to the cost of implementation, value, and readiness of providers to implement APIs (Section III). One opportunity to provide valuable data in these areas is through a hackathon.

The Departments could incentivize providers to make pricing data available through standards-based APIs by hosting a such a hackathon. Hackathons are low-cost events and bring together technology professionals and other stakeholders to solve technological problems over a short period of time. The GSA has been successfully running hackathons to facilitate public-private partnerships in technology⁵ and some companies report saving up to $50,000/year in technology costs as a result of hackathon projects. Such an event would provide value to the Departments and to health insurance providers.⁶

As noted in the rulemaking document, developers would also benefit from the availability of a standards-based API offering for many reasons. Providing information through standards-based APIs would likely reduce the development time for building pricing information portals . Every commonly used programming language has the ability to handle standards-based API requests, which gives programmers flexibility when choosing how to implement self-service portals. Developers will be able to lean on these established best practices instead of building proprietary systems that will be more expensive to change or re-build in the future.

“APIs are the fundamental connective tissue of the internet. They’re also a powerful tool for efficient, rapid scaling market entry, when a new app or service developer can reach users through existing APIs offered by platforms that have already achieved significant economies of scale.” – Chris Riley, Director of Public Policy, Mozilla Corporation⁸

Requiring applications and websites to be built with standards-based APIs would allow pricing information portals to be built in a forward-compatible manner. As Riley states in the comment above, APIs are widely adopted and allow for efficient innovation on new apps and services. If health insurance providers were required to publish their pricing information via an open API, application developers could create innovate services to access this data.

The creation of standards-based APIs would also allow for the aggregation of providers through third-party applications and generate innovative new healthcare applications. For example, an open, standards-based API would allow a third-party developer to create a single service that a patient could use to view prices for different healthcare plans.

I would again like to thank the Departments for their thoughtful considerations in the proposed rules on transparency in healthcare coverage, and for their consideration of the feedback provided in this comment. I welcome further contact if I can be of any assistance to related matters.

¹ “Healthcare providers, health insurance issuers, and self-insured group health plans to provide or
facilitate access to information about expected out-of-pocket costs for items or services to patients before they receive care.” – Executive Order 13877, Section 3b

² “Coordination of Benefits: Using Two Health Plans to Your Advantage”, March 12, 2019
https://www.thebalance.com/coordination-of-benefits-2645754 (Accessed January 16, 2020)

³ “How You’re Tracked Online — and what you can do about it” CBS News, March 31, 2018
https://www.cbsnews.com/news/how-youre-tracked-online-facebook-google-amazon-uber-what-you-can-do-about-it/ (Accessed January 16, 2020)

⁴ It is important to note that simply making information available without an account will not guarantee that a health insurance provider cannot link searches to an individual via other technical means. Providers could use a technique known as fingerprinting to link a specific device to searches, or to link searches that all come from the same WiFi network. These techniques, though, are far less reliable than tying this information to a single account, and restricting account based services is a critical protection that should be afforded to users.

⁵ https://www.gsa.gov/blog/2016/06/03/open-data-democratizes-innovation

⁶ Movio: How A Tiny Go Microservice Coded In Hackathon Is Saving Us Thousands”, April 10, 2018 https://movio.co/blog/saving-money-with-Hackathon-project/ (Accessed January 19, 2020)

⁷ 3 ways APIs Help Developers Deliver Software Faster,
https://techbeacon.com/app-dev-testing/3-ways-apis-help-developers-deliver-software-faster (Accessed January 16, 2020)

⁸ Re: Competition and Consumer Protection in the 21st Century Hearings, Project Number P181201:
https://www.ftc.gov/system/files/documents/public_comments/2018/08/ftc-2018-0050d-0021-155045.pdf

Appendix A: Proposed Language to prevent account requirements for cost-comparison analyses

29 § 2590.715-2715A (D)(2)(i) could be amended as follows:

(i) Internet-based self-service tool. Information provided under this paragraph (b) must be made available in plain language, without subscription or other fee, through a self-service tool on an internet website that provides real-time responses based on cost-sharing information that is accurate at the time of the request. Information provided under this paragraph (b) must be made available to users of the self-service tool without requiring the user to sign into a personally identifiable online account. Group health plans and health insurance issuers must ensure that the self-service tool allows users to:

Additionally, a definition should be added in 29 § 2590.715-2715A (a)(2) that explicitly defines personally identifiable online account as follows:

Personally identifiable online account means individually identifiable information about an individual collected online , including an email address or any other substantially similar identifier⁹ that is used by an internet website or mobile application to grant access to part or all of an¹⁰ online service

⁹ Derived from the definition of Personal information in 16 § 312.2 (2)
¹⁰Derived from the definition of Online contact information from 16 § 312.2 (2)

Appendix B: Proposed Language to allow for Alternative Online Services

Insert into section 29 § 2590.715-2715A (a)(2) a definition for alternative online service:

Alternative online service means a software application installed on or added to an
internet-connected device that provides access to an online service

Amend 29 § 2590.715-2715A (a)(2) as follows:

(i) Internet-based self-service tool. Information provided under this paragraph (b) must be made available in plain language, without subscription or other fee, through a self-service tool on an internet website or alternative online service that provides real-time responses based on cost-sharing information that is accurate at the time of the request. Group health plans and health insurance issuers must ensure that the self-service tool allows users to:

Append to 29 § 2590.715-2715A (a)(2) a section (D) that includes explicit access requirement rules:

(D) Access cost-sharing information in a way that is not dependent on a specific type of internet-connected device