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

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?

• • • 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?

• • • 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?

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

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.

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.  

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