Congratulations! It’s been something that you’ve been planning for a long time, but when you get the news, it’s still a shock. It’s actually happening. Cue the tidal wave of intense emotions. Excitement, fear, optimism: everything is about to change.
Of course, we’re talking about when you make your first integrated sale to a major health system. Don’t worry though, people have been doing this for years. And with a little help from Redox–your integration midwife–things just got a whole lot easier.
Working with IT teams
You probably got this far (contract signed) because you have a strong internal champion, e.g. an influential clinician, someone with title of VP or CxO, etc. However, health systems don’t tend to function like the military where an order makes it all the way through the ranks. Expect a few more hurdles.
At most health systems, the strategic priorities are established by one or many governance groups. You should have clear messages around your ROI so that your champion can strongly lobby your cause to these groups. Once our project is prioritized, the IT team gets to decide how many projects they are able to take on at a time. And the strategic eyes are ALWAYS bigger than the IT stomachs. You may be at the top of the list, but the IT team is probably already fully committed to current projects. FIFO. No need to play your ROI cards on these guys because very little of it gets back to the specific IT analyst or engineer that are going to make your dreams come true.
What to do:
- Shrink your kickoff scope as much as possible. Small projects get traction exponentially faster than larger projects, and it’s not as hard as you think to go back and expand the scope gradually. Moral of the story? Get your foot in the door with a product that can grow. Like the baby in the (moderately successful?) theme of this post.
- Bring your Redox Implementation Lead to the table early and often. (We don’t charge hourly to incentivize this!) The last thing the IT folks want to do is educate your tech team on what to do and how to do it. As part of your Redox pre-production account, we’ll jump on calls and be your experts on how to move forward as seamlessly as possible.
Getting connected
Time to get your own house in order. Get connected with Redox and get some test messages filing successfully. It’s a major red flag to the health system if they start sending you messages and you can’t conclusively say whether the test was successful. Conversely, if you committed to send information back into the health system, better have that function ready when the health system is ready to receive it. The most valuable currency at this stage of the project is MOMENTUM, and nothing kills momentum faster than the health system IT team perceiving that you’re not ready to dance when the music starts. IT team attention has a very short shelf life, and you’ll be starting over if you miss the window. Be ready.
Security reviews
Before establishing a VPN connection, the health system is going to do a security review to make sure the PHI that they are trusting to you (and us) is always safe and secure. These security reviews are often large spreadsheets with questions about everything from encryption protocols to security policies. Your Redox Implementation Lead has seen dozens of these and can help you fill it out. Who reviews it? Usually another governance committee made up of network security, data governance, compliance, and legal. And that means it’ll probably not be a “one and done” exercise. Expect to go back and forth. The process can go as fast as a week or take as long as a few months, but most health systems can complete the security review in 2-4 weeks if we get the answers right the first time.
VPN connectivity
The VPN connection is a major milestone for our project. The VPN is essentially an open gate in the firewall where data can leave and enter as long as it has very specific authentication on each message. The health system and Redox team will exchange their respective specifications and then we jump on the phone (can’t do it over email) to exchange the secure keys/tokens. Don’t be offended if you’re not invited to that phone call, some health systems only allow the Redox network team to listen in since these secure tokens are kept under cyber lock and key. Note that this may be the only time that you or Redox will interact with the network team, sometimes referred to as the “perimeter team” since they secure the perimeter of the health system’s data. The network team tends to get pulled in at the last minute and usually aren’t given a ton of context, so it’s common for balls to get dropped here. Be patient. The connectivity call may include several failed attempts to get a “ping” out and back. Don’t stress. And the first few times that we use that VPN channel, there might be issues. That’s common too. The Redox team will own any/all VPN issues for you as things settle down.
What if Redox already has a VPN tunnel established with the health system? Then we can skip this step for you. All data for all Redox applications will flow through the same VPN tunnel.
Subscriptions
In order for the health system to send or receive data, they need to connect the specific data feed to Redox. Think of the VPN as the conduit, you still have to run the wires, which are different for patient administration (ADT), scheduling (SIU), media (MDM), and our other data models. When the health system network team finishes, they pass the baton to the integration/interface team at the health system. The interface team will enable the correct feeds from the test environment of the EHR. The interface team will want to know what the high-level workflow of your product is so that they can turn on all of the messages that are relevant. As you describe the workflow, the Redox team will translate into “interface-ese” where a new appointment=S12 and a patient update=A31. Don’t worry about memorizing the buzzword bingo, but be sure you have a clear workflow documented. It’s common to need 2-3 working sessions with health system analyst, health system interface team, Redox and you on the phone sending each message for the first time and noting any issues. Issues at this point tend to be small, but usually need time outside of the call to resolve, so we try to schedule the next call as we end the current one. Interface teams don’t have to modify the message formats in order for Redox to receive them, so the issues are usually around enabling certain messages or filtering feeds so we don’t get more than what you’re approved to receive.
Connectivity is considered complete when you and a non-interface analyst at the health system can walk through the workflow together and the data flows from the health system into your application/product without any issue.
What to do:
Have clear workflows documented so that all of the disparate teams that are involved with connectivity are on the same page.
- Start a weekly touch base with the Redox team. Whether it’s hammering out the security review of staying current on the state of the VPN connection, it’s important to talk often.
- Be patient. If you haven’t been through a health system VPN onboarding process, bumps in the road are common, but we’ll get through it.
Testing the workflows
We’re back to familiar territory here. For this phase, you and the health system analysts run through the workflow scenarios as many times as it takes to assure you and them that the systems are going to interact correctly. Redox is available and willing to join as many of these sessions are you invite us to, but it’s not necessary. We’ll constantly be monitoring any errors or unexpected outcomes from the messages that you exchange as part of testing and will reach out when necessary.
What to do:
- Make sure your application is ready to receive and send data (if applicable). Testing should mirror the live experience for both the health system and your product, so make sure you’re ready to say “yes, that message got all the way to our application and things look good”.
- Be thorough. The health system likely has some basic testing scripts that we can use as a starting point, but try to think of all of the variations at each of these workflow phases:
- Starting – what are all of the ways that a user/patient can initiate a workflow with your product? For example: Patient shows up unannounced, user accesses the website, you receive an order for XYZ for a patient in ABC department, etc.
- Middle – what are all of the different tasks and transitions that can happen in the workflow? For example: patient gets transferred, patient skips some questionnaire fields, user quits half way through, etc.
- Ending – what are all of the terminal events for your workflow? Patient cancels the appointment, payment gets submitted via a family member instead of the patient, the PDF gets sent to the EHR, etc.
Going live at a health system
The big day is here. And you’re ready already. Your delivery care team (Redox and the health system interface team) is on standby, ready to react to any issues, but it’s really you and your users that are the main characters in this act of the play. To make sure that this and all future days are successful, we need to make sure that a few key things are in place.
For most EHRs, the production instance of the EHR is physically separate from the test instance of the EHR (like different boxes in the same basement of the hospital) so the analyst/interface team will need “sync” up any changes that they made during testing into the production environment. You might hear works like “migrate” or “courier” to describe the tools that the EHRs provide to make that happen.
Just because something worked in testing, doesn’t mean it’s going to work in production, and a major percentage of go-live issues are caused by inconstancies in workflows and technical setup between the testing and production environments. Some health systems don’t (officially) maintain test patients in production, others have policies that prevent test data from entering the production environment. Expect that each health system is going to have a slightly different model and threshold for production testing, but always insist that production testing gets done. Push the data as far as the health system will allow it to be pushed.
Redox will work with the interface team at the health system to make sure that they are ready to exchange production messages. For outbound (health system —> Redox), we’ll start listening to those messages a few days ahead of when you are scheduled to start receiving them so that we can triage any discrepancies with production. We call this a “soft go-live” because the systems are live but it may be slightly before the public go-live event.
And then it just happens. The moment for which you’ve been preparing for months or years just happens. We all watch everything very closely for the first few days to make sure there aren’t any surprises, but it’s common for things to settle down in 24-48 hours. You may discover some enhancements/changes that you need to make to improve the workflow. We’ll keep a close dialogue with the health system teams to discuss those modifications. At that point, we can make ongoing iterative changes.
What to do:
- Make sure your training plan is in place and communicated well in advance. This is the most common reason to delay a go-live and is easy to forget if we’re stuck in “technical install” land. Get early buy-in from the health system users and plan accordingly.
- Don’t make big application updates at the same time. If we’re going live with a health system on Monday, please don’t release a re-write of your entire code base on Sunday night. It never goes as smoothly as you hope, and we recommend that you not gamble with the “health system credibility” chip on the table. If a major release is go-live critical, plan accordingly.
- Respect the governance. Health systems are burdened by trying to keep dozens of systems and hundreds of people coordinated with an endless stream of software updates and patches. Your health system counterparts are bound by very strict processes when making changes to production. Expect to hear the words “after hours”, “blackout windows”, and “downtimes” as they try to figure out when to make our changes. A 10 minute change might not be able to take place until next Tuesday.
The first few months
Within Redox, we are going to always maintain a staging connection and a production connection. Most health systems will appreciate having these separate, and hopefully your product can accommodate having these two connections live simultaneously, but even if you can’t, Redox will continue to listen to the pre-production feed. Why? It’s the best indicator of when the health system is going to change their feed and what those changes are. For example, say that you’ve been live for a year and the health system is planning to upgrade to a new version of Epic or convert to the latest Cerner offering. As the organization prepares for that transition (that you and Redox are blissfully unaware of), they will likely update the pre-production feed and we will start seeing errors which will notify us to have a conversation with the health system about how the production feed might eventually change as well.
When people think of healthcare, they rarely think of the nuts and bolts of getting the right tool into the hands of the patient and providers. But that’s the point. Redox is committed to making this process as simple and streamlined as possible for you and your team so that you can focus on what you do best – creating the next generation of game-changing tools. Contact us if you have a lesson learned that you want to make sure others start expecting or when it’s time for you to deliver your beautiful bundle of joy into the world of health systems.
Stay in the know! Subscribe to our newsletter.
Related Posts
Study: What providers want from tech vendors in 2023-2024
A health technology vendor can deliver a pitch deck that’s as meaty as they come. But to a…
