FHIR Facade Model: Is it right for your payer organization?

By: Charlie Provenzano

HOW DO I COMPLY WITH ALL OF THESE NEW REGULATIONS? – IT’S ALL IN THE USE CASES

 

We’ve all had a couple of months now to review the new rules from HHS. While there may be some tweaks that come from the official review period, date changes, etc., the main points are finalized. Payers and providers will be required to share patient data, and HL7 FHIR will be the standard through which it’s accomplished. While the regulations and inherent expectations are clear for most, the actual implementation details, the implications for your own organization, and the questions you need to ask yourself, are probably a lot less clear-cut. For example:

How will I identify patients?

      • If I have a patient ID and I’m querying a payer, should I be able to use that ID with a date range?

      • If I’m querying a payer and I don’t have an ID?

      • If I’m querying a provider and I don’t have an MRN?

      • Do I have a patient match service as part of my FHIR implementation?

Which version of FHIR do I need to support?

      • New regulations demand STU2 (Standard for Trial Use), but comments are urging STU4

      • What if providers in my network use EHRs with STU2? Can I still support STU4?

 How will patient consent be managed?

      • Do I need direct consent from the patient?

      • Can I trust consent has been given to the requestor?

      • How will I confirm consent for all types of data being requested?

 What data sources do I need to become FHIR-enabled? And for what types of requests?

      • If I’m a payer, do I only need to provide data I’ve received via claims?

      • What data will we consider ours vs. the patient’s?

      • How do I describe the provenance of data at my institution that was shared by other institutions or providers?

The members of the Da Vinci Project have been wrestling with these issues since 2017. Since Da Vinci is made up of private industry participants from both providers and payers, as well as participants from CMS, the Da Vinci use cases are already aimed squarely at these questions. The answers you need will likely be found in the implementation guides for these use cases as they are developed, and in the accompanying reference implementation projects. Let’s talk about applying these resources to your own work in FHIR.
 

WHAT’S A USE CASE?

For the Da Vinci Project, the use cases are all around value-based care workflows. The members focused on high volume manual activities that would benefit from full or partial automation. Specific to the new regulations, Da Vinci is actively developing two uses cases for eHealth Record Exchange, Payer Data Exchange (PDex) and Clinical Data Exchange (CDex). Detailed descriptions of all of the Da Vinci use cases can be found here: http://www.hl7.org/about/davinci/use-cases.cfm

 A use case defines a problem at a high level. Within each use case are defined scenarios. Each scenario is a User Story in the Agile development sense. Each scenario describes a workflow involving specific end-user characters who each play a part. These scenarios strive to be as realistic as possible. For example, here is a draft workflow from one of the current PDex use case scenarios:
 

Patient:

Lauren Dent is a 62-year-old female, living in Wisconsin but she spends winters in Tampa Bay, FL.

Lauren works on a seasonal basis and has just accepted a new position with her employer and has moved to a larger town in Wisconsin to live with her daughter. As a result of the move she has selected a new primary care provider.

      • Lauren is in reasonable health but is managing a number of conditions.

      • She has been diagnosed as pre-diabetic and is being treated with medications.

      • She s taking medication for hypertension.

      • She had a knee replacement five years ago.

      • She had a procedure seven years ago to correct a problem with a disc in her lower back.

      • A history of a normal colonoscopy five years earlier.

      • A history of a pneumovax and zostavax four years earlier.

Physician:

Dr. Jillian is an internist

In this scenario, Lauren has moved into the community and wishes to establish care with Dr. Jillian. The goal of the scenario is to describe the process by which Dr. Jillian receives available clinical data from Lauren’s insurer.

WHAT’S A REFERENCE IMPLEMENTATION?

For each use case, a reference implementation guide is created. The reference implementation contains code and related artifacts that address the scenario. It’s intended to be a source of information and a model for developers who are trying to implement the use case in their own systems. It also can be used to demonstrate the FHIR interactions described in the guide.  All of this code is public, so you can feel free to copy it, incorporate it into your own projects, or just use it as a learning tool.  

For the above scenario (for which HealthLX built the reference implementation) the reference code includes: a SMART on FHIR app (to gather information for a CDS hooks call); code to launch a CDS hook and retrieve a CDS information card; and a second SMART on FHIR app to display the data returned and allow that data to be selectively written back to the EMR. (The code also had to support STU2, STU3, and STU4 on the EMR end, and to write either individual FHIR resources, or a document bundle if those resources were not supported for write by the EMR.) All of this code is available in a GitHub repository as both raw code and as Docker images. 

The next step for a reference implementation are the FHIR Connectathon events put on by HL7.org at its quarterly meetings. The Connectathons are a chance for other HL7 members to explore the reference implementation and give feedback on the guide or the active use cases. Most often, a reference implementation is improved and enhanced over a series of meetings until the members have agreed that the use case is ready for balloting by HL7 as a whole. HL7 balloting occurs three time a year, and once the artifact is passed it becomes part of a STU. The public Da Vinci Project implementation guides (in their various states) are available on the Da Vinci public Confluence page.

 

NOW WHAT?

As clear as the new HHS rules are, becoming compliant with them is easier said than done. The Da Vinci Project’s value will become increasingly apparent as organizations wrestle with the questions outlined above. Da Vinci is doing the work most healthcare organizations need to do, but don’t have the time or resources to devote to it. And, Da Vinci’s collaborative aspect ensures high levels of relevancy and quality in the use cases and implementation guides. All of this work is being done on behalf of the entire industry, so don’t feel like you have to go it alone when it comes time for your own implementation. Better yet, if you feel you have the cycles and the expertise, and you want to influence the evolution of the FHIR standard, inquire about your company joining the Da Vinci Project as a paying member.

Want to review this series in depth? View the previous posts:

Part I

Part II

Let’s Get Started

We Want to Know What Data Integration Needs You Have!

Schedule an intro call