GUEST BLOG: Da Vinci Project’s One-on-One with Founding Member HealthLX

By: Jocelyn Keegan

As the Program Manager for the Da Vinci Project, I get to work with leadership across the many stakeholders represented in our private-sector initiative under HL7. Our core focus is to advance value-based healthcare by enabling payer-provider data transfer. We believe this data sharing required for value-based workflows will be made possible by leveraging HL7® Fast Healthcare Interoperability Resources (FHIR(r)). Da Vinci’s 30+ members include payers, providers and health information technology companies. Da Vinci's open business model process enables members to identify and develop use cases that involve managing and sharing clinical and administrative data between industry partners. With Da Vinci’s alignment with the power of HL7, new and ever evolving business requirements can be translated into national healthcare industry standards.

HealthLX is a founding member of the Da Vinci Project and their team members have taken an active role since its launch in early 2018, best known for its leadership in HIE, EHR and clinical interoperability. I recently had the opportunity to reflect with Will Tesch, HealthLX CEO about his organization’s participation:

Q: I remember meeting you at our first Birds of a Feather at HL7 workgroup meeting.  What drove HealthLX to join the Da Vinci Project?

Will: Value-based care is the next step in the evolution of healthcare in this country, and Da Vinci’s role is crucial in defining the new workflows. We saw in Da Vinci one of the first instances of payers and providers working together on pragmatic, deployable solutions and we wanted to contribute. Argonaut was a forerunner in terms of standardizing data exchange in healthcare, but their electronic health record work is focused within the provider network. Da Vinci is tackling the gap between payers and providers. Radically improving healthcare interoperability is at the core of HealthLX’s mission, so we’re right there working at the intersection of data and that last mile of workflows, where data is transferred between payers and providers. Timely exchange of patient information will help improve outcomes and reduce errors.

Q: Can you share the use cases your team has worked on?

Will: One of the first is the Data Exchange for Quality Measures (DEQM). When patients visit their provider, DEQM enables a digital record of that encounter which can be shared with payers. The first application helps providers and care coordinators create a complete, accurate patient medication record across care settings. This use case is one of the farthest along in the HL7 balloting process.

Another use case we’re working on is the eHealth Record Exchange: Payer Data Exchange (PDex). The goal here is to make it possible for providers to easily access payer data on a patient’s prior healthcare services during the encounter, so providers can more effectively manage the patient’s care.

It’s really important to recognize that the end-goal for the healthcare industry goes beyond sharing data. Sharing data is the first step to creating new workflows that decrease the distance between payers, providers and patients. In a recent article, Gartner analyst Barry Runyon talks about the fact that we’re still in the early stages of leveraging the full value of interoperability. He points out that it’s going to take both “interoperability capabilities and a leadership mindset to share work between and across cooperating systems.”1 I couldn’t agree with him more.

Q. Can you share where you see an organization like HealthLX’s role with Da Vinci?

Will: Our value proposition is enabling last-mile interoperability – the phase when payers and providers share and exchange data to collaborate on value-based care. With Da Vinci, we enable systems to talk to each other, so we’re kind of like Elmer’s glue.

Our team at HealthLX really cares about solving healthcare operational inefficiencies.  At the core are these interoperability challenges, so we want to understand the ‘whys’, not just the ‘hows’, behind workflow innovation. Our participation in Da Vinci helps us decide how we want to build and evolve our products and validates our thought leadership.

Q: Let’s get real. What is it like to be involved in standards development. What is the typical week like for your team?

Will: Our team is currently part of several Da Vinci working groups. Once a week, various people within our team get on a call for about an hour to share updates within each group, troubleshoot and resolve issues to keep moving forward. The end goal is to deliver balloted standards that are ready for testing, adoption and deployment. I believe there are about a dozen use cases at various stages of the process, including those planned for 2019 and for the future.  

Q: Can you help articulate why is it so important for organizations to get involved?

Will: Da Vinci’s work is leading to universally accepted, repeatable workflow models that will drive patient-centric healthcare. That’s invaluable. For organizations that want to lead in creating better healthcare in the U.S., you can’t get any closer to how the industry wants to and will be transforming workflows and communicating data.

Learn about the latest Da Vinci Project work underway and how you can get involved at http://www.hl7.org/about/davinci/index.cfm

  1. Runyon, Barry. Healthcare Provider CIOs: Shift Interoperability Strategy From Moving Data to Orchestrating Workflow. Gartner, February 25, 2019.

New Platform to Help Payers Meet 2020 HHS Requirements for Data-Sharing with Patients

1upHealth and HealthLX Partner to Advance Healthcare Interoperability

GRAFTON, WI (March 11, 2019) - Leaders in the healthcare interoperability space announced today they’re collaborating on a first-of-its-kind platform that will enable healthcare payers to meet stringent new HHS requirements for patient access to electronic health information by 2020. 1upHealth, a Boston-based company providing unprecedented EHR connectivity, and HealthLX, a managed clinical data exchange solution for payers, providers, and software vendors, are partnering to add payer-sourced data to 1upHealth’s FHIR API-based platform. This new data source makes payer data available to the entire spectrum of 1upHealth’s subscribers and users.

“1upHealth is enthusiastic about the proposed rules and hopes to help payers and health plans take advantage of the new-found interoperability through our collaboration with HealthLX,” said Ricky Sahu, CEO of 1upHealth. “We believe that patients have a fundamental right to their data. By enabling patients to share it with apps via FHIR APIs, payers can gain deep insights into healthcare quality and cost, and individuals can access numerous tools to help improve their outcomes.”

“We share 1upHealth’s vision of a freely-accessible personal patient record - it’s something we’ve been passionate about since we entered this space,” said Will Tesch, CEO of HealthLX. “Our collaboration is aimed at helping payers to stay ahead of HHS rules for data-sharing and patient data control, and to expand their commitment to excellence in the member experience.”

Interoperability, or the ability to share data across the healthcare ecosystem, has represented a major barrier for payers and providers in using healthcare data effectively and in allowing patients access to and control of their own personal health information.

Under the new rules CMS-9115-P  for 2020, “All payers, including health plans, should have the ability to exchange data seamlessly with other payers... and with providers….Health plans are in a unique position to provide enrollees a complete picture of their...data, allowing patients to piece together their own information that might otherwise be lost in disparate systems. This information can contribute to better-informed decision making, helping to inform the patient's choice of coverage options and care providers to more effectively manage their own health, care, and costs.”

With their deep experience in FHIR-based interoperability and proven track records for innovation, 1upHealth and HealthLX are well-positioned to solve this challenge.

“1upHealth and HealthLX are both at the forefront of FHIR-based interoperability, but we have very different capabilities,” said Tesch. “We believe our partnership is key in developing the platform payers need to become compliant with the new HHS rules.”

About 1upHealth

1upHealth helps patients, providers and app developers get electronic health data in minutes. Clinical data is connected from 300 health systems and wearable devices across the US. Using the 1up FHIR application platform, developers are able to build connected HIPAA compliant apps in days. Patients can combine health data from hundreds of facilities and share medical data with providers. Providers and researchers can view data in EMR integrated applications or write data back into their EMRs directly. For more information, visit https://1up.health/

About HealthLX

HealthLX™ (Healthcare Language Exchange) gives new healthcare software solutions instant access to comprehensive patient information and real-time analytics by linking legacy data, applications and processes with modern approaches to application integration. The HealthLX platform is built around a software integration engine that is specifically designed for the interoperability needs of the healthcare industry bridging older legacy systems to newly acquired solutions. HealthLX simplifies the effort and cost of new solution integration by configuring application (HL7, X.12, HIPAA) connectors to meet unique client needs. Designed with enhanced levels of transaction monitoring and security the integration platform ensures message integrity and delivery. HealthLX implementation services are provided through its parent company, TESCHGlobal - an experienced healthcare-focused professional services firm specializing in enterprise integration and business intelligence. For more information, visit www.healthlx.com.

For media inquiries, please contact:

Jennifer Behnke

Director of Marketing, HealthLX

jennifer.behnke@teschglobal.com

***


Why Your Healthcare Organization Needs to Catch FHIR Part II

Unlike some technologies that have been talked about everywhere but seldom implemented (blockchain?), FHIR is finding widespread adoption both in systems and in policy. This month, the U.S. Department of Health and Human Services (HHS) proposed new rules to support interoperability and in the process endorsed new rules from CMS and ONC, both of which are built around the FHIR standard. There’s plenty of new reading (724 pages for the HHS rule alone), but how can you apply it to your own institutions and your own systems? What are your institution’s FHIR priorities?

Value-Based Care and the Da Vinci Project

If part of your institution’s mission involves value-based care, the chances are pretty good that you will be focusing on interoperability outside the four walls, and that the Da Vinci Project use cases will be of primary interest. The Da Vinci Project is a private sector initiative (full disclosure, HealthLX is a founding member) tasked with addressing the needs of the value-based care community using the FHIR standard. The goal of the Da Vinci Project is to help payers and providers to positively impact clinical, quality, cost and care management outcomes.

At HIMSS19, members of the Da Vinci Project, successfully demonstrated use cases involving data sharing between payers and providers using FHIR endpoints. These use cases were modified in each demonstration to use different EHRs and different payer systems in order to demonstrate that the same FHIR interfaces can be applied across the industry when the standards are followed. If payer/provider interoperability is one of your priorities, you should pay close attention to the Da Vinci Project use cases as they develop. The use cases can be found here: http://www.hl7.org/about/davinci/.

US Core - The Fundamental Elements of Exchange

Maybe your priorities are not focused around a particular set of use cases.  Perhaps you’re building a new system or are updating an existing system and you just want to be able to share that data using the FHIR standard. Just about every current FHIR implementation is built around some portion of a set of resources referred to as US Core. The US Core implementation guide defines the minimum requirements for accessing data via FHIR and is intended to be the foundation for all US-realm FHIR implementation guides. (It’s also at the center of the new HHS proposed rule.) Whether you are building out your own FHIR server, building FHIR workflows, or working with a vendor, if your solution covers the US Core endpoints you’re off to a good start.

The US Core profiles cover obvious elements such as allergies, conditions, procedures, medications, and results. (For a full list of profiles, visit: http://www.hl7.org/fhir/us/core/.) Each profile specifies the minimum required elements to request the profile, as well as minimum elements that must be returned. For example, AllergyIntolerance has “Patient ID” as the one required argument, but must return: a status of the allergy, a verification status, a code which tells you what the patient is allergic to, and a patient ID. As with most things produced by HL7.org, the documentation is excellent.

Internal vs. External Servers

Most of the use cases proposed by the various agencies understandably focus on interoperability between healthcare entities, but FHIR can be an effective tool for data exchange within your organization as well.  If you work in a large enterprise, it’s not uncommon for your IT programmers to spend hundreds of hours a year integrating internal systems via proprietary APIs.  What if all of your systems used the same interfaces for the same types of data?  Interop programming would become a much simpler endeavor.  So then, it’s quite possible in a large or complicated enterprise that you may want to have more than one FHIR server.  Perhaps you will want a server for external inquiries, and a second or third for internal data integrations. 

Let’s take allergies as an example again.  Suppose that a particular payer institution has two sources for allergy data: a care management system where that data is collected by care management (CM) nurses, and a data warehouse that collects and manages that data from an HIE and other internal and external sources. For an external query, you would want to provide allergy data from the warehouse because it’s going to contain data on more members, not just those in the CM database.  But you probably also want an internal FHIR server which can make the CM allergy data available to the warehouse, because it’s a direct and reliable source.  In fact, for internal queries, you will probably want to ping that source before the warehouse.  The FHIR resources and call syntax are the same, but the server address, the purpose, source and destination are all different.

Build vs. Partner

The technical aspects of FHIR are not too difficult to comprehend, and the decision to create a RESTful API was made in part in order to use a technology that is already commonplace. Therefore, finding trained resources who understand the technologies involved shouldn’t be a difficult task. If your environment is simple, or you have an established team for interoperability programming that is up to the task, all of the tools are publicly available for you get started on your own.

However, consider a partner if any of the following statements are true:

  • You are resource or time constrained but FHIR is still a high priority

  • Your IT environment is large and complex (i.e., multiple clusters, a mix of new and legacy, purchased and home-grown systems)

  • You have multiple sources for the same data types

  • You have internal AND external interoperability challenges 

If any of the above describes your environment, you probably want to consider partnering with a firm to envision and execute your overall FHIR strategy.

As you develop your own plans around FHIR, ask yourself these questions:

  • What are your use cases?

    • Does your plan conform to new and impending regulations?

    • Do you need internally and externally facing FHIR servers?

    • Do you need to consider value-based care (Da Vinci Project) use cases?

  • What are your most trusted sources of data for sharing externally?

  • Do you need to partner, or can you build this with existing resources?

As I mentioned, there is plenty of reading material out there.  I’ve included some primary sources in the links above. I hope this post has helped you focus your research into FHIR and illuminated for you some of the considerations for this type of project.

Why Your Healthcare Organization Needs to Catch FHIR

For many in healthcare IT, FHIR might be viewed as a radical shift in interoperability standards, “yet another standard” that requires retooling of multiple systems.  For those institutions and individuals who have been working in the healthcare interoperability space for years (and for some of us decades) it can be viewed as a natural and welcome evolution of the standards, and an evolution that brings with it many benefits we have sought for years.

The Medium is the Message

First attempts at interoperability between systems involved parsing messages.  Message standards allow data sharing in its most basic form, the only drawbacks being timeliness (messages must be published and “listened” to so real-time integration was elusive at best), and customization of messages. Standardized message formats like HL7 (and I include document specifications in this definition) are still the most popular method of data sharing between systems, despite these drawbacks.

Standardization of messages though, even with a specification as well designed as HL7v3, has its limits.  Z-segments, designed to allow customization of the standards, are very commonly used to carry data that is actually covered elsewhere in the specification. Re-use of “unused” segments is also common.  These types of customizations are harmless for interoperability within the four walls of an IT organization. In this context, customizations can be standardized across all systems that will consume the messages.  It can be messy but it’s manageable. However, this breaks down the minute those messages need to be shared outside of the originating IT organization.

And then sometimes the four walls move.  As designers, we tend to think of our own IT organization as the center of the integration universe.  Due to that fact, few integration designers have ever thoughtfully considered the possibility of a merger of institutions when architecting their message-based solutions. Even when we do consider it, we tend to assume that “our” standards will prevail. The result is usually a tangle of confused standards that has to be continually re-scripted as the systems evolve.  If you believe that your own IT organization is slow to roll out upgrades, this could well be one of the main causes.

APIs and the Quest for “Real-Time”

I always feel like “real-time” should be in quotes because it is defined contextually.  Usually though, it refers to request-based as opposed to event-based integration. For illustration purposes, we can generalize that messages are generated based on events, an admission, discharge, order, etc. Other systems can listen for these events and capture the messages, or they can filter through messages historically and look for particular events. A real-time integration is usually request-based.  One system requests data from another system as needed.

In the pursuit of more real-time integration, in the last 10 or so years, API (Application Programming Interface) based integrations have become more popular.1  The decision by some large EMR vendors to open up their system APIs to outside consumers has provided more meaningful and actionable integrations for the end users. Simultaneously, it also provides stickiness for the associated EMR vendor.

Vendor-specific API integrations provide the greatest flexibility and leverage of existing systems.  However, they are also expensive to create and maintain. Part of that expense comes from the skill set required to build those integrations in the first place.  Where message-based integrations may often be built and maintained through configuration of a tool designed for message handling (i.e., an enterprise service bus), potentially combined with some form of scripting, API integrations require a coder’s skill set which is often more expensive. Additionally, each vendor’s API will have its own structure for calls to that API.  That is, the code required to query a system for something like patient allergies can be completely different for each system. It may require different arguments, multiple lookup calls, different security protocols, etc. The fundamental architectures could also differ (SOAP vs. RESTful). In addition, some APIs may be accessible from the web, and others not.

FHIR Evolution

FHIR (Fast Healthcare Interoperability Resources) aims to bring together the best aspects of message-based and API-based interoperability into one standardized API. As such, FHIR combines the standardization of an HL7 message with the real-time request-based structure of an API. From the HL7.org/FHIR website:

“(FHIR) is designed to enable information exchange to support the provision of healthcare in a wide variety of settings. The specification builds on and adapts modern, widely used RESTful practices to enable the provision of integrated healthcare across a wide range of teams and organizations.

The intended scope of FHIR is broad, (and) … is intended for global use and in a wide variety of architectures and scenarios.”

FHIR is:

●       An API addressable via http protocol, i.e., a web-based API

●       A standardized API built around a set of defined resources backed by HL7.org

●       A flexible API in that resources are standardized, but the returned data is customizable based on the request

This allows developers/integrators to build applications based on data from disparate applications using the same API calls throughout.  FHIR improves on message-based interoperability by providing real-time request-based access that is backed by standards. It improves on proprietary API implementations in that the structure of the calls is standardized for each resource. This level of standardization allows a single developer to build an application that can pull data from numerous discrete sources.  The sources themselves can be from across the institution or from across the world.

Perhaps the best illustration of this concept is the most prevalent real-world example, the Apple Health app. Apple Health is an app for the iPhone which recently added the ability (in beta test) to hold all of a user’s medical records.  The records are gathered from participating institutions using the FHIR standard. (Apple Health uses Draft Standard for Trial Use #2 of FHIR.  The current version is DSTU3, with DSTU4 destined to be the first production ready version.) Included resources are: allergies, conditions, immunizations, lab results, medications, procedures, and vitals. Because of the FHIR standard, information can be collected from multiple institutions without having to write code that is institution specific. Within my own record, I can view procedures performed in multiple locations and institutions within the same view, and I can trace those records back to their originating source.  A standardized API makes all of that possible.

That same standardization can work for integrators inside of their own IT walls in ways that are just as impactful.  Most institutions have a combination of vendor and home-grown systems spanning any number of technologies from the last two decades.  Imagine if building an application that draws data from those systems could be as easy as creating a web page. If all of those systems provide FHIR end-points (and also participate in the same security paradigm), it can be just that easy.  With a standard as flexible and powerful as FHIR, we are likely to see rapid progress in its adoption. In fact, with Apple and its participating healthcare providers, it’s already happening on a national scale. This adoption will likely be limited more by each institutions ability to publish FHIR interfaces than by any other factor.

What’s Next?

FHIR is revolutionary in our journey to more patient-centered, data-driven healthcare in the U.S. It has reached a tipping point with its adoption by 82% of hospitals, the ten largest electronic health vendors, the Centers for Medicare and Medicaid Services, and a majority of clinicians.

Check back for Part II in this three-part blog series where we take a deeper dive into FHIR and the challenges it poses for healthcare organizations who are slow or roadblocked to change. In Part III, we’ll share implementation and adoption strategies you can use to put FHIR to work for your organization.

1.      Roy Thomas Fielding, the originator of the REST standard describes an API this way:            

“A library-based API provides a set of code entry points and associated symbol/ parameter sets so that a programmer can use someone else’s code to do the dirty work of maintaining the actual interface between like systems, provided that the programmer obeys the architectural and language restrictions that come with that code.” (Source.)

An API can be thought of as a set of code objects addressable by other systems through a programmed interaction.  In some cases, vendors have chosen to make public the very objects that comprise the fundamentals of their systems, i.e., they publish the same objects used by their own engineers.  In other cases, they have provided a specific API that is only used by third-party applications. Both methods provide the same benefits to end users.

An API-based integration is preferable for real-time integrations because the data may be requested from the API as needed rather than listened for as with a message.  This is request-based integration as opposed to event-based. This allows other systems to call on data as needed and in real time. For example, an order system in a walk-in clinic may want to request allergy information at the time the order is created from a local hospital that treats many of the same patients.  Some vendors have gone as far as to include hooks for integrators to insert their own custom workflows and screens. For example, a user may wish to view notes from an outside system when updating orders in the primary system.

About HealthLX

HealthLX is a company born from years of integration experience and is completely dedicated to healthcare interoperability.  The architecture of HealthLX is highly scalable and extensible, bringing HealthLX dataflows to a potential myriad of devices and systems. HealthLX – FHIR Starter™ can place FHIR compliant interfaces in front of your legacy and homegrown systems

By exploiting our architecture, specialized data flows can be built to share information between care management platforms, payer systems, provider EMR systems, mobile applications, big data repositories, and more.



News: Da Vinci Project to Advance Value-based Care

ANN ARBOR, Mich., Sept. 5, 2018 /PRNewswire/ -- Over 20 health care companies have formed the Da Vinci Project, a private-sector initiative that is leveraging HL7 Fast Healthcare Interoperability Resources (FHIR®) to improve data sharing in value-based care (VBC) arrangements via two initial test cases.

Stakeholders clearly understand the criticality of working together to define a common set of standards that can be implemented on a national basis. The project will minimize the development and deployment of one-off solutions between partners with a goal to help medical groups and health plans better deliver on clinical quality, cost and care management outcomes. The HL7 FHIR technology enables easier sharing of health information across plans and practices, reducing duplicative tests and supporting better health outcomes. 

Da Vinci Project Founders and Governance 

The Da Vinci Project was founded by the following health plans, care providers and vendor organizations: Allscripts, Anthem Blue Cross and Blue Shield, Blue Cross Blue Shield Association, Blue Cross and Blue Shield of Alabama, Blue Cross of Idaho, Cambia Health Solutions, Cerner, Cognosante, Edifecs, Epic, Health Care Service Corporation, Health Level Seven (HL7) International, HealthLX, Humana, Independence Blue Cross, Optum, Rush University Medical Center, Surescripts, UnitedHealthcare and Zeomega. For a full list of members visit: http://www.hl7.org/about/davinci/members.cfm.

The Da Vinci Project, hosted by HL7 International, operates independently but collaborates with HL7 work groups to ensure feedback into FHIR standards. As a founding member, HL7's leadership team provides critical support to ensure, where appropriate, that the project's implementation guides will be balloted through the HL7 process to become open industry standards.

Chief Information Officer, Rush System for Health and Rush University Medical Center, Dr. Shafiq Rab said, "Da Vinci is a collective initiative of concerned, diverse market leaders that include payers, providers, HL7 and EHR vendors that understand how critical it is to put forward and employ standards that promote data exchange in real time. These efforts will enable data to be available at the right time to the right person every time securely.

"This level of collaboration across payers and providers is unprecedented and will have a tremendous impact on how we use data to improve health care while keeping the architecture simple. Da Vinci members are selecting the most relevant use cases that will showcase the effectiveness of its solutions. The initial success has been over joyous, and I believe that such act of selflessness is what our nation needs," Rab said.

The founding member organizations have established a formal governance model for Da Vinci, which includes both steering and operating committees. The Da Vinci operating committee is responsible for the project's day-to-day activities. The steering committee approves recommended business case priorities, consultant resources, contracts required and obligations necessary to complete projects based on the recommendations received by the operating committee.

Sagran Moodley, UnitedHealthcare senior vice president of Clinical Data Services and Technology, serves as the chair of the steering committee. Jocelyn Keegan, payer practice lead at Point-of-Care Partners, acts as the Da Vinci program manager. Dr. Viet Nguyen, founder of Stratametrics, serves as the project's technical director.

"We are thrilled with the initial participation and interest in the work of the Da Vinci Project. The support demonstrates the shared understanding from industry stakeholders that health plans and care providers need to have in common and well-defined ways to exchange critical data in order for the focus on value and outcomes to succeed," said Keegan. "We believe the flexibility and specificity of HL7 FHIR and its underlying resources will enable our partners to define targeted use cases to power standard-based approaches to share the minimal data required by these new contracts and partnerships."

Da Vinci Project Use Cases 

To promote interoperability across VBC stakeholders and to guide the development and deployment of interoperable solutions on a national scale, the industry needs common standards such as HL7 FHIR, implementation guides and reference implementations. The Da Vinci Project has identified two initial use cases currently underway:

  • 30-Day Medication Reconciliation Medication reconciliation programs can reduce the incidence of adverse drug events after discharge. The objective is to create a simple workflow that enables care providers to indicate a 30-Day Medication Reconciliation was done for a specific patient on a specific date.

  • Coverage Requirements Discovery Coverage discovery enables care providers to request and receive information on health plan coverage requirements at point of service.

"Value-based care promotes better patient results at lower costs, and it relies on timely data sharing between doctors and health plans," said Moodley. "The associated data-sharing capabilities support physicians in a number of ways, including enabling them to see patients' benefits in real time, improving medical record exchange and reporting, informing clinical decisions at the point of care, and helping them reduce administrative burden."

Significant progress was made on the initial use cases at a project meeting in Cleveland, April 30-May 1, 2018, and subsequent sessions in Cambridge, Massachusetts, June 21-22, 2018. The Da Vinci team received project scope statement approvals at the May HL7 International Conference and Working Group Meeting and has submitted the initial drafts of the implementation guides in the current September 2018 ballot cycle. The team will bring the initial implementation guides and reference implementations for use at the September HL7 FHIR Connectathon in Baltimore.

About the Da Vinci Project

The Da Vinci Project is a private sector initiative comprised of industry leaders and health information technology technical experts who are working together to accelerate the adoption of HL7® FHIR® as the standard to support and integrate value-based care (VBC) data exchange across communities. The core focus of phase one of the project is to deliver implementation guides and reference software implementations to the public for data exchange and workflows necessary to support providers and payers entering and managing VBC contracts and relationships.

To learn more about the Da Vinci Project, visit www.HL7.me/davinci.

About Health Level Seven International (HL7) 

Founded in 1987, Health Level Seven International is the global authority for health care information interoperability and standards with affiliates established in more than 30 countries. HL7 is a nonprofit, ANSI accredited standards development organization dedicated to providing a comprehensive framework and related standards for the exchange, integration, sharing, and retrieval of electronic health information that supports clinical practice and the management, delivery and evaluation of health services. HL7's more than 2,000 members represent approximately 500 corporate members, which include more than 90 percent of the information systems vendors serving health care. HL7 collaborates with other standards developers and provider, payer, philanthropic and government agencies at the highest levels to ensure the development of comprehensive and reliable standards and successful interoperability efforts.

For more information, please visit: www.HL7.org

What Exactly is Value-Based Care?

Before we talk about value-based healthcare, let’s first get a basic understanding of the current provider-payer-patient relationship. Traditionally, providers (physicians, hospitals, and the like) are reimbursed via a fee-for-service model. It looks something like this:

  • Provider bills for services (an office visit, ordering a lab test, outpatient surgical procedure, admission to a hospital) they perform

  • Payer pays for these services

  • Patients pay a portion per their health plan

Simply put, you pay for what you use. The overwhelming sentiment of providers and payers is that fee-for-service no longer works and value-based care is going to fix the healthcare system.

UNDERSTANDING THE FLAWS IN FEE-FOR-SERVICE

The fee-for-service model isn’t without flaws. Because profit comes directly from the services performed, healthcare providers may be swayed to perform more and more services, some of which are unnecessary. Have a headache? Let’s get a CT scan. It’s rare a patient will reject a physician’s orders if they deem a service necessary. But this ends up in expensive procedures, most of which could have been avoided.

More services also means a need for sick patients. Providers are not incentivized to keep patients healthy but instead to have sick patients. The more sick patients, the more office visits, labs, and procedures. This doesn’t mean that physicians are practicing in a harmful way, but it may suggest that financial incentives are improperly aligned.

DEFINING VALUE-BASED HEALTHCARE

So, what is value-based care and how does it differ from fee-for-service? The core of value-based care is a changing reimbursement model that pays providers based on the quality of care that is provided. There are several variances of this model:

  • Pay for Performance. An extension of fee-for-service, the provider is still primarily paid based on services plus they receive bonuses or penalties based on the quality of care provided. This model was pioneered by Medicare with the Physician Quality Reporting System (PQRS; replaced by the MACRA/MIPS program). Through PQRS, providers received bonuses (or paid penalties) as a percentage of their Medicare billings based on quality measure results. This doesn’t eliminate fee-for-service, but it does hold providers accountable for the quality of care being delivered. Plus it monitors overuse or reduction of unnecessary services by penalizing providers when those actions are not clinically appropriate (such as unnecessary imaging or prescribing antibiotics)

  • Bundled Payments/Capitation. While there are differences between options, the concept of these models is that a payer will pay a provider/hospital/health system one lump sum for a group or bundle of services. It is then up to the health system to deliver the care for those services. The payment never changes based on the amount or type of services actually provided which incentivizes providers to be efficient in their care delivery as they will not be paid more for extra services. This model is common for episodes of care like a knee replacement surgery.

  • Shared Savings. In this model providers can receive an additional payment if actual costs incurred are lower than projected or benchmarked costs. The savings are split between the payer and the provider. Medicare and Medicaid have paved the way with their shared savings program at accountable care organizations (ACOs).

Quality of care is a major component for value-based care and payments to work. In a bundled payments or shared savings model it is critical to measure quality of care being delivered to ensure that necessary services are not bypassed simply to meet spending goals.

Measuring quality of care is nothing new, payers have long been measuring quality based on claims data. Through claims analysis, payers can easily assess when certain procedures have been performed. But claims data only goes so far in helping you measure quality.

For example, if payers are reimbursing for a large group of patients that have diabetes, a claim can tell the payer if a blood sugar A1c test was performed, but it won’t tell you if the patient’s blood sugar value is under control. To effectively measure quality you need clinical data from an EHR. With clinical data, you have access to data like lab results, blood pressure values (no claim is submitted when taking a blood pressure) and social history such as if a patient is a smoker and if they are were they given cessation counseling.  

This is the differentiator when it comes to value-based care: combining clinical quality data with cost and utilization data.

LEVERAGING INTEROPERABILITY

To successfully combine all the cost and quality data, it’s important to enable multiple systems to talk to each other. Data from claims, practice management systems, EHRs, outside labs, and so on need to be integrated to paint a full picture of value. This remains one of the biggest challenges in healthcare today.  

Great strides are being made with initiatives like the new Fast Healthcare Interoperability Resources (FHIR) standard developed by HL7. FHIR is an open and free standards framework designed to ease the burdens of interoperability. Built using standards like XML and JSON with a focus on ease of implementation, FHIR looks to be a key tool in building value-based care and payment systems for healthcare providers and payers.

At HealthLX, we are proud to support FHIR and HL7 initiatives. HealthLX is a Da Vinci stakeholder working with other industry leaders and health IT technical experts to accelerate the adoption of HL7 Fast Healthcare Interoperability Resources (HL7® FHIR®) as the standard to support and integrate value-based care (VBC) data exchange across communities.

Value-based care is a critical component to fixing our healthcare system. Bringing new payment models, combined with quality measurement and population health, using standards to promote interoperability will create great change in providing better patient care.

News: Casenet and HealthLX Partner to Launch TruCare Linx for Care Management Clinical Interoperability

BEDFORD, MA – June 24, 2015 – Casenet®, LLC, a leading provider of extensible care management solutions, today announced a partnership with HealthLX™ to deliver TruCare Linx™, a new integration engine solution for the healthcare market. TruCare Linx powered by HealthLX provides a proven suite of pre-built components to support the integration of TruCare to existing clinical systems including health information exchanges (HIEs) and electronic medical records systems (EMRs).   

The TruCare Linx integration engine is capable of using a wide range of data message schemas to support HL7, X.12, XML and custom data mappings. The TruCare Linx Standard ADT Message Suite provides a flexible means to accept the HL7 hospital admissions, discharges and transfers (ADT) messages commonly used for care management integration. This approach enables TruCare to be deployed without being dependent on customized backend integration and enables real-time or near real-time notifications of clinical events. TruCare Linx, which is designed specifically for TruCare, can be delivered as an on-premise or hosted-software integration engine to meet the unique needs of Casenet clients.

“We are excited to be partnering with Casenet,” states Will Tesch, CEO of HealthLX and TESCHGlobal. “It is critical for us, all of us, to fully use and leverage health data that is vital to improving patient care.  The power of TruCare combined with the TruCare Linx integration engine delivers unprecedented integrated care management capabilities to the care management market.  This collaboration will help discover and develop better treatments  while improving safety and quality in the delivery of that care.”

Effective care management is facilitated by access to timely clinical information. Understanding and managing changes in member status (such as a pending discharge from a hospital to a skilled nursing facility) allows for more effective care coordination as well as cost management. Additionally, increases to the speed and accuracy in which changes in member status (such as a move to inpatient) can be conveyed to a health plan will enable more effective management of that member resulting in better clinical outcomes and ultimately lower costs. 

TruCare Linx further expands Casenet’s ability to improve care coordination between providers, care managers, coaches, pharmacists, families and members. With a single platform for utilizationcase and disease management, Casenet delivers unmatched flexibility to implement, coordinate and manage clinical, wellness and quality programs. Using TruCare Linx and its current native web services, TruCare can now be more easily integrated with other systems including EMRs, HIEs, predictive modeling and analytic tools, mobile monitoring devices and collaborative care partner systems enabling a holistic view of all members. As a result, TruCare offers an unparalleled intersection of member data, clinical content, business rules and workflow which makes it unique and which raises the bar for care for all members. 

“We are pleased to be partnering with HealthLX,” said Peter Masanotti, Casenet CEO. “By enabling real-time or near-real time access to data from other clinical and administrative systems via TruCare Linx, TruCare will provide care teams with a complete view of its members, enabling truly integrated care management. The result is improved care coordination, member engagement and outcomes as well as reduced time to intervention and cost.”  

 About Casenet, LLC
Casenet provides a comprehensive suite of extensible, enterprise care management software and services solutions for commercial, Medicaid, Medicare, TPA, provider/ACO and carve-out organizations. These solutions enable our customers to improve care coordination and the quality and delivery of care through enhanced case, disease, utilization and home and community-based services management as well as tools for total population management. Casenet supports small to very large enterprise customers that require tremendous scalability, have many lines of business with benefits that are complex and complicated to administer, and require comprehensive configuration for each targeted member population. These solutions enable organizations to meet their unique requirements and adapt quickly to changing market and regulatory dynamics, identify and target populations having distinct risk characteristics and deliver specific care management programs for those members — taking the first step toward better individual health and total population health management. For more information, visit www.casenetllc.com.

Casenet Media Contact:

Kelli L. Bravo, 781-357-2706, kbravo@casenetllc.com

About HealthLX

HealthLX™ (Healthcare Language Exchange) gives new healthcare software solutions instant access to comprehensive patient information and real-time analytics by linking legacy data, applications and processes with modern approaches to application integration. The HealthLX platform is built around a software integration engine that is specifically designed for the interoperability needs of the healthcare industry bridging older legacy systems to newly acquired solutions. HealthLX simplifies the effort and cost of new solution integration by configuring application (HL7, X.12, HIPAA) connectors to meet unique client needs. Designed with enhanced levels of transaction monitoring and security the integration platform ensures message integrity and delivery. HealthLX implementation services are provided through its parent company, TESCHGlobal - an experienced healthcare-focused professional services firm specializing in enterprise integration and business intelligence. For more information, visit www.healthlx.com.

HealthLX Media Contact:

Brian.Bezanson@healthlx.com

Learn more about TruCare®

Request a demonstration and find out how TruCare can improve your member health

Patients and care providers are missing opportunities to improve people’s health and welfare when information about care or health status is not  easily available. It is critical for us, all of us, to  fully use  and leverage the health data that is vital to improving patient care. Doing so will help us discover and develop better treatments  while improving safety and quality in the delivery of that care.

News: C-CDA Award

HealthLX is pleased to announce its selection by HL7 International and the Office of the National Coordinator for Health Information Technology (ONC) as runner-up entrant in their C-CDA Rendering Tool Challenge.

HL7's Consolidated Clinical Document Architecture (C-CDA) standard defines structure and semantics for the exchange of clinical documents by healthcare providers and patients.

This challenge aims to alleviate clinician frustration with the usability of C-CDA documents.

While this information is critically important to the delivery of high-quality care and timely decision making, the wide variety and volume of data contained in these documents creates a challenge for clinicians who need to sort through this data effectively and quickly.

To rapidly address this problem, this challenge was created to develop an effective C-CDA viewer which can rapidly optimize the usability of this critical information.

As runner-up in the C-CDA Rendering Tool Challenge, HealthLX is to be awarded $5,000 by HL7 International for its submission.

"I could not be more pleased with the performance of our team" stated HealthLX CEO Will Tesch. "Our team responded to HL7's challenge in 30 days and competed against 45 other entries.”

Our C-CDA viewer entry, "Patient Insight 1.0", addresses improvements in three critical usability areas:

  • Viewing and interacting with large amounts of CCD information

  • Viewing multiple source schemas (EHR specific, standard, and nonstandard schemas) in one programmatic interface

  • Create the resulting solution with open source technology.

As a result, CCD information can be of much higher value to clinicians and care managers in delivering care to patients and members from both quality and time perspectives.

HealthLX will be including “Patient Insight 1.0” as an important care management addition to its HealthLX Healthcare Service Bus (HSB) integration and data management solution and will issue a separate press release regarding its availability.

ABOUT HEALTH LEVEL SEVEN

Founded in 1987, Health Level Seven International (HL7) is a not­-for­-profit, ANSI ­accredited standards developing organization dedicated to providing a comprehensive framework and related standards for the exchange, integration, sharing, and retrieval of electronic health information that supports clinical practice and the management, delivery and evaluation of health services. Learn more at ttp://www.hl7.or.

ABOUT HEALTHLX, INC.

HealthLX, offers a full integration solution set designed for Healthcare software solution firms to bridge the gap of interoperability and innovation, necessary to enable them to quickly implement their solutions in diverse environments. HealthLX’s solution­ set includes open source integration software that creates and manages connections and data­flows, integration consulting and connectivity services, and solution management. For Healthcare software solution firms that want to make integration a differentiator, visit ttps://www.healthlx.co.

Our Role in Healthcare Innovation

The way healthcare data is organized today is highly complex and not change ready. There is little to no governance which leads to multiple truths, broken systems, and maintenance and upgrades that can be extremely costly.

Specialization and increasing industry change are forces that continue to contribute to the problems of connecting applications and their data. Whether you are a local or state government, public health organization, healthcare provider or payor, the exchange of clinical information will be critical to meet both regulatory and business viability in the future. Unstable data systems create an environment where both personal security and compliance can easily be breached and we need to avoid this at all costs.

Your future, along with the future of today’s healthcare recipients, depends on choosing the right integration governance solution that efficiently creates and manages intelligent integrations, adequately manages those integrations, and effectively manages and monitors ongoing dataflow.

Doing our part to make a difference in our data-complex world, we developed a revolutionary healthcare product, HealthLX (Healthcare Language Exchange), that was designed with three critically important integration governance capabilities:

  1. Integration connectivity that supports a broad level of service orchestration and data integrity between source and target applications.

  2. Effective HIPAA compliant security between systems supporting enterprise-wide auditability and application service level management.

  3. Monitoring and management of dataflow at the transaction level for enhanced visibility for system-wide performance measurement.

Creating Integrations: HealthLX leverages modern integration best practices and Open-Source technologies to create intelligent connectors that interface source data and external APIs. As a result, creating new integrations is easy and repeatable.

Managing Integrations: Existing connections need to adapt over time to changes in data sources, API’s and functional applications. Because connections are mapped inside the HealthLX integration hub, updating and changing integrations is easier to accomplish.

Managing Dataflow: HealthLX’s management dashboard provides an audit trail of every transaction that passes through it and flags failed transactions providing high levels of security and compliance.

CONNECTING THE WORLD, ONE INNOVATION AT A TIME.

Your Clients are Looking to You for Integration Leadership

It might seem daunting, since transaction and data integration may not be in your wheelhouse, but potential prospects and customers are looking to you for integration leadership.

If you are selling software solutions into the healthcare market, you are selling into a crowded and growing space. Decision cycles get extended, pricing pressures are greater, and the need to interoperate with external systems and data sources is more complex than ever. In addition, integration's rapidly growing importance is moving the market to a much more prominent role in selections and negotiations.

Being in a position to see a number of in-flight software deals, I can assure you that now is the time to turn integration into a competitive advantage for you and your solution.

Here are some recommendations for making this happen:

  • Start by making integration a part of your early-stage qualification process

  • Be prepared for one or more of your competitors to make integration an issue

  • Prepare yourself to be the competitor that uses integration to create competitive advantage

These are fearful propositions because integration may not be a strength for you or your organization, it may slow down the sales process, and your prospective client may not be giving signs that it's a big deal.

Tips on getting started down the path of integration leadership:

  • Understand that nobody has all the answers or solutions - so nobody expects you to know or have all the answers

  • Discover who the thought leaders and forces are that are bringing integration to the forefront (see Will Tesch's latest blog entries for ideas)

  • Determine who in your organization has the most integration knowledge and spend time with them to gain additional insight

Our experience shows that knowledge and understanding are key elements to becoming an integration leader. Remember, your clients are looking to you for solutions and integration leadership plays a big role in gaining that competitive advantage.