We present a healthcare information interoperability project in development. The idea behind the system is achieving semantic interoperability of di erent healthcare data models, by enabling translation of instance data based on structured mapping de nitions, and using RDF as a common information representation. We have developed a framework that allows the domain experts to de ne linkages between di erent data elements and utilizes the mappings to translate the data models from one format to another.
A healthcare IT environment breeds incredibly complex data ecosystems. Clinical data exist in multiple layers and forms ranging from the heterogeneous of structured, semi-structured, and unstructured data captured in enterprise-wide electronic medical record and billing systems, through a wide variety of departmental, study, and lab-based registries and databases. In many cases the data need to be retrieved from multiple independent sources. Because of the lack of interoperability between disparate data sources, retrieving data from multiple sources is extremely time consuming, wasteful and costly.
Interoperability can be achieved by adopting standards and translations between di erent standards. There exist many di erent standards in healthcare, each having its own uses and advantages. It is unrealistic to have one universal standard that ts all the use cases. Therefore an e cient way of translation between di erent data models is needed. Since each data model can be in a different format, adopting a common information representation model is unavoidable for the translation. In this sense, RDF (Resource Description Framework) [5] is a good choice since it is schemaless and is a commonly accepted information representation model by the semantic web community. Translation requires mappings between the sets of data elements in the di erent data models. Capturing the mappings between the data models in a structured format enables auto-generation of the translation code. 1 Data Models
Data source 1 Data source 2 Data source 3 Data source N
Convert to RDF 5
Capture Data Models
4 Read Mappings for:
2
Target Data Source X Translation Engine 6
Metadata & Mappings
Database UI for Metadata & Mappings
3 7
CSV Output
lation components work together. The metadata for each data source (
For each of the data sources, a data dictionary is captured and stored in a metadata repository [7]. In our work a data dictionary includes data model details for classes, attributes, attribute values, and their associations to each other. As an example, for a relational data model, the metadata consists of tables, table elds, allowed eld value sets for the elds, as well as the relationships between di erent metadata elements such as parent-child relationships.
The metadata repository also includes a mapping schema. The goal is to enable storing the mappings between di erent data models in a structured format. The mapping schema is designed so that a target eld can be mapped to from multiple candidate source elds that belong to one or more candidate source data models with eld-level priorities, and a value set translation from source values to target values, and a pre-de ned transformation logic from source elds to the target eld. A user-friendly interface is used by the data managers to view the data dictionaries, manage the term de nitions and de ne mappings between di erent data elements. In addition, the interface also has a test module that lets the data managers write and execute tests to validate their mappings. 2.2
The exibility of RDF allows di erent schemata and models to be converted, represented and connected via RDF. In this work, the translation engine performs the translation on the RDF representation of the source data elements. The conversion from a source data format to the RDF representation di ers for each data model, i.e., a di erent RDF data conversion routine is executed for each data format. The conversion from source instance data to the RDF representation happens on the y during the translation process; only the speci c source instance data, which is required by the mapping, is converted.
The usage of a metadata repository provides valuable bene ts in data interoperability. Capturing the mapping knowledge in a structured format provides connectivity between disparate data elements, and it enables an automatic generation of the data translation code to some extent. This leads to more transparency in the transformation process; i.e., in case of any data error it helps to track the source of the problem by checking the documented data mappings.
Data value translation enables the translation of a concept term in one data code system into an equivalent concept term in another data code system. For instance, a male gender can be represented with the term \Male" in one system while it is represented with the term \M" in another system. The associations in the documented value mappings are used to discover the term conversion from \Male" to \M". In many cases a single target data eld is mapped to from more than one source data eld. In this case the translation engine needs to know the priority of the source elds and/or a derivation logic to translate from multiple source elds. The priorities and the derivation logic can be de ned by the data managers using the mapping interface. The translation engine is then able to generate the translation code by utilizing the de ned priorities and the derivation logic. 3
Healthcare data interoperability requires the necessary tools, an e cient roadmap
and a strong commitment from relevant communities. Several studies have been
suggested for this purpose. For instance, the Yosemite Project [4] suggests an
ambitious roadmap for healthcare information interoperability on a global scale,
by using RDF as a universal information representation and creating a hub for
crowd-sourcing translation rules.
In this work we presented a framework to achieve interoperability between
di erent healthcare data models. It tries to alleviate the lack of interoperability
solutions and works fairly well on a small scale. However, our approach may
need improvements for use on a larger scale. In our work, we assumed that
there is already a de ned data dictionary in place for each data source. This
assumption may not be correct for all data sources. Also, manually de ning
the mappings can also require signi cant amounts of time due to the size of the
healthcare data. As future work, we plan to work on the following improvements:
(
Acknowledgments Our work is implemented in the Cleveland Clinic Cardiology Application Department to support interoperability between legacy data models. The authors would like to thank the Kent State University Semantic Web Research Group (SWRG) members, Cleveland Clinic Cardiology Application Group members and Semantic Web Health Care and Life Sciences (HCLS) Interest group members for their helpful feedback.