0:00 Jared Jefferey ｜ FHIR and CMS ｜ KERI Conference 2026
0:03 All right. The title
0:05 of the talk is FHIR and CMS. And
0:08 we'll talk a lot about that. I actually
0:10 want to spend a little bit of time today
0:12 going over what the vital framework is.
0:14 It's actually the vital initiative. I
0:16 need to change the slide on this.
0:17 This is an old one and as you can
0:19 see, it's glitching out. But I want
0:21 to talk through this, what it means, why
0:23 it's important what the acronym of
0:25 verifiable identity and trust automation
0:27 layer is. Here's just a quick
0:31 intro. We're going to go through CMS
0:33 and their standards process
0:35 interoperability standards in
0:37 healthcare kind of at large, how we got
0:39 to what FHIR is now today.
0:41 What is FHIR? And we'll go very high level
0:45 on this. You we're not going to go into
0:47 kind of the different IGs within FHIR.
0:50 We're not going to talk about
0:51 FAST necessarily. Just this is
0:54 FHIR 101 for the KERI ecosystem as
0:57 they want to come up to speed on the
0:59 applicability of the KERI ecosystem for
1:01 different industries. Then we'll talk
1:03 about CMS-0057-F and then we'll talk about
1:05 The VITAL initiative. So just as a as
1:08 a high level Jared Jeffery CEO founder
1:10 at healthKERI, a startup
1:12 that is in the industry of the
1:16 missing trust layer for healthcare. So
1:18 we have adopted some open source open
1:20 standard protocols. If you're at the
1:22 KERI conference, you can probably guess
1:24 as to what those are. But for us, it
1:27 is imperative that we see this
1:31 trust layer be implemented into the
1:33 healthcare ecosystem. As a little bit of
1:35 background on myself: I am a
1:38 fellow of the American
1:40 College of Health Data Management. I'm
1:42 former class research. Class is
1:45 probably the biggest name in health-
1:46 care's market IT research and convenience.
1:49 They've spent years and years
1:52 getting all of the right
1:54 groups into the room where typically
1:57 those groups are very contentious.
1:58 They'll put those people down in a room
2:00 say take your hats off. Let's
2:02 actually solve problems. And so they've
2:03 done a lot of work like getting pairs
2:06 and providers to come together and talk
2:08 about solutions which is the fact
2:10 that they did that and it never came to
2:11 blows was I think actually a miracle.
2:14 And then previously, you know, my
2:17 educational credentials come both
2:19 from UVU. So happy to be back at
2:22 the alma mater today. And then
2:25 WGU, which is Western Governor's. Okay.
2:27 Want to talk about just really
2:29 quickly why it is we're doing this in
2:32 healthcare. So my background is one
2:36 15 years in healthcare IT, yes, but
2:38 I'm also a brain cancer survivor and
2:41 patient myself. So at one point I was
2:43 being treated by the single machine in
2:45 the entire Rocky Mountain West that
2:46 could provide me the care I needed to
2:48 survive, to thrive. Without that
2:50 machine I wouldn't be here today. The
2:53 reality is that for many millions
2:56 of patients that is a very similar thing
2:58 but often for them it is not some
3:01 bespoke proton therapy machine that
3:04 is hard to build. Oftentimes it is
3:06 something as simple as access to an
3:09 ER doctor at the time they need an ER
3:11 doctor. And so one of the things that
3:12 has started to happen increasingly is
3:15 that as these ransomware attacks which
3:17 are targeting healthcare, (we'll talk a
3:18 little bit about that in a minute),
3:20 the targeting of this industry has
3:23 real world implications. So the why for
3:25 us, why we're here, why we're doing this
3:27 is because as we increasingly move
3:31 care into a digital context, we
3:33 increasingly make the risk to patients
3:36 explode. And why is that? Well, if you
3:38 shut down a hospital using a ransomware
3:41 attack, the first response that
3:44 hospital has to do from a care
3:46 perspective is send every ambulance
3:48 that's supposed to come to them
3:50 someplace else. And especially
3:53 in the US that ecosystem is incredibly
3:55 fragile. And so if you're talking about
3:57 for example an urban center, they may
4:01 have to push hospitals out to hospitals
4:03 in rural centers and those hospitals may
4:05 not have the same equipment, they may
4:06 not have the same training, they may not
4:08 have a level one trauma center. So if
4:10 you shut down a large health system, you
4:12 are actively threatening the lives of
4:14 patients. In fact, NPR about two years
4:17 ago put out a report that stated that a
4:20 ransomware attack on healthcare should
4:22 be considered as disastrous as a
4:24 natural disaster. So a
4:27 tornado or hurricane, they are the same
4:29 level of disruption. The difference
4:31 of course is while we can blame God for
4:34 tornadoes and hurricanes we blame
4:36 Russia and North Korea for the
4:38 ransomware attacks that are happening in
4:39 the industry. So a little bit of data
4:42 on this. Healthcare is the most
4:45 targeted industry by a large margin
4:48 when you look at some of these other
4:50 pieces. There's a few reasons for
4:52 this. They're also the most
4:54 expensive. So, this is part of what's
4:56 driving that. You'll get the biggest
4:58 payout if you're holding a knife to the
5:00 throat of an organization that has to
5:02 pay you or people will die. And so,
5:05 attackers know this. This is a
5:06 persistent data source. This isn't just
5:09 one year. This has been for the last
5:10 decade. Healthcare has been the most
5:12 targeted industry. So one of the
5:16 questions we get all the time is why
5:19 attack patient data? What's the
5:21 value proposition for an attacker to
5:22 come into this ecosystem and to
5:24 compromise all of this data? The reality
5:26 is there's a few different things. The
5:28 first is that on the black
5:29 market, a patient record is typically
5:32 10x or more the value of let's say a
5:35 credit card, which makes perfect sense,
5:37 right? You your credit card gets
5:38 compromised. What's the first thing you
5:40 do? You call up Capital One or Chase and
5:42 you say, "Hey, I lost my card." And
5:44 within a week, they've got a new card
5:46 for you, right? They've rotated you to a
5:49 new credit card number. And you're back
5:50 up and running. When you lose your
5:53 medical record, you're losing your
5:55 social security number, you're losing
5:56 your date of birth, you're losing your
5:59 name, you're losing typically one or
6:02 two payment methods, and you're also
6:04 losing all of your medical information
6:06 itself. None of that can be rotated. As
6:09 much as I'd love to call Capital One and
6:10 say, "Hey, you know, I've got brain
6:12 cancer. That's great. Can we rotate this
6:14 to like diabetes?" I'd prefer that
6:16 it just doesn't work that way. You have
6:18 immutable data in a health record, which
6:20 means that the value of that data lasts
6:23 for as long as the data is valid,
6:25 which is forever. So with that data,
6:29 there are a number of different things
6:30 that they can do. So one is just selling
6:32 the records online but beyond that it's
6:34 things like standing up fake clinics
6:38 to execute fraud to CMS and it
6:40 [inaudible]
6:49 I can prove to CMS that I'm treating you
6:54 and I can do that at a scale of
6:56 hundreds or thousands of clinics.
6:57 There was actually a clinic, this was
7:00 two years ago, I say “clinic”, there
7:02 was a group in Florida that was found to
7:04 have absolutely no patients, but they
7:07 had a whole lot of data and they were
7:08 billing CMS pretty
7:11 aggressively to get money out of that
7:13 system. Other things to note here
7:15 is and this one I actually want to hit
7:17 pretty heavily which is extortion
7:19 attacks. It used to be that the
7:23 primary attack surface that an attacker
7:26 was looking for, the monetization
7:27 that they wanted was if I hit a
7:31 hospital, they'll pay me $7 million to
7:33 unlock my data. And that's still true.
7:36 But these days, the attacker actually
7:38 also couples that with exfiltration of
7:40 that data. And because AI has made the
7:43 cost per extortion so low, they'll
7:46 now go after individual patients as
7:48 well. So they'll go after .., a recent
7:51 article I read was that a bunch of
7:53 mimography images were captured and
7:56 they were actually going to individual
7:57 women and saying, "Hey, we have
7:58 compromising images of you from this
8:00 this data that we pulled out of your
8:02 health system. You're going to pay us
8:04 $2,000 or we're going to put these out
8:06 on the dark web." And so it used to be
8:08 that $2,000 wasn't enough to get anybody
8:10 interested. These days, because it is so
8:12 simple and easy to make that attack, and
8:14 by the way, I already have all your
8:15 contact information, we can just set
8:18 up a script and the AI can extort for us.
8:20 Which is obviously not terrible but
8:22 when we ask about 'Why is healthcare
8:24 so compromised?', it's because it's
8:25 insecure it's high value and the
8:28 data doesn't change across time which
8:29 makes it a really good find and
8:32 can be resold multiple times in the
8:34 future.
8:37 The other problem here is, not only is
8:40 healthcare's data incredibly valuable,
8:42 it is also incredibly complex. So you
8:45 have health systems, you have health
8:46 payers. These are typically the two big
8:48 players in the space. Each of these
8:50 ecosystems will on average have about
8:53 1,500 connections. So the average health
8:56 system has got vendors that are
8:58 connecting into their system doing a
9:00 number of different tasks for them. Each
9:03 one of these connections represents
9:06 an attack surface for the attackers. I
9:08 showed on that previous slide about 3/4th of [inaudible]
9:11 of actually originate in an external
9:14 party. So I think a good example of [inaudible]
9:17 helps people understand [inaudible]
9:21 happened, is probably five six years ago now.
9:24 All of the credit card information in
9:26 Target got stolen. The way that they got
9:28 in was through the HVAC vendor. So the
9:30 HVAC vendor had a connection into
9:31 Target. Obviously HVAC, he doesn't
9:34 feel like he's got to be all that
9:35 secure, but simply by virtue of
9:37 connectivity, they were able to do a
9:39 privilege escalation attack, which is
9:40 basically you compromise the first set
9:42 of credentials. You move from those
9:44 credentials laterally to somebody else
9:45 that has better access into the system
9:47 and then you can move up. Eventually,
9:48 you're looking for a sysadmin role.
9:50 Once you have a sysadmin role, you have
9:52 keys of the kingdom. You execute your
9:53 ransomware. You know, within a month,
9:56 the cyber insurance will have paid
9:58 out the $7 million because the
10:00 hospital's got to get back up and
10:01 running. So that's the attack in
10:04 a nutshell and this is the risk. So
10:08 again thousands of connections coming
10:10 into the system each one of them
10:12 representing a potential attack surface
10:14 for bad actors to enter in. So we used
10:18 to think and I think some people still
10:20 do that if we've encrypted the
10:22 channel then we have a secure connection
10:23 and the reality is that the attacker
10:26 will most often use that channel
10:29 against you hunting for what we call
10:31 shared secrets. This is a shared
10:33 credential. This is username and
10:34 password. This is a bearer token.
10:36 There's a number of different things
10:37 that qualify as a shared secret. Our
10:39 contention is that we probably should
10:42 stop letting them steal these shared
10:44 secrets. Impersonating your third party,
10:47 moving through the channel that you
10:48 trusted to be secure, and then
10:50 exfiltrating your data. It's time for us
10:52 to actually reduce the attack surface by
10:55 taking this piece here and removing the
10:57 shared secrets that come into the system
11:00 so that those attacks are no longer
11:02 valid, no longer reasonable for an
11:05 attacker to execute. Now, we've talked
11:07 about earlier today a lot of the value
11:09 in terms of the connectivity problem
11:13 with regards to onboarding, with regards
11:16 to the manual lift on it. One of the
11:18 other things that KERI does for us is
11:20 this. It allows us to create an ecosystem
11:23 of true zero trust where there is no
11:29 compromising credential for
11:32 participants to be attacked on.
11:35 In fact, we've actually shown this. We
11:36 had a pentest done on a system that
11:38 was basically running this. We stood
11:40 the system up. We were running hundreds
11:42 of thousands of FHIR
11:44 transactions, (We'll talk about that in a
11:45 second) through the system, we
11:47 brought in some white hat hackers. We
11:49 pointed them to the system and we said,
11:51 "Go ahead and break it. Here's
11:53 everything that you would need if it was
11:54 a traditional system." They came
11:56 back and said, "We can't get into the
11:58 system. There's no serious flaws that we
12:00 see." It was humorous to me though
12:03 that they did say, "Hey, there's no
12:04 TLS on this connection. So you guys are
12:07 missing that. Maybe you should put it in
12:08 there." And the reality is we believe
12:11 that KERI-based connectivity is
12:12 actually a replacement for TLS.
12:16 Tthat's kind of the background on
12:19 healthKERI and why I think the vital
12:21 initiative and what we're going to talk
12:22 about today is important. Now let's get
12:24 into what CMS is, what they actually do,
12:28 why they matter. So very high level CMS
12:31 is the Centers for Medicare and
12:32 Medicaid. Remember Medicare is for
12:35 the elderly, Medicaid is for low-income
12:38 individuals. So we care about our
12:40 elderly, we provide aid to the poor.
12:42 That's the way I always remember it. And
12:43 then you can keep those two straight.
12:46 It's important to note that while not
12:48 all care happens through CMS, they're
12:51 managing what was it like a trillion
12:53 dollars? 1.2…
12:57 1.8. So round up, you've
12:59 got a couple trillion dollars flowing
13:01 through the system every year, which
13:03 means across years it's trillions and
13:04 trillions of dollars. So even if you are
13:07 not a Medicare or Medicaid plan, even
13:09 if you're not accepting Medicare or
13:10 Medicaid dollars this is the 800 lb
13:13 gorilla in the room. So when they speak,
13:16 typically everybody listens. Yeah. Mark
13:18 – Amendment. Medicaid is not run by CMS.
13:22 – Right? It's state-run.
13:24 – The states… the reason they
13:26 have the
13:28 some level of control is that they'll
13:30 pay a 90 / 10 split for investments into
13:35 Medicaid.
13:38 – That's good clarity. But at the end
13:40 of the day, the reality is that if you
13:42 are looking to get money out of the
13:44 healthcare system it would be wise
13:46 of you to listen to and abide by the
13:50 regulations that CMS puts out. Now
13:52 CMS themselves typically do not
13:55 originate standards. What they like to
13:57 do and what they've done numerous
13:59 times in the past is that they will work
14:01 with an industry group like HL7 who
14:04 who stands up the FHIR standard and they
14:06 will basically say these are the things
14:08 that we are looking for. There's deep
14:09 collaboration there. FHIR will say, okay
14:12 let's get the industry together, we'll
14:13 stand up a standard like FAST which
14:16 is what Mark was talking about
14:17 earlier today. Once they have a an
14:20 acceptable standard CMS will come
14:22 back and basically bless that standard,
14:24 put it into regulation and say this is
14:26 how we want to see things done. So, for
14:28 example, we talked about pretty
14:29 extensively earlier today, CMS-0057.
14:33 It is a regulation. It's a requirement
14:35 for payers. They will not get or will be
14:37 penalized by CMS starting January 1,
14:40 2027. And that penalty is based on
14:43 whether or not they have a FHIR API
14:45 endpoint. So again, you start to see
14:47 this converging of the federal
14:49 regulators working with industry groups
14:52 to establish these standards, then
14:53 enacting them into mandate. And then
14:57 often, but not always, though I
15:00 would argue the most effective ones
15:02 are when they tie those to payments. So
15:04 if they say, "Hey, you're going to get
15:05 penalties. You're going to get fines.
15:06 We're going to cut off your Medicare
15:07 Medicaid funding." That's when you
15:09 actually see the industry move. And
15:11 then yeah, they'll come
15:12 in and they'll basically say by X date
15:14 you want to see Y happen
15:17 within the industry. So let's talk
15:20 about kind of the history of these
15:22 standards, how we got to where we are
15:24 today. I think there's some
15:26 instructive pieces here. It's important
15:28 to note that we started with what I
15:30 would call foundational interoperability
15:33 standards and as we've moved across time
15:35 we've moved up to, I think, much more
15:37 useful standards which would be
15:39 network interoperability standards. Now
15:42 I want to give a couple of
15:44 definitions here. So a foundational
15:46 standard is basically just what's the
15:48 pipe look like? If you stand up the pipe:
15:50 good, you've met the foundational
15:51 standard. And there we'll talk about
15:52 some examples here in a second.
15:54 Structural is really just: I have
15:56 the pipe. I know that the data is
15:58 coming through and the reality is that
16:00 this is for a diabetic, let's
16:02 say it's a glucose test. That's
16:04 more useful than just: "Hey, data is coming
16:05 in and out as you move up the ladder
16:08 to like semantic data. This is where you
16:10 start to get structure and coding into
16:12 it," which basically lets you say things
16:13 like: " Hey, this is a glucose test, it needs
16:15 to go into the doctor's decision support
16:18 tool." Right? So as you build the
16:20 standard on interoperability, you get
16:22 more and more value out of the data
16:23 that's flowing in and out of the system.
16:25 The network standard, and this one is ..,
16:28 these are I would say adopted
16:31 nomenclature. I've been adding this. So
16:34 this is new to healthKERI. My argument
16:36 is that we need to get to network
16:38 standards where it is not just
16:40 structured coded and scaled, which is
16:42 important for these other things. It
16:44 needs to be governed and that governance
16:46 piece is the piece that healthcare is
16:48 still I think currently grappling with.
16:51 So let's talk about a few of the
16:54 ways that this lays out in terms of
16:57 manual effort. So if you have a
17:01 foundational interoperability model,
17:02 literally it's just the pipe; everything
17:04 else is on you. Congratulations. You
17:06 have data. Have fun
17:08 normalizing all of that. Maybe you'll
17:10 pass it into Mirth or Iguana or
17:11 somebody else .., they can do the job
17:13 for you. This goes all the way up to the
17:15 question we should be asking, which is:
17:17 "When data is flowing through the system
17:19 is the standard built in such a way that
17:22 we can answer the question affirmatively,
17:24 will this improve patient care?" and
17:26 that's what we're trying to get to
17:28 with interoperability standards. So
17:30 let's talk about what some of these
17:32 standards are. So back in the 80s
17:35 which I was not around for ADTs
17:38 came out. ADTs is admissions discharges
17:41 and transfers, basically this was the
17:43 building block of healthcare's
17:44 interoperability. Can I see from a
17:47 hospital perspective is the patient in
17:49 my hospital, is he out of the hospital or
17:52 has she been transferred to another
17:54 hospital? And that was the foundational
17:56 effort that came again back in the 80s.
17:58 We moved on to between 87 to 95 there
18:02 was CDAs that were added in and the
18:05 one that I actually want to talk about
18:06 is HL7v2. HL7v2 is the precursor to
18:10 FHIR. So this is probably and correct me
18:12 if I'm wrong here, Mark, the most
18:15 adopted standard in healthcare today.
18:17 Most data flows on HL7v2.
18:22 So it's HL7v2 dot
18:25 question mark…
18:26 – It's standard. – Yeah, standard adjacent.
18:30 And so that was back in 95 that this
18:32 came out. You can see that
18:33 healthcare is… Yeah, go ahead.
18:36 – What's the differentiation there? What's
18:37 what's the customization? Is it the data
18:39 model that's consistent? Is it just
18:41 what's the proprietary
18:44 niches?
18:44 – It's extensions.
18:47 It's wide open extensions. They
18:48 call them Z segments. They just let you
18:51 let you put whatever you want in there
18:52 and define them for your local use. So
18:55 it's a local extension and they're
18:56 allowed and a lot of
18:59 them are used in fact even later
19:01 versions of HL7v2 that actually support
19:03 those capabilities later. People
19:07 didn't change their Z segments because
19:08 they were working and they were mostly
19:10 were communicating inside the enterprise
19:13 so communicating from the system that
19:17 manages the
19:19 encounters with the systems that are
19:21 [inaudible] so from the [inaudible] system the lab system
19:24 back. So that's why they could be
19:27 that's why they couldn't be not standard
19:29 because they were for use in a
19:32 [inaudible]
19:32 – And the other thing is the v2 and CDA
19:37 standards
19:38 were effectively proprietary. So in
19:41 those days you have to pay to get access
19:43 to those just like you do today with
19:45 X12. So if you want to do a financial
19:48 transaction in healthcare it has to go via
19:51 RX12 because cost you like 1,500
19:56 bucks a year just to be able to see that standard.
19:59 – [inaudible]
20:02 – Yeah. Right here.
20:06 It's all in here. And
20:08 obviously not comprehensive. We're just
20:09 trying to do a high level here. So
20:12 then back in 2011… you'll be happy
20:14 to note I was here for this one. I was
20:15 here for this one. The FHIR
20:18 standard was put out in 2011. Since
20:22 then there's been a lot of work in the
20:24 FHIR space. I think at this point. So
20:26 when I got into healthcare we were
20:29 just talking about interoperability
20:31 standards and there was a lot of
20:33 discussion around, is FHIR the go forward,
20:35 are we going to do this? Are we not?
20:37 Because a lot of people were happy with
20:39 HL7v2 in the sense that they're lazy and
20:42 didn't see the need to change and
20:43 we're still faxing things anyway. So why
20:45 do we care about a data standard? I
20:47 would say that in the last 5 to 10
20:50 years that has really flipped and the
20:52 industry has started to say yes FHIR is
20:54 the go forward standard. So even if
20:55 people aren't using FHIR today for all
20:57 of their connections everybody has
20:59 kind of accepted the fact that at some
21:01 point FHIR is going to be coming into
21:04 their world and again we'll talk more
21:05 about what FHIR is in a second. So I
21:08 want to go up one level and talk about
21:11 kind of the network level of
21:13 interoperability standards. So for
21:15 things like TEFCA, which is the trusted
21:18 exchange framework and common agreement,
21:20 This is a federally backed program to
21:22 do nationwide interoperability.
21:25 They are actually using FHIR in TEFCA.
21:27 So this isn't a morphing of this
21:30 standard here. Well, sorry, they talk a
21:33 big game about using FHIR. They
21:36 anticipate that in the future they will
21:37 use it.
21:41 CDA or HL7v2 .
21:45 But they have acknowledged that this is
21:47 the direction they're going to go (FHIR).
21:49 So this isn't a new standard as much
21:52 as it is a new set of guidelines.
21:56 So that common agreement is the
21:59 governance framework that they're trying
22:01 to instantiate on top of existing
22:04 frameworks. So the other one that I
22:06 would mention here just kind of in
22:07 passing is CMS aligned networks.
22:10 That's one that will become I think more
22:11 relevant as we [indaudible]
22:15 and FHIR in the ecosystem
22:18 [inaudible]
22:23 …the first being we don't actually
22:26 have full adoption of FHIR up here yet
22:28 and beyond that these ecosystems up
22:32 here do not have, I would argue, an
22:36 effective mechanism for governance and
22:38 trust on the frameworks. So and
22:41 I think I've got a couple things. We
22:43 we'll come to it later on why I say
22:45 that. But let's switch just very
22:47 quickly to talk about FHIR. So FHIR
22:50 is fast
22:52 healthcare interoperability resources.
22:54 It's a lot of things. So, it's an
22:57 acronym, but it's also the data
22:59 structure. It's restful APIs, which is
23:01 just modern API connectivity. It's a
23:04 set of tool sets. So, it's
23:06 developers kits. it's,
23:08 validation implementation guides.
23:10 HL7 actually does maintain public FHIR
23:13 test servers. So, if people are looking
23:14 to get into FHIR, they've made it really
23:16 easy because you can go in and play
23:18 within their ecosystem. And then
23:20 there also is a community that's
23:22 I would say relatively strong and
23:24 vibrant, growing every day in terms of
23:26 people in the ecosystem doing FHIR.
23:29 like I don't think I've talked to
23:31 another healthcare startup that isn't
23:34 starting with FHIR in terms of the
23:35 connectivity that they're trying to
23:37 drive into the ecosystem. The other
23:39 thing that I think I should point out
23:41 here is that the data structure piece is
23:44 actually incredibly valuable. So, a CCDA
23:47 HL7v2, they didn't really allow for
23:50 discrete elements of the data to be
23:51 called out, which meant that often
23:54 times when you're transacting a data
23:56 record, what you're getting is a
23:58 stack of information and then you'd have
24:00 to go through and kind of parse through
24:01 that to get to value. Yeah.
24:03 – How does that relate with various
24:05 EHR type?
24:08 – What do you mean?
24:10 – I think electronic health or portable
24:11 health records. I'm not sure if
24:14 – Yeah. So, with EHRs it's
24:18 going to depend on EHR, Obviously,
24:21 most of them are transacting data on
24:24 HL7v2.
24:24 – But does this say you have to
24:27 use a particular type or aren't there
24:29 multiple EHRs?
24:31 – There's lots of EHRs out there. Yeah, the ONC
24:37 basically has really got the role of
24:40 regulating the
24:43 healthcare tech industry. – ONC being the
24:46 office of the national coordinator for
24:48 health.
24:50 – And so they, a number of years ago,
24:53 defined
24:55 FHIR
24:56 set of resources known as US core.
25:00 And basically had certifications
25:05 so that if you were a certified health
25:07 information technology platform you
25:09 would have to certify against that and
25:11 that required you basically to have a
25:14 population health API based on FHIR,
25:17 patient access API based on FHIR, and
25:20 using those calls that was on an
25:22 older version of FHIR and what's
25:24 happened over the last year is
25:28 they updated to the same version the
25:30 players are actually using.
25:32 Yeah, it is a standard that
25:36 lives underneath the EHR itself right
25:38 because they're trying to get
25:39 data in and out. So back to
25:42 the data structure the model here, these
25:44 data descriptions, and it's completely
25:46 gone now, which is great. Is
25:48 actually really important in terms of an
25:50 upgrade here. One of the things that
25:51 FHIR allows you to do that
25:54 previous interoperability standards
25:56 didn't, is to be able to call out
25:58 discrete data elements from the FHIR
25:59 record. So, when you're talking about a
26:01 multi-hundres-page patient record, which I'm
26:03 sure mine is with all the things I've
26:04 gone through the ability to go in
26:06 and say, I just want these blood tests,
26:08 I just want this, you know, from this
26:10 date to that date. To be able to parse a
26:12 record at scale like that. That's
26:15 incredibly valuable. And I think,
26:17 all the rest of these things are
26:19 essential. They're helpful, but really
26:21 it's that data structure and the ability
26:22 to make the data actually useful in
26:24 clinical practice is what's driven FHIR.
26:27 – [inaudible] the rest of the API
26:28 as well because traditionally what
26:30 would happen is if you wanted data, you
26:32 would make a request say basically send
26:34 me a document.
26:35 Yeah.
26:36 Right. So, they're going to put that
26:38 data into the document. I've been in
26:39 meetings where there's been discussions of how
26:42 much data should we put in a document if
26:44 we're going to have a standard which is
26:46 a little bizarre,
26:48 whereas with the restful API and those
26:50 data structures you can, if you've got
26:53 the permissions you can go in and say
26:55 give me just the A1C readings out of the
26:58 observation resource.
27:00 – Yeah just give me the discrete
27:02 elements from the data that I actually
27:04 want. So this is the objectives of
27:08 FHIR that's that's stated by HL7 who's
27:10 standards body that forwards FHIR.
27:13 They wanted to be built for
27:14 implementers. So this isn't something
27:16 that was thought up by
27:19 people like me who would definitely get
27:21 it wrong but actually by implementers that
27:23 know what needs to go into a standard.
27:24 They regularly do connectathons
27:27 because it doesn't do any good to
27:29 have an implementer standard if you
27:31 can't teach people how to get this done.
27:33 I think that this is another piece
27:35 that's very valuable is that they
27:37 operate on an 80 / 20 rule. So they're
27:39 going to anticipate that they can get
27:41 about 80% of all the use cases enacted
27:43 into the standard. But that XKCD
27:47 Comic I had up earlier is very
27:49 true which is if your standard
27:53 is rigid not flexible you end up
27:55 proliferating standards. The other
27:57 things that are I think important is
27:59 it's open source. And the
28:01 adoption as far as everything that FHIR
28:03 tries to do is to make it incredibly
28:05 easy. So that's kind of the FHIR
28:08 in a nutshell. Let's talk about CMS-0057.
28:10 So this is the latest version of
28:13 that synergistic loop that I talked
28:16 about earlier, which is CMS doesn't want
28:18 to set standards. They want the industry
28:20 to set those standards through somebody
28:21 like HL7 and then they come together and
28:24 start to put them into mandates. CMS-
28:26 0057 basically says that by January 1,
28:28 2027, every payer that receives Medicare
28:31 and Medicaid dollars has to stand up an
28:34 API for these four use cases, which is
28:37 payer-to-payer exchange, patient
28:40 access, payer to provider exchange,
28:43 and then a streamlined prior
28:44 authorization process. Is anybody not
28:47 familiar with what prior authorization
28:49 is? We've we've thrown that around
28:50 pretty loosely, but if you don't know,
28:52 okay, great. I will say that when I
28:54 went to go get the proton therapy, it
28:57 took 3 months to get the prior
28:59 authorization approved on that. So
29:02 if we can streamline that, I would be
29:04 very, very pleased. So,
29:07 let's talk about how the connections
29:08 work right now. Mark mentioned a couple
29:10 of these things earlier, but it's
29:11 typically in terms of trust on the
29:13 connection, it's certificates, it's
29:15 tokens, it's very manual. And often
29:18 the org identity is assumed not
29:21 proven. So they have some evidence of
29:23 who you are, but it's not cryptographic
29:24 evidence. It's not something that would
29:26 necessarily hold up in court. And so
29:29 with this idea that healthcare is the
29:32 most targeted and that most of those
29:34 attacks are coming through third
29:35 parties this is a disaster waiting
29:38 to happen. So CMS has come in and said
29:40 you need to stand up these four types of
29:42 APIs. In reality, what that means is
29:44 you're going to have thousands, if not
29:45 hundreds of thousands of new connections
29:47 coming into the ecosystem. And given
29:50 that we are already the most targeted,
29:52 we're just going to make it worse for
29:54 ourselves because again 3 / 4s of
29:56 all the attacks are already coming
29:58 through an outside connection that
29:59 you have. Let's talk about
30:03 what FHIR has done and then we can talk
30:06 about what we think still needs to be
30:08 done. Semantic data: super
30:11 important that you're all speaking the
30:12 same language on your data transactions.
30:14 Real time versus asynchronous.
30:17 You want something that's lighter. I
30:19 think they've done a great job with that.
30:20 The developer access and the
30:22 discrete element parsing. This is again,
30:23 I think the biggest one that FHIR has
30:25 solved. You may disagree with me,
30:27 Mark. There might be things more
30:28 important, but I think that's pretty
30:29 foundational to the value that FHIR
30:32 drives. So really FHIR fixes today
30:36 the how. They do a really good job of
30:38 how are we going to get data moving back
30:41 and forth. (Sorry, that's a med-
30:43 alarm.) But what it doesn't solve is the
30:46 who. So right now in the industry,
30:49 Mitch, what was the last count on Epic
30:51 lawsuits? Are we up to 15 yet?
30:54 – It's climbing.
30:55 – Yeah. Okay. So, we're somewhere
30:57 between 13 and 15 lawsuits. And that is
30:59 both Epic suing people and Epic being
31:01 sued by people.
31:02 – Epic's the largest EHR [inaudible]
31:07 Yeah. They're the behemoth [the biggest, red.] in the
31:09 industry. What
31:11 happened, and I'll walk you through
31:12 this because I actually think it's
31:14 really interesting, is a small startup
31:16 called Particle Health sued Epic and
31:18 basically said, "You're blocking
31:19 information. We have a right to clinical
31:22 information through Epic's EMR. We want
31:23 to be able to treat patients and you're
31:25 not giving us that info." And so they
31:27 kicked off this lawsuit that kind of
31:28 rocked the industry. The response to
31:31 this was, yes, obviously Epic's taking
31:34 this with their lawyers in court and
31:35 they're having discreet arguments there.
31:37 But in the court of public opinion, Epic
31:40 decided to go out and sue one of the
31:42 on-ramps to the networks. So, Particle
31:45 said, "Hey, you have to give us the
31:46 data." And in the court of public
31:48 opinion, Epic said, "We can't give you
31:50 the data. The networks aren't
31:51 trustworthy." And so they went and sued
31:52 Health Gorilla, which is one of these
31:54 on-ramps into TEFCA, that national
31:56 exchange framework, and basically
31:57 alleged that they were letting bad
31:59 actors onto the network without proper
32:01 vetting. And so Epic now can kind of
32:04 hold their virtue in the court of
32:07 public opinion by saying, "No,
32:09 we're not info blocking. We're doing
32:11 what's right by patients because if we
32:12 were to put patients data out on these
32:14 networks, it would be compromised
32:15 because the networks can't be trusted."
32:17 And then of course because lawyers
32:19 get excited, there has been a number of
32:21 other lawsuits that have all started to
32:22 spawn out of this same thing. So you've
32:24 got class action lawsuits that are go
32:26 now going after Epic because this is a
32:28 big issue. States are suing
32:31 Epic around this same thing. And at
32:33 the core of all of these litigious
32:36 contentions is: well can we trust the
32:39 other side of the ecosystem? And so
32:42 coming all the way back to the lawsuit
32:44 that kicked this off, if we could
32:48 trust the network, then we could
32:50 actually hold Epic to account and say,
32:52 "Yeah, you're info blocking. You're just
32:54 not sharing the data because you don't
32:56 want to because data is the new oil and
32:57 because you see a lot of value in owning
32:59 all of the patient records." But
33:02 without that trust, we have to get into
33:04 this incredible and increasing web of
33:07 litigation trying to solve that problem
33:09 at scale. I said this earlier today,
33:12 I'll say it again. The question used to
33:14 be, can we connect? The answer is yes.
33:17 Now, the question is, can we trust those
33:19 connections? So this is a slide I
33:22 also stole from Mark. I did
33:25 beautify it a bit. So but if we are
33:28 going to get to a place where we can say
33:31 "yes" to the question of trust and
33:33 connections we really need a couple of
33:35 things. We need first to have a
33:39 organizational binding to the
33:41 individuals in that organization, be they
33:43 people or entities. You have to be
33:46 able to delegate and prove delegated
33:48 access and authority to those
33:49 individuals. And then you have to be
33:51 able to particularly in healthcare scope
33:54 down their access to just the minimum
33:56 needed the purpose of use for that
33:58 particular connection. If you can do all
34:00 of those things, you can bind them
34:01 together cryptographically then you can
34:04 get to: yes we can trust the connections.
34:08 Now how do we get to that trusted
34:10 onboarding the connections
34:12 themselves? It's these pillars down
34:13 here. You need something that's
34:14 verifiable, auditable, automated, secure
34:17 and open. And if you think of a
34:20 there may be an open source open
34:21 standard protocol that was invented
34:23 by someone in this room [Sam Smith, red.] may actually fit
34:25 the bill for this. In fact this
34:28 may be me right now. If you understand
34:31 KERI I think you know where this
34:32 starts to go. We want to build and we
34:36 talked about this earlier today. A
34:38 trust equity framework or connectedness
34:40 at trust. This is a diagram I
34:44 entirely came up with myself. Phil gave
34:47 no commentary on this at all. He didn't
34:50 No, I'm just kidding. This is Phil's
34:52 diagram for really how we see KERI and
34:55 in particular the vLEI participating in
34:57 an ecosystem where we can start to
34:59 answer that question of can we trust the
35:01 connection. So it starts with the
35:03 trust anchors. Yeah, go ahead. Okay,
35:05 I'll go super quick. It starts with
35:07 the trust anchors which for the vLEI is
35:09 GLEIF. We see DirectTrust playing a
35:12 huge role in this in terms of
35:14 translation of global standards into
35:17 value for individual ecosystems like
35:20 healthcare. And then obviously SEDI
35:22 because this is all built on the same
35:23 stack plays very nicely with the rest of
35:25 this. So the way that the vLEI stack
35:27 works is they are the Root of Trust.
35:30 They create what are called QVIs that
35:32 issue a credential to organizations.
35:34 That credential is called the vLEI. Once
35:36 you have your vLEI, you can start to issue
35:38 credentials off of that vLEI to
35:41 individuals or entities within the
35:43 organization. And again, all of this
35:45 is cryptographically attestable all the
35:48 way back to the Root of Trust. So, I now
35:50 know who you are, who you work for.
35:53 In particular, I know what you're
35:55 doing, which is where DirectTrust comes
35:57 in. And it's the right things to be
35:59 doing. And that you are chained back to
36:02 GLEIF as a Root of Trust. So, super
36:04 important. the end result is ,we can
36:08 move from an ecosystem where connections
36:12 take you know weeks to a day or two, and
36:15 like you said earlier today Mark, the
36:17 actual technical lift on this takes
36:18 minutes, it's going to be a day or two to
36:21 get the emails you know coordinated
36:23 right that's all the lift that has
36:25 to happen on these and we drop those
36:27 costs down by 75% or greater per
36:32 connection the result is of course that
36:34 If we take away the attacker's favorite
36:37 toy in this industry, they will move on
36:39 to other industries. They will find
36:41 another place to go and do compromises
36:43 because the third party attack that is
36:45 so common and prevalent today, no longer
36:48 an issue. What do we see? We
36:52 see a future where the question of can
36:55 we trust this connection is answered by
36:58 KERI through the vLEI. So as you
37:00 incorporate the vLEI into the FHIR
37:03 standard, as you start to build network
37:05 interoperability standards that require
37:08 organizational ID, then you get to a
37:10 place where you can start to say "Yes,
37:12 the connection is trusted." And more than
37:14 that, you can start to automate
37:17 connectivity across multiple
37:18 organizations. The initiative that
37:20 we've kicked off for this is called the
37:22 VITAL initiative. It's backed by
37:24 CARIN Aliance, DirectTrust and GLEIF.
37:26 This is a group that's come
37:28 together and said yes, we see this as a
37:29 problem. We want to get this solved.
37:31 So I'll stop there. What questions do
37:34 you have for me?
37:41 – I'm writing up and I'm making FHIR end
37:43 points to Epic. So do you foresee this
37:46 protocol or this trust layer being the
37:50 the intermediary in that FHIR
37:53 call or is it a…
37:56 I'm trying to understand at what level
37:57 do you actually implement this?
38:00 – Yeah. So we would we would see it as
38:02 embedded within the FHIR API, the call
38:06 itself. So every time you reach out and
38:08 call basically you're doing a credential
38:09 presentation. You're saying this is my
38:10 vLEI and any of the relevant engagement
38:13 context raw credentials underneath that,
38:15 that say, I am Etna. I'm the sysadmin
38:19 there and I have a purpose of use for
38:22 payer-to-payer connectivity. And all of
38:23 that is cryptographically handed to you
38:25 as you establish the connection and then
38:27 the data flows through a typical FHIR
38:29 API.
38:30 – What about from the clinical parts
38:32 [inaudible]
38:35 – So the next step for us really… so
38:38 this is the simplest version, right ,we're
38:42 trying to get to just, can we prove to
38:44 the payers that they can connect here
38:46 the next step, I think you're absolutely
38:47 correct, is to say can we get this to the
38:49 providers right and that becomes a much
38:51 more complicated. – [inaudible] individual
38:54 identity but you end up having to…
38:57 a provider can work at three
38:59 different places so what's the context
39:01 in which they're operating, so that's
39:03 where the vLEI, with a purpose of use, tied
39:06 to a digital identity would be able to ..,
39:09 say, because you're working for Beth
39:12 Israel as a provider, that yes you
39:16 can request data about this patient
39:18 you're treating.
39:20 - Yeah and there's going to be, I
39:22 anticipate there will be a large
39:25 fruitful discussion in the future
39:27 around how we do credentialing for
39:30 providers using things like this.
39:33 Right now there's a very
39:36 very expensive rent seeking happening
39:37 which is the American Medical
39:39 Association gets $300 million a year
39:41 just issuing credentials to providers
39:44 to provide care. And like we heard
39:46 earlier today oftentimes that can take a
39:49 couple of weeks to get things done. So,
39:52 okay. And we are at time. So, thank you
39:55 [Applaus]