I have worked in healthcare for close to 30 years, and like many of you, I have learned quite a few lessons along the way. I have been part of the healthcare “crack the interoperability nut” generation that started in 2005 with a primary focus on moving data for coordinated care delivery, provider-to-provider. The mentality then was, “I need to connect” because the meaningful use regulations said I did. I learned that connecting to merely comply checks a box, certainly, but then what? Interoperability is too heavy a lift not to solve specific problems. My advice is to make sure you have a clear business case that frames out the purpose, scope, costs, stakeholders involved, technologies needed and expected costs. In interoperability terms, this is known as a use case.
This blog series has discussed the types of data that you must make available to consumers and what it means to connect to a Trusted Exchange Network. You need to know these first two items to comply with the pending CMS interoperability regulations for health plans. Yet, to realize value for your interoperability effort, you need clear, well-thought-out use cases. With an appropriate use case, interoperability will act as a change agent to how you do business, leading to innumerable benefits for your health plans, providers and members. Otherwise, why do it?
Understanding Use Cases
Done right, data interoperability should be underwhelming to the user. Think about your ATM card. No matter where you are and when you need it, you can walk up to a machine and check your balance or access your money in a secure fashion. It’s easy. It solves for many end-user goals—checking a balance, getting cash for shopping, or even making a deposit. It makes information available whenever and wherever it is needed, regardless of whether you are using your own financial institution’s ATM.
To parallel ATMs to the healthcare world, if you need your health information to enroll with a new insurance carrier, the new plan has none of your information for enrollment—your name, date of birth, address, etc. Your electronic health information (EHI) is not available to you or entities with whom you wish to share information such as other plans or providers. The information is currently in a silo, disconnected from the many healthcare entities with which you need coordinated communication. Wouldn’t you like to have access to data regarding your personal health and related economics whenever and for whatever reason you need it? While I do not think having an easy access card for health information is coming (the security implications of that are pretty horrifying), we are making progress towards data sharing and appropriate transparency for not just health plans and providers, but consumers as well.
So, how do we move data-sharing capabilities forward in healthcare? For health plans to achieve strong, sustainable interoperability, a great place to begin is with a use case. A use case provides a business model framework through a logical, thoughtful process. As an example:
- Step 1 – Identify the Problem with a simple problem statement.
- Step 2 – What are the needs? Are you solving for care coordination, data capture for a new enrollee, or some other purpose?
- Step 3 – Who has the need? These are your actors in the use case.
- Step 4 – Map the Solution to meet the needs of each actor.
- Step 5 – Determine the technology and data needed. Is the data within your possession, in the proper standardized format? Will you need to store data? What is the transport technology you will be using for secure, trusted exchange (e.g., Direct messaging, HL7 Fast Healthcare Interoperability Resources [FHIR] API, Health Information Exchange [HIE])?
- Step 6 – Determine the financial and operational impact to your organization and customers (e.g., initial and ongoing costs, new/redesigned workflows, solution roll-out, etc.)
You should approach use case development by distinguishing between foundational and scenario use cases. Foundational use cases represent infrastructure and base capabilities that must exist to solve for individual, end-user scenarios. For example, reporting quality data is a larger, foundational use case that will require specific technical capabilities for any scenario-level use case. Whereas, scenario use cases set forth the specific problem or epic use of foundational capabilities to solve day-to-day problems. An example of this type of use case would be reporting the percent of adult patients with hypertension who are controlled. Note that this NCQA measure may lead to incentives under a pay-for-performance initiative to support value-based care and payment.
As you develop your use cases, always work with three guiding principles in mind: use cases should improve member-patient quality and experience, increase care safety, and increase operational efficiency to lower costs. Moving data between disparate systems is a herculean accomplishment, but your use case will require that you think about achieving these guiding principles as you tease-out and push data, as well as consume and use the data you receive. Our final blog in this series will explore industry efforts at creating priority use cases between payers and providers, and the emerging data sets to support expanding goals for data-driven operations.
In Summary
SS&C Health will continue to monitor interoperability initiatives. For an overarching understanding of interoperability in healthcare refer to the other 2 blogs in this series on data requirements and trusted exchange networks. We are interested in hearing from you, so contact us for a personal conversation on how SS&C Health can support your efforts.
