Recently the VA and DOD announced that they have licensed 3Ms Healthcare Data Dictionary, or HDD, for open use as'HDD Access'.
As someone that has spent a fair amount of time with the HDD, I think that this announcement represents something very exciting for those of us trying to leverage structured information in healthcare. I have to assume that there are a number of people out there that do not have an understanding of what the HDD is and how it can be used.
First of all, I should share that most of my knowledge and experience with the HDD is based on a core HDD. I am not sure how that translates to the ‘HDD Access’ version that will be released over the next 12-24 months. This being the case, I will focus more on structure and the features of the structure rather than the content itself.
HDD Access is described on its website as an “Enterprise Reference Terminology (ERT) that serves as the foundation for data management”. The HDD is primarily comprised of four core tables as described on the HDD Access website. These tables are CONCEPT, RSFORM, RSFORM_CONTEXT and CONCEPT_RELATION.
Concepts
The CONCEPT Table is where the concepts are stored. The primary key is called the ‘Numeric Concept Identifier’ or ‘NCID’. As the name implies the NCID is a meaningless numeric identifier (or Dumb Number as some people like to call it) which is a good thing. It is also supposed to be stable, which means that once a concept is introduced it is never deleted, which is also a good thing. A concept has a status that indicates if it is still active and the status itself is also an NCID. Every NCID is associated with and Enterprise identifier (Enterprise_NCID) that identifies the source of the NCID.
An organization can be issued an Enterprise_NCID and can then create their own NCIDs within an assigned NCID integer range. This is the mechanism currently in place to extend the concepts in the HDD to support local or unique concepts. This must be done with caution as adding local terms to a ‘standard’ terminology will create semantic drift that will require cleanup later if you want to take advantage of the standard.
Representations
The RSFORM and RSFORM_CONTEXT tables work together to allow concepts to have multiple contextual representations. Representations have a unique numeric identifier as well called the RSFORM_ID for each unique representation associated with an NCID. A representation will also have one or more Context_NCID that provides context relative to the nature of the representation. A context allows a representation to be more than just a synonym. This difference, though it may seem small, has a significant impact in terms of utility.
例如,你可以显示上下文like ‘patient oriented display context’ or ‘provider oriented display context’ to show synonyms for use under certain circumstances. You could also have interface contexts like ‘SNOMED-CT interface context’ or ‘ICD10CM interface context’ that allow you to associate code values to a given concept as representations. Since contexts are concepts themselves they can also have relationship and conceptual hierarchy, this allows you to group contexts into subsets like ‘Display Contexts’ has child ‘patient oriented display context’.
Like concepts, representations have an associated Enterprise_NCID and can be extended using an assigned range of numeric RSFORM_IDs.
Relationships
The CONCEPT_RELATION table has the relationship between a source concept and its related concepts. Each relationship has a relationship type (RELATIONSHIP_NCID), which is also a concept. A relationship will also have an Enterpirse_NCID associated with it. While this type of structure is not uncommon when compare to other ontologies, like SNOMED-CT, the HDD tends to have more explicit relationships and avoids the overuse of the ubiquitous ‘IS A’ relationship preferring instead the more specific ‘has Child’ and ‘has Member’ type relationships that I tend to prefer.
Relationships in the HDD can be used to describe conceptual hierarchy and taxonomy but are also used to denote defining attributes and properties of a concept.
The Structure in General
The HDD has similar structural characteristics to SNOMED-CT and in some ways the UMLS metathesuarus so it can support some fairly sophisticated patterns. It can get complex when you are trying to isolate a specific valueset but the granularity of the relationships and the ability to filter representations by context are worth the additional work. When 3M releases the information models I will dive deeper into the structure and with their permission I may even put together a screencast.
The Timeline
On the HDD Access website they have a timeline that you can hover over and magnify. Here is the timeline in tabular form (dates approximated from timeline graphic):
Summary
I think that, much like SNOMED-CT, LOINC, RxNorm and the UMLS Metathesaurus, the HDD Access offering will be an excellent resource that has the potential to make a difference in healthcare IT.
Our objective at Clinical Architecture will be to ensure that Symedical® Server, our state of the art terminology management and interoperability platform, will enable our clients to take full advantage of the HDD Access content. This will include capabilities like managing local subsets, enhanced mapping, sophisticated customizable search and ontology traversing. We will also support advanced terminology and ontology management with the ability to publish local enhancements directly to the HDD schema. These capabilities will be released in Symedical® Server in advance of the first release of the HDD Access content.
我们很乐意分享我们的想法和经验智慧h anyone who would like some assistance with the implementation of the HDD Access content and structures in addition to any other terminology source in the public domain. Please feel free to contact us here at Clinical Architecture, if we can be of service.
If there is interest, I would be happy to create follow up posts that compare the HDDAccess model with SNOMED-CT and UMLS Metathesaurus.
If anyone has any corrections or other feedback, please feel free to leave them in the comments.
