Skip to end of metadata
Go to start of metadata

Attendance can be found Here

Co-Chair and Key Participant information can be found on the Agenda found Here

Discussion items

11:07Naming SystemPeter

Naming System is a tightly and narrowly defined resource that is still at Maturity Level 1. A curated namespace that issues unique symbols within that namespace for the identification of concepts, people, devices, etc. Represents a "System" used within the Identifier and Coding data types. Examples of use would be things like National Patient Identifiers.

Defines a specific code system or identifier system, so that it can be noted in a registry for other systems to find and understand an identifier.

Three 'kinds' of Naming System

  1. Code Systems
  2. Identifiers
  3. Root

In the Identifier datatype us the 'System' is referring to the the Namingsystem.


Summary of last quarter:

Currently Concept Map is only intended to represent the nature of concept equivalency. Some have raised that other relationships should be included.

Some have suggested that other relationships could be managed using supplements, but this could lead to a case

Code system supplements could only reference members within the code system that are being supplemented, and expand Concept Map to include other relation types and change the name to reflect that other relation types are permitted and update the definition accordingly

Put an invariant on Code System Supplement to constrain the resource to only reference items within the code system and supplement. You cannot create properties that reference other code systems.

New discussion:

Concept Map is intended to create associations between concepts from different code systems. Code System Supplement is intended to extend the available attributes/properties/relationships within ONE SINGLE code system. ←Do we redefine Code System Supplement as such?

Action items

  • Update the Identifier data type 'System' element to explicitly reference 'Namingsytsem' as opposed to 'namespace' in the description AND definition as well as in descriptive text throughout the datatype.
    In our effort to evaluate the maturity level of Namingsystem we need to clarify the intent of the resource with examples Peter Jordan
  • No labels

1 Comment

  1. Given that the Identifier data type is normative, perhaps we should regard the following entry in the description of the Identifier data type as sufficient...

    If the system is a URL, it SHOULD resolve. Resolution might be to a web page that describes the identifier system and/or supports look-up of identifiers. Alternatively, it could be to a NamingSystem resource instance.

    Noting that the system element may not always be populated by an instance of a Naming System resource. In terms of providing examples of NamingSystems within the definition of the resource itself, it might be indicative that I found the examples already provided to be sufficient when creating instances for NZ identifiers and code systems.  Further, local, examples are probably best housed in Implementation Guides.