emr in the dod

went to a seminar this morning on the dept. of defense's new electronic medical records system, chcs II (composite health care system II) (also see this article on the system). the stated goals of the system (which is used at every us military medical hospital in the world and even in the theater of opperations) are to:

1. provide longitudinal access to patient records
   
2. ease of use
   
3. enhance epidemiological knowledge and response

the first two are givens, but i thought it was great that they are explicitly looking to enhance their public health stance within the military population -- the speaker specifically mentioned gulf war syndrome.

the system's ui is a fat client which i think is a good thing (although i wish it was a rich-thin-client). it's built to look a lot like outlook, and the practicioner enters data by chaining together concepts from a tree widget. so the practicioner does not type free text into the system, but constructs medical observations through a predefined and heirarchically organized vocabulary (if you're wondering it's not umls, it's not snowmed ct, the vocabular was internally developed but can be mapped to all the other vocabs if necessary).

not only does this prevent the vocabulary normalization nightmare inherent to medical records (e.g., 10 different descriptions for sinusitis), but it also automatically saturates the medical record with additional information such as meta-data and billing/order codes. the downside is that you have to drill down trees all day, which can probably be frustrating, although the speaker did not mention any usability data.

one interesting point made was that the system captures events instead of facts. that is, instead of storing something like, 'blood pressure is 120/80', the system stores 'nurse jenkins observed mr. smith's blood pressure to be 120/80 on friday, june 4th using a digital pressure cuff'. i guess this has no immediate benefit, but it should provide a much richer substrate for data-mining.

another interesting architectural decision involved the database schema: they are basically using two different databases, one for regular information transactions, and one for report querries, both of which seemed strangely simplistic. the 'report' database -- which is populated from the 'regular' database -- has a schema that you would probably consider normal, that is, the rows are patients, and the columns are clinical observations such as pulse, bp, etc:

-------------------------------------------------------------------------

| patient | blood pressure | pulse | bun | creatinine | ... | potassium |

-------------------------------------------------------------------------

| 23423   | 120/80         |  70   |  20 |    10      | ... |    5      |

| 44133   | 160/110        |  80   |  30 |    15      | ... |    5      |

| 729113  | 110/70         |  60   |  15 |    7.5     | ... |    5      |

-------------------------------------------------------------------------

the 'regular' database actually has kind of a weird schema, that looks something like this:

---------------------------------------------------

| patient |    test type             |    result  |

---------------------------------------------------

| 23423   | blood pressure           | 120/80     |

| 23423   | pulse                    | 70         |

| 44133   | bun                      | 30         |

| 729113  | age                      | 27         |

---------------------------------------------------

as you can see, it looks really ineffecient, but the reason why they made it this way is that new types of tests are always being added to the clinical repertoire. for example, they had to start recording pain as a clinical observation, so if they had a typical schema like the one in the 'report' db, then they would have had to add a column, which is bad database hygiene.

with this seemingly oversimplistic schema, a new clinical observation is just another row, so you don't have to drop tables and all that nonsense. since the 'report' db is constructed with data from the 'regular' db, it's not a big deal to rebuild it with a new column.