CTS2-LE Interoperability: Unterschied zwischen den Versionen

Aus CTS2-LE
Zur Navigation springen Zur Suche springen
(Die Seite wurde neu angelegt: „ == RDF and OWL == Modern semantic (web) technologies have its root in mature knowledge representation (KR) methods and techniques. They can be seen as a “We…“)
 
 
(10 dazwischenliegende Versionen von 2 Benutzern werden nicht angezeigt)
Zeile 1: Zeile 1:
 +
__NOTOC__
  
== RDF and OWL ==
+
This section describes the set of standards that provide solution developers with standard interfaces for extending the functionality of CTS2-LE and for utilizing CTS2-LE terminology services within their own solutions:
Modern semantic (web) technologies have its root in mature knowledge representation (KR) methods and techniques. They can be seen as a “Webification” of KR languages such as the Frame Language and Description Logics (DL). In fact, the Resource Description Language (RDF) standard can be considered as a simple frame language as well as a language for semantic nets and OWL has its direct foundation in a certain DL dialect. The semantics of these languages are the theoretical backbone of controlled vocabularies and are widely used to define concrete vocabularies.
+
* [[#CTS2|Common Terminology Services (CTS2)]]: CTS2-LE functional model
 +
* [[#RDF|Resource Description Framework (RDF)]]: CTS2-LE internal terminology data format
 +
* [[#SPARQL|SPARQL Protocol And RDF Query Language (SPARQL)]]: CTS2-LE terminology query language
 +
* [[#HL7 FHIR|Fast Healthcare Interoperability Resources (FHIR)]]: CTS2-LE external terminology exchange format
  
For instance, SNOMED-CT has the expressivity of the OWL EL++ dialect and even LOINC can be proper represented and processed by means of DL. Moreover, methods and techniques beyond representation such as DL-inference, logical rules , and querying via SPARQL are the building blocks for processing vocabularies.
+
== HL7 FHIR ==
 +
HL7 Fast Healthcare Interoperability Resources is an HL7 draft standard for exchanging healthcare information in a structured, interoperable and easily implementable manner. In contrast to the constraint-based approach of HL7v3 (e.g. an implementation guide for a referral letter constraints the CDA RMIM, which constraints the HL7 RIM ist), HL7 FHIR is based on modular resources which can be composed to use-case-specific data interchange definitions. FHIR already comes with a  [http://www.hl7.org/fhir/resourcelist.html catalogue of standard resource definitions] which can be composed and tailored to match the need of a specific healthcare data exchange problem. For further information about HL7 FHIR see:
 +
* [http://www.hl7.org/fhir/ HL7 FHIR homepage] with links to the full FHIR documentation and the [http://www.hl7.org/fhir/resourcelist.html FHIR catalogue of standard resource definitions]
 +
* [http://hl7.de/themen/hl7-fhir-standard-fuer-mobile-kommunikation/ Introduction to FHIR] (German)
 +
* [http://www.fhirabend.de/ German FHIR Blog] von Simone Heckmann
  
Another important aspect is the utilization of RDF for storing and querying linked (big) data. So far many RDF stores (Jena TDB, Virtuoso, etc.) are available and able to hold data in the range of several hundred million triples. Compared to object stores and assuming an average number of 10 object attributes, one can easily store and retrieve several million objects. These capabilities would give us the opportunity to “weave” instance nets for arbitrary medical data objects together with referenced vocabularies.
+
 
 +
<!--
 +
== CTS2 ==
 +
The Common Terminology Services Version 2 is a joint standardization effort from HL7 and OMG. The objective was to provide a standardized model for all terminological resources. CTS2 served as a blueprint for CTS2-LE in order to support a wide range of applications.
 +
 
 +
While HL7 defined the functional model for managing terminology artifacts, OMG mapped this abstract model onto a concrete information model and service interfaces, which again can be bound to various standards (e.g. SOAP, REST, RDF). Even though CTS2 was developed with healthcare use cases in mind, it can as well be used for managing and distributing terminology resources from other domains.
 +
-->
 +
For further information on CTS2 see:
 +
* [http://www.omg.org/spec/CTS2/ OMG CTS2 Homepage] (contains links to all published versions of the CTS2 standard)
 +
<!--
 +
* [http://de.slideshare.net/cts2/cts2-introduction Introduction to CTS2] (Presentation from Harold Solbrig, Mayo Clinic)
 +
 
 +
=== Use of CTS2 in CTS2-LE ===
 +
CTS2-LE's internal data model is an RDF-Binding to version 1.0 of the CTS2 standard. By this CTS2-LE supports all terminology resources defined in the CTS2 standard and follows the CTS2 service functional model for discovering and sharing these resources. The full RDF mapping onto the CTS2 model can be found [http://semantik.fokus.fraunhofer.de/WebCts2LE/main3/systemData.jsp here].
 +
 
 +
=== Interoperability with 3rd-Party Solutions ===
 +
CTS2-LE can manage any semantic resource that complies to the CTS2 functional model. This not only includes terminologies but even networked ontologies and structured knowledge bases. Owners of such semantic resources can easily load these into CTS2-LE and by this utilize the standard SPARQL and REST interfaces of CTS2-LE to provide users access to these resources.
 +
-->
 +
 
 +
== RDF ==
 +
Modern semantic (web) technologies have its root in mature knowledge representation (KR) methods and techniques. They can be seen as a “Webification” of KR languages such as the Frame Language and Description Logics (DL). In fact, the Resource Description Language (RDF) standard can be considered as a simple frame language as well as a language for semantic nets and OWL has its direct foundation in a certain DL dialect. The semantics of these languages are the theoretical backbone of controlled vocabularies and are widely used to define concrete vocabularies. For instance, SNOMED-CT has the expressivity of the OWL EL++ dialect
 +
<!--
 +
and even LOINC can be proper represented and processed by means of DL.
 +
 
 +
Another important aspect is the utilization of RDF for storing and querying linked (big) data. So far many RDF stores (Jena TDB, Virtuoso, etc.) are available and able to hold data in the range of several hundred million triples. Compared to object stores and assuming an average number of 10 object attributes, one can easily store and retrieve several million objects. These capabilities gives CTS2-LE the opportunity to “weave” instance nets for arbitrary medical data objects together with referenced vocabularies.
 +
 
 +
=== Use of RDF in CTS2-LE ===
 +
CTS2-LE manages all semantic resources as RDF graphs. RDF-Schemas are used for implementing the CTS2 functional model on top of RDF. CTS2-LE uses the Jena TDB quad store for efficently managing these graphs.
 +
 
 +
=== Interoperability with 3rd-Party Solutions ===
 +
Using RDF Schema language, further information schemes can be defined and integrated with CTS2-LE. In such scenarios CTS2-LE acts as an integrator that allows to link new artifacs with existing terminologies. 
 +
 
 +
By default the CTS2-LE distribution uses [https://jena.apache.org/documentation/tdb/ Jena TDB] for storing terminology data. This component can easily be exchanged by any other triple store solution (e.g. [http://virtuoso.openlinksw.com/ Virtuoso]).
 +
-->
 +
 
 +
== SPARQL ==
 +
The SPARQL Protocol And RDF Query Language (SPARQL) is a W3C semantic web standard for manipulating and querying [[#RDF|RDF]] graphs. For further information about SPARQL, see:
 +
* [http://www.w3.org/2009/sparql/wiki/Main_Page W3C SPARQL Working Group homepage] with references to all parts of the SPARQL standard
 +
* [http://www.cambridgesemantics.com/semantic-university/sparql-by-example SPQRQL by Example tutorial] containing many example queries to open RDF stores (e.g. medication databases)
 +
 
 +
=== Use of SPARQL in CTS2-LE ===
 +
Due to the full RDF-encoding of all terminology artifacts, CTS2-LE allows for arbitrary queries within and across terminologies, value sets, concepts, and concept relationships. For this means are provided to transmit a standard [http://www.w3.org/TR/2008/REC-rdf-sparql-query-20080115/ SPARQL query] to CTS2-LE. The query result is provided in standard [http://www.w3.org/TR/rdf-sparql-XMLres/ SPARQL Query Results XML Format].
 +
 
 +
=== Interoperability with 3rd-Party Solutions ===
 +
Third-Party-Solutions have full access to the complete CTS2-LE terminology base through the [[CTS2-LE REST API: SPARQL Query|CTS2-LE SPARQL REST API]]. Queries must comply to the [http://semantik.fokus.fraunhofer.de/WebCts2LE/main3/systemData.jsp CTS2-LE CTS2 RDF-Binding].
 +
 
 +
<!--
 +
=== Use of HL7 FHIR in CTS2-LE ===
 +
CTS2-LE uses the [http://www.hl7.org/fhir/valueset.html FHIR value set resource definiton] as its standard format for externalizing terminologies and value sets. In particular terminology artifacts can be uploaded and retrieved using this standard.
 +
 
 +
=== Interoperability with 3rd-Party Solutions ===
 +
The [[Hauptseite#CTS2-LE_REST-API|CTS2-LE REST API]] provides various interfaces for sharing FHIR value sets that can be used for connecting terminology providing and consuming services to CTS2-LE:
 +
*[[CTS2-LE REST API: Resolve Value Set|Resolve Value Set]]: Resolve and/or fetch an FHIR origined value set (or terminology) which is identified by it's URI.
 +
*[[CTS2-LE REST API: Requesting Concept Details|Request Concept Details]]: Fetch the details of a concept which is identified through a codesystem and code.
 +
*[[CTS2-LE REST API: Update Value Set|Update Value Set]]: Create or update a FHIR coded value set (or terminology) within CTS2-LE.
 +
 
 +
An example for using these APIs in conjunction with web forms can be found [[CTS2-LE REST API Example: Loading a Value Set into a HTML Form DropDown-Box|here]].
 +
-->

Aktuelle Version vom 18. Januar 2022, 18:58 Uhr


This section describes the set of standards that provide solution developers with standard interfaces for extending the functionality of CTS2-LE and for utilizing CTS2-LE terminology services within their own solutions:

HL7 FHIR

HL7 Fast Healthcare Interoperability Resources is an HL7 draft standard for exchanging healthcare information in a structured, interoperable and easily implementable manner. In contrast to the constraint-based approach of HL7v3 (e.g. an implementation guide for a referral letter constraints the CDA RMIM, which constraints the HL7 RIM ist), HL7 FHIR is based on modular resources which can be composed to use-case-specific data interchange definitions. FHIR already comes with a catalogue of standard resource definitions which can be composed and tailored to match the need of a specific healthcare data exchange problem. For further information about HL7 FHIR see:


For further information on CTS2 see:

RDF

Modern semantic (web) technologies have its root in mature knowledge representation (KR) methods and techniques. They can be seen as a “Webification” of KR languages such as the Frame Language and Description Logics (DL). In fact, the Resource Description Language (RDF) standard can be considered as a simple frame language as well as a language for semantic nets and OWL has its direct foundation in a certain DL dialect. The semantics of these languages are the theoretical backbone of controlled vocabularies and are widely used to define concrete vocabularies. For instance, SNOMED-CT has the expressivity of the OWL EL++ dialect

SPARQL

The SPARQL Protocol And RDF Query Language (SPARQL) is a W3C semantic web standard for manipulating and querying RDF graphs. For further information about SPARQL, see:

Use of SPARQL in CTS2-LE

Due to the full RDF-encoding of all terminology artifacts, CTS2-LE allows for arbitrary queries within and across terminologies, value sets, concepts, and concept relationships. For this means are provided to transmit a standard SPARQL query to CTS2-LE. The query result is provided in standard SPARQL Query Results XML Format.

Interoperability with 3rd-Party Solutions

Third-Party-Solutions have full access to the complete CTS2-LE terminology base through the CTS2-LE SPARQL REST API. Queries must comply to the CTS2-LE CTS2 RDF-Binding.