What is in a Name?

“	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)

For some reason, naming things seems to be a really important act.  I have far too many years of experience as an engineer dealing with these names to really be offended, when, at the very last minute, marketing changes the name of something in a user interface, and we have to search and replace all occurences of the name used to explain it in all documentation and UI code.  As you can tell, changing the name doesn't change it's behavior, but it often does change the perception.  Engineers often use the duck test when they name things.

“	If it looks like a duck, swims like a duck, and quacks like a duck, then it is probably a duck. -- Various

Names are interesting because how you name something says something about your point of view.  Engineers name things based on how the code works.  We do things like create whole models of the world or significant parts of it (e.g., the HL7 Reference Information Model or the ebXML Registry Information Model) that are made up of reusable parts based on how those things act when we have to code them up.

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.