We focused on connected healthcare solutions to address important issues that faced IT professionals, administrators and clinicians. The most important areas where technology solutions are required include: patient engagement and adherence, clinician mobility, population health, and alarm fatigue among others.
Acute and general health care: The point of technology assisting centralized monitoring, single point operability, effective alarm management, and clinician mobility, is to help reduce the challenges that are faced by clinicians and not aggravate or overwhelm them instead.
Home Monitoring: Through home monitoring patients suffering from chronic illness can be extended continuous care without them being needed to stay at the hospital facilities. With the help of wearable devices their stats can be continuously kept in check and in case any anomaly is noticed steps can be taken to correct them.
Sleep and respiratory care solutions: By understanding consumer needs one can extend healthcare services to ensure healthier patients and best practices for certain processes and procedures. One of them being addressing complex sleep conditions among some patients that can be eased with a focus on information analytics, patient compliance and data management.
Enterprise Telehealth - This technology looks at leveraging telehealth enabled programs, computer-based algorithms, and patient data to remotely monitor and address patient health and also reduce costs and overheads by decreasing costly re-admissions.
Imaging and Informatics: By streamlining the handling, archiving, and management of patient data in the form of radiology, cardiology, and pathology reports made possible through seamless interactions with the main hospital’s information systems, health care providers can strike a healthy balance in clinical work flow, improving the quality of care extended to the patients, and the economic value attached to the entire process.
Connected health: Finally in the same lines at imaging and informatics, allowing the integration of data and analysis of the same will help provide better patient care and support and also lead to better patient engagement. The Philips HealthSuite Digital Platform offers a secure cloud based-IT platform that allows secured collection of patient data, pertaining to health and lifestyle.
Congratulations! You’ve been picked to lead or participate in a clinically related IT project for a Healthcare vendor, hospital, or group of clinics. It may be the selection of an electronic medical records system, a roll-out of IV pumps or some electronic blood pressure monitors. Regardless of the product or project, it’s critical to understand the project team members and their roles in Healthcare project management. There are some aspects of Healthcare IT projects that mirror those of other IT projects, and there are some unique practices and business cultures that are fairly unique to Healthcare. Let’s look at some of the key players on a Healthcare IT project.
IT Project Sponsor.
The project sponsor is the visionary of the project. Many times this person will be a VP or CEO of an organization if the project is large; and maybe a Director if the project is medium-sized or smaller. While this may sound like a figurehead role, it really isn’t. In Healthcare, it’s quite common for there to be some push back from medical staff when they hear that a new technology is being proposed.
Let’s say a hospital has a high-performing surgeon who brings in a lot of revenue for the organization, but is very averse to technology. This surgeon may throw their weight around at the highest levels, and even threaten to take their practice elsewhere if the organization proceeds with the project. (Believe me, it’s not a far-fetched possibility). There is no way that an IT Project Manager or analyst team has the clout or executive skills to deal with this kind of crisis. That’s what the executives get paid the big bucks for! They have the “street cred” with the powerful people in your organization, so it’s critical to get them fully on board early on to support your IT project.
Healthcare IT Project Manager.
The Project Manager of course is the main point person and overall responsible person for the success of the project. They are accountable to the Project Sponsor and just about everyone else on the team, but mostly likely don’t have authority to hire or fire. That’s the nature of Project Management. They begin the project by writing a charter document that defines some very important aspects of the project:
The PM then needs to corral the required staff to put together the implementation plan for the project, defining specific steps to take by all of the team members.
Job of the Project Manager is to keep the project on time, on budget, and within scope.
Once the initial plan is developed, the PM then holds everyone else accountable to stay on time and within budget, and puts into place a communication plan to raise concerns if any part of the project hits a roadblock or falls behind. The PM then sees the project through to the end, and gathers “lessons learned” from the team after closure to document for future projects.
The Physician Champion is not always required on a project, but is usually needed for larger projects. This person provides the advanced clinical expertise to communicate to the team how this project impacts the physician community. They will act as the liaison between IT and other physicians, and help resolve any clinical issues throughout the project.
Subject Matter Experts.
Subject Matter Experts (SMEs) are usually not full-time participants in the project. They lend critical advice in a very particular area of expertise as needed. They are the representatives for the “foot soldiers” in an organization. Let’s pick one example from the opening paragraph above: a clinic will select and implement new blood-pressure monitoring devices for a group of clinics. The SME could provide necessary input, such as:
So you can see that SMEs can be your best advocates in a project. They can prevent the dreaded post-project complaint, “You never told us it was going to work like this“.
CMIO or Nursing Informatics.
In a Healthcare IT project, there is usually a representative from a clinical Director role who like the SMEs, represents the clinical users- only at a higher authority level. This person is involved in product selection and workflows, and is available during and after go-live to define policy and monitor compliance.
The Super User role could also be held by the same person as the SME. The main difference is that after the project has completed, this person will be responsible for ongoing training and basic troubleshooting of a system for their colleagues. There will always be staff turnover, requiring additional training, and the need to try to solve simple problems without needing to contact IT. That is the role of the Super User.
Clinical Application Analyst.
The Application Analyst is responsible for knowing and implementing the functional and technical aspects of whatever is being rolled out. If we use the blood-pressure devices example from the previous paragraphs, then we’d see the Analyst knowing how to set up, troubleshoot, test, and ultimately support the system indefinitely. The Analyst should also work with trainers to help develop training materials. In some organizations, the Analyst may also do some of the training.
The Clinical Trainer position is pretty much just what the title says. They work with other team members to understand specific workflows to then develop tip sheets and other training materials, depending on the number of staff to train and the complexity of the product. They may also provide onsite support when your application is launched.
Depending on the size of your project, there could be other team members such as a QA Analyst, and possibly the Biomedical Department in a hospital. However, this covers most of the key members.
Just about all hospitals or other Healthcare organizations have many different technologies in use by clinicians, administrative staff, billing offices, and others. It is common for these systems to be developed on different platforms, and coded in different programming languages. There are lab systems, EMRs, staff management systems, pharmacy automation, business applications, and a host of others. Without a common standard, the data between these systems would stay segregated, resulting in :
Fortunately, Healthcare IT systems do have a standard for sharing data among multiple systems. It is Health Level Seven, commonly referred to as HL7. So what is HL7?
Videos on Interfaces, HL7, & Interface Engines.
Please click on below hyperlink to have a look at these videos on YouTube
There are lots of sites to help you learn about the various HL7 messages, but many are lacking in usability, and are not well-suited for the beginner to interfaces. I’ve weeded out some and have found these to be useful:
HL7 Sample Messages.
Once you’ve viewed some videos and studied the reference materials, you’re ready to look closer at some other HL7 messages. In the videos you’ll become familiar with the concept of “counting pipes”, the pipe symbol | that separates the data into segments.
ADT Admit Message – ADT^A01.
This is an ADT Admission message. Notice that it has basic info about the patient contained in the PID (patient ID) segment. NK1 is next of kin, PV1 is the patient visit segment, and allergies are in the AL1 segment.
ORM Message ORM^O01 – Orders message that is placed for a Lab test
Note that ORC segment is bold. This is a NEW (NW) order, and ORC:2 has an order control number. After the order is placed, it then gets resulted by a Lab, who then sends the following message with the same order control number in the ORC segment. This is what links the two messages together.
ORU Message ORU^R01 – Results coming back in from Lab test above MSH|^~\&|HIS|EPIC|LAB|HOSP|20140307110114||ORU^R01|07110114|P|2.3
PID|||12001||SIMPSON^HOMER||19670824|M|||123 Fake St.^^Springfield^OR^90020
MFN MFN^M02 – Master File Message To Update Staff.
HL7 is not just for clinical messages. This is an example of an interface that updates user information, in this case a physician.
Interface Engines / Integration Engines.
An interface engine, aka integration engine is a software program that processes data between numerous Healthcare IT systems. Think of it as the nerve center or traffic cop of all the data that flows between multiple technologies in a hospital or other Healthcare organization. The technical staff who set up and maintain an interface engine will create individual configurations, or threads for each type of data coming into and out of the interface. There are patient records ADT threads that manage admission, transfer, and discharge data in an organization. There may be a lab interface thread that gets lab data to an EMR system. There can be a pharmacy dispensing interface thread that passes medication administration data to multiple systems. There are interfaces for orders, staff management, and a lot more. Also, there are times when an organization may create a thread on an integration engine that processes a fixed set of data for a limited purpose and timeframe. An example would be the medical histories on many patients in a legacy EMR that need to be loaded into a new EMR. The engine would reformat the existing data as it is committed to the new EMR’s database.
A technical analyst could feasibly spend their entire career just working with interfaces and interface engines.
Some of the top interface engines are:
In the early days of Healthcare IT, clinical documentation was done on mainframe-connected terminals, and later on Windows-based clients running on individual PCs. About the only data that was shared from these platforms was to billing services. Competing systems were built on different platforms with different programming languages; all by humans who have different ideas on what these systems should focus on. As Healthcare IT has evolved, the number and scope of connected systems has exploded. Today’s hospitals typically have more than one hundred systems that need to communicate with each other, not to mention the ever-increasing number of devices within the Healthcare setting, and the addition of consumer based devices like Fitbits.
This all means that Healthcare IT systems need to become more adept at exchanging data between lots of devices and other systems. This concept is called interoperability.
So what is interoperability and why is it important in Healthcare?
In order for two systems to be considered interoperable, they need to be able to exchange data and present it in a way that is useful to clinicians. Interoperability has been pushed forward by the Office of the National Coordinator for Health Information Technology (ONC). In 2014, the ONC released a 10-year plan to achieve interoperability in the US by 2024. The goal is better utilization of clinical data, improved workflows, lower health costs, and improved patient wellness. The OCC has recognized the need to more quickly overcome the fragmentation of various Healthcare technologies.
Levels Of Interoperability.
The Healthcare Information and Management System Society (HIMSS) has come up with three levels to define what qualifies as interoperability:
Foundational interoperability is the lowest level of operation, requiring data exchange from one system or device to another without an expectation that the data is interpreted. An example might be the use of a patient portal to send a PDF document that has patient history information. The recipient of the PDF document would need to open it and manually enter that data into an electronic medical record system.
Structural interoperability is the next level of operation requires the data to follow some structure or format, that there is uniform movement of the data, and that the data is stored somewhere in the receiving system. The data also needs to be preserved in its original form. Examples of structural interoperability are HL7 interfaces and the transmission of patient data from connected devices like Fitbits. Patient portals can be configured to allow patients to upload data from these devices. Another example is data from devices in physicians offices- like blood pressure monitors and glucose readers.
Semantic interoperability is the highest level of interoperability, requiring interpretation and use of the data to achieve outcomes such as improved patient care, improved patient safety, and the ability of clinicians to make decisions on that data. Examples of semantic interoperability are Health Information Exchanges and data collection methods for population health. Population health technology makes use of risk scores, which are calculations of many clinical data points to predict, for example how likely a patient is to be readmitted to a hospital in the near future. A clinical case manager can work from a report of risk scores to personally reach out to high risk patients with intervention activities.
HL7 interfaces may qualify as either Structural or Semantic interoperable technologies, depending on how they are implemented.
Where Is Interoperability.
Headed?For the short and medium-term future, I think we can expect to see a lot more consumer driven healthcare, where patients expect more connectivity from EMRs to devices, apps, and platforms that are not part of the EMR platform. Also, we can expect to see Healthcare IT departments work to make better use of data from multiple sources. Devices, population health data, and clinical charting will all be used together with greater efficiency to (hopefully) impact patient outcomes.
If you are looking to get into Healthcare IT, one of the first places to look is your local hospital. All but the very smallest hospitals have some form of IT department which interacts with almost every other part of the organization. Your exploration into Healthcare IT should start with a good understanding of a hospital IT department structure, and how various departments interact with IT. Let’s start at the top of a hospital organization and work our way down to the staff who do the day-to-day work in a hospital IT department. There’s a graphic at the bottom of the page.
Hospital Executive Structure.
At the top of course is the organization’s CEO. Directly under that person will be either be the hospital’s Chief Operational Officer (COO), or the Chief Information Officer (CIO). Whether the CIO reports directly to the CEO or not, the CIO is the last word and authority over the hospital IT department.
The Chief Medical Information Officer (CMIO) straddles the line between the CEO and the CIO. This person is always a physician, and works closely with the VP of Nursing Operations. The CMIO represents the physicians of the organization in determining the long-term vision for IT at the hospital. They play a key role in all major IT decisions.
Depending on the size of the hospital, there may be a director position that has front-line managers reporting to them. I used to work for a 300 bed hospital that did not have this level, and now work for a 900 bed system that does have directors.
Hospital IT Departments.
Next you have the individual departments where you start to see a real distinction in the work that gets done in the hospital IT department. The departments are more or less broken down by clinical functions.
Inpatient Clinical Applications.
This department manages the clinical software and related processes that serve the onsite hospital departments such as medical floors and wards, ICU, operating rooms, labor & delivery, and usually the emergency department. Some of the software products supported by this group are:
The IT manager of this area is usually has one of the largest teams, and the application analysts on this team typically has more licensed staff (RN, pharmacists) than some other areas. This team carries a heavy load because the hospital is a 24/7 operation. They frequently get after-hours calls. Quite a number of hospital nurses transition into IT by this route.
Ambulatory Clinical Applications.
This manager is over the clinical analysts who support software and related processes for Outpatient and Specialty clinics, which may include urgent care locations. They support these kinds of software products:
The size of the Ambulatory team depends largely on the number of Outpatient and Specialty clinics that the organization has. While the Ambulatory analysts get their share of after hours and weekend calls, they generally get to sleep a bit more than the Inpatient team.
The Business Applications.
The Business team supports those non-clinical IT software and services that are not always at the top of everyone’s minds. These include:
Desktop Support and Help Desk.
In most places I’ve worked, the PC support techs and the help desk analysts all report to the same manager. I’ve seen the Telecom group either under this manager or under the hospital facilities department.
Desktop support staff support the PCs, laptops, printers and other devices for a hospital. They are highly visible to the users in the clinical locations, and they go everywhere in an organization. They usually know every inch of a hospital. This staff usually doesn’t have much clinical knowledge, and doesn’t need to unless they are trying to move into a different role. They frequently get called after hours to deal with PC, printer and monitor issues.
The help desk team takes the phone calls and other requests from the users in distress and routes calls to all of the other teams in the hospital organization. They are the first line of support for IT. While they are typically not clinically minded, they do need a good grasp on the various applications in order to correctly assign issues to the right analysts. Most hospital IT departments struggle with mis-assigned tickets due to the difficulty in determining where trouble tickets need to be assigned.
Networking, Security, & Infrastructure.
This is the highly technical team responsible for core systems, security, and system maintenance. Some of the functions they perform are:
These are your system administrators that usually focus on specific areas. For example, a hospital with Epic will have Epic Certified System Managers (ECSMs) who work on the core systems of Epic, but probably don’t get into firewall administration.
These folks are almost always on call, and they regularly have to perform system maintenance at the least-busy times of the night, like 2:00 am Sunday mornings.
Project Management Office.
Hospital IT project managers provide oversight and direction for specific projects that have start and end dates. Project managers work closely with staff managers, directors, analysts, and the CIO to ensure that projects are successful. Depending on the size of the organization, the PMs may have a project management director, or may report to the CIO.
PMs sometimes come from clinical areas. I’ve known a few who had previously been RNs. The main professional designation for project managers is the Project Management Professional (PMP). I’ve seen organizations that have few or no PMPs, and some that require the certification for project managers.
The training department employs the IT staff who develop curriculum and train end users on a multitude of software systems. I see quite a number of RNs and other clinical staff who end up doing training, but that’s not usually a requirement.
I’ve seen a few organizations who have the IT trainers under the Organizational Development department, but most are under IT. I think having IT trainers working in the IT department makes sense.
Hospital IT Org Chart.
Finally, here is an image that lays out the hospital IT department structure. I can’t present all the possible scenarios, so I’m just showing what a medium-sized hospital may look like.