|“||What's in a name? That which we call a rose By any other name would smell as sweet.|
-- Romeo and Juliet (II, ii, 1-2)
|“||If it looks like a duck, swims like a duck, and quacks like a duck, then it is probably a duck.|
Other people who have to use these systems are more interested in other attributes of the thing. How they are used in a specific business context, or what policies and procedures must be developed around them (The business viewpoint). What information they convey about a thing, and what specific attributes make this thing different from that thing (the informatics viewpoint).
Unfortunately, in just about all software engineering disciplines, all the good names are already being used. So the same names sometimes get used in the engineering viewpoint as in another viewpoint. This can often create confusion because using the same name doesn't necessarily indicate the viewpoint of the namer.
Discussions around the names of things help when they expose these different viewpoints, and illustrate the different behaviours. They can become divisive when there is a lack of clarity around which viewpoint is being discussed. A current discussion in IHE is around the distinctions between a care plan used in nursing, and another plan used to coordinate care for chronic conditions. There are of course, different points of view, and unfortunately, we aren't necessarily clear about which point of view is being discussed.
From my perspective (an engineers viewpoint), the care plan and the coordination plan require a lot of the same behaviours be coded into the expression of the thing. From the perspective of others, the behaviours are different. The frequency at which the plan gets updated varies depending upon whether the plan is being used to support inpatient care or to manage care for a chronic condition from a different setting. The determination of that frequency is a business decision based on policies necessary for appropriate care in each of these settings. Does that mean I have to change the code I use to manage it? Not necessarily. Quite often, business rules are dealt with separately from the rules about representation and storage. So, I'd like to call it a care plan ... from the engineering perspective. But if I don't expose that perspective to others, and it doesn't use the same business rules, then its identity becomes confusing.
We have a similar problem in HL7 Version 3 constructs. The HL7 RIM describes things from an informatics viewpoint. We have acts and observations that describe the bits and pieces that make up a medical record described in a way that makes it easy to compute with things, and to expose similarities between things like problems and allergies. However, these names in the RIM don't address differences in business rules around them, or perhaps even the engineering viewpoint.
A perfect example of where the informatics viewpoint and the engineering viewpoint differ in Version 3 are the distinction between codes and identifiers compared to how those same things are represented in HL7 Version 2. Version 2 was much closer to the implementor viewpoint, and so a coded concept (CE) and an identifier (CX) both had a component called ID which was the identifier of either A) the concept or B) the thing to be identified. In Version 3, the coded concept data type no longer calls the code value an identifier, even though it still identifies a concept from a specific coding system, and the II data type uses a term ("extension") completely different from "identifier" to talk about the part we (implementors) normally think of as the identifier part. When I teach these data types, I start with identifier, explain how the parts map to the things that implementors think about, and then explain code and show the similarities.
The purpose of the Micro-ITS is to make HL7 Version 3 easier to implement by exposing names of things using a different viewpoint. The use of these different viewpoints is important because the implementors of HL7 Version 3 are NOT by and large, informaticists. They are for the most part, software engineers and interface developers who have some experience with the business viewpoint in healthcare. Trying to make them conform to the "informatics" viewpoint is proving to be counterproductive. Informatics is a 2-3 year graduate degree program, but you don't need to have that background to implement an interface.
Being able to look at things from different viewpoints is what the thing formerly known as SAEAF, and now known as SAIF (The Services Aware Interoperability Framework) is helping HL7 to do. Understanding what viewpoints are exposed and when and where they are discussed in the specifications you are working from will help people to better understand what we are talking about.
So, when you are discussing names, remember that one of the things in it is an associated viewpoint, and that it is important to expose and understand that also.