0:00 Scott Stuewe Mark Scrimshire Jared Jeffery ｜ Provenanting Patient's Medical Records ｜ KERI Conf 2026
0:03 Yeah, Mark, do you want to start with
0:04 your intro and then Scott and then all…
0:06 – Yeah, we can do that. So, we're
0:08 going to be talking about KERI and vLEIs
0:11 and so forth. So, let's see if we can
0:13 bring that up. So, I'll kick off. I
0:15 apparently you guys were talking
0:17 yesterday, so people may know you. Yes.
0:22 I'm new. First time here. It's
0:24 been a while since I've been in Utah. My
0:27 name is Mark Scrimshire. I'm chief
0:29 interoperability officer at ONYX.
0:32 And we focus really on
0:34 interoperability largely in the payer
0:36 market for
0:38 I suppose a bit of background about me.
0:41 I was actually
0:43 invited to go into CMS back in
0:46 2015
0:48 To build Blue Button 2.0, which is an
0:52 API for 53 now 60 million Medicare
0:56 beneficiaries to be able to share their
0:57 data
0:59 with the apps of their choice.
1:01 That led to me now being retained by HL7
1:04 where I've written some of the other
1:05 implementation guides that CMS points to
1:08 in their regulations. So, I'm very much
1:11 focused around how do we take secure
1:14 APIs and operationalize them.
1:17 So, that's really the focus and that
1:19 is how it's drawn me to
1:22 KERI and the way that we can
1:25 potentially solve that. So, gentlemen.
1:28 Yeah, so let me go next. So, my name is
1:30 Scott Stuewe. We did talk a little bit
1:31 yesterday. I'm the president and CEO of
1:33 DirectTrust and we're a nonprofit trade
1:35 association that supports trust in the
1:38 healthcare ecosystem broadly and
1:40 actually increasingly we're
1:42 describing ourselves as somebody who
1:44 cares about trust
1:46 focusing first on healthcare. But so,
1:48 with the understanding
1:50 that healthcare is adjacent to virtually
1:52 every other sector on the planet.
1:54 And in particular in this country
1:55 healthcare and financial services are,
1:57 you know, deeply related. My
1:59 background is mostly in the healthcare
2:01 IT space. I grew up working in the
2:04 healthcare IT, the electronic
2:06 health record business. Watched that
2:08 business kind of grow and but
2:10 I've also been involved in
2:12 interoperability and identity kind of
2:14 from the very beginning of my career.
2:16 Worked as what they used to call an
2:18 interface guy. You remember what that's
2:20 like. So, doing
2:22 business-to-business interfaces before
2:24 that there really was a
2:25 thing called interoperability. So,
2:28 I've been doing this…
2:29 … started that life in '93. And then in
2:33 the late part of my life in the EHR
2:35 business, I actually worked on trying to
2:38 get healthcare information exchange to
2:39 work as well. So, we have that
2:41 commonality. I'm more of the
2:43 marketect. I think arguably he's more
2:46 of the architect. So, Yep. – And I'm just
2:48 the marketer, right? That's the… So, my
2:51 name is Jared Jeffery. I'm CEO and
2:53 founder of healthKERI. As the name
2:55 suggests, yes, we are all in on MDL.
2:58 That's what we do pretty much every day.
3:00 No, we…
3:02 [laughter]
3:03 We have
3:04 seen the light and have decided to
3:07 roll this innovation that Sam
3:09 kicked off into healthcare. This
3:12 really started for me about 15 years
3:14 ago. I had a job at a law office. My
3:17 role was to try and get paper
3:19 records, medical records from point A to
3:21 point B. And felt like I was going
3:23 insane because I had a supercomputer in
3:25 my pocket, but we couldn't get data
3:27 moving around inside of healthcare. So,
3:29 You know, 15 years ago I really
3:30 started to say, "Okay, somebody's got to
3:32 be able to solve this problem."
3:35 And that's led me up to here
3:36 and to starting this company. So,
3:38 Excellent.
3:41 So, we're going to cover a couple of
3:43 things
3:44 as we go through in really talking about
3:47 how we're really taking things
3:49 like vLEI and really applying them into
3:53 really
3:54 increasingly established
3:56 protocols and technologies that are
3:58 being used in healthcare because I think
4:00 if we go back to some of the things
4:02 that Sam was mentioning, we've really
4:04 got to try and make it easy for
4:08 for organizations to take that first
4:10 step and start to get comfortable with
4:13 the technology.
4:15 And so we're doing a… we'll talk about
4:17 it later of a particular… we're trying to
4:19 get a pilot off the ground that is very
4:21 very focused.
4:22 But once you see that, you can then see
4:24 how it could be applied in many
4:26 different
4:28 situations across healthcare. So
4:32 we'll go through all of that. We'll talk
4:33 about that for FAST security
4:36 explain a little bit about that because
4:38 that's driving how the healthcare
4:41 industry in the US is going to be
4:43 basically connecting to each other.
4:46 So
4:47 let's go and let's talk a little bit
4:48 about some of the problems you
4:51 – Yeah, sure. So the challenge we have
4:52 is that the healthcare ecosystem is
4:54 immense and diffuse and also has a
4:58 need for connectivity which is extreme.
5:00 So
5:01 a lot of this is already connected in a
5:03 way. A lot of this through
5:06 intermediaries.
5:07 So when you look at the numbers though
5:09 it's just this kind of staggering story
5:11 about the different kinds of
5:13 organizations we're talking about. They
5:15 all have
5:16 protected health information that is
5:19 fundamentally what is the sensitive
5:21 information that needs to be moved back
5:22 and forth. It needs to be encrypted all
5:24 the time. Needs to be protected. So
5:27 getting this stuff to actually work
5:30 is first of all a problem of scale.
5:32 It's a huge problem.
5:35 Now interestingly when you look at the
5:37 providers…
5:39 providers don't really have very good
5:41 identifiers. Payers don't have
5:43 identifiers at all. Like so
5:45 literally are unenumerated. When you
5:48 hear about…
5:50 there's a…
5:53 public database you know, federal
5:54 database called NPPES, which was
5:57 originally in its conception designed to
6:00 enumerate both payers and providers, but
6:02 in the end only ended up successfully
6:05 enumerating individual providers.
6:07 They don't do organizations very well,
6:10 and they don't do payers at all. So,
6:13 next slide. – Yeah, well, can I
6:14 just put a little bit of
6:16 note on that as well, which is that the
6:17 the onboarding process for the NPPES
6:20 system is really light.
6:23 You know, Ryan House, who was here
6:24 yesterday, didn't mention this in the
6:27 conference there. He has an NPI
6:29 number. He is not a clinician. He does
6:31 not provide care for anybody. But on
6:34 a lark he decided to go see if he could
6:35 get himself an NPI. So I asked him
6:38 what code he used. I think it was
6:39 probably therapy. So, if you need
6:41 a shoulder to cry on,
6:43 Ryan House [laughter] is
6:43 your man.
6:46 – Yeah, so I think the next slide, we
6:47 actually kind of get into the NPI
6:49 question, I think on the next.
6:51 We can't
6:53 answer this basic question. So, the
6:56 onboarding process for all these
6:58 organizations and the onboarding process
7:00 for our CMS is weak at this point.
7:02 They're looking to strengthen it. I
7:03 think they're talking about
7:04 strengthening it and including
7:07 you know, IAL2 identity assurance as a
7:09 part of the process. That's something
7:10 that they've said they're going to do.
7:12 Unfortunately, that's only the very
7:14 smallest part of the problem. So
7:16 the manual onboarding that these
7:18 organizations do with networks, for
7:21 example, is a tremendously onerous
7:24 process on the one hand, but also not
7:26 standardized. It's standardized in
7:28 policy in theory. So, in other words,
7:31 there are a couple of big national
7:32 networks, one called Carequality,
7:34 one called TEFCA. They're are very
7:37 similar. They are almost have the same
7:38 participants. One, you know, came
7:40 first and the other one kind of came
7:42 second as an effort of the government.
7:44 And so the 11 different organizations
7:47 that operate the TEFCA ecosystem, those
7:50 11 different, they call them QHINs, each
7:53 have to onboard the organizations to
7:55 those various places. And the way the
7:57 topology of this stuff works is that the
8:00 people who are connected by one QHIN
8:03 then are passed from the QHIN to another
8:05 QHIN and to their
8:08 participants and sub-participants. And
8:10 this weakness, these extra
8:13 hops, basically means that the people
8:15 who are receiving messages have no idea
8:17 who sent them the message cuz there's no
8:19 actual understanding of the
8:21 organization across that boundary. So,
8:24 there's also no universal organization
8:27 ID. So, particularly, the only thing we
8:28 really have that does
8:30 organizational vetting is the issuance
8:33 of a digital certificate, which is
8:34 something DirectTrust does at scale
8:36 today for a whole bunch of
8:38 organizations, but it's not really all
8:41 that useful to tell you about the
8:43 organization. It just tells you that
8:45 this person has control of this domain,
8:47 which is not all that useful,
8:49 particularly if patients are trying to
8:51 find where their doctor is, which is one
8:53 of the problems we're trying to solve.
8:55 Is if I've got a directory that has a,
8:58 you know, listing of all the places my I
8:59 might look, how can I tell which one is
9:02 where my doctor's stuff is? So, it's a
9:04 big problem.
9:06 There's also a big deadline. – I can maybe
9:08 talk a couple of things here. So,
9:11 you see digital identity, individual
9:13 identity there.
9:15 That doesn't solve the problem. My
9:17 sister's a doctor in the UK,
9:20 and you know, on Monday she would be
9:21 working for one organization, on Tuesday
9:23 for another. So, it's all about context.
9:27 So, you really need to be able to tie
9:29 that organizational identity and the
9:32 individual so that you understand what
9:35 context they're actually acting in.
9:37 Now, the other thing that we were
9:40 about to get to is CMS-0057. It Sorry,
9:43 it rolls off the tongue. We add the two
9:45 zeros, so it sounds a bit like James
9:47 Bond. But it isn't. But this is
9:50 really mobilizing the industry because
9:52 CMS a couple of years ago put out
9:55 regulation. And remember, CMS spends
9:58 what, about 1 and 1/2 trillion dollars a
10:00 year, which they give to
10:03 basically payers around the industry. So
10:06 they hold the purse strings. So they put
10:08 out regulations that basically say,
10:11 "You need to do this."
10:13 Right? And 0057
10:16 really does a couple of things. One,
10:18 it's expanding patient access. So if you
10:21 have a
10:24 plan with a Medicare Advantage
10:27 organization, a payer, you're allowed
10:30 to go and get your health data that they
10:32 hold. Now, what they're doing is they're
10:34 adding in prior authorizations to that.
10:37 The other big thing that everybody's
10:39 focusing on this rule is
10:42 providers are going to be able to submit
10:44 in a standard way a prior authorization
10:47 request and get an answer from the
10:49 payer.
10:50 That means you've got a secure API, and
10:52 you literally going to have tens of
10:53 thousands of provider organizations
10:56 having to talk to a thousand different
10:58 payers to get an answer.
11:01 Today it happens through provider
11:03 portals at the payer, through faxes,
11:06 through phone calls, all of these
11:08 things, no standard way of doing it.
11:10 What CMS has done is saying,
11:12 "This is an API standard to do
11:14 this." And so everybody's busy
11:17 automating that, and the deadline is the
11:20 1st of January, 2027. So we are about
11:25 7 months away.
11:28 – And I'll say one other thing here. If
11:29 if you're interested in FHIR, my session
11:32 later today talks through I think in
11:34 depth what FHIR is, how it works
11:36 at a very atypical or atechnical
11:39 level just to kind of put some
11:40 definitions in there.
11:41 – Yes, so a lot of the CMS series of 57
11:44 is really driving the adoption of FHIR
11:46 (fast healthcare interoperability
11:48 resource) specifications.
11:51 that drives a standard way of
11:53 expressing exactly what you want to do.
11:56 So here's a patient record, here's a
11:58 coverage record, here's an encounter
11:59 record, etc.
12:01 So the industry, particularly the
12:04 payers, are busy implementing this and
12:06 hopefully also the EMRs will as well.
12:10 So I think we can
12:11 go on.
12:13 – So this is sort of the
12:15 nature… So interestingly you know
12:18 United Health Group and actually most
12:20 payers are publicly traded companies. As
12:22 a consequence, they actually mostly have
12:25 LEIs, which is actually a useful thing.
12:27 But also just to understand the
12:29 challenge of the complexities here,
12:32 disambiguating an organizational
12:35 unit over here, the names of these
12:38 health insurance
12:40 organizations. So if there are 1,100
12:43 or so, some, you know, I don't
12:45 know, 10 or 12 of them are actually
12:47 under United Health Group. And so for
12:49 for you to find a health plan that's
12:53 associated with United Health Group, you
12:55 need to understand what the LEI can
12:57 provide for you, which is the who's your
12:59 daddy problem, right? So all of these
13:02 children health
13:04 insurance companies roll up through
13:06 United Health Group. Now not shown
13:09 on this slide is the complexity
13:11 underneath United Healthcare Services.
13:14 UHS actually operates
13:17 an incredibly complex network of
13:21 variable kinds of organizations, some of
13:23 which are actually provider
13:25 organizations.
13:27 One of their subunits is called Optum.
13:29 They're actually the largest owner of
13:32 providers in the country.
13:34 The largest
13:36 employer of providers in the country.
13:37 And they roll up through a company
13:39 that also has a bunch of health
13:41 insurance companies. So it becomes very
13:42 important for us to figure out
13:45 you know, I'm not just talking to UHG.
13:47 That would help me in no way at all if I
13:48 want to figure out what the bonafides of
13:50 this organization are and what frankly
13:53 they ought to be able to do on the
13:54 network. I need to know exactly what
13:57 organization I'm working with, but also
13:59 I probably need to know more about that.
14:02 I actually need to know
14:03 if they are bonafide for a given purpose
14:05 of use. You know, who says that they can…
14:09 And there's actually a huge
14:11 controversy right now on the care side
14:14 relative to whether or not you are
14:16 bonafide for treatment. The question of
14:18 whether or not a provider, just a
14:20 provider who's making a query
14:22 can do so on the basis of treatment. In
14:25 other words, that they're actually
14:26 treating a patient at this point.
14:28 They might work for a
14:30 law firm at this particular moment. They
14:32 actually are practicing provider and
14:34 they might work for all sorts of
14:36 other companies potentially. But they
14:38 they shouldn't be able to
14:41 operate in that context if they are
14:44 working in that particular setting. So
14:48 understanding where they are really
14:50 literally, but also
14:52 what is the purpose of use that they are…
14:55 that they are bonafide for.
14:59 – And Scott, I think…
15:00 – Yeah, I'll just really quickly sort of
15:01 what our role is and I think
15:03 we're going to move into a very much
15:04 more technical mode here after this, but
15:07 one other little thing I
15:08 can say is that
15:10 we play this role today. When I talk
15:12 about our community, we do not
15:14 ourselves issue anything.
15:17 We're a non-profit trade association.
15:19 Our members are the operators of a very
15:21 large healthcare network that actually
15:23 operates a PKI framework for that
15:26 purpose. So, and if you actually pull
15:28 back the covers on what DirectTrust
15:30 does, it looks oh so very much like what
15:34 the vLEI ecosystem looks like. So, it's
15:37 it's actually a very good map in terms
15:39 of how it would look cuz we're
15:41 fundamentally a
15:43 a governance engine. We're not a
15:45 we're not… you know, some people argue
15:48 we're not even a network, but we do
15:50 operate a network. This idea of our
15:52 accreditation process is what gives us
15:54 the ability to make sure everybody's
15:57 doing what's right associated with the
15:58 governance not just of our governance
16:00 expectations, but also for expectations
16:03 of external sources of truth like
16:05 853 or 863 as we were talking about
16:08 yesterday. If it's
16:10 identity assurance or if it's
16:13 taking care of your cybersecurity
16:15 bonafides, all of that stuff is what we
16:17 do today.
16:19 – And I think it's important to note Sam
16:20 said this morning that
16:22 the technology doesn't solve the problem
16:24 alone. And I think increasingly with
16:27 with Daniel's presentation earlier
16:29 with what we're talking about here, you
16:30 do have to go get the stakeholders from
16:33 the governance side involved
16:34 because you can have the best technology
16:36 in the world, but if you're not solving
16:38 the policy concerns you're not
16:40 going to get to actual results. – Yeah.
16:45 So, just touching on the scale of the
16:48 problem,
16:50 what we've seen if I go back to the
16:52 work I did with Blue Button, you would
16:54 have individual consumer apps coming and
16:57 trying to connect so that they could
17:00 then have a member use that and give
17:03 them permission to go and get the
17:05 data. Well, we built, at ONYX ,we built
17:08 an app
17:09 you know,
17:11 get my data, and we wanted to connect to
17:14 health plans across the country so that
17:17 you could go to this one place, you
17:18 could
17:19 find the health plan,
17:21 authorize sharing, pull the data.
17:24 We actually got 350 health plans
17:26 connected,
17:28 but it took us about 6 months.
17:30 Because everyone you had to go
17:32 individually to the health plan.
17:34 And this is where you've got like an
17:36 Aetna and they've got 47 plans.
17:39 But you rapidly get down that
17:43 curve where you're talking you run a
17:45 plan, you've got an API, I need to
17:47 connect to it.
17:48 And the process is a manual back and
17:50 forth. You answer the same
17:53 50 questions 150 different ways at every
17:56 different
17:59 plan.
18:00 And they'll finally decide that they're
18:02 going to give you access. Under the
18:04 regs, there's very little they can do to
18:06 refuse.
18:07 So it's a heavily manual process. So as
18:10 we were looking at this requirement to
18:12 do things like providers have access to
18:15 payers to pull data about the members
18:17 they're treating
18:18 or to be able to submit a prior
18:19 authorization
18:21 or for one payer to connect to another
18:24 payer because a member's moved and they
18:26 want their data,
18:28 you get this
18:30 math problem of the number of
18:32 connections you need to make. And we
18:34 need to…
18:35 we are not going to be able to
18:36 operationalize the APIs if we cannot
18:39 find a way of basically automating this.
18:42 And so this again comes back to this
18:44 core issue that particularly in health
18:47 care space,
18:48 we don't have a standard identifier. We
18:52 haven't got an easy way to identify. And
18:54 in fact, the plans tend to push away
18:57 from that. You know, talking about
19:00 having a national plan ID you know,
19:03 it's taken years and it's gotten
19:04 nowhere.
19:05 But we do know as you said Scott,
19:09 there's about 90% of the health plans
19:12 already have an LEI.
19:15 Right? So they're already
19:17 on the slope. We've got to just prod
19:19 them down there. Yeah, and I imagine
19:22 Karla can tell you it is a very
19:23 laborious process to get your LEI. I
19:25 think it's about $50 and what a day, 2
19:28 days if you've got all the
19:29 documentation.
19:30 – 15 minutes of actual real work. – Yeah,
19:32 yeah. Complete completely untenable for
19:34 the industry to adopt, right? Yeah.
19:38 – Can't be done.
19:39 – Yeah.
19:40 So let's go into what we're
19:42 really trying to
19:44 propose here. So the first thing is that
19:47 let's get people from an LEI to actually
19:50 having a digital credential for the
19:52 organization. Okay?
19:55 That brings a whole bunch of benefits
19:57 and Jared, feel free to chime in on
19:59 this.
20:00 But really what we're trying to do
20:02 I suppose I should take a little bit of
20:04 a diversion here and talk a little bit
20:06 about TEFCA from the payers'
20:08 perspective. Scott, you mentioned, you
20:10 know, there's a lot of the providers
20:13 have gone into TEFCA. They were in
20:15 CommonWell. They're probably still in
20:17 both.
20:19 The challenge is that to get into
20:21 TEFCA, you're then agreeing to do
20:24 Basically return information about
20:26 treatment in multiple different
20:29 formats. And so the payers are looking
20:31 at this and saying
20:33 I'm going to have to respond to a whole
20:34 boatload of queries. I can't really do
20:37 the same in the opposite direction. So
20:40 it's very imbalanced and a lot of this
20:42 stuff I don't want to be dealing with.
20:44 I'm worried about January 1st,
20:47 2027 and getting my FHIR APIs
20:50 operational.
20:51 I don't need to worry about having to do
20:53 IHE
20:56 formats and so forth. So
20:58 they've been resistant. So how do we get
21:01 them moving forward? And this is really
21:03 the first step. – Yeah, one other
21:05 reason why they're resistant is they
21:06 already have the data that they are
21:08 required to ask for in
21:10 this new model. They're like, they
21:12 already have this data. They've done
21:13 individual data sharing relationships
21:16 with all the electronic health record
21:17 companies. So, they don't see the value
21:19 proposition. So, it's like you can't
21:21 really get them interested in TEFCA. And
21:23 so, they want to try and do something
21:24 that is extra TEFCA. I like to call it
21:27 extraterritorial.
21:28 – Yeah, and really the
21:30 purpose there is that then they can
21:32 start to set the boundaries for the
21:34 connections. Right. So, CMS has said
21:36 this is what you got to get stood up.
21:37 It's got to be FHIR APIs. But, in terms
21:40 of the value for the payers, it really
21:43 comes down to and you know, Phil did
21:45 this demo yesterday and I'm sure he'll
21:47 talk a little bit more about it today.
21:48 It's that idea of can I take a
21:51 member's request and bring it through
21:54 from one payer to another payer to pull
21:55 the data back out through. And that's
21:57 what they're trying to get solved here
21:59 that doesn't get discussed as
22:00 deeply in TEFCA, but will be incredibly
22:03 relevant for the CMS-0057 connections
22:05 that are required by January.
22:08 – Yeah, so the key thing as
22:10 we're looking at using vLEI is really
22:13 being able to identify who is the
22:16 organization,
22:17 what's the purpose of use, and who's
22:20 actually been delegated the authority to
22:22 actually engage into those transactions,
22:25 right? And I'm basically coming this
22:28 at this from a very simple perspective.
22:30 And I've been in calls where
22:33 we start going down the digital
22:34 identity, the individual identity route.
22:37 And I'm saying, "No, no, no, no.
22:39 What we're actually trying to do here is
22:41 you've got this first step of actually
22:43 getting secure APIs connected. And how
22:47 do you have confidence that the
22:48 organization that is representing
22:51 is actually who they say they are and
22:53 the person that's trying to
22:55 do that setup is permitted to do it.
22:58 And there's multiple types of
22:59 transactions we're talking here, PriorAuth
23:01 payer to payer, provider access.
23:04 So, how can we
23:06 really start to bundle that together so
23:08 that you can answer that question and
23:10 ultimately be able to automate it?
23:14 So, this is where Jared and I are going
23:16 to try and make Phil at the back there
23:19 cringe as we try and do more of a
23:21 technical
23:22 explanations.
23:23 – Yeah, so let me let me just run through
23:25 this at a very high level and again
23:27 point you to some of the stuff that
23:28 Phil's going to be presenting later
23:29 today.
23:30 The way that we see this is that there's
23:32 with some minor augmentation at the
23:36 ECR level,
23:38 what GLEIF has done with the vLEI is
23:41 actually pretty much perfect for
23:44 this use case. It's purpose built
23:45 for what we're trying to do here, which
23:47 is if I don't understand the other
23:49 organization on the other side, then the
23:52 GLEIF ecosystem solves this problem. And
23:54 I would… so, just raise of hands, is
23:55 anybody in here not familiar with the
23:58 vLEI's architecture, how they lay these
23:59 things out?
24:01 Okay, then I think we can go very
24:03 quickly through this just to say that
24:05 all the way down at the bottom, the ECR
24:07 credential piece, that's where there's
24:09 going to be a lot of work done I think
24:11 with DirectTrust and others in the
24:12 industry to determine what is purpose of
24:14 use. And we're starting with payer-to-
24:16 payer, but the amount of ECRs that
24:20 you can issue within this ecosystem that
24:23 is specific to healthKERI is
24:24 incredibly valuable. So, everything that
24:26 we're doing, we really want to keep it
24:28 as stock standard vLEI as we can to
24:32 the point that if there are vLEI issuers
24:35 that are working on, you know,
24:36 issuance outside of the healthKERI
24:39 industry, we've really pushed to say the
24:42 vLEIs that operate there should be able
24:44 to operate here. Now, one of the
24:45 questions that we had was, okay, well
24:47 let's say you've got Bank of America and
24:49 they've got a valid vLEI. Just because
24:52 they have a valid vLEI, can they come
24:53 into the healthKERI ecosystem to one of
24:56 these payers? Can they go to CVS Aetna
24:58 and ask for your data because they're a
25:00 validated organization? The answer is no
25:02 because in that ECR credential space,
25:05 we'll have specific purposes of use that
25:07 we talked about already. – Yeah.
25:09 And I think that's key and
25:11 obviously by being more precise about
25:13 the purpose of use. So, whereas TEFCA is
25:15 basically you join the network and
25:17 anybody within the network we're seeing
25:20 now some of the legal challenges
25:22 saying are you really who you say you
25:24 are? And are you able to really
25:27 ask for that data?
25:30 By being very precise about the purpose
25:32 of use, it actually potentially
25:33 simplifies the policy framework that's
25:36 got to be around that.
25:38 You know, to the point of one of the
25:39 things I'm proposing is
25:42 in FHIR, we actually create
25:45 implementation guides that define
25:47 effectively a use case for the standard,
25:50 right? And so, each of those IGs has a
25:53 canonical
25:54 you know, basically URL that you can
25:56 reference. And that could be a mechanism
25:59 for actually defining the purpose of use
26:01 because what you're saying is
26:04 within an implementation guide, there is a
26:06 API for doing, for example, provider
26:10 access.
26:11 And so, there's actually a canonical I
26:13 know I wrote it.
26:15 You know, so
26:17 you could define that as something
26:19 unique that everybody then understands
26:21 this is the transaction type that I'm
26:23 engaging in.
26:25 So, we're really then leveraging
26:28 particularly down the ECR credentials to
26:30 define those purposes of use.
26:35 So, it really goes this way. We
26:38 get an organization gets their
26:41 organization credential.
26:44 We're looking at the fact that
26:46 there are going to be people within the
26:47 organization that will actually
26:50 do the transaction. So, in effect somebody,
26:53 for example, in an IT department or in a
26:55 compliance department is going to be
26:58 responsible for
27:00 making sure that these connections get
27:01 created. So, should they have been
27:05 delegated the authority to do that?
27:07 Another thing, with just the complexity
27:08 of healthcare, I mean, we
27:10 by the end of this year, we will
27:12 actually represent the interoperability
27:15 capability for more than half of the
27:17 Medicaid agencies in the country. Right?
27:21 So, we are operating on their behalf.
27:23 So, they would effectively, if they
27:25 brought into this, would have a vLEI for
27:27 the Medicaid agency,
27:29 and they would have a delegation of
27:31 authority to ONYX to be able to go and
27:34 set up these connections with whoever
27:36 they wanted to
27:38 set up.
27:40 – And similar to the Provenant use
27:41 case here, that is incredibly
27:43 essential, right? Because
27:45 while we will want ONYX and others to be
27:48 able to act on behalf of those Medicaid
27:50 organizations, we don't want them to be
27:53 confused in the pathway, right? You
27:54 still need to know whose throat you can
27:56 choke, essentially. – Who's it
27:58 going up to? Yeah, exactly.
28:00 So, we're building this effectively
28:02 this chain.
28:04 One of the things we're suggesting is
28:05 also
28:07 when you make a connection, what
28:10 typically happens today, we can get into
28:12 the technology of smart on FHIR, so it's
28:15 the issuing of a credential to allow
28:18 you to now effectively open up the API.
28:23 You normally… that's just a transaction
28:25 between the two parties. What we're
28:27 saying is, well, what happens
28:30 if the party that issues you those
28:32 credentials, so payer A goes and says,
28:34 "I want to connect to payer B for
28:37 payer-to-payer."
28:38 When they issue the relevant smart
28:40 on FHIR credentials so that the APIs
28:42 work, what if they give back a
28:44 credential that says, "Payer B has
28:47 approved payer A." And now you put that
28:49 into the package.
28:52 And now you go to the next payer, payer C.
28:55 And you can actually
28:56 present to say, "I'm already connected
28:58 somewhere else." You get to a point
29:00 where a payer is going to go,
29:02 "What the hell am I doing by trying to
29:04 do a manual verification of you when
29:07 you're already connected to another
29:09 bunch of folks in the
29:11 in the network?"
29:13 So that then starts to lead to
29:15 you can automate the process of
29:18 actually registering. So it goes from
29:20 being, you know, as
29:22 being conserved at $2,000 at a time to
29:27 hundreds of dollars a time.
29:29 Right? Just because you can now
29:31 automate. And as long as it we can use
29:33 the capability in the vLEI to
29:36 say, "Well, if there's a bad actor,
29:39 they can be revoked."
29:41 You can check that.
29:43 And therefore there's confidence in the
29:44 network. – Yeah, I really want to hit this
29:47 concept here really hard, which is
29:49 that
29:51 Mark has coined it as
29:53 connectedness is trust. And the way that
29:54 I put it is trust equity. The reality
29:57 is that for every organization, every
29:59 single connectivity point that they have
30:02 to operate today is both a
30:04 bottleneck and a cost center. You get
30:06 nothing from it other than the
30:08 connectivity. It is a bother, and once
30:09 you're done with it, you go to the next,
30:11 and you repeat that entire process. And
30:14 the vLEI allows you to start to do this
30:16 connectedness is trust. You start to
30:17 build a trust equity within your
30:19 ecosystem with those back filed
30:22 credentials that say, "Hey, we're
30:23 connected. We've done the check. We
30:25 trust who you are." And at a certain
30:26 point you get to
30:29 the opportunity to actually look at one
30:32 of the
30:33 biggest monoliths in healthcare, which
30:36 is the clearinghouses, and say, "We
30:38 don't actually need to rely on you to do
30:41 our network of connectivity anymore."
30:43 Because one of the problems that
30:44 healthcare has right now is you've got a
30:46 monopoly of a few very small parties
30:49 that are making
30:51 rent-seeking to the tune of billions of
30:53 dollars on facilitating all of this
30:56 exchange. And that sounds fine, I guess,
30:59 if it was just that problem. But one of
31:02 those clearing houses was Change
31:04 Healthcare that got blown up and it's
31:06 been 18 months now. And you go ask
31:09 some of the mom-and-pop clinics that had
31:10 to fold up shop because Change got
31:14 completely destroyed in an attack.
31:16 What we're talking about here is an
31:18 alternative. So if you go talk to an
31:19 Availity, if you go talk to one of these
31:21 large clearing houses, their answer is,
31:24 "This is a solved problem. Just be our
31:25 customer." And the contention that we
31:27 have for the entire industry is that
31:29 that's a really, really bad idea because
31:32 we don't want to centralize power into a
31:34 few different, you know,
31:36 private organizations as they move
31:37 forward. Now, I don't think the
31:39 clearing houses are going anywhere.
31:42 But what we do want to present is an
31:43 alternative where you can build your own
31:45 trust equity, you can build a network of
31:47 connections, and you can do it
31:49 automatically and at scale.
31:51 – And I wasn't here yesterday, but Ryan
31:53 was.
31:54 When we first presented this concept to
31:57 to Ryan, and he's been very much
31:59 promoting this,
32:00 the first words out of his mouth were,
32:03 "Is this open source?"
32:05 Because if you're going to get this
32:06 adopted across the industry, you don't
32:08 want those barriers to implementation.
32:11 That's been one of the real benefits of
32:13 HL7 and the FHIR protocol because that
32:16 was made open source. Anybody can go and
32:18 look at the specs, they can
32:20 take them, use them. There's no barrier,
32:22 whereas, you know, we're looking
32:24 at X12, and I have to go and buy a
32:27 license every year just to look at what
32:29 the spec says, right? So we don't want
32:32 that barrier. And so that's really
32:34 important. One of the features that
32:36 KERI brings is this open source
32:38 basis.
32:40 So, anyway, let's… So, let's talk about
32:43 this
32:45 What we're actually trying to do
32:46 here. There's a couple of initiatives
32:48 going on.
32:50 TEFCA, as Scott mentioned
32:53 is really this national network. It's
32:56 largely providers. Payers haven't leapt
32:58 into it yet.
33:02 There is an accelerator
33:05 FAST (FHIR at scale task force).
33:08 It started as part of the ONC
33:10 initiative, but now is an official
33:12 accelerator within HL7. And they're
33:15 really looking at how do we build the
33:17 infrastructure to enable all of this
33:20 interoperability.
33:22 So, it really is an underpinning of
33:24 of FHIR. Now,
33:26 they have an implementation guide. They
33:28 have multiple. FAST Security or FAST
33:31 Security for Scalable Registration,
33:33 Authentication, and Authorization.
33:36 Terrible.
33:38 But it's one of the longest.
33:41 That is actually in regulation saying
33:44 TEFCA is going to use that. And that
33:47 defines the mechanism
33:49 for basically acquiring those smart on
33:54 FHIR credentials to do a connection
33:57 between
33:58 two organizations.
34:00 So,
34:02 that is in there. Now, that
34:04 FAST Security
34:06 protocol implementation guide is
34:09 extensible.
34:11 And that's what we've really tried to
34:12 leverage here in saying, "Let's use the
34:16 vLEI
34:18 and all of the associated credentials
34:22 to make it easy for an organization to
34:25 move into this and have more confidence
34:27 in who they're connecting with."
34:30 I'm just saying, "One thing about this
34:32 that in its first iteration, this was
34:34 expected to be an X.509 certificate that
34:37 anchored these connections
34:40 for organizational security. So,
34:43 this idea of being able to have clients
34:45 dynamically register with servers and
34:48 get, you know, so that they can
34:49 eliminate that
34:51 access topic was initially imagined to
34:53 be a strictly an X.509 exercise.
34:58 – Yes, so
35:00 I suppose as an aside, I actually trace
35:03 the dynamic client registration protocol
35:06 in a OAuth 2.0
35:08 is really there in what we call SMART on
35:11 FHIR. Okay? So, it's the mechanism of
35:14 getting connected. So, you've got this
35:16 ability to get credentials. Dynamic
35:19 client registration has been there in
35:21 the OAuth spec for years.
35:23 And I can trace it back to in 2015, I
35:26 wrote a blog for the
35:29 Department of Health and Human
35:30 Services about
35:32 how could we actually
35:34 really leverage dynamic client
35:36 registration? Nobody used it because
35:39 they didn't trust who was coming in and
35:41 saying, "Just register my app."
35:44 And so,
35:45 I went to, I think, organizations like
35:48 DirectTrust and a couple of others and
35:49 says, "Is there a way that you could
35:51 tell me whether the person that's
35:53 actually submitting
35:55 can be trusted?" And so, that really
35:58 emerged into what is often referred to
36:00 as UDAP, but if you're talking to the
36:02 FAST folks, if I say UDAP, someone's
36:04 going to come out and punch me. It's
36:06 FAST security.
36:08 So,
36:10 what that's done is basically put an
36:11 X.509 certificate on top of dynamic
36:15 client registration so that you can say,
36:17 "I know who the organization is.
36:21 Here's all the information you would
36:22 normally have plugged into a developer
36:24 portal. Go register." Okay?
36:28 What we're proposing is using the
36:31 extensibility in fast security to
36:34 say, let's add an additional
36:37 cryptography check, which is for the
36:40 vLEI. So, that you can put the vLEI in
36:43 there and I know Phil's going to be
36:44 cringing at this because I'm not as
36:46 expert as he is.
36:49 You can
36:50 basically reference the vLEI, I'll
36:52 call it the vLEI package. So, all
36:55 of those bundles of credentials
36:58 and validate that they are legitimate.
37:02 Right?
37:03 And so,
37:04 what we're also… in there is
37:06 effectively setting a confidence factor.
37:10 Because if you are able… What's going to
37:13 happen is
37:14 we have this crazy scenario. You go
37:16 and talk to health plans and they
37:17 basically say,
37:19 we're trustworthy. It's all those others
37:21 out there that you cannot trust them,
37:23 you know, at all.
37:24 So, there's a problem with looking in
37:27 the mirror and really saying, you know,
37:30 am I trustworthy?
37:31 And so, we've got to we've got to try
37:33 and break that. So, what happens is they
37:36 are going to want to manually
37:38 validate anyone that even submits
37:41 this.
37:42 Right? So, what we're saying is let's
37:44 allow them to configure a confidence
37:46 factor. So, if you pass that threshold,
37:49 you could be automatically registered,
37:52 go into, get DCR runs, you get your
37:54 credentials, and away you go. – Yeah. And
37:57 I want to call out a couple of
37:59 things on this slide in particular
38:01 that I think
38:02 a staunch KERI advocate would
38:05 bristle at. One is the word OAuth
38:07 2.0 and the other's token grants. And
38:10 I know that there are people in the room
38:12 that look at that and go, well, why?
38:14 Why do that at all? Like if KERI is
38:16 what KERI claims to be and I think we
38:18 all believe that it can live up to its
38:20 promise,
38:21 why go backwards? And the reality here
38:24 is similar to I think what
38:26 Provenant is doing with Telco, you've
38:27 got to meet the market where they are.
38:29 You have to come to people and say,
38:31 you know, we're we're just adding a line
38:33 for that kind of cryptographic proof on
38:36 the ecosystem. And that's one of
38:38 the most common questions we get as we
38:40 start to go into the pilot on this
38:43 is payers saying, "Well, are you trying
38:44 to rip everything out and replace it?"
38:46 And the answer has to be right now,
38:48 today, no. No, we're making an
38:50 augmentation that is that is incredibly
38:52 minor to gain a ton of value. Now, if
38:55 you ask me, maybe not on stage, my
38:57 answer might change and I say, "Yes, we
38:58 want to rip all this out. We think we
39:00 can do it better." But we're going to
39:01 walk people into that path, right?
39:03 – Yeah. I mean, put this in context.
39:05 Back in July 2021,
39:08 All of these health plans that are
39:11 funded by CMS, so the Medicare
39:15 Advantage, Medicaid, CHIP plans, so
39:18 Children's Health Insurance Program, and
39:20 Medicare,
39:22 MCOs, all of these
39:25 have to follow these CMS regulations. So
39:28 there's about a thousand plans out
39:29 there.
39:30 They have invested in FHIR
39:33 interoperability with smart on FHIR, so
39:36 with OAuth 2.0. It's gotten through their
39:39 security
39:41 teams, which is
39:43 a major thing. I you know, I took
39:46 this concept through CMS. I had to
39:48 actually explain what OAuth 2.0 was.
39:52 Now that's accepted. So really what
39:55 we're doing is we're just adding an
39:57 additional check on top of that. So
39:59 you're building on top of something
40:00 they've already implemented, and we're
40:03 trying to make it really easy for them
40:05 to take this extra step and gain a lot
40:08 in return.
40:10 – And the ecosystem also includes all the
40:14 provider organizations,
40:15 and they're all served by electronic
40:17 health record companies and each of
40:18 those electronic health record companies
40:20 have also made that same investment. And
40:22 so, as a consequence, what you've got
40:24 is, you know, tens of thousands of
40:26 organizations that need to make changes
40:29 to their road map to include new
40:31 capabilities. This is a whole lot harder
40:34 than getting you know, Google and
40:36 Apple to do something, by the way.
40:41 So, this is really where we're at. It's
40:44 not a replacement, it's one additional
40:46 check
40:47 is really what we're trying to drive
40:49 home here.
40:51 So that we take the extensibility of FAST,
40:55 we leverage vLEIs in that, with all of the
40:58 subsidiary credentials and you've now
41:01 got the ability to have more confidence
41:03 in
41:04 the organization that's connecting
41:06 to you. You can also define specific
41:10 purposes of use.
41:11 So, we're talking about payer-to-payer.
41:14 It is required for 1127.
41:17 So a 1,000 health plans out there in
41:20 the US are going to have to
41:21 support payer-to-payer. So, when you
41:24 decide to up and move to the next plan,
41:26 as many of us do,
41:28 you can say, "Go get my data."
41:30 So, they're going to have to have these
41:32 connections. So,
41:34 rather than confuse things around the
41:35 fact that I've got tens of thousands of
41:37 providers
41:39 and that's complication,
41:41 say, "Let's get you comfortable with the
41:43 technology between people that you sort
41:46 of trust. They don't trust each other,
41:48 but they sort of do, right? Just a
41:51 little."
41:52 So,
41:53 we're trying to drive this as a specific
41:56 pilot, but if you talk to folks, I've
41:58 talked to folks in the Medicaid
42:00 agencies, I've talked to folks at the
42:02 various plans,
42:03 and their mind is immediately going,
42:06 "I may have to deal with a hundred
42:08 or a even up to a thousand health plans,
42:11 but I've got tens of thousands of
42:13 provider organizations"
42:16 And that's where their mind is already
42:18 going there. We just don't want to push
42:20 them there right now.
42:22 We'd rather them get comfortable and
42:24 then say, "But we can extend that."
42:26 Again, it's a it's a small step further.
42:29 But we bring them…
42:30 – Yeah, we're we're boiling the frog for
42:32 sure on this one.
42:33 –Yeah. Totally.
42:36 So,
42:37 the other thing that is happening is
42:40 there's actually… we get… what's the
42:43 time?
42:43 – Yeah, you got about 2 minutes. We may we
42:45 through.
42:46 – What we're actually getting to is we're
42:48 proposing this CMS aligned
42:50 network. So, that's a sort of mini
42:52 version of TEFCA
42:53 focused on doing specifically payer-to-
42:56 payer, so we can actually prove this
42:58 technology in the wild between a handful
43:01 of payers and then scale it
43:04 potentially really quickly.
43:06 So, that's really where we're
43:08 going with this. And so, if we had… we
43:11 were more or less at questions. So, I
43:13 don't know if you've got time for
43:14 questions. Yes.
43:16 – I love what you're doing. It's
43:19 really ambitious and it's obvious you
43:21 have deep industry knowledge. What I was
43:24 curious about was in particular the
43:27 notion of the canonical URL.
43:30 To me it seems like if
43:32 [inaudible] this city is associated with
43:36 the URL wouldn't that be an
43:38 anti-pattern? Wouldn't you rather have some
43:40 sort of canonnicity that was tied to
43:42 the content itself rather than a path to
43:44 the content?
43:45 – What we're really talking about is
43:46 what's a shorthand for
43:49 for example payer-to-payer?
43:51 Right. And so, just trying to take the
43:54 easy path… is there's hundreds of
43:56 organizations out there that are looking
43:58 at implementing payer-to-payer. And
44:01 they're going to have to connect.
44:03 They're all looking basically at the
44:04 same implementation guide.
44:07 And that… we have scopes in those
44:09 implementation guides and one of them is
44:12 you're going to give a permission to
44:15 do, for example, a member match. And
44:17 that… – And that permission
44:19 is embedded in the URL? – Well, that's…
44:23 you can effectively look up the
44:25 implementation guide by that URL, which
44:28 says here's the use case that we're
44:31 looking at. What we're saying is that
44:33 could be a short hand
44:36 to put into the purpose of use because
44:38 it's very specific. It's about this
44:40 particular use case that's been defined
44:42 as a standard. – It's interaction. – Yeah.
44:53 Anybody else?
44:56 – Okay. All right.
45:02 – And after that question, we got a
45:04 great announcement of Jared.
45:08 – Back in the
45:10 mid to late '70s, I was responsible for
45:13 a database called Sparks,
45:16 which has all of the admissions and
45:19 discharges from every hospital
45:21 experience in the state of New York.
45:24 And we traced the doctors and we traced
45:27 the organizations
45:29 without this then by their license
45:32 number.
45:33 And every state
45:36 in the United States,
45:39 there is a license number for doctors
45:42 and
45:45 clinics and hospitals issued by their
45:48 local…
45:49 their state health department.
45:51 Why aren't you using that?
45:55 – So let me describe
45:57 the challenge I think that that
45:58 represents. I think… So, the payers,
46:00 for example, frequently use EINs
46:03 as a part of what it is they use to
46:05 identify organizations across
46:07 the ecosystem. The challenge here is
46:09 that these organizations, first of all,
46:11 operate across state boundaries. So
46:14 the meanings of those things are
46:16 going to change as you move from state
46:17 to state. The other thing that is
46:19 challenging about any of the enumeration
46:21 models you have today is that
46:23 they don't actually represent hierarchy.
46:25 And this is actually a real problem for
46:27 any of them. The biggest issue I see
46:29 is with tType 2 NPI, which is what they
46:31 do for the healthcare
46:34 organizations. That is what CMS uses to
46:37 identify those organizations, but it's
46:39 not really the organization they're
46:40 identifying. It's a billing group, which
46:43 is not really helpful. So not to the
46:45 outside world. They don't understand
46:47 that construct. So getting something
46:49 that is universally understood as well
46:51 as disambiguating is the challenge. And
46:54 it doesn't work if it's a
46:55 state-issued item because these
46:58 organizations are multi-state entities
47:01 with you know, children who are in other
47:03 states. So it's a complexity that
47:05 is difficult to manage.
47:08 – All right. Thank you.
47:10 [applause]
47:14 So then before we go to the last plenary
47:17 speaker of today, I would want… – Yeah, so
47:20 so we've talked about this I think a
47:22 few different times today. I guess the
47:23 the announcement that I'd make for you
47:25 is and this is probably
47:27 deleterious to my own session. But I
47:30 would encourage you as you look at the
47:31 agenda for the rest of today and
47:32 tomorrow to bias your sessions towards
47:35 the KERI Foundation sessions and the
47:38 sessions that are being hosted by Ari
47:39 and Phil. The reason that I say that
47:42 is because we have pushed a massive
47:45 amount of code into the open source
47:47 as a result of wanting to kickstart
47:50 this ecosystem. So we're talking about
47:52 things like witnesses, watchers and
47:54 the Locksmith
47:55 wallet as well. So if you are looking at
47:58 the things that we're trying to do, if
47:59 you think you've got an ecosystem that is
48:01 very relevant here, I think we've
48:03 seen really common threads through Telco
48:05 and healthcare. If you have lines on
48:07 other industries, you want to start
48:08 doing these things we're
48:11 equipping you with all of the tools you
48:12 need to get started in that process. So,
48:14 again as much as I'd love to have a
48:16 full session later today, if there's a
48:18 competing session that's a KERI
48:20 Foundation or Ari or Phil I would
48:23 bias you towards those to go learn more
48:24 in depth about what exactly has been put
48:26 into the open source and what the value
48:28 is for you as an individual in the
48:30 KERI community. – Well, first, a very big
48:33 thank you for donating all that code
48:36 into open source. – Yeah, it
48:38 represents literal man years of time,
48:41 so.
48:41 [applause]
48:43 – Fantastic.