Brian Corbin – Accelerating healthcare transactions with Python and PyPy – PyCon 2016

Brian Corbin – Accelerating healthcare transactions with Python and PyPy – PyCon 2016


(Brian Corbin)
All right. Thank you all very much. It’s been exciting for me
to be here at PyCon. I’m a South Carolina native
so we came a little way to get here. And so I want to talk to you today
about some of the work we’ve been doing at PokitDok to help both move faster and help facilitate more change
more quickly by using Python, and also running that faster by using
PyPy to execute that Python code. So if we flip to the slides here,
I kind of did a quick outline. If we were to do this talk in Python,
we might have a few function calls or method calls here
that would discuss a little bit about health care for those
that aren’t familiar with that. We’ll talk about some of these
standard transactions that are exchanged as part of
conducting a healthcare transaction. And then we’ll also talk about
some of the things that we’re doing to build things quickly in Python
and running it fast with PyPy. And I did a version of this talk,
and then I kind of went back through it and I realized that without
an appropriate context manager, some of the things
may not make sense. So we’ll spend a few moments
at the beginning applying a context manager to some of this
to hopefully better introduce it and give folks a little bit
different perspective. So let’s travel
down the road to PyCon. I know everyone traveled
a little bit different road to get here and during their life.
So I grew up in Clifton, South Carolina, and just down the road from my house,
you’ll see signs like this. This is a tractor, and you see
a lot of tractors kind of moving about. And I grew up in South Carolina,
spent all my life there. And in high school,
I had a really good teacher, and that man taught me
that ignorance breeds ignorance. And I want you to kind of
keep this quote in your mind and imagine — you know,
there’s a guy from South Carolina wearing overalls
that’s giving you this quote from a public school
in South Carolina. So let’s keep that in mind
as we go through this talk. And I also want to take a brief
moment to recognize some folks that were instrumental
in getting me into computing. When I grew up,
I didn’t really have a computer. I didn’t really do much with
computing until I got to college. And these were some of the three
professors that helped me out a lot: Dr. Olds, Dr. Varn, and Dr. Shiflet. She was actually
the chairman of the department. So as I was coming up,
most of my interaction was with her. So I didn’t realize there weren’t
really that many women in computing until I got out into industry.
And so I just wanted to thank her. She recently retired, and I think
she would be well pleased to see a lot of the folks
that have shown up at PyCon that are, I think,
ready to pick up her torch that she carried for so many years
to inspire other folks to do big things in computing. And so, based on some of their work,
I got into rural computing. A lot of the best problem solvers
I met in graduate school and after, I found out they all came
from small towns in the South and South Carolina,
and really all over the world. They have a different perspective
sometimes and I wanted to do more to encourage those folks
to do more in computing. And so I would come home
and complain to my wife a lot that there weren’t meetups
and there weren’t other things that a lot of folks
maybe in the Bay area or other places enjoy and have access to.
And so I wanted to do more of that in our small town in South Carolina
and in other towns like it. So I got together with some other
folks and we started a nonprofit to equip, educate,
and encourage more folks to do things with computing.
And as a result of that — we kind of live near another city
that’s known as The Hub City. It’s where all the trains intersected
for all the old textile mills, and it’s called The Hub City
because it was a hub for that. And so we kind of started
our own little Python user group a few years back.
And I told him I would do this. I wanted to put Trey Bailey
from Cow Pens, South Carolina on the board. We didn’t have
a very good spot to meet up, but this is the back
of an old furniture store that allowed us to put
our projector up and review some code. And so throughout this process, I was working to kind of
build up more awareness for some of the really good folks
doing things in rural areas, and — but a lot of folks
didn’t really understand that. They kept thinking I was
trying to introduce folks to do better PowerPoint
presentations and whatnot. And as you can tell
from some of the slides, I’m not the person
you really want to talk to if you are looking to make
a super-duper presentation. But along my path and industry,
I met up with a couple of folks that were really inspirational for me. And so as I was facing problems encouraging more people
to do things in the rural areas and those folks
not really understanding, I met up with Lisa and Ted.
And at the time they were working on a number of projects,
and I asked them, I said, “Hey I would like to work
with you all,” because my family was also going through some
health care problems at the time. And so I’ve got this passion
or helping folks in rural areas, and I also understand
there’s a lot of complications that everyone deals with
in healthcare. And so in 2011,
I joined up with Ted and Lisa as the first engineer officially
to sign along the dotted line to join the company,
and I’ve been working with a lot of really good folks
over the years with them, and I just can’t say enough about
these folks. When I speak about them, it’s like they’re my extended family,
not really like a company. So I just appreciate
all that they’ve done to help me. And now, healthcare. So, I can’t
say it quite like John Oliver would, but we’re gonna try to do our best.
And as a many of you all know, it impacts all of us
regardless of our gender, or religion, or race,
or anything like that. So it’s a very important problem
that we all should be focused on. One of the things that get folks
riled up sometimes about healthcare is who pays. Do I pay? Do you pay?
Does someone else pay? Is there some coordination of paying?
And it all gets really complicated. And then when you add technology
into some of these healthcare problems, folks get further frustrated
because a lot of things in healthcare aren’t as easy as, like, maybe
uploading a photo of your dinner. And it’s hard for some of the
established folks to change because they’ve acquired
a number of systems over the years and they don’t talk to each other
and they don’t necessarily have time to redo everything. So they’re
trying to keep things running. And it’s difficult
for new folks to enter because there’s this tremendous
barrier that you have to cross to get into the healthcare business. And so that kind of makes
a lot of folks sad, and they kind of shrug,
maybe walk off and don’t necessarily consider
doing things in healthcare. But there are a lot of things
that we can help fix, even if we’re not politicians
or are not actively involved in policy-making decisions,
things like that, like if we’re working in tech. We can make it easier for you
to check your own healthcare information. Have I met my deductible?
Am I covered for this service? We can make it easier for
healthcare providers to get paid, those providers that are
really good providers that are out there
trying to make a difference and just want to help folks without
this extra administrative burden. And this list could go
on and on and on. So one of those professors
I showed you earlier, Dr. Olds, he told me one day, he’s like,
“Brian, one of the great things “about standards
is that there’s so many of them.” And in healthcare
that’s absolutely true. The more I started working
in healthcare, the more people started rattling off
these transaction set codes to me. “Give me a 271, 270, 276, 277,” and they just go on down the list,
and after a while you just kind of glaze over and you’re
not quite sure what’s going on. But trust me, all these really do map
to something that really happens. But I wanted to point out too
that I tried to put the number of pages in some of these claims.
Like for “claims” there, some of these specifications, like,
in just the professional claim specification, not anyone’s
particular implementation guide, that’s 704 pages. So if you’re having trouble
sleeping at night and you don’t want to take additional
medications or anything, I can recommend that you go to read that
and it’ll put you to sleep pretty quick. So, some of the folks back at PokitDok
have worked really hard to try to help folks visualize
how these transactions fit together, because it gets
really complicated very quickly. And for folks that have
really good technical ideas but they’re new to healthcare,
we’ve been trying to help them implement their ideas more quickly. And so as you can see here,
you enroll in benefits. Once you’re enrolled,
you can check your eligibility. You can potentially get
authorized for a service. And after that, you can file claims,
check the status of those claims. You could do that
in a whole kind of loop. And then if you don’t like your plan,
you could change and re-enroll and go through that process again. So let’s look at
some of the X12 raw data. And here’s just a sample snippet
that I kind of grabbed and wanted to use to introduce folks
to these transactions that might not be
familiar with them. So each X12 healthcare transaction,
like the other X12 transactions that exist for other industries,
have this notion of an envelope. So there are these two records
that kind of bookend all the data in between.
And inside that envelope, there’s a functional grouping
of transaction sets. And then inside that grouping,
there’s a transaction set and there can be one or more
of these transactions sets. So you can kind of see,
I’ve indented it on this slide, but there’s this notion
of this looping that can happen. So these files can be really small
and just contain one transaction. They can be really big
and contain a whole bunch. And so let me show you what the guts
of one of these transactions might look like. Here’s a claim.
This is one of my own claims, because, you know, a lot of this
data is HIPAA protected, but I can give you all my data
that I want. It’s OK. So this is one that I had recently
just for a routine physical, and it’s just a snippet,
but you can see in here, like the SV1 segment ID there,
that’s like a line item on a receipt. So if you go buy something
at the store, they’ll give you a receipt and say
you got this product or this service. And so in the healthcare claim,
it’s very much like that. I got this procedure 99214
and I paid 70 bucks for it and so on. A lot of times, though,
these transactions aren’t even this well-formed.
A lot of times it will be on one line. And so you end up, like,
trying to scroll forever to figure out what’s going on. It’s just not a very intuitive way
to work through some of this stuff. So at PokitDok, one of the things
we’ve been doing is — and we work in Python quite a bit.
So we’ve been working to make sure that we can easily convert to and from
a dictionary representation of these transactions,
because it’s easier for us to work with and review
and even talk with our EDI team and other folks in the healthcare
business about this data. And they don’t have to get mired up in all of those older transactions
unless they want to. And so, folks that draw
and visualize things better than I do helped make this
for some customers at PokitDok to help them kind of understand
the flow of transactions through our system
and other systems that may be doing similar kind of transactions.
And one of the main things I just kind of want to highlight
here if you can see it, is there’s a couple of indicators
as this workflow progresses that says, well,
it may be about 24 hours before you get back an acknowledgement
for this claim transmission. Or it might be one to two weeks
before you hear whether or not your claim has made it into this
adjudication process and it might be paid.
And then if there’s additional paperwork required,
it may take even longer. And so a lot of times I’ll ask folks,
“Well, why does it take one to two weeks?” Or “What happens between
this point and this point?” And one of the answers
I get a lot is, “Well, “that’s just the way
we’ve always done it.” And you might expect in the South
they say that for other things too, maybe incorrectly. And I just
wanted to kind of mention this: that my grandma, she made
the best fried okra I’ve ever had. And I’ve never found anybody else
that had any fried okra like Grandma. That’s about the only thing that
“That’s the way we’ve always done it” should be used for. So if it’s
your grandma’s fried okra, it’s okay. If it’s something in healthcare
or something in another industry, you always want to make
an examination of it and see if you can do
a little bit better. or if it’s a new group,
you want to, you know, treat them well. You may not
know anything about them. And so, just another
quick little summary here. In healthcare, there’s a couple things
that challenge us along the way. A lot of folks are too big
to move quickly. My brother recently shared
a video on YouTube with me of a V8 chainsaw that was
out here I think in Portland or in Washington state.
And I was really impressed by it. My brother thought it was great.
But it’s a V8 engine on a big chainsaw and it takes a couple of big folks
to move it around to get it over the log that they’re cutting up.
And that’s kind of what I visualize when folks say they can only use
enterprise products to do things. When we move with Python,
we move a lot quicker. But, you know, a lot of folks
unfortunately get so caught up in these specs
that I just walked you through, they never get to actually
implementing anything or making the first transaction
get across the wire. And I was telling some folks
at lunch that that’s kind of like the Allen Iverson segment, you know,
where he was talking about practice, he was just talking about practice,
not the actual game. Unfortunately in health care,
a lot of folks talk about specs and don’t ever make it
to the actual transactions. And in the South, this would compare
to, like, pulling weeds all day in the corner of a field
and never getting the field cut. So at PokitDok, some of the folks
I’ve been chatting with about how we work and how
I might explain it to folks, especially in rural areas:
it’s kind of like tractors and weed eaters and we’re trying to —
in each development sprint we’re trying to get the field cut
but make it still look good so it’d be a nice pastoral scene that
folks would want to come by and admire. So one day I was walking through
a field between my house and my brother’s house. We live
on some land in South Carolina. And he comes home with this
on his trailer. And I said, “Man, what are you gon’ do
with that? What is that?” He goes, “Man, this is a field mower.” He goes, “I’m calling my buddy Reed.
We gon’ hook that up to the four-wheeler “and we gon’ get after this field
and cut it all down “and make it real nice.”
And I was like, “Oh my goodness.” But sure enough, these guys
are some of the best problem solvers I know and they came up,
and that evening, within minutes, that field was cut.
And then I started thinking about how we operate at PokitDok
with some of the Python stuff. We really have been kind of operating
like these guys have been, making quick work of the work
that they’ve been given. And so let’s talk about how Python
might help facilitate some of that. So I look at Python like
the diamond plate truck toolbox. So if you know folks that have
big trucks or trucks, a lot of times you’ll see
this kind of truck box on the back. And this is my brother’s truck.
So if he rolls up to help you on a problem, he doesn’t say,
“I’m gonna come back “in 6 to 18 months
and I’ll get with you then.” He says, “I got that in the truck.
I’m gon’ help you right now.” And I feel like
that’s how I view Python and some of the stuff we’ve been doing.
And as many of you probably know, Python’s really good
for large and small projects. A lot of folks in healthcare
will sometimes kind of come at me with, “Well, it’s just a scripting language.”
Well, we’ve built a whole platform with it, right?
A large system, large application. It’s got a really good standard library
for a lot of the common things that you might run across
in healthcare. You’ve got all sorts of really good
language features like decorators, generators, context managers. It’s just easy to tote around,
like my backpack. So how can we tractor with Python? I’m interactive all day.
I don’t know if you went to Scopatz’s talk the other day,
but he’s got some good stuff with Python and Bash
and merging those things together. So I’m interactive all the time.
I operate one line at a time. And that’s been a big help
to me to quickly know: Does this work? Does this not work? And this is kind of like
the workflow I do every day. If someone calls up and says, “Hey
we need to get this done real fast,” I kind of work through
interactive evaluations, come up with snippets, and test.
And I sling them right up there into a buffer. And then those snippets
evolve into a library of functions. And then I ship it and circle back around
so we can get something out there to meet folks’ needs. And when you
ship it and circle back around, it’s kind of like you’re driving
a big truck. You kind of have to turn that big wheel
and come back around. So how do you weed eat?
Well, there’s a lot of folks on our team like Dixon Whitmire.
He’s one of the best guys I know at doing some of this.
So if I sling stuff up there and it’s working pretty well
but there’s opportunities for improvement, Dixon can come back through
or any of the other folks on the team and reduce any kind of duplication. Those functions may become classes. We’ll optimize code based on some
real-world metrics we’ve been gathering. And here’s an important thing:
it’s OK to call that tractor back if not enough was fixed up.
I know a lot of folks don’t want to have technical debt
linger, and we don’t either. And so this is how we deal with it.
The weed eater crew can always call you back
and say, “Hey, let’s fix this up.” So let’s look at a couple of
samples here that we’ve got that we’ve just kind of
discovered or stumbled across with how we process X12 with python. One of the first things
I like to point out to folks is we use context managers a lot. And so, you notice in that other
slide where there’s an X12 file, there’s an X12 functional group,
and a transaction set. Each of those have corresponding
trailers where they have to keep up with, like, the segment counts
and other information about what was contained
in that file. But by using these context managers,
we can just focus on writing out segments and doing
maybe business-specific things. And when we kick out of that
context manager, the trailers and the counts and everything
just kind of naturally flow along. The same thing popped up
with decorators. As you saw earlier, all these segments exist
and they’re all over the place, and depending on the context
that they occur in, they may have different meanings
associated with them. And so in this case,
here’s an example from a 271 response that contains
your eligibility information, in this case, the deductible. So rather than having these funky
‘if’ blocks that go on for miles, we break those up into functions,
decorate them so that we can apply just those when we encounter
a segment that we’re processing. So in this case we’ll pick up
the EB segment, we’ll take the EB01 element
when it’s a C, and then this function will fire.
And that’s kind of the logic we’ll load up
based on the transaction set to convert
these raw EDI transactions into our dictionaries
that we work with internally. We make heavy use of generators,
because I don’t know if you’ve picked up anything
off the shelf before and it’s highly touted as being
an EDI mapper or whatnot, and then you throw the first
big swole file to it and it just totally hit —
goes out of memory and blows up. Well, with Python, as you know, we can use generators
to stream this data in. So we can work with it more efficiently
and keep a lower memory footprint. So we stream in these segments
and we can work with them in a raw mode, kind of just like a plain dictionary
with that raw segment data. But we can also chain
these generators together, so I can stream in my segments,
bust those up into dictionaries, and then take
those segment dictionaries and then map them
into internal models, so that when I’m working
within that context, I never even really
look at the raw EDI. I’m just yielding these internal
dictionaries that represent transactions. So unless there’s
some sort of core issue, I’m always working with these
higher level transactions and I can make
pretty quick work of those. And as an example of that, a lot of folks will tout these
X12 standards on and on and on, but then in practice, let’s say
for, like, the enrollment world, a lot of times
what ends up happening is they ship your data around
in spreadsheets or CSV files, not the X12 834 that they
preached a lot to you about. And so one of the things
that we’ve done even related to eligibility data
is, folks will say, “Hey, “we’ve got customers
that would like to use your APIs “to access their eligibility data, “but we can’t send you
an X12 271,” for whatever reason. “But I can send you a spreadsheet
or I can send you a CSV.” And so you can import CSV
from the standard library. You can create a little generator that can take the dictionary
representation of that row, we can quickly map it
to our internal model, and then we can stream it
back out as X12, as if it had come to us that way. And then we can host that data for them.
Our customers can use the APIs. They never know that there was
a problem behind the scenes with X12. So that’s been a really cool thing
for us to use there. And if you’ve noticed,
all this stuff fits on a slide. So we’ll get to an example in a minute
that won’t fit on a slide. So buckle your safety belts.
We’re going to accelerate and hit the last part of this talk,
because I know you’re wondering about, “Well, where does PyPy come in?” So in the South, you hear a lot of stuff
that may sound ignorant sometimes, and I hear it in the healthcare world
when they talk about Python. So you’ll hear stuff like,
“But my mama’s brother’s neighbor’s “co-worker’s best friend said Python
was too slow and you can’t scale.” And I’m like — I do my Scooby-Doo
on that. I’m like, “Ruff?” I’m like, “What are you talking about?” I don’t even know if that makes sense,
but you hear it a lot, right? And a lot of organizations,
both at the upper level and even lower level, will say,
“Well, we’re not going to consider that.” And I think that’s a mistake
sometimes. So let’s see, how can we make this go faster? We’re gonna bring in Py power.
We’re going to take our Python code, run it with PyPy,
and we’re going to accelerate. And if you’ve ever seen
the movie “Sling Blade,” this is what I imagine
when I get to this slide. You know, you’ve got
a perfectly good lawnmower here. All these folks are standing around it
saying, “Well, it ain’t working.” And then Sling Blade or Billy Bob
comes over and he just goes, “It ain’t got any gas in it.” And so that’s kind of what I think
a lot of these folks are missing, right? They just ain’t got any gas
in their lawn mower. So we switched to PyPy and we’ve seen
really good results from that, and we’re going to check that out
here in a second. But one thing I wanted to point out here:
while we were working through a big project
and running it with PyPy, we did hit a few things
that I didn’t expect. And in one case,
I had some tests that broke due to some UI degeneration
and I couldn’t quite figure it out. But I took a moment and I posted
on their issue tracker. I’m like,
“Hey. Hey, folks. How you doing? “I appreciate all your work
and I want to thank you for it. “And I just ran across this
and I’m not sure what to do with it.” So, you know, working in healthcare,
I don’t even know if I expected a response for 6 to 18 months
or whatever. Well, sure enough, that same day,
Alex Gaynor, a guy I don’t even know but I’ve heard a lot about
and I respect, he shows up. He says, “Man, that looks pretty bad.
I’ma go ahead and fix it right now.” And then, sure enough,
that same-day service happened. He fixed it in PyPy
and we kept rolling. So I just wanted to mention
that a lot of times — and this is something my dad
always told us growing up that my grandma passed down
was that, you know, it doesn’t cost you anything
to be nice to somebody. And that’s something that’s
stuck with me for a long time. And you see a lot of times
in the tech world, you’ll have a lot of people
talking down to each other on pull requests and on other things.
And I don’t think that’s right, right? We shouldn’t treat each other that way.
And I’ve found that I get a lot better results,
my pull requests get processed or my issues get worked
if I say, “How you doing?” In the South, we’d say,
“How’s your mama and them?” But I don’t do that
on the pull requests. [laughter] And then I thank them. I say,
“Thank y’all for your hard work,” because I know a lot of people
are putting in big-time work onto this stuff and I don’t even
understand half of it, right? So I respect what they’re doing. So let’s get to the main event.
I know I’m running out of time here. Let me give you a real-world example
that maybe you can take back to some of your folks
that may not believe in Python or may not believe in PyPy
and in some of the work there. So let’s take
some real-world stuff here. So if you’re familiar with healthcare,
you know that each health are provider gets a unique ID. They call it an NPI. And it’s used all over
these X12 transactions. It’s used all over the place.
And just as an example, that 146 etc., that’s actually me. You can go get your own NPI
if you work in healthcare, and you can make your specialty,
like, “healthcare data technician” or whatever the code is. So they use the Luhn algorithm
to do a checksum on this, kind of like you might do
a credit card. And I’m not going to go
into that algorithm, but there’s a good write-up
on Wikipedia about that. But really it’s just designed
to catch accidental errors. You know, there’s a lot of typos,
you know, if somebody’s manually entering something,
and we want to catch that before we relay it on to a trading
partner or payer for processing. So on that Wikipedia page,
they had a Python snippet, an example implementation
of the Luhn algorithm that someone had posted.
So I was like, “That’s pretty cool.” Let’s just do some timings of that,
just to show folks, well, what kind of speed-ups might you get
on a real-world kind of thing with PyPy. So I did a few rounds of timeits,
and with Python 2.7, it came out at maybe like
9.74 microseconds per loop. Python 3.5 was a little bit faster
in these tests. And ran it with PyPy
and it went down to 1.54. So that’s pretty significant.
I didn’t do anything but just take a snippet of Python code
and ran it with a different interpreter. Well, one of my co-workers,
Jared Corduan, I call him JC for short. He’s a South Carolina native also
but he doesn’t talk quite like I do. He’s a little bit more refined,
I would say. But he’s got a big math background,
a PhD in math, I think, actually. And he came over and we were working
on some new pharmacy APIs and he said, “Hey man, I think I can
make that go a little bit faster.” And so he says, “You know, I think
that’s just really “some integer arithmetic,
maybe a lookup table or something. “Here, take these four functions
and try it out.” So I’m like — you know.
And it still fits on the slide. He’s got a bunch of comments on it
if you look at the companion, so you can get the full detail there. And so while we were talking,
I was like, “Let’s see how that does.”
And look at that! Pretty — I mean, this is —
even in the non-JIT’d CPython, it went from, like, 9 to 2.21. So you get a pretty good
speed-up, you know, just thinking a little bit more
about how you’d solve the problem. There was a little bit
of an increase in Python 3.5. I haven’t had a chance
to look into that yet, but there may be something else
going on there that I didn’t expect. But in PyPy, look. It was almost like
a three times improvement there just by kind of
swapping out your algorithm. And so I was like,
“Man, JC, that’s awesome.” And then he was like,
“Well, let’s see. “How long would it take
to validate all the NPIs? “Let’s say we got — tomorrow,
every healthcare provider in the US “said, ‘Here’s a claim.’ Let’s process it.
Let’s validate all that stuff.” So, another little quick snippet.
Again, it fits on the screen. Taking JC’s implementation,
and we’re going to take the May release of the NPI data. There’s a public data set out there.
Anybody can get it. And if you’re a healthcare provider,
don’t put your cell phone in there, because it’s public data.
Then you’ll get all these calls and you won’t know
where they’re coming from. So that’s just a heads up on that. We get asked that a lot.
“Well, how’d you get my phone number?” Well it’s in this data set. It’s public.
It’s out there on the Internet, you know. So anyway, I wanted to have
this little snippet. I wanted to run JC’s algorithm a bunch
to see what would happen there. And just out of fun, in curiosity,
a lot of folks just say, you know, “We can’t use Python. We use Java.
We need speed,” or whatnot. And I was like, “All right,
so let’s do a Java version too.” And it’s been a while
since I’ve written any Java, so y’all might be able to do
a better one that I did. So that’s another reason I kind of
pulled in the Apache commons there to get their Luhn algorithm. I thought that might be
a little bit more fine-tuned. But you notice,
this doesn’t fit on the screen. You have to go out and check
the companion to see the rest of that. So let’s compare them. And these
are all rough calculations, right, like we might do in the field,
my brother just tinkering with something. Run the Java version. I ran this
over and over and over and over again, got similar timings.
Ran JC’s algorithm in PyPy. It always beat it, every time. A lot of people don’t think about that,
right, because they never stop to learn about anybody new
or anything new, and I just wanted to kind of highlight that to maybe
let those folks consider something new. Basically to say:
algorithms still matter, and a lot of folks
don’t think about that. So let’s take it to the house.
Just a quick summary of what we are going to
wrap up with here, things I want you to kind of
maybe take back with you. Interactive development and a JIT:
it helps you tractor and go fast, and Python and PyPy
are one way to do that. And one of my co-workers and friends,
Ghadi, would like me to remind you that Clojure could also be used
in this case. But since we’re at PyCon,
I’m talking about Python. But yes, there are other
alternatives out there, and folks should consider those too
because those may fit, you know, better
with your organization. But in general, folks should be
more open-minded about the tools and techniques they could use
to solve some of these really important problems that we
all face and that impact us all. And there’s a couple of
follow-up references. Brett Cannon, I got to chat
with him the other day. They’re doing some cool stuff
with Pyjion to make it easier for folks to bolt on the JITs
of the future, and he’s got a really good summary,
a good survey of other Python interpreters
if this is kind of interesting to you. And he does a much better job
at recapping all of that than I could ever do. If you’re more
interested in the Luhn algorithm and those NPI checksums,
you can check that out. And I’ve got a little repo on GitHub
and I’ve got a docker image out there too if you want to
take this and run it on your machine to see what’s up. And thank y’all. I really appreciate it. [applause] (session chair)
Thank you very much, Brian. Unfortunately, we don’t have
enough time for questions, so what I would encourage you
is to talk to Brian on the hallway or open an Open Space.
Thank you very much, Brian. [applause]

Daniel Yohans

1 thought on “Brian Corbin – Accelerating healthcare transactions with Python and PyPy – PyCon 2016

  1. desertfish74 says:

    This is a pretty fun talk that I didn't expect at all because of EDI (arghhh). Well done 🙂

Leave a Reply

Your email address will not be published. Required fields are marked *