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 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.

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

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.