Today on This Week Health.

You can get yourself into sticky situations when you have thousands of apps internally that you're trying to support and maintain but one of the use cases that is so important, not just in pediatrics, but just in disease management in general is the concept of a disease action plan.

Welcome to This Week Health Community. This is TownHall a show hosted by leaders on the front lines with 📍 interviews of people making things happen in healthcare with technology. My name is Bill Russell, the creator of This Week Health, a set of channels designed to amplify great thinking to propel healthcare forward. We want to thank our show sponsors Olive, Rubrik, Trellix, Hillrom, Medigate and F5 in partnership with Sirius Healthcare for investing in our mission to develop the next generation of health leaders. Now onto our show.

Hello and welcome to another episode of This Week in health IT. I'm Jake Lancaster, a internal medicine physician and the chief medical information officer for Baptist Memorial healthcare. And today I have Peter Hong who is a Clinical Informatics fellow as well as a Pediatric Hospitalist fellow at Boston Children's. Peter, welcome to the program.

Thanks Jake. So nice to be here.

Can you tell the audience just a little bit about your background and what you're doing.

I am the son of a veterinarian and born in Florida. Three younger brothers and with all the animals and other human type animals around the house, I was almost destined to become a pediatrician. And so I really like the philosophy of preventive medicine and the ideology behind ounce of prevention preventing a pound of cure. And I think when I got to finally experience pediatric residency I was really encumbered by a lot of the processes.

A lot of which I am sure I'm preaching to the choir here, but a lot of which involved information technology and different processes that, that touched upon our clinical information systems. And so I was trying to figure out what more people were doing in this space and found that such a thing as clinical informatics fellowships existed around the country and found my way from pediatric residency initially in Dallas, Texas, and now finishing my third year of training at Boston, Massachusetts.

Well, that's great. Thank you again for agreeing to come on the program. I think what we wanted to talk about today was some of the work that you're doing with internal app development. Now a lot of the places I've worked at you know that we're outside of maybe an academic medical center, didn't have a lot of internal app development capabilities. Most of what we would take on would be third-party vendors, or we would have some some capabilities of internal development around our EHR. But when you're talking about app development, can you just explain a little bit of what you're doing and what your experience has been?

I think one thing that really attracted me to this program here, t here was a strong culture for many decades, really around finding the best either process or the best software or sometimes vendor to help meet the needs of our institution, of our, the workflows of our clinicians and one of the things and culturally generally, if we couldn't find that in the public space or there was no vendor working on that, then that NBCH wouldn't necessarily hesitate to just make it themselves.

And so I thought that was pretty cool. Of course you can get yourself into sticky situations when you have thousands of apps internally that you're trying to support and maintain but one of the use cases that is so important, not just in pediatrics, but just in disease management in general is the concept of a disease action plan.

So if you have asthma or diabetes or hypertension or congestive heart failure, that does not just describe a specific state that you're in at any, along your entire life, you can have different flare ups of your chronic disease and the disease action plan should be kind of part educational tool, part clinical tool to help patients understand based on their symptoms based on.

Some signs that the physicians can help them to interpret at home, to empower themselves, to take care of themselves. And so lot of people were kind of doing these by hand in the different divisions or the different groups clinically at Boston children's and we thought, could we give our providers.

A little bit of a tool. So a framework for them to be able to design the plans themselves without having to do a lot of coding themselves or a lot of reinventing the wheel or trying to bootleg different productivity softwares to all essentially do the same thing that everyone else is doing.

Okay. So do you have a dedicated team to this app development or is it really scattered, like you were saying across every department has their own coders.

If we're going to integrate this into our electronic health record, our interfaces team and our clinical applications, so we can serve like a web service face up to the clinician in a seamless experience within their electronic health record workflow. And so this group got together and tried to figure out their project scope.

You said launching the app, is this an iOS, Android app or is this more of a FHIR base?

No, no, this is completely internal and not mobile. It is a JavaScript app that is launched through the web through a browser experience that is embedded into our electronic health records.

Okay. And within your team what sort of capabilities do you have as far as skill sets go? Is it mainly going to be Java base or you'll have the ability for developing, I guess other types of apps, mobile apps are based apps etc.

Yeah, I think across the enterprise, you can imagine just like people are doing great work clinically. There are a lot of people with different software development skills, whether that's languages themselves, or the arrange of their backend and front end skillset. And this particular group I think was just one small part of the Boston children's enterprise. And I should mention that I'm not speaking on behalf of children's formally, but just about my experiences personally.

We have, for example an innovation group called the Innovation Development Healthcare Accelerator or something like that. IDHA that has multiple arms dedicated toward research and development and teams who are proficient and you named the software language, I think doing a lot of work.

I'll give you an app for example circulation, which I think was maybe bought out by Uber health if I remember correctly working on transportation within healthcare. And I'm not sure what language that was coded in, but I'm sure they had sufficient power and a sufficient scope to be able to have a functional app that they were able to spin out into a public company.

And then I think in the not in the information services department and like clinical applications group itself there's people working more directly with Cerner our core electronic health record vendor product, every one of them including some modules from Epic, but they're, they're using the specific languages that help them to understand how to work in Cerner or an Epic accordingly.

And then you know, I think the sky's the limit, but I think one thing that you mentioned earlier on the call is you don't really often see software developers in inside clinical and healthcare team. So I think part of the reason why this construct or language, I say our framework was chose was mostly because of the expertise of the people who are on staff.

And I'm sure if they were more proficient with Python or that that environment of tools then that very well could have been a reason for choosing that. And maybe Java Scripts are fairly commonly available language and has information that people can research quickly and hopefully a wide community that we can recruit people into.

But you know a lot of people, especially particularly in the Boston area, once they get proficient at certain languages, have many other opportunities for software development outside of healthcare, per se.

You alluded to this earlier, when you were talking about how apps were maybe previously developed in individual departments. But in my experience at another academic center, we had a similar issue where there was some independent app development that would occur and we'd have these legacy apps and then the physician or whoever made the app would leave the organization. And then all of a sudden you had to pick up this, this code that nobody knew about and tried to maintain it over time. How has your group looking at making sure that they can maintain and keep up with, with these apps once they're out there?

Yeah. Oh man. Gosh, if we had the answer to that I think we would be all set. We wouldn't need to look outside for any vendor softwares. I think we, we had a similar experience of that and I'm sure we're very much not alone.

In some of our applications being written by specialists with really deep domain knowledge and certain things that necessarily weren't a easily fundable skillset. And I think somewhat, fortunately I think a lot of people are working in this space and the, a lot of the different vendors and companies globally.

So sometimes we have fortunately been in a situation where something starts to not work so much. And it's, we're at the point where it's harder and harder to keep putting patchwork onto an application when everything else around it is evolving rapidly. And at some point with advocacy efforts or more research and I think publicity around the importance of you know some of the different functionality and the electronic health record, particularly in pediatric needs. Different vendors are catching up and able to provide some of that software. So we don't necessarily need to then go to redesign those applications from the ground up. And there seem to be ways that we can more seamlessly integrate that either from a vendor or a company that works very closely with some of the vendors that we work with.

Okay. Let's shift gears. Can you tell us a little bit about your, your intake process for new projects that somebody wants to get off the ground?

I wish I had a crystal clear map that I could paint, but there are, just at a really high level, there's no executive governance structures. There's IT governance teams that then report up to the executive governance for projects that include things like real estate acquisitions or opening up of clinics in different areas or different programs. And so I think there's any clinician, any person can request the support of an executive sponsor or at some point in the chain of command. You need the approval and have to have run by your thought for a a plan by someone. And if they think that it's a reasonable thing to bring to this council, then we can kind of present your evidence, what you think the return on investment for that will be whether that's financial or whether that's safety and quality, which are a little bit more difficult to measure the impact of.

And then what kind of resources you would need and what kind of impact that would have, whether that's mostly for your division or a small group, or whether that might have wider ranging implications for safety or for financial return across the enterprise. And so if, if it seems to make sense and just kind of goes through iterative processes of review by groups to see if that, if it makes sense. X project makes more sense than compared to Y projects since we're resource constrained.

We're talking to a fellowship audience, I guess the project management, triple scope of a triple constraint of either their budget and resources or time and your budget resources and time. Is that what I'm thinking of?

Peppered in different ways. Yeah. It can be there fast, good and cheap. I think it's what you're referring to.

Yeah, that's right.

So quality, speed, and cost I think it's what you were alluding to. But I would imagine first, if you have a new need, I guess for somebody has a need and they would come to this group, you all would evaluate externally first to see if it already exists elsewhere before trying to build it yourselves and try and then I guess determining one, is there a need for it at the organization. Two, does it exist within our EHR or through a third-party vendor and then three, do we have the expertise internally to build it? If it doesn't exist somewhere else?

I think that's exactly right. I would be so curious of all the requests that are just submitted or just thought about in, across the institution and not never submitted, how many of those would be reconciled with just education on the things that we already have, or education on how to use the things that we already have better.

Or just a introduction to a creative way to use a tool that we already have that a person may not know about. I'm curious in that same evaluation prior to you running it by your sponsor to bring up to this governance chain. How well we're doing across an enterprise at sharing the secrets are not the secrets, but the best practices that you learn on how to deliver care well.

Well but yeah, I think that's exactly right if. If you do a quick market scan of what's available and you see that the only vendor doing this as selling the product at a way to exhorbitant of a price, maybe you can try to make a case for doing it yourself. Although if you imagine if a vendors already have, have a mature product out there that they're going to be other people who might be following or that it's gonna be really difficult to justify over the longitudinal view you making your own internal thing.

Yeah. So I would imagine whatever does end up coming to your group would, would be a fairly niche use case. Can you just share a few of the things that you've been working on?

Yeah. So actually I wish I could speak more to all the different apps that are going across the enterprise. And I'll say just looking back historically on some of the functionality that wasn't quite up to snuff and it's not to say that it didn't exist on the market, but may not have been attached to the, the suite of software products that we are using at any given time.

But charge capture and billing has been historically a really thorny pain in the side of many clinicians and healthcare providers. We, at some point in our institutional history found that our vendor product just wasn't delivering you've heard stories of other organizations losing out on significant amount of revenue, just because of inability to adequately document and bill and charge for the services and products that they were delivering. So we have a custom application for that. Things like surgical scheduling. And it's kinda, it's kinda funny cause when I talk about these things, they sound really core functionality for healthcare enterprise.

And so when you talk about really delving into these niche areas, there's so much room to disruptively innovate in those spaces, but in terms of the impact across you know getting your maximum juice out of your squeeze. It really is this processes that people are doing day in and day out.

Like people are billing for things. People are admitting people to the hospital, they're doing procedures. And if the processes there aren't, they don't have a good user experience or the human factors are so bad that people are doing the wrong bank consistently. I think those have been historically, at least identified as the highest need areas. I think vendors are catching up. So then we're going to start to see, and we are, have already seen a lot of work into more niche things like smart on FHIR apps, where you can calculate a in the pediatric space, I don't know how relevant this will be to our adult medicine listeners calculating Billy Reuben and matching that against the nomogram for newborns on what is a dangerous level for Billy Reuben. In these kinds of things that take a lot of cognitive energy and time, but computers can do really well.

And so what level of involvement do you have with the app development? Are you writing the code yourself or are you kind of guiding the programmers?

Thankfully I'm not writing the code myself. That might have disastrous consequences. Especially I think in the, in the fellow role it's interesting. We tend to have more transitory presence in an institution. It's not necessarily a guarantee that we'll be here in two or three years. And when app issues may present themselves down the line, I think just from a wisdom or street smart standpoint, it may be better to keep people around who know the institution, know all the different apps or processes that your app will touch and be affected by when changes to your code are needed. And I think that in itself, on top of the actual software development coding expertise per se takes a lot of kind of institutional memory and time to be able to develop.

I think the role that I played that was, I wished that I could have been earlier and more agile and to have more touch points in the process is to just help with the human factors, help with the, the clinical side of the end user experience. Thinking about like when, when you design an app, wanting a box in a different place or wanting the ability to bold something or underline something. Those seem like really trivial things to us in this day and age, when there's really a lot of talent and effort poured into software development design, but when you have kind of more limited teams and you have therefore also constraints on your time and your ability to have a fully featured application just thinking about which are the features are really critical and may actually impact quality and safety. I think it's hard for the IT teams to necessarily understand that. I think this is why Agile processes, maybe being adopted more so than a waterfall type process.

When I came in more toward the end of the project, after a lot of the development have been done, it is unless it's a really game stopping showstopping issue in the code. At that point, it's really hard to get a change made. Cause maybe they poured a hundred hours into, into that app and changing something like the size of, the size of the box might not be as trivial as you think it is when it exists in multiple different places. I I'm I'm sure someone would actual development expertise is laughing at that comment, cause it actually is trivial, but hopefully people can understand what I'm getting at.

Just as a tangible example You may not think that deciding what data you are and your field can store. For instance, like the Unicode or can your field actually capture and store special characters. Like the other language characters. We realized at some point during the project that we couldn't code with the end users input Spanish characters. So the difference between some, some words is trivial, but maybe like no and unusual to mean I don't know what kind of PG level of audience or talking, but you know, a little squiggle on top of the end can mean the difference between a year and anus. So maybe, maybe a medics and that might have somewhat of a impact on how someone interprets instructions for their clinical care.

And so you can imagine if you could have put that in the project requirements much earlier than different decisions would have been made, or just like an entirely different approach toward software development might have been taken.

Those are good points. With any of these apps and within any of these projects a large amount of maintenance and time is going to have to be put into making sure that you can keep up with the requests that will come in from users for adding different languages, things of that nature. And you gotta have the internal skillset available to, to handle those requests, which may be difficult for a place that's maybe outside of an academic medical center to do. I would expect.

That's exactly right. Yeah. I would be so interested, we spoke a little bit about the preventive medicine like nature of pediatrics, but also in informatics.

How much of our processes, time and resources could we potentiate by intervening a little bit earlier and more integrating the clinical experts or domain subject matter experts? With the it teams to try to multiply what they do instead of rushing to get a minimum viable product out there that ends up taking a lot more time in the backend to, to retweak and to fulfill what features that probably the clinician would have wanted in the very beginning. If there were a little bit more of an iterative agile process for letting those be known.

Well, Peter it's been great chatting with you. I think you've provided a lot of valuable insights. Any final words for the audience before we let you go.

I think on each side of the aisle is the clinicians who are busy, the developers who are busy. And I have worked on many projects where there's just a lot of inefficiency in the process on getting the clinical teams to be able to express what's important. And then the IT and data teams to be able to tell the clinical folks how to actually translate their request into database structure and SQL queries and joins to figure out how a data set is going to be formatted. I've encountered so many lovely people on both sides of the aisle who just want to learn and I'll just encourage folks to not feel worried about engaging people.

I think during the pandemic, it's been simultaneously challenging to have those kind of touch bases with folks and to build rapport with teams that kind of facilitate kind of energy and collegiality to move projects forward. But I think at the same time I've met so many different people I probably wouldn't have met otherwise, just because you can hop on a Zoom for like five or 10 minutes and save yourself what writing a 15 minute, two page email on exactly what you need and why you're frustrated with the product.

Yeah, all very good points. Well, well, thanks again for joining the program and wish you well with your career post fellowship.

I love this show. I love hearing from people on the front lines. I love hearing from these leaders and we want to thank our hosts who continue to support the community by developing this great content. We also want to thank our show sponsors Olive, Rubrik, Trellix, Hillrom, Medigate and F5 in partnership with Sirius Healthcare for investing in our mission to develop the next generation of health leaders. If you want to support the show, let someone know about our shows. They all start with This Week Health and you can find them wherever you listen to podcasts. Keynote, TownHall, 📍 Newsroom and Academy. Check them out today. And thanks for listening. That's all for now.