Working Paper
Draft 1.0
February 1999
1

Data Registry Content Consistency
Contents
-------------------------------------------------------------
Foreword
Introduction
1 Scope
2 Normative references
3 Definitions
4 Registry Issues
5 Levels of Abstraction
6 Complex Data
7 Use Cases
Normative Annexes
Informative Annexes
A Example of Registry Population
B Informative References
2

Foreword
ISO (the International Organization for Standardization) and the IEC (the International
Electrotechnical Commission) form the specialized system for worldwide standardization. National bodies that are members of ISO or IEC participate in the development of International Standards through technical committees established by the respective organization to deal with particular fields of technical activity. ISO and IEC technical committees collaborate in fields of mutual interest. Other international organizations, governmental or non-governmental, in liaison with ISO and IEC, also take part in the work.
This document was prepared by ISO/IEC JTC 1/SC 32, Data Management and Interchange.
3

Introduction
The exchange of metadata between ISO/IEC 11179 metadata registries depends not only on registry software that conforms to the standard, but also on metadata contents that are compatible between registries. While the standard has provisions for data element specification and registration, there are pragmatic issues pertaining to populating the registries with content.
Based on the experiences of organizations that are implementing the standard, a technical report to explore content issues could help current and future users.
ISO/IEC 11179, Part 3 and extensions proposed to it in a related New Work Item, have concentrated on the basic attributes of data elements. Much of the work done to date is for the
"abstract" level, not "application" level data elements. Well-formed data elements and their domains can be recorded in a metadata registry as "models" for potential reuse. Additional attributes may be required to record essential facts about how a data element is used in an application. Some potential attributes include "purpose for which data is collected", "statistical methodology used in data collection" and other potential data quality attributes. What other attributes are required? There is a need to address the attributes that should be documented at the application level. This will make use of the standard's extensibility, since all application level attributes cannot be established in advance. Scientific metadata is a special case of application metadata, which seems to have additional characteristics that should be explored.
The proposed revision of ISO/IEC 11179, Part 3, models a data element (DE) and its associated data element concept (DEC). A data element consists of the data element concept plus its representation. Creation of an application data element frequently requires additional qualification of the object class and/or property. Does this creation of an application element always cause the creation of an application data element concept? Does the qualified concept inherit meaning from the standard concept to which it is related, and is there an adequate place in the current scheme to store this relationship? How are application DEC’s distinguished from other DEC’s or is there a need to make such a distinction?
Conceptualization and articulation of rules and relationships in the creation of object classes, properties, data element concepts and data elements are needed. Explication of the various possible levels of data elements and data element concepts and their relationships would greatly assist in the creation of shareable, well-formed data. Relationship and inheritance from the most abstract data element to the most concrete application data element needs to be specified. Reuse of data value domains should be enabled and regularized.
4

1 Scope
This document describes use cases and methods that 11179-compliant registries can use to implement them. It addresses topics such as the following:
How a registry handles relationships between components such as data elements and domains.
Clarifying definitions and relationships among data elements and components at differing levels of abstraction.
Reusability of data value domains that are not enumerated.
Handling data elements that are component parts of groupings.
5

2 Normative References
The following standards contain provisions, which, through reference in the text, constitute provisions for this document. At the time of publication, the editions indicated were valid. All standards are subject to revision, and parties to agreements based on this document are encouraged to investigate the possibility of applying the most recent editions of standards indicated below.
Members of IEC and ISO maintain registers of currently valid International Standards.
ISO/IEC 11179-3:1994, Information technology - Specification and standardization of data elements - Part 3: Basic attributes of data elements
ISO/IEC 11179-4:1995, Information technology - Specification and standardization of data elements - Part 4: Rules and guidelines for the formulation of data definitions
ISO/IEC 11179-5:1995, Information technology - Specification and standardization of data elements - Part 5: Naming and identification principles for data elements
ISO/IEC DIS 11179-6, Information technology - Specification and standardization of data elements
- Part 6: Registration of data elements
ISO/IEC DTR 15452, Information Technology - Specification of Data Value Domains , August,
1998.
6

3 Definitions
For the purposes of this document, the following definitions apply.
3.1 attribute : A characteristic of an object or entity.
3.2 conceptual domain : A set of possible valid value meanings of a data element expressed without representation.
3.3 context : A designation or description of the application environment or discipline in which a name is applied or from which it originates.
3.4 data element : A unit of data for which the identification, meaning, representation and permissible values are specified by means of a set of attributes.
3.5 data element concept (DEC) : A concept that can be represented in the form of a data element, described independently of any particular representation.
3.6 data element representation: A data element component consisting of a value domain and representation class.
3.7 data identifier : A language independent unique identifier of a data element within a registration authority. An unambiguous name for an object within a given context.
3.8 data item : An occurrence of a data element value.
3.9 data value : An element of a value domain.
3.10 data value domain : A set of possible valid values of a data element expressed in a certain representation, for a data element having a value domain.
3.11 enumerated domain : A value domain that is specified by a list of all permissible values.
3.12 identifier : See data identifier.
3.13 international registration data identifier (IRDI) : The unique and registered identifier of a data element.
3.14 name : The primary means of identification of objects and concepts for humans.
3.15 object class : A set of ideas, abstractions, or things in the real world that can be identified with explicit boundaries and meaning and whose properties and behavior follow the same rules.
7

3.16 permissible value (label) : An expression of a value meaning in a specific value domain.
3.17 property : A peculiarity common to all members of an object class.
3.18 representation class : A classification of types of representations.
3.19 structure set : A method of placing objects in context, revealing relationships to other objects.
Examples include Entity-Relationship Models, taxonomies, and ontologies.
3.20 value meaning : A valid value in a conceptual domain.
3.21 value meaning identifier (VMID) : A label that uniquely identifies a value meaning.
TBA: registry
8

4. Registry Issues
As organizations gain experience with populating and managing metadata registries, they have faced a number of data management challenges related to making the registries useful to a variety of users. Current implementations of registries that are compliant with the International
Organization for Standardization (ISO) Standard 11179 vary widely in their contents and interface styles. All of the registries, even though they have different missions and user populations, struggle with the same challenges. The major goal of any registry is to provide metadata on organizational data elements that is presented in a meaningful fashion to encourage reuse of data element specifications and value domains.
This clause describes issues that have surfaced as an organization implemented a data registry by mapping existing data elements to registry elements.
4.1 Registry Goals

To promote reuse of well-formed data elements and to enable data sharing, via provision of well-formed standard data elements that have concise definitions and attributes, as well as managed sets of data element values or standard reference domains (code sets).

To provide a catalog to an organization's data with an inventory of data elements in major systems and to provide the basis for informed data administration.
4.2 Levels or Types of Data in the Registry
In pursuit of the goals defined above, a diverse array of data has been entered into the database, and several different levels of data elements have emerged.
The first level reference data elements (also referred to as Core, Generic, and Abstract) are fully described data elements used in a number of applications across the enterprise. These are the kinds of data elements that would be found in the Core module of an integrated information system, although often with some additional descriptors. They provide the basis for developing good data elements in applications that enable data sharing and domain reuse. They can be the basis for forming building blocks of information systems, but always need additional context expressed in metadata attributes to accurately reflect what is in the applications. Zone
Improvement Plan (ZIP) Code implies a generic definition, a set of domain values, and a data format, but nothing more. Reference data elements are often associated with a reusable domain of values, such as State codes, but may also be associated with a non-enumerated domain such as latitude measure. Mailing Address Zip Code is another level of a reference data element. It
9

provides a good, specific, reusable definition of a data element, and may imply a subset of a domain.
The second level make up the logical data elements, or those data elements that would be found in a logical model of an enterprise. They contain the full description of data element attributes found in Level 1, but also carry the information added by a data model which places the data element in a context. For example, Facility Mailing Address Zip Code provides a more accurate description of the information content of a field than just Zip Code, or Mailing Address Zip
Code.
The third level make up the physical data elements, or those data elements that would be found in a physical model of the enterprise. Fully documented, these data elements are sufficiently specific to form the basis for data exchange and reporting. In addition to the attributes describing Facility Mailing Address Zip Code, a physical data element would carry the application system and table location information that would provide sufficient attributes to enable a complete understanding of the information and use of the data element for query or exchange purposes.
In the process of registry construction, a fourth level of data may exist. These data elements have incomplete, unreviewed metadata that has been drawn from a data dictionary or Computer
Aided Software Engineering (CASE) tool. They represent actual system data but may not be defined sufficiently to form the basis for data sharing without further analysis. Eventually, additional attributes could be added to these data elements, or they could be associated with a standard data element to add sufficient documentation to make them complete physical data elements.
Some data elements could be logically grouped within complex data elements. For example,
Person First Name, Person Last Name, and Person Middle Initial might be components of a data element called Person Name. In the future, the registry will be modified to enable data elementto-data element links, which will enable the formation of complex data element relationships, or the linking of a conforming application data element to a related standard data element.
10

Although metadata registries may contain diverse data (or data at a number of levels of abstraction - see clause 5), the data elements may not need to be tagged with a level identifier. It is difficult to anticipate all possible levels of data elements, and the levels may be difficult to portray to the registry users. In addition, some of the levels represent the level of data element compliance with the standard. Each registration authority can specify their registration process, and may want to set criteria for data element standard compliance, but it may be difficult to distinguish compliance levels and would constitute a significant administrative burden.
4.3 Interface Design to Respond to Use Cases
At the present time, the registry does not tag data elements by level, as the levels are not included in the ISO 11179 model, nor are they well-defined. Instead, the registry is modifying its user interface to highlight the queries by current data element groupings that will respond to user needs. Featured queries will include:

Data elements by subject-area standard document (biological identification, chemical identification, date, facility identification, Standard Industrial
Classification/North American Industry Classification System (SIC/NAICS), and latitude/longitude).

Data elements by thematic group (regulatory, location, facility identification, organization, point of contact, ecological areas, chemical substances). Thematic subgroups may be created, allowing the groups query to provide basic components of an agency data architecture which implies relationships or associations between data elements and groups of data elements (entities).




Data elements by application system.
Data elements by standards status (registration and administrative).
Data elements by keyword.
Data elements associated with other data elements. For example, Facility Mailing
Address State Name could be associated with State Name so that a user of a facility standard or thematic group could easily find the standard value domains and well-defined reference data element.

Data elements associated with a data concept.
4.4 Related Objects in the Registry
The metadata concepts in ISO 11179 have been applied throughout the registry. Not only does the system store attributes about data elements, but also about systems, which are
11

sources of data elements, and about documents, which can be sources of data elements. It also registers Electronic Data Interchange (EDI) message sets that have a number of data elements as components. In time, keywords and data concepts and object classes may be derived from a linked thesaurus to ensure common usage of terminology.
Thus, if you drill down through the layers of information, you can obtain substantial amounts of information on the context of a data element, and the quality of the information resource. This additional metadata enhances the usefulness of the registry, making it a more complete repository of organizational metadata. The registry can be used to manage information on data concepts, data elements, data standards, data systems, value domains, related classification terminology, and standards-related documents.
4.5 Conceptual Domains and Data Value Domains
Currently each recorded data element in the registry is associated with a conceptual domain, and each conceptual domain is associated with a value domain. Some value domains are enumerated (i.e., State Code) and some are non-enumerated (sometimes called determinant) (i.e., latitude measure). Each value domain is associated with a welldefined data element. This enables a system developer to locate a data element of interest, and to download the data element attributes, along with the related permissible values and value meanings for direct use in a new information application. Although some users may simply be seeking the list of codes or names in a value domain, it is useful to get the associated data element, as that information aids in use of the standard data element attributes.
An eventual goal of the registry is to enable searching across value domains to find individual data values. Until that capability is developed, value domains are located through data element searches.
4.6 Summary of Issues
The following issues were raised in this registry implementation:

Levels of data elements and mapping of existing elements to registry components.

Grouping of existing data elements to facilitate information retrieval.

Handling related objects in the registry.

Linking of domains with data elements.
12

5 Levels of Abstraction
This clause presents a conceptual framework for structuring data elements in a registry and mapping existing data elements to registry components.
Data elements are ideally the result of a process of development, involving several levels of abstraction. Levels progress from the most general (conceptual) to the most specific
(physical). The objects at each level are called data element components. Using the
Zachman Framework, for instance, the highest levels of definition are contained in the business view; development progresses to the implemented system level.
After the conceptual components are developed by a process of specification from the highest conceptual level, a representation term is assigned which may in turn be derived from a structure set or process. Components are envisioned as a set of building blocks that can be assembled into data elements, and serve to ensure that the end product, the total set of data elements, is as discrete and complete as possible.
5.1 Developing Levels of Abstraction
Data element development begins at the conceptual level (See Figure 1). At this stage, a set of concepts exists as entities or objects (called object classes), which, with the assignment of properties, become data element concepts (DECs). An object class represents an idea, abstraction or thing in the real world, such as tree or country. A property is something that describes all objects in the class, such as height or identifier.
From the examples above, we can form the DECs tree height and country identifier.
DECs also contain conceptual domains, which are composed of value meanings. These value meanings are defined but do not have a specific form of representation (Figure 2).
The next step in forming data elements takes place at the logical level. A complete logical data element must include a form of representation for the values in its data value domain. For example, name, code, and measure can be applied to the DECs above to produce tree height measure, country identifier name and country identifier code.
13

Figure 1. Components of a Data Element
Data Element Concept
Object Class
Property
Conceptual Domain
Value Meaning
Permissible
Values
Data Value
Domain
Representation Class
Data Element Representation
Data Element Model
14

Figure 2. Levels of Abstraction
DATA ELEMENT
Data Element Concept
Object Class
Property
Conceptual Domain
Value Meaning
Conceptual
Level:
Object Class and
Property
Permissible
Values
Representation
Class
Data Element Representation
Data Value
Domain
Data Element Model
Logical Level:
Representation
With addition of
Qualifier,
Application Level
15

Some logical data elements can be considered generic elements. These are data elements that have a well-established data value domain and are recognized at the organizational level or above as useful and shared among several systems. Country name and country code are both potential candidates for designation as generic elements. ISO standard
3166, Codes for the representation of names of countries , presents a well-established reference list of country names and codes.
Note that this is the highest level at which true data elements, by the definition of ISO
11179, appear: they have an object class, a property, and a representation.
The next level of data element development is the application level. Typically, a data element will be customized to an application by subsetting its data value domain or narrowing the definition (or both) to include only those values of interest to the application. For example, if an application of Country name were to list all the countries a certain organization had trading agreements with, the application data element would be called Trading partner country name. The data value domain would consist of a subset of countries listed in ISO 3166. Note that the qualifier term trading partner is itself an object class. This relationship could be expressed in a hierarchical relationship in the data model.
The last type of data element is the physical data element. These are the elements which actually appear in the database table column headers, file descriptions, EDI transaction file layouts, etc.
16

6 Complex Data
Many organizations produce data for internal or external use. As a result, information that describes that data (metadata) must be readily available. With the advent of electronic access to data through the Internet and other media, the metadata must be accessible electronically, too. Registries are deployed to manage and organize the metadata, and standards such as ISO/IEC 11179 address the content and basic functions of those registries.
Organizations around the world are implementing registries based on the framework described in ISO/IEC 11179 and the metamodel defined in ANS X3.285. However, the framework has limitations that constrain the usefulness of the registries. The proposed modifications to ANS X3.285 will remedy some of these limitations.
ISO/IEC 11179 addresses the specification and standardization of data elements. The metadata that is specified in the standard describes data elements at the fundamental level. Organizations that produce and use data generate new data elements from existing ones, and the standard does not address this issue. Also, object oriented technology, multimedia applications, and advanced scientific applications produce very complex data types that are not described very well by the standard.
Some data elements are generated from other existing ones in many ways. Mathematical calculations (e.g. variance estimations), aggregation (e.g. multivariate cross tabulation), concatenation (e.g. formation of telephone number from its constituent parts), or grouping (e.g. address) are typical examples. Metadata registries that contain the descriptions of how data elements are generated from others will help users to understand the data more fully.
Even the fundamental data elements of an organization, ones that are not generated from others in the sense described above, can be generated. The functions of the business themselves can generate data elements. Identifying these functions, especially within the context of the organization, will help users increase their understanding of data.
At this point in time, the only identified types of complex data are derived data and data groups. These are defined as
•
Derived Data Element A data element whose values are derived through a transformation of the values of one or more other data elements. This transformation may be mathematical, logical, linkages, or some other type (including a combination of these basic types).
• Data Group A set of data elements considered as a logical unit.
17

An important point about data groups is that they are equivalent to abstract derived data elements, where an abstract data element is a data element that is not part of a particular application. This view means that data groups don't need to be treated separately.
These minor changes to ANS X3.285 will improve the handling of complex data items:
• Have the Rule entity account for the transformation formula.
• Put an attribute on the relationship between Data Element and Rule, called role, to distinguish data elements which are input to a transformation and the data elements which are output from a transformation (derived).
• A lookup table entity, such as Derivation Type, is needed to keep track of the type of transformation used.
• A recursive or hierarchical relationship on Rule is necessary to account for combinations of transformations.
18

7 Use Cases
7.1 Introduction
The following use cases were developed to implement requirements for a registry developed by members of the health care industry. The need to share data developed and stored by diverse tools was recognized. A standards-based registry of shareable components is required to provide a consistent method of recording and managing this metadata.
7.2 Objectives
The objective of this registry is to provide open standards-based metadata registry services for healthcare SDOs, system developers, and other users of data standards. The proof-of-concept metadata registry will be used for the following purpose:

Capturing information about data elements

Viewing information based upon criteria

Analyzing comparisons of same or similar data concepts
 n a m e s s
 d e f f i i n i i t t i i o n s s
 a l l l l o w a b l l e v a l l u e s s ( ( c o d e s s e t t s s ) )
 f f o r r m a t t a n d s s i i z e
This effort provides for a metadata registry based on international standards, ISO/IEC
11179. In general terms, the Proof-of-concept registry will:

Contain metadata for three registration authorities

Show the interchange and sharing of information within and among industry, government, and educational environments

Show policy makers and developers a method of specifying semantics

Allow comparison of different views of common healthcare data elements
Over time, the proposed registry will:

Allow many registration authorities to enter and maintain metadata within a respective portion of the registry or their own compatible registry.

Promote the interchange and sharing of information within and among industry, government, and educational environments.

Provide system developers with easy access to accepted healthcare data standards.

Increase use of healthcare data standards in systems.
19


Provide standards users with easy access to accepted healthcare data standards.
To maximize effectiveness, this registry must have an Internet interface for general access by those working on healthcare informatics standardization. The registry itself must be based upon standards that promote the interchange and sharing of information within and among all industry, government, and educational environments. The registry must support:

Structuring from the ISO/IEC 11179 and ANSI X3.285 standards.

Use of a high-level concept framework (200 concepts).

Web based / Open / Platform independent implementation.

Scalability and Extensibility.

Dynamic selectable viewing based upon:

Elements associated with a concept showing source.

Side-by-side comparison of selected elements.
The specific actions of this task include:

Developing a registry service based upon ISO/IEC 11179 international registry standards.

Implementing a registry model derived from registry applications.

Implementing a Web user interface with queries by:
 High-level model.

Data element.

Data agreement.

Organization.

Keywords.

Registry.

Providing capability for registries supporting four represented healthcare organizations
7.3 Benefits
The benefits of the proof-of-concept metadata registry would be the demonstration of the applicability of using a standards based registry in the health informatics arena. This metadata registry would provide:

Exposure of data specifications to multiple audiences in a standardized manner

Quicker-to-find and reusable data specifications
20


Easier-to-recognize similarities and differences

Promotion of common understanding

Content administered by experts in functional areas

Ability to link to other authoritative sources
7 .
.
4 D a t t a R e g i i s s t t r y R e q u i i r e m e n t t s D o c u m e n t t
Category I – Structural Elements (Structural information includes information about elements, their attributes, and the structuring relationships in which they are involved.)
1.
Keep facts about characteristics of data so they can be used to describe, inventory, analyze, and classify data.
2.
Require information about a data element that will provide a common understanding of its meaning, representation, and identification.
3.
Base structure of the data registry on the ISO/IEC 11179 and ANSI X3.285 standards.
4.
Implement a registry derived from registry applications.
5.
Support version control for elements in the data registry.
6.
Use data elements and concepts that show names, definitions, allowable values (code sets), format, and size.
7.
Register a data element by assignment of an unambiguous identifier to the data element in such a way that makes the assignment available to interested parties.
8.
The Registration Authority Identifier is a 4 digit numeric International Code
Designator (value is 0060 for Dun and Bradstreet) and a 9 digit numeric (value is the
D-U-N-S that is assigned by Dun and Bradstreet to the organization who will be the
Registration Authority).
9.
The Data Identifier is a 7 digit numeric
10.
The Version Identifier is a 3 digit numeric.
11.
Category II – Operations, Behaviors, and Interactions (This includes information about the normal sequence of occurrences, including behaviors and interactions. The focus is on "what" happens, not "how" it happens. The ordering of sentences is inherently meaningful with respect to the problem or situation.)
1.
Queries should be available by high level model.
2.
Data registry should be able to identify, compare, and extract relevant standards.
3.
Information can be viewed based on criteria.
4.
Comparisons of same or similar data concepts will show names, definitions, allowable values (code sets), format, and size.
5.
Data registry can link to other authoritative sources.
6.
Standards developers from different organizations can administer their content independent of other organizations.
7.
Queries should be available by data element.
8.
Queries should be available by data agreement.
9.
Queries should be available by organization.
21

10.
Queries should be available by keywords.
11.
Queries should be available by registry.
12.
The system will be able to link data elements to external models/views.
13.
Charter and Scope
14.
The user will be able to select data elements and request that the metadata for the data element be downloaded at any time during the session.
Category III – Exceptions and abnormal condition (These conditions cause a problem and a deviation from normal operations whenever it is detected.)
Category IV – Expectations and Non-functional requirements (Expectations typically are requirements that are impossible to quantify; for example, "The user interface must be easy to use." Non-functional requirements include performance requirements and implementation or run-time environments.)
1.
Data registry must have an Internet interface.
2.
Data registry should be Web based, open, and platform independent implementation.
3.
Data registry utilizes a Web user interface based on an existing registry.
4.
Data registry should be scalable and extensible.
5.
A secure environment will allow widely distributed customers from multiple organizations to maintain, register, publish, and distribute data element information.
Category V – Administrative requirements (System Administration Requirements specify the client's need to modify, configure, and tune the previously stated requirements. This can happen while the application is running or when it is "down".)
22

7.4.1 Generate Version Comparison Matrix Use Case
Name Generate Version Comparison Matrix
Summary User selects a data element, and versions of the data element metadata are displayed in matrix format to facilitate comparison.
Goal Allow a user to determine what has changed between the various versions of a data element.
Standards Developer. Actor(s)
Pre-Conditions User enters Services area of data registry.
System restricts data elements to those included in previously selected registration authorities.
Begins When
Description
Ends When
Exceptions
User selects Generate Version Comparison Matrix report.
1.
System displays Data Elements Search area.
2.
User selects a data element.
3.
System displays version comparison matrix with rows for the metadata specifications. The columns include the row descriptions in column one and the data element information in the other columns.
The system will highlight what metadata has changed between the various versions. (See
Attachment 1 for example.)
System displays version comparison matrix.
None.
Post-Conditions None.
Traceability II.2 Data registry should be able to identify, compare, and extract relevant standards.
II.4 Comparisons of same or similar data concepts will show names, definitions, allowable values (code sets), format, and size.
23

Attachment 1
Data Element ID : 0060 123456789 0001492
Version : 5
Type : Data Element
Data Element Sex
4
Data Element
Gender
3
Data Element
Sex-Category Code
Name :
Definition : The sex of the person. The code indicating the The code that represents a gender of the patient or insured. classification of an organism according to the reproductive function.
As recommended by the DoD Standard Context : Required for analyses of service utilization, needs for services, and epidemiological studies.
Uniform Hospital
Discharge Data Set
(UHDDS) and the
Uniform Ambulatory
Care Data Set (UACDS)
Person Gender Synonymous Gender
Name : Sex Code
Representational ISO / IEC 646
Category :
Representational Code
Form :
Datatype : Integer
ISO / IEC 646
Code
ISO / IEC 646
Code
Maximum Size : 1
Representational N
Layout :
Data Domain : 1 Male
2 Female
3 Indeterminate
9 Not stated / inadequately described
Character
1
1
A
M Male
F Female
U Unknown / not stated
Integer
1
1
N
1 Male
2 Female
0 Indeterminate
9 Unknown
Current Retired
Status :
Status Date : 18 Jul 1998
Submitting Health Care Policy
Organization :
Source Document ISO 1977
10 Feb 1997
Personnel
Employees' Handbook
10 Feb 1997
Health Care Policy
:
Comments :
Note: The method that the system will use to highlight a change is being determined. Changes are not highlighted in this example.
24

7.4.2 View Information Based on Criteria Use Case
Name View Information Based on Criteria
Summary User selects data element search. The system displays a form where the user specifies the criteria to be used in the search. This criteria can be a word used in a name or definition and further limited by such criteria as the registration authority, data element type, administrative and registration status, submitting organization, or application system. Based on the criteria, the system will display a list of names for the data element type from which the user may drill-down to more detail.
Actor(s) Standards User, System Developer, Standards
Developer
Pre-Conditions None.
Begins When User selects data element search.
Description
Ends When
Exceptions
1.
System displays a search query form screen. (See
Attachment 1.)
2.
User fills in criteria or accepts the defaults provided by the system.
3.
System displays a list of names meeting the criteria.
4.
User selects a name.
5.
System displays information in standard format.
System displays detailed information in standard information.
No information found meeting the criteria. System will display error message and pointer to query the help screens.
Post-Conditions User may request that detail information for previous name or next name in the query result list be displayed.
Traceability II.3 Information can be viewed based on criteria.
II.7 Queries should be available by data element.
II.11 Queries should be available by registry.
25

Attachment 1
This query allows you to retrieve information from the United States Health Information Knowledgebase about data elements, data element concepts , derived data elements , or composite data elements . You can select data elements by using any combination of the following: words in the names or definition, the administrative status, and the registration status.
Registration Authority :
Data Element Type :
Word:
Search Options:
Selection Options:
Containing Beginning With Exact Match
Name Only Definition Only
Both Name and Definition (Performs Only the Search Option Choice "Containing".)
Administrative Status :
Registration Status:
Submitting Organization:
Responsible Organization:
System:
as at :
Begin Search Clear and Start Over
The following criteria should have drop down lists:
Registration Authority
Data Element Type (All, Composite Element, Data Element, Data Element
Concept, Derived Data Element)
Administrative Status (All, Current, Superseded, Trial = AHIW statuses, All,
Rejected, Proposed, Test, Draft, Accepted, Interim, Final = EDR statuses)
Registration Status (All but Legacy/Incomplete, All, Phased-out, Retired,
Certified, Legacy, Recorded, Standardized, Incomplete = EDR statuses)
Submitting Organization
Responsible Organization
System
26

7.4.3 Show Data Element Usage Use Case
Name Show Data Element Usage
Summary User selects a data element, and the system displays a list of data elements linked directly or indirectly to the
Goal
Actor(s) data element. The user then both selects and requests the display of information for an individual data element on the list or selects several data elements on the list and requests the generation of a comparison matrix report.
Allow a user to identify possible sources of additional information on a data element's meaning and usage by reviewing other information linked directly or indirectly to it.
Standards User, Standards Developer.
Pre-Conditions User enters Services Area of data registry.
Begins When
Description
User selects Show Data Element Usage report.
Ends When
Exceptions
1.
System displays a data element search screen that allows a user to make a selection based on a data element name or letter of alphabet.
2.
User requests a data element name or a letter of the alphabet.
3.
System displays a list of data elements beginning with the data element name closest to the word entered or beginning with the selected letter of the alphabet.
4.
User selects a data element.
5.
System displays a list of data elements that are linked directly or indirectly to the data element.
(See Attachment 1.)
System displays data usage information.
None.
Post-Conditions User can select a data element, and the system displays its information in the standard format.
User can select several data elements and request the generation of a comparison matrix.
27

Traceability
User can select a data element and request a show data element usage be generated.
II.2 Data registry should be able to identify, compare, and extract relevant standards.
28

Attachment 1
This is an example for data element Person-Gender.
Person-Gender MHS 0012345 1 Data Element Legacy
Direct Links
Name Reg Auth ID Vers Type Status Relationship
Type
Indirect Links
Name
Sex-Category Code MHS
Reg Auth
0002234 2
ID Vers
Data Element
Type
Current
Status Relationship
Type
Higher
Standard
Patient-Sex
Empl-Gender
Sex-Category Code
MHS
MHS
MHS
0002222
1234000
0002234
1
1
1
Data
Element
Data
Element
Data
Element
Legacy Physical condition
Legacy Physical condition
Retired Superseded by
Gender Code X12 0000253 1 Data Element Current External standard
(Note: Some possible examples of relationship type from ISO-11179 for data concepts are: "qualifier of",
"qualified by", "subject of", "part of", "physical condition", "external reference", "higher standard." The rules and conventions for relationship type need to be set.)
From AHIW:
Type of relationship
An expression that characterises the relationship between the data element and related data.
Obligation: Mandatory. Datatype: A40.
Valid values: has been superseded by superseded previous data element is a composite part of is composed of relates to the data element relates to the data element concept is a qualifier of is qualified by is used in the derivation of is derived from supplements the data element is supplemented by the data element is used in the calculation of is calculated using is used in conjunction with is an alternative to
Note: ISO 11179 does not specify a field size for this field.
29

7.4.4 Display Model Information Use Case
Name Display Model Information
Summary When a user is displaying the detail information on a data element that has been linked to a model, access to the model may be requested. The system will download the model or transfer control to another location for further processing.
Ability to show a data element in a model context. Goal
Actor(s) Systems Developer.
Pre-Conditions The model has been previously registered in the data registry and the data element has been linked to the model.
Begins When
Description
Ends When
User selects model from list provided under
'Computer Aided System Engineering (CASE) Model linked to this Data Element'.
1.
The system requests the user's name, organization name, user's telephone number, and email address and indicates whether the data model will be downloaded or that control will be transferred to other location.
2.
User provides requested information.
3.
The system downloads the data model or transfers control to the other location.
The system downloads the data model or transfers control to the other location.
Exceptions None.
Post-Conditions None.
Traceability II.12 The system will be able to link data elements to external models/views.
Overview of Data Model Access Capabilities
Initially the data registry will support two types of access to data model information. The first type provides for the downloading of the model from the data registry, which is basically free access to the model. The second type provides for the transfer of control to other location for further processing, thereby, allowing the other location to provide restricted access
30

to the model. For both these types of access, the data model must be registered with the data registry.
Implementation note: A new browser window will be opened to gather the user information. At the time the user information is being requested the user will be informed if control is being transferred to another site.
31

7.4.5 Download Information Use Case
Name Download Information
Summary While viewing a detailed data element information report, the user requests the download of the data element's metadata. The system requests some user identification information and then downloads the information.
Goal
Actor(s)
Ability to download the metadata for a data element including permissible values for a coded data element.
Systems Developer.
Pre-Conditions None.
Begins When
Description
User selects 'Download Data Element Information' from list provided when the detailed data element information report has been provided to the user.
1.
The system requests the user's name, organization name, user's telephone number, and email address and questions whether all the metadata or just the domain values are to be downloaded.
2.
User provides requested information and indicates whether all the metadata or just the domain values are to be downloaded.
3.
The system downloads the information.
Ends When The system downloads the information.
Exceptions None.
Post-Conditions None.
Traceability II.13 The user will be able to select data elements and request that the metadata for the data element be downloaded at any time during the session.
The default delimiter will be a comma, however, the user may select another delimiter from a drop down list or specify a delimiter.
Implementation note: The user's IP address will be noted and for repeat downloads the user will be asked to validate the user information. The user will be informed that a cookie will be created and that if this can not be done then repeat downloads will require re-entry of the user information.
32

7.4.6 Generate Comparison Matrix Use Case
Name Generate Comparison Matrix
Summary User selects an area of interest, various registration authorities, and then data elements that are displayed in matrix format to facilitate comparison of the metadata.
Goal Allow a user to utilize data element mappings to a high level model that were done independently and separately to group, select, and compare data elements which might have the same meaning.
Actor(s) Standards User, System Developer, Standards
Developer.
Pre-Conditions User enters Services area of data registry.
Data elements have previously been mapped to high level model.
Begins When
Description
User selects Generate Comparison Matrix report.
1.
System displays High Level Model.
2.
User selects area of interest.
3.
System displays a list of registration authorities that have data elements mapped to the selected area of interest.
4.
User selects registration authorities to be included.
5.
System displays a list of data elements that are mapped to the selected area of interest. The list also shows previously linked data elements in a matrix format. See Attachment 1 for example of format.
6.
User selects data elements to include in the comparison matrix. (Note: During the process of selecting data elements, a user can display detailed information on an individual data element to determine whether to include it or not.)
7.
System displays comparison matrix with rows for registration authority, data element ID, data element name, definition context, and data domain information. The columns include the row descriptions in column one and the data element information in the other columns. (See Attachment
33

Ends When
2 for example.)
System displays comparison matrix.
Exceptions None.
Post-Conditions User can select a data element, and the system displays its detailed information.
Traceability II.1 Queries should be available by high level AIHW model.
II.2 Data registry should be able to identify, compare, and extract relevant standards.
II.4 Comparisons of same or similar data concepts will show names, definitions, allowable values (code sets), format, and size.
II.11 Queries should be available by registry.
34

Attachment 1
The registration authorities are listed at the top of the table with the data elements linked to the selected area of interest shown the column below their name. Data elements from registration authorities that have been previously linked appear on the same row e.g. Sex, Gender, and Gender Code.
AIHW
Aboriginality
NCVHS MHS X12
Country of birth
Country of birth
Date of birth
Indigenous status
Sex Gender
Date of Birth
Martial Status
Gender Code
Marital Status Code
Sex-Category
Race or Ethnic Code
Citizen Status Code
35

Attachment 2
AIHW
Data Element NHIMG 000149 2
ID :
NCVHS
NCVHS 3
Data Element Sex Gender
Name :
Definition : The sex of the person.
MHS
Xxxx yyy DDDS 11697 2
Sex-Category Code
X12
Gender Code
Context : Required for analyses of service utilisation, needs for services and epidemiological studies.
As recommended by the DoD Standard
Uniform Hospital
Discharge Data Set
(UHDDS) and the
Datatype : Numeric
Minimum Size :
Maximum Size :
Data Domain : 1 Male
2 Female
1
1
3 Indeterminate
Uniform Ambulatory
Care Data Set (UACDS)
Numeric Numeric
1
1 Male
2 Female
1
3 Unknown / not stated
1
1
1 Male
2 Female
0 Indeterminate
9 Not stated / inadequately described
Linkages : (A determination will be made as to whether or not linkages to other data elements, data collections, data agreements, models, or initiatives should be included. If so, how will they be displayed.)
The code that represents a classification of an organism according to the reproductive function.
The code indicating the gender of the patient or insured.
ASC X12N 834
Benefit
Enrollment and
Maintenance
Implementation
Guide
Character
1
1
M Male
F Female
U Unknown
9 Unknown
36

7.4.7 View Information Based on Keyword / Synonyms Use Case
Name View Information Based on Keyword / Synonyms
Summary User enters keyword search area of data registry, locates the keyword of interest, and the system then displays data elements previously linked to that keyword.
Goal Allow a user to locate data elements based on previously established keywords, which might not be used in the data element name or its definition, but which have been linked to the data element.
Actor(s) Standards User.
Pre-Conditions Keywords have been established.
Data elements have previously been linked to keywords.
Begins When
Description
User selects keywords from the main menu or the menu at the bottom of the screen.
1.
System displays keyword search screen that allows a user to make a selection based on a word or a letter of alphabet.
2.
User requests a word or a letter of the alphabet.
3.
System displays a list of keywords beginning with the keyword closest to the word entered or beginning with the selected letter of the alphabet.
4.
User selects a keyword.
5.
System displays a list of data elements that are linked to the keyword.
6.
User selects a data element.
7.
System displays the data element information in standard format.
System displays data element information. Ends When
Exceptions None.
Post-Conditions None.
Traceability II.10 Queries should be available by keywords.
37

7.4.8 Linking to Authoritative Source Use Case
Name Linking to Authoritative Source
Summary
Goal
User researches an external data registry and finds a data element pertinent to a local data element. User enters information in the local data registry that links the data elements together. The link allows the external data element's information to be reviewed at a later time.
Ability to link data elements to information in other data registries and view the current information in that other data registry.
Standards Developer. Actor(s)
Pre-Conditions The external data registry information and minimal set of information about data elements has been registered in the general registry. See Table 1 for information required.
User enters services area of data registry.
Begins When
Description
User selects establish data element linkage.
1.
System displays list of registration authorities that are available.
2.
User selects two registration authorities (or indicates the data elements are both in the local data registry).
3.
System requests the user to enter a data element name or the beginning letter of the data element name for each of the two data elements to be linked.
4.
System display list of data element names, which may be linked.
5.
User indicates which two data elements to link and their type of relationship.
6.
System establishes linkage and informs user linkage established.
Ends When
Traceability
System informs user linkage has been established.
Exceptions None.
Post-Conditions None.
II.5 Data registry can link to other authoritative
38

sources.
Type Information
Data Registry
Information Required
Name
URL
Point of Contact Name
Point of Contact Telephone Number
Point of Contact E-mail address:
D-U-N-S
Abbreviation
Data Element
Protocol Type
Name
Definition
Registry ID
Table 1. Information about a Data Registry and its elements to registered in the general registry.
39

Following is background information on the data registry interfaces, types of control, and levels of interaction.
The data registry interface is supported by a General Data Registry that provides pointers to remote data registries, lists of their data elements with definitions and the type of protocol the data registry supports. Data elements from USHIK type data registries and other type data registries are recorded in the General Data Registry. The General Data Registry is the used to support three levels of search and linkage between various data registries.
Figure 1 Overview of Data Registry Interface provides a graphic view of
General Data Registry, USHIK type data registries and other data registries.
USHIK type data registry with direct interface to each other.
ISO 11179 type data registry where basic information was registered in the general data registry.
General data registry with pointers to data registries and lists of their data element names with definitions and registry Ids.
Figure 1 Overview of Data Registry Interface
The linkages between the local and remote data registry is at a transfer control to the remote data registry or keep control within the local data
40

registry. With the transfer control to the remote data registry linkage, the user is transferred to the home webpage of the remote data registry. There the user will use remote data registry's capabilities to find the data element of interest. The user may return to the original local data registry by using their web browser's previous button or other history list. Table 2 Controls and Interface Levels describes the level of control and the interface levels.
Table 2 Control and Interface Levels
41

7.4.9 View Information Based on Lists Use Case
Name View Information Based on Lists
Summary
Actor(s)
User selects an area of interest from the following: data agreements, data collections, initiatives, or organizations. The system shows a list of topics within that area of interest. The user selects a topic.
The system provides a general description of the topic and a list of the data elements linked to topic.
Standards User, System Developer, Standards
Developer
Pre-Conditions None.
Begins When User selects data agreements from the main menu or menu at the bottom of the screen.
Description 1.
System displays a list of data agreements.
2.
User selects a data agreement of interest.
3.
System displays descriptive information for the selected data agreement, including a list of the data elements linked to that data agreement.
4.
User selects data element.
5.
System displays data element information in standard format (See Attachment 1.)
System displays data element information. Ends When
Exceptions None
Post-Conditions User may select for display an Information Model
Entity linked to this Data Element.
User may select for display a Computer Aided System
Engineering (CASE) Model linked to this Data
Element.
User may select for display a Data Agreement that includes this Data Element.
User may select for display a Data Collection that includes this Data Element.
User may select for display an Initiative that references this Data Element.
User may select for display a Keyword that is related to this Data Element.
User may download this Data Element's information.
Traceability I.1 Keep facts about characteristics of data so they can
42

be used to describe, inventory, analyze, and classify data.
I.2 Require information about a data element that will provide a common understanding of its meaning, representation, and identification.
I.3 Base structure of the data registry on the ISO/IEC
11179 and ANSI X3.285 standards.
I.4 Implement a registry derived from AIHW
Knowledgebase Registry and EPA Environmental
Data Registry applications.
I.4 Support version control for elements in the data registry.
I.5 Use data elements and concepts that show names, definitions, allowable values (code sets), format, and size.
II.8 Queries should be available by data agreement.
43

Attachment 1
Identifying and Definitional Attributes
Data Element ID : NHIMG 000149 Version No : 2
Type : Data Element
Status : Current 01-JUL-98
Definition : The sex of the person.
Example :
Context : Required for analyses of service utilization, needs for services and epidemiological studies.
Synonymous Name :
Gender
Comment :
Data Collection Methods :
Relational and Representational Attributes
Representational Form : Code
Representation Layout : N
Unit of Measure :
Precision :
Minimum Range :
Maximum Range :
Data Domain : (Note: This should include the permissible value, domain meaning name, and domain meaning definition text.)
1 Male
2 Female
3 Indeterminate
9 Not stated / inadequately described
Related Data References : is used in the derivation of Diagnosis related group
NHIMG 000042 vers 1 supersedes previous data element Sex NHIMG 000149 vers 1
Administrative Attributes
Date of Submission :
Source Document :
Source Organization :
Data Element Links
44

Information Model Entities linked to this Data Element
NHIM Demographic characteristic
Computer Aided System Engineering (CASE) Model linked to this Data Element
HREXP Person-Gender
Data Agreements which include this Data Element
National minimum data set - institutional health care from -
01/JUL/1994 to -
Data Collections which include this Data Element
Initiatives known to reference this Data Element
Keywords relating to this Data Element
Download Data Element information
45

7.4.10 Maintain Data Element Status Information Use Case
Name Maintain Data Element Status Information
Summary A user establishes a new version of a coded data element, which includes new permissible values and other metadata changes.
Goal Ability for a designated group of users to be given update authorization for a specific set of data elements.
Standards Developer. Actor(s)
Pre-Conditions User has been assigned a User ID and designated as a member of various update groups. (See Maintenance
Capabilities Background Information below.)
User has logged on.
Begins When
Description
User requests the ability to maintain a specific data element.
1.
System displays the data element's information for single entry type attributes (such as definition, example, context, datatype, minimum size, etc) in fields that allow the user to change their values.
The system also displays update command buttons for multi entry type attributes (such as data domain, links to information models, links to
CASE models, links to data agreements, etc) that allow the user to request update capabilities for those specific attributes or a finished command button.
2.
User makes changes to the single entry type attributes and selects a multi entry type attribute for updating or a finished command button.
3.
System updates the single entry type attributes. It displays an update screen for the multi entry type attribute along with command buttons for update access to the single entry type attributes, other multi entry type attributes, or a finished command button.
4.
User makes changes to the specific multi attribute and selects a finished command button.
5.
System updates the multi entry type attribute and
46

Ends When displays a data element update message.
System informs user that an update has been completed.
Exceptions None.
Post-Conditions None.
Traceability I.5 Support version control for elements in the data registry.
II.6 Standards developers from different organizations can administer their content independent of other organizations.
IV.5 A secure environment will allow widely distributed customers from multiple organizations to maintain, register, publish, and distribute data element information.
Maintenance Capabilities Background Information
User ID's and groups control the create, update, and delete capabilities for the data registry. Users who require create, update, and delete capabilities are given user ID's and are assigned to one or more groups. There are two types of groups, administrative and update. Administrative type groups can:
1) assign users to an update group(s), 2) specify the update group that can maintain a data element, and 3) create or delete data elements. Update type groups can change the metadata for data elements that have been assigned to the group, but can not create or delete data elements.
Note: For the initial release of the data registry, the HIRS team will administer the user ID's and groups. Requests for user ID's and group assignments will be handled via email to designated HIRS personnel.
47

Annex A: Example of Registry Population
48

Annex B: Informative References
[1] ISO 1087:1990 Terminology - Vocabulary
[2] ISO/DIS 1087-1 Terminology work - Vocabulary - Part 1: Theory and application
(Partial revision of ISO 1087:1990)
[3] ISO/DIS 1087-2 Terminology work - Vocabulary - Part 2: Computer applications
(Partial revision of ISO 1087:1990)
[4] ISO/IEC 2382:1979-1998 Parts 1-32 Information technology - vocabulary
[5] ISO 2788:1986 Documentation - Guidelines for the establishment of monolingual thesauri
[6] ISO 3166-1:1997 Codes for the representation of names of countries and their subdivisions.
[7] ISO 5964:1985 Documentation - Guidelines for the establishment of multilingual thesauri
[8] ISO/IEC 7826-1:1994 Information technology - General structure for the interchange of code values - Part 1: Identification of coding schemes
[9] ISO/IEC 7826-2:1994 Information technology - General structure for the interchange of code values - Part 2: Registration of coding schemes.
[10] SC32 N0147 Horizontal Issues and Encodable Value Domains in Electronic
Commerce.
[11] Zachman, John A., The Framework for Enterprise Architecture: Background,
Description and Utility , 1997, http://www.ozemail.com.au/~visible/papers/zachman3.htm
49