Data Element Exchange

From IHE Wiki
Jump to navigation Jump to search

Data Element Exchange leverages the concept of a metadata registry to add mapping metadata to an annotated data capture form at the point of form design instead of the exchange of data instances.

Summary

To enable clinical research, public health, and quality assessment studies through secondary use of EHR, a mechanism is needed to map EHR data to secondary domain meanings. Integrating patient care and clinical research domains requires a standard-based expressive and scalable interoperability framework for sharing the semantics of the data elements used in patient care and clinical research domains and their mapping to varying data sources. DEX profile enables this through a metadata registry architecture where machine processable definitions of data elements (i.e. metadata) across domains can be shared to address this interoperability challenge to move towards EHR-enabled research. DEX enables retrieving metadata definitions of data elements including “extraction specifications” for a data element defined in a selected domain (like SDTM data elements), from an implementation dependent content model in another domain (like HL7 CCD). As an example, an RFD form Manager can locate the exact mappings of the data elements in the research data set to a pre-population data set provided in HL7 CCD format.

Benefits

  • Standardized interaction with a metadata registry to search and retrieve metadata definitions
  • Flexible mapping between clinical research and patient care data elements
  • Enables dynamic pre-population of clinical research, public health, and quality assessment forms from pre-population data provided by EHR systems as medical summaries

Details

This profile leverages the power of an ISO/IEC 11179 Metadata Registry to search and retrieve data element metadata. The objective is to facilitate creation of annotated data capture form at the point of form design by adding mapping metadata for the data elements in a data capture form to the content models used in clinical care domain. The metadata registry such as CDISC SHARE can serve as the Metadata Source in this profile will define and maintain correspondences between research and healthcare data elements, and will provide an exact map by which an RFD form Manager can extract data from the pre-population data set.

An electronic data capture system or a research protocol design system would host the Metadata Consumer actor, to query the Metadata Source actor to retrieve the list of data elements hosted and retrieve the metadata of a selected data element including the exact mapping path of the selected data element instance in a content model like HL7 CCD. These mappings would be used to create the annotated data capture forms at the point of form design.

Systems Affected

Metadata Registries may define and maintain metadata of data elements including the correspondences between research and healthcare data elements.

Electronic Data Capture system may query the Metadata Source for a list of Data Elements matching a selection criteria, and may retrieve the metadata of the selected data element.

Figure 1 DEX Actor Diagram.jpg

Metadata Consumer The Metadata Consumer is responsible for the importation of metadata created by the Metadata Source. The Metadata Consumer can optionally query the Metadata Source for a list of Data Elements matching a selection criteria.

Metadata Source The Metadata Source is responsible for creation of the Data Element list matching a selection criteria and the creation of metadata for a selected Data Element per request from the Metadata Consumer. The Metadata Source is associated with a metadata registry.

Table 1 DEX Profile Actors and Transactions.jpg

Specification

Profile Status: Profile Status: Trial Implementation

Documents:

[1]

IHE Radiology Technical Framework:

  • Vol. 1 - Section 5 (SWF Profile)
  • Vol. 2 - Sections 4.8 to 4.10, 4.14 to 4.19, and 4.23
  • Vol. 3 - Appendix E

Underlying Standards:

<list all the standards on which the profile is based; if possible with links to sources>

See Also

<The following sections can be left out if there is nothing to point to. This is just to show where such information can go.>


Related Profiles

<List profiles this one depends on, profiles that depend on this one, profiles that are synergistic with this one. Start with the name of the other profile as a link and then explain the relationship.>


Consumer Information

The Profile FAQ Template answers typical questions about what the Profile does. <Replace the link with a link to the actual FAQ page for the Profile>

The Profile Purchasing Template describes considerations when purchasing equipment to deploy this Profile. <Replace the link with a link to the actual Purchasing page for the Profile>

Implementer Information

The Profile Implementation Template provides additional information about implementing this Profile in software. <Replace the link with a link to the actual Implementation page for the Profile>

Reference Articles

<List References (good and bad) (with link if possible) to Journal Articles that mention IHE's work (and hopefully include some analysis). Go ahead, Google: IHE <Profile Name> abstract or Google: IHE <Profile Name> and under the "more" select "Scholar". You might be surprised. >


This page is based on the Profile Overview Template