0:03

There's

0:03

a lot of innovation around healthcare,

0:06

but the way we move around medical data?

0:09

Let's face it, it's tedious,

0:11

it's manual, it's outdated. But

0:13

that's changing. The technology

0:15

at the center of that change, both in the US

0:18

and abroad, is the API, Application

0:21

Programming Interface. On the

0:23

outside, API integration seems

0:25

like an easy way to add new functionality

0:28

to older systems to allow different

0:30

services and platforms to talk to each other.

0:33

But the truth is a little more

0:35

complex. And that complexity

0:37

is causing many to come out in opposition

0:40

to healthcare IT modernization.

0:43

But why? Upgrades, more

0:45

agility, more features, those

0:47

are all good things, right?

0:54

This is Compiler, an original podcast

0:57

from Red Hat. I'm Brent Siminoe.

1:00

And I'm Angela Andrews. We

1:02

go beyond the buzzwords and jargon

1:05

and simplify tech topics. Today

1:08

we're taking a closer look at APIs.

1:11

This is one episode of

1:13

our series on legacy technology.

1:16

To listen from the beginning, start from the episode

1:19

in Defense of Legacy.

1:24

Let's see what producer Kim Hwang

1:27

has for us. The

1:29

way I think about it is that APIs

1:32

allow systems or applications

1:34

to talk to each other, to communicate amongst

1:36

themselves. That's

1:39

Jamie Beckland. He's the president

1:41

of Context, a company that specializes

1:43

in API

1:44

security. And

1:47

really, I think the elaboration of APIs has

1:49

created whole new categories of what software

1:52

can do, how it can work together, and how it can

1:55

sort of be componentized into microservices, and

1:57

also expanded to do much more

1:59

across.

1:59

functionality. APIs

2:02

allow different applications or services

2:05

to integrate and share information under

2:07

specific conditions without

2:09

the different teams involved having to know

2:11

how these services are implemented. They're

2:14

kind of like an agreement or a bridge between

2:17

different pieces of software. Most

2:19

people don't think of APIs as

2:21

legacy

2:21

software, but they have been around

2:24

for quite a while, around three decades.

2:27

At that time, they would pass information between

2:29

mainframes and be local to

2:31

the systems they were operating on.

2:33

Today, they are how most people

2:35

encounter older systems and older

2:38

programming languages. The interface

2:40

might be different and modern, but

2:43

it's still that older software underneath

2:45

the window dressing. And since

2:47

old systems are still pretty common, APIs

2:51

are common too.

2:53

People interact with APIs probably

2:55

most of the time without realizing it. Today,

2:58

API calls represent

3:00

over 75% of all internet traffic. It's

3:03

the majority of the internet, right? If you think about any

3:06

service or any system that you're

3:09

using through a browser, it's going

3:11

to be built on top of a bunch of APIs. Every

3:13

app that you have in your phone is built

3:16

up of a bunch of API components.

3:18

So really, almost every experience

3:21

that humans use on the internet

3:23

is built and managed through APIs.

3:26

Did they say 75% of all

3:28

internet traffic? Yes,

3:31

that's huge. I thought it was Beyonce,

3:34

but you're telling me it's API? Software

3:38

eats the world. APIs eat the internet,

3:40

I guess. Sheesh. Yes. So

3:43

I want to talk a little bit more about the proliferation

3:45

of APIs over time. This is something

3:48

that has been kind of like this

3:50

fast development, this rapid development. I mean, APIs

3:53

have been around for a while, but

3:55

the use

3:56

cases for them, specifically in

3:59

tech heavy areas.

3:59

is like social media and banking.

4:02

Think about whenever you

4:04

go on Facebook Marketplace to

4:06

buy something or whether you have

4:09

integrations on

4:11

your social media platforms to make a purchase

4:14

or to go to have it integrate

4:16

with a personal calendar

4:18

or another app that you use. Those are

4:20

all made possible with APIs. Okay,

4:23

so APIs are the goat. They're what's

4:25

out there. They're making the internet run. We

4:28

wouldn't be able to do a lot of

4:29

things without API.

4:32

Right. That's true.

4:34

And this is starting to become really

4:37

essential in different industries, like I

4:39

said before. But for this episode,

4:41

I want to focus just on healthcare,

4:43

how API integration

4:46

is being used to update the infrastructure in

4:48

healthcare systems, especially when it

4:50

comes to the matter of sharing patient information

4:53

between providers. How

4:56

healthcare IT is structured now, how it's

4:58

always been, right? And how most

5:00

of our listeners will understand it is that

5:02

when you go to your doctor and

5:05

say you want to go to your doctor and

5:07

then go to a specialist. Well,

5:09

that specialist has to have the same information

5:11

that your primary doctor has. How do they

5:13

get that information? Traditionally

5:15

speaking, they would get a fax,

5:18

right? You would have to fill out a form using

5:22

these devices called pen and paper.

5:25

And you would have to use a fax

5:27

machine to send this

5:30

information back and forth between

5:32

your primary doctor saying that this

5:34

other healthcare provider has

5:36

your consent to have the

5:39

same information and the same patient data as

5:41

your primary doctor in order for

5:44

them to treat you

5:44

or do their job.

5:47

I think it's funny that you said used to.

5:50

Hmm, that's true. They still

5:52

do. I'll

5:54

do you one better. Yeah, I very

5:56

recently hand carried paper.

6:00

medical records from one medical

6:03

office to another one and a CD

6:06

a CD wrong Images,

6:11

yeah. Oh wow. We've

6:13

come far but we all long

6:15

ago This is not long far.

6:18

Yeah,

6:18

and those situations are

6:20

extremely common, right? Yes,

6:23

but where are we going now? So in

6:25

the last few I would say the last decade

6:27

or so governments have kind of stepped in and

6:29

said Surprise surprise. This

6:32

is not very efficient and we want

6:34

health care You know to kind of reflect

6:36

the different changes that are happening in technology and

6:39

other You know other industries

6:41

like banking where you don't have

6:43

to carry a shoebox full of your

6:45

receipts from one bank to the other or

6:48

you know for context

6:51

But what what we have in place currently

6:53

and this is this is the product of many years

6:55

of work is something called Health

6:57

information exchanges and that's at the

7:00

state level. This is mostly pertaining to the United States

7:02

These kind of exist at the state or regional

7:05

level to handle the movement

7:07

of patient data back

7:08

and forth in the form of EHRs electronic

7:11

health records, so

7:13

Brent your your hand carrying the files.

7:15

This is kind of the equivalent

7:16

of that. Mmm. Okay, but

7:19

For a variety of reasons some will talk

7:21

about today It's still very difficult

7:23

to move patient data between

7:26

doctors hospitals and other health care providers

7:29

This is called interoperability.

7:31

So we'll use that

7:31

word moving forward

7:34

now the 21st century CARES Act a US

7:38

law that was passed 2016 requires

7:40

the ease of movement of these records

7:43

by the end of 2022. Well, it's

7:45

2023 while

7:47

we were recording this how

7:49

how is that? We're doing

7:53

Let's just say things are in flux.

7:56

Yeah. Okay. Well, I assume this is

7:58

like a very

8:00

It's a challenging and complicated technical

8:03

problem, in addition to sort of like

8:06

legal and privacy and all

8:08

that. There you

8:09

have it. And I want

8:11

to bring it back to APIs because

8:13

there's so many different parts of this,

8:16

like you say, but like why are APIs

8:18

such a huge component of this

8:20

type of modernization? I

8:23

spoke to Bobur Emrizakov.

8:25

He likes to be called Tiger. He's a developer advocate

8:27

who works with the Apache Foundation, and he's written

8:30

extensively about APIs.

8:32

APIs can be modelized

8:35

in such a way that different

8:37

people can work on one API, another

8:40

team can work on another API. That

8:42

gives more flexibility. Instead of

8:44

like completely replacing the old system,

8:47

as a developer, I can use APIs

8:50

to bridge this sort of

8:52

gap. And then I can step

8:54

by step move my,

8:57

the big legacy of systems

9:00

by migrating to the APIs, not immediately,

9:02

so

9:03

that I can allow new

9:05

models and talk to other new models

9:08

to the APIs easily.

9:09

That makes transition to modern technology

9:12

smoother, right?

9:14

You have people who are very,

9:17

very eager for this to be a new

9:19

normal, where people can just

9:21

move their electronic health records, their patient data

9:24

from one place to another very easily.

9:26

So it seems like it's the

9:28

cure-all, right? It does.

9:30

It's the cure-all for legacy systems

9:32

with the ability to change

9:34

the user interface, add new functionality

9:36

for the user themselves. It all seems

9:39

very ideal, picturesque.

9:42

I feel like there's a bug coming. You

9:44

know it is. I'm just waiting for it.

9:47

But it's more complicated than

9:49

that.

9:53

Yes. What we found is that there's a huge business imperative

9:56

to add APIs into

9:59

our existing services and applications. And

10:02

oftentimes that push

10:05

has caused teams to move really, really quickly.

10:07

And when you move fast, the

10:09

risk is that you break things.

10:11

We'll find out more about what Jamie is talking

10:13

about when we come back.

10:16

Ship Shadowman here with your daily

10:18

traffic report. We're seeing a major

10:20

jam at the intersection of dev and ops

10:22

due to a few new clouds rolling in. And

10:25

if you're on the way to vendor support, bad news,

10:27

they're rerouting all traffic until further

10:29

notice. But

10:31

there's a reliable alternate path through

10:33

Red Hat, where roadblocks never stand

10:35

in the way of where you need to go from the data

10:38

center to the clouds to the edge. Start

10:40

your journey at redhat.com flash

10:43

option.

10:51

Jamie was

10:53

telling us about the complexities of

10:55

using APIs for the exchange of health

10:58

data.

10:59

You know, we're

11:00

a more open understanding that

11:02

there's a value exchange going on between

11:04

the user and the social media platform

11:06

or between the media company and the advertiser,

11:10

right? There is an implicit understanding

11:12

from the consumer that

11:15

part of the opportunity to

11:17

get something is that they're sharing

11:19

some part of themselves. But that's not the case

11:22

in health care.

11:23

So we're thinking

11:25

APIs are very useful

11:27

for, let's say, buying something

11:29

off of a social media platform or

11:32

having all of your different applications

11:35

integrated with each other. If you want to share photos,

11:37

if you want to have

11:39

things integrated with your personal calendar. But

11:41

this isn't the same thing. This isn't apples

11:43

to apples, right? This isn't the

11:45

same thing as buying a T-shirt. This is

11:47

a person's medical history. It's

11:50

very deeply personal information

11:52

that they probably don't want to share

11:54

with anyone else. Exactly. So

11:57

these are two different ends of the spectrum.

11:59

where

12:00

we put information out there easily,

12:03

freely, no one cares,

12:06

but when it comes to something so personal

12:09

and so intimate, your

12:12

medical information, that

12:15

has to be handled with a higher

12:17

level of scrutiny,

12:18

in my opinion. I guess

12:21

the question is, are APIs

12:23

the actual solution for

12:25

said thing? If we're so used to using

12:27

it in this really open way, when

12:30

we're talking about something very closed and

12:32

secure, this does

12:35

not seem like the same thing. Yeah, you

12:37

and I are on the same kind of wavelengths

12:39

about this, but here's Jamie

12:41

again, because he goes a little bit more in

12:43

depth.

12:44

When we're talking about PII, personally

12:46

identifiable information, citizen data,

12:49

patient data, when we're talking about the

12:51

data of individuals, there

12:54

is already an expectation of privacy. And

12:56

we've seen, I think, in the last five

12:58

years, a huge explosion

13:01

in awareness from consumers about

13:04

how at risk, you know, their online

13:07

information is. So when you take a step back

13:09

and you look at where this landscape has led

13:11

us, if you're a bad actor, you

13:14

sort of go where the easiest target is. And

13:16

APIs are the easiest target today.

13:20

Wow. I can see

13:22

that. I can totally see that. Yeah.

13:25

And it's almost if we're talking about such

13:28

private data and protecting

13:30

their laws in place to protect people's

13:33

medical information and PII.

13:36

Yeah. So I always go back to

13:38

the old adage, it's not

13:41

if you're going to get hacked, it's when. That's

13:43

right. And how do you mitigate against

13:46

putting your business in the street like that? Yeah.

13:49

How? And again, I think it has to do with

13:51

where we are as a technologically

13:53

advanced society and where we are with our

13:55

relationship with technology, right? There's so much

13:58

risk of they're okay with taking on.

13:59

But this does not apply to that situation.

14:02

This crosses the line. None of us are

14:04

willing to take that risk. And APIs,

14:07

unfortunately, have already become

14:09

a huge target for cybercrime because

14:11

they become so ubiquitous. They've proliferated

14:14

to the point where they're everywhere. According

14:16

to a 2021 survey covered in VentureBeat, 94% of the respondents

14:21

that they

14:21

talked to cyber security professionals

14:23

experienced security issues related

14:26

to

14:26

APIs that year. Wow.

14:28

Wow. Thank you. I did a lot more than

14:32

I was expecting there. Is this, are

14:34

APIs such a big target for cybercrime?

14:37

Is that because of

14:39

just the nature of APIs that they

14:41

allow you into systems? Well,

14:45

I think it's because it's like they're integrated

14:47

with these systems. They're kind of like, think of them

14:50

as kind of like a go-between, right? So

14:52

they're allowing two applications to talk

14:54

to each other. Yeah.

14:56

So, you know, think of it as like

14:58

a bridge between two islands. What's

15:00

the most vulnerable point of that

15:02

relationship is the bridge itself. Mmm.

15:05

Good analogy. And then you add patient

15:08

data into the mix. That's a

15:10

goldmine. Let's see. It's a recipe

15:12

for something very

15:14

disastrous that a lot of people really wouldn't

15:17

be able to understand the consequences

15:20

of the ramifications of

15:21

right away. Yeah. Yeah.

15:23

Bober points out the compliance

15:26

issues, which is what Angela you were talking about

15:28

a little bit, the compliance issues, the

15:30

APIs and the scenario of

15:32

one system failing while

15:35

the other system is trying to access

15:37

the data through the API.

15:38

The APIs are like still

15:40

the one of the best approach

15:43

to go to some modernization, but

15:46

you need to consider

15:48

this modernization comes with responsibilities,

15:51

like responsibilities, which means like

15:55

data, another API,

15:57

let's say with health system or with

16:00

the on-the-man systems, that both APIs

16:02

should be

16:05

communicated enough. Otherwise,

16:07

like, if one system is not reliable,

16:10

if this system fails, it

16:12

cannot get the response on time.

16:15

When Vober said that

16:18

to me, I immediately started going through,

16:21

like, life or death scenarios in my head because that's

16:23

really what a lot of health care is,

16:25

right? It is a lot of times, emergency

16:27

situations or life and death. If

16:30

the person that you're working on or the person

16:32

that

16:32

you're doing, you know, you're responding

16:34

to an

16:34

emergency, the person that you're trying to administer

16:36

care for has a pacemaker, but you

16:38

don't know that, or the

16:40

person has a certain type of allergy, but the

16:43

information, the health data that has

16:45

that information, that EHR,

16:48

is not readily accessible because one

16:50

system is failing, the APIs there,

16:52

the API is working, but one system fails while the other

16:54

system is up. For me,

16:56

and maybe I'm just sensationalizing

16:59

it a bit too much, but I can't

17:01

stress enough that this information that we're

17:03

talking about, these EHRs, they

17:06

contain information that is very

17:08

sensitive to

17:09

our very lives.

17:11

And you bring up an interesting point here, Kim, because

17:14

it's like we obviously want to

17:16

be concerned about privacy

17:18

and security,

17:21

and at the same time,

17:23

we do want people to be able to access

17:26

it when they need to access it, like the right

17:28

people. The right people. The

17:31

right people.

17:31

Who are the right people though? Who

17:34

does that? Who decides that? Does the government decide

17:36

that? Does the hospital

17:38

decide that? Does your primary

17:42

doctor decide? It's a lot

17:44

of very, very

17:46

big questions around health data

17:49

and who needs to know and who doesn't need to

17:51

know. Exactly. Just because you're in a hospital

17:54

and you have a logon to this system, are

17:57

there role-based access controls in place?

17:59

that says you can or cannot access

18:02

this data. How are we segmenting

18:04

it off? And that's just another level

18:07

of security, but it's also another

18:09

level of complexity because maybe

18:12

you can or should have access

18:14

to patient X, but

18:16

not patient Y or whatever. I

18:18

don't know, I'm just saying like, knowing

18:21

who should have access and

18:24

taking it a step further, you know, if

18:27

you're a patient not in

18:29

a particular

18:30

hospital, but your information

18:32

is a part of this health system or

18:34

it's trying to be accessed, should you

18:37

be allowed to access it? Like where are

18:39

the guardrails? Where are the

18:41

rules

18:41

that says who can access what,

18:44

when and why? Yes, Jamie

18:47

talks about this a bit too.

18:49

When we think about data transmission,

18:52

we think about several core

18:54

concepts. What is the data itself?

18:57

So is it, you know, mailing address or is it

18:59

personal health information, test results?

19:02

Has the subject of the data appended any

19:04

constraints? Are there any legal constraints? You

19:06

know, what are the constraints around this data sharing?

19:09

And then what can that data actually

19:11

be used for?

19:13

Just like what is the data

19:15

itself? Who's requesting it?

19:17

Where is it going? And who

19:19

could read it?

19:21

Yes, and something as dynamic

19:24

as someone's, you know, doctor

19:26

visits, something that can be very, you know,

19:29

like it's not static,

19:31

it's very dynamic. If you have children, you have

19:33

a pediatrician, you have all these different specialists

19:36

and things, you have dental care, you have

19:38

vision, you have, there's, you know,

19:40

our

19:41

healthcare, I guess I would call it a healthcare

19:44

data portfolio, but

19:46

the ecosystem in the portfolio is very

19:48

complex. So the

19:50

simple kind of, you know, who needs to know

19:53

is actually quite a big question

19:55

and quite

19:56

difficult to decide when it's

19:58

constantly changing.

21:59

We're on social

22:00

media all the time. We're posting photos.

22:03

We're doing all the things we probably shouldn't be doing, but we're

22:05

doing them.

22:06

But this is the one thing that is going

22:08

to continue to give me pause

22:11

because this is something I don't think we should

22:13

rush into for the sake of, well,

22:16

we have to get this data out here and there's the

22:18

Cures Act in there. We have to do this

22:21

by a certain time or date. I'm

22:24

really interested in seeing where this goes because

22:27

this

22:27

is all the marbles really.

22:29

Well, this is reminding me of something that we've talked

22:32

about on this show before, which is that

22:34

technology doesn't exist in a vacuum.

22:37

That's correct. The technology that we're building

22:40

as technologists intersect

22:43

with the law. It

22:45

intersects with social

22:47

issues. It intersects with historical

22:51

issues. It's all kind

22:53

of embedded and knotted up

22:55

within all that. It exists within

22:58

all of these different contexts.

23:01

And I

23:03

just lost my train of thought.

23:05

Catch the next

23:06

one. Well, you

23:08

know what?

23:09

That was actually a really good segue because Fober

23:11

has done, like I said, a lot

23:14

of writing on APIs. He

23:16

identifies three important factors

23:18

in building an API.

23:20

Problem, people, and context.

23:23

Those factors are important,

23:25

but they're not the only things we need to

23:27

understand.

23:29

When you are, let's say, dividing

23:32

this moment's application or

23:34

a business system, think

23:36

about

23:38

what will be the outcome for the future

23:42

when you are migrating the

23:44

system to another newer, better

23:47

systems because the factors also depends

23:49

on not only three problems in consumer

23:51

context, but in the future, how you

23:53

would like to support.

23:56

This is the reason that

23:58

I wanted to talk about...

23:59

APIs within the context

24:02

of legacy technology. Because

24:04

sometimes the challenge with migrating

24:07

to a newer platform or a newer system

24:10

isn't a technical problem. It's

24:12

a human problem.

24:14

Wait, explain that a little bit. I

24:16

don't know.

24:17

So we have a situation here where

24:20

we have the solution, right? APIs are

24:22

a great way to have two

24:25

different systems talk to each other. Okay.

24:27

There are problems with API security

24:30

that obviously need to be addressed.

24:32

If you have leaky APIs, if you know, like

24:34

there's the people who are building it. There's a

24:36

lot of episodes we have in our bad catalogs. You

24:38

can listen to that have the same kind of refrain of

24:41

the people are building it or not building what security in mind.

24:43

Then obviously you're going to have people who take advantage

24:45

of that bad actors. Right. But

24:49

in this situation, it's intriguing

24:51

that the people

24:53

who are affected, the patients,

24:56

the healthcare providers, they

24:58

are fighting back against modernization

25:01

for reasons that are, you

25:04

know, on, on paper and at face

25:06

value, quite valid. Because

25:09

they're not sure about the

25:11

guardrails. I'm not sure about who's going to have access

25:14

to data. And even though

25:16

there are governments and organizations that are trying

25:18

to work out what these modernization

25:21

efforts look like, they don't have all the

25:23

answers up front. And when you don't

25:25

have all the answers up front with something as sensitive

25:28

as heart surgery,

25:30

that's

25:31

kind of concerning.

25:34

That is concerning. Yeah. Think about technology.

25:37

Usually technology usually

25:39

progresses. Everybody jumps on it

25:41

and they don't think about these things. This

25:45

is one of those scenarios where yes,

25:47

the technology has taken off. It's been

25:49

around for a while. It's prolific, but

25:52

we're trying to use it in this new and

25:54

different use case where the rules are

25:57

different.

25:59

This is really.

25:59

Like you said, it's a human problem.

26:02

You're dealing with such critical information.

26:04

How do you reframe

26:08

the way you

26:10

build and interact when something

26:13

is such high value? And

26:16

I wonder if that's a different thought process.

26:20

I wonder if that makes

26:22

you think about it differently.

26:25

Just a question.

26:26

I think when we started this episode, I

26:28

was thinking maybe uncritically

26:30

about this because I was like, oh

26:33

modernization, that's good.

26:35

Of course, we should use APIs to solve

26:37

this really

26:42

important problem. Of course,

26:45

modernization equals good.

26:47

Again, I

26:49

was thinking very uncritically. I

26:52

think what I'm having trouble making sense

26:54

of in my mind is I want

26:57

to keep the optimism that I had

27:00

at the beginning of this episode. I

27:03

want to be optimistic about

27:05

solving important problems with technology.

27:09

And at the same time, I

27:12

want to be critical about the way

27:14

I'm doing it. And sometimes

27:18

I don't know how to hold those two things together because

27:20

it's so easy to slide into like pessimism

27:24

and paralysis. How

27:26

do you think critically while also remaining

27:29

optimistic?

27:30

Good question. Angela, what do you think?

27:34

Okay, so I'm

27:36

going to be perfectly honest with you. Yeah,

27:38

go ahead. I am hopeful, but I

27:40

am very

27:43

terrified. This is one of those things

27:45

where rushing

27:48

to modernize can definitely

27:50

have its downside. And

27:53

for those folks who are rallying

27:56

against this type of modernization,

27:59

it's because because their lives are at risk.

28:02

And there's very few things that we do on the

28:04

internet where our lives are

28:06

at risk. And this really

28:08

does just change my perspective

28:11

in how technology is being used.

28:14

I know that there are amazing companies

28:16

out there working to solve this very

28:19

problem. But again,

28:21

I'm one of those wait and see

28:23

type of people because we cannot

28:26

and we should not wanna rush into

28:28

this without having done

28:30

a lot of due diligence.

28:32

And there is no totally

28:35

impenetrable system. It doesn't

28:37

exist. That's why they're

28:39

bugs. That's why things happen, vulnerabilities

28:42

happen. So can

28:45

we promise?

28:48

Question mark. Never. Right?

28:50

There's always some risk, right?

28:52

I think that in the situation or situations

28:54

like this, fear is healthy because it means you care.

28:57

Okay, I can

28:59

live with that. Yeah. Yeah,

29:01

fear is healthy. If you're a technologist and you have fear,

29:04

you have hesitation. That's good because

29:06

it means that you care about the end goal. You

29:09

care about the people who are involved and

29:11

impacted by the things that you make.

29:13

As long as you don't let it paralyze you. No,

29:16

of course. No.

29:16

Of course, you do move

29:18

forward. You still have to move forward.

29:20

With caution. With caution. With

29:23

extreme caution.

29:25

Kim, I'm really curious. We've

29:27

been talking about APIs in the context

29:30

of healthcare. And we

29:32

have been talking about how maybe

29:35

sometimes modernization, we might

29:38

want to be cautious about it. What

29:40

can this teach us about

29:43

other contexts, specifically

29:45

with modernization?

29:47

For me, working on this episode

29:50

taught me a lot about expectations

29:52

and the kind

29:55

of expectations we have with technology

29:58

when we are just consuming the technology.

29:59

when we create the technology.

30:03

And I feel like there's certain

30:05

expectations on all sides that

30:08

are manageable. And then there are ones

30:10

that

30:11

may not reflect the reality. Jamie

30:15

said something about pushing things

30:17

fast and breaking things. And pushing

30:20

and breaking things fast are a part of

30:23

whether we like it or not, modern day

30:24

culture. But

30:27

that doesn't translate very

30:29

well into something like healthcare. And

30:31

I

30:31

feel like the most important thing

30:33

for people to take away from all

30:35

of this, because these are questions

30:38

that we're still, they don't have answers. They're still,

30:40

you know, things are still being debated and

30:42

still going through

30:45

discussion, going through legislative

30:48

bodies, through the

30:49

government. I think the

30:51

biggest takeaway from all of this

30:53

is keeping

30:56

in mind that sometimes humanity

30:59

has to catch up with what we can

31:01

do technically.

31:02

I'll say that again. Oh, there it

31:04

is.

31:05

Sometimes humanity has to catch

31:07

up with what's technically possible. And

31:10

as long as we keep that in mind and

31:13

are empathetic to the people who

31:15

are most impacted on the

31:17

apps that we build, on the

31:19

APIs that we are working on, on

31:22

the systems that we maintain, we'll

31:24

all be better off for it.

31:28

What do you think about our API issue in

31:30

the context of legacy technologies?

31:33

Is it really the panacea for app

31:36

modernization for older technologies

31:38

that we think it is? I would love to

31:40

hear your thoughts about this and

31:42

on all the other cool things we talked about today.

31:45

Please hit us up on social media at Red

31:47

Hat using the hashtag compiler

31:49

podcast. We would love to hear from

31:52

you. And that does it for this episode of Completely

32:00

Today's episode was produced by

32:02

Kim Wong and Caroline Craighead.

32:05

A big thank you to our guests,

32:07

Jamie Becklin and Bover Umerzakos.

32:10

Victoria Lawton is a natural born communicator.

32:13

Just don't ask her to send you a fax.

32:17

Our audio engineer is Christian

32:19

Proholm. Special thanks to Sean

32:21

Cole. Our theme song was composed

32:23

by Mary Anchetta. Our

32:25

audio team includes Lee Day,

32:27

Stephanie Wonderlich, Mike Esser,

32:30

Nick Burns, Aaron Williamson,

32:32

Karen King, Jared Oates,

32:34

Rachel Hortel, Desinte Hout,

32:37

Mattias Foundez, Mike Compton,

32:39

Ocean Matthews, Paige Johnson and

32:42

Alex Treblesi.

32:43

If you like today's episode,

32:45

please follow the show. Raid

32:47

us, leave a review, share it with someone

32:49

you know. It really does help us out.

32:52

Take care everybody. Until next time.

32:55

Alright, see you next time. We'll fax you.