Improving Healthcare Data Interoperability with Cerner’s Greg Meyer

Episode 104 · 43:09 · SRT · archive.org · all Tanzu Talk

Hi, everyone. Welcome to Pivotal Conversations. I'm Jeff Kelly, and this week, Dorman and I chat with Cerner's Greg Meyer. Greg is a distinguished engineer at the maker of healthcare software, and in this episode, Greg talks about a new specification he helped develop to achieve interoperability and easier data movement between healthcare systems. He also explains how the company is modernizing its development practices to increase the pace of innovation, all for the benefit of patients and healthcare outcome. So Greg, maybe you can tell us about this specification reference implementation that you've been working on, just to get us up to speed on what is it? What is it intended to solve for society at large? Right. So just give a little bit of context here. So health IT, one of the kind of big movers in health IT over the past decade or so has been interoperability, and that's interoperability, it's got a lot of definitions. But in this context, it's really kind of moving information from one health system organization to another, and that's amongst a lot of other things. Typically, there's been a couple big standards organizations in health IT interoperability, those being HL7 and IHE. A lot of those specifications, the interface is built around those. They can be very complex in terms of configuration, the specifications themselves. So back in late 2009, there's actually one of the engineering fellows here at Cerner and a Gartner, one of the Gartner guys, were working on something that they wanted to do to be able to pass information very simply between two organizations and what they

initially called that simple interop. And they wanted it to be built on top of some existing specifications. They could do structured or non-structured data. A lot of things inside of health IT are very, very structured. So one of the other things they did is in early 2010, there was a part of the federal government called ONC, Office of National Coordinator, and that's under a bigger umbrella of HH Health and Human Services, which I'm sure a lot of people are aware of them. They do Medicare, Medicaid, amongst a lot of other things. And they brought about 80 companies together all in one. This is kind of one of the first times that they initially tried to do this underneath this umbrella. And that's, hey, we're going to take the simple interop idea and we're going to go turn it into something real. With the goal being is we want a mechanism instead of these complex interfaces of sending information, let's just create a simple way to go do this. So the 80 companies met, we had various task force and work groups. Eventually, we came out with initial specification of what we thought we might want it to look like. We did a bake-off of about four implementations. Eventually, in the summer of 2010, we came to a conclusion that we're going to use SMTP and a few other things, some SMIME specifications. And what that allowed us to do is then start running with some reference implementations built off of those specs. And interestingly enough, it was the entire endeavor was what we called a duocracy. A lot of the folks writing the reference implementations were actually writing a lot of the specs and driving a lot of the specs. So it's very different than what we see in a lot of the IHE and HL7 interoperability task force where they have a lot of these spec writers and policy writers, and then they just drop a spec out there. And then maybe or maybe somebody may or may not write a reference implementation. But this was the total opposite where

you got the guys doing the work, writing the implementations, doing a lot of the spec writing. So as the actual spec came out, we had a full working implementation out there. So what does the specification actually do? It's in the end, it's just a simple point to point standard where we can push information from one organization to another. Just using simple SMTP, it actually runs off of the exact same backbone internet that your email does today. So we didn't really invent anything new. We just put some security layers on top of it that kind of made it robust for healthcare. So it was a push type of specification where an organization that they needed to push some data to another, they just type in an email address, they push it, does some trust and some security verification, and can send that data. And there's a whole bunch of different use cases out there that you could now go utilize this for. And it was like transitions of care, referrals, we can go on and on and on. But that's the verbal diarrhea of the specification called the direct project. Direct project. Yeah, there's definitely, thank you for that sort of high level, how the sausage is made in terms of reference implementations in these specifications. It's interesting that this is a different way that things went about this in a different way than kind of in the past. It sounds like there's some advantages to having the reference implementation developed at the same time as the spec being defined so that it's actually usable. That sounds, that sounds, you know, almost kind of akin to, uh, you know, like having, having the developers actually write the tests before they write the code, that kind of notion of, instead of having these in two separate places, like collapse it into one.

Yep. Yep. Absolutely. Yep. And, and it really did speed up. I, I think in terms of being able to turn this into a, um, into something that was usable by the public at large. I mean, you, you hear about a lot of these specifications taking years and years to write. We went from an idea to a 1.0 release version of the reference implementation in under a year and that included a, a consensus spec as well as a reference implementation. We actually did it so fast that, um, ONC, when they did their certificate, they write these health IT certification of specifications that all health IT vendors have to go. We went from an idea to actually be written into a health IT regulation in about 18 months, which is totally unheard of. Wow. Yeah. Um, yeah, it seems like the, the, the kind of the path to production, if you will, was, was streamlined in that case. So, you know, tell us kind of that, that all sort of happened in the, you know, early 2010s. Um, and so what's been happening since, and you recently put out a new reference implementation, um, but maybe you could kind of walk us through what, you know, your, your journey has been on, what your journey has been, um, in kind of arriving at the, the current version. Yeah, sure. Um, so this, this actually goes back almost a decade. Um, I, I actually didn't get introduced into spring until probably about 2008 or so. Um, I was working on another product and written on top of an ESB architecture and they were just getting ready to move into spring, you know, when they were coming out their latest version of their ESB software. And I looked at it initially, I think it was like spring 2.5. It was still, um, fairly newish, you know, with, you know, five years old or so, um, very verbose based very much in, in XML. Um, personally,

I found it to be a little too verbose, a little hard to use. So I, I kind of shied away from it a little bit. And then when we started doing the reference implementation in 2010, I think we had spring three at the time, we, we kind of split off the two teams that wrote that, um, I handled the core spec and then another one was doing some configuration and those were some web-based apps. And they did all of that, um, with the spring XML, they did wars, you know, deployed in Tomcat. Um, again, I, I looked at the updated spec was still kind of shying away from it because, because I felt it was, it was very heavy, maybe hard to configure. So in the, in the core spec, that guy was looking for something lighter and I ended up going with anything. I went with Google juice, um, after working with it for a couple of years, you know, I actually found it being a lot harder than I thought it was going to be. Um, just, but it was lightweight. And then I think in like 2012, the, the folks that were of the team that handled all the web UI stuff and web configuration, they actually left the, this, this was all open source, uh, volunteer projects. And now I gotta, I gotta, um, handle and, and own the entire stack. So I, I was forced to go actually learn spring at, at the state that it was at, or at least in the version that they put in there. Um, still shying away a little bit, still kind of early on, they were using still some 2.5 and 3.0 stuff, but I did come to get an appreciation of the declarative nature of spring at the time. It was a lot easy or pretty easy to make some changes specifically at like deployment time. I could write some scripting to do some things like that. Um, at, at the same time, because you know, this is a reference implementation. So it gets downloaded, um, by anybody who wants to go use it. You know, my company actually Cerner was using it as well. And you know, it's, it's a reference implementation. So I always make these analogies of reference implementations, you know, like reference hardware. If you look at folks that implement hardware, a lot of folks will put out a reference

board. Um, you'll make some tweaks to it before you go into production. So it was the same thing with here. So we, we were kind of eating some of the dog food that I put out there, uh, making some tweaks so we could have our own Cerner or, uh, our own Cerner direct project specification. Again, it was, it was very Tomcat based. We, we were doing microservices sort of, you know, instead of what we think now of spring boot, we had all these little itty bitty little Tomcat apps. Um, and then for the core spec, we're using this product called Apache James, um, which was using some of the juice stuff. So we had kind of a polygon of spring and a whole bunch of Tomcat apps. And then the, the core direct specs still running in juice. Then in about, this was, I want to say February, 2015 of, of all people, Josh Long came to Cerner and he gave us a presentation here on some of the great, you know, the latest status, latest and greatest stuff coming up in spring. And, uh, spring boot was only less than a year old. Uh, spring cloud was still an alpha and he gave us this great presentation, um, here in Kansas city on doing spring boot applications and using Netflix OSS spring cloud, um, spring boot configuration. And it just completely changed the way that we looked about doing our applications and doing our microservices. We're actually doing a rewrite of one of our, um, kind of like our, our male web client that sits over the top of our direct project implementation. We did a complete rewrite of that thing, um, using spring boot. And I still wasn't a big buyer into it. I actually wasn't part of that process. I was doing some other things. Um, so still, still hadn't bought into, into spring quite yet. Um, but then in about late 2016, uh, we got the call, uh, Brian Kelly and I did here of, Hey, we get to go cloud native. We can go pick whatever we want. And so we picked to go do PCF. And that's really when I jumped into spring boot,

um, and, and got the latest and greatest stuff. I think it was spring four or something at the time. And as I wrote, did the deep dive into that completely changed my view on spring. I couldn't believe the number of updates that, that they had done in terms of the way that you do configuration. I mean, the fact that I didn't have to do XML anymore. Um, I had annotation based, um, configuration. Um, I could go do spring data. I could go write interfaces, um, for doing all my, my data access. And it just totally blew my mind. Auto configuration, um, was another big piece of that. So we took our implementation of, of Cerner, Cerner's direct implementation completely did the entire stack in, in spring boot. It was like 30, some 30 or 40, some, uh, microservice. And we've, we've got a lot of complex systems here. And we went, then we ended up going live with that just a few months ago. And ever since then, I mean, that, that jump into spring four and getting to do PCF and, and seeing the, the integration now that we could go do and writing applications a lot faster. And just, like I said, it completely changed my view of spring forever. Wow. Okay. So this was, no, this was the Cerner implementation based on specification, but the, the, the main publicly accessible reference implementation was, which you kind of maintained is this, that's the volunteer side. Um, now had, is what's that currently available in? Yep. So that's a great segue there. Um, so as we were doing a lot of these microservices for, for our implementation, we were having to kind of swizzle some of the reference implementation, because we're still a lot of our implementation still based off the reference implementation. Um, we had to swizzle those into kind of updating those components to, to work as spring boot

app. So this actually happened at a SpringOne this pet, just this past year, a couple months ago, I was sitting in a lot of those sessions in there and just going through my head. Oh man, what just, I need to be putting these back in the reference implementation. I've, and I've really been wanting to do this for a long time and just never found the motivation or time to go do that. So actually at SpringOne, during one of the breaks, I sat down there, downloaded all the code and just kind of started from the bottom up all the way down at the, at the DAO layer and doing a comparison of, well, we've got all of these DAO implementation classes, just thousands of lines of code out here written in still in, uh, in spring three and started doing those, those migrations. And actually I tweeted some things out doing some side-by-side comparisons of the amount of code that we had to write with those old DAOs versus, um, the first one being spring data interfaces. And I was just literally going through and just deleting thousands of lines of code, um, and inside there, you know, making maintenance just so much easier. And over the, the past couple of months just started going through all the different layers of the stack. So, you know, we, we got rid of a lot of these old SOAP interfaces. Um, we did RESTful interfaces in JAX-RS. Um, all that got, uh, ended up moving into spring MVC and, you know, while we're doing it, might as well add in web flux in there as well. So we've got, um, you know, we, we have streaming interfaces in there. A lot of our RESTful clients that we had on the client side were all kind of all handwritten. We weren't even using REST templates, you know, shame on us for that. Um, but then we started moving that into FANE clients, you know, again, eliminating tons and tons of code. Actually the, the fun part with the FANE clients is a lot of that was just copy-pacing those spring MVC, um, definitions inside of the, inside of the, the microservices and just dumping them right into, into FANE interfaces. Um, authentication, you know, we had a lot of handwritten authentication, uh, spring cloud security ended up getting rid of that,

uh, got rid of a lot of the XML configuration, uh, using annotations, um, the ability to pull in property files or sports, uh, spring cloud, uh, config if we wanted to, uh, we really wanted to modernize this, but also be backward compatible with the classic version, which was Tomcat and James. We realized if people were going to update to this new version, they still may want to go do, um, Tomcat, but they may want to go do, um, they may want to go do a spring boot microservices and maybe even PCF. So we, we found the ability to go take an existing more or something, you know, an end state and be able to run both at the same time. So we now had dual support of our classic mode and our, uh, um, microservices. So over here the past couple of months, we actually did last week or two weeks ago, a milestone one release of the reference implementation. That's completely modernized, modular microservices. Um, we've, we've actually pushed a lot of these out on, uh, um, pivotal web services. You know, I, I had lunch with James Watters out there at SpringOne. He was nice enough to allocate us some resources to go do this. So now we've got, uh, an entire reference implementation, not only running kind of in our pet VMs, but now fully running a complete stack out in pivotal web services. Okay. So for folks that are also in healthcare, specifically touching healthcare IT, and want to make use of this updated reference implementation, where should they go to take a look at it and kind of be able to start to play around with it? Is it a pivotal web service hosted version? Yeah. So there, there's, there's quite a few options. Number one, it's all open source. So all the codes out, it's still out there in GitHub. Um, we, we're moving it to a new organization now out there. So it's, uh, I think direct project RI is the, or direct project job RI is the, is the GitHub

source. Uh, we post everything out on in Maven central repos. So there's like a, what we call an assembly project on all the microservices that are, they're out on the Maven. And then we also post out a, a, uh, a reference implementation, uh, installation guide out there. Uh, it's, I believe it's api.directproject.org and gives everybody, here's how you download it. Here's how you go install it. Um, my next part of the, the reference implementation is now updating everything. If somebody wants to go do it, the the microservices way, um, I do highly, um, recommend using something like cloud foundry or, or pivotal cloud foundry to go do that. Um, if somebody wants to go stand up their own cloud foundry and implementation, you know, you're absolutely free to go do so, you know, either using open source or, or going out and giving cloud foundry of the, or pivotal cloud foundry, the, the pivotal web services was, was a very nice way to, to go do this of trying to get the stood up. Um, especially if you're somebody that wants to go from a classic, um, you know, kind of home cloud hosted system, or even folks that are doing, um, public cloud, they kind of either take their existing VMs and just re-implement them or they'll do a lift and shift. But if they want to do a true cloud native stack, um, without a big cost of implementing, uh, you know, a whole bunch of VMs out there, uh, did some of the math on this, you know, it's like seven microservices that we had to push out there to do a full stack. Um, I think there were four services from the, uh, from the marketplace that we had to go pull in. And if, if you do the, if you do the cost comparison, it is just ridiculously how cheap you can actually go do this. Even if you did like an Amazon EC2 instance, you know, you're going to be paying, I don't know how many hundreds of dollars a month to, to go do that, but you're, you're really having to tend to it and, and really feed it like a pet. Whereas with, if you're doing the cloud foundry way, we just pushed it out there.

Um, the deployment became very easy. We could integrate it with concourse for doing CICD. Um, I think the cost around that, and this was for the full stack and everything, you know, it was a few hundred, even below $1,000 a month, you know, depending on how much data that you wanted to go push through there. So, um, it'll be interesting to see how many folks want to start moving into true cloud native type of implementations versus a, versus a pet model, because it's, it's actually a lot easier to go run it and it's a lot cheaper than they think it might be. Yeah. So it seems like this kind of move to, you know, a, a fully kind of modernized and rewritten way of running the, the specification with this, with this reference implementation is sort of potentially a, an opportunity for folks to start to embrace, embrace a broader cloud native way of operating. Am I understanding that right? Yeah, absolutely. So you get not just the, the modernization of, of the architecture that makes it cloud native, but all, you know, all of the other things that kind of inherently or either consequently or inconsequently that come with that, that you may not think of, you know, and a lot of this comes around your, your day two pieces of it, of being able to do troubleshooting. You know, it's, it's amazing when we ended up moving to a cloud foundry, just how easy, how much easier and integrated and seamless it was to go do just the operational and support side of it. The deployment and configuration just becomes so much easier. I can't tell you how much time folks will spend just on configuration alone. You know, the CICD pieces of it. So you get, you just get so many different aspects of this that you just don't think of, of by going cloud native. So in that cost comparison that you were referring to, you know, help me understand that a little bit cleaner. What you were comparing, running this new reference implementation, you said you had it on some pet VMs. Were the pet VMs running PCF or was it, you know, you had to kind of manage the full

stack there? Yeah, you had to manage the full stack. So when we first pushed out the reference implementation, we just threw out a Ubuntu EC2 instance out on Amazon. You know, it, it, it didn't have a lot of power. You know, these are a little micro service or a little, you know, micro instances out there. But, and, but if you wanted to go turn on a, an instance of this, there was just a lot of manual steps that you had to go do a lot of configuration that actually the documentation is, I don't know how many pages long of trying to turn these on or trying to turn these on. The cost for the EC2 instances themselves are not actually that much. It's when you start getting into a lot of the day two and the manual configuration, because honestly, that's where a lot of your cost is going to end up running from a day two perspective of, okay, I need to go do an update to this. What's that going to cost me from a personnel resourcing perspective versus if I want to go do this in a, in a pivotal web services, you know, if I, if I've got patch management or whatever, I'm going to go do the, the cost, that's really where the big cost comparison is going to hit. If, if you just start looking at here's an EC2 instance, you know, a couple of them that are going to run me, you know, to maybe 200 bucks a month versus I'm going to go run this out in Pivotal cloud or Pivotal web services might cost me 500 a month. But what am I getting in terms of my total cost of ownership? And that's where that cost comparison really starts to show up where you've got to go do tending of pets and patch management and updating of databases and configuration versus you just kind of get that for free, free as in beer here, but you, you get a lot more of the, you don't have to spend so much resourcing, um, of trying to keep things up to date using cloud native, um, Pivotal web sources versus doing a pet tended system. Yeah. And if for folks that, you know, they could also, if they still wanted to be using, um, Amazon for their infrastructure, they could put cloud foundry or, or PCF on there and do the same

thing. I'm kind of curious, but your recommendation for sort of looking at P dubs is just because, hey, it's already up and running. Um, it's a PCF environment that you can then push this reference implementation to quickly and you have all the day two taken care of already. Yeah. I mean, we, you know, we, we, we inside a CERN, we've, you know, we do stand up a pivotal cloud foundry out on, on Amazon. So that's definitely an option. But as you said, you know, the infrastructure here was already done. So, you know, trying to, trying to turn on the system. Now you don't have to go worry about allocating services, having to go get a PCF expert, uh, that knows how to go stand up a system. You know, we, there's a system already out there. So it was, uh, as we were writing, writing code, it was just, uh, a matter of going to the marketplace, turning on the three or four, you know, things that we need, just a quick CF create service instance. You know, it's, it's one command to go turn these on and then create a manifest and do a CF push. So it's, it's just night and day trying, trying to, trying to stand up a full, a fully implemented stack, you know, just using a few commands. And how does that trickle down to, uh, other things you can now do in, in your productivity and other areas? In, in terms of, uh, well, you know, in, in terms of doing CICD. So that that's one of our productivity pieces, you know, before in order to push something out, we were having to maintain a lot of chef scripts out there, which, you know, anytime we made a change to a, that we had to make a change to the system, we had to go man to maintain a chef script. Uh, then we had to go do all the chefy things that you have to go do of synchronizing up to a service, making things, um, up to date, and then go kicking those off on, on the nodes. Uh, whereas today in, in our, uh, system that we have now, you know, we utilize concourse and concourse is a very streamlined approach of going and doing that.

And a lot of the things that we would have to go do in chef, um, just now become a, uh, natural side effect of just doing our pipelines and our day-to-day work. So we don't even think about, Hey, I need to go update this configuration chef. I mean, the, the pipeline just takes care of it. Um, if I want to go kick something off, you know, we've, we've got automated pieces that are automatically just running single commands out there as, as opposed to, uh, you know, these convoluted scripts to go, to go kick that off. So that that's just one aspect from the developer side. Um, you know, and, and we can get into, to all the day two pieces of it. You know, we, before when we were using chef, we kind of had two completely different implementations of, of chef set up one for development, uh, one for production. We had two different, completely different pipelines. We had one pipeline for development and then there's kind of like a kick it over the wall into the, into the production, you know, into the production guys. Now, now it's all streamlined. We just see everything as a, as one pipeline going through development and hitting those, those different aspects that they have to, you know, we're ISO, uh, 9,000 compliant and healthcare. So we've got to make sure we're meeting about regulatory pieces, but we just see it as one streamlined process that, that hooks all together. And we're not maintaining two different systems. It's just one pipeline from end to end. Yeah. That kind of seems to, um, set you up to avoid a lot of those issues of like, well, it worked in this environment and now it's not working over here. Yeah. That's, that's been one of the nicest parts of, I think of moving to concourse and PCF is as we look at what our development systems look like versus our production systems, they're almost completely identical, even all the way down to dev where we're doing some of our experimentation, you know, from an infrastructure perspective, it's all the same. You know, we're, we're allocating the exact same size of, uh, of services of being at databases or rabbit or Eureka or whatever else we're using out there, Redis. Um, and even, even the size of, of the machines themselves, you know,

I, I did this, uh, I did this comparison of our, of our compute resources that we had previously when we did our pet systems versus PCF. We had a ton of all over allocation over to prod. And then we basically didn't get a lot of love back over to our, to our development system. So when, when we did the graphs of the number of nodes and compute and memory and everything, prod had those big, huge bars going clear up in terms of the number of CPUs, but dev was, you know, very, very small. So it's, it's kind of hard to get a one, you know, side set side to side comparison. As you said, you're tearing your hair out going, why, why is this not working? It, it, it works over here, but not there. And you just don't have that type of compute now in PCF. When we look at the, between the two, you know, our, our dev systems have roughly the exact same amount of power and compute that our production systems do. So it's, it, it's a lot easier now when we get those systems that we got to go toss back into dev that we really are talking about apples to apples. Yeah. I want to jump back a little bit to, you mentioned that you, you, you've recently gone live inside Cerner with the, the modernized implementation that's now you, you said 30 or 40 different microservices and you know, now running in, in spring, you rattled off a bunch of different aspects of spring, spring data, um, auto config, spring security that you have been able to bring in as part of this rewrite. Um, so how long, how long did this process take within Cerner to kind of change how you guys are, are implementing the, the, the specification and were there any other kind of lessons or surprises along the way as, as you kind of went down this path? Yeah. Um, so most of the things, like I said, they were running as a Tomcat apps before and had to bring them over to spring boot. It was actually a pretty painless process to go do the, probably the

biggest part that we really had to be aware of was the configuration piece of it. Um, a lot of these being that they were Tomcat and they were getting pushed out via chef, which was copying configuration, you know, web XML files out there and properties files out there was trying to move that into a true cloud native configuration of being that being part of the, uh, the 12 factors out there. So if, you know, if anybody's looking at saying what's going to be the hardest part of trying to move from a legacy system over to a true cloud native system, and especially in spring boot, it's probably going to be, how are you doing your configuration and how do I need to wrap my mind around that? Cause that's, that's really going to be the hardest part of that. Um, there are some other things that we had to look at in terms of security configurations, just because we were previously running on prem, um, you know, running in a data center that was protected from the outside internet via, you know, firewalls, all that kind of things versus going out into public cloud. Uh, so a lot of, a lot of now security pieces that we didn't have to worry about, you know, we had to make sure we, all of our rabbit MQ connections were now using TLS, um, all of the end to end end points between all the microservices or part of our mesh were now all secured. Um, same thing we could say the exact same thing with my SQL, uh, previously trying to maintain a lot of those things would have been take, I don't want to say difficult, but there are other configuration things that we would then have to go worry about. Um, you know, with doing those as part of the marketplace now and, and just doing service bindings, it, it almost made it a no brainer to, to go do a lot of those. Um, some of the things with the service mesh of making those secure, um, we are using an older Oloth spec, um, to go make that happen, which a lot of these didn't have implemented. So we had to go turn that on. Um, we're now going to be looking, uh, probably sometime here in the near future, looking at Istio, which make, which could make that security layer a lot less, you know, a lot less complicated.

We'd probably end up ripping out and doing like we did with the reference implementation, end up ripping out a bunch of this, you know, legacy Oloth code in there and just let Istio take care of that. Um, so those, that's probably the biggest three that we ran into. Okay. I think that's super helpful for folks to kind of just thinking through any of these kind of modernization projects to sort of know where they're going to be facing bigger hurdles and other places where, you know, they can sort of save themselves a lot of hassle, like the, the kind of notion of, um, you know, the, the service bindings and in general, like using the, the concept of service broker. So those types of changes to some of the dependent services can get updated in a more seamless manner. That sounds great. Keeping an eye out for, for config security. Um, and I, and I think that it's a testament that, you know, in the part of, as part of doing this, you also moved it into the public cloud, proving out that that's possible, um, and can, can be done in a secure fashion. So, uh, kudos to that. Yep. And, and it's, it's interesting you bring it with the configuration and, and the public cloud, you know, one of the, one of the other pieces I, I've, I forgot to mention here, you know, with the service brokers is, is the entire credential management, you know, it's, it's no secret that, you know, Cerner's now got contracts with, uh, with DOD and VA. So the, the, the scrutiny that we get around security audits is a lot higher. And, you know, that, that involves things like making sure you're doing proper credential rotation. I can't tell you how much time is actually spent on a lot of our systems that, you know, we've got, we may even have an entire team that maybe that's all they do is just making sure that we're doing credential rotation. You know, the service broker model just makes it a non-worry out there. You know, we, you know, we, we, we would have to go out there and making sure that we have our credentials in sync, you know, on these 40 microservices connecting to RabbitMQ or MySQL, uh, using service brokers, we don't even think about it anymore. You know, we,

if, if we have to, if we've get a something coming down the line and a regulation that we have to go rotate these things every three months, that's okay, fine. We'll just go, we'll go add a blue green redeployment into a, uh, into a pipeline in, in production says redeploy this app every three months and boom, boom, we, we get auto, uh, we get auto credential management and rotation. Wow. Okay. So now to, to put this in some perspective for the, for lack of a better term, the community reference implementation that, that you work on as being kind of part of the, um, it's committee or I don't know what the right word is kind of going back to the, to the, to the whole sausage making, um, effort for, for building the spec and the reference architecture reference implementation. Um, you mentioned that you, you were really starting to dig into this at SpringOne platform. So late September this year, and you just had a milestone release a couple of weeks ago. So call it two months. Um, how, how long would that have taken you? Um, would you say in, in the past with, with the sort of, without, you know, the service broker model, without some of the, the kind of annotation model that, um, spring provides, et cetera, just, can you estimate like, what would that have, what, what amount of time when you would have had to figure out how to lay out volunteer wise for yourself in order to do that? Right. So when we did the first reference implementation, it took us roughly, I want to say seven months with three to four resources, um, working pretty much full time on this to, to, to bring this all, to bring this all up. Um, now moving over to the, uh, you know, it's a lot of the modernization things. And, and I should, I should also mention it, it took a lot of expertise across different domains and, uh, you know, different areas of,

you know, people being able to write, uh, modularized components for, for a modern spec versus, uh, the web APIs and everything else. Um, so yeah, about seven months for resources, moving all this over to a modernization, um, piece of this, you know, it took one guy, you know, it took me about roughly two months working, maybe 50% on it, um, to do this modernization. And a lot of that, you know, not, not only do we have a, a modernized implementation, but I, I think we've greatly enhanced the ability of what we can do with the system in, in terms of deployment, in terms of, um, the ability to manage it. So Spring Boot not only brought the ability to, to really simplify the architecture, you know, I, I mentioned the thousand lines that, that we deleted in there. It doesn't take nearly the expertise now to, to go maintain these, you know, for example, somebody tracing through a, a DAO implementation. Well, now it's just an interface. So you, you don't even have to go worry about that anymore. Um, as well as all of the other day two production things that, that you just get out of the box from, from Spring Boot. You know, if, if we had to go write all of the things, you know, I think of the, the actuators, the micrometer pieces, um, integration into, into other subsystems, you know, like PCF metrics. And that would, I, I can't even, I can't even put the, how long or substantiate the amount of effort it may have taken, uh, this team to go put together these, these production pieces, you know, those things that make a production system, a true production system. Um, had we not had, uh, Spring Boot too, where now we get all that out of the box. And, and I, you know, that, that's one of the arguments I have with people that say, well, oh, Spring Boot, that's just too heavy. You know, just, just go turn this out into a, into a used go. And you can just quickly turn this into something you can go deploy out there and like, yeah, you can deploy that out there, but now how are you going to go manage it? How are you going to operate it? How, how are you going to measure it? What, what do you get out of the box, you know, using a, a small go application compared to what you get out

of the box of a Spring Boot 2 application? It's, it's really hard to compare the two because you just really can't quantify it that well. There's, there's so much more that, that you get out in terms of, in terms of being able to, to measure, deploy a monitor, um, that, that you just can't do without using something like Spring Boot 2, or I should say that you just can't do very easily without a lot of effort. Yeah, no, that's, um, that's taking the long view, which, um, which I always appreciate. So, uh, one last question for me is, you know, now that, that you're able to kind of crank through, you know, modernizing a reference implementation over here and in a fraction of the time and effort, um, what's, what's next? What are you working on these days? Um, what are you, what are you looking forward to, to getting out? Oh, great question, boy. Um, a lot of what I'm doing is, is, is day to day, you know, I've, I'm the, the next piece is going to be taking this implementation. We obviously get documentation. Everybody seems to forget about the documentation part of, of this. So we're, we're going to go document, document this. We're going to go evangelize it. Um, there's, there's some other specifications, um, that are being utilized today inside of, uh, health IT. You know, one of the big ones out there is something called FHIR, F-H-I-R. It's fast, something, boy, I'm embarrassed. I can't remember what it talks about, but it's basically a restful way of, of being able to, to move data from one way to the other. It's kind of a poll, or it's a kind of a poll model, a request reply model of being able to evangelize some of these things of, of the, of what we've been able to do of being able to deploy services, not just for this reference implementation, but then moving these into other pieces of, of the healthcare architecture. So FHIR being one of those, um, we have a lot of other systems inside of our inter, interoperability

space where I work here at Cerner. Um, things like doing e-prescribing, um, some other HL7 transactions out there and modernize, modernizing those infrastructures as well. So what we did with direct project and, uh, a couple other systems in here inside of Cerner, which is kind of step one of proving out that, look, we can, we can take these systems and we can turn these into cloud native, uh, applications. We can push them out in the, in the, uh, in the public cloud. Um, we can operationalize them. I can't tell you actually how the amount of time that, uh, that we've reduced from our, from our operational side. So now trying to evangelize this in, inside of Cerner and actually try to take this out to some of the other implementations. If I can, this is going to be a hard fight, uh, with some of the other folks in, inside of HL7 or, or IHE and see if they can adopt, uh, reference architectures, um, inside of their organizations as well. Well, that sounds like an exciting path ahead. Where can folks follow you and, and sort of see how you're, you're coming along in this, uh, this adventure you've got for yourself? Yep. Um, they can generally find me out on LinkedIn and Twitter, uh, Twitter, uh, I believe my handle is Greg underscore Meyer 93. I think I'm violating something there with, uh, using an underscore, uh, and also LinkedIn. Uh, I think it's LinkedIn is Greg Meyer health IT. So I, I try to blog out there when I can, I don't get to do it nearly enough, but, um, as this milestone comes out, uh, you'll be catching a lot more of me out there. Well, I have learned a tremendous amount, both about, um, just kind of the, the general concepts around these specifications and how they're used, but also this, this pretty interesting journey that, uh, you've been on and that this particular, the direct project has been on, um, really exciting stuff and looking forward to hearing more. So we'll be make sure to include in the show notes links to the, the Maven repo and, and GitHub, um, for, for the direct, um, project so that folks can try it out. Awesome. All right. Thank you so much.

Thank you.

Tanzu Talk · 🍕 Get more pizza.