This information is for reference purposes only. It was current when produced and may now be outdated. Archive material is no longer maintained, and some links may not work. Persons with disabilities having difficulty accessing this information should contact us at: https://digital.ahrq.gov/contact-us. Let us know the nature of the problem, the Web address of what you want, and your contact information.
Please go to digital.ahrq.gov for current information.

Architecture of Health IT

Areas of Current Investigation |  Background | 

Areas of Current Investigation

Many issues arise when attempting to implement health IT. Typically, any of the components described above or the connections between them can go awry. It is also important to remember that there is a human element in all of this. Sometimes the "back-end" of the health IT process loop is manual, and despite good intentions in entering data electronically, someone still has to physically act on the data. That can be a major barrier to improving quality. We do not know enough about how big this barrier is?--i.e., how "automated" the process loop is. The Federal Government has invested a significant amount of money investigating the potential of health IT to improve the health care of all Americans. Efforts are under way in communities across the U.S. where issues such as standards harmonization, medical error documentation, cost analysis, e-prescribing, and health information exchange are being examined by researchers and practitioners.

While we know a lot about the barriers to implementing health IT, we still do not have good data on the usefulness of health IT. Does it really save money or improve care? Does it do harm? Does it actually improve care, or does it just "speed up" the normal care process? We know that CPOE alone is not sufficient--CDS is the key component. But one of the problems with CDS is that it provides "too many alerts," and the user has to sift through and figure out which one is important and which one is not.

Background

Health ITconsists of a complex set of technologies, policies, standards, and user sets. The text and diagram is intended to help put some of the "buzzwords" into perspective.

A general framework for understanding the levels of health IT from a technical perspective is as follows:

The various facets of health IT can fall into the categories described above. Applications include the following:

These are the applications (that run stand-alone or as modules) on the client or server devices.

One flow of data within health care organizations begins with multiple specialized systems that efficiently collect and store specific data within hospital information systems. For instance, a patient may have blood drawn and analyzed by the hospital laboratory. Specialized laboratory information systems have been developed to collect all the data about processed specimens. Similar systems have been developed for radiology, billing, pharmacy, and other services.  These hospital information systems are designed to serve narrow functions with great efficiency, but this situation results in multiple silos of information.

It is more useful to collect all the information on a patient in a single location. To accomplish this, health care organizations often have clinical data repositories, which pull data from all the separate specialized hospital information systems into one place. Such data repositories rely on other services and databases to perform this function. For instance, each hospital information system or external data source may use different information to identify a given patient. The central data repository might rely on a master patient index to ensure that all the different identifying information about each patient can be matched to a single patient identity.

To pull data from these specialized systems into the clinical data repository (or other consumer of the information), standards have been developed so everyone can agree on what each piece of data represents, and on how to format each transmission of data. The need for these standards has resulted in the development of coding and messaging standards, respectively. Unfortunately, not everyone uses the same standards or implements them in the same way. To translate data from a standard the sender understands to one that the the receiver understands, health care organizations need to develop and maintain interface engines.

HL7 (Health Level 7) is the most ubiquitous and overarching messaging standard. It can encapsulate many kinds of clinical information. ADT (Admission/Discharge/Transfer) messages signal patient registration events within different clinical service delivery settings (radiology, laboratory, pharmacy, outpatient clinic, ER, and so on). NCPDP codes are for transmitting medication data. DICOM is used to transmit radiology images and reports.

Coding standards include many types as well:

  • LOINC is a laboratory and clinical observation coding standard.
  • ICD codes for diagnoses.
  • CPT codes for procedures.
  • NDC and RxNorm code for medications. 
  • SNOMED CT codes for clinical concepts. 

All of the afore mentioned activity is transparent to the end user. Ultimately, the end user is interested in the applications that are built upon this infrastructure. There are many examples of such applications. For instance, CPOE refers to an application that allows providers to enter their orders (for lab or other tests, medications, consult requests, or other orders) into an electronic system for processing. Typically, during the "ordering phase," clinical decision support (CDS) is provided about the choices made by the provider. For example, if a medication is prescribed that conflicts with another medication that a patient is taking the ordering user is given an alert. CDS systems are typically "rules processing engines" that (1) can access the current set of clinical data about a patient, (2) know the "best practices" within a given domain (expressed as electronic rules using Boolean or other logic), and (3) can apply these rules to the clinical data in the face of a new command or order and provide appropriate guidance about potential problems.

E-Prescribing systems and eMAR systems allow users to prescribe or record the dispensing of medications electronically. Thus, CDS systems also are integrated with these applications to provide the appropriate guidance. E-prescribing and eMAR systems are subsets of CPOE systems.

Results reporting and electronic documentation systems allow users to look up old results or document new findings electronically.

At the process level, many elements must be in place. HIE refers to the overall effort of Health Information Exchange. This includes many concepts such as an MPI (or a Master Patient Index) that accurately maps many different medical record numbers for an individual as housed in many systems to a unique identifier. HIPAA is security and privacy legislation that protects the contents of confidential medical records from unintended audiences.

Finally, at the device level, health IT can be thought of as the devices on which the applications run -- for example, PDA devices, fixed workstations, servers, bar code readers, web sites, and so on.

A detailed summary view of the inter-relations between all of these applications can then be diagrammed as follows:

Health IT Architecture Diagram

The information on this page is archived and provided for reference purposes only.