Linux for Health | Dixon Whitmire, Lead Coding Architect, Watson Health

Luke Schantz: In this episode of In The Open, we're excited to bring you a conversation with Dixon Whitmire. Dixon is Watson Health's leading code architect. We'll be discussing a variety of healthcare industry technology, including the open source distributed processing network operating system, Linux for Health. Before we welcome our guest, let's say hello to our co- host, Joe Sepi.

Joe Sepi: Hey, Luke. How are you my friend?

Luke Schantz: Good. How are you doing, Joe?

Joe Sepi: I'm all right. I'm all right. The weather actually has been pretty decent lately, and I managed to get all of my, or not all of, I have a little section over here, but almost all of my yard work done, which I'm very pleased about. I feel good about. How about yourself?

Luke Schantz: Nice. I have tons of leaves outside that I haven't touched since our last show. Full confession, I bought a chainsaw though, so I think it balances out.

Joe Sepi: Yeah, cut those leaves right down.

Luke Schantz: Yeah. Without further ado, let's welcome our guest, Dixon.

Joe Sepi: Hey, Dixon.

Dixon Whitmire: Hey, Joe. Hey, Luke. Thanks for having me on today.

Joe Sepi: Yeah, happy to have you.

Luke Schantz: Maybe we could just start the conversation off with a quick introduction of yourself for our listeners.

Dixon Whitmire: Yeah, sure. My name is Dixon Whitmire, and I've been with IBM since March of 2020 as the Lead Coding Architect for Watson Health. Prior to that, I've probably spent about 20 or so odd years in the healthcare industry. I worked with a startup called PokitDok, started that about 2020, where I worked with Ted Tanner, the Watson Health CTO, to build out an API platform for healthcare transactions. And then following PokitDok's acquisition by Change Healthcare, worked for Humana for about a year, primarily on the Synaptic Health Alliance project, which was a blockchain- oriented use case. So just happy to be here... And oh, and currently I'm working on Linux for Health. I guess I probably shouldn't leave that one out, and that's why I'm here today.

Luke Schantz: We're glad to have you. And we first heard about Linux for Health when we had TED on, and we were so interested in learning more that, and that's why we looked you up and we asked you to be a guest, so thank you for being here. Let's talk about your time at IBM and what you came on, what you're working on, including Linux for Health.

Dixon Whitmire: Sure. So when I started at IBM, what I was working on initially was just on different integrations that we can implement within the healthcare space. And we started out taking a look at integrations with blockchains, specifically hyperledger fabric with integrating some payer transactions like the X12- 270 eligibility check. And once we had a few demos in place and that we saw that we were basically gathering and collating all these different healthcare transactions under an umbrella, Ted was saying this could be the basis for an operating system or a framework for a platform that could be leveraged by other developers, so within Watson Health, within a larger ecosystem. And so with Linux for Health, what our goal is to be is essentially just the reference implementation for healthcare transactions. So if you need to execute an eligibility check or you need to process a healthcare claim, you would come to Linux for Health and have everything with the batteries included approach. And as an operating system, what we want to do is basically include all that for you within a single distribution and to be able just to share that data and to leverage those transactions in the way to where you don't really necessarily need to understand how to initiate that transaction. So I guess to kind of back up a little bit and to unwind that some, typically when you're sending a transaction to a healthcare payer today, there are several different things you need to take a look at. One is, what's the protocol that's being used to basically convey that data? What are the security aspects of that data? Do you need to have key payers? Is there an SSL certificate? Are you doing it over TCP/IP, or are you using a web service? And so within Linux for Health, what we want to do is basically subtract that away from the developer to provide a richer developer experience to where if you want to interact with healthcare data, you could do something simple like subscribe to a topic or an event and just consume data from that event, rather than having to understand, and this is how Ted likes to put it, how the sausage is actually made. You can just leverage the data as it's flowing through the system rather than having to initiate all those transactions yourself.

Joe Sepi: It's interesting to me that we're not talking about an application or something, we're talking about an operating system.

Dixon Whitmire: Right.

Joe Sepi: I'm fascinated that the team went to that level. Can you just briefly explain why you would go all the way down to the OS?

Dixon Whitmire: Sure. I think that when you're looking at it as an OS, you're looking at it as so basically some core capabilities that you provide to a user with a system call. And that could be like a REST API or an SDK or something of that sort. And so when you're doing that, it's like you're painting with a broader brush because you're not thinking about specific use cases. And so I think that when you can go with that operating system approach, that also allows you to say, " Okay, here the platforms we're going to support," and you can have a wider spread horizontally as well. Then the applications that are built on top of that, if you've worked an open source, well, we all know that when you have an initial idea and the point of view for a thing, once it's out in the open and someone starts using it, it develops and then evolves on its own based on the community need, and it often does so in a way that you wouldn't expect. And so I think that one of the benefits of just implementing it as an operating system is just we're not trying to bias anything. We're saying, " Okay, we know that we need to be able to support these core capabilities," and that's mainly along the healthcare, the standard protocols that are used, whether they're FHIR, HL7, DAs or the X12 specification, and then we're allowing users to build applications on top of that, but providing that firm foundation with protocol support and security.

Luke Schantz: Excellent. There's so much to unpack there. I feel like we need to dig more into this project, we need to dig into some of these standards you mentioned, but I also think it might be helpful if we just quickly discuss what is the status of the industry now? What are the problems? Why did this need to happen?

Dixon Whitmire: Well, I think in the industry today, what we see is we still see that data is siloed. And within systems, maybe they're EHRs or EMRs, and integration is basically still point- to- point using FHIR or a protocol such as FHIR or HL7. And so what we're trying to solve here is basically we want to position Linux for Health so that we can eliminate these point- to- point integrations. Because rather than having to integrate with a medical system within a provider's office or a payer system or maybe a system that's on a device, what we can do with Linux for Health as an operating system is install it in multiple places within a secure networking context and then have the data be replicated across those devices. And so then what we're not focusing on are point- to- point connections and interactions, what we're focusing on is event publishing and consumption instead. And that's a totally different paradigm. And it goes back to what I was saying before. We can have a developer experience where you don't really need to be concerned about having to know the ins and outs of how to format a SOAP message or basically how to rotate key pairs or things like that, or where is the FTP server and what's the login? If we can provide abstractions for all of that so you're just dealing with the data, after you've been authenticated and authorized, of course, then that gives you a different programming model and then you're able to leverage the data within that network where Linux for Health is deployed.

Joe Sepi: That's fascinating. I knew we were going to be talking more about this. We had a prep call early in the week and I got my booster shot in the middle of the week. I forgot my phone, and I lost my vaccine card pretty much when I got it'cause I'm a ding dong, but I even forgot my phone, which is really rare. But I went to go get my booster, and when I got my two first shots, I used the CDC's VAM system, the Vaccine Access Management System, and I'm thinking, " That's the system They can just look me up and no problem." And I get in there and I go to a CVS, and she's like, " No, I need all of your information." I'm like, " Just log into VAMS." She's like, She said to me, What is VAMs?" I mean, I had to reschedule and go get all my information the next day, but I'm just baffled that even something like this that's really current and everybody's focused on, and yet we still don't have any sort of information sharing besides a piece of paper. It blows my mind.

Dixon Whitmire: Yeah. And I think one of the things we can do with that, and this is something that I worked on at PokitDoc with our dockchain or our blockchain offering, is that what if you could drive all of your data sharing from this? I mean, everybody seems to have a cellphone nowadays. I mean that doesn't need to be the only way that we could do it, but if you could permission your own personal data and then share it with CVS when you walk in, now, how much easier would that be? And so in order to do that, what we need to have is we need to have that underlying processing fabric there so the data can be shared in a secure manner when we adhere to regulations, and that's what we're shooting for with the Linux for Health Operating system.

Luke Schantz: So interesting. And I must say, just to reflect back on what you said about the developer experience and making it very easy for them to get started, I can imagine in these scenarios, you're inside an insurance company, you're inside a hospital, this is mission critical stuff, you're very busy. If there's too much of a barrier to entry, it's going to be tough to play with that stuff too, so I could see how this strategy is good for a production, but it's also from a developer's perspective... Right away I'm interested and I'm excited because I feel like I can get something done and move that needle versus having to read an entire textbook and understand everything about the systems and the ecosystem, which is quite complex.

Dixon Whitmire: Yeah. And that's one of the things that we're working on within Linux for Health. If you go out to our GitHub, you'll see that we have quite a few projects that are out there right now. And just to be honest and transparent, as some of the projects are driving projects like the Clinical Data Pipeline project and Linux for Health Connect and other ones are ancillary Legos that you can bolt on for additional functionality, and so we're kind of going through the process of just identifying those and just having a better landing page and presentation for it. That being said, if you take a look at our EDI project that's out underneath our GitHub site, what that is meant to do, once it's fully implemented, is we're talking about that barrier entry for developers. So if you want to support a healthcare ecosystem as a developer, you might need to be familiar with the HL7 version 2. 6 specification, some of the X12 specifications, and these things have specs that are about 700 pages long. It's something you definitely have to ramp up for. And then FHIR. And the industry wants to move towards the FHIR representation just because, you can deal with restful interfaces, there are resources, and developers understand REST APIs right now, and so that's a very helpful thing, especially since you don't have to deal with the fixed length data format. But with our EDI project, what we want to do with it is basically, and we've implemented the portion where we can consume any EDI message and validate it in its native format, but then the next step with that is actually translate it to a meaningful FHIR representation. Because if that's what the industry standard is going to be, then what we can do is say, " Okay, we can translate that HL7 message or the X12 message to FHIR," and then for developers that are ramping up, you still do need to be familiar with the data to a degree, obviously if you're working with it within the the system, but then it's one format instead of three, four or five. And so I think that could be helpful too, and that could also be leveraged even more on backend systems where if there is a need to have a FHIR integration capability, but just you don't want to put the effort in to building that yourself, you can use this library to handle that data conversion for you.

Luke Schantz: So maybe we could just unpack a few of these terms for our listeners.

Dixon Whitmire: Sure.

Luke Schantz: So just give us a high level of what is the ASC X12 and the HL7 first?

Dixon Whitmire: Yep. So the ASC X12 is that is the standards body that has created the specifications for just electronic transactions, and these specs are used in manufacturing and healthcare, in addition to other places. And so when we talk about X12 within a healthcare context, it's typically going to be for an eligibility check, which is a 270 or a 271. Then you have a healthcare claim, which would be the 837 format, and then you have a payment format or an adjudication just to give you details about the claim you just filed if you need to remediate anything. That's the 835. And then what I call it the Domino's Pizza Tracker of claims to find out where your claim is after you've sent it off to the payer and send the black ether of the black box or whatever, that would be the claim status, the 276, 277. And so those are the X12 transactions, and those are generally on payer systems that are supported running on a mainframe. What the HL7 specification, there's actually, and this is where it gets confusing because the acronyms are a bit overloaded, but there's an HL7 organization that supports the HL7 file specification and then the FHIR specification. And so it's like you have an overload there on the HL7 name. But with HL7, the file format, that is a fixed link- based file format that's typically used with medical devices and with medical record systems, that is the common language that they speak and is the predominant language that's spoken within that provider clinical setting. It's meant to basically support clinical data transfers from one system to another. And then with FHIR is basically what the industry wants to move towards from HL7, but it hasn't seen the adoption. And basically, FHIR hasn't overtaken the HL7 format right now. Folks are still primarily speaking HL7, but FHIR basically takes HL7 and puts it into a nice REST based format. I mean honestly, there is an XML format too, but folks are probably going to tend to want to use the REST resources more because that's what we're using now today. And so lots of formats and lots of options, but what the industry has signaled that it wants to consolidate on are the FHIR resources, and so that would be from the clinical side, with the payers probably still speaking X12 just because how much does it cost to upgrade software on a mainframe, but there is going to be a need for FHIR integration capability there as well.

Joe Sepi: This is really interesting. I feel like it might help me to just take a moment to get really high level. We have a few different personas if you will. We have a payer, which is the insurance company, providers like the doctors and whatnot, and a patient. And then maybe you could talk to me about what would be... If everybody came to the table and said, " Okay, Dixon, we're ready to implement this completely. Tell us what to do." At a high level, what would that kind of look like for all three parties?

Dixon Whitmire: Okay. For all three parties, and of course putting Linux for Health in the mix, I think what we would have is the patient would have a Linux for Health client on their device, whether that is a tablet, smartphone, or whatever. They can send messages to the Linux for Health network that they are enrolled in. And so what we could say is, and I don't want to limit Linux for Health deployments, but let's just assume this deployed throughout a provider network for an insurance company. And so we'll just keep it simple and just say our patient has health insurance. And so the patient would have a Linux for Health client or an application just on their smartphone or on their tablet, the provider could have that just on the machine where the provider system is, like the PC or the server or even up in the cloud, and then the payer, it would be somewhere close to the mainframe. Because what we're doing with Linux for Health is it's designed to be basically a system that can run on the edge of processing so it can be close to data. And the reason why is that as transactions are flowing through it, the data is being saved down into a distributed database so that we can build an intelligent health record for that patient. So we can check all the interactions. If a patient picks up the cell phone and enters in some health stats like through Apple's Care Kit or something like that, " Hey my blood pressure was this today or something like that," we can save that down, but we can also any interactions or encounters at the provider's office or an appointment. The details from that, we can capture that data as well. And then on the payer's side, we can basically just integrate that with the insurance information and information within that payer system. So I think that what Linux for Health helps out with there is it helps give you that holistic picture of the patient and the patient golden record, if you will. And then with the EDI capabilities we have, we would have everything in a common FHIR format just so if there is a need for analytics and reporting just downstream, you can just leverage that with a single file format rather than having to pick and choose and do bespoke integrations and implementations. But at the heart of that, the patient needs to have control over his or her data just to say, " Okay, this is on the smartphone app. I'm going to say that my insurance company can know what my blood pressure was today," or whatever the metric is, just so that information could be shared.

Joe Sepi: And I think the first question that comes up in this sort of conversation is security, right? Maybe you could touch on that.

Dixon Whitmire: Right. Yeah, sure. And so basically within Linux for Health today, we do have a concept of security and known entities that are processing within the network. And so whenever we deploy a node into a Linux for Health network, the other nodes have to know about it and there has to be a hand shaking protocol that's there. And so at that bare infrastructure level, all of that is secure and in place using technologies like with keys and two way SSL and that sort of thing just so you can't do a man in the middle attack. From data storage standpoint, data needs to be encrypted I guess both in transit and at rest. And so that way it can't be decoded by someone who is... if someone's able to compromise a system. One of the things that we did at PokitDoc is we basically established an algorithm that allowed a patient to sign their data with a key, and then it got signed again by another key. And so we have this notion of dual encryption that's there as well that can only be unlocked by the patient who has the key. And then there's a whole key recovery aspect to that as well, but it all ran from a mobile device. And I think that's what we would iterate towards just in Linux for Health, unless Ted pops up to my right or my left here real quick. It's just that we want to basically help the patient direct where the data is going to go, and so that's going to be on a smartphone app or on a tablet probably more likely than web client.

Luke Schantz: That makes a lot of sense. And I just wanted to rewind a little bit too. I feel like we have to unpack EDI. I feel like even what is an EDI? We have so many acronyms. And then explain because it is... You had mentioned in our prep call that it's, " Oh, it's the not interesting plumbing," but I feel like right when we look at the problems in the industry, it actually is. This is to me like the key thing. If we get this in place, this could really help free things up and get things moving between these different silos.

Joe Sepi: I think from a developer's standpoint too that seems like that would be the place that would be interested in getting involved.

Dixon Whitmire: That'd be a great first place to get involved because there's certainly a lot of work there. So with EDI, inaudible general term, this refers to Electronic Data Interchange. And so what you can think about is when you have an EDI transaction, you have a request that you're forming up on one format, and then you hopefully get a response back that's in another format. When we're talking about it within a healthcare context, typically it doesn't have to be, but with the healthcare claim, your shipping files back and forth, and they're batch files. With healthcare eligibility, an EDI transaction could be just basically a REST call where you send a request over to a payer server and they send back an HTP response of some sort. And so when we're talking about EDI within the Linux for Health context right now, it's more about the messaging formats, like what is the file format or what is the REST resource format, rather than that transmission layer. And so within EDI in the specifications we're supporting, that's where all of these formats we were talking about earlier on the show come into play with HL7 and FHIR and the ASC X12. And so typically what we're doing with EDI is we are preparing a payload of some sort that's going to be received by another party so they can go into a system of record.

Luke Schantz: And so essentially what this is going to do is it's going to allow systems that are using these legacy standards to be able to communicate with the more modern say FHIR protocol moving forward.

Dixon Whitmire: Yep, exactly. That is the dream. And so what we have in Linux for Health Connect right now is we do have a single endpoint. I came up with a name, and you can tell I'm not in marketing, but it's just called/ Ingress. Any guesses what it does? And so that's where the data payload comes in and the EDI library is used to identify what type of data format it is, and then to validate it before it saves it down as the Linux for Health system. But as we can grow more support and grow the Linux for Health organization, then we'll start working on the data conversion problem. I definitely don't want to trivialize that because if anyone has done EDI before and has gone through the task of trying to translate one format to another, there are lots of considerations and lots of things you have to do. It's not a trivial problem, and it's not really hard, it's just tedious because you get into these situations where you're like, " Hey, in HL7, this address could be in this field, or maybe it's down here, or maybe it's down here. But in FHIR, it goes over here." And one of the nice resources or one of the great things the HL7 organization has done is provide mappings just on their website from how you should convert HL7 to FHIR. But the problem is that out in the wild, things don't get used according to the specification. I remember when I was processing benefit enrollment for a previous employer, that was the 834 transaction, there was this whole set of data segments that was used to convey basically an individual's coverage information, whether they had family coverage or employee spouse or employee only in a type of health plan. And that's what you would typically expect to see, but one of the insurance carriers we're working with basically didn't use those segments. They created a bitmask in a free field segment that you had to parse. And so you get into this sort of gray area where the specification says one thing, but the industry is using freeform text fields and this other means of conveying data due to whatever constraints they may have on their side, and so you have to adapt to that as well.

Luke Schantz: That makes so much sense, and I love that cause it's realistic, like we have to meet organizations and individuals where they are, otherwise this isn't going to move forward. And it reminds me of a story. I forget where I was. I was at a business accelerator and I was talking with a startup and their whole thing was helping Latin American and telecoms that were consolidating deal with similar type issues'cause they had all kinds of different formats and structures. And in that instance, they were using a graph database, which I know FHIR technically isn't a graph, but in my mind it's very graph like in that you've got a schema and an ontology and you're able to... I could see how it could be a key piece in helping... The EDI is a key piece in helping interface between these different formats.

Dixon Whitmire: And with the EDI too, it may be that just to get the conversion or the translation process, it may require an external configuration of some sort or some heavy like AI inaudible over it just to kind of discern how these things need to clunk over and what the right buckets are. But I think it's definitely an interesting problem, and if we can help in Linux for Health by providing a library that can get you 80 or 90% of the way from going from HL7 or X12 to FHIR, I think that would be huge because then developers can pick that up and just say, " Okay, I've got HL7, I just need to instantiate an object, pass it into its constructor, and then boom to call a method and I have a FHIR resource now." And then that way it's like when you can focus on learning the FHIR language or the FHIR specification of it just for what your needs are, your use case, without having to worry about everything else. But the job is on us and the task we have ahead is to make sure that those conversions aren't lossy and they're meaningful and they actually do work. Because like I said, it's not a trivial matter.

Joe Sepi: It sounds to me like Linux for Health can be a lot of things, but also I'm wondering if it's can be adopted piecemeal as well. For example, EDI just for data munging or whatnot, is that the case? Is it all, or nothing or can you just start to take pieces to help move some of these groups in the right direction?

Dixon Whitmire: That's a great question. And you can actually take the repositories and use them just separately or in concert if you want to. One of the things that we've been working on at IBM is we have... well, underneath the Linux for Health at org, there's an HL7 to FHIR converter, and that project is being leveraged in other projects outside of Linux for Health just to... well, to do what it sounds like, right, to convert HL7 to FHIR. And so you can definitely pick that one up and run with it. If you want to use the EDI application by itself, you can certainly do that. One of the things we have on our roadmap but we haven't gotten to yet is provide... We have a CLI for it and then there's also an SDK that you can use if you're integrating it with an existing PI application, but we want to put a REST API on it. And so that way you could just stand up a microservice and if you needed to validate EDI before you send it off somewhere, you can use it. If you want to convert EDI before you send it off somewhere, you can use that too. And so I think that's the beauty of the system and it is going with the operating system paradigm where we're not necessarily in the system space, we're in the user space, though within user space you can pipe together whatever utilities you want to. You can do your wisting, you can do your grepping, you can use T and whatever just to get your job done.

Joe Sepi: I would ask that previous question in terms of implementation, but I guess I can also ask it in terms of if the developer wanted to just start playing around with this stuff. I could imagine someone listening to this and being like, " Oh, I don't want to install Linux for Health on a partition machine or something, but I'm curious," so can people just pick up one of these repos and start to play around and find issues and work on things?

Dixon Whitmire: Absolutely.

Joe Sepi: Okay.

Dixon Whitmire: Yeah, absolutely.

Joe Sepi: Where would you recommend they start if they were looking? I mean EDI sounds like a good example with that.

Dixon Whitmire: I think EDI would be a good place to start. The X12 library, we could use some additional help there as well. And so if you have experience with X12 formats, we would love to hear from you and connect. If you don't have experience with the X12 formats, we would love to hear from you and connect because that's the one thing we do want Linux for Health to be, as well as also inclusive, because there are some things we can use some help on with the projects, even though they have EDI or X12 in their name, they might not be format specific, but more programmatic implementation concern types of things that folks could help out with.

Luke Schantz: And as you mentioned earlier, these projects take on a life of their own as people come and contribute. So I would say a call to action, come get involved, get the issues that you have and the things that you need for your organization in the mix here. And then the community starts to help solve those problems for you. And so if you speak up and get involved, you're going to get along farther than having to do that work yourself.

Dixon Whitmire: Oh no, absolutely.

Joe Sepi: Yeah. And I feel like with everything that's been going on the last couple of years, operating in the health space as a developer seems to make a lot of sense to me, especially with that experience I had this week. I'm just like, " As a developer, I want to solve this problem." And I know we have lots of things to talk about, but I'm just curious, if I were to start working on EDI just real quickly, what would that look like? I'd clone the repo, pull it down. Can I run test cases, or just go through issues?

Dixon Whitmire: Yeah, sure. So basically, each one of our projects has a README in it where it tells you how to get started with the project, and so it's as simple as cloning it and then just following the different steps. For the Python projects, you'll create a virtual environment. For all the projects you'll run test cases of some sort and then take a look at the issues that are on the GitHub repo just to see... and we can do a better job of doing this and I'll take this as an action on myself, of labeling things like good first issue or need help or things of that sort, but that would be a great way to get started. And then we also have a repository that two of my coworkers, Carol Corley and Dr. Henry Feldman been working on called Connect Clients. And these are basically applications and tutorial applications that exercise the different parts of the Linux for Health ecosystem. And right now, as the name suggests, it's a little bit Connect heavy because the name of the repo is Connect Clients, but we could expand some of these examples and tutorials out for whatever use cases developers are interested in or businesses, and then include EDI in there as well.

Luke Schantz: That makes a lot of sense. And something else I wanted just to bring up. So we have the developer's perspective and it is an operating system, so from the IT infrastructure perspective, where can this run within the digital estate of a healthcare ecosystem?

Dixon Whitmire: Oh sure. And so what we've done for with the deployment methodology is utilize containers. I mean, you certainly don't have to use a container, you could just run it on bare metal if you wanted to, but we do support Alpine as our base container image and actually extend that from there. We did have additional support for other popular container variants like Red Hat's UBI, but we just wanted to scale that back a little bit because what we found is that right now we're still in our early stages, and so we wanted to be able to focus more on the features that we need to implement rather than supporting this flavor of Linux or this UBI minimal version or something along those lines. But that being said, if there is a container flavor you would like to see supported, reach out to us on our Slack workspace to contact us and we can definitely start working on that or someone could create a pull request for it.

Luke Schantz: Excellent. And I also was reading that... So mainframes, Z machines, and LinuxONE are obviously huge within the healthcare space, and I know that's a key part of the strategy for Linux for Health. Could you tell us a little bit about that?

Dixon Whitmire: Yeah, sure. And so we actually did a demo that we had generated a blog post. It was an eligibility use case where we said, " Okay, we're going to install Linux for Health on a provider system." I think we had it on a Raspberry Pi on this one, I'll have to go back and look at it, and then within the Z mainframe space. And so with Z, what we're doing is we're utilizing an integration interface called KICKS that provided a REST API for us just to integrate with that backend system, but that did utilize the Hyper Protect virtual server capabilities of the platform as well. And so what we're able to do there is we deployed the Linux for Health Connect, and basically we did an eligibility check from the provider system, then it hits the payer system. And then when that eligibility request and response are saved down, what Linux for Health does is on the node... or on the deployment you're accessing to kick off a transaction or you're sending a transaction through, it saves it down into an immutable database, and then that data is then synchronized throughout that network where Linux for Health is installed. And a Linux for Health network is simply a group of machines that are working together, that know about each other, that have done that handshake that we talked about earlier that can share data. And so when that eligibility request goes through, then it gets saved down, then it would go over to the Pi if you have enough storage obviously cause it's like a little device there, and then the payer system as well with that installation. And so what that allowed us to do is have, I like to call it like an optimized data path. But then again I'm the same marketing guy that came up with the Ingress endpoint, so that might not be the best name. But what that allows you to do is rather than having to execute that eligibility check each time through your healthcare journey... Like if your shoulder hurts and you go to see your provider first and then you have to go to Lab Corps somewhere to get an X- ray and then you have to go to a specialist, an orthopedist, instead of having to do that eligibility each, time you have that cashed and then that can be used by the other providers within the network.

Luke Schantz: So interesting. And you mentioned earlier about how at a future date when these systems are advanced, and it would be amazing as a user if I could pull up my phone and be able to figure out the status of a claim or of what's going on with my healthcare and be able to get up to date immediate information. Because it's crazy, Joe was mentioning earlier some of the roadblocks that he encountered this past week, which I think I gave him a dirty look when he said he forgot his... or that he lost his vaccination card, but I have a confession. I went to New York this past week to do a little shopping, and I went to Flushing, Queens for soup dumplings, and I forgot my vaccination card. And in New York you need a vaccination card to go into a restaurant. But luckily, I had my IBM Digital Health Pass Wallet and they accepted it, so...

Joe Sepi: Nice. I actually looked up the Health Pass and was thinking I might be able to use that for my booster, but it didn't seem to have enough information. I was confused because it only has I think my last shot in the Health Pass and you can go in and see the JSON, and I was like, " Oh, this doesn't have as much information as I had expected," so I'm glad that it worked for you.

Luke Schantz: I think you would need to send another copy of your card as you update it and then they'll update it I believe.

Joe Sepi: Yeah.

Dixon Whitmire: Yeah. Because I just recently got a booster, and I think I need to do the same thing because I had previously put it into the Health Pass, but I haven't updated it yet.

Joe Sepi: Yeah, yeah, I'm going to look at that. So we've been talking about Linux for Health and all this open source stuff, which of course what we love to do, but I know you work for Watson Health, and I'm curious how this relates to that as well.

Dixon Whitmire: That's right. No, sure. That's a great question. So with Linux for Health, what we're currently working on, which we're all excited about, is synergies with Project Alvearie, which you know from the previous show that Ted and Adam were on, you talked about Project Alvearie a little bit as being the open source assets and capabilities from Watson Health that are being put out on the GitHub so folks can consume those services and use them, just with the idea that you'll be able to better innovate when you have more eyes on the glass and you have something that is open source. And so what we're looking at with Linux for Health is how we can use that basically to provide data to Project Alvearie assets. With Linux for Health Connect, what that component and what that project is inaudible with doing, at least right now, I'm sure its use will grow in its purpose will as well, but it's designed to receive data and then transmit that data to other Linux for Health nodes in the network after it's been validated and all that good stuff. And so what we can do when we're talking about these EDI capabilities that we have, we could say, " Okay, let's let Linux for Health bring in whatever data is coming into the front door." We don't really have to care what the format is, but as long as it's a CCDA, X12, HL7, or some sort of FHIR from a FHIR implementation guide, we can feed it in through Linux for Health from the EDI project and then Connect, then the Alvearie component can consume those data events that are in FHIR. And so then what that allows Alvearie to do is ingest all this data it may not have had access to earlier, just because it wasn't able to parse HL7 or X12 or something along that sort. And so that gives the Alvearie components actually more use cases you can explore with.

Luke Schantz: Also, there was a Slack, right? There's a slack for Linux for Health.

Dixon Whitmire: Yeah, there is a Slack for Linux for Health.

Joe Sepi: So tell me more about Watson Health.

Dixon Whitmire: Well, Watson Health has been a just... Man, it's been a great experience just being here. Just going from an environment where I was working for a startup and we had a platform that we're building, and to be in Watson Health just to see all the innovation and everything that's occurring, I mean, it's amazing. There are lots of smart guys and gals here. And something that it didn't really take long for me to get used to is typically when you're working a startup, you do more than you should probably just because there's no one else around to do it for you. But here, it's like there are so many folks and they're all just so helpful. Initially, we started working with the FHIR server bit, so we got to interface some with the FHIR Server team and then we worked with Hyperledger Fabric with the healthcare and life sciences division, and so we got to work with some of the folks that work on that SDK, just on some of the integrations and things we're demoing. So definitely lots of cool stuff going on.

Joe Sepi: First of all, I marvel at being at IBM, at the people that I work with are just really helpful. It's interesting. I'm an open tech, and I do a lot of open source stuff, and the amount that we use open source in the things that we're building, in our products and stuff, is really impressive. So I'm spending a lot of time in Kubernetes and SDO and KNative and Tekton and all these open source projects, but they underpin our products. And it sounds to me, correct me if I'm wrong, but that's similar in Watson Health. We're talking about open source this whole time. And even when I ask you to talk about Watson Health, you still talk about open source, so it sounds like it's the same there as well.

Dixon Whitmire: Yeah, and that's the way it's going.

Joe Sepi: Yeah. It's just remarkable. I think it's really fantastic.

Dixon Whitmire: Yeah. And with the deployment methodologies, with Linux for Health, we are trying to be a bit agnostic and just say, " Okay, here's a docker container," because then if you want to use just straight up Kubernetes or if you want to use a helm chart or if you want to use Rancher or just some sort of orchestration methodology or if you just want to run the container in ECS somewhere, just listing off just different services, but you can do that and that's perfectly fine. With Watson Health Proper, one of the things we have been looking at is the obvious integration with Red Hat for some of our customers, and so there's an emphasis on Red Hat's OpenShift, which is a great platform that basically has a whole lot more batteries included with it from deployments in a CICD life cycle. And with Linux for Health, one of the first deployments I worked on with that when we're supporting UBI containers was a Red Hat OpenShift deployment on Azure, so that was pretty fun. However you want to deploy it, you can deploy it.

Luke Schantz: Dixon, is there, or will there be, or maybe the question should be, does it make sense for there to be a OpenShift operator for the EDIs or something like that? Could that be-

Dixon Whitmire: Oh, there certainly could be. I think where we are right now, just to be honest and transparent in our very early stages, we're trying to do things that aren't too opinionated just because we don't want to be too limiting in what we're doing. I think that I can see the use case for that down the road, and that might be something where that we have that open source flavor. And then in a fork somewhere or in a monetized product, if we get to that point, we would have an operator.

Luke Schantz: Well, I imagine that you're mentioning if there is a hospital or an insurance company that is already using OpenShift and they're like, " We want that," they could drive the fact that they need that to exist.

Dixon Whitmire: Sure.

Joe Sepi: That's the great thing about open source.

Dixon Whitmire: It is. And we are looking forward to... Next year, I think we'll see more around, because as I mentioned earlier and Ted mentioned, we're still in our early stages, but hopefully we'll have some organizational things around Linux for Health and external contributors that'll be more visible and that we can talk about in 2022 just as we're sort of ramping up.

Joe Sepi: Yeah, tell me more about 2022.

Dixon Whitmire: For 2022, what we would like to see there is more work around our longitudinal patient record. For some reason, that phrase is just something that's like a tongue twister for me always. It doesn't really roll off the tongue as an eloquent thing, but basically what we're looking at within Watson Health is the concept of an intelligent health record, and this is something that Linux for Health can help with as transactions are flowing through a provider network and being able to capture those, and have a platform that can represent that person's health record. Sort of like that aggregated view of the person rather than, " This is what you look like in this EMR or on this floppy disc or on this zip drive," if someone's still using that. In healthcare, probably someone is still using that somewhere. So I think what we're going to see is some closer integration with some projects that are yet to be open source within Watson Health just to help drive that feature in that pipeline.

Joe Sepi: Yeah, that's interesting. I think talking about intelligent patient records I think is fascinating, especially as our personal devices get smarter and smarter. I mean, I know that my watch here, actually, Target's telling me something, but I mean, it's continually monitoring my heart rate and all these things. And I think even the newer ones are somehow doing oxygen level or something. There's so much data that we could be pulling from our personal devices. It really makes sense to me to just have it all available to me that I can share with others. Yeah, I think that's the future.

Luke Schantz: Speaking of tongue twisters, I had to practice saying, " Open source distributed processing network operating system." I said that at least 12 times.

Dixon Whitmire: I can't take credit for that one. I have the Ingress endpoint, but I can't take credit for the other one.

Joe Sepi: I was looking at the word longitudinal. When it's written, it's even harder to say, like when you're reading it if you just recall it from memory.

Dixon Whitmire: Well, it's one of those words that looks like it's spell... You know how sometimes you look at the word and it just looks like it's spelled wrong, " This has to be incorrect," but it's the right one. inaudible

Luke Schantz: And maybe just to define it, so is it called longitudinal because it's crossing many domains versus-

Dixon Whitmire: Right, right.

Luke Schantz: Latitude would like be a deep system, whereas this is a wide system is the idea.

Dixon Whitmire: That's exactly right. Because when you look at just the way patient records are stored today, and of course your mileage may vary based on what healthcare system you're interacting with or you're a part of, but there's one centralized system that has all this data in it. It might be in a few places. It could be in a provider's EMR system or in a payer system, but then if you go to CVS, there may be another system that's a pharmacy benefit management system. And when you look at some of the legislation that gives patients access to their data, but especially the Blue Button legislation where you can just click the easy button and get all your stuff, one, it may not be in a format that is something you could actually do something with. And then two, it's actually from that specific system. It's not like it's everything. And so what the longitudinal patient record does is that is basically the holistic view of the patient's data across all systems would be the perfect case, golden scenario there.

Joe Sepi: It sounds like there's a lot of work to be done here. And obviously when you're an open source, you hope the community gets involved. But I just have to ask, are you hiring? I would imagine there's a lot to be done.

Dixon Whitmire: Well, I think we will be, and we're certainly open to pull requests and partnerships from external organizations. And with Linux for Health, within Watson Health and IBM are right now the primary contributors to it, but what we're looking to do, and the analogy that I like to use, is I want to healthcare what the Cloud Native computing foundation is for being cloud native and container orchestrate. And when you look at that, you have all of the big players, IBM included as a part of that, and so it'd be great if we could get other folks throughout the industry to come join us on this journey. And we are on some discussions right now. The more of the merrier. Right?

Joe Sepi: Yeah, absolutely. I'm not even sure we can talk about this or whatever, but I'm just curious, do you see any partnerships or things where we can start to work with some of our clients or other folks out in the industry that we can start to flesh out some of these things, I wonder?

Dixon Whitmire: Yeah, I think we will be able to. We just can't really openly discuss that at this point in time, but we are actively working with some other organizations just to get some pull requests in and to get some things over the line. Ideally, what we would like to do in the future is have Linux for Health governed by a board and have that level of governance in there as well, and so that's something that we're working on too.

Joe Sepi: Isn't there a Linux Health Foundation?

Dixon Whitmire: There is.

Joe Sepi: All right. I don't know if there are discussion's happening there, but if not we should start them. I know some people.

Dixon Whitmire: Okay. And that's an area where I think we've identified where we could be a good fit, and so we're just working through some of the logistics of that right now.

Joe Sepi: Yeah, yeah, very interesting.

Luke Schantz: Yeah, we had a guest earlier this year, James Snell, who was involved with that.

Dixon Whitmire: Oh yeah.

Luke Schantz: I remember there was a tracking app that they were working on or a contact app.

Joe Sepi: Yeah, yeah, the COVID stuff that NearForm had built I think was part of that conversation, right? Yeah, that's fascinating. And really, it seems like what we're talking about benefits everyone. Like we were talking earlier, the payer, the provider, the patient, it benefits everyone. So this is exciting stuff, and I'm really looking forward to watching how this develops.

Luke Schantz: And I think personally, I'm going to dig into some of these repos and check them out because it's a very exciting space, and it's poised for growth because I mean everybody feels the pains that we're talking about with these silos and the way things are communicating. In our prep call, we were talking about it, how many times do I have to fill out a photocopied piece of paper again and again. At a consumer level, I can only imagine that whatever I'm doing, how many other juggling acts are going on in these different various back offices, or maybe there's clear things in that data that could benefit me as a patient. But because they're in all those silos, they're not unified. There's all kinds of things, but this is such a... It's such a complicated space. There's so much regulation. And then obviously all these different organizations, they have their own levels of security.

Dixon Whitmire: And that's the real, I think, the challenge is that.. Now obviously, things need to be regulated in healthcare because you don't want to have folks just putting PII and PHI, like dumping it out in CSV files or putting it out on the internet, but the challenges that we have with the information sharing are not technical problems. Now, we couldn't do this, but I could share data easily if I have a Pub subsystem, and I send somebody data and they can just subscribe to it. I mean, that's contrived example, but it's not a technical problem that we have, it's more of a problem of working within the regulations, making sure that things are done in a secure and a transparent and safe manner, and then also to try to maybe work alongside these existing systems rather than positioning ourselves as trying to displace them. And I think that in the near term we could have some wins with EBI because the low hanging fruit is the data here. And so if you can make the data easier to work with, then the next thing we can work on is sharing that data with the different participants.

Joe Sepi: Yeah, yeah, it's fascinating. And I imagine in the healthcare industry, there are lots of really legacy implementations and systems and stuff, so I imagine inaudible.

Dixon Whitmire: When we were at PokitDoc, we were high fiving when Amazon released like their FTP client that you could use or their server where you could do that in the cloud. Because today with healthcare claims, we DDoS the payer just because we were familiar with the healthcare transactions, but we're becoming more familiar with healthcare processing, and so we were sending claims over in real time. And so what we found we had to do was say, " Okay, let's talk to these guys and see how many times a day we can send them data." And of course, out of this whole configurable suite a trading partner configuration was grown where we could even track outages to and uptime on the trading partner end, but we were able to batch the transactions and send them two or three times a day.

Joe Sepi: Wow. Again, the hour just whizzes by. I want to make sure that we touch on all of the call to actions.

Dixon Whitmire: Okay.

Joe Sepi: So let's say learning. I think Luke had the Connect Clients link up earlier. Is that a good place for people to learn more and start to get their hands dirty?

Dixon Whitmire: Yeah, absolutely. The Connect Clients repository contains tutorials for working with the projects in the Linux for Health ecosystem. Right now, that's going to be targeting the Connect Repo, which is the data ingress and synchronization. There are just lots of tutorials there with Linux for Health Connect that'll be helpful to start out with.

Joe Sepi: Okay.

Dixon Whitmire: And if you see the need for a tutorial that's not there, please reach out to us and do a pull request.

Joe Sepi: Yeah, that's the open source way, right? And then EDI, you mentioned that's a good place for folks to get involved as well, so that's another one. What else should we point people at before we hit the top of the hour?

Dixon Whitmire: Yep. The HL7 to FHIR converter is another good one that's in active development right now with IBM, that we're using it for some of our products that are both maybe closed source and open source. And so if you'd like to help out with that effort, I mean, that's available too because it's out there. And then Linux for Health Connect, that's still a project where we're still iterating on it a bit, but certainly take a look at some of the open issues that are out there. And if you feel like you could help with one... A great example is we would like to support Redis in Linux for Health Connect, a data caching system, and that's something that really would not take that large of an effort to do. And so if you'd like to work on that issue, reach out to us, let us know you're working on it, and then we'll help you through that process. Because we do realize too that we'll need to help shepherd the initial contributors just through the process just as we are still in our early organization, and we are happy to do so.

Joe Sepi: That's exciting. It's a really exciting space.

Luke Schantz: It is exciting, and I feel like I see a light at the end of the tunnel because it does seem... Like, we all know that there's problems, but this to me seems like this is the foundation that that can be built from. And as you mentioned, we have to do this in a way... These organizations are in motion functioning at scale and securely, so there has to be this path where they can implement it while they're still running the existing legacy systems. And right away, what pops to mind is, " Oh wow, we're really good at that already." That is something that we do on a daily basis at modernization across all sorts of enterprises, so I think it sounds like this project is set to explode.

Joe Sepi: Yeah, I think the app modernization stuff, but also the open source stuff, just knowing how to work in open source and help guide open governance and move things forward in the open source space. We have a lot of skills there too. I'm really excited about this effort, and I am really looking forward to talking more about it. I expect we'll be talking about this a lot.

Dixon Whitmire: All right. Well thanks for having me today, guys. Appreciate it.

Joe Sepi: Yeah, it was really great, Dixon.

Luke Schantz: It's been a pleasure. Thanks for tuning in folks and see you next time.

Joe Sepi: Cheers.