Your Master Problem List - Working FOR you or AGAINST you?
Julie M. Green, DVM, MS
Special Assistant Research Professor
Veterinary Terminology Services Laboratory – Veterinary Medical Informatics
Va-Md College of Veterinary Medicine – Virginia Tech, Blacksburg, VA

In this highly connected world where our cell phones serve to organize our lives, carrying all of our important information, clients are beginning to expect their pets’ data to be as electronically portable as their own.  Unfortunately the reality is that veterinary electronic medical records are not yet capable of truly portable data.  Online pet health record systems such as Patterson’s ePet Health have the ability to mine data from specified medical record systems, but the data is not “transferrable” to other clinics.  It’s only available for viewing online.  Agreed upon data standards such as a shared data model as well as terminology and messaging standards are required to make true electronic transfer of medical information a reality.  Until they are fully realized, “data” transfers must be done manually or as “pseudo-data” pdf files, and we will continue to have to read through pages of records in order to “extract” the list of previous problems when receiving a new patient.  
Through the creation and maintenance of the Problem and Diagnostic Terms subset of SNOMED CT and the Veterinary Extension of SNOMED CT (VetSCT), The American Animal Hospital Association recognized this need and chose to promote standardization of the Master Problem list as a good place to start.  The Master Problem list serves as an important part of nearly all medical records giving a quick historical view of the patient’s medical history.  
Standardization in the purest sense means that everyone in a given group (practice, practice group, veterinary profession, etc) uses the same “standard” list, in this case for the Master Problem list.  Practically, we’d also like it to be a controlled terminology or list which is managed according to good principles of terminology, avoiding the common pitfalls that will be reviewed in the next section.  Standardization of problem list terms helps to avoid the inevitable spelling errors that plague medical records, as well as helping to enforce purity of the data stored as a “master problem”, i.e. only problems and diagnoses should be stored, not owner notes, demographic info, procedures performed, etc.  It also helps to ensure consistent and reliable recording and retrieval.  When free text is used for a Master Problem list, great variability can be introduced in the terms used to describe any given problem.  For example, a veterinarian with an interest in cardiology (or one recently trained by veterinary cardiologists) is more likely to record “Arrhythmogenic right ventricular cardiomyopathy”, while older veterinarians may be more likely to record “Boxer cardiomyopathy”.  In order to retrieve all cases, one would have to first compile the list of all possible ways to refer to this one cardiac disorder, and many other examples can be easily found (cardiac failure vs heart failure, kidney failure vs renal insufficiencies, etc).  
Standardization using an externally agreed upon standard, such as SNOMED CT and VetSCT, gives additional benefits.  Using external standards gives the ability to share or transfer the Master Problem list electronically. As long as both the sending and receiving systems are able to store and process codes from the standard, then the Master Problem list can be sent in a data format that can be truly imported into any EMR and be immediately available for use.  This would be an important step towards true electronic transfer of medical information.  Furthermore, since SNOMED CT has been adopted by United States public health and is encouraged as part of the US government’s Meaningful Use guidelines, use of SNOMED CT and VetSCT means that our medical records would be compatible with public health and human medicine.  While realization of any benefit from this is clearly years down the road, it is important to retain that capability for the future.  And finally, the logical structure of SNOMED CT and VetSCT provides relationships between medical concepts that make advanced query construction possible.
Most EMRs today come with a built-in list of diagnostic codes or master problem list codes.  Unfortunately experience has shown these local lists to have many issues as they are not managed according to good principles of terminology.  The most common problem that users immediately notice is that the lists are incomplete, missing many of the problems or diagnoses needed.  Most systems allow the user to overcome this by adding their own problems to the list.  Unfortunately this capability is one of the main causes of the other two most common problems with local lists: duplication and ambiguity.  Users rarely have the time or training to do a thorough review of the lists to be sure that the problem they need is in fact not there.  If we use our earlier example, if “Boxer cardiomyopathy” is not quickly and easily found, the average user would add it without thinking to look for “Arrhythmogenic right ventricular cardiomyopathy”….leading to two versions of the same disorder: duplication.  Once you have duplication in the list, then searches for records with one of these diagnosis terms will not return the cases stored with the other.  Retrievals will be incomplete; records will be missed.  The other problem seen with list items added by users with no terminology training is that the terms are often ambiguous, lacking the clarity to ensure that the term means the same thing to every user that reads it. For example, a busy practitioner who’s just seen a “congested kitten” might search for “congestion”.  With more appointments waiting, if he doesn’t find it immediately, it’s likely that this overworked practitioner might decide to just quickly add what he needs and add “Congestion”.  Unfortunately this term is not specific enough to inform the next veterinarian.  Someone else might see a dog with pulmonary congestion on radiographs and choose this same term “Congestion”.  Both are congested, but they are very different clinically.  Similar issues could arise with findings in locations like “fundus” (stomach or eye?) or “knee” (horse’s carpus or dog’s stifle?). When ambiguous terms are allowed in the list, you lose data accuracy.  If the same code is being used for cases that are actually different diagnoses, you cannot be sure that you are returning cases diagnosed with the disorder in which you’re interested.  We also find that a wide variety of “types” of terms get added to the Master Problem list when users are allowed to add at will.  Everything from procedures performed (spay, pedicure, anal glands) to notes about the animal’s disposition (caution with pedicure, will bite).  These are not “Master Problems”, and including them here reduces the purity of the data.
The solution to the issues with the local lists included in EMRs is to replace them with well-managed, standardized lists.  The question then becomes….Do we internally manage our own standard for our practice(s)?  Or do we adopt an externally managed standard?  
The main benefit of locally managed lists is that you have total control over wording.  Assuming that your doctors can agree on terms, you can use what is preferred by your doctors.  Plus you don’t have to rely on an outside entity and their update schedules and resources.  Unfortunately most practices and/or practice groups don’t have anyone on staff with terminology experience (there are only a handful of veterinary professionals with this training across the United States).  This means either investing in a salary for a trained terminologist, which most practices cannot afford, or training someone currently employed by the practice/group to be the terminologist-on-staff.  The terminologist will need to maintain centralized controlled of the lists.  In other words, the software must be locked down to restrict modification of the lists to only the trained terminologist to avoid users propagating the issues discussed.  If these conditions can be met, then locally managed lists can be well controlled and locally “standardized”.  But remember, local lists are only understood or usable by the local system(s).  These codes cannot be transferred and understood by external systems.  
In order to preserve the ability to exchange data with external systems, you must use an external standard.  Externally managed standards such as the AAHA Problem and Diagnostic Terms are managed by trained terminologists, so there’s no need to have staff trained in terminology management.  This does mean that you will have to rely on that external entity for additions and changes to the standard, though there should be a process for making requests and you should take advantage of it.  You will also have to be sure that your system is prepared to handle the updates as the external standard changes and matures.  This is very vendor dependent, as the software has to be set up to handle the updates.    
For small animal general practice, the only external standard available for master problem list or diagnoses is AAHA’s Problem and Diagnostic Terms (AAHA PDT).  The AAHA PDT is a subset of concepts and descriptions from SNOMED CT and VetSCT.  It’s designed to be used as an interface list in systems for recording problems or diagnoses in small animal general practice.  Its scope does NOT cover specialty medicine or species other than cats and dogs.  Feedback so far has been positive regarding the coverage of cases seen in general practice as well as emergency medicine, though we expect that the subset will expand as more practices implement it.  
At this point implementation of the AAHA PDT is in a very basic form in order to fit into current interfaces.  Current systems generally store a text phrase (term) and an identifier, and do not provide a way to connect more than one term to a single identifier.  With this limitation, it is not possible to take advantage of the fact that the AAHA PDT provides multiple synonyms for most of the concepts in the subset.  The Editorial Board that reviews terminology issues affecting the PDT has chosen a single term for each concept as the “preferred” term, and this is the term that is generally implemented in existing systems.  Unfortunately because veterinarians have a wide variety of preferences, this preferred term may not match the preferences of every hospital.  This is the reason that the AAHA PDT has multiple synonyms available for each concept.  Vendors should be encouraged to restructure their interfaces to allow for the ability to connect multiple terms to each concept.  This will dramatically increase user acceptance since everyone’s preferences can then be available when they are looking for codes or doing code based case retrieval.  Another issue that many vendors are struggling with is the fact that the SNOMED identifiers are 64-bit integers, much larger evidently than most systems are using for identifiers.  For example, in order for IDEXX Cornerstone to be capable of loading the AAHA PDT, they have to alter the identifiers in order to make them fit into their identifier field.  This works ok for now, but will cause problems in the future when we start to send data between practices.  Vendors need to be made aware of this issue and should be encouraged to plan for this need.
If you’re not lucky enough to be using a system that can load the AAHA PDT for you (such as IDEXX Cornerstone, ImproMed or some of the new cloud based systems), then you will have to tackle the task of importing the codes and migrating your system on your own.  Unfortunately, I have yet to find a system that offers a batch import functionality.  Manual entry is the most common, typing each code and term in one at a time.  Some vendors may offer to load the codes for you via their support mechanism (Cornerstone is an example of this).  But before you even begin the process of getting the codes into your system, you must consider legacy data.  Legacy data is data that you may have already stored in your system using your system’s current list.  If you haven’t coded any problems or diagnoses, then you have no legacy data to be worried about.  You can just enter the codes and terms and get started using them.  However, if you have already been coding problems or diagnoses then you have to consider how you are going to handle those previously coded cases.  Currently, the process with Cornerstone is that as part of the steps that Cornerstone support takes to load the AAHA PDT, they inactivate all old codes.  So your old cases will be coded using the inactive list, and any new cases will be coded using the AAHA PDT.  While this is expedient, it creates a data wall between your old cases and your new cases.  We suggest that a more data friendly approach would be to look at the list that you’ve been using, compare it to the concepts in the AAHA PDT, and create a “map” between the two lists.  A map is just a file that records equivalency between the old codes and the new ones so that you have a way to reconcile your old cases with the new terminology.  The map creation is best done by a terminologist or someone who has been trained to be sensitive to the details of terminology and recognizing when 2 ideas or concepts are truly equivalent and what to do when they are not.  The mapping process may help to identify any terms that you’ve been using that might need to be included in the AAHA PDT.  The map can also serve as a guide if you decide that you want to review your old cases and code each of those diagnoses/problems with the new codes in order to have them retrieved via the new coding system.  Vendors should be encouraged to develop a mapping functionality that tracks the relationship between inactive codes and the new AAHA PDT codes.  If this were built into the system, then searches could be automated to access the map and retrieve cases coded with inactive codes that have been deemed as equivalent to current AAHA PDT codes.  This would remove the need to recode legacy cases.  
And finally, once you’ve accomplished your migration, AAHA PDT implementers must be ready to handle updates.  In April and October of each year, a new release is made available that includes new concepts that have been requested, new synonyms for existing concepts, and notices of concepts that have been retired or removed from the subset.  With each update, any new concepts should be added to each system’s list.  New synonyms should be reviewed to consider if this new synonym might better meet the preferences of the practice (once systems all multiple synonyms for each concept, then addition of these synonyms will be all that is necessary…no review required).  And finally any retired concepts should be inactivated in the system’s list.  Vendors should be prepared to update the terminology lists in each system, or at least provide you with the tools you need to do it internally.  At present it is unclear how this will be handled in systems, such as Cornerstone, that have the AAHA PDT available.
While we all would like to be able to choose a system out-of-box that will allow us to store our medical data in a format that will easily transfer to other practices, this is just not available in current systems.  And unfortunately, creating a fully standardized record with all of these goals in mind is beyond the resources that veterinary medicine has available for standardization.  We can only move forward using small, targeted steps, such as standardizing the master problem lists.  But if we keep our goals in mind and move forward one step at a time, we can improve our data and as a result improve our medicine.  This is the ultimate goal.