HIStalk Interviews Jeremy Pierotti, CEO, Sansoro Health

Jeremy Pierotti is co-founder and CEO of Sansoro Health of Minneapolis, MN.

Tell me about yourself and the company.

I grew up in Madison, Wisconsin. I went to school out East, then worked in healthcare policy in Washington, DC after college. I then moved to Minnesota for graduate school. Despite promising my wife that we would be here for only two years, that was 1996, and we’ve been here in Minnesota for 22 years.

We started the company in 2014. We knew that the next generation of digital health solutions would require data liquidity. We thought we had an innovative way of providing advanced data exchange between health IT applications. I had no actual skills since I’m not a physician and I can’t code, so when I showed my partners how to move a PowerPoint slide backwards and forwards, they told me I should be CEO.

How widely are APIs being used in healthcare?

We’re seeing them adopted at an accelerating pace. We’re excited by it. I’ve always believed that in healthcare, we adopt treatment technology eagerly and deploy it pretty rapidly. New information technology has been adopted more slowly. But now we are counting on digital health solutions to help us deliver better outcomes with lower costs, higher patient satisfaction, and higher provider satisfaction. Recognition is now widespread that this will happen only with secure, seamless exchange of data between applications. In manufacturing, retail, logistics, and financial services, that’s all done through APIs. We are seeing more rapid adoption of that in healthcare, too.

Do EHR vendors make it easy for customers to integrate their products with those sold by other companies?

To some extent, yes. Most of the major EHR platforms have API or developer programs. Some are more robust than others. It depends on the business strategy of the company and the other demands that are on the company. A lot of regulatory requirements have been placed on EHR vendors over the last 10 years. That has consumed a lot of engineering and product development time within those teams.

Our goal at Sansoro is to provide a universal API so that great developers and great healthcare software companies can write to a single API standard. Then we will handle the nuances of getting the data out and putting the data back into the EMR. As a developer, you don’t have to learn the different APIs and the different integration approaches of each vendor.

I saw you your site that Emissary doesn’t update EHR tables by scripted inserts or updates, but instead uses the vendor’s back-end service to preserve their validation logic. What are the use cases for updating the EHR database and do other methods do direct database updates?

I don’t know whether other companies are doing direct table inserts. Our team is a collection of experienced health IT personnel who know how to create safe application. We’ve all been working with health IT for 20, or 30 years per person. Our approach has been to use the back-end services to make it a safer process. We also get to take advantage of the work that’s already been done by the EHR vendor in terms of the updates.

Examples of what we allow for writing data to the EHR would be discrete observations, documents, and notes. Pretty straightforward stuff, but important. In most provider systems, the EHR is the system of record, so it’s important to get key data into the EHR itself. That’s the operating system for a provider.

Our secret sauce is doing the hard work of mapping the data structures of all of the different EHRs that we support into a unified data model. That’s the holy grail. That’s why we can provide a single API in which an engineer can read data from different vendor platforms and write data back to different vendor platforms without having to know the nuances and differences between those vendor platforms.

What are the most-request API integrations and also the most-desired that aren’t yet available?

We see three common use cases across our customers and prospects.

One is pretty simple. We want to pull patient charts. We typically will have to do an extract, run a database report, or send personnel into the clinic or hospital to print out the chart or print it to a PDF. Being able to pull that chart for quality reviews, medical necessity reviews, and release of information — just being able to pull the basic patient chart — is a standard need and use for our APIs.

The second is for advanced analytics. Basic patient chart information, but with additional information. What clinic or department was this patient in when this procedure was performed? What is the provider’s background? Then combine historical information with real-time information to create a dashboard back to the provider in real time, with insight about the possible best treatment for this patient or how the patient’s condition is improving or deteriorating. Real-time analytics, pulling both historical data and data that’s up to the minute from the EHR or from other data sources to provide those exciting insights for clinicians for administrators.

The third and broadest use case involves workflow improvement. Probably 200,000 prior authorizations are submitted every day in the United States. You print out a bunch of information from the patient’s chart, fill out a prior authorization cover sheet by hand, and fax it into the payer. Then the payer has a person who adjudicates that prior authorization. Often, the the approval will be snail-mailed back to the provider. Not really up to 21st century speeds.

Workflow improvement is using our integration platform to listen for orders, determine if those orders require a prior authorization based on the patient’s insurance, and if so, grab only the data that’s needed from the chart to adjudicate that prior authorization, and then push the approval number back into the patient’s chart. All without any further human intervention. Once the provider places the order in the EHR, the rest happens automatically. That’s a great workflow improvement that saves hours for every prior authorization request.

Another great workflow improvement involves unified communications. Lots of companies provide communications tools that augment the EHR tools, whether it’s Vocera, Voalte, PatientSafe Solutions, or Spok. There’s a pretty good list of vendors that have great tool sets. Enhancing those tool sets to send those messages to the right clinician with appropriate context. Here’s a lab result for the stat order you placed, but in addition to this lab result, we’re going to include the last three results for that same lab test so you can put this result in context. Also, here are the patient’s most recent vital signs and here’s the medication list.

As a provider, you’re not getting a call from the lab with the lab result and then having to log into the EHR to find all that information manually. Instead, it’s delivered to you on your smartphone. As a clinician, that saves you a lot of time and allows you to make a decision faster about the appropriate treatment for that patient.

The FHIR standard is even further entrenched now that Apple is using it to populate Health Records. How does FHIR fit into the overall needs for interoperability?

We believe in a “FHIR and more” approach. Our integration platform, we believe, provides the most complete and comprehensive integration on the market today. But we understand that there’s a role for FHIR.

The challenge with any standards group is that it takes time to develop those standards, and that’s totally understandable. The other thing we’ve seen is that those standards are a paper-based or an electronic specification, but they don’t always get implemented in the same way by each vendor. You can look for a single FHIR resource and find that different vendors implemented it in different ways. You would need a different code base for using the same FHIR resource from one vendor to another.

We believe that FHIR has an important role and Apple has shown that you can do some interesting things with it. We’re working with customers that may be able to use FHIR for some of their needs, but they have other needs as well. We are able to provide APIs that fulfill needs that the FHIR working groups haven’t gotten to yet or that haven’t been deployed by the vendors yet.

There is no “one size fits all” solution for data exchange. We know from our growth over the last few years and from the continued interest that we have from new customers that there’s a demand for FHIR and more.

Do you have any final thoughts?

The next generation of software that will be part of the digital health revolution demands data liquidity. When you have free flow of data, it’s fascinating what you can accomplish.

The easiest analogy that I draw is to the smartphone. As a platform integrating your location and the ability to send messages, the smartphone has enabled whole categories of industries to develop. Take ride-sharing, for example. That never would have been developed.

As we start to break down the barriers among health IT applications and create the ability for them to exchange data, we’re going see a similar explosion in the creativity and innovation around health IT software. We are excited to be able to support that. For all of us, it will mean a better patient experience, lower costs, and better outcomes. That’s what we’re all trying to achieve.