Understanding SNOMED-CT data model: Basics



Ever wonder why specifications from a standard body are complex? Have a look at Java Specifications or try understanding a new declarative language, they are mired in complex functionality and assumptions.

A couple of years ago, I came across SNOMED-CT and found that not all specifications are made equal. Being an IT professional, I expected such kind of work from an IT major, but surprisingly it came from the medical community.

SNOMED-CT is a specification for identifying, defining and describing medical terms. This should have been one of the complex specification in the know IT world but is one of the simplest.

The authors of this specification understood the underlying structure of the data should closely represent the domain model, which is the medical terminology context. The following is the basis for the specification(I will use terminology and specification interchangeably in this blog):

  • All components in the terminology are represented by Concepts.
  • Any relations between these concepts are defined by relationships.
  • All the components have a human/system readable description.
That's it! This is the entire gist of the specification. The underlying data structure is simple and concise and does not blur the distinction between data representation vs interpretation.

The goal of this article is to go through the data representation of the SNOMED-CT terminology.

The main Content components in SNOMED
  •  Concepts
  •  Descriptions
  •  Relationships
There are other supporting components such as
  • Reference sets
  • Extensions
Let's go through the main concepts one by one

Concept: 

A clinical idea that is associated with a unique identifier.  Each concept is associated with an FSN.

FSN(Fully Specified Name):  An FSN is used to describe a clinical concept and is associated strongly with a concept. Each concept will have one and only one FSN in one locale. Authoritative description of the concept type.

Identifier: A concept identifier is a numeric identifier which is up to 18 digits. 

Each concept is associated with one or more "description".

Description: 

      A description describes the associated concept or relationship. The relationship between description and concept is managed by a reference to the concept identifier. Similar to a Foreign Key relationship on the Concept Identifier.
      Descriptions also have a unique identifier which follows a different pattern to the concept identifier.

There are different types of descriptions that can be associated with a concept.
  • Fully Specified Name(FSN) 
  • Synonym
  • Optional Description of other types
The description is in Unicode, so can be used to describe concepts in different locales.

Relationship:

      A relationship identifies the associated relationships between concepts. A relationship is identified by a unique identifier which follows a different pattern than a concept or descriptions identifier.

Each relationship has a relationship type which identifies the type of relationship between two concepts.

The relationship is of the form (concept)---[relationship]---(concept). The concepts are identified by the concept identifiers.




For a detailed understanding of the SNOMED-CT terminology please visit SNOMED-CT tutorial 

In the next article, will see how to persist the Snomed data into a Graph DB.

Location: Sydney NSW, Australia

Comments

Post a Comment

Popular posts from this blog

Master Data Management in Financial sector

Image
One of the problems with large banks is that they are monsters created by mergers and acquisitions. The initial plan would be to merge the software stacks in a phased manner. Identify systems that provide common functionality. Identify costs associated with maintaining and upgrading the systems and software. Select a strategic platform. Start your project to migrate all applications onto the strategic platform. Start Phase 1 Get lost in business process translation. Most of the time it is too hard to merge two software stacks and come up with a single unified strategic platform. Higher Management would see this as a futile exercise and will take a decision to maintain the two systems and merge them in the future to save costs in the short term. Now, from a customer perspective you are a single bank, but the from the bank perspective you are a different customer in each of their systems. To simplify things, let us assume a bank which is standalone and does not have t...
Read more

Why the role of IT in Financial Institutes is more important than ever

Image
Most of today financial institutes see IT expenditure as an expense which eats into their profit margins. But, in todays world where you can order virtually anything on the Internet.  Interestingly , you can buy the Moon . But, try buying an insurance or apply for a loan and you would spend anywhere between 1 hour to days to get the policy or loan approved. Why does this happen? Why organisations tend to see IT as an expense rather than as an Investment? From a finances perspective, IT expense does not convert to revenue. Something similar to using fuel in a Taxi. For a taxi driver the taxi is an investment and the fuel consumed is an expense. Even though his taxi does not run without fuel, it is always seen as an expense. This would mean, sometimes it might seem to be a good idea to use subpar fuel to improve profitability. Businesses cannot survive without IT it is the life blood of modern organisations.But from a finances perspective it looks like an never ending ...
Read more