5 Rules to Successfully Analyze Certification Based Healthcare Projects
They are simpler than you think!
I have had the pain and pleasure of leading requirements analysis for some of my career's most complex healthcare IT projects. These projects ran well over 6 to 9 months and required the utmost focus, patience and dedication to finish the job. It involved talking to the certifying bodies, IT vendors and occasionally the Department Of Health and the DEA. I was scavenging the internet for any information I could gather on these projects to help me understand the mesh. There were numerous sleepless nights and breathless days, full of anxiety and stress; and full of accomplishments and relief.
The Affordable Care Act (also known as Obamacare) ushered in an era of increased government spending on Healthcare IT and product certifications. As a vendor, we also needed to certify our product for the Meaningful Use initiative. Under the MU umbrella, I had to gather requirements around and design workflows for projects like CCDA, the Immunization Project, The DIRECT Project, and most important - Electronic Prescription of Controlled Substances or the EPCS Project. If Healthcare IT was Jurassic Park, EPCS was T-Rex. All the projects had their own set of requirements, multiple upstream and downstream dependencies, and workflow requirements that needed to fit into an already existing application that physicians use daily. Having made sense of everything eventually and successfully getting multiple projects certified, I believe the key steps below will help an analyst conquer any certification-based healthcare IT project.
1. Be Minimalistic
As an analyst, our moral obligation is to have a defined strategy. This strategy should be all-encompassing. You must first understand your entire application well to identify the areas of the application that get impacted by your current project. You must have a minimal viable product defined to give you the best usability and get you through the certification. You would want a happy certifying body and happy users of your software.
The analyst must research on :
What is the problem we are trying to solve?
What are the certification test requirements, and how much of those apply to your product?
What are the upstream and downstream dependencies for this project?
Are there any certification waivers that apply to your product because you don't offer certain features/ functionality? Etc.
2. Get heads-down analysis time!
If you work in an Agile environment like I do, you would probably agree with me that it is very important but challenging to keep a good backlog of stories ready for the team to work on continuously. You constantly support the team who delivers every sprint. As a result, you often get pulled into multiple directions and are not focused. Don't do it. Talk to your managers. Get some heads down time and analyse. Chances are you will go nowhere with it and will not understand much. But if you are persistent, this changes quickly and suddenly, you find yourself connecting the dots. Yep - The Tipping Point!
3. Whiteboard, throw stones at the design and discuss
More often than not, when everything else fails, whiteboarding comes to the rescue. I would highly encourage an analyst to do otherwise. Once you're done with the analysis and have a good set of requirements and design - start with a white-boarding session. Discuss with technical leads, architects and any other stakeholders that might be of value to the project. I've noticed that most of the time, the fastest way to get to a solution is by crowd-sourcing the problem. You will be pleasantly surprised to notice how much good comes from this.
4. Don't Assume ...... Ask (Certifying Bodies are Angels !)
This is a very crucial step that most analysts never make use of. Once you finalize the certifying body, you get their full support to answer any questions you might have about the project. Their websites have highly defined content around certification needs. This includes videos, FAQs, and what have you. Your proctor - who will eventually certify you - will always be available by email and might jump on a phone conversation if needed.
There have been numerous times when I was considering two design options. Option 1 required more effort, and Option 2 was easier and less work. I was unsure if Option 2 would have sufficed, so I sent very simple emails to my proctor explaining both options. Option 2 worked most of the time. This ensured we followed the regulations and saved some dollars as an IT company. Certifying bodies are our partners and are really there to help us. You need to ask.
5. Utilize Delta Certifications (And Mock Certifications)
More often than not, certifying bodies have Delta Certifications, which are part certifications adding up to one big final certification. This is a useful model to follow when projects get as big as EPCS. Other times you as a company can have an internal team that runs mock certifications, thus preparing you better for D-Day.
Projects like EPCS have many moving parts to them, and the sooner you get a big picture, the easier it is to manage the project successfully. So start with measuring it. As someone rightly said - If you can't measure it, you can't manage it.
I was recently sitting in a war room with 12 other people on the team that was going to get us through Meaningful Use Stage 2 certification. And so we did. We got us certified on multiple projects successfully!
Are you a product owner working in the Healthcare IT space? Did you face similar challenges getting your products certified? I would love to hear from you in the comments section!!