This wiki has undergone a migration to Confluence found Here
<meta name="googlebot" content="noindex">

Difference between revisions of "Concept Domain Naming Conventions"

From HL7Wiki
Jump to navigation Jump to search
 
(13 intermediate revisions by 2 users not shown)
Line 1: Line 1:
 +
[[Category:Vocabulary]][[Category:StyleGuides]]
 +
 
== Overview ==
 
== Overview ==
 +
In order to provide consistency in how models and concept domains are interpreted, a set of naming conventions pertaining to concept domains have been developed.  This will help vocabulary users in identifying existing concept domains that may meet their requirements, as well as provide a consistency for developing and reviewing vocabulary updates. 
  
 
== Naming Conventions ==
 
== Naming Conventions ==
  
When naming Concept Domains, the following naming conventions will be applied:
+
''Root'' concept domains are assigned to a specific RIM class attribute or HL7 Abstract Datatype property.  The naming standard for all ''Root'' concept domains is as follows:
 +
 +
* ['''RIM Class Name'''] + ['''attribute name'''] or
  
* Concept Domain names shall begin with the applicable parent class name (Act, Entity or Role) as appropriate.
+
* ['''Abstract Datatype Name'''] + ['''property name''']
  
* Concept Domains shall end with '''Type'''
+
For all concept domains that specialize a root concept domain, their names shall begin with a print name qualifier followed by the root concept domain name. 
  
 +
Note: Where the attribute name or property name is '''Code''', it will be changed to '''Type'''.  This is necessary to avoid confusion as concept domains are essentially categorizations, and do not in and of themselves contain codes of any type.
  
  
=== Act Examples ===
+
=== Example - RIM Class ===
  
Where ''PrintName'' is the name of the domain being considered for addition, the following examples attempt to illustrate the application of the naming conventions.
+
Where RIM Class Name = ''Act'' and attribute name = ''Mood'', the concept domain is ''ActMood''
  
==== ActReason ====
 
  
ActReason -> '''Act'''''PrintName''''''ReasonType'''
+
=== Example - Domains That Specialize a Root Concept Domain ===
  
==== ActConsentType ====
+
Where the concept domain is ''ActMood'', and the specialized print name qualifier is ''Proposal'' the specialized concept domain is ''ProposalActMood''
  
ActConsentType -> '''Act'''''PrintName'''''ConsentType'''
+
== Backwards Compatibility ==  
 
 
==== ObservationType Subdomain ====
 
 
 
ObservationType -> '''Act'''''PrintName'''''ObservationType'''
 
 
 
 
 
=== Role and Entity Exceptions ===
 
 
 
For the RoleCode and EntityClass concept domains, the concatenation of the '''Class''' and '''Type''' strings will be added as a suffix to the ''PrintName''.
 
 
 
==== RoleCode ====
 
 
 
RoleCode -> '''PrintName''''''RoleType'''
 
 
 
SpecializedRoleType -> ''PrintName'''''SpecializedRoleType'''
 
  
==== EntityCode ====
+
At this time there will be no effort to modify existing concept domains to adhere to the naming conventions specified here.  While changing the name of a domain is easy, any modification of an existing domain name will necessitate an update to all models making use of that domain.  For the time being, this effort is considered unreasonable and focus will be directed at ensuring new domains are named in accordance with the recommended naming conventions.
  
EntityCode -> '''PrintName''''''EntityType'''
 
  
SpecializedEntityType -> ''PrintName'''''SpecializedEntityType'''
+
== Value Sets ==
 
 
== Backwards Compatibility ==  
 
  
There will be no effort to modify existing concept domains to adhere to the naming conventions specified here.  Any modification of an existing domain name will necessitate an update to all models making use of that domain.  For the time being, this effort is considered unreasonable and focus will be directed at ensuring new domains are named in accordance with the recommended naming conventions.
+
'''NOTE''':  [[Value_Set_Naming_Conventions|Value Set naming]] are document elsewhere.

Latest revision as of 20:13, 7 February 2016


Overview

In order to provide consistency in how models and concept domains are interpreted, a set of naming conventions pertaining to concept domains have been developed. This will help vocabulary users in identifying existing concept domains that may meet their requirements, as well as provide a consistency for developing and reviewing vocabulary updates.

Naming Conventions

Root concept domains are assigned to a specific RIM class attribute or HL7 Abstract Datatype property. The naming standard for all Root concept domains is as follows:

  • [RIM Class Name] + [attribute name] or
  • [Abstract Datatype Name] + [property name]

For all concept domains that specialize a root concept domain, their names shall begin with a print name qualifier followed by the root concept domain name.

Note: Where the attribute name or property name is Code, it will be changed to Type. This is necessary to avoid confusion as concept domains are essentially categorizations, and do not in and of themselves contain codes of any type.


Example - RIM Class

Where RIM Class Name = Act and attribute name = Mood, the concept domain is ActMood


Example - Domains That Specialize a Root Concept Domain

Where the concept domain is ActMood, and the specialized print name qualifier is Proposal the specialized concept domain is ProposalActMood

Backwards Compatibility

At this time there will be no effort to modify existing concept domains to adhere to the naming conventions specified here. While changing the name of a domain is easy, any modification of an existing domain name will necessitate an update to all models making use of that domain. For the time being, this effort is considered unreasonable and focus will be directed at ensuring new domains are named in accordance with the recommended naming conventions.


Value Sets

NOTE: Value Set naming are document elsewhere.