HIStalk Interviews Erkan Akyuz, CEO, Lyniate
Erkan Akyuz, MS, MBA is president and CEO of Lyniate of Boston, MA.
Tell me about yourself and the company.
I’m a software developer by trade. I started in the PACS world, the imaging world, at a small company called Mitra Imaging in Ontario, Canada. I was a developer on a product called Mitra Broker, then did some display work, and from there I went into management.
We started Lyniate as a carve-out of Rhapsody, our flagship product from Orion Health in New Zealand, in November 2018. Shortly after that, six months or so, an opportunity came to merge Rhapsody with Corepoint Health out of Frisco, Texas, and we did that merger. A primary driver behind the merger was being able to provide a more full solution to the market in all the segments, with the ease of use of Corepoint and the extensibility and the multiple platform strength of Rhapsody.
We’ve been running the company in that mode for a while. Earlier this year, we also merged NextGate’s enterprise master patient index solutions into the portfolio. In late July, we also merged CareCom, which is a terminology services provider out of Copenhagen, Denmark, into Lyniate.
What is the current state of interoperability and what challenges remain?
When I started as a developer on Broker in the late 1990s and early 2000s, we had an interoperability challenge. As developers, we used BizTalk from Microsoft. Then Orion came up with Rhapsody. So even 22 or 23 years ago, there was a core technology issue about interoperability and being able to exchange messages between EMR and the PACS systems and the modalities.
In the years that followed, I would say that thanks to companies like Corepoint and then Orion Health, the problem of interoperability has almost gone away. Even though HL7 standard adoption, or its implementation in a standard way, by healthcare was challenging, companies like Corepoint companies and Orion Health provided solutions to make integration and interoperability more efficient.
Fast forward 20 or 25 years. We still have interoperability challenges. They are less in technical nature and more semantic in being able to help people interoperate with each other. Not only to send the right version of HL7 and then receive the right version of HL7 back, but to help a doctor prescribe a prescription accurately. Then on the pharmacist side, to receive that prescription and administer the right pills so that we minimize mistakes and we improve efficiency.
Interoperability issues are much, much less technical in nature. I don’t think that we have the issues of being able to exchange data now, It is more of a multi-organizational workflow. We hear about data blocking or a site that doesn’t want to share data, but that’s an easy way out by blaming the vendor, blaming the EMR vendor, blaming the hospitals, etc. And at times, our healthcare ecosystems — from payers to providers, multiple payers to multiple providers — introduce such complexity that one vendor, one provider, cannot really solve it.
In my view, we need, as a nation or as a globally, better motivation to make data available to the systems without any hassle, without any struggle, so that it can be used in care settings where the data is not produced. If the data is produced in an acute care setting but now needs to be accessed in a social care setting, that should be easy, without many bottlenecks.
Unfortunately today, we sometimes see legal, sometimes affiliation-related, bottlenecks. A social care worker will not be able to get access or even identify where the data that they need for the patient, for the baby or the person they are providing care for, is available, how they can find it, and how they can access it. We need to do better from every angle, every stakeholder in this picture – vendors, providers, and payers — to create a federated environment by providing our data, making it available to everyone who wants to access it. From the consumer side, we need to make it easier to consume this data from federated, basic data suppliers.
What interoperability needs are coming from payers and life sciences companies?
When it comes to technical connectivity, they are able to access the data. But they don’t understand how the data is stored and structured as well as a provider. If you’re a provider, you developed your EMR structure and made decisions about how to store patient data, so you have a very good idea of how it’s done. When you access a different provider, you can’t figure out how to navigate through it. If you are coming in as an outsider, if you have never been a hospital, if you never seen an EMR, understanding this data structure is not that easy.
You are interested in one bit of information. Let’s say you have a clinical surveillance system. You would like to monitor certain diseases, and they are spread in the hospital. Let’s say you are interested in getting a notification every time a patient is diagnosed with sepsis. In today’s world, in order to get that notification, an external party — let’s say in this case, life sciences or device companies — need to have good understanding of how to find the data and create an alert so they can get a notification. Our EMR systems were not designed to create those alerts. They don’t understand it as much.
We need to make accessing and consuming data much easier than it is today. We use money exchange, like ATMs, as our goal internally. Lyniate will be done when exchanging healthcare data is like paying an electric or gas company bill, riding in an Uber, or using Venmo. There are no barriers. You can pay someone independent from what that someone does, in multiple formats — check, cash, Venmo, PayPal, Wires, Zelle, or whatever. These different protocols and mediators are able to move currency. It’s so easy that we don’t even know how gas company accesses that money, but they do it. Unfortunately in healthcare, when a life sciences company is trying to get a imaging data, sepsis data, or clinical trials data, they need to have a deeper understanding of where that data is and how they can get it.
SWIFT’s [Society for Worldwide International Financial Telecommunications] currency exchange protocol is an example. We need to be able to provide services like SWIFT to the multiple providers of that currency — with healthcare data as the currency, and multiple consumers of that currency — without being held to understand too much in the intrinsics of how I keep the cash, how you keep the cash, and how we are going to use it. We need to bring it to the fidelity of the healthcare data and make that easily accessible, independent from the affiliations between organizations. We need to implement a SWIFT-like environment to manage those transactions. I don’t think we are very close to it yet.
Who would lead the charge for a SWIFT-type exchange in healthcare?
I think it has to be a shared effort, but bringing a group together around that solution is going to be difficult. As an example, I really admire how RSNA succeeded as an organization in providing leadership, and then came DICOM. I started my career as a developer in the DICOM world. RSNA came up with the IHE [Integrating the Healthcare Enterprise] idea. Their thing was, we are not going to reinvent DICOM. We are not going to reinvent HIE. But we are going to bring the parties together who are stakeholders to use standards when it comes to exchanging data.
I was a technical representative of my company. I would go to Chicago once a year, where we would spend a week around the table with different vendors and different providers. We would discuss, how are we going to do patient information reconciliation? Let’s say the modality acquired this study and then patient information changes. Which bits and bytes of the standards are going to be used? How we are going to populate it?
IHE and RSNA led this effort to create these integration profiles, saying that if this is a workflow, then all the EMR player actors are going to do this and all the modalities are going to do that. Representatives from vendors, providers, and standards worked together to define how that integration profile will do the job. We changed our code in Connectathons, we tested all that stuff, and it worked.
Today, when you look between the modalities, PACS, RIS, and whatever systems are doing their job, then exchanging data and who’s going to do what, quite honestly, we don’t. But now it’s a system. Every year we have Connectathons. Every year we are testing integration profiles.
They need something similar on the EMR side. Let’s say HIMSS can take this leadership since they’re a strong player. They need to bring life sciences players, device manufacturer players, EMR vendors, payers, and anyone and everyone who is interacting with patient information. How do we do this? What is the integration profile? Are we going to use HL7, FHIR, or DICOM?
Let’s say there’s an integration profile called Accessing Patient Information for Clinical Trials. The life sciences players should define what they need, how they want to use it, and what format they want to consume. The EMR vendors can describe how they can access the data. Providers will offer the legal structure they require.
It needs to be a joint effort and organization. HIMSS may be a good one, or it could be the American Hospital Association. An organization needs to take the lead to pull these players from the different corners and bring them together for a common cause. IHE is a stellar example of how it can be done, and right now, IHE profiles are working like SWIFT.
I did a little bit of research about SWIFT, asking why these competing banks don’t worry about losing – or let’s say “leaking” – customers to a different bank. We always hear that patient leakage makes providers not want to share their data to protect their customer base. I learned that SWIFT is a legal entity and all its shareholders are the member banks who are using SWIFT for money exchange. Every time then there’s a SWIFT exchange, banks pay a transaction fee, and at the end of the year, they basically receive a proportion as dividends. The bank that contributes the most funds into SWIFT receives the most funds from SWIFT at the end of the year.
So in the bank world, they created the SWIFT organization and they own it. There are no third parties. In healthcare, TEFCA may be a good example. Maybe we create an organization like that and mandate it jointly by a membership, a paying membership by the life sciences, payers, and saying that we want this organization to be the SWIFT of healthcare.
Where do you see the company going in the next three or four years?
We put a vision in front of us to implement an infrastructure layer that helps not only data exchange, but also helps manage the identity of data. That’s why we merged with NextGate. Then also to help translate the content of the data so that the consumer of the data doesn’t need to worry about the format the data was stored in and the data itself will be translated for them in the unit that they would like to consume it. We also want to expand it even more than being able to store that data so that our users and other healthcare IT providers like the vendors can access this infrastructure as a platform that they can use to exchange data. Then make sure that the data that they are exchanging is trusted — coming from a trusted party and belonging to the person that they believe that it belongs to — and then interpreting it to the format that they would like. If they would like to also store it more in perpetuity, they can also store it.
Our vision is staying as an infrastructure provider for healthcare interoperability to provide a more multifaceted features, such as what we did with Rhapsody and Corepoint in data exchange, identity management and identity assurance with NextGate, and terminology mapping services in and expanding that even to the coding services with CareCom. We will continue to invest in them and expand the infrastructure based on what we are hearing from our customers.
I think you're referring to this: https://www.wired.com/2015/03/how-technology-led-a-hospital-to-give-a-patient-38-times-his-dosage/ It's a fascinating example of the swiss cheese effect, and should be required…