Video Case Study: How EHR Integration can Enhance Your Patient-Reported Outcomes Program

DOCSF17 Panel

Our CEO, Breanna Cunningham, presents a real-life case study about how one of our clients successfully integrated with their EHR to build an even more robust patient-reported outcomes program.

Ryan VanderWerff: Ryan VanderWerff, University of Utah, I’m the department administrator and I work at an orthopedic hospital and our department is heavily involved in patient-reported outcomes.

Nicholas Augustinos: I’m Nicholas Augustinos, I’m the CEO of Aver, we are in the business of helping customization of fee for service value base reimbursement [inaudible]

Benjamin Levy: Hello. My name is Benjamin Levy, I’m the co-founder of a [inaudible 00:00:54] firm called BoostrapLabs. We focus explicitly on the applied artificial intelligence technologies. Pretty active [inaudible 00:01:01] and looking forward to comments [inaudible 00:01:05]. Thank you.

Evan Leonard: Hello, my name’s Evan Leonard, I’m the chief of staff for a cycle reliability engineering group. That’s the group that keeps Google running all the time and continually re-engineers the system for better reliability, performance and efficiency.

Niko Skievaski: Thank you.

Evan Leonard: You’re welcome.

Breanna Cunningham: Okay, well first off, thank you so much for choosing this case study and I know there were many options and I think both Niko and I both are honored and humbled to be here presenting. We’re really excited to share this with you. This is a really cool story about a client of mine that we’ve also been able to really help maximize the value of their outcomes program. This is a case study story, ORA Orthopedics, which is a large private practice in Iowa had a dream to have a very robust patient report outcome program and they worked with my company, CODE Technology to collect that data. They use that data, integrate that data back into their EHR through REDOX.

ORA was asking this question that to everyone in orthopedics these days is which is how are we quantify our value. As a competitive marketplace they are a private practice business and they wanted to make sure that they stay relevant in their record place. What they realized is that they were lacking that numerator of the value equation. They didn’t have outcome data. By outcome data I’m not just referring to length of stay in a hospital or readmission data, we’re talking long-term patient recorded functional outcome data.

They decided that that’s what they were going to do. They knew it was going to be very, very difficult to collect that data but realized that without engaging with their patients directly they were not going to be successful in this day and In orthopedics. [Inaudible 00:03:06] all of which improved the quality and delivery of care and the profitability of their practice. What they didn’t have a dream of was actually collecting that data, that’s a pain. They did have a goal of collecting functional outcome data on every surgical data. That’s what the group came together as it was important to them. Then they made a list of nice to haves and a list of need to haves and they narrowed that list of need to haves down to three things. These were the core KPIs for their program. That is one, a high patience response rate. Not just preoperatively but also post operatively as well.

A system that’s non-disruptive to position a cloud and also a system that then integrates with the EHR that they were using. The first attempt that they had was partnering up with one of the major hospitals that they fee who also had dreams of collection patient reported outcomes. I should back up and say they wanted to have a program up and running within one year. First attempt was with a hospital. Raise your hands if you’ve ever seen a program between a hospital and a physician go swiftly and smoothly.

After six months they said this isn’t going to work. If we’re going to do this in one year time we want to go ahead and do this in clinic ourselves. Their second attempt capture rate, it was so low that it wasn’t meaningful at all. Even though 30% is still an okay number, it’s not enough to drive meaningful change. They said this isn’t working after giving it a good go for about a year and say what can we do next. This isn’t sustainable.

They thought what if we could collect the data outside a clinic and that’s when they found CODE Technology and that’s the model that we have for patient-reported outcome data. A year later, they’re winning. They’re doing a fantastic job. They’re building a very robust data registry. They have over 5,000 patients enrolled and their patient response rate is 75%. That’s at the one year mark. Not just pre-op but that post op data and they’re building a very robust registry. In addition, workflow is never disturbed and it has been a very good fit for that organization. They’re having this year after year championship performance, so they’re really succeeding.

Now that they have all this outcome data it’s time to dump it in the EHR so they can have it at their point of care for the patient. With that, I’m going to turn it over to Niko who does all the integration for CODE.

Niko Skievaski: Howdy. I love presentations like this much more than the one everybody saw in the main room because REDOX is behind the scenes where infrastructure patients, the providers will never know about us most likely because we are simply providing that interoperable layer between the applications that are out there doing the innovative things, coming up with really great ways to get patient reported outcomes out of patients. We look to enable that, so it’s always workflow focus which is why we started with CODE’s presentation because we want to know what that workflow, what is the data you need and when and why and how do we make it in a way that streamlines the experience that a patient has as well as the back office workings of the providers as well.

Really simply we’re going to hop into how that innovation actually works. ORA happens to be using the GE Centricity. We also powered the same integration with a number of other EHRs. I think we do ECW and NextGen for this exact integration. REDOX at large supports dozens and dozens of different EHRs through different types of workflows. The idea here is that we look at what the health system and the EHR are doing that’s on the left hand side of the diagram here and what functionalities nail that through EHR. With Centricity they have HL7 Traffic available based on the types of things that were needed.

What we’re doing in the re-op side is translating all of that traffic to a standard API that remains consistent across different EHR vendor and different limitations of those EHRs. The workflow here with CODE is first we need to onboard that patient, so we’re going to listen for any time a patient is scheduled for an event, for a surgery or for a pre-op visit. When that scheduling of when that happens we’re able to capture the demographic data from EHR and send that to CODE so they can actually create a patient within their system.

That’s step one. Step two if anything updates within that schedule, if it’s schedules, if it’s rescheduled, if it’s moved, we want to make sure that CODE has that data if the surgery is canceled we’re not asking the patient if they had a good surgery because they didn’t have one. That’s really important for the databases to stay synced up to make sure that there’s continuity in the workflow for the patient side.

Number three was important for the providers in the sense that often times they don’t want to be, we’ve heard about it in another room here, they don’t want to be logging into multiple systems and physician’s assistants doesn’t want to be logging into multiple systems. How can we get that data back into the chart where when they’re doing chart review before the follow up visit they can see what the outcomes data is. We’re sending data back into the chart and the summarized report view so the providers can get into that and see it.

As I mentioned, we can take the same integration and apply it within any EHR structure. Once CODE is hooked up on one side, the idea is as they go from the first client to the second client to the third client, their work is pretty much done, they can focus on making sure that the providers have a really good user experience that the clinic is doing well with capturing this data. We can simply turn on more clinics.

Similarly on the other side of the equations are the other types of applications that are available through that same API. This is where that network approach comes from that I touched on is that once it’s plugged in from the health systems point of view, ORA, they’re plugged into REDOX they potentially look at other applications that might be complimentary like a draft scheduling application or a video tele visit type interaction that is also enabled through the application with more turnkey access to those applications.

The value propositions here we see is on both sides of the equation. On the left hand side with the applications connecting once to many health systems and then on the right hand side the health system only has to do one integration project and then have a wealth of applications that they may be able to turn on. It addresses that question earlier that in the last room, how many branches can we put on this tree. As long as the trunk remains the EHR is a source of truth then that number can be really democratized down the line, down from the CIO practice management level to the provider level choosing what technology they will use and then potentially all the way to the patient level being able to choose I want to use this app or that app. That’s the vision that I think we’re getting towards with this interoperable network.

We really strive to put these applications as our heroes in this journey because they’re the ones stored out there selling products, selling value into health systems one by one. Each time it allows us to build this stronger network that we can all start benefiting from as the network becomes bigger and stronger and we see that network effects.

Breanna Cunningham: All right. In a nutshell we’re able to meet their goals. They’re really happy with their program, it continues to grow. They started with total joints, and have since expanded to everything, every surgeon in the practice is participating, and they also do patient experiences on their data on all patients as well (non-surgical) are all included. There’s a term that we use a lot in medicine which is practicing at the top your license. I think of that a lot in technology as well. For example, CODE collects data and we do it really, really well. REDOX integrates and they integrate really, really well. Sometimes you’ll see these EHRs trying to have a module or something that does one thing but not that great of a job of it.

I think what’s really neat about where we’re headed with in the future and with companies like Niko’s is you can find a solution that meets you needs that’s really specialized in the niche area. It actually winds up making the process more simple. What can we all learn from this case study? ORA did a fantastic job and I want to highlight some of the key things that I noticed with them in this program.

First off, set timeline goals. I cannot tell you how many people I talk to a week that have been having a patient report outcome program dream for five years and it hasn’t even got off the ground. They did a really great job saying we’re going to have this done. In one year we’re going to be up and running with something and they stuck to that. It’s amazing how quickly time goes by so make sure that if you’re starting a program wither its outcomes or whatever that’s involving, especially technology, that you have a clear timeline goal.

Second is set some standards, those must have, those things that you don’t want to budge from. There’s no such thing as a perfect system but you’re going to get one that’s pretty close. Find out what you’re willing to compromise on, what you’re not and make sure you stick to that. The third is fail quickly. I think that in healthcare, especially in the hospital side I see this a lot, we’re afraid to fail. If something’s not working we tend to try and push it more and more. Then years go by and you’re stuck with the same system. If you’re not meeting your goals don’t be afraid to pull the trigger.

With the first vendor that ORA was using they did a really great job making sure that there was an exit in their contract if they weren’t happy with them. I think that’s really wise. Make sure that you k now what that contract looks like. The next is select your vendors carefully, make sure that you call and get references. That’s super important. We deal with a lot of switchovers, and so make sure you talk. In a nutshell, thirds party apps are here to stay and which is really exciting because a lot of people are getting great products and great programs out there and you can really build your dream system like they were talking about in the last talk.

With that, I’ll it over to Q&A?

Kenneth T.: Thank you. Thank you both. At this point in time in terms of orthopedics, it obviously important transition times especially with the transition to value based care and so there’s a need for … This brings up a lot of issues in terms of data collection, quality measures and also brings up a lot with regards to integration. You guys, I just want to ask a couple questions and I want to allow the panelists to say something.

This was an outpatient group, this was a large medical group, correct, that was … Have you had integrations with larger hospital systems subsequent to that and how easy is that and what are the real barriers because it seem like technical challenges aren’t the real challenges. It seems to me that if I got to my administrator at my hospital and say hey I’d like to PRO outcomes by having them integrated, getting bandwidth of the FIT team, getting the support of the hospital administration, all those things, it’s going to be the hardest challenge.

Maybe give a sense for you say it scales to the next place but once you’ve done the technical work, how easy is it in terms of these subsequent deployment?

Breanna Cunningham: It’s still going to switch. I will say, I’m going to answer both sides of that question. The first part you talked about was or you eluded to was the administrative burden. I would say that’s much more of a barrier than a technical burden. One of the things that’s great about working with a company like REDOX is that they are very articulate and experts in all of these platforms. For me, for CODE, what we did was get REDOX on the phone with the CTO or their IT team and they can speak the language and it really does make them feel more comfortable moving forward from an IT standpoint.

I would say that just over the years with CODE we’ve been on for several years now and I’m seeing the IT barrier become less and less. I would say the most challenging part that we see is pushing it through the administrative realm, especially in the hospital setting and knowing your budget, knowing how to get that through.

Niko Skievaski: I’d really like to answer that first because we don’t want to say that we hope applications get through that process both administrative side as well as the technical side. Hearing from her it makes it seem so much more real to me. We put a lot of thought and effort into putting together a project finance scope that way we can go into a health system and say these are the five things we need to do. This isn’t a brainstorm about how we’re going to integrate this app because that’s the route you jump into when you go into a tech committee is they start talking about all the possibilities, they call up the EHR vendor that add six months to the timeline as he talks through all the different possibilities for how you’re going to do a project like this.

We go into these projects and say this is the value propositions that you’re purchasing from this application. These are the three data feeds that we know you already have running with a new system that you need to explore. This is the specification for how to get it to us and we don’t need you to change anything within that data feed. We will take it as it is and then the general stuff. That’s how we try to minimize the brain space that a health system, both administration and the technical teams, need to approve a project.

Because if we can go in there with project plan like that, it builds a ton of confidence on the health system IT team. It also makes a project easy for them. They can just do five steps rather than thinking of what those five steps should be. That’s what we strive to do as a partner when we’re bringing an application into integration space like a complex health system.

Kenneth T.: Does the complexity of the integration in any way impact what it takes to convince the administrators that are concerned for the data? Is that something that comes into play in health systems?

Niko Skievaski: Absolutely it does. First off, making sure that both us and the people we work with are fully HIPAA complaint and abide by that practices in data security. Second of all, we sometimes phase a project in what we call an integration project of least resistance where we might start by saying okay we’re just going to streamline onboarding first. So first project very simple, [inaudible 00:17:12]. Something like that where it’s a very simple standardized thing to do. After we improve value with that, show the consistency of it, it’s much easier to add up another scheduling feed, or push back data results. An iterative approach to integration rather than the kitchen sink at one time.

Breanna Cunningham: Could I add to that? Actually in this case, our case study that we presented, we did just that. We started off saying we nee4d your surgery schedule and fee. The reason that we focused on that and not the claims database or all the CPT codes or core morbidities, we started with that because we knew that the time sensitive component was that patient reported outcome. If we didn’t get it before surgery then doesn’t make a different if we get it afterwards or not.

Since then, we’ve been able to now start with a new integration and then pull in that retrospective data. We found that the exact strategy that Niko was talking about I’m sure it works for his other clients as well but that’s been something that’s been really successful, starting small and expanding and seems more palatable to the IT team.

Kenneth T: Ryan you have quite a bit of experience running a large orthopedic clinic in Utah. Maybe you can share; you also got quite a bit of data collection and also helped to create some of your own applications. Maybe you could share your experiences, questions you have.

Ryan V.: Thank you. As a department hospital administrator whenever we have the last five to seven years just third party applications of business interest come out of the woodworks and we get pummeled by that. It’s like every week there’s someone reaching out to us. We’re interested in them but whenever they tell us that they can integrate Epic and our CTO and CIO, they’re very skeptical because we’ve spent $250 million investing in Epic and why wouldn’t they leverage any functionality that Epic might have. Epic talks to them and says don’t worry we got a module coming out, stay tuned and then they really get focused in on that.

Our experience with third party applications with regards to integration is they use the term loosely and become very skeptical. They got to experience it and say – we can set an HL7 feed [inaudible 00:19:22], we can get everything you want and then by the time they execute and go down the road it’s not there. I just wanted to ask both of you when it comes to really complicated integration, and I mean not just getting patient demographic information, not just pushing that to the thirds party, getting down to can we interfere these applications with Epic like with my chart. Can we pull this data out so that physicians can drop them with their notes, like automate that data integration? How realistic is it for the more other complex integration?

Niko Skievaski: That’s a really good question. First off I want to talk to the multiple of applications that are hitting in this every single day because a lot of health systems have actually come out with a new role or a new department that the new integration department or the chief innovation officer because they can’t handle the inflow of startups trying to sell them gadgets. It can be overwhelming. I think the space that we need to start looking in the healthcare administrator standpoint is how can we get to a point where rather than applications coming to us and pitching projects that cost hundreds of thousands of dollars that takes months to implement, to a place more like we have with our phones in our pockets.

That’s one where we can find an application, we can try it out with very little or no risk and then see if we like it and if not delete it, no hard, no foul and basically make it to envision a world where application doctrine is democratized to a point where we can try things out quickly and allow the providers to have more say in what’s used. Because providers go to conferences like this and come back to administrators and say I have 10 things that I want to do. How can we make that easier? I think that this integration later is a missing piece of infrastructure that can really facilitate that process.

The second piece of that with the more complicated workflows is something definitely near and dear to our hearts because you can’t do everything with HL7 or with the available APIs that EHRs create, make available to applications. There’s a lot of things that need to be done by analysts working at the health systems who are configuring and maintaining their EHR instance. We are very cognizant of what we can and cannot do. Our teams, our product implementation teams, our solution matching teams, with project managers that have technical service people out there, so we know exactly what can be done from an outside interface perspective versus what needs to be filtered by analyst at the health system. We are not going to go against other people and build something with an app, that’s not the way that app, it works in the world or other EHR members.

Going into projects like that where you want a specialized button on the sidebar or you want a new window to pop up within the EHR, those are things where we say we can get data to that user interface but we cannot build that user interface. These are the steps and this is the at the user level article they’re going to look at to figure out how to do that, but that’s coped into the project. That’s going to be a 20 hour project for an analyst to do. We need to know that upfront.

He would scope that later as that’s not the integration project of least resistance – that’s all the bells and whistles later on.

Breanna Cunningham: And to add to that, when it comes to outcome data, let’s use the KOOs for example. There was 40 questions, there’s an overall score and there’s five categories. We get asked a lot upfront do you dump all this data in EHR. Well, first off, most likely your EHR has one data fill for KOOs. Just one. Sure we can put that back in there or you can work with your EHR vendor to see if they want to build out more of those but sometimes it’s … I find that people don’t really know what they want to look at until a program’s been up and running for a while at least with outcome data. With ORA matter of fact, they built their own custom report that they wanted as a PDF instead of flowing into that one data fill.

I think that with outcome data or with any program that you implement knowing not really perfect to be enemy of good with integration but knowing that capabilities and technology to do it exists.

Kenneth T.: That’s actually a nice transition to Nic. I don’t know if any of you were present at the discussion this morning when he presented the other case study. Gave a little bit of background about your company and also issues in regards to integration when it comes to outcomes.

Nicholas A.: First of all I want to highlight a couple things that I really like about what you said that I consider everything that happens outside the HER is an out of body experience and isn’t perfect. Because somebody said it earlier on [inaudible 00:23:59]. One day I called him on the phone and I said okay guys, if we put just for this screen pick a size, seven inches, whatever you want, put a screen next to each other for all these things that you’ve done, how many screens do we get in the room. They said not [inaudible 00:24:25].

Clearly, in IT integrations are very important. Having said that, I assume that there is a fundamental challenge and the challenge is that analytically to pull things out of the EMR is [inaudible 00:24:41]. At that point it becomes a challenge in these interactions. Coming back to your point, I think Niko what I like about it is you have to start with something that is so fail proof and start there and evolve from there because if you start with a challenging aspects of the workflow integrations.

In our case, Aver is helping our customers implement analyze and implement value base contents. In our case we chose to do as little integration as possible in order to avoid if you want a complexity of integrating with something that is not built with [inaudible 00:25:49]. Having said what I said, it is we run a process and application that is intended for care coordinator that is working with our system and not [inaudible 00:26:05] because we have found that EMR does not accommodate this transaction from one place, a value base in systems.

We try to minimize what we draw out of what we push back into an EMR. So far, to be quite honest, most of our customers that we have that are in this journey they chose not [inaudible 00:26:27]. I do have to say this. We started with a point and then we know REDOX because we would like to do exactly what they’re doing, but most of our customers the starting point is spreadsheet. When the starting point is a spreadsheet then [inaudible 00:26:48] you need to keep that in [inaudible 00:26:53].

The other thing that we try on commercially so to speak is to avoid the IT pitfall. The IT pitfall, I worked seven years with Cisco. I made global health integrations for Cisco. I talked to IT people all the time. Where there is risk associated with integrated with third party applications, whether it is a security thing, whether it’s a HIPAA, whether it is a technical thing or whatever it is, there are so many hurdles to overcome that commercially for a young company like ours – it is the kiss of death.

Kenneth T.: When you’re talking about PROs and integration you’re really talking about suppository building and pulling out demographic data then the patient needs [inaudible 00:27:41].

Breanna Cunningham: Right.

Male: Patient reported.

Breanna Cunningham: Yeah, patient reported, we call pull any sort of retrospective data into the system but in order for us to get started we take that scheduling feed and the patient demographics, reach out to the patient and then later on we can pull, let’s just say I wanted to know all your implant types or the reference number on that we can go over and pull that in.

Male: You are [inaudible 00:28:09]?

Breanna Cunningham: Yeah.

Niko Skievaski: One of the things I want to point out, what you said was really important that applications solutions shouldn’t strive to integrate unless it’s mission necessary. I think CODE’s a great example of this and that they brought the product to market at a value for customers before integration became a topic. Integration’s kind of the last mile of streamline the workflow is going enterprise wide so that way when the latter joins the systems it’s going to be as smooth as possible.

There’s always early adopters who have a very difficult problem that they’re trying to solve. They will log into a new system. They will use something else. It doesn’t necessarily need to talk back to the EHR to deliver that value. One of the reasons why we do what we do at REDOX is to support these types of innovations that are coming to market. We talk to them every single day. Dozens and dozens of new applications every day and probably about half the time we’re telling them that sounds like an awesome solution. You shouldn’t do integration until you have your customer live already. You should put it in your project scope after your pilot, after the go live, after you deliver value and prove value. Because if you put it at the beginning, it’s going to kill your project and it’s going to kill your sell.

We probably leave projects on the table because of that. At the end of the day, if they can integrate later on, it’s going to be a customer process, it’s going to grow the network out and make it stronger. You don’t want to get in the way of adopting new technology. We want that technology to be in the use of clinicians as fast as possible so they can see as they get value out of it.

Kenneth T.: Just for perspective, how long was it for you to put something like this in place?

Niko Skievaski: I’ll give a general answer, Breanna can give you what actually happened.

Kenneth T.: Yeah.

Niko Skievaski: Because those often vary. Typically when we scope out a first project with the first application and their first health system it’ll be about four to six weeks depending on how many different data interfaces we’re looking at. It’s like first week is connect up, it’s the actual connectivity into the API connection. Second week is mapping their data into our data models. Third week is testing. Fourth week is go live.

Variability in that process really comes from the health system side. Can they keep up with that timeline? We have some groups that were at 10 going on 15 sites who have now where scoping projects at five days where set a day one connectivity, day two data mapping, day three testing, day four go live. It can get much shorter than that but if also they can keep up with it.

What happened at ORA?

Breanna Cunningham: I was just trying to think in my mind. I think we started, I think it was around five or six week with ORA. Since then it’s gotten a lot shorter. We’ve learned that on CODE’s end- what we need to give the IT team. REDOX did a great job coaching us so we could start the process before we jump in with the actual migration.

Ryan V.: Just by contrast to that, in Utah we’ve been collecting the patient-reported outcomes for over three years now. It took us, our spine and joint team started this eight years ago on spreadsheets. What was it Chris, five or six years ago we actually started link together, couldn’t find a vendor, couldn’t find integration so we decided to build it ourselves. We hired coders, and all this and it took us almost two years to get something in operation. Just the contrast. We did prefer to keep to our core competency in providing first grade surgery and care rather than getting into this business.

Male: Sorry, was yours in the home as well?

Ryan V.: Yeah, they do it two ways. We’ve got ipads in the clinic, but we prefer to do it over email. I think that’s a 75% completion rate.

Breanna Cunningham: Which is fantastic by the way.

Male: You have a coordinator.

Male: We did not really have a coordinator there, we just .. it is painful

Male: That is painful. It was.

Breanna Cunningham: Sorry we didn’t meet before.

Benjamin L.: Stefano asked me to come to this conference today. I think you provided a different viewpoint. I’m coming from the outside of the healthcare world coming from the world of technology now and where we spend a lot of time of deep technology, we heard a lot about artificial intelligence and it’s just does work for many [inaudible 00:32:24]. As I’m observing what’s going on today I think there’s all great conversations. I think it’s great to see people from across the board.

When I was you guys here I see hey I’m all about healthcare platforms because the future you want to have the data, you want to basically make it available when it’s needed, extremely quickly. The challenge as an investor looking at this I’m like most of the stocks we invest into they not only go buy quickly the products, and they own the data and they make it available [inaudible 00:32:52]. Here, I’m looking at someone that’s helping large organization that’s struggling to design project and so you’re really helping them figure it out. That’s a very conservative approach to developing a product that might not even scale to the next organization because the doctor have other friends and preferences.

They’re not looking at the guy [inaudible 00:33:06] but relating that to the experts and facilitating that at the same time, we need to teach what rights do you have to that data. You can do other things with it than just providing it back because otherwise as an investor I’m like what am I investing into [inaudible 00:33:24]. That’s why I think the vendor industry is looking at us and saying what the hell and I’m getting real day maybe testing on millions of customers at a time to get feedback on my products when it’s going to take you six days to design it, but you don’t [inaudible 00:33:41].

At the same time, how can we make it more consumer driven because you have more control, there are companies that are providing to them actually on the data or they got the rest of the data to do other things. The investment we made so far is actually into the mental health and wellness space. A company that is regarded just like [inaudible 00:34:13] in the market provided what is needed and then talking about the data information going through the [inaudible 00:34:20] actually providing that as benefit. [inaudible 00:34:22] …

We’re looking to invest in skilled technology companies and for that we don’t like waiting around for a while collecting data information, providing them to the customer and then use that data and just go back and so hey, actually medically it’s proven that it’s doing as good or better that what has been done before. That’s just a bit of context. It’s not [inaudible 00:34:48]. I’m fine what you’re doing, but it’s important [inaudible 00:34:53] …

Niko Skievaski: … we can’t shut off anybody else. We can’t even give that to patient who is at or who ask for that data. HIPAA says that patients have the right to download data, meaningful use gave us the ability to or the regulation that says they have to be able to download it electronically. They didn’t specify what that means to download it electronically. In the privacy policy it must also specify what electronically means. At my doctor, electronically means a PDF saved onto a DVD. My laptop doesn’t even have a DVD drive. That’s what we’re looking at in this world.

I think that once a network like ours is in place we can actually give patients the ability to authorize the use of their data to an application, any application they want. If CODE was selling a product that a patient can directly benefit from and the patient says I got a knee replacement at UCSF, I want to use CODE to manage my care or whatever they might seek value in. they can authorize CODE to have that data and UCSF doesn’t even necessarily need to know that CODE gets the data because the patient authorized it. All the health system needs to be able to do is deliver the data to a patient in a way that is interoperable in an API fashion.

That’s the future of where I think this is going is that once we’re at a place where patients can authorize the use of their data and can become the brokers of it, and then that changes data all together because no one likes selling to health systems. We’d much rather deliver the value to patients, let patients choose where they want to bring that to whatever health systems and applications could do that if this API infrastructure was in place.

Male: I good Trojan horse might be use a word together, make sure that every application she builds there’s a [inaudible 00:36:35] data button and then you guys can aggregate it and then something else needs to be there.

Niko Skievaski: After market.

Male: Yeah, and this is after ….

Male: You want to offer the end user the ability to [inaudible 00:36:47]. You want to capture all that information, make it secure and then allow them to do other things with it.

Niko Skievaski: Yeah, exactly. Right now we use this A to B use case to build this network of patient data flow. Hundreds of thousands of records to look through every single day, but it goes between A and B, that application, that health system. It’s flowing through this exact same network. It’s multi-tenant system, so it’s all going to the same place. We can very easily add functionality on top of that to say any application, and there’s thousands of applications. They’re integrated through us, any of these applications can use a patient authorized workflow to actually let the patient verify who they are and then authorize their application to have that data.

Male: Last point in the charts you have on your presentations where you go to the systems and then you go back to the application builders. It sounds like you were building a clearinghouse for all this data coming [inaudible 00:37:44]. Do you see variety between should we recommend you to someone else, do you fail the projects? Where eddo you get the most variety to do?

Niko Skievaski: Within our business call we have two points of [inaudible 00:37:54]. The first one is exactly what you described. We started working with CODE, obviously our discussion started before we had any integrations with them and then it went to one integration and then it went to two. Is it five now, six?

Breanna Cunningham: Unreal.

Niko Skievaski: Yeah, there’s a lot. There’s many. What’s great about that is that that grows the network out. Coincidentally sometimes a network overlaps where two applications will work with the same health system. In that case, we don’t have to do anything but start flowing the data because it’s already connected. That’s the first order virility model. The second one is once we’re plugged into a health system and the health system obviously knows that they’re going through the ops because we’re working directly with the IT team. The health system said that was really great for this first application, I happen to be working with five other. Can you work with them as well?

The health system starts turning into a channel partner and then from the channel partner we’re actually starting to sell directly a platform to health systems to say plug us in and then it’s on you. Give me a call for whatever applications you want. The end state with that is if every health system had a platform like ours and applications can move without any barriers between health systems and I think that’s the world that we want to get to where people like CODE shouldn’t have to pay to integrate. Integration should be a commodity that if you sell your product because the values and the morals of your product, you shouldn’t have to go through the turmoil of figuring out how to do integration. That should be a turnkey thing that happens because we’re all doing it the same way.

Male: To partly answered your question. I think people like REDOX who are bringing integration are forward engineers or building information super highway, connecting cities which are hospitals, which then allow interesting [inaudible 00:39:32] like ours, which is predictive analytics, which [inaudible 00:39:37]. You can see that this room is packed; some of the other rooms are not packed. That shows you how much interest there is in integration. To what the guy from Utah talked about [crosstalk 00:39:50] …

Breanna Cunningham: [Crosstalk 00:39:49] …

Niko S.: Thanks.

Evan L.: [Inaudible 00:39:57] I’m glad you raised some of the issues you did. Coming from a technology background, I’m similarly asked to provide that point of view. I think what I might add would be in terms of ORA you touched on the contract at the beginning. I guess this is a question for the room too. You haven’t captured marketing right now, right? You have the people who are your insurance companies [inaudible 00:40:19]. What we’re talking about is a future where we aren’t; somebody was saying they’re not consumers before, but a little bit more like a consumer when the promise that you’re promising happens and you can actually take your healthcare with you.

If you don’t build … My background, I’m bringing organizational design and development, and it’s fine if you make one of these changes in 12 months or 18 months. It will be the hospital systems and the systems that actually integrate these changes in a week. That doesn’t just have to do with the technology, that has to do with the culture. it has to do with the administrators, it has to do with attitudes and audience that you have as what your purpose is as an organization.

If you’re not working on those things as well, you’re not willing to enter into different sorts of contractual engagements with vendors when they’re exploratory and open-ended and your initial outcomes or initial things may not [inaudible 00:41:12]. You’re not willing to engage in those types of integrations if you don’t have that expertise internally, the whole thing will come crumbling down at some point. With more innovative healthcare providers you won’t have company. That’s where this world is headed now.

I don’t know if you have thoughts about that. Just sort of a future organizational structure in the health system once the democratized exodus and the outcome. The customers can choose based on outcome.

Breanna Cunningham: What I would love to see is … By the way, my background is I’m a nurse and worked clinically in bedside for a long time and then also had the role as a hospital administrator. I would love to see what we saw with ORA, which was a fail quick. The contracting component of hospital, it’s a nightmare. Anyone that sells to hospitals knows that it’s really, really hard and it’s also equally as hard to usually get out of that contract. I think that with innovations like those in this dream world that we’re describing that we’ll see that process happen quicker. I think of it like San Francisco. If you’re not at a restaurant you’re out of business in two weeks. I think it’s going to be the same way in my dream; it’ll be the same way with these products.

Niko S.: I thought a lot about how right now technology buy-in in a health system is, it’s at the top. The CIO’s office is proven or it can put a barrier out for all technology because they have to manage all the technology. The legacy world of on premise offer means that it needs to go somewhere in the basement. That’s the legacy mindset. Basically, if I understand the question right, correctly is how to get from there to this consumer based world of apps flow freely without any of this.

I think that there’s a lot of discussion in healthcare about how do we … Healthcare seems to be primed as an industry to be disrupted, to be replaced; much like Blockbuster was with the Netflix version of it. I don’t think healthcare can be because it’s too entrenched, it’s too big. It’s like replacing our stock market financial system. There’s too many ties into everything and it’s too big of a problem because the continuity in so many systems that have to somehow work together. We’re not going to have Uber healthcare or Airbnb of healthcare that will totally make taxicabs a job.

Hospitals will be there, providers will be there, academics will be there. I think what’s going to happen, what I hope is going to happen is that we can start moving around that spectrum from status quo to disruptive. I think that there’s a spectrum in that where you can move down the line and say how do we take the technology buying decision from the CIO’s desk and pass it to the orthopedics department. Because there’s an infrastructure in place where the CIO knows looking into this infrastructure then ortho department do whatever you want because we know that that infrastructure is secure and we know that it’s not going to hurt our source of truth, which is the EHR.

Once it’s at that department level how can we go a level deeper down to the sub-departments are to the shift level or even to that provider level and say as long as it’s plugging into this infrastructure and at the end of the day where this goes and this is really where disruption happens is when it gets down to that patient level. That’s how Uber did it. They went straight to the drivers; they went straight to the people needing rides. It didn’t come from that organizational side but I think in healthcare there’s a way to do that down spectrum if we have forward thinking healthcare organizations who are willing to release some of that power as long as they understand that the data will be secure.

I think in all these organizations who are creating innovation departments have that mindset. They want to do that. It’s just how do we actually take that first step. I think infrastructure is a big piece that’s missing that people are still scratching their heads on.

Male: Ken I know we’re running short. Just quick. A lot of corporations they come to be [inaudible 00:45:09] close to innovation. Ideally I tell them look there’s a spot. It’s not about [inaudible 00:45:16] innovation; it’s about actually bringing outside innovation in more efficiently. In your case I’d be curious to see can an organization like yours maybe set, full all the historical data and put it in a sandbox where you might [inaudible 00:45:30].

A lot of the patterns are looking for, a lot of the features that you have to deploy could be back tested very easily. You can test it, if it works or it doesn’t work and what feature people would want to see before it even goes live, as opposed to it has to go live, it has to collect data, have to wait for results. How could you do a lot of that work beforehand by creating safe, secure sandboxes for third party application to go and test?

Male: We’ve run out of time, so I don’t have time for questions from the audience. Two things to point out, one is Breanna’s company is the one that’s live streaming this event so we need to thank her for doing this. Second is look forward to seeing you next year.