Articles in 24×7 and elsewhere exploring the technological convergence of IT and clinical engineering often discuss how to deal with overlapping roles (and one another), planning (project management), new skill sets and tools required, and the possible repercussions when things go wrong. This article will review one area of overlap—directory services. This is a service that can cause some problems for clinical users and can fall into clinical engineering’s bucket to either resolve or help coordinate a solution for it.

ACTIVE DIRECTORY

A key IT system used today that affects many of clinical engineering’s systems as they are placed on the network as part of a distributed network environment is Active Directory (AD) or the less common Novell Network Directory Services. This article will focus on AD because it is the most commonly used system. AD is defined as “a centralized and standardized system automating network management of security, user data, and other distributed resources. It also enables interoperation with other directories.”

One of the principal functions is setting up the rules for system access, logons, and passwords, along with user rights, and keeping a log of users’ access to the various systems. There are, of course, many more capabilities, but for the purposes of this article we will concentrate on this function.

As a central database, AD stores information and settings and enables interoperation with other directories.

Logons and passwords are a required part of everyday systems. But in health care, many of the smaller clinical systems, or device-based systems, either have had limited security access or were never implemented, which is no longer acceptable. As these systems are upgraded or replaced, they are usually placed on the hospital network as part of a distributed network environment. AD is used to manage and automate these processes across the enterprise versus having stand-alone management systems for each application. AD is an IT service to assist them in managing their various systems with a central tool.

One may ask, “What does this have to do with clinical engineering?” Since AD is managed by IT, if system access to a clinical system is denied and it is an AD problem, then what can clinical engineering do but point the users to IT and tell the users to contact IT? Why does clinical engineering need to worry about it? The reason is this: Clinical users such as physicians, nurses, etc, perceive the inability to access a system as a system problem. Clinical engineering—in the user’s mind—owns the system, and the system is not working. Therefore, call clinical engineering. If the EKGs are not available on the system, the users are going to call clinical engineering, not IT. AD is a behind-the-scenes service, not readily identifiable by users as having a problem. In fact, from experience, the users will associate the problem with the clinical system. If that clinical user is not in the hospital and cannot access information any other way, the problem can escalate very quickly.

Bottom line: clinical engineering needs to know how to troubleshoot issues and determine if it is an AD issue or a local system issue (troubleshooting). Pointing fingers is not acceptable, and it is definitely not acceptable if one assumes the problem resides in AD.

For example, a hospital recently upgraded its AD services, and the clinical engineering department was aware of it. However, the upgrade had an unexpected incompatibility with some of this particular system’s processes, preventing the system from accepting new patient results and users from logging on. After about 4 hours of communicating with IT and the vendor, the problem was identified and work-around was developed, but it took another day to get an incompatible script modified, which totally resolved the problem.

Now, this could have gone on for days. However, the hospital’s clinical engineering service had a detailed database on the system setups, current state, and software levels (which even the vendor did not have), and by working with IT it was able to bring the system back online. The issue was in the AD change, but it was still clinical engineering’s “problem.” More importantly, IT and clinical engineering worked together with the vendor to resolve the problem—no finger pointing.

Troubleshooting AD can involve several techniques. First, determine if IT has released any alerts about AD problems or upgrades. Next, know how to check the clinical system. Is it online? Is the hardware communicating to the network? This could be as simple as pinging the IP address, so you need to know the system’s IP address. Are all of the processes (threads) running? After this, run tests the manufacturer may have provided to test system features, or call the support group for the system. Always be prepared for the “it’s not our problem, must be your system” answer, and handle it diplomatically.

IN THE LOOP

Clinical engineering should be knowledgeable about AD processes, rules, and contacts. Attending and being part of change management meetings with IT is critical in order to know when AD events may be scheduled, and, of course, getting on the notification list or pager list when unscheduled events happen.

If clinical/biomedical engineering is to play a role with these systems, it must take ownership of the middle, between IT and the clinical users. IT will control the AD services or any enterprise service, but clinical/biomedical engineering needs to be able to mediate between IT and the clinical users and do it quickly and effectively, providing ongoing status changes back to the users or IT. Clinical departments may need to revert to downtime procedures, and communication with their clinical users is essential.

In the meantime, calls may be coming into clinical engineering’s dispatch line (or other notification process) to report problems. This is an ideal time to communicate information and current plans/time frames to resolve the problem. It may be a clinical system problem, a process, hardware, or application problem resulting in slow response, or loss of access to systems. In this case, if clinical engineering is supporting, it is clinical engineering’s role to get it back online. AD help may still be needed to bring the system back on the network.

Read previous Networking articles in past issues of 24×7.

GET TO KNOW AD

Learn about AD—what it is, its structure, what it does and does not do, and how it interacts with the systems maintained by clinical engineering. Know IT policies and departmental procedures, how users are added and removed from the system, what resources are needed, and how passwords are handled. Know the procedures for lost or expired passwords and what the turnaround time is to get new ones. (It may be several days.) Understand how IT reports and resolves AD problems internally—several IT services will usually be involved. Waiting until a problem actually happens to learn how it works will be a painful learning experience and will do nothing to help you with your customers. And remember, if it is clinical engineering’s system, then the users expect clinical engineering to respond and take the lead.

Greg Herr, BSEE, MBA, CCE, is director, imaging support/technical assessment, for Masterplan Inc at the Health Alliance and The Christ Hospital in Cincinnati. For more information, contact .