Requirements for a Data Element Repository



Requirements for a Data Element Repository

Value of a Data Element Repository to HL7

Multiple groups both outside and inside of HL7 are beginning in earnest to define clinical data elements. Lack of coordination of the content produced from these efforts will dilute if not render useless the standards produced. Success from these efforts depends on authoritative, ubiquitous specification, including definition of Data Elements, the basic units of data[1]. Such standard data elements are not easily obtained, for example, rather than one authoritative source, there may be multiple authoritative stakeholders. Further, these stakeholders may not be known to each other. Therefore, obtaining standard data elements has a substantial search and discovery component, followed by a necessary evaluation and agreement component. Both technology and process are needed to facilitate such standardization of the units of data that we collect, store and use in healthcare. While standard data elements can be achieved without facilitative technology, manual efforts will remain small and not scale to meet the international need. This document outlines the requirements for an important component of the facilitative technology, a data element repository.

As stated in ISO/IEC 1179-3, “MDR's are organized so that those designing applications can ascertain whether a suitable object described in the MDR already exists. Where it is established that a new object is essential, its derivation from an existing description with appropriate modifications is encouraged, thus avoiding unnecessary variations in the way similar objects are described. Registration will also allow two or more administered items describing identical objects to be identified, and more importantly, it will identify situations where similar or identical names are in use for administered items that are significantly different in one or more respects”1.

A key step in standardizing data elements is to evaluate existing data elements that are possible semantic matches. This involves first finding possible matches, and second a comparison to identify possible matches. Today, the finding occurs manually through identification of likely sources, e.g., clinical professional societies, and through manual searches through documents, publications, clinical guidelines, data collection forms, database schemas, and data element repositories where they exist. In the absence of facilitative technology, the identification of matches occurs by human comparison. Neither of these will support the scale of effort envisioned by the Clinical Interchange and Interoperability Consortium (CIIC) formed last April from clinical professional societies. Importantly, these societies look to HL7 for guidance and support in their efforts to define and standardize data elements used in their clinical domains. Today, we remain ill-equipped to support a goal central to HL7’s mission.

The following HL7 Work Groups _____________ have defined the following functional requirements for a data element repository that will facilitate both searching for data elements and identifying possible semantic matches. In addition, an approach for linking HL7 technical specifications and DCMs, templates, archetypes, and DAMs to their component data elements is identified.

Data Element Repository Functional Requirements

1.0 Input of Data Elements

1.1 Displays data entry screens where data element attributes (defined in Appendix X) can be key-entered

1.2 Allows importing data elements in the format defined in Appendix X from csv, pipe, or tab delimited, xml, or Excel spreadsheet

1.3 Assigns a unique data element identifier (oid?) upon loading

2.0 Management of Data Elements

2.1 Supports statuses “registration status”1 to manage a registration lifecycle. These statuses should be definable and changeable by the steward of the repository over time as the registration lifecycle process changes. Example statuses are pre-submission, draft, informative, normative, and deprecated.

2.2 Supports programmatic (batch) changing of statuses based on data element attributes

2.3 Supports manual, one at a time, changing of statuses

2.4 Supports manual, multiple data elements at a time, changing of statuses, i.e. query returns 10, the user wants to select three individual data elements and change those statuses only.

3.0 Data element Storage

3.1 Supports the ISO 11179 model with extensions as defined in Appendix X.

3.2 Stores historical information and displays the creation and change history for individual data elements in a user friendly representation

3.3 Ability for the repository steward to roll-back the repository to a point in time

3.4 Stores valid values for the data elements (do we want to do this?)

4.0 Data Element Browsing

4.1 Supports form-based query on all Data Element attributes

4.2 Allows user to select data elements and “save them” for download later during that session for public users, anytime later for authenticated users

4.3 Supports comparison of uploaded data element set with repository contents; uses a form-based query to identify match attributes, and allows AND, OR combinations of attributes for the match

4.3.1 displays the results of the comparison, listing the compared data element with the possible semantic matches

4.3.2 Allows user to remove possible matches from the display and results, i.e., those deemed to not be important for consideration

4.3.3 Allows download of the comparison results

4.3.4 Allows authenticated user to save search results

4.4 Helps browsing by using key attributes as navigation aids, i.e., therapeutic area, owner, status, etc, (these will need to be defined)

5.0 Export / Downloading Data elements

5.1 outputs to a download file user selected data elements in the formats described in 1.2

6.0 Data Element / Registration Lifecycle

6.1 Supports exposing data elements for public comment as sets

6.2 enables registration of comments against a data element (requires authentication, possibly of external parties, i.e., CIIC members)

6.3 enables logging of responses to comments

7.0 Access control

7.1 Supports role-based access control

7.2 Facilitates public assess requiring no user authentication

8.0 Authentication

8.1 Uses HL7 userID and password for roles requiring authentication

Other Considerations:

First, registration, as defined in ISO/IEC 11179-1, “is the set of rules, operations, and procedures that apply to an MDR”2. Registration requires a set of

procedures for managing the registry, submitting data elements for registration, and maintaining subject matter responsibility/ownership, called stewardship here, for submitted data elements. Managing such a repository will require dedicated staff. This staff will curate and manage content, help users obtain and interpret output, answer questions about the repository, and manage access control for the repository. Managing such a repository also includes the following as described in ISO/IEC 11179-1:

▪ Monitoring adherence to rules for providing metadata for each attribute

▪ Monitoring adherence to conventions for forming definitions, creating names, and performing classifications

▪ Determining whether an administered item still has relevance

▪ Determining the similarity of related administered items and harmonizing their differences

▪ Determining whether it is possible [and necessary] to ever get higher quality metadata for some administered items

Secondly, designation of a single national or international repository may not be necessary. To take a metadata driven approach and maximize the benefit of standard data elements, individual organizations will need an institutional repository. Such a repository would be the receptacle for standard data elements, would serve as the source of metadata for operational systems, and would be used to automate the transform from operational systems to clinical data repositories and warehouses. It may follow that SDOs specifying data element content may host their repositories. Such an approach would work if there were a Data Element Exchange Message or Service. Such an interchange vehicle would enable a MDR administrator to query other repositories and send the results to their local repository.

References

1. ISO/IEC. 11179-3:2003 Information Technology Metedata Registries (MDR) Part 3 registry metamodel and basic attributes2003.

2. ISO/IEC. 11179-1:2004 Information Technology - Metadata registries (MDR) - Part 1: FrameworkISO/IEC 11179-1:2004(E). 2004.

Proposed Data Element Attributes for Clinical Data Element Repository

ISO/IEC 11179 Common attributes that are used for each type of administered item, i.e., Classification scheme, conceptual domain, context (for an administered item), data element, data element concept, object class, property, representation class, and value domain. Thus, these attributes are common to all types of Administered Item. ISO/IEC 11179-3 further categorizes these common attributes as: Identifying, Definitional, Administrative, and Relational. The following tables are taken directly from the ISO/IEC 11179-3:2003 standard.

Identifying

|Attribute |Allowed Occurrences |

|name |One or more per metadata item |

|context name |Zero or more per metadata item. Required if more than one name attribute exists. |

|context identifier |Zero or one per metadata item. Required if context name is not unique within its |

| |usage context (e.g. a standard). |

|context description |One per context name. |

|item identifier |Zero or one per metadata item. Required if name is not unique within a given context|

|item identifier – data identifier |One per item identifier. (The mandatory portion of an item identifier.) |

|item identifier – item registration authority |Zero or one per item identifier. (The optional portion of an item identifier) |

|identifier | |

|version |Zero or one per metadata item |

Definitional

|Attribute |Allowed Occurrences |

|definition |One for each context in which the metadata item is used |

|definition language identifier |Zero or one per definition. |

|definition source reference |Zero or one per definition. |

Administrative

|Attribute |Allowed Occurrences |

|comments |Zero or one per metadata item |

|registration status |Zero or one per metadata item |

|responsible organization name |Zero or one per metadata item |

|submitting organization name |Zero or one per metadata item |

Relational

|Attribute |Allowed Occurrences |

|classification scheme name |One for each classification scheme in which a |

| |metadata item is classified |

|classification scheme identifier |Zero or one per classification scheme name, Required if classification scheme name |

| |is not |

| |unique within a context |

|classification scheme type name |One for each classification scheme in which a |

| |metadata item is classified |

|classification scheme item type name |Zero or one for each classification scheme in |

| |which a metadata item is classified |

|classification scheme item value |One for each classification scheme item by which |

| |a metadata item is classified |

|related metadata reference type of |Zero or more per metadata item, One per related metadata reference |

|relationship | |

ISO/IEC 11179 Specific Attributes: The following attributes are used only for a specific type of administered item. The following tables are taken directly from the ISO/IEC 11179-3:2003 standard.

Attributes specific to Data Element Concepts

|Attribute |Allowed Occurrences |

|object class name |One per data element concept |

|object class identifier |Zero or one per object class name |

|property name |One per data element concept |

|property identifier |Zero or one per property name |

Attributes specific to Data Elements

|Attribute |Allowed Occurrences |

|Value domain name |Zero or one per data element |

|Value domain identifier |Zero or one per data element |

|Datatype name |Zero or one per data element. Required if neither |

| |value domain name nor value domain identifier is |

| |not specified |

|Datatype scheme reference |Zero or one per datatype name |

|Layout of representation |Zero or one per data element |

|Representation class |Zero or one per data element |

|Maximum size |Zero or one per data element |

|Minimum size |Zero or one per data element |

Attributes specific to Conceptual Domains

|Attribute |Allowed Occurrences |

|dimensionality |Zero or one per conceptual domain |

Attributes specific to Value Domains

|Attribute |Allowed Occurrences |

|datatype name |One per value domain |

|datatype scheme reference |Zero or one per datatype name |

|unit of measure name |Zero or one per value domain |

Attributes specific to Permissible Values

|Attribute |Allowed Occurrences |

|value |One per permissible value |

|permissible value begin date |Zero or one per permissible value |

|permissible value end date |Zero or one per permissible value |

Attributes specific to Value Meanings

|Attribute |Allowed Occurrences |

|value meaning description |One per value meaning |

|value meaning identifier |Zero or one per value meaning |

|value meaning begin date |Zero or one per value meaning |

|value meaning end date |Zero or one per value meaning |

HL7 Implementation Specific Uses: The data elements listed below are uses of ISO/IEC 1179 attributes specific to an implementation for HL7 clinical data elements:

1. Clinical definition will use the definition field for the Data Element Concept

2. Citations for clinical definition will use the definition source reference for the Data Element Concept.

3. Permissible values are supported directly through value domains and permissible values

4. Controlled terminology for data element will use the classification scheme name and the classification scheme identifier attributes for the Data Element (should this be Data Element Concept?)

5. Controlled terminology for data element value/s will use the classification scheme name and the classification scheme identifier attributes for the Value Domain associated with the Data Element.

6. HL7 data types will be supported through using HL7 data types as a Datatype scheme reference and applying the HL7 data types as Datatype name.

7. Representation for Data Elements will be handled through Layout of Representation and Representation class.

8. The associated DAMs, DCMs, templates, archetypes, CDAs, messages, EHR profiles will be associated to a data element via the classification scheme name and the classification scheme identifier attributes for the Data Element. However, we think the DAMs/templates/archetypes/CDAs/messages/EHR profiles should reference the Data Element item identifier, rather than the Data Element tracking which artifacts are using it.

9. Mapping to the RIM, DMIMs and RMIMs can be achieved through the classification scheme name and the classification scheme identifier attributes for the Data Element. However, we think the DMIMs and RMIMs should reference the Data Element item identifier, rather than the Data Element tracking which artifacts are using it.

HL7 Specific Extensions of the ISO-11179 model: none identified yet

-----------------------

[1] A data element is a unit of data for which the definition, identification, representation and permissible values are specified by means of a set of attributes. (ISO/IEC 11179-3) Data elements can occur at different levels of abstraction for example both Hematocrit result and Lab result can be data elements.

................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download