Fueling Your FHIR Webinar Q&A

In our recent webinar “Fueling Your FHIR: The Keys to Strategic, Complete, and Compliant Interoperability”, we discussed how organizations can achieve holistic interoperability using an integrated healthcare data platform that leverages EDI and FHIR alongside their existing core systems. We received a lot of great questions from our audience and unfortunately ran out of time before we could address all of them—but don’t worry, we cover them here.

Read on for our speakers’ perspectives on your most burning questions!

Q: Can you give an example of leveraging or integrating legacy processes to support a FHIR use case?

Eligibility checks are one opportunity to leverage legacy processes to support a FHIR use case. Using the 270/271 transaction set, organizations can tap existing EDI integrations instead of building new FHIR integrations, thus supporting prior authorization requirements efficiently via the already integrated gateway. This approach takes advantage of existing back-end system infrastructure while adopting new protocols provided by FHIR.

Another example is the integration of Good Faith Estimate (GFE) requests under the No Surprises Act. Organizations often create “dummy claims” in their adjudication systems to support price estimations, despite these systems not being ideally structured for such estimates. This involves tweaking the adjudication system and customizing dummy claims to indicate they are for pricing purposes, aligning with FHIR API calls for GFE requests.

Q: From our implementation experience harnessing data, integrating downstream hasn’t been easy or seamless. Are you able to expand more on this?

One of the most challenging aspects of integration is the translation/transformation of data between standards and/or from non-standard to standards-based formats. Our expansive and continuously maintained library of “mappings” combined with our extensive experience in handling non-standard formats make this a much more “mundane” task for us than it is for vendors that concentrate in either specialized workflow applications (e.g. Utilization Management) or data storage (e.g. FHIR Repositories). This capability has materially contributed to our Best in KLAS Interoperability ranking for our 9115-F implementations.

Q: Is the identity solution comparable to ping/okta/etc., or is it more specific to interoperability use cases?

It is similar in terms of core function; however, it expands on those offerings by natively integrating/referencing member and provider data in the repository so that it can be included in the authentication token. Interoperability use cases require the use of SMART on FHIR technology that adds a security layer to FHIR interfaces based on open standards like OAuth 2.0 and OpenID Connect. Edifecs solution natively enables SMART on FHIR as identity and access management model.

Q: If we already have a FHIR solution in place for 9115-F, what is the bare minimum we would need to comply with 0057-F? And will your solution work with ours?

While a bare-minimum approach is not what we recommend as it can create a lot of extra work later on, we realize budgets are tight and it’s important to start somewhere. By adopting a holistic strategic approach to interoperability, however, you’ll enable future-proof interoperability, regardless of standards or use cases, and reach the next frontier in information exchange, transparency, and efficiency.

That said, to comply with 0057-F, you need to enhance your patient access API to capture prior authorization information, expose a new provider access API with dependencies like consent management and attribution, and add a channel or API for prior authorization and its endpoints. Our solution can seamlessly integrate these capabilities with your existing 9115-F solution or replace components as needed, adapting to your current setup.

Q: In payer-to-payer data exchange, how do you ensure quality data is coming from the other health plan?

In payer-to-payer data exchange, ensuring data quality involves tagging clinical information with its origin using the concept of provenance. While we can’t guarantee the quality of data from another payer, we ensure compliance by verifying that the data conforms to valid codes and standards. Organizations like CAQH Core play a crucial role in maintaining the semantic integrity of data during format conversions, ensuring that the data retains its meaning and usefulness. Continuous updates and enhancements – better enabled through a SaaS deployment – are essential to adapt to new requirements and maintain data utility.

Q: For the provider access API, do you feel like there needs to be buy-in from the provider side to benefit or ensure compliance?

Yes, buy-in from the provider is essential for the Provider Access API to be beneficial and compliant. Providers are likely to utilize the API to access patient information, especially in critical situations like emergencies. However, the trustworthiness and accuracy of the data will be crucial for providers to rely on it for clinical decisions. Ensuring the validity of the information will be a key consideration for its effective use.

Providers need access to a comprehensive set of patient information for accurate assessments, especially during admissions. Additionally, in use cases like risk-adjusted populations and value-based care arrangements, having extensive data helps providers manage care and costs effectively. Therefore, the Provider Access API offers significant value across various scenarios, motivating providers to utilize it.

Learn more about our FHIR Gateway or tune into our recent webinar: Fueling Your FHIR: The Keys to Strategic, Complete, and Compliant Interoperability.