Patient Observation: Domain Model

Figure 11-1 shows the initial domain model for our system.

Figure 11-1. Patient Observation Domain Model

How do these concepts represent the information in the domain?

I'll start with the simple concepts of Quantity, Unit, and Range. Quantity represents a dimensioned value, such as 6 feet ”a quantity with amount of 6 and unit of feet. Units are simply those categories of measurement with which we want to deal. Range allows us to talk about ranges as a single concept ”for instance, a range of 4 feet to 6 feet is represented as a single Range object with an upper bound of 6 feet and a lower bound of 4 feet. In general, ranges can be expressed in terms of anything that can be compared (using the operators <, >, <=, >=, and =), so the upper and lower bounds of a Range are both magnitudes . ( Quantities are a kind of magnitude.)

Each observation made by a doctor or a nurse is an instance of the Observation concept and is either a Measurement or a Category Observation. So a measurement of a height of 6 feet for Martin Fowler would be represented as an instance of Measurement. Associated with this Measurement are the amount 6 feet, the Phenomenon Type "height," and the Patient named Martin Fowler. Phenomenon Types represent the things that can be measured: height, weight, heart rate, and so forth.

An observation that Martin Fowler's blood type is O would be represented as a Category Observation whose associated Phenomenon is "blood group O." This Phenomenon is linked to the Phenomenon Type "blood group ."

The object diagram in Figure 11-2 should make things a little clearer at this point.

Figure 11-2. Patient Observation Object Diagram

Figure 11-3 shows that we can make an Observation serve as both a Measurement and a Category Observation by stating that a Measurement of "90 beats per minute" can also be a Category Observation whose associated Phenomenon is "fast heart rate."

Figure 11-3. Another Patient Observation Object Diagram

At this stage, I have looked at only the representation of the concepts; I haven't thought much about behavior. I don't always do that, but it seems an appropriate starting point for a problem that is mainly about dealing with information.

For the moment, I'm still talking about patient observation concepts, just as I would be doing with a doctor or a nurse. (Indeed, that is what happened in real life. The conceptual models were built by a couple of doctors and a nurse, with me helping.) To make the move to an object-oriented program, I have to decide how to deal with the conceptual picture in terms of software. For this exercise, I have chosen the Java programming language. (I had to get Java into this book somehow!)

Most of these concepts will work well as Java classes. Patient, Phenomenon Type, Phenomenon, Unit, and Quantity will work with no trouble. The two sticky items are Range and Observation.

Range is an issue because I want to form a range of quantities for a Phenomenon. I could do this by creating a "magnitude" interface and stating that Quantity implements that interface, but that would leave me with a lot of downcasting . This does not happen in Smalltalk, and I can use parameterized types in C++. For this exercise, I prefer to use a QuantityRange class that uses the Range pattern.

My problem with Observation is that an Observation can be both a Category Observation and a Measurement at the same time (see Figure 11-3). In Java, like most other programming languages, we have only single classification. I decided to deal with this by allowing any Observation to have an associated Phenomenon, which effectively lets the Observation class implement both the Observation and Category Observation concepts.

These decisions do not result in a perfect state of affairs, but they are the kind of pragmatic imperfection that allows work to get done. Don't try to do software that exactly maps the conceptual perspective. Try, instead, to be faithful to the spirit of conceptual perspective but still realistic considering the tools you are using.