It’s one thing to get education and certification for a job in Healthcare IT, but the real skills come when you show that you can configure clinical software for your users. There’s no better way to learn these skills than the process of bringing up a new department or location from scratch.
I’m going to walk you through just about everything you need to consider when you get the go-ahead to bring up a new department. Let’s go with the assumption that our department is a primary care or specialty clinic that sees patients during normal hours and has physicians, RNs, medical assistants, and scheduling staff.
Department Demographics
One of the first places to start in building a new department is the basic information on its physical location and clinical structure. Regardless of what clinical software is being implemented, here is some of the information you will need to have when creating the new department:
- Legal department name and department number
- Name as it should appear on external facing communications, such as faxes
- Address, phone numbers, and fax numbers
- Billing cost center code
- Specialty description
- Any State or Federal license numbers
Department Workflow Analysis
This is where things can get more difficult as you learn the details about how the department’s many functions are done, either in an existing software system, or manually with paper records. You will need to gather copies of all paper forms used by the clinic. Here are some examples:
- Forms used to document patient history and progress notes
- New patient intake forms
- Forms used to place orders
- Release of information forms
- Return to work/school forms
- Changes of insurance
These forms will all need to be turned into electronic processes and workflows in the new system. You will almost certainly get lots of help from your vendor’s implementation staff.
Then you will likely need to diagram out some of the clinic workflows on a whiteboard or Visio document to help you understand what needs to be built-in your new system. Translating workflows into what is actually built-in a software system is a big part of what Healthcare IT analysts do. You get better with practice and with every new department that you implement.
Data Conversions or Other Chart History
If you are implementing a system in a department that is already operational, then there will be existing clinical records that were recorded before this project. Those records are still legally and clinically viable, and Federal law requires that they are kept. If the data exists in another electronic form, then you may need to bring in a conversion analyst who can get that historical data imported into the new records system. Because every data conversion project is different, there will be significant effort toward analyzing the historical data to figure out how it will be imported. It is really important to start looking at this at the beginning of the project.
If your old data is just on paper, then you will likely have the data scanned into the new system. Just be sure to let the department or clinic manager know that they will need to provide staff to do this, beginning a few weeks before the go-live. The amount of historical chart data that is on-hand will determine how long it takes to finish.
Hardware Usage – PCs, Printers, Mobile Devices, Scanners
Early in the implementation, you will need to determine all of the electronic hardware that is being used in the clinic. This part may be done at or near the same time as the workflow analysis as you observe how clinicians use PCs or devices in the course of patient interactions. Here are some things you’ll need to consider:
- Does the building have nursing stations with PCs?
- Will there be traditional PCs in the exam rooms? Laptops? Tablets?
- Will you use workstations on wheels (WOWs)?
- How will users log into the system? User ID/password every time, or badge reader?
- How will scanning of paper records be done?
The Patient Experience
A very common patient complaint these days is that the physician spends more time poking at his/her computer than interacting with the patient. A lot of this can be helped by the placement of the hardware and furniture in the exam rooms. You’ll want to have the monitor at the same height of the patient’s head while sitting, and at a midway point between the clinician and patient.
Device Integration
Most clinical departments have at least some medical devices. They may be as simple as blood pressure readers, EKG units, and glucose meters; or more complex like ultrasound units and cameras that take photos of the inside of patients’ eyes. When a clinical department first goes live on an EHR system, they usually start by entering device data manually into the new system, and later look into an interface that brings in the data into the new system. Either way, you will need to discuss this up front with your users so they know what to expect.
Interfaces to Other Systems
If your clinic is of any significant size or scope, there will probably be data that is sent to other electronic systems. A few examples that you could see are:
- External labs such as LabCorp
- Automated medication or supply dispensing systems like Omnicell or Pyxis
- Medical supply systems
- Billing software
- Staff management systems such as Lawson
Any of these may exchange data with the software you are implementing. There are analysts who work strictly with Healthcare IT interfaces who would be brought in to manage this part of the project.
Network Infrastructure
Working on the network configuration of your location will apply if it is a new move-in or new construction. In that case, a project manager or office manager would probably work with a networking team to run cables, set up routers and switches, and put up wireless access points. An application analyst probably won’t get into this part, but someone needs to have it on their radar.
User Permissions, Roles, and Security
Here is where we consider the roles of everyone who will be using the new software. For example, a Medical Assistant won’t have the same features and functions as an RN, and an RN won’t do some of what a physician does. Here are some of the questions to ask when considering the roles and security levels of your users:
- Who will have access to all parts of the electronic record?
- What will be the default view that users will have when they log on?
- Who will be able to scan documents into the chart that come from outside sources?
Orders and Results
Any clinical department will have procedures and lab orders that are sent out to an external lab for results, and other tests that are routinely ordered and/or performed in the clinic. Here are some of the things you will need to know when building orders for your clinic:
- What are the common orders that are placed by the clinic?
- What has access to sign orders?
- Are there orders that need to be co-signed?
- Do non-physician clinicians need to be able to enter orders that are then signed by the physicians?
- Are there any protocol orders?
- Are all orders sent out to an external lab, or are some resulted in the clinic?
Scheduling
To build out the scheduling portion of the software, you’ll need to get a list of everyone and everything that can be scheduled. By “thing”, I mean that appointments are not only scheduled with doctors, but also with clinical equipment, like an MRI machine or a procedure room. Once you have all of your schedulable entities, you will build scheduling slots or templates to make hours and days of the week available for booking appointments. You will also probably need to get a list of all the rooms that your clinic has. The rooms will be used to show the status of the rooms, such as empty, patient in room, ready for physician, ready for check-out, and ready for cleaning. Consider that non-clinical staff such as environmental services may need access in the system so they know which rooms are next up for cleaning.
You also may need to consider if your department will have any self-service check-in kiosks or PCs that patients use to start the registration process. This part of the project may involve changes in the building to accommodate the check-in devices.
Electronic Prescribing
Almost all physicians use electronic prescribing of medications these days. If you are implementing a system for e-prescribing, you will need to have physicians’ credentials in a spreadsheet that gets sent to the e-prescribing vendor (most likely Surescripts). They will probably need the info a few weeks before your activation. You will need to provide:
- Full provider legal name
- NPI number
- Full street address of the clinic
- Fax number
- Previous e-prescribing ID numbers from other organizations, if applicable
Part of your testing will involve sending sample electronic prescriptions to the e-prescribing vendor before going live.
Electronic Faxing
Your clinic will probably have a standard fax machine for sending out hard copies of documents, but should also have an e-fax vendor such as RightFax. This makes incoming faxes much easier to manage, as the e-fax software allows you to easily sort by sender and date. You may have to remind the clinic’s office manager to order the phone line number or work with your telecom department if e-faxing hasn’t been done before.
Inbox Messaging
If you are implementing a scheduling or clinical EHR, it should include some kind of electronic messaging system where staff sends communications between schedulers, RNs, MAs, and physicians. Those users are usually grouped together into user groups, or Pools of users. A nursing group or pool would work so that all nurses can view all messages sent by schedulers (front office) to the clinicians (back office). Pools are set up so staff don’t have to worry about who sees the messages on a given day when some are off work. All staff see and can act on the same set of messages.
You will need to gather all the staff names and their roles, as well as the designation of the groups or pools. You may have things like North Wing Nursing Pool, Cardiology Physicians Pool, Main Street Practice Scheduling Users.
Patient Portal
If you are implementing a major EHR like Epic, Cerner, Practice Fusion, or eClinicalWorks, there will also be the option to set up a patient portal where patients can send messages to the office, get test results, and request appointments. Your vendor should provide lots of advice on the things that need to be set up, and you will need to work with your clinic staff to understand how this will affect their work.
Training
When your system build is nearly done, you will need to consider how training will be handled. In larger IT organizations, there are dedicated instructional designers who write up class materials and hold training sessions. If you are in a smaller organization, the application analyst may perform this role. In any case, you’ll need to communicate training needs to your clinic manager to make sure they have their staff available to rotate through classes.
If this is a full EHR that affects all parts of the department, you may have to reduce the schedule load by about 25% for the first week or so to give users time to adjust to documenting in the new system. Some people won’t like this because it means less revenue for the department, but it is standard practice for large implementations, especially if they are coming from paper records.
Pre-Implementation Dress Rehearsal
About a week before you go live with the new system, you will need to schedule a time with representatives from all areas of the clinic at the clinic. During this time, you will perform a mock patient visit through all phases, just as if the patient was there. Sticking with our primary care office assumption, you will check in a test patient, gather vital signs, bring them to an exam room, perform the visit, place and print orders, then check them out. This step will save you a lot of trouble at activation. You can spend the next few days documenting and fixing any issues that are found at the dress rehearsal.
Launch Day
When you actually go live with your software at the new department, you will need to have enough training staff onsite to support the users, and have a written agreement with the department manager for how long you will provide personal support. During the first week or so of go-live, you should document any activation related issues that can be referenced for the next department go-live.
If all goes well, then once you’ve successfully launched your software, you will need to have a post activation lessons learned meeting where you discuss what went well, what didn’t, and what you can do better next time.
Next Up: Learn about the members of a Healthcare IT project team.
Read More
