For those of you evaluating the use of the SNOMED-CT Core Subset, you need to be aware that the NLM has made some non-trivial changes to the format and content of the subset file in the latest (second) release dated 200908 (July).
If you have developed a load program, as we have, that uses the subset file to identify concepts that are included in the subset, it is likely you will need to modify that program.
Here is a summary of the changes:
Term Changes:
- Nine terms were added and eleven terms were retired from the core subset.
New Terms:
SNOMED_CID | SNOMED_FSN | SNOMED_CONCEPT_STATUS |
208892001 | Closed traumatic dislocation of hip (disorder) | Current |
165468009 | Erythrocyte sedimentation rate (ESR) raised (finding) | Current |
197321007 | Steatosis of liver (disorder) | Current |
40733004 | Infectious disease (disorder) | Current |
165346000 | Laboratory test result abnormal (situation) | Current |
442234001 | Serum cholesterol borderline high (finding) | Current |
442438000 | Influenza due to Influenza A virus (disorder) | Current |
442551007 | Dental caries extending into dentine (disorder) | Current |
4557003 | Preinfarction syndrome (disorder) | Current |
Retired Terms:
SNOMED_CID | SNOMED_FSN | SNOMED_CONCEPT_STATUS |
41006004 | Depression (finding) | Ambiguous |
309158009 | Laboratory finding abnormal (navigational concept) | Current |
371330000 | Fatty liver (disorder) | Duplicate |
131016008 | Increased thyroid stimulating hormone level (finding) | Duplicate |
166829003 | Serum cholesterol borderline (finding) | Ambiguous |
191415002 | Communicable disease (navigational concept) | Current |
78431007 | Influenza due to Influenza virus, type A, human (disorder) | Ambiguous |
416103000 | Elevated erythrocyte sedimentation rate (finding) | Duplicate |
50047001 | Compound dental caries (disorder) | Ambiguous |
63079007 | Closed traumatic dislocation of hip joint (disorder) | Duplicate |
64333001 | Preinfarction angina (disorder) | Duplicate |
File Structure Changes:
June Subset | July Subset | Change |
SNOMED_CID | SNOMED_CID | - |
FSN | SNOMED_FSN | Name Change |
CONCEPT_STATUS | SNOMED_CONCEPT_STATUS | Name Change Now uses Description instead of Code!!! |
UMLS_CUI | UMLS_CUI | - |
OCCURRENCE | OCCURRENCE | - |
USAGE | USAGE | - |
- | FIRST_IN_SUBSET | New Field (YYYYMM) |
IS_RETIRED | IS_RETIRED_FROM_SUBSET | Name Change |
- | LAST_IN_SUBSET | New Field (YYYYMM) |
- | REPLACED_BY | New Field (SNOMED-CT Concept ID) |
New Fields:
New Field | What is it? |
FIRST_IN_SUBSET | This is the issue year and month when the concept first appeared in the subset. |
LAST_IN_SUBSET | This is the issue year and month when the concept last appeared in the subset as a non-retired concept. |
REPLACED_BY | Concept ID of the concept replacing a retired concept. |
OUCH!
If you developed a program that loads the core subset file this update likely broke it.
If you are using a text ODBC/OLEDB driver to load the file the name changes to the columns broke it.
If you are accessing the fields using sequential access and splitting the fields using the pipe delimiter, the insertion of the FIRST_IN_SUBSET before the IS_RETIRED fields will break your load program.
If you created a function that uses the coded values in the CONCEPT_STATUS field to support your load logic, that is now broken by the switch to the text value. (I don't understand this change at all. It seems to run contrary to the move away from free text. I would change it back...)
Needless to say, this update was a painful one for the early adopter. But, if you have already created logic based on the inaugural release of the core subset data... and early adopter is what you are and it is not without risks.
Along with the painful changes that left our load program writhing on the ground, clutching its face and yelling "You broke my nose!" are some new useful additions.
The FIRST_IN_SUBSET, LAST_IN_SUBSET and REPLACED_BY_SNOMED_CID are useful lifecycle management fields that will help with the management of term availability.
Patience is a Virtue
If this update frustrated you, I would ask that you focus on the positive and consider that the Core subset is another in a growing line of great, "FREE" work products from our friends at the NLM.
It is also worth noting that as we in the HIT industry leverage SNOMED-CT, RxNorm and LOINC the bar will continue to be raised in terms of update frequency and format stability. From the interactions I have had with the NLM, I expect that they are paying attention and will be responsive as we evolve and leverage them more.
Free Advice
As someone who worked at a commercial content provider, I would encourage the following with respect to all data products.
1.) Do not change field/column names lightly if they are included in the file, as developers will leverage that with a text driver to load the information.
2.) Avoid inserting fields into a record, as some load programs will operate based on field order. If you append new fields to the end of the record you will be less likely to disrupt the load.
3.) Coded fields are better than text fields...always.
Regardless of the constructive criticism...this is good stuff. If we at Clinical Architecture can help you better take advantage of it, give us a call!
The Roman architect Vitruvius in his treatise on architecture, De Architectura, asserted that there were three principles of good architecture:
- Firmatis (Durability) - It should stand up robustly and remain in good condition.
- Utilitas (Utility) - It should be useful and function well for the people using it.
- Venustatis (Beauty) - It should delight people and raise their spirits.
The question on the table is: do these principles, meant to apply to physical architecture, apply to system architecture and more specifically clinical architecture? I believe that they do.
Any technologist "worth their salt" can easily see the value
of the first two principles when it comes to architecture. Firmatis and Utilitas: It will last and it will do the job. Some, however, might scoff at the third principle of beauty.
Before you riddle me with derisive laughter, consider that architecture in the brick and mortar sense does not stop at the foundation or the framing. Architecture is about the whole enchilada. You don't look at an ugly building with great framing and sexy plumbing and admire the architecture. By the same token, a beautiful building that caves in after five minutes due to bad internal architecture is not admired either, at least not for very long.
Most technologists can easily believe that the first two principles are our responsibility and the third is optional. I would argue that the third principle, venustatis, is at as important as the first two.
Why is Beauty important?
Let's go back to Vitruvius and the translation of the first two paragraphs in book one of De Architectura titled "On the training of Architects":
"The science of the architect depends upon many disciplines and various apprenticeships which are carried out in other arts. His personal service consists in craftsmanship and technology. Craftsmanship is continued and familiar practice, which is carried out by the hands in such material as is necessary for the purpose of a design. Technology sets forth and explains things wrought in accordance with technical skill and method
So architects who without culture, aim at manual skill cannot gain a prestige corresponding to their labors, while those who trust to theory and literature obviously follow a shadow and not a reality. But those who have mastered both, like men equipped in full armor, soon acquire influence and attain their purpose"
What Vitruvius is saying is that architecture is about craftsmanship and technology. Also, in the second paragraph, if you interpret culture as an appreciation for the sensibilities and behaviors of your target audience this, drives directly to the point I am going to make.
The difference between a good application architect and a great application architect is the ability to craft an elegant solution in a way so as to delight the user.
Venustatis in software is the combination of culture (understanding your target users), craftsmanship (you desire to produce a elegant solution) and technology (the easy part).
Are there any cheap tricks you can use to determine if what you have built is beautiful? Yes.
The most simple and straight forward way to determine if your software is "beautiful" is to use it. Not for five minutes. Not for ten minutes. Use it for an hour or two hours straight if possible. You are building a tool that someone else will be using for long periods of time. If you can't use it for an hour without hating yourself, odds are, neither can they. This will also give you a feel for the flow, need for short cuts and additional items that could be useful to the user.
These universal principles of good architecture: Durability, Utility and Beauty, can help us all be better at what we do.
As a technologist, one can be very tempted to use labels to deprecate something you don't agree with or don't understand. This happens with the term ‘Architecture' all the time. When asked about an older system that we inherited or an application we are tasked with renovating, it is easy shrug off the notion of an underlying architecture. I think when we do that, we short change our ability to understand how a system works and thus making our jobs more difficult.
Most definitions of architecture resolve to the following: A style and method of design and construction.
In the information technology world, we use the word "architecture" to describe patterns and mechanisms and, for the most part, use it to make our case relative to some industry adopted standard. In older systems, or those prototypes that somehow make it into production, we are quick to dismiss them as not having an underlying architecture.
I happen to believe that when you build something it has an underlying architecture, whether intended or not. So any system we should come across in out travels has either a deliberate or accidental architecture.
Accidental Architecture
Architecture does not always mean that someone sat down and deliberated the best way to do something, compiled a standards document and built something eternal. We are all dealing with or have dealt with accidental architectures.
We have all looked at something we inherited, with all of the legacy problems and issues and ask "what were they thinking?"
We have all built or done something that someone else is, or will be, looking at and asking the very same question. (c'mon, you know it's true - if you don't, you haven't built anything...)
The important thing to remember is "architecture happens", and once established it can become a pattern that is replicated, regardless of whether it was the right thing to do in the first place.
Accidental architectures are easy to create. Most accidental architecture occurs when someone is trying to solve an immediate problem and the impact on the future is not a priority. Accidental architecture can also serve a useful purpose; their successful and not-so-successful characteristics inform us on how we need to evolve our deliberate architecture.
Deliberate Architecture
A deliberate architecture is as much about the future as it is about today and is typically built on the bones of the accidental architectures that preceded it.
Developing a deliberate architecture is part archeology, part fortune teller and part problem solving. To define a deliberate architecture, you need to determine the scope and what problem it solves. Once you have defined this, you can constrain the features of the architecture. Defining and constraining the scope helps to reduce the potential mutation of the architecture. Make no mistake; a mutated architecture is also an accidental architecture.
Why look for the architectural patterns?
The value of recognizing that architecture happens is it provides you with a basis to determine motives. If you assume a system was developed randomly by an infinite number of monkeys, you will assume there is no pattern and doing the work to enhance or evolve that system would be difficult. If you look for the architectural patterns, even if they are not obvious, it will provide you insight and a basis for understanding what the developers were doing at the time. As a technology resource, it is your job to provide insight and manage the software assets in your care. Like an anthropologist or archeologist, you need to uncover the motives of those that thought differently from you or those that came before you. To renovate their work, or even replace their works with something new, you need to first understand it.