July 2021 Newsletter

Fee-for-service reimbursement will celebrate its 56th birthday next month. It has lived a long and increasingly rich life stymying numerous efforts to contain its voracious appetite for the health premium dollar. New and unprecedented changes in the healthcare economy, regulation, and technology may put fee-for-service on a very harsh diet if not kill it outright.

On July 30, 1965, President Lyndon B. Johnson signed into law legislation that established the Medicare and Medicaid programs by signing H.R. 6675 in Independence, Missouri, the home of former President Harry Truman who had tried unsuccessfully to implement federal health insurance in the 1950s. Truman was issued the first Medicare card during the ceremony. The budget for Medicare/Medicaid was approximately $10 billion and nineteen million individuals signed up the following year.

Since 1966, government-sponsored healthcare has grown to cover nearly 110 million people at an annual budget of $1.4 trillion.

Several factors have contributed to this astounding rate of growth. For one, Medicare and Medicaid have increased the number of eligible individuals. When it started, Medicaid insured people requiring cash assistance, predominantly the elderly and the poor. Low-income families, pregnant women, people of all ages with disabilities, and people who needed long-term care were soon added to the Medicare and Medicaid rolls. For example, in 1972, Medicare was expanded to cover the disabled, people with end-stage renal disease requiring dialysis or kidney transplant, and people 65 or older that choose Medicare coverage.

Medicare and Medicaid have also increased the services they cover, including prescription drug coverage, improved hospital and skilled nursing facility benefits, mammography, and an outpatient prescription drug benefit.

By the end of 2019, total per enrollee expenses for Medicare, Medicaid, and the Children’s Health Insurance Program stood at over $12,800 per enrollee per year, a 23-fold increase.

Besides increased eligibility and coverage, much of this astounding growth is due to fee-for-service reimbursement, the payment system introduced by Medicare that reimburses hospitals and physicians for each service they provide to patients. While fee-for-service has evolved over the years from its original cost-based approach, it remains a “perverse incentive” because it pays physicians and hospitals for more, rather than better, care. It has also proven extraordinarily resistant to change. Despite testing 54 alternative reimbursement models in the last ten years through the Center for Medicaid and Medicare Innovation (CMMI), only four have been permanently allowed by the Centers for Medicare and Medicaid Services (CMS).

As we move forward from 2021, four forces are converging on fee-for-service healthcare that threaten to end it, once and for all. These interrelated forces – COVID-19, consumerism, administrative burden, and mandatory provider participation in Medicare risk contracting – will make fee-for-service too complex and costly for payers, providers, and consumers to tolerate.

The COVID-19 pandemic exposed the weaknesses of fee-for-service healthcare in profound and permanent ways.

COVID-19 slammed fee-for-service providers and hospitals by shutting down in-person appointments and procedures and the revenue that accompanied them. Providers in value-based contracts fared much better as they had been ensured significant, if not full, payment for each of their patients in a value-based contract.

The pandemic also revealed enormous disparities in equitable access to healthcare among persons of color, the economically disadvantaged, and the disabled. Telemedicine brought healthcare to the patient, first by enabling audio and video teleconferencing instead of in-person visits and second, by increasing the testing and deployment of remote patient monitoring and in-home acute care delivery. Whether this “democratization” of healthcare delivery is not a short-term trend remains to be seen. Telehealth has proven very popular among patients, but some providers are jettisoning telehealth services for in-person care as the pandemic subsides threatening to disenfranchise many people for whom telehealth was the only access they had to the health system.

Consumerism is an overused term, but the fact remains that buyers of healthcare (individuals, employers, and government) want more value for their premium dollar. Regulations that free health data for consumer use will power the development of applications designed for a range of health markets.

Fee-for-service also makes an improved consumer experience a costly and arduous goal for payers and providers. Real-time prior authorization is possible but maintaining the data that enable it to work is much more difficult when one is forced to bear the burden of piecework that is fee-for-service. And compliance with price transparency and no surprise billing regulations is more achievable for payers and providers with value-based contracts than with their fee-for-service arrangements.

Essential to consumerism is that the individual has complete and unfettered access to all of their health data not only to see from which provider they can get the best value, but to switch easily from those providers who do not pass muster to those providers that do. This requires the standardization of data and exchange (interoperability), a prohibition on health care organizations blocking consumer access to their information (information blocking), and a shift in ownership and management of health data from the industry to the consumer.

Administrative burden is the third force bearing down on the industry. While the burden and risks of prior authorization on patient care are enormous, payers and providers continue to disagree, as they have for years, on how it should be alleviated. When you combine prior authorization reform, payer and provider price transparency regulations, and the ban on surprise patient billing, providers and payers may make the shift to value-based care to reduce the complexity of “paving the cow paths.” When reimbursement is fixed, covers the entire cost of a patient’s care, and providers are expected to manage financial risk, many providers may move from fee-for-service contracts to value-based contracts over the next several years.

The fourth and final force is CMS’s shift, through the Center for Medicare and Medicaid Innovation, away from voluntary participation in low or no risk payment models to mandatory participation by physicians and hospitals in full-risk contracts. While physicians have more experience than hospitals in managing risk, that experience is in contracts with significant limits on total financial exposure and narrow quality reporting. The improvements in health data quality, standardization, and exchange will produce better contracts by enabling near real-time cost and quality reporting, improved clinical risk-adjustment for varying populations of patients, and support for more effective coordination of care.

Fifty-six years is a long time to get used to fee-for-service as the primary payment model, but profound and concurrent changes in culture, the economy, in policy, and in technology will break the habit once and for all.

Denny Brennan, Executive Director

Please let us know what you think of our newsletter at newsletter@mahealthdata.org and look for our next issue. Thank you for your continued support and participation!

MHDC Events

Meetings this month:

  • Board of Directors: July 15, 8-10am
  • CIO Forum: July 12, 9-10:30am - Dr. Joseph Kvedar
  • DGC Steering Committee: July 14, 3-4:30pm
  • DGC Working Group: July 1, 9-10am
  • NEHEN Business Users Group: July 1, 9-10am - CANCELLED
  • Vantage Point: Dr. John Glaser: July, 22 10am-12pm

Want to learn more about any of these meetings? Email info@mahealthdata.org

MHDC Webinars

New this month, we're making our formerly private CIO Forum events public. Join us to learn about telehealth from Dr. Joseph Kvedar of Mass General Brigham on Monday, July 12 from 9-10:30am.

Missed any of our webinars in 2021? Click here to see what you've missed! 

Interested in holding an MHDC webinar or have an interesting topic you'd like to present? Contact us at webinars@mahealthdata.org

The Vantage Point Series

 Join us for exclusive interviews with some of healthcare’s most recognized leaders as they reveal how and why they chose their careers, what they learned on their journey, and how to apply their insights to the everchanging future of healthcare.

Our next Vantage Point Series interview features John Glaser, PhD on July 22nd from 10am-noon.

Missed our previous Vantage Point Series interviews? You can find the recordings here.

Spotlight Analytics Update

Spotlight Business Analytics helps healthcare organizations run custom analytics on health data including market share, patient origin, disease prevalence, cost of care, and comparative costs and outcomes for acute care hospitals.

We are working on incorporating new datasets in Spotlight to enhance the analytics and reporting including local and national comparison metrics. We'll have more information coming soon.

We are planning to schedule meetings with current Spotlight users to discuss how to make Spotlight better and meet the different needs and objectives of each user.

Our current status is:

Loaded and available for use:

  • Massachusetts Hospital Inpatient Discharge Data FY19 (HIDD)
  • Rhode Island Hospital Inpatient Discharge Data FY19
  • Massachusetts Emergency Department Discharges FY19 (ED)

Future planned data:

  • Massachusetts Outpatient and Observation FY19 (OOD)
  • Massachusetts Hospital Inpatient Discharge Data FY20 (HIDD)
  • Rhode Island Hospital Inpatient Discharge Data FY20
  • New Hampshire Facility Discharge Data Sets (Application pending)
  • Maine Hospital Inpatient and Outpatient Data

Please feel free to drop us a line with any questions or comments at spotlight@mahealthdata.org. In the meantime, thank you for being a Spotlight Analytics user and a member of this community! Feel free to visit our Spotlight Business Analytics page or email us at the address above for more information.

DGC Update

The Data Governance Collaborative (DGC) at MHDC is a collection of payers and providers throughout the region exploring ways to better exchange health-related data incorporating industry standards and automation as much as possible.

The DGC expects to move to the implementation phase of the code mapping service soon. This system will be available to anyone (with a discounted rate for DGC members).

We continue to participate in industry events and workgroups that help inform our work and have been looking more closely at new and upcoming regulations and laws including the No Surprises Act set for implementation starting January 1, 2022 and the newly released draft of a 21st Century Cures Act 2.0 bill.

We are planning our next Deep Dive on social determinants of health (SDOH) on Thursday August 5th from 2-4pm. We expect this to be the first of several conversations on the topic and look forward to gathering information about the current state of SDOH data within healthcare organizations. Deep Dives are free and open to the public - please join us. You can register here.

Membership in the DGC is open to any payer or provider with business in Massachusetts - big or small, general or specialist, traditional or alternative. Want to know more? Email datagovernance@mahealthdata.org

NEHEN Update

NEHEN reduces administrative burden through the adoption of standard X12 (HIPAA) transactions for payer and provider trading partners. It is a cornerstone service for payer and provider trading partners wishing to exchange industry standard X12, HIPAA compliant transactions in a real-time, integrated manner using APIs. Because of our unique governance, non-profit status, and membership-based model, NEHEN is able to offer very competitively priced services relative to the market at large.

Our service provider Trizetto is presenting their advanced roadmap development plan to the NEHEN Business User's Group. Part one of the discussion was in June with part two occurring at our August meeting. We look forward to offering some of these services including specific service type code (STC) mappings for eligibility inquiries, automated discovery for Medicare benefits, claims attachments for submitting additional documentation, AI and ML predictive claim outcomes, eligibility PRE (Patient Responsibility Estimator) and others.

For information about NEHEN please contact us at members@nehen.org.

Electronic Prior Authorization Initiative 

This project is a prototype implementation that automates prior authorization transactions using the industry standard, open platform methods developed by the HL7 DaVinci Prior Authorization workgroup. This project will be compliant with the three related implementation guides which utilize open, FHIR based API exchange methods. This will allow each payer and each provider to implement a single prior authorization process and format for exchange so long as all of their exchange partners adhere to the same standards.

MHDC has secured funding for the ePA project thanks to the distribution of grants from the Massachusetts eHealth Collaborative. This is an important milestone that allows us to move forward with the execution of the Participant Agreements as each participant is eligible for implementation grants to support their efforts.

On June 7th MHDC and the Network for Excellence in Health Innovation NEHI co-hosted a webinar titled "Innovations in Automation of Prior Authorization: Tackling the Issues from a Multi-Stakeholder Perspective" featuring three separate prior authorization solution providers: Cohere HealthOlive/Verata, and Mettle Solutions. The webinar was attended by NEHI and MHDC members to learn and ask questions directly from the solution providers about how their solution(s) improve the processes of submitting and obtaining authorization for the specific healthcare services that require it. The most important discussion point as it relates to the automation of prior authorizations is the need for a single, standardized methodology and interoperability method so that we do not find ourselves with many disparate solution approaches on the payer side and the provider side that do not help alleviate the burden of working with individual payers and providers on a one-to-one basis. All three of these solution providers agreed with the use of the DaVinci exchange standards as is required for the ePA Prototype Project.

For more information email us at epa@mahealthdata.org.

Industry Events

Interested in webinars and online conferences through July? Here are some we recommend (they're free unless otherwise noted):

We do periodically post webinars we plan to attend on social media, so feel free to follow us on Twitter (@mahealthdata) and LinkedIn for more webinar ideas and for our take on interoperability, data, health equity, telehealth, APIs, and other topics of interest.

Have an upcoming event next month to suggest? Write us at newsletter@mahealthdata.org - no self-promotion please.

Patient Access/Provider Directory

It's finally here - enforcement day for two of the major components of the CMS Interoperability rule: Provider Directory APIs and Patient Access APIs. But what does that actually mean, and how can you expect these APIs to be used? We'll look at the Provider Directory APIs first then follow up with the more complex Patient Access APIs.

Provider Directory APIs

Provider Directory APIs using FHIR v4.0.1 are required for all Medicare Advantage plans, Medicaid Fee-for-Service (FFS) programs, Medicaid managed care plans, CHIP FFS programs, and CHIP managed care entities. Unlike other CMS rules, they are not required for QHP issuers on federally funded exchanges as these programs already have their own provider directory requirements.

Unlike most APIs, these APIs are providing public information with no privacy constraints. Thus, the APIs cannot require authentication or place any constraints on requestors. Anyone should be able to request information using the APIs provided they do so in the published, documented format for the APIs.

Such documentation is required and must be publicly available on the payer's website or via a link on their website. Payers cannot place any conditions on viewing the documentation such as registration, agreement to receive promotional materials, or fees.

At a minimum, Provider Directory APIs must include provider names, addresses, phone numbers, and specialties for all in-network providers. If a Medicare Advantage plan covers pharmacy benefits it must also include pharmacy directory data including pharmacy name, address, phone number, and pharmacy type. Information available via the API must be updated within 30 calendar days of a payer receiving new or updated directory data.

CMS recommends but does not require compliance with the Da Vinci Plan-Net Implementation Guide. This guide is maintained by the Da Vinci Payer Data Exchange (PDEX) work group and incorporates the required data as well as additional useful directory data. As with all regulations, the requirements outlined in the regulations are a floor not a ceiling.

It's worth reiterating that this is a public API. That means anyone from any organization and from any location can access the API. If you understand how to make a REST API call you can retrieve information. None of the information in this API is proprietary in any way. For comfort, some organizations will use a completely separate base URL for their public APIs versus their APIs requiring authentication, but that's not technically necessary to maintain security.

Another area of concern that often gets raised around the Provider Directory APIs (and provider directories more generally) is maintenance and accuracy of the information. This is a problem that exists outside of the API framework and is not directly addressed by this regulation beyond the requirement noted above that any updates sent to payers be reflected within 30 days of receipt. However, the No Surprises Act, passed in late 2020 as part of the consolidated budget bill and encompassing commercial insurance plans as well as government-funded insurance, includes clauses to address directory accuracy. This includes specific requirements for providers to send timely updates to payers, validation requirements for payers, and a requirement to remove providers who can't be validated among other things (including that payers honor in-network status declarations made via their provider directory information). These requirements start at the start of the first new plan year on or after January 1, 2022 and we'll be looking at them - and all of the other requirements set forth in No Surprises - as regulations related to the law start come out so watch this space.

Patient Access APIs

Provider Directory APIs using FHIR v4.0.1 are required for all Medicare Advantage plans, Medicaid Fee-for-Service (FFS) programs, Medicaid managed care plans, CHIP FFS programs, CHIP managed care entities, and QHP issuers on federally funded exchanges.

Patient Access APIs must make adjudicated claims data (including provider remittances and patient cost sharing), encounter data, and the subset of clinical data included in the USCDI v1 available to patients within one business day after the data is received by the payer. Further, payers must include all such available data associated with any date of service on or after January 1, 2016 and include data originally received in or that's stored in any electronic format including PDF files and other originally unstructured data.

FHIR v4.0.1 does not have a direct representation of USCDI. Rather, CMS has indicated compliance with the US Core Implementation Guide (US Core) is deemed an acceptable alternative for purposes of this rule. US Core is both more expansive and more restrictive in some ways than USCDI, but it does incorporate all of the components of USCDI in some form. It's important to note that US Core and USCDI are not maintained by the same organization and are updated on different schedules. Further, the Patient Access APIs explicitly require use of USCDI v1, but US Core will almost certainly evolve and incorporate some form of newer versions of USCDI (USCDI v2 is already in draft form and expected to be finalized this fall). It is unclear exactly how this relationship will evolve as USCDI v2 is not entirely backwards compatible with USCDI v1, but the current US Core should be used for initial Patient Access APIs.

Payers are not required to acquire new clinical data to send to patients via this API, but must include all clinical data included in USCDI they already have or receive for any purpose. As previously mentioned, data that's previously only been stored in unstructured formats like PDF files are not excluded from this requirement. The only exception is data received through the upcoming Payer to Payer exchange if that data isn't received via FHIR APIs (note that this loophole will likely be closed in future rules; requiring FHIR for this exchange is part of a currently frozen CMS interoperability rule). If you have USCDI data in any format because you've used it to make prior authorization decisions you must send it to patients. If you have the data for a care management program you must send it to patients. If you have the data for risk adjustment or quality measures you must send it. And so on. This means that this data can no longer be strictly segregated into silos within a payer organization but must be collated together for the use of this API, although this could happen as the data is gathered when requested rather than in a single central data store if preferred.

The requirement to exchange clinical data included within USCDI (or US Core) is a floor, not a ceiling, and CMS encourages including additional data. While not required, they also recommend using the CARIN Alliance Blue Button Implementation Guide for exchanging claims data, the Da Vinci PDEX Formulary IG for exchanging pharmacy-related data, and the Da Vinci PDEX IG for exchanging other clinical data. We're interested in hearing whether folks are actually using these IGs or doing their own thing - let us know at datagovernance@mahealthdata.org.

Data falls outside of HIPAA once sent to a third party app or other non-regulated entity via APIs which has caused a lot of consternation. This is not a sufficient reason to refuse a request, nor is not having a previous relationship with an application or the company developing it. Payers cannot restrict the applications patients use unless they truly believe an application will cause a security risk to their own systems (the exact text is "present an unacceptable level of risk to the security of PHI on the payer's systems based on objective and verifiable criteria") - a very high bar it's unlikely many (any?) apps will meet. This makes a lot of folks very uncomfortable, but it's the law. Patients get to choose which apps they use. The Federal Trade Commission (FTC) has some controls over app behavior generally including adherence to privacy laws and there are industry groups forming voluntary guidelines that apps can attest to following, but the truth is that the way we as an industry control and oversee health data changes with the advent of Patient Access APIs. Payers can recommend preferred apps, provide links to report apps to OCR or the FTC, express guidelines around apps for patients to consider, and encourage patients to read privacy policies (and report companies that do not follow their own stated guidelines), but when push comes to shove it's the patient's choice what to use and whether to report bad behavior. We know most people just click accept on privacy and data use policies and that's not likely to change any time soon.

It's not entirely the Wild West, although it may feel like it. Payers must authenticate requests using OAuth 2.0 and OpenID Connect and have adequate processes (and documentation) in place to allow applications they do not have any previous relationship with to use these authentication mechanisms as long as one of their patients desires it. These are industry standard protocols used across all sorts of apps containing all sorts of information including sensitive private information like financial information to validate identity and access rights. Nothing is guaranteed, of course, especially in the current environment of enhanced attacks on health data. Data could very well be safely exchanged via APIs but compromised via an attack on a business associate of a payer or provider that the patient didn't even know had their data (as recently happened to the author of this piece).

All of this requires a fair bit of documentation. The minimum documentation requirements outlined by CMS include documentation for the API itself, a listing of the components and configuration needed to successfully interact with the API, and information about how to register with authorization servers deployed in conjunction with the API. The API documentation must include information about the API syntax, function names, required and optional parameters with data types, return values and their types or structures, and exceptions and error handling methods and their return values. CMS does not distinguish between reference and usage documentation for the API itself, so whether to provide anything beyond basic reference documentation covering the above topics is left to the payer. As with everything else, this is the floor not the ceiling and the more quality documentation that's provided the less likely you are to have significant support requests from app developers trying to use your APIs. All documentation must be publicly available on the payer's website or via a link on their website. Payers cannot place any conditions on viewing the documentation such as registration, agreement to receive promotional materials, or fees.

We expect changes and additions to this API over time, both through adoption of future versions of USCDI and through the addition of other types of data identified as important to patients. USCDI v2 is a fairly minor update, but USCDI v3 is likely to include SDOH and other expansions that move beyond basic clinical data. The original regulation received comments about including image exchange and this conversation has been periodically ongoing since. While the previous second CMS final rule was withdrawn and the proposed rule frozen, additional data related to prior authorizations encompassed within is likely to be resurrected at some point. Groups are looking at all sorts of other data including clinical trials data, genomic data, and advanced directives. Data related to medical devices, remote monitoring, consumer health data, non-traditional treatments like acupuncture and massage, community services, wellness programs, and more may also be part of a patient's health data history. Some, if not all, of this data will eventually find its way into CMS exchange regulations.

Regardless of what makes its way into future regulations, MHDC firmly believes that these regulations represent the bare minimum that should be done. Using consistently structured data exchanged via regular, agreed upon APIs for all health data exchanges regardless of the type of insurance a patient has or what type of providers they see is a goal we think is well worth pursuing. We're working on it.

Okay, the APIs are here - now what?

For many, the Patient Access APIs will be a bigger lift than the Provider Directory APIs because because they require authentication and patient matching to identify the correct information to send in response to specific API requests. In addition, the provider directory information is often already collated and public facing in some form while the data served up by Patient Access APIs includes PHI and often has not previously been exchanged via any type of automated electronic exchange. The data may exist in unstructured formats like PDF files or in structured data that needs to be mapped to FHIR resources for exchange. Once set up, though, it opens up a lot of doors for patients and a world of potential uses that we've only just begun to imagine.

The Patient Access APIs, in particular, are more than a change in technology. It's a change in the way we exchange data. Previously, most data sharing efforts were project-based. A group of people from both sides got together and negotiated exactly how things would work and the responsibilities of each side of an exchange. This is not only not possible, it contradicts the new model which pretty much requires an automated, self-serve process. Once a general process is implemented and shown to work, payers should not expect to have any - let alone extensive - conversation with specific application developers or others at the companies developing the apps unless they receive customer support requests. That's the expectation of an average app developer and anything else will be seen as problematic at best and obstructionist at worst. That doesn't mean you can't gather information or have knowledge about who's using the APIs, but it means this data should be collected via some simple onboarding or registration forms and via logging and other automated processes.

Another thing to note that's not discussed very often is that there's no requirement that these third party apps be used or designed for mobile devices. Third party apps could be written for any computer or for any consumer item that includes embedded code. In addition to desktops, laptops, tablets, and phones we could see third party apps using Patient Access APIs in consumer health devices, standalone single purpose data appliances (such as a family's group calendar if historical data is maintained), financial tracking applications, smart watches, and more.

We're all operating under the assumption that if we build it they will come, although perhaps in ways we haven't yet imagined. There are already third party health applications incorporating payer data into their workflows, but will patients who don't already use existing apps adopt them as the data spigot opens? Some of that depends on patients knowing that they can and other aspects of patient education. Payers should provide some direct information, but is that enough? It will likely only be accessed by folks looking for it, not reach folks who don't even know to ask. Public service announcements about information blocking have appeared on Massachusetts television and in popular social media applications - will similar campaigns discuss third party app access in the future? Will any app developers advertise the services themselves? We just don't know.

What we do know is that this is an early step in a growing industry shift to make data more widely available and to make the patient the hub of their own data. Right now there's no requirement that patients be able to send data to various spokes on the hub, but be assured that's coming and coming soon. Patient corrections, annotations, and the ability to directly initiate sending a carefully curated selection of their data to anyone else they choose are all clearly in the future, although perhaps not immediately. The previously published then withdrawn CMS rule adding additional requirements to existing exchanges as well as new electronic prior authorization requirements and a Provider Access API requiring payers to send most of their data to providers will almost certainly reappear in some form, although the form and timing of that is unclear. The next big interoperability ask on the books will likely come from the aforementioned No Surprises Act which includes quite a lot of data sharing between payers, providers, and patients - including between out of network providers and payers and is currently slated for January 2022 - but all of that's just what we expect in the near term. Who knows what else is coming or how fast it will get here. Watch this space.

LGBTQ+ Pride Month

LGBTQ+ Pride Month is a time to celebrate LGBTQ+ identities, progress, and contributions, learn about the history of this community, and also to highlight continued inequities and to advocate for LGBTQ+ rights. In recent months there has been a rise in anti-trans legislation, especially targeting trans youth and access to healthcare. This article discusses the issue from the perspective of a Boston Children’s Hospital pediatrician that works with trans youth.

Learn more about Pride Month:

Wrapping Up

Before we go, here's a reminder of upcoming data exchange deadlines from ONC and CMS (including the CMS rule that's currently frozen, as noted by *):

And that's it, folks. Loved it? Hated it? Have an idea for next time? Send us feedback and suggestions about this newsletter at newsletter@mahealthdata.org or send us feedback and suggestions about anything else at info@mahealthdata.org.

Massachusetts Health Data Consortium
460 Totten Pond Road | Suite 690
Waltham, Massachusetts 02451

For more information,
please contact us at info@mahealthdata.org

join our mailing list

© Massachusetts Health Data Consortium