Patient Class

I'm working with a group at the Illinois Department of Public Health that is developing simple medical information systems in Smalltalk. The applications are all similar, and it seems like it should be possible to develop a standard design and set of classes to support it and then just crank them out. However, things are not as simple as we would like.

A typical system manages information about patients. One manages a standard set of blood tests for newborns. Another keeps track of immunizations for children. Each of these has patients with names and addresses. Patients are treated by doctors at hospitals.

It is not that hard to standardize Name, Address, Doctor, and Hospital, because these classes don't do that much and are always the same. The really interesting class is Patient, and unfortunately it is different in every application. Every application keeps track of different information about patients. Sometimes it keeps track of the result of tests or procedures. Sometimes it keeps track of a set of agreements. Sometimes it keeps track of a record of payments.

Data is always stored in a relational database. The Patient table tends to be a little different in every application. Maybe we should split the table into an application independent part and an application dependent part. An alternative might be to make some sort of "attachment", which could be the record of an event, and give each Patient a set of attchments. This would require a different kind of schema than they are used in the past.

Although each application is developed independently, it is fairly common to suddenly decide that data from one application needs to be compared with data from another. A standard PatientClass would help immensely, since it is always the center of the application.

My guess is that problems like this have been solved hundreds of time before. Have you seen one of them? If so, please describe the solution.

-- RalphJohnson

: "... keeps track of different information about patients. Sometimes it keeps track of the result of tests or procedures. Sometimes it keeps track of a set of agreements."

You might find MartinFowler's AnalysisPatterns book useful, in particular, see chapter 3 "observations and measurements". Apparently he's done some work on the COSMOS clinical process model (this may or may not be useful) see: http://smwww1.med.ic.ac.uk/dm/dmgm/cpm.htm --

Yes, I've seen that. We introduced the analysts at IDPH to AnalysisPatterns, and they now all have a copy and like it very much.

-- RalphJohnson

" it seems like it should be possible to develop a standard design and set of classes to support it and then just crank them out" Maybe it isn't possible. Maybe no one class will suit. Maybe the best you can hope for is to collect the useful tricks in creating classes like this.

OTOH, if I were in your position I would jump on RoleObject- Observed, Corresponded, Billed, Medicated. There'd be nearly nothing left in Patient when you were done, however. -- KentBeck

Hmm, I got stepped on. Anyway, as I was saying before I was so rudely interrupted, I think I'd take all my various Patient class definitions and put them into the same (separate) Smalltalk image and refactor them to see what they really had in common. Kind of incremental discovery. -- RonJeffries

I do work in COM and it is rather interface-centric. Essentially you think of an object as a locus of identity surrounded by interfaces, each of which gives you a particular view of the thing. ErichGamma wrote up the mechanics of COM in the PLOPD3 pattern ExtensionObject, but I don't have it in front of me, and I do not know what it would mean to work in untyped Smalltalk. My only guess would be that you would ask a Patient for a view of itself which fits your work at hand.

I have a question though.. how often does someone navigate from Patient to any of those "views?" It seems that work in medical information is about a patient, but, in real life, do we ask patients for their test results or their record of payments? Is Patient a subject of the system rather than an object of it? In other words, is Patient behavior rich in the domains or information rich?

-- MichaelFeathers

In the ShlaerMellorMethod you are encouraged to partition systems into domains (aka "Packages"). They point out in their examples that you can have the same object in different domains, for example "train" in a command and control system. You can have a "train" class in the GUI, a "train" class that manages sensors and effectors in the field and a "train" that embodies the management logic in a centralised location. Different domains have different concerns and abstractions so the same "physical thing" can be defined as a class in several domains.

- Maybe this is a bit like having multiple interfaces in a system such as COM(?)

As KentBeck and MichaelFeathers already mentioned, RoleObject (which uses ExtensionObject) seems appropriate for the situation you describe. You can find links to the relevant papers [1] (all available online).

-- YonatSharon

Isn't there an interesting tension between ExtensionObject and LawOfDemeter? Hmmm...

You might also want to look at the work on HL7, CCOW, and CORBAMed, all of which deal with this particular domain. HL7 is a messaging protocol for transmitting information between medical systems; CCOW and CORBAMed are COM and CORBA objects corresponding to these messages. Most of the information in these messages are of the type you mention in the first part of this thread.

We are having the same problem modeling country-specific information for pharmacological products. The main problem that you run into is that eventually the only shared information is an ID for the object and, perhaps, a description. I hyperbolize here, but as you delve deeper into the actual "shared" information that you can get from all of the systems, you come up with a smaller and smaller subset (it is the intersection, after all, isn't it?). As for modeling these, I've found that one can organize the database as a set of tables for each specialization linked to a table that represents the "base class" items, with the resulting difficulty in joins and speed, or one can union these all together into a big table that wastes space.

The real issue here is that this is where the mismatch between OO and relational modeling sticks out like a sore thumb. That solution is to use a good OO database, but if that is closed to you, the best you can hope for is a slightly misfit model with (possibly) slow access time, to boot.

-- FrankAdrian (98/8/5)

Patients, as you indicated belong to newborn, payment, agreements, immunizations, etc. With this premise, then, a set of forms that represent classes can be templated, selected, and modified for the patient. This approach preserves the individuality of the patient, something that is of great interest to me. When comparing data across applications, aren't you really talking about "departments" within an organizational structure? The patient is providing information that is utilized by different departments, and, therefore, your approach could be to start with a database that reflects patient information, build templates for each department, and "move" your patient from department to department.

I think you are already well into a successful approach with your SmallTalk continuity for applications development, and wish you luck.

-- TomPoe (98/8/18)

I assume this discussion is academic by 99.02, and we can learn Ralph's final "answer". The discussion is nonetheless interesting.

It is not the case that an observation, or agreement or payment "belongs" to a patient. Nor is it the case that patients "belong to newborn, payment, agreements, immunizations, etc." Nor is it the case that a patient has a Role of testee, agreeer, payer. None of those things belong to Patient. A Patient is a relation between a Person and a Hospital (or medical service provider). The only things that belongs to Patient are the Person, the Hospital, and patient's ID. Everything else is outside of Patient. There are n-way relationships between the patient, various departments or doctors of the hospital, test types and the test results. There are other n-way relationships between the person (or patient) and the hospital or doctors and certain agreements. There are other n-way relationships between person/patient and departments/doctors and tests/services and invoices and payments. What to do about them is strictly a design matter in the context of anticipated uses.

With the anticipated use of unexpectedly needing to compare different tests from different departments, you are faced with either doing a search, using a two-stage design structure, or doing meta-level inquiry ("return all test types performed on this patient. for each test type do, ..."). Having a relational or object database in the background doesn't change this. It may mean that meta-level inquiries are out.

The easy part in Smalltalk is the meta-level inquiry. The hard part is adding all those new relationships to Patient (as though Patient was supposed to know about them). Relational technology reverses those. Asking for table names is nearly impossible. However, adding a new table that has the patient ID as a key is simple. The patient never "knows" that it is being used as a key. Speaking directionally, the new test / invoice knows of the patient directly, but not the reverse. Easy update.

In the relational model, with the advent of a new test or test comparison, the programmer adds code to reference the new or both test tables, keying off the patient's ID. presto, done. That corresponds, in the OO model, to having a set of relationship objects, each knowing (pointing back to) the patient. The OO code requests a search of all relationship instances whose patient is P. The back end converts that search request (automatically, I must add) to a relational query. (This has been done, I have used such, they were fast).

The funny part is that the OO model shows all these relationship objects. Makes most OO domain modelers queasy until or unless they discover good noun names for them.

That's my nickel's worth. -- AlistairCockburn

I wish I'd come across this earlier. I used to work for a medical peer review organization in the late 80's. We programmed C and SQL for large Oracle databases holding claim information for medicare, medicaid, and lots of insurance companies (like Blue Cross, Travelers, etc.).

We weren't trying to do O-O at the time, (we did E-R instead ;-) but we pretty much did almost exactly what Alistair described above. We considered the "patient" information to be a property of the relationship between (a) a given patient, (b) a given medical service provider, and (c) a given claim-maker or insurance provider (the last two seemed to have the greatest effect upon what was/wasnt part of the claim information). I suppose Rumbaugh would have called it an "association class." We commonized what we could into a single table ("class"?) and then some of the other items in the relationship formed a "key" into a slot in an "extension table" (extension object?) to get the non-standard info (and look at its schema "reflectively" in some rare cases). -- BradAppleton

I've seen something related, though not quite the same. Classes in a distributed system which use IDs to indicate that that they refer to the same thing. It is kind of like TypeObject except that it deals with instance identity rather than type, and the only delegated behavior is identity comparison. For lack of a better term, I call them IdentityObject-s. An IdentityObject is an object stripped of everything but its identity. Other objects refer to that identity so that they can meaningfully associate information and behavior with whatever that identity represents.

Coincidentally, the domain is medical also. -- MichaelFeathers

Ralph, what did your group come up with? (Feb 1999)