tl&dr
- SSPs is our beta, open source standard service package library for powering Good Faith Estimates at scale
- Check it out here! (SSP website | Github repo)
- More to come throughout this year and into 2023
If you’re reading this blog, you’re deep in the healthcare Matrix. For the next few minutes, you're Neo, and we’re Morpheus. Let’s take the red pill and get right into it. The No Surprises Act (NoSA) describes a litany of requirements for Good Faith Estimates, Advanced EOBs, and patient estimate solutions (here’s a high-level overview for context). Back when we read the No Surprises Act over cookies and eggnog in the winter of 2020, our brains ran wild on the technical infrastructure:
- How will providers create accurate GFEs at scale, vs. piecemeal ad hoc creations?
- How will GFEs be handled for complex, multi-provider procedures like orthopedic surgeries and deliveries?
- How will patients compare estimates apples to apples if received from multiple providers?
- How will providers translate GFEs to “pre-claim” forms to be “pre-adjudicated” as an Advanced EOB?
- Why did I just drink so much eggnog?
Over the better part of two years, we’ve quietly worked on an open-source project to help answer these questions and lower the barriers to wide-scale compliance with NoSA in a way that is actually useful to patients.
So without further ado, we’re announcing the beta release of our free, open-source Standard Service Package (SSP) Library, live now.
What are SSPs?
SSPs are a growing, open list of common shoppable services and their typically associated ancillary charges. They are intended for provider and third-party use as a starter template for furnishing GFEs at scale in a “pre-claim” format.
Here are a few more distinguishing characteristics:
- SSPs are algorithmically generated by clinical associations present between charges on over 30M+ patient episodes found in Komodo Health data
- We’re launching SSPs for an initial list of 37 high-volume shoppable services. We paid particular attention to the 500 shoppable services mandated by Transparency in Coverage
- SSPs are currently intended for a technical audience (more on this below). You’ll be interested in SSPs if you’re A Data Person within a provider tasked with complying with NoSA
- SSPs comprise HCPCS, revenue codes, facility fees, and professional fees. They are intended to resemble charges on a UB04 or CMS 1500 claim form
- SSPs are a free and open project. We invite collaborators to share feedback via our Github repository
Library Overview, How, and Why
The healthcare industry has a long history of associating healthcare services into simplified events (think MSDRGs for inpatient Medicare reimbursement). However, these groupings are typically proprietary, meant for actuaries and backend reimbursement, and not geared towards patients and shoppable services. Consequently, existing technologies would not be a fit for the common shoppable services needed for NoSA.
What’s more, the proprietary nature of the groupings would prevent wide-scale adoption and iteration in time for 2023. Many high-volume shoppable services are commoditized enough that a core suite of standard, archetypal charges appropriately describe the vast majority of encounters.
As such, we set out with our data scientists and 30M+ longitudinal patient records to algorithmically derive the archetypal services for these common shoppable services. In the process, there were several hurdles to work out. There are mutually exclusive services (for example, Anesthesia X and Anesthesia Y might be highly correlative, but you would never use both). There are also several shoppable services that are clinically distinct, but the associated charges are relatively common and should be combined from a lay patient's perspective (for example, there are 32 types of hysterectomies, but how many should patients see?).
Our initial release of SSPs is a baby step towards accommodating these and several other complexities in quoting the cost of healthcare. We want to be clear: this is a beta release. Use with caution and leave us feedback as you go.
Over the coming weeks, we will be happy to roll out more of our technical methodology for both deriving SSPs and deciding which SSPs would make good initial candidates for release. You can read more about our methodology here.
Who’s this for?
Currently, SSPs are meant for a technical audience. This is typically developers and data professionals finding themselves deep in price transparency compliance requirements for their provider or payer organization. We call them nerds. Here are a few relevant audiences:
- Engineering and data professionals: Visit our Github page, use the API, or access the raw JSON versions of SSPs to immediately begin creating estimate templates for your provider.
- Provider Rev Cycle leaders: You may be tasked with complying with NoSA, but have your hands full. You will be able to intuitively understand the template services in the library. After reviewing them yourself, invite A Data Person to the conversation.
- Federal and state government: Many providers will see GFE compliance as a technical burden. Manually creating service packages and finding associated charges is a heavy lift, we know! You may use the services packages site for awareness and education.
- Clinicians: Believe it or not, we’ve met many clinical folks who care about the patient's financial experience. SSPs are beta and open. We’d love your input on the various service packages and charge inclusion.
Our initial release is only a tiny drop in the bucket compared to what we have planned (episodes, inclusion of diagnoses, customizable SSPs based on different patient populations). We’re currently refueling on eggnog. Please reach out to us if you are interested in collaborating!
How to use the SSP library
In this initial release, the SSP library has a few primary use cases. To help you envision how a health system might incorporate SSPs, we’ve put together this clickable demo. If you’re greedy for more, here are a few more uses:
- Quickly locate common charges and codes associated with common shoppable services. This will save you time in furnishing a prompt GFE and sending an accurate estimate
- Identify co-providers for convened estimates by looking through the services associated with an SSP. For instance, you’ll need to reach out to a few med groups if you’re a hospital furnishing an estimate with pathology, anesthesia, and surgery
- Marry SSPs with your chargemaster by code to create charge amounts specific to your provider’s services. Live happily ever after.
- Use SSPs to communicate with patients where prices may vary. For instance, if an SSP is heavy on operating room time, you can let the patient know that the cost of the procedure may depend on this factor
Limitations
In this first iteration of SSPs, we are primarily trying to paint a vision for the future of standard patient estimates while providing a useful tool with which to start. We are aware of the many limitations of this first release, and we’d be eager to hear your feedback on others. Here is a non-exhaustive list:
- SSPs were built using claims data for facility-based outpatient services. Thus, many of the current SSPs skew towards hospital outpatient service archetypes. In further releases, we plan to involve a wider array of sites of care
- No two patients are the same (clones and doppelgangers included). We recognize that a multi-comorbid patient receiving orthopedic surgery may have a different service mix from a healthy patient. In future iterations of SSPs, we plan to involve diagnosis as a qualifying criterion
- SSPs aren’t currently easily read by patients. As we mentioned, our initial release is geared towards technicians. Through our Github, we’d love to source feedback on patient-friendly descriptions of service packages and associated charges
- SSPs are not yet episodic in nature. If a patient comes in for a knee replacement, there are diagnostics on the front end and physical therapy sessions on the back end. Currently, SSPs are geared towards the “event” of the primary encounter (eg, the outpatient surgery encounter)
- There are tons of shoppable services, and only a few SSPs to start. Help us add more by leaving feedback on candidate SSPs on the project Github
This is the start of a beautiful friendship
We’re looking forward to enlisting feedback as we build towards “no friction compliance with NoSA.” We want patient estimates to be as ubiquitous as standard quotes in other industries (car insurance from Progressive, home repairs via Thumbtack, etc). To do that, we have to tackle the complexities of healthcare and we hope to have your help.
Over the coming months and years, we’ll be 1) Releasing additional SSPs, 2) Refining existing SSPs with clinical feedback, and 3) Creating more episode-based SSPs. As the year progresses, we’ll also work to integrate diagnosis data + share documentation for the creation of locally-customized SSPs specific to your patient population.
Interested in collaborating or offering feedback? Do you have very strong opinions about eggnog that you cannot help but share? Drop us a line at info@turquoise.health