Service, Systems, and Setting the Path to Military Health Record Modernization

PJ Kennedy

As Chief Engineer for the Leidos Partnership for Defense Health, PJ Kennedy not only leads the engineering function for the team, he also shapes the direction of the entire systems engineering lifecycle, managing a diverse team of technical experts responsible for delivering the integrated, secure MHS GENESIS system for active duty military, Veterans and their families.

A few weeks before Wave TRAVIS Go-Live, we met to talk about the extensive scope of PJ’s responsibilities— from the daily pressures of responding to critical “hot button” issues, to planning long-term systems engineering strategies, and how family, greyhounds and ice hockey bring balance to a dynamic life.

You’ve had a variety of roles during the six years you’ve been a part of the LPDH team – Chief Engineer, Solutions Architect, Segment 2 lead. What are your primary responsibilities as Chief Engineer?

I’m the primary technical point of contact for the government. So from a customer perspective, if they have a demanding technical question they come find me. And as a result, I’m spending a lot of my time in Rosslyn right now.

From a chief engineering perspective, what we have here is a system of systems, which requires us to evaluate how things interact with each other, both internal and external. That includes all the functional areas — systems engineering and integration, engineering, test and evaluation, deployment, adoption, training and sustainment.

I provide governance and often act as a dispute resolver across the functional areas, ensuring that all seven layers in the lifecycle (Systems engineering & Integration, Engineering, Test & Evaluation, Deployment, Adoption, Training, and Sustainment) flow appropriately. I don’t micromanage people, but I set a goal or path that we want to go down, and at the same time give people the ability to do their job.

When we have a hot item from the customer, I bring together a couple of senior architects, a couple of deployment people, whoever I need in the room to work those tasks to completion. The hard part is when you have more than one of those high visibility issues going on at one time.

What are some of the latest technical challenges you are working to resolve right now?    

The modernization we are undertaking requires us to share one instance of our system with DoD and VA.  That means that all of the data for active duty military and for Veterans will be in the same place.

This requires a long-term strategy to ensure that one department implementing a capability doesn’t break or change what the other department needs to happen in that instance.

Cardiology is a prime example of that planning. A hospital serving Veterans and a DoD hospital serving active duty military, typically with fewer heart problems, have different needs because of these different populations.

We’ve been working to determine how to implement all of the cardiology modules and the associated technical components that the VA requires without impacting our existing DoD functional workflows and technical stack.  We don’t want to impede providers from using the system as it was expected to be used. In this case, we are architecting and engineering a solution that mitigates risk and currently implementing a new cardiovascular interface for the DoD to support its legacy workflows.

Or, another example would be when a new device is brought on by the DoD that the VA doesn’t use, and we need to figure out how to implement it without impacting the other entity.  You’ve got to think about the big picture when you’re designing or developing a single component within this system.

What led you to a career in systems engineering? What do you find most challenging and most rewarding about your work on the DHMSM program?

I was a biomedical engineer in undergrad enrolled in pre-med coursework. But I didn’t want to be a doctor.  I wanted to build, design, and develop the machines in hospitals – MRI’s, CAT Scans. That degree helped me to understand the medicine behind the machines and the doctors’ and nurses’ perspective.

While working for Leidos (formerly SAIC), I was given the opportunity to participate in the Masters’ degree program for Systems Engineering Management. Participating with small cohorts of people from the company helped me focus on the skills required to think from a systems perspective and understand how to evaluate the multiple components of a system and exactly how all the pieces interact.  I think the combination of those two degrees has given me a well-rounded perspective to understand more about some of the challenges providers and clinicians are facing.

Making good technical decisions with a rationale behind them takes time. To be completely honest, the pace of this program is challenging.

You need to dig in, make sure you have the right answers and have done all your homework. So being an analytical fact-finder and doing that in a short timeframe is very challenging, especially when there are five or ten of those decisions stacked up in a week.

The most rewarding part is that I am doing this for the active duty military. I was never in the military and people ask me where my haircut comes from if I was never active duty. And I keep telling them I was related to half the Chicago police force when I was growing up. So I didn’t have military, but I had police presence. I have a vast array of friends, a few cousins now, that are all military. And this is my way of giving back.

How has the LPDH matured since the initial days of the program and what milestones and process changes have you observed from an engineering perspective?

We have listened and learned a lot.  I think we’ve evolved in the area of release planning. What we didn’t have during the Initial Operational Capability (IOC) sites was an understanding of how we would iterate processes and keep things up-to-date. So the ability to adopt a pattern or cadence that evolves into monthly or quarterly solution updates for a particular item is an improvement. And we are moving toward a block release process that will tell us what the next 6, 12, 18 months looks like. We’ll be able to be proactive and share that information with the community and our customers.

As we talk, we are approximately 29 days from Wave TRAVIS Go-Live.  How do you and the team need to execute to ensure that Travis and subsequent deployments are successful?

At this stage in the game we have a lot of Adoption and Training activities happening related to Change Management, providing hands-on support to the people at the sites.

We are in coordination with the people at the sites and we have a set of engineering resources for site rollout.  We’ve revised the task checklist from the IOC, which is about a couple of thousand lines long, to match what’s happening at Travis and the ancillary clinics.  Other things include making sure all the devices are hooked up appropriately and have their network connections.  But largely that roll-out checklist is the primary way of ensuring all our engineering needs for our wave deployment are met. We’ll also have feedback from the team at the site.