Have you considered NiFi for your data integration needs?

With legislative and business pressures for interoperability heating up this year, payers are searching for the right data integration solution. Though Apache NiFi has been available for about five years, it’s still a virtually unknown data integration platform in the healthcare industry. HealthLX uses the NiFi open-source tool as the foundation for our core platform, and we believe it’s worth a closer look for solving modern large-volume and large message-size healthcare data flow challenges.

NiFi’s Big Data Benefits

NiFi grew out of the NSA’s NiagraFalls data flow platform and was released as an open-source system in 2014. NiFi takes a blackbox approach similar to other integration platforms, but here’s where it’s different: Boxes in NiFi are loosely coupled, allowing users to separate their data flow and put each step on a dedicated server. By optimizing NiFi in this manner, organizations can effectively manage their high load requirements, a feature that seems tailor-made for handling high volumes of healthcare data at scale.

What else do we like about NiFi for healthcare data integration?

  • 10X faster integration – NiFi’s building blocks are process-oriented rather than detail-oriented, enabling a higher-level, process-based integration that is remarkably faster than other platforms without any loss of functionality.

  • Data provenance – NiFi delivers an unprecedented amount of data lineage, which is becoming ever more essential in healthcare. NiFi gives up to 100X more provenance data than the original data.

  • Extensibility – users can rapidly develop and test extended code functionality that supports their organization’s specific business processes and goals. This same extensibility can be built into product suites like HealthLX that rely on NiFi for core workflows.

  • Reliability – NiFi persists everything to disk, so there’s no risk of losing data or transactions, which is an essential capability for the healthcare industry.

  • Security – NiFi has a mature security model, and gives organizations fine-grained control over viewing and modification access.

  • It’s free – NiFi is open-source technology that’s actively developed and well-supported by a large open community. It is a key component of Cloudera’s (Hortonworks) Hadoop large-scale data movement platform.

Graphics Slides (11).png

NiFi may be a well-kept secret for now, but it’s likely to see rapid, widespread adoption as more health organizations come to understand its distinct value in big data processing and distribution. If you’d like to learn more about moving interoperability forward in your organization, please reach out. We’d love to start the conversation with you.

HealthLX 3.0 Expands Functionality to Enhance Interoperability for Healthcare Payers and Software Vendors

New Features to Improve Workflow Design and System Transparency

GRAFTON, WI (June 25, 2019) – Healthcare interoperability leader HealthLX (HLX) today announced the release of version 3.0 of its core platform. HealthLX is a managed clinical data exchange solution that drives business agility and advantage for payers and software vendors looking to achieve healthcare interoperability. With an innovative core platform and seamless add-on solutions like Care Linx, Document Exchange and FHIR Starter, HealthLX takes organizations through the “last mile” of integration between payer and provider systems.

HealthLX 3.0’s innovations remove roadblocks to interoperability for its customers. Workflow Designer enables business users to design clinical workflows based on the high-level business processes they understand without needing knowledge of the underlying technology that will support the workflows. These visualizations can become the starting point for collaboration in cross-functional teams working to improve the patient and provider experience in support of value-based care objectives.

“We’ve seen time and again that the exchange of ideas between business and CX leaders and IT teams around workflow innovation is a challenge because of the high complexity of healthcare,” said Will Tesch, CEO of HealthLX. “Workflow Designer combines an advanced whiteboard with purpose-built workflow designs to help teams visualize their new workflows and prepare for their implementation in a way that supports interoperability.”

Another new feature, the Management Console, is a dashboard that provides greater transparency into the data moving through the overall system. This gives visibility to the system performance so that IT teams can maintain compliance for their organizations without building these capabilities themselves. With active remote monitoring enabled by the Console, IT teams can ensure data exchange is occurring with optimal efficiency and without errors to enhance data management.

“The Management Console extracts all of the system performance detail in real-time to a simple dashboard that enables IT teams to manage their application without needing expertise in the back-end technology,” said Charlie Provenzano, HealthLX Chief Operating Officer. “The Console also allows customers to set up alerts when pressure on the message queues exceeds certain thresholds, so they can actively manage the system to prevent issues.”

“Part of the HealthLX commitment to interoperability is continually enhancing our platform and services to help our customers overcome potential roadblocks and accelerate toward their goals,” added Tesch. “That last mile of interoperability is always the most difficult. We do whatever it takes to help them get there.”

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



Why Your Healthcare Organization Needs to Catch FHIR Part III

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:


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.  

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

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



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. Click here to continue reading and check out Part III.

In case you missed it, check out Part I.

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.


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.


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.


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:


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.