Archive for October, 2010|Monthly archive page

Meaningful Use criteria and Healthcare IT Infrastructure

This is another excerpt from my class on Healthcare IT Infrastructure. Analyzing the Final Rule for Meaningful Use of Healthcare IT for implications of Infrastructure:

Healthcare IT is currently undergoing an unprecedented rebuilding process. The paper chart used in the past, and the EMR that replaced it, were focused on recording episodes of care for one provider with one patient. Each episode of care contains Problems (usually the reason someone uses medical care), Medications, Allergies, Lab-Tests and other notes, usually organized in a hierarchical data model.

The government provides with ARRA/HITECH incentives to reshape the EMR into an EHR, which includes interoperability – meaning that data needs to be exchanged with other care providers, payers, and public health agencies. This has massive implications on the IT infrastructure of providers, because now clinical data (not only claims data) needs to be submitted securely with other providers, and even electronic access by patients is required.

Healthcare IT managers have to rebuild infrastructure right now in unprecedented scale and complexity, all while having to adhere to extended HIPAA Privacy and Security rules.

Here is a comprehensive overview of Objectives and Measures for Meaningful Use for Eligible Providers (EP) based on the Final Rule published in July 2010[1]:


Objective Measure Infrastructure
1.     CPOE: Use computerized provider order entry (CPOE) for medication orders directly entered by any licensed healthcare professional who can enter orders into the medical record per state, local and professional guidelines. … more than 30 percent of all unique patients with at least one medication in their medication list seen by the EP have at least one medication order entered using CPOE. Data entry at the point of care (mobile access); EMR with CPOE capability;
2.     Implement drug-drug and drug-allergy interaction checks. The EP has enabled this functionality for the entire EHR reporting period. Use of medication information source such as FDB or Medispan with online updates
3.     Maintain an up-to-date problem list of current and active diagnoses. More than 80 percent of all unique patients seen by the EP have at least one entry or an indication that no problems are known for the patient recorded as structured data. Create CCD (structured XML) record with coded problems (ICD9/ICD10), HITSP C32
4.     Generate and transmit permissible prescriptions electronically (eRx). more than 40 percent of all permissible prescriptions written by the EP are transmitted electronically using certified EHR technology. Connectivity with RxHub and coded medications
5.     Maintain active medication list. More than 80 percent of all unique patients seen by the EP have at least one entry (or an indication that the patient is not currently prescribed any medication) recorded as structured data. Create CCD with Problems, Meds & Allergies
6.     Maintain active medication allergy list.
7.     Record all of the following demographics:

(A) Preferred language.

(B) Gender.

(C) Race.

(D) Ethnicity.

(E) Date of birth.

More than 50 percent of all unique patients seen by the EP have demographics recorded as structured data. Part of CCD
8.     Record and chart changes in the following vital signs:

(A) Height.

(B) Weight.

(C) Blood pressure.

(D) Calculate and display body mass index (BMI).

(E) Plot and display growth charts for children 2 – 20 years, including BMI.

… more than 50 percent of all unique patients age 2 and over seen by the EP, height, weight and blood pressure are recorded as structured data. EMR/EHR functionality.
9.     Record smoking status for patients 13 years old or older. …. more than 50 percent of all unique patients 13 years old or older seen by the EP have smoking status recorded as structured data. EMR/EHR functionality
10.  Report ambulatory clinical quality measures to CMS or, in the case of Medicaid EPs, the States. …successfully report to CMS (or, in the case of Medicaid EPs, the States) ambulatory clinical quality measures selected by CMS in the manner specified by CMS (or in the case of Medicaid EPs, the States). Requires in many cases that data is off-loaded to RDBMS for processing and reporting
11.  Implement one clinical decision support rules relevant to specialty or high clinical priority along with the ability to track compliance with that rule. Implement one clinical decision support rule. EMR/EHR functionality which requires data entry at the point of care
12.  Provide patients with an electronic copy of their health information (including diagnostics test results, problem list, medication lists, medication allergies) upon request. … more than 50 percent of all patients who request an electronic copy of their health information are provided it within 3 business days. Requires patient portal with secure access to structured data and export, usually as CCR
13.  Provide clinical summaries for patients for each office visit. …clinical summaries provided to patients for more than 50 percent of all office visits within 3 business days. EMR functionality
14.  Capability to exchange key clinical information (for example, problem list, medication list, allergies, and diagnostic test results), among providers of care and patient authorized entities electronically. Performed at least one test of certified EHR technology’s capacity to electronically exchange key clinical information. Requires ability to store structured data in a CCD/CCR (CDA2, XML) and web services for patient identity (PIX/PDQ), Provide and Register, and retrieve document sets.
15.  Protect electronic health information created or maintained by the certified EHR technology through the implementation of appropriate technical capabilities. Conduct or review a security risk analysis in accordance with the requirements under 45 CFR 164.308(a)(1) and implement security updates as necessary and correct identified security deficiencies as part of its risk management process. Implement technical, physical, and administrative safeguards.


More details are in the text of law (42 CFR, see above) or here:

Let me highlight a few infrastructure consequences of the Meaningful Use (MU) guidelines:

  • Data has to be captured in structured format. Structured means (a) not paper and (b) not in a text document, but essentially in a CCD or CCR. CCD and CCR are based on HL7 CDA2, which itself uses XML for a hierarchical, structured continuity of care record/document in structured format (Dolin et al, 2006). For MU, a specific derivative has been specified and standardized as HITSP/NIST C32,  ( As a consequence, all EMR vendors have to update their software to add these features to their software, so their clients can meet MU. That also meets that hundred thousands of providers have to undergo major software release upgrades, or implement electronic medical records for the first time.
  • Section 10 (Quality Reporting) means that Providers need to be able to generate reports across their patient population for epidemiological purposes and report data. Traditional MUMPS databases struggle with reporting across the branches of their tree, but newer versions like Cache either provide SQL interfaces, or provide ETL tools to download into a Datawarehouse (DWH) for reporting purposes. This is of course troublesome for a single provider.
  • Section 12 (Patient Portal) requires Patient access to electronic health information. This is difficult for providers with traditional stand-alone EMR systems, but many SaaS style EMR offerings have emerged, providing Personal Health Record (PHR) access along with the EHR.
  • Section 14 (Health Information Exchange) requires the capability to exchange clinical data with others Providers. HL7 messages are insufficient for this, because traditional HL7 messages have document types for unstructured data (HL7 MDM). For the exchange of structured documents like CCD or CCR, it is necessary to build a web services infrastructure such as IHE ITI XDS.b ( ).
  • Section 15 (Data Security) re-emphasizes that all this needs to happen under the HIPAA framework.  45 CFR 164.308(a)(1), which is referred to in section 15, is of course the HIPAA Privacy and Security rule ( This constitutes a challenge in combination with all the other requirements, because the cross provider access allows providers from outside the organization to access documents, but still requires maintaining access controls and auditing in accordance with the law. As we discovered since 1996, it was already difficult to achieve compliance within a single organization – now this compliance needs to be extended to Health Information Exchanges.

Dolin, R., Alschuler, I., Boyer, S., Beebe, C., Behlen, F., Biron, P., et al. (2006). HL7 clinical document architecture, release 2. Journal of the American Medical Informatics Association, 13(1), 30.

[1] United States Department of Health and Human Services, Centers for Medicare & Medicaid Services, 42 CFR Parts 412, 413, 422 et al., Medicare and Medicaid Programs; Electronic Health Record Incentive Program; Final Rule, online at

Why are hierarchical databases like MUMPS still popular in Healthcare?

For my class on Healthcare IT Infrastructure at GGU (ITM 351) I had to explain to my students why hierarchical databases are not only still popular, but also practical, and show the limitations at the same time. It is amazing how little material there is comparing hierarchical and relational models – maybe because outside of Healthcare M is not used much and in computer science students only learn about RDBMS. But Healthcare is different. From Meditech to Epic, many EMR systems still use MUMPS or M. And actually for a good reason. Here is an excerpt from my GGU ITM 351 class:

Hierarchical database models continue to play a very important role in Healthcare IT, we need to review this aspect a lit tle bit more. First, let me explain what a normalized RDBMS is. Based on Codd (1971), the pioneer of modern Database technology, a database in normalized when it is at least in third normal form. Third normal form is required to prevent update and data inconsistency issues.

In figure 1 you find a very simple normalized relational database model:

Figure 1 Relational Model

In this example we have three entities (Patient, Encounter, and Procedure) to reflect a core concept of medical records. Every time a patient enters a Hospital, a new Encounter is created. One Patient can have multiple encounters over a period of time, so this is a one-to-many relationship. Each Encounter will require one or more Procedures, so again we have a one-to-many relationship, and each of the procedures can require one or many orders – all parent-child like relationships, all one to many and hence perfect for a hierarchical model. But in a relational model,  it is necessary to normalize to the 3rd normal form (NF), and in order to do this, the data architect needs to satisfy the requirements of the first normal form (1NF) first:

  • No repeating groups within or across columns

That means if a patient can have multiple phone numbers or multiple encounters, we cannot store these in the same table. Multiple Phone Numbers in one column would create problems when a program needs to update a single Phone number, because a single query would return the content of the field, which would be multiple phone numbers, not one in particular. And having multiple columns of phone numbers would violate 1NF, because we could have a lot of empty columns (i.e. if a patient has only one, but we anticipate up to three), or, if a patient has more phone numbers than we anticipate, we wouldn’t have enough. So that’s why we create a new table called “Encounter”, or “Phone Number”. We use MRN, the primary key of our Patient table, as a foreign key in the Encounter table (that establishes the link between the two tables), and we create an encounter ID. Encounter ID and MRN together identify Procedures, and we can add as many procedures as we like for each encounter, and as many encounters as we like, without ever violating 1NF.

Second normal form (2NF) requires:

  • All non-key attributes must be fully dependent on the key

The encounter table meets this requirement, because the table has three attributes (MRN, Encounter-ID, and Procedure Code). The non-key attribute “Procedure Code” is fully dependent on the composite key. Why do we need a composite key? One patient can have multiple Encounters, so I could have the same patient (= same MRN) with multiple encounters, and in each of those encounters a different set of procedures.

Third normal form is achieved if

  • No functional dependencies of non-key attributes

Orders are dependent and specific to each encounter, so we could not have orders and encounters in one table with MRN and Encounter ID as key. So the above simple diagram is a database schema in 3NF.

Now let us look at the same data organized hierarchical:

Figure 2 Hierarchical Data Model

In a hierarchical data model we have one restriction, which is that we can only model one-to-many relationships. But in the previous normalization exercise we discovered that that applies to all relationships. One patient -> many encounters. One encounter -> many orders. And when you think about this, medical records are always organized like this – they are logically hierarchical tree structures, which lend themselves to the database models like MUMPS, which not coincidentally was developed in Healthcare. The other advantage of hierarchical databases is that they do not have to be in 1NF. I could list multiple encounters and multiple phone numbers in the Patient table, and then link from there to the child, so for example encounter 1 links to a table with details about encounter 1, which contains many orders etc.

Because simple operations, like looking up a phone number, require costly table joins, some database designers purposely violate 3nf and design some redundancies in their database schema for the benefit of efficiency.

What is more efficient – RDBMS or M?

The Codd model of an RDBMS is very elegant, and a great implementation of mathematical set theory, which allows us to relate data in ways that were not necessarily predefined. If I would like to know all patients in the Hospital that have had an Appendectomy, I could simple formulate a query such as:

Select MRN from Procedure where Procedure Code = “47.19”

And if I wanted to know the Name of patients that had had appendectomies, my SQL query would be:

Select FNAME, LNAME from Patient where MRN =( Select MRN from Procedure where Procedure Code = 47.19”)

This is called a JOINT operation, in which two tables are joint on a common field (in this case MRN), which is great for all kinds of queries. It is the reason why RDBMS are so popular. But at the same time, every time I want to know a simple thing like which phone numbers a patient has, I have to use a joint also:

Select FNAME, LNAME from Patient AND Phone Number from Phone_Numbers where Patient MRN = Phone_Number MRN

Now, joints are computationally very costly, because in a joint first all data elements are brought together into an intermediary table, and then the joint condition or constraint is applied (in this case matching MRNs). If a join requires combining a database table with 500,000 rows with another table of 500,000 rows, the intermediary table will have 500,000 x 500,000 entries before the constraints are applied. In contemporary information systems that is not a big deal, but ten, twenty or forty years ago, it certainly was. And still today, RDBMS response time can be an issue if the database schema has not been designed with efficiency in mind. So while a relational model is very elegant, and allows all kinds of queries, a hierarchical model is very efficient BECAUSE of redundancies.

Downside of hierarchical models

It is hard to believe, but it is difficult for a hospital using a hierarchical database (and that is the majority of Hospitals in the US) to answer a simple question like “how many patients do you currently have with H1N1 diagnosis”. Hierarchical databases are built to structure data hierarchical, so if I Look up a patient X, I can most certainly find out if he has a diagnosis of “y”. But if I want to know all patients that have a diagnosis of “y”, which would be an unusual query for a regular Hospital process, but not so unusual for public health purposes, I would have to look up each and every patient tree to retrieve that information.

In interoperability the standard defined by the Department of Health and Human Services is the Continuity of Care Document (CCD) or Continuity of Care Record (CCR). Both CCD and CCR are XML schemas, which are built hierarchical. But XML uses metadata tags, so the query of diagnosis Y is a little easier, because I can look for a particular metadata tag, and select only entries where the metadata tag is non-empty. Still, the system would have to parse all records and then count the ones that match.

Another common way to overcome the disadvantage of a hierarchical model for non-standard queries is to load the data in data warehouses or data marts. The latter approach becomes very common for quality reporting and public health requirements, which are part of the ARRA/HITECH Meaningful use guidelines, and represent obviously a challenge for all the EMR systems based on MUMPS.

Codd, E.F (1971), “Further Normalization of the Data Base Relational Model.” (Presented at Courant Computer Science Symposia Series 6, “Data Base Systems,” New York City, May 24th-25th, 1971.) IBM Research Report RJ909 (August 31st, 1971). Republished in Randall J. Rustin (ed.), Data Base Systems: Courant Computer Science Symposia Series 6. Prentice-Hall, 1972