Watch Out for these Anchors Holding you Back from Compliance
The proposed rule is currently titled ‘Reducing provider and patient burden’. However, the proposed rules do not promise any reduction of burden for payers. Payers must make sure their systems are updated, along with their workflows to be compliant with the proposal once it does become a rule.
As burdens go, here are a few challenges payers must be prepared for while gearing up to reduce provider and patient burden.
The healthcare ecosystem has seen rules pop up, year after year. Health plans, however, take them with a pinch of salt. In the case of the latest proposal to reduce burden, it does in fact become challenging for health plans o align their systems to be compliant once these proposals become rules.
Not only would it affect their ongoing operations, but it would also put a dent in their prior investment in resources, expertise, strategies, and technology that helped them adhere to previous standards. Teams must now familiarize themselves with the latest API requirements, implementation guides, and keep themselves updated on every FHIR release, which is not easy to do while keeping the healthcare ecosystem running.
Payer organizations run on a number of systems, just like any other organization out there. However, these systems have different infrastructure, data formats, data storage, and processing practices making it difficult for health plans to collaborate using said systems. It is not a recommended practice to work with systems that pose a challenge in enabling data exchange among themselves.
With the introduction of this proposal, systems within health plans must share data and communicate among themselves to provide holistic information to the patient when they require it. Developing solutions to facilitate data sharing among these systems and integrating them, aligned with FHIR standards, is time-consuming and complex.
The CMS has mandated health plans to share a list of information with the patients via APIs, one of them being clinical data including laboratory results. Now clinical data and laboratory results are famous for being murky. Patient reports are often just smidges of written text across fields, and laboratories across the continent follow a myriad of codes in naming and listing services and diagnosis.
FHIR-based data sharing is easy when the data is structured. When unstructured data comes into play, it stirs up complications. Clinical data is often redundant, inconsistently coded, or incomplete thereby limiting the value of the Patient Access API. Additionally, up until the IPA rule, most payers did not even have systems in place to receive clinical data.
Health plans across the continent have varying data vocabularies which makes it difficult to match the data from different systems with the same context. The lack of a universal terminology becomes problematic when trying to match data since terminologies vary with purpose. Billing systems usually do not accept clinical terminologies and have to convert the codes to classification to be able to process them. Health plans must match their data from a specific source to a specific target, which will take up time owing to the abundance of terminologies available.
The same goes for patient matching. Without a national patient identifier, health plans are left to determine patient records from different systems that have their own identifiers. The trouble intensifies in the case of empty fields and incomplete data, but let’s address that in the next point.
Implementing FHIR-based APIs means collecting a lot of data from a lot of different sources. The challenge of integrating systems across an organization was discussed previously. However, the data drawback that contributes to it is a challenge of its own.
These APIs must communicate with a number of sources to be able to collate information and present it to the patient and to the provider when sharing patient data at the point of care. Health plans have to acquire the data, identify it, cleanse it, and then convert it to a format recognized by the latest standards. It does not stop there. The data must then be analyzed for optimization, which calls for algorithms and data models that can work with these standards.
Thanks to technology, health plans can engineer solutions for the above. The problems arise when the data collected from these heterogeneous sources turn out to be of different data formats and poor quality, which is the case most often. From absent or empty fields, spelling errors, to miscommunication all contribute to bringing down the value expected from these APIs.
Partner with data experts
Handling and working with data, contrary to popular belief, could be a piece of cake with the right roadmap. Health plans already have their hand full with their ongoing operations be it claims management, enrollment, PHM programs, and so on. Navigating through organizational or operational challenges on the route to implementing compliance would be added pressure.
This is where compliance experts come in. Connect with health plan experts at email@example.com to ensure a smooth journey towards compliance.
Latest posts by Shireen Noushad (see all)
- The Various Facets of FHIR - January 12, 2022
- Reducing Burden with FHIR APIs – Part 2 - December 31, 2021
- Reducing Operational Burden with FHIR APIs – Part 1 - December 30, 2021
- Posted In:
Currently, trying to navigate through the ocean of Healthcare IT systems, processes, and workflows. Passionate about writing, and stringing together words in the simplest of ways for a better reading experience and easier comprehension.All stories by: Shireen Noushad