Unfortunately, I can't disagree with anything you wrote. It is important that they get this right for so many reasons,…
Lisa Maki is co-founder and CEO of PokitDok of San Mateo, CA.
Tell me about yourself and the company.
I’m the co-founder and CEO of PokitDok. We’re a digital health company providing an open platform of APIs streamlining the business of health.
Explain how APIs work and the types commonly found in healthcare.
I started in software back in 1989, working on pre-Windows DOS versions of consumer and enterprise-facing software. I did that at Microsoft. Over the years, as software evolved into many industries, health included, it became clear that you needed services that would connect different siloed sources of data, different siloed sources of functionality, so that the enterprise IT professional software developers could create seamless business, user, and consumer experiences across all those silos.
How that shows up in healthcare increasingly is a set of APIs that can give access to interoperability, exchanging data between the EHRs and others in the form of standards that FHIR supports. APIs like ours that connect you to insurance X12 EDI or eligibility, claims, benefit enrollment, pre-authorizations.
The beauty of an API is it can be integrated anywhere into new digital or existing products. It doesn’t need to dictate your user experience. It can integrate into it and provide that service as you think best fits your business model or your user experience.
Non-technologists might think that APIs are pain-free and foolproof, providing instant interoperability. What are the challenges involved, both technical and non-technical?
APIs are intended to do the underlying infrastructure or operating system heavy lifting for software developers and IT professionals. It doesn’t remove work. It still assumes that you’re doing some work on your side to build the product or integrate it into the product.
In the case of our APIs that connect to insurance companies for access to X12 EDI services, eligibility and claims, those insurance companies — that’s over 400 now — still change their endpoints, those things we’re connecting to, often on a daily basis.
Part of the value that we provide software developers is we keep track of that. We detect it. We adapt to it. We manage that so software developers don’t have to. They have one endpoint they can go to and they can get access to all those insurance companies, all those services. The value we provide is managing that complexity on the back end.
But that software developer still has to integrate that into their own software, perhaps into a very complex system on their side. Maybe they service multiple EHRs, multiple practice management systems, in one single healthcare system, especially with consolidation. That can be very challenging and a lot of work.
It’s not an instant solution. It does a lot of the heavy lifting to get to that solution.
We also provide an identity management API that is not open like our others. We want to talk to you first because it is complex. Sometimes we assist our customers to put in an identity management solution across their health system because they have several instances of the same person in many different repositories. That identity management solution gets them to one instance of it.
But yes, there’s work involved. It’s not a switch. It’s not an on and off.
How do companies or systems that offer APIs coordinate software changes so that the end-to-end functionality won’t be broken?
It starts at the heart of how you architect your APIs. If you are architecting your APIs such that it requires a change in configuration every time — say in our case, an insurance company changes their endpoint or their gateway — then you haven’t done a good job architecting. That’s the bottom line. We have architected our APIs so that we can handle those changes and not put that burden on the users of our APIs. There can be exceptions to that, but a large part of our value is removing that burden.
There are things that we can’t control, like downtime of the insurance companies or changes for our identity management solutions. For example, I can’t control whether or not Cerner, Epic, or Allscripts is changing something about your installation, but I can certainly architect it to remove the majority of the heavy lifting. That onus is on all of us who are API providers. We have to architect that correctly.
We also have to provide open and transparent dashboards for our customers. For developers, one of the things we provide — and encourage any other API provider to also give their customers — is transparency all the way through the development process. You’re making an API call. You should know exactly where that API call is in the process. If something is being held up, you should know where in the system and where in the call, for what reasons, and get all of that feedback in real time.
That’s something we provide our development customers. If it’s downtime of a major insurance trading partner, they should be able to communicate that to their customers in real time with transparent information. For things we can’t control like that, it’s the goal to be as transparent as possible so that our customers can as well.
Much of the interoperability barrier is cultural rather than technical. What elements of trust or permissions have to be built into APIs so that data can move freely?
You hit the nail on the head. There are no technical reasons why we can’t have interoperability in healthcare. There are absolutely no technical reasons. Most of these technical obstacles have been solved back in the 1990s in other industries that are equally complex. Financial — heavily regulated, very complex — has addressed these issues.
You have to have a will to achieve a business model and create a business model that rewards interoperability and openness instead of closed systems. Most of the time, we’re overcoming habit. We’re overcoming misinformation around security and compliance. There’s confusion over what the P for HIPAA stands for. It stands for portability. There’s a lot of behavioral issues that have to be overcome to achieve the interoperability that we all want.
A lot of progress is being made. The progress is being made because the market has shifted. Any time you see someone like us and a company like PokitDok going into a market like healthcare … we’re not healthcare experts. We’re technology experts who want to make the tools available so that people who are experts in healthcare can create the patient onboarding experiences and the business models they need to support their business in this changing market.
We come in because there has been a market shift, like you see with consumers moving to high-deductible plans. All of a sudden consumers are starting to change their behavior. They have to pay for it out of pocket. They’re demanding more transparency and service at the point of scheduling or checking in before they have the procedure. That’s a huge market shift.
In order for health systems to respond to that, to compete, to protect their revenue cycle stability instead of seeing their former reimbursement revenue now go to collections, they need new tools. They need the ability to schedule, check eligibility, and take a payment in real time, both mobile and Web-based. That’s what we respond to.
The market shift is overcoming any behavioral or former business model resistance, both from EHR and API providers.
What healthcare APIs are most commonly used and most needed?
There are not a lot of APIs available in healthcare that would fit my definition of a developer-ready open API. We are one set. FHIR is certainly another, early but evolving and getting a lot of interest. There are certainly your standard developer APIs, when you’re creating that new product from software technology providers.
Early efforts from CommonWell and other alliances are attempting to provide API access. EHR vendors like Cerner and others are looking to release access to APIs. Even sandboxes represented by Athena, Epic, Allscripts, or Greenway are heavily business model controlled API sets. They require a lot of heavy lifting, a lot of time and interaction in a sandbox before you can take something to market quickly.
Today’s software developers who are building truly innovative solutions for either their own or for their customers in healthcare expect modern API experiences, not sandboxes. Not long, lengthy vetting processes to get something to market. We’re seeing some interesting things from companies like Redox who are doing intra-EHR interoperability. There’s some interesting things from companies like PatientPing. I’m excited by this because they’re following more of the modern developer standard and expectation for open APIs. I think the market will follow.
Most of the handful of surviving hospital EHRs use a 1990s style client-server architecture at best. Are those companies up to the task of creating scalable, secure APIs that use more modern technologies than their own products?
It’s a huge cultural shift for those companies. My co-founder and I both come from companies like Microsoft and Apple and various startups. We’ve released product into many industries and now healthcare for the past 10 years. It’s going to take an immense amount of leadership in those companies to prepare them for this shift.
It must and will happen. New technologies are showing up every day that will make the shift for them whether or not they’re ready. If I were in those leadership positions of those companies, I would be starting parallel projects with people who are used to those sorts of open and technologically advanced environments, cloud-based Web services. I would start that now if you haven’t already and I would start it really fast, because it is coming and it’s likely that with your current systems, all you will be doing is migrating them over.
You will need a different set of people familiar with with building and supporting those systems. If you haven’t already started it, then starting it today would be your next best bet.
I would also partner. You’ve got companies like Microsoft who are trying to build API-driven architectures that do much of the heavy lifting, even compliance and security, into the fabric of Azure, their cloud offering for healthcare enterprise development. You’re going to see a lot more of that.
EHRs also have to get clear on what part of this they are going to own moving forward as the business shifts to the cloud. Which part will be owned by companies like Microsoft, Google, Oracle, and IBM that will be built into the cloud fabric. You want to get clear on that quickly because it affects your strategy.
Where do you see the company going in the next five years?
We want to be the house for all healthcare enterprise business transactions. We hope to achieve that in five years. That’s our big goal. There are a lot of unnecessary ones that add friction and operational cost to healthcare enterprise today that we hope to remove and then there are new ones that we hope to add.
There’s no reason why our healthcare customers — and this is what we provide them today — shouldn’t be getting up-to-date and real-time business outlooks and intelligence off of all their business transactions today. There’s no technical reason why they can’t have it. That’s what we deliver and that’s what we want the entire healthcare industry to be enjoying from its business and ultimately clinical transactions on a daily basis.
Do you have any final thoughts?
I love what you’re doing. These sorts of conversations, as the industry is going through such a massive market and technical shift, are super-important. More of us talking about what is technically possible and identifying, as you’ve astutely said, the behavioral and business impediments to healthcare enterprise moving forward to deliver the kinds of patient, provider, and business experiences it needs to. Those are the right topics.