Section 1.1 Adopt – Assess
Visioning and Strategic Planning for HIT
(See accompanying Webinar and PowerPoint handouts)
Health information technology (HIT) refers to the broad class of information technology that aids
health care organizations in achieving efficient and effective care delivery. All HIT encompasses
software applications and hardware, as well as requisite people, policies, and processes. Your
hospital needs to develop a plan that describes its long range goals for acquiring and achieving
effective use of HIT. Without a guiding roadmap, you are in a reactive position, responding to what a
vendor offers or what appears to be a regulatory requirement. Getting true value from HIT comes
from setting your own course, communicating expectations, engaging all stakeholders, and
celebrating success.
Software Applications
Within HIT are many types of information system applications. Any given health care delivery
organization may use some or all of these, depending on whether it is a critical access or small
hospital, clinic, long term care facility, behavioral health facility, home health agency, integrated
delivery network, or other form of provider:
1. Financial, administrative, and departmental or ancillary systems support the operations
of a health care organization. Even though for most small and rural facilities these systems
come from a single vendor and may be well-integrated, they include modules that provide for
registration-admission, discharge, transfer (R-ADT); patient financial services (PFS); health
information management (HIM);* clinical laboratory information system (LIS); radiology
information system (RIS); pharmacy information system (PIS); surgery information system
(SIS); nutrition and food services (N&FS); quality management; and potentially others such
as anatomic pathology, blood bank, emergency department, intensive care unit support,
therapy services (e.g., rehabilitation, physical therapy, respiratory therapy), nurse acuity
staffing, materials management, and executive decision support.
* HIM functions may include master person index if not included in the R-ADT module,
dictation/transcription and electronic signature, encoder, chart tracking, and deficiency
analysis.
2. Clinical information systems support health care professionals in direct care delivery. When
these clinical systems work together, they are often described as an electronic health record
(EHR) system. EHRs used in inpatient (both acute and long term) environments and
ambulatory care EHRs have differences.
a. In an inpatient setting, clinical information systems often include several distinct
modules—frequently acquired and/or implemented separately in no specific sequence
(1.2 HIT Strategy/Migration Path). A suite of applications for nursing documentation
may include nurse assessments, interdisciplinary care plans, clinical pathways, vital
signs documentation, and workflow support. Other applications often acquired early
in the process toward more clinical automation include those for results retrieval,
imaging (e.g., picture archiving and communication systems [PACS]), and medical
device data integration. More sophisticated clinical systems depend on significant
connectivity with departmental systems. These typically include computerized
provider order entry (CPOE) and electronic/barcode medication administration
records (EMAR/BC-MAR) that depend heavily on a robust pharmacy information
Section 1.1. Adopt – Assess – Visioning and Strategic Planning for HIT- 1
system and other departmental automation. Although clinical decision support (CDS)
is generally included in CPOE and EMAR applications as related to medication
management, more sophisticated CDS and point-of-care (POC) charting for providers
frequently are implemented after most other applications.
b. In ambulatory care (physician offices/clinics), the various functions of data capture,
results review, documentation, ordering/prescribing, and clinical decision support for
care management are generally combined into one comprehensive application. Many
EHR vendors are tightly integrating practice management (patient registration,
scheduling, and billing) into the EHR. Ambulatory care settings may chose to adopt a
migration path that is less daunting. Some providers adopt standalone e-prescribing
systems, use registries for care management (which may contribute to external
registries, such as an immunization registry), obtain a continuity of care document
(CCD) application for managing referrals, and depend on a provider portal to connect
to their hospital.
3. Clinical data repository (CDR) is the means by which data from the various applications
come together for processing into clinical decision support. A CDR is essentially a database
that is optimized to manage transactions for a given patient. For example, a CDR may enable
developing a graph showing a patient’s vital signs in comparison to medication
administration.
Clinical decision support is greatly enabled by a CDR. For example, when an order for a drug
for a given patient is placed via a CPOE application, the order is placed in the CDR. The
ordered drug is compared with drug knowledge information and the patient’s lab results,
which have been entered into the CDR by the laboratory information system. If the drug
being ordered is contraindicated for poor liver function and if the lab results for the specific
patient for whom the drug is ordered indicate poor liver function, an alert will display stating
a potential contraindication. The alert may also suggest a lower dose, alternative drug, or
closer monitoring, as applicable. The ordering provider accepts or rejects the
recommendation then the order is transmitted to the pharmacy information system. If the
system’s suggestion is rejected, the CPOE application may be set to ask the ordering provider
to identify the reason for the rejection. This informaion is held in the CDR as part of the
patient’s EHR.
Some EHR vendors fully integrate their clinical components with a data repository. This is
generally true for ambulatory EHR vendors and some hospital EHR vendors. Other EHR
vendors, primarily for hospitals, do not automatically include a data repository, leaving it up
to the hospital to decide at what point in their migration path they are ready for the capture
and integration of discrete data that enables complex alerts, reminders, condition-specific
guideline support, etc. Many small and rural hospitals acquire all their applications from a
single vendor that provides a well-integrated solution. In this your case, your hospital may be
able to get by without a clinical data repository until you chose to have sophisticated clinical
decision support that depends on processing data from more than one application.
Some small hospitals do not follow this IT strategy and have applications from a number of
different vendors. In this case, a limited amount of data sharing occurs through interfaces
between applications, sometimes aided by an interface engine—special software that
manages multiple interfaces. For example, an interfaced system could display an allergy to a
medication, but not process drug-lab contraindication checking. These hospitals will likely
seek a clinical data repository sooner than those hospitals with fully integrated applications
because interfaces only enable exchange of data, not pooling of data into a single database
structure that enables their integrated processing.
Section 1.1 Adopt – Assess – Visioning and Strategic Planning for HIT - 2
Although a clinical data repository is primarily designed to integrate discrete data, some
repositories also include pointers to documents and images.
4. Electronic document management system (EDMS) is often used in hospitals where a
bridging strategy is needed to achieve a paperless environment during the time clinical
systems are being implemented. EDMS allows document scanning and indexing to archive
documents until all data collection aspects of the health record are automated. Later EDMS
supplements the EHR when external documents are received in paper or digital form (e.g.,
email, efax, or digital dictation). In hospitals, document scanning is often used as a means of
converting (some or all of) paper charts of active patients into a new EHR, in addition to
incorporating paper and digital forms.
5. Portals are another important application to connect different providers to one another, and
patients to providers. In general, a portal is a Web interface that serves as a secure door to
related sets of data and services. A provider portal is typically a means to provide remote
access by providers to an organization’s various information system applications. For
example, a physician from home or office may gain access to the hospital’s EHR and obtain
patient vital signs and enter orders. A clinic may schedule a patient admission to a hospital
via a portal, transmitting key demographic and patient history information to the hospital. A
patient portal provides the ability for a patient or caregiver to request an appointment or
prescription refill, complete new patient intake forms, and perform other functions.
6. Data warehouse is also a database, but one that has been optimized to collect and manage
data on which complex queries and analysis, such as data mining, can be performed. Such
databases may also be called translational or analytical databases. It is advantageous to have
a data warehouse when the organization intends to conduct a significant level of data analysis
and reporting. While you can do some analysis and reporting from any database, including
the databases in individual applications or the CDR, very complex analyses on large
quantities of data will significantly slow down the CDR in performing its operations. In
general, only large hospitals or clinics have a data warehouse; however, many small and rural
hospitals and clinics are starting to contribute data to external data warehouses and quality
registries, such as those held by the Centers for Medicare & Medicaid Services (CMS) or
various other payers.
7. Telehealth, personal health records (PHR), and health information exchange (HIE)
services are other forms of HIT which are rapidly evolving and being adopted by large and
small health care delivery systems. Many hospitals use “Night Hawk” services for remote
reading of radiograms. Many small and rural communities have extensive telehealth
implementations, connecting them to their closest tertiary care facility or reaching out to very
remote areas for patient monitoring and supplemental care delivery. Small and rural
communities may find it advantageous to use a remote storage area network for backup and
disaster recovery. Personal health records (PHR) are starting to be recognized as important
adjuncts to health care delivery. CMS is developing a PHR system for Medicare beneficiaries
to keep track of their medications. Several health plans, including a number of Blue Cross
plans, are also doing this. The US Department of Veterans Affairs has created My
HealtheVet, a PHR systems for veterans. Some vendors are supplying various forms of
PHRs—from patient friendly summaries of care to access to lab results and even selfadministered medical history systems that reduce the documentation burden for providers.
8. Middleware is a final type of software that is important to include in HIT. While often not a
concern to end users, various report writing applications, presentation layer utilities,
interfaces, database management systems, and other software is required to make all of the
end-user applications work.
Section 1.1 Adopt – Assess – Visioning and Strategic Planning for HIT - 3
Hardware
Of course, information system applications require computer hardware. Hardware includes the
various processing devices and servers to run the applications. Data entry requires various input
devices (e.g., desktop computers, tablets, personal data assistants [PDAs], speech microphones) and
output devices (monitors, display screens, printers, fax machines, speakers, etc.). Data must also be
archived, so storage functionality is needed. This may include various forms of storage devices, each
with their associated media (such as magnetic disks, optical disks, flash drives, etc.). Various storage
area networks and storage management systems are used to manage large volumes of archived data.
As the HIT becomes more mission critical, backup storage and redundant processing devices are
necessary, often with middleware applications to provide automatic failover. All of these devices
must connect to one another in a network, so various network devices and their associated media
(including various forms of cable for wired networks and wireless network capability) must be
acquired and maintained.
Conceptual Model of HIT Environment
The diagram below illustrates the many HIT components described above. It depicts how an EHR
has the ability to capture data directly from multiple sources, including ancillary systems and users of
all types, and use the data in clinical decision making for the purpose of supporting patient-specific
health care as well as public health and population health. While this diagram may seem
overwhelming, recognize that as clinical computing requirements are addressed, the complexity of
applications, technology, and operational elements to support them increase in complexity, as do the
capabilities for use of the resultant information and knowledge.
Section 1.1 Adopt – Assess – Visioning and Strategic Planning for HIT - 4
Copyright © 2009, Margret\A Consulting, LLC. Used with permission of author.
For support using the toolkit
Stratis Health  Health Information Technology Services
952-854-3306  info@stratishealth.org
www.stratishealth.org
Section 1.1 Adopt – Assess – Visioning and Strategic Planning for HIT - 5