One of the hottest jobs in Healthcare IT for several years now has been the Clinical Application Specialist or Clinical Application Analyst. When a Healthcare IT vendor signs a contract to implement a given system for a Healthcare network, they rely on their client’s Clinical Application Specialist to plan, implement, and support clinical software systems. There are a few variations on the title, but for the rest of this article, I’ll stick mostly with “Application Analyst“.
Clinical Application Specialist Role
The title itself can sound intimidating, as if you need to be a nurse and a programmer. That’s not really the case most of the time. Let’s walk through some of the tasks that a Clinical Analyst would do in an organization, starting from the beginning of a project.
We’ll assume our organization is looking for a new Electronic Health Record, and needs to evaluate several options. Then the Application Analyst perform their role all the way through implementation and support.
Let’s go…
Software Evaluation
An organization will usually start with a Project Charter to begin the selection of a new software package. The Charter will usually be authored by an IT executive, a Project Manager, and someone from leadership of the team who will actually use the product. The charter will have clear objectives for what the organization needs in the new software. Here are some examples:
- The selected system must be an integrated health record that can be used by Inpatient, Outpatient, and Specialty clinicians
- Must have a Windows client interface that is well-received by physicians, medical assistants, techs, and other users
- Must scale to an organization that has 1,000 active users
- Must have enough configuration options to support the various clinical workflows
- Must be able to send patient demographic data to external systems via HL7 Interfaces
The Clinical Analyst will participate in evaluation sessions to evaluate the initial list of software vendors. They will get the vendors to show actual workflows with real data, not just screen shots or mock-ups of what the software can do. The Clinical Analyst should look at vendor demo systems with a very critical eye, and bring in representatives from the clinic community to help with evaluations.
Your clinical representatives are one of the biggest assets you have as an IT Analyst. Build solid relationships with them, and have your organization pick some to be your Subject Matter Experts (SMEs).
Clinical Workflow Analysis
Clinical workflow analysis involves the careful assessment of how various functions are done in clinical settings, specifically relating to the use of software. You should begin your workflow analysis before selecting the software, and this should continue throughout the early parts of the implementation. You do workflow analysis by observing all the steps within a function, such as an office visit. You ask questions at every step and document processes from start to finish. This documentation becomes the foundation for how the rest of a project will proceed.
There is a constant battle in Healthcare IT between existing workflows and the workflow changes that software sometimes forces on users. You just have to work with your clinicians to get through these changes as they come. All sides have to be flexible, and always watch for “hard stops”. A hard stop is an impasse that can reveal problems early on, and may even eliminate a given software vendor from consideration.
Healthcare Software Implementation
The Application Analyst is the key participant in the nuts-and-bolts of rolling out a clinical software solution. Once a vendor has been selected and workflow analysis has been done, the Application Analyst will visit the department or clinic site again to gather lots of data that will be used to configure the software options and settings. Some of these tasks may be assisted by a Healthcare IT Project Manager:
- List of users of the application and their roles (Physician, Medical Assistant, Radiology Tech, etc)
- List of computer workstations, noting variations of operating system versions and models
- List of printers and their proximity to the workstations (don’t forget specialty printers like for labels)
- Peripheral devices such as scanners and bar code readers
The Application Analyst should also consider any other medical devices such as blood pressure monitors. Depending on what software is being implemented, there may be integration or interfaces with these devices so that the data from them flows to the software you are implementing. Some of these points should have been brought up during your workflow analysis.
Software Configuration
This is the part of the project where you do many of the core tasks that define the Application Analyst role. You will likely have gotten training on the specific system. If it’s our EHR example, you probably did quite a bit of studying and had to pass an exam to be certified in the software. Here are some examples of the configuration work done by the Application Analyst:
- Set up user accounts according to the job roles they have. There are many security options to consider. A Medical Assistant obviously can’t do all the things that a Physician can, such as signing orders
- Analyze and configure the types of orders that are done more frequently in the medical office. If it’s a family practice, there will be common labs, X-rays, and a host of other orders that need to be called out
- Depending on the software, there will probably be many options for how the User Interface (UI) will look to the users. They may want certain buttons or selections for orders to be here or there on the screen; and there may be a host of other options to configure
- Printer configurations from your site visit will need to be built. The staff checking in the patients won’t have the same printers as the physicians in the back who print prescriptions
I can’t possibly list everything that the Application Analyst would do here, but this should give you a decent view of what goes on.
Healthcare Software Testing
Next, you will likely take a leading role in testing the configuration and build that was done in response to your users’ requirements. I’m assuming your organization does not have a dedicated QA Analyst, although most larger IT departments do. You will work with your Project Manager and staff from your clinical users to schedule testing events.Levels of Software Testing
Here we will briefly cover the various levels of software testing that you will perform in this phase of the project. Future posts will get into more detail on software testing approaches. For each testing phase, you will usually need to get sign-off by your Subject Matter Expert (SME). The testing events will be supported by written test scripts that you put together with assistance from your SME and Project Manager.
Functional Testing
In functional testing, you perform basic steps in the application to make sure nothing is fundamentally broken. You don’t yet look at data that may flow into or out of the system being tested. In the case of our EHR, you would probably test the check-in of patients, and basic functionality of documentation in the EHR.
Integrated Testing
In the integrated testing phase, you have the tester(s) start with the same tasks as in functional testing. They may then add additional steps that involve data that goes to other systems, such as external billing. Also, here is where you would test the workflow of any medical devices being used with the EHR, such as digital blood pressure monitors. You will work with Interface Analysts and Analysts from other software systems to verify the successful transmission of data or messages to those systems.
Software Problem Tracking and Fixes
After testing, you will likely have found errors in the configuration or design limitations or bugs in the software product. The Application Analyst will then log these changes, then fix whatever can be fixed in the IT department or work with the vendor to get software patches delivered.
Regression Testing
For any configuration or software changes that are delivered, you will then need to so some basic regression testing, which is intended to go back to make sure your “fix” didn’t break something else. You usually won’t test everything that was done in the first round of testing- just whatever functions pertain to the problem that was found. It’s important to know that you could test forever; but at some point you have to get your software live!
There may be other levels of testing, including a testing dress rehearsal where you will test some of the functions in the location where the product will be used. However, this is not an article completely on testing. I’m trying to give you an overall view of the many roles of an Application Analyst.
User Training
Depending on the size of your project and organization, you as the Application Analyst will either work with one or more trainers to get users trained, or will do the training yourself. If it’s our EHR product, you will probably have at least one trainer who will work with you. It’s a good idea to keep your trainer involved from early in the project, and it’s great to have them also help with the testing.
Ready To Launch
You’re finally ready to go live with your software. This is where the Application Analyst will work with your Project Manager, department leaders, SMEs and others to be ready. An activation date has been announced well in advance, and communication has gone out far and wide. Here are some of the things you will need to consider for activation:- How many support staff will be needed, and what will be the hours of support?
- How much on-site support will you provide, vs over the phone?
- Do you have the right backup IT staff to help with PC issues, network issues, and printer problems?
- Are your SMEs ready to provide basic support for their co-workers, instead of calling you for simple issues?
Software Project Lessons Learned
Finally after the dust has settled, you will work with your Project Manager to review the ups and downs of your project. You will need to reach out to your users to get their input on what went well, and what could have gone better. Log these issues in a place where you can refer to them on your next project. Usually, the lessons learned will be at least a couple of months after the activation.
True story: I was a key player in the roll out of an EMR, and the conclusion of our lessons learned meeting was that we needed to pick another vendor. And off we went…again.
Clinical Application Support
Depending on your organization, you may be only an implementation analyst or a support analyst. If you don’t move on to another implementation project, you might now transition into a support role where you provide ongoing advice on the software, as well as planning upgrades, and adding additional features and optimization to the product.
Clinical Application Specialist Salary
Of course we all know that salaries will vary greatly by national region. This job won’t pay the same in Mississippi as it does in California or New York. But if you’re looking for some ballpark figures, the salary for a Clinical Application Specialist might be in the $65k/year range on the low end. That would be either in a lower pay area, or for someone with not much experience. Then on the high end, if you have someone with lots of experience and vendor certification, the job could easily be in the $70-80k/year range. On the West Coast or Northeast US, it could then hit the $100k/year range. Here is a link with more on Healthcare IT Salaries.
Next Up: Learn about Healthcare IT Project Management Teams
Read More
