The Data Retention rules for the Legacy systems of Covered Entities may be in conflict with the member data access rules of the CMS Interoperability and Patient Access Rule. Onyx addresses this collision with SAFHIR.
In September, 300 FHIR Community members gathered in Baltimore for the first weekend FHIR Connectathon in a few years. The event was buzzing with many great conversations taking place in addition to important testing that continues to advance the HL7 FHIR Specification and a myriad of Implementation Guides forward.
As I reflect on the many discussions that took place, one in particular is worth delving into further because it focuses around a common area of confusion with the CMS Interoperability and Patient Access Rule.
I have had innumerable conversations with health plans and vendors about the CMS Rule and the Five Year “rule” invariably comes up. The CMS Rule has a number of dates and durations that it refers to. The interpretation of these dates and durations may catch health plans out especially when it comes to FHIR data being generated from their source legacy systems.
Here’s the thing. Health Plans typically define a data retention policy for their operational systems. This could be 5 years, 7 years or longer. This is often a policy that is applied across all enterprise systems.
If the FHIR data published in accordance with the CMS Rule is generated from these legacy enterprise systems when requested by the member then there is a potential conflict with the CMS Rule. Let’s dig in to this to understand how this collision can occur.
The CMS Rule requires a health plan to make health data available to a member going back as far as January 1, 2016. As I write this article in late 2022 that is over 6 years ago. For a long standing member of the health plan there is 6 years of data and it is still accruing.
The Five Year “rule” relates to the length of time that a member is able to return to a health plan AFTER dis-enrolling and request access to their data. This means that if a long standing member decides to leave their health plan on January 1, 2023 the plan will have to enable the member to retrieve their data until December 31, 2027. That is a total of 12 years.
This potentially leaves the health plan with a challenge. There are a few options:
- Extend the data retention period for the source system to accommodate the publishing of data from long-standing members.
- Keep the data retention rules in place and archive the aged data and provide a mechanism to retrieve the data from the archive and convert it to FHIR to deliver to the member.
- Publish a point-in-time version of the data in FHIR format and maintain that data separately from the legacy systems where the member’s data can be safely deleted five years after they dis-enrolled from the health plan.
As time passes this problem will grow for organizations that publish FHIR data directly on demand from their operational or enterprise systems. Unless the data retention rules are modified, which could have significant complications and added costs of operation, Organizations will have to support converting data from multiple sources to present an entire member health record.
It is my belief that we are heading towards a tipping point. Creating a FHIR Store that can retain data as longitudinal health records spanning many years, coupled with that FHIR store being able to share data with internal systems using a consistent set of data structures will become a strategic advantage. That FHIR store can also handle the transition from outbound publishing of FHIR data to a world where FHIR data is bi-directional. We already see this trend emerging as the expected Burden Reduction and Patient Cost Transparency regulations drop. Data will need to flow back and forth between Payers and Providers. All using standardized FHIR formats.
The FHIR store is set to become a strategic resource. It will be receiving and responding to requests from provider organizations and other health plans. This will position it as the source of truth across the enterprise. Enterprise systems across the organization will depend on the consistency of data format and comprehensive view of health data. These systems will query the FHIR store for the latest information.
What does this mean for health plans?
There are two types of health plan:
- Those that viewed the CMS Interoperability and Patient Access Rule as compliance requirement and developed solutions to publish data for members in FHIR format.
- Those that saw the CMS Interoperability Rule as the first step in a journey to a future where data is exchanged and transactions are conducted across the Healthcare industry using FHIR-based specifications.
If you one of the former you may be waiting for Burden Reduction and No Surprises regulations to drop with trepidation.
If you are the latter, you will have a FHIR Interoperability platform and strategy in place and will be positioned to embrace the new regulations as a means to transform your organization and the member experience.From the outset Onyx has been building the adaptable FHIR Interoperability platform that can power business transformation.
Come join us!