Convert your FHIR JSON -> XML and back here. The CDA Book is sometimes listed for Kindle here and it is also SHIPPING from Amazon! See here for Errata.

Tuesday, June 16, 2009

Observation of the Week

What's wrong with this list:

Vehicle Type:
  • 4-Cylinder
  • Commercial Truck
  • Motorcycle
  • Hybrid

One of the problems is that the value set for this data element covers five different axes for classifying the vehicle: Number of engine cylinders, use and body style of the vehicle (in one term), skills needed to drive it, and type of engine.

These are accentuated by the fact that the data element itself isn't well described. If it had said "vehicle cylinder count", "vehicle use", "body style", driver's license type, or engine type, it would be much more clear how this particular data element was to be used.

I have had four separate discussions with different groups on data elements that use the word "type", "kind", "category", "classification" or "code" in the name, where the only other piece of information given was what was being classified. Most things can be classified more than one way, and we usually know in a class diagram what class the attribute applies to. Most of the time I spent with these different groups was in understanding what the definition of the data element meant. By the way, on at least one occasion, drilling into the definition yielded something like: "the XYZ type describes the kind of XYZ that is being used". That's not very helpful ;-(

My design observation for this week is that if you are naming a data element to classify a thing, think not about what it applies to (vehicle), or that it classfies it (type), but rather, how you are classifying it. The implementers of the system you are designing may never notice, but then you'll probably never have to field questions about what "XYZ type" means either. It may save you some time, and it should certainly save them some.