d4.4.1 salus semantic mediation framework -r1 · pdf file4 ehr data sources ... 5.4.1 athena...

FP7-287800 SALUS

SALUS-FP7-287800• D4.4.1 • Version 1.0, dated 30/04/2013 of

98

SALUS “Scalable, Standard based Interoperability Framework for

Sustainable Proactive Post Market Safety Studies”

SPECIFIC TARGETED RESEARCH PROJECT

PRIORITY Objective ICT-2011.5.3 b) Tools and environments enabling the re-use of

electronic health records

SALUS D4.4.1 SALUS Semantic Mediation Framework–R1

Due Date: April 30, 2013

Actual Submission Date: April 30, 2013

Project Dates: Project Start Date : February 01, 2012

Project End Date : January 31, 2015

Project Duration : 36 months

Deliverable Leader: AGFA

Project co-funded by the European Commission within the Seventh Framework Programme (2007-2013)

Dissemination Level

PU Public X

PP Restricted to other programme participants (including the Commission Services)

RE Restricted to a group specified by the consortium (including the Commission Services)

CO Confidential, only for members of the consortium (including the Commission Services)

FP7-287800 SALUS

SALUS-FP7-287800• D4.4.1 • Version 1.0, dated 30/04/2013 of 98

Document History:

Version Date Changes From Review

V0.1 2013-03-27 Initial Document Agfa WP partners

V0.2 2013-04-17 Integrated contributions from partners Agfa Agfa

V0.3 2013-04-19 Integration Agfa SALUS

V1.0 2013-04-25 Final version Agfa SALUS

Contributors (Benef.) Kristof Depraetere (AGFA)

Gokce Banu Laleci Erturkmen (SRDC)

Mustafa Yuksel (SRDC)

Suat Gonul (SRDC)

Giovanni Mels (AGFA)

Hong Sun (AGFA)

Responsible Author Kristof Depraetere Email [email protected]

Beneficiary AGFA Phone +32 3 444 8174

mailto:[email protected]

FP7-287800 SALUS


SALUS Consortium Contacts:

Beneficiary Name Phone Fax E-Mail

SRDC Gokce Banu Laleci

Erturkmen

+90-312-2101763 +90(312)2101837 [email protected]

EUROREC Georges De Moor +32-9-2101161 +32-9-3313350 [email protected]

UMC Niklas Norén +4618656060 +46 18 65 60 80 [email protected]

OFFIS Wilfried Thoben

+49-441-9722131

+49-441-9722111

[email protected]

AGFA Dirk Colaert +32-3-4448408 +32 3 444 8401 [email protected]

ERS Gerard Freriks +31 620347088 +31 847371789 [email protected]

LISPA Alberto Daprà +390239331605 +39 02 39331207 [email protected]

INSERM Marie-Christine Jaulent +33142346983 +33153109201 marie-

[email protected]

TUD Peter Schwarz +49 351 458 2715 +49 351 458 7319 Peter.Schwarz@uniklinikum-

dresden.de

ROCHE Jamie Robinson +41-61-687 9433 +41 61 68 88412 [email protected]













FP7-287800 SALUS


EXECUTIVE SUMMARY

This report describes the semantic mediation framework prototype developed to support the semantic

interoperability between the clinical research and clinical care systems of the SALUS project. The

deliverable itself is the set of tools and services developed to create the semantic mediation

framework prototype. For each of the involved tools and services the functionality and the interface

are described in this report. The architecture and design of the semantic mediation framework is

defined in SALUS deliverable 3.4.1 Conceptual Design of the SALUS Architecture. This initial

version of the framework is used for the pilot scenario of the Case Series Characterization pilot

scenario.

The resulting semantic interoperability layer Stub Semantic Interoperability Layer Data Services

(SIL-DS) provide access to mock-up data of both LISPA and UKD. Using the developed conversion

rules both data sets are translated from their Content Model Ontologies to the harmonized SALUS

Common Information Model Ontology. In parallel the real SIL-DS of TUD has been further

developed and configured and already works with a stub of the real TUD ORBIS SPARQL endpoint.

The real TUD ORBIS SPARQL endpoint has been further developed and is configured to use the

UKD ORBIS system. The TUD ORBIS SPARQL endpoint has been installed in the Agfa

HealthCare’s VPN environment to UKD and has been tested on this real UKD ORBIS system.

However it has not been released yet to be used by the other SALUS services because the security

services to anonymize the extracted data are not in place yet. The other semantic services needed to

further augment the retrieved data are also developed and installed in the test environment.

Specifically the semantic services to aggregate the data from both sources (Aggregation Service), to

perform terminology reasoning and unification (Terminology Reasoning Service), to perform the

analysis on the result set for determining the characteristics of the data (Query Result Calculator

Service) and finally the overarching workflow manager (Safety Analysis Query Manager) are

developed and made available in the test environment.

In the next version of the prototype the real data sources of UKD and LISPA will be integrated. The

SIL-DS of LISPA needs to be developed and integrated. The privacy and security services need to be

integrated. The necessary model converters and model formatters need to be developed and

integrated. Finally the necessary workflow managers for the other scenarios need to be provided.

The second version of this report is to be delivered at M24.

FP7-287800 SALUS


TABLE OF CONTENTS

EXECUTIVE SUMMARY .................................................................................................................. 4 Table of contents ................................................................................................................................... 5 1 Introduction .................................................................................................................................... 7

1.1 Purpose ...................................................................................................................................... 7 1.2 Scope ......................................................................................................................................... 8 1.3 Reference documents ................................................................................................................ 8 1.4 Definitions and Acronyms ........................................................................................................ 8

1.4.1 Definitions.......................................................................................................................... 8 1.4.2 Abbreviations and Acronyms ............................................................................................ 8

2 Meta-Architecture .......................................................................................................................... 9 2.1 Semantic Web ........................................................................................................................... 9 2.2 Representation State Transfer ................................................................................................... 9 2.3 Reasoning .................................................................................................................................. 9 2.4 Partitioning ................................................................................................................................ 9 2.5 Independent Services............................................................................................................... 10 2.6 Data Reuse .............................................................................................................................. 10

3 Semantic Mediation ...................................................................................................................... 11 4 EHR Data Sources ........................................................................................................................ 13 5 Semantic Mediation Framework ................................................................................................. 14

5.1 Ontmalizer Tool ...................................................................................................................... 14 5.1.1 Transforming XSD to RDF/OWL.................................................................................... 14 5.1.2 Transforming XML to RDF/OWL ................................................................................... 16 5.1.3 Notes about Ontmalizer ................................................................................................... 18

5.2 EYE reasoning engine ............................................................................................................. 18 5.3 Semantic Interoperability Layer .............................................................................................. 20

5.3.1 Semantic Services ............................................................................................................ 20 5.4 Semantic Services Infrastructure ............................................................................................. 20

5.4.1 Athena .............................................................................................................................. 20 5.4.2 Servers ............................................................................................................................. 21

5.5 Semantic Services ................................................................................................................... 21 5.5.1 ORBIS SPARQL endpoint .............................................................................................. 21 5.5.2 Stub ORBIS SPARQL endpoint ...................................................................................... 22 5.5.3 Semantic Interoperability Layer Data Service (TUD) ..................................................... 22 5.5.4 Stub Semantic Interoperability Layer Data Service (TUD) ............................................. 33 5.5.5 Semantic Interoperability Layer Data Service (LISPA) .................................................. 34 5.5.6 Stub Semantic Interoperability Layer Data Service (LISPA) .......................................... 35 5.5.7 Case Series Characterization Query Converter Service ................................................... 36 5.5.8 Aggregation Service ......................................................................................................... 38 5.5.9 Terminology Reasoning Service ...................................................................................... 39 5.5.10 Query Result Calculator Service .................................................................................... 42 5.5.11 Safety Analysis Query Manager .................................................................................... 43

6 Conclusion and Future Work ...................................................................................................... 45 APPENDIX 1 Mock-up Data .......................................................................................................... 46 APPENDIX 2 An Example ORBIS SPARQL Query to Retrieve Medication Information ..... 47 APPENDIX 3 An Example Eligibility Criteria expressed in SALUS CIM Ontology ............... 48 APPENDIX 4 An Example QEDext Get Care Record Profile Query message ......................... 50 APPENDIX 5 An Example QEDext Get Care Record Profile Query Response Message ........ 52 APPENDIX 6 An Example Medical Summary in HL7 CDA format USING PCC/CCD

Templates 64 APPENDIX 7 An Example Medical Summary as an Instance of HL7 CDA OWL Model ...... 71 APPENDIX 8 An Example Medical Summary Expressed in SALUS CIM Ontology .............. 92

FP7-287800 SALUS


APPENDIX 9 A Terminology Reasoning Rule to Find MedDRA HLGT Term

Correspondences of Source Codes..................................................................................................... 97 APPENDIX 10 Rule for Obtaining Common Conditions Prior to Medication of Interest ....... 98

FP7-287800 SALUS


1 INTRODUCTION

1.1 Purpose

This report describes the semantic mediation framework prototype developed to support the semantic

interoperability between the clinical research and clinical care systems of the SALUS project. The

deliverable itself is the set of tools and services developed to create the semantic mediation

framework prototype. For each of the involved tools and services the functionality and the interface

are described in this report.

Because of the nature of the work, tasks 4.3 (Building SALUS Harmonized Ontology for Post Market

Safety Studies) and 4.4 (Developing the Semantic Mediation Framework) have many dependencies

and therefore both tasks were conducted in parallel with immediate feedback of the results of one task

to the other.

The description of the work for task 4.4 states: “In this task the Semantic Mediation Framework of

SALUS infrastructure will be developed to address semantic interoperability between clinical research

and clinical care systems by using the SALUS harmonized ontology as a common denominator. On

top of this harmonized model, we will develop semantic mediation tools supported through reasoners

to seamlessly map the messages exchanged between clinical research systems and EHR systems for

enabling patient safety studies. We will support two complementary functionalities based on the

semantic awareness level of the underlying clinical research and care systems:

For clinical research and clinical care systems (like EHR and PHRs) that are not semantically

aware, we will provide the necessary ontology lifting and mediation tools. In this way, these

systems will be able to communicate through the domain information models they already use

such as CDISC ODM, HL7 CDA, archetypes, i.e. the content models we identified, and these

semantically similar but syntactically different content models will be seamlessly mediated

through one another with the help of SALUS semantic mediation tools. We will provide

semantic lifting tools to translate the message payloads in the native content models such as a

CDA XML to the semantic representations available in the harmonize ontology so that

semantic mediators can map them through reasoning on the harmonized ontology.

For clinical research and clinical care systems (like EHR and PHRs) that are semantically

aware, we will enable the development of semantic interfaces (such as SPARQL). Through

these semantic interfaces the clinical research systems that want to conduct patient safety

studies can create clinical data requests directly on top of the SALUS harmonized ontology as

a semantic query, and this semantic query will be converted to the native query language of

the supporting clinical care information source (such as EHR systems) through SALUS

Mediation framework. For this, necessary tools will be provided to extract the ontological

representation of the native data repositories and align these ontologies with the SALUS

harmonized ontology.

In this way we will provide a migration path from clinical care and research systems that can

communicate through semantically enhanced functional interoperability profiles to clinical care and

research systems that support full-fledged semantic systems enabling semantic interfaces through our

harmonized patient safety ontology.”

The result of the development process is a constellation of semantic services and tools that together

constitute the Semantic Medication Framework.

This document is structured as follows. Section 2 specifies the architectural principles taken into

account for the solution. Section 3 describes the followed semantic medication approach. Section 4

gives a brief description of the available data sources for the SALUS project. Section 5 describes the

Semantic Medication Framework. Section 6 states the conclusion and highlights the future work.

FP7-287800 SALUS


1.2 Scope

This document is a report on a prototype and thus the prototype itself is considered to be the main

deliverable.

1.3 Reference documents

The following documents were used or referenced in the development of this document:

- SALUS Description of Work (SALUSPartB_20110118.pdf)

- SALUS Deliverable 3.4.1 – Conceptual Design of the SALUS Architecture

- SALUS Deliverable 4.3.1 – Harmonized Ontology for Post Market Safety Studies-R1

- SALUS Story Board for Case Series Characterization Tool

- SALUS Deliverable 8.1.1 – Pilot Application Scenario and Requirement Specifications of the

Pilot Application

1.4 Definitions and Acronyms

1.4.1 Definitions

Term DEFINITION

Entity A subject in a certain domain with its relationships to other objects.

Entity Model The formal model for representing an entity.

Content Model The structural data model

Content Model

Ontology

The ontological representation of the data model

Table 1 List of Definitions

1.4.2 Abbreviations and Acronyms

Abbreviation/

Acronym DEFINITION

CMO Content Model Ontology

CIM Common Information Model

CSCQC Case Series Characterization Query Converter Service

CSCT Case Series Characterization Tool

DO Domain Ontology

DQ Domain Query

DSQ Data Set Query

DoW Description of Work

DWH Data Warehouse

HQMF Health Quality Measures Format

LISPA Lombardia Informatica

N3 Notation 3

OWL Web Ontology Language

RDF Resource Description Framework

SIL Semantic Interoperability Layer

SIL-DS Semantic Interoperability Layer Data Service

TIDSQS Technical Interoperability Data Source Query Service

TUD Technical University of Dresden

UKD University Hospital of Dresden

XML eXtensible Markup Language

XSD XML Schema Definition

QED IHE Query Existing Data

QEDExt Extended IHE QED

Table 2 List of Abbreviations and Acronyms

FP7-287800 SALUS


2 META-ARCHITECTURE

Six types of end user scenarios need to be supported by the overall SALUS system. However due to

the different nature of each of the scenarios, i.e. the intended use, the data processed, and the

environment of deployment, we foresee that the solution will not be a single monolithic system. We

therefore proposed the SALUS system as being a constellation of services. Depending on the user

scenario and the environment of deployment the necessary services will be deployed and need to

interact in order to provide the user scenario’s solution. We therefore should aim for a maximum

reuse of services between the different settings.

The SALUS solution shall adhere to the following architectural principles.

2.1 Semantic Web

The Semantic Web provides a common framework that allows data to be shared and reused across

application, enterprise, and community boundaries1. It is based on the Resource Description

Framework2. The framework enables reasoning as there is now a clear distinction between a 'world'

and an explicit and formal semantic theory about that 'world'. Notation3 (N3)3 is used as a further

extension of RDF by adding formulae (literals which are graphs themselves), variables, logical

implication, and functional predicates, as well as providing a textual syntax alternative to RDF/XML4.

2.2 Representation State Transfer

The REST architectural style5 (the architectural style of the World Wide Web architecture) defines an

architectural style to create the architecture for distributed systems. The six constraints imposed by the

style are client-server, stateless server, cache, uniform interface, layered system and (optional) code-

on-demand.

2.3 Reasoning

The chief utility of a formal semantic theory (as mentioned in "Semantic Web") is to provide a

technical way to determine when inference processes are valid, i.e. when they preserve truth. This

provides the maximal freedom for reasoning engines while preserving a globally coherent notion of

meaning.

2.4 Partitioning

One shot reasoning, i.e. taking in all available knowledge and trying to reason with it all, almost

immediately leads to the combinatorial explosion of the reasoning process and does not deliver a

result within reasonable time. Therefore a system will be devised to select and partition the relevant

knowledge and allow to reason on these parts. The results of these reasoning steps will then be added

to newly selected knowledge and reasoning can be performed again. This process continues until the

final results are retrieved.

1 W3C, W3C Semantic Web, http://www.w3.org/standards/semanticweb/

2 W3C, Resource Description Framework (RDF), http://www.w3.org/RDF/

3 Tim Berners-Lee, Dan Connolly, Notation3 (N3): A readable RDF syntax,

http://www.w3.org/TeamSubmission/n3/ 4 W3C, RDF/XML Syntax Specification, http://www.w3.org/TR/rdf-syntax-grammar/

5 Roy Thomas Fielding, Architectural Styles and

the Design of Network-based Software Architectures, REST architectural style,

http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm

http://www.w3.org/standards/semanticweb/

http://www.w3.org/RDF/

http://www.w3.org/TeamSubmission/n3/


http://www.w3.org/TR/rdf-syntax-grammar/

http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm

FP7-287800 SALUS


2.5 Independent Services

The reuse of services can be simplified by aggressively restricting the objectives of a single service.

Thus we aim for fine grained and single purpose services. In addition by taking the workflow out of

the services, i.e. one service is not hard coded to invoke another known service, services become

interchangeable.

2.6 Data Reuse

Using the Semantic Web, data is promoted to become first class citizens by providing semantic

representations of the original raw data. These representations are expressed using ontologies6, the

intention of which is to reduce the number of possible interpretations of the concepts and

relationships. As a result these semantic representations become self-explaining. However the true

power surfaces when data from different sources are combined and by utilising the self-integrating

capabilities, i.e. the web effect of using URIs for identifies, of their semantic representations to come

to a bigger view and better understanding of it.

6 W3C, W3C Vocabularies, http://www.w3.org/standards/semanticweb/ontology

http://www.w3.org/standards/semanticweb/ontology

FP7-287800 SALUS


3 SEMANTIC MEDIATION

As described in D4.3.1 Harmonized Ontology for Post Market Safety Studies we use a hub and spoke

approach to semantic mediation. The different, both source and target, content models are the spokes

and the harmonized model is the hub.

The formalization workflow from data to formal resources is designed as depicted in Figure 1.

Figure 1 Formalization Flow

Two different workflows are identified: one workflow at development time and another workflow at

runtime.

The different development steps (purple squares) are:

1. The necessary data sources are identified and within the data sources the relevant content

entities.

2. Via a (preferably) one-to-one mapping the native content format is formalized. Having a one-

to-one mapping limits the amount of interpretation needed using non-model theory based

mechanisms.

3. The one to one mapping results in a content model ontology for each data source. The content

model ontology is used to express the content entity models.

4. These content model ontologies can be used to write data set queries to retrieve relevant data

from the data source.

5. In parallel domain ontologies are collected and created for expressing the domain entity

models.

6. Using the content model ontologies and domain ontologies the necessary conversion rules are

created to transform the content entity models into domain entity models.

7. Domain Queries can be written to retrieve needed data from the domain entity models.

8. Analysis rules are used to further deduce additional information from the domain entities.

Note that other rules could be used to convert to a target content model.

FP7-287800 SALUS


The different runtime steps (red circles) are:

1. The user application launches a domain query.

2. The domain query invokes the necessary data set queries to retrieve the relevant content

entities from the data sources.

3. The data set query is translated to the native query format of the data source.

4. The data is retrieved and with the one-to-one mapping is converted to an RDF representation

of the content entity model. The content entity model is expressed using the content model

ontology.

5. The domain conversion rules are used to convert the content entity models into domain entity

models.

6. The domain entities can be queried by domain queries to retrieve relevant information.

7. Analysis rules can be used to augment the domain entities and infer new domain entities.

Additional target content entity models can also be generated.

8. The analysis results can further be queried by domain queries.

9. Finally the results are presented to the user.

FP7-287800 SALUS


4 EHR DATA SOURCES

The two data sources that will be available for the SALUS project are:

An Agfa HealthCare ORBIS™ system of the University Hospital of Dresden (UKD) in

Germany by the Technical University of Dresden (TUD).

A clinical data warehouse of the Italian Lombardy region provided by Lombardia

Informatica (LISPA). The Lombardy Region runs the Regional Health Data Warehouse,

which extracts all data necessary for administrative and statistical purposes from the

Lombardy EHR systems.

However at M15 of the project we do not have live access to these data sources yet and are thus

unable to fetch data from these data sources at runtime. Therefore we opted to create mock-up data

with the same structure as the corresponding data store. The mock-up data allows us to work with

realistic data but also to easily verify the outcome of the applications, i.e. we know upfront the

statistics that should be displayed in the user application.

The mock-up data is designed with the help of an Excel spreadsheet (APPENDIX 1) and described in

the SALUS Story Board for Case Series Characterization Tool report. For the LISPA data a

corresponding RDF file for each patient is created. The LISPA data is expressed using the HL7

CDA/CCD Content Entity Model from task 4.3. For the UKD data an RDF file containing the

foreground population and an RDF file containing the background population are created. Both UKD

files express the data using the ORBIS Content Entity Model from task 4.3.

Live access to the data sources will be established during the remainder of the project.

FP7-287800 SALUS


5 SEMANTIC MEDIATION FRAMEWORK

In this section we explain the results obtained to build the semantic mediation framework for the

semantic interoperability layer as designed in Deliverable 3.4.1 Conceptual Design of the SALUS

Architecture.

The first release of this semantic mediation framework supports the Case Series Characterization pilot

scenario as described in D8.1.1 Pilot Application Scenario and Requirement Specifications. This pilot

application is in detail described in the SALUS Story Board for Case Series Characterization Tool

document.

5.1 Ontmalizer Tool

Ontmalizer is a tool developed by the SRDC team that is able to perform comprehensive

transformations of XML Schemas (XSD) and XML data to RDF/OWL automatically. Through this

tool, it is possible to create RDF/OWL representation of XML Schemas, and XML instances that

comply with such XML Schemas.

The state of the art open source and/or free tools for RDFizing XSD and XML were not able to handle

complex schemas and XML instances such as HL7 Clinical Document Architecture (CDA) R2. Only

the commercial versions (standard and maestro) of TopBraid Composer7 were successfully able to

handle such complex schemas. However, we do not want to use such commercial tools in SALUS.

Besides, TopBraid Composer is able to RDFize XSDs and XMLs through its GUI; it does not provide

an API for easy integration.

As a result, we implemented our own solution. We make use of Sun's XSOM library8 for processing

XML Schemas, Apache Xerces9 for processing XML data and Apache Jena

10 for managing RDF data.

While proceeding with the implementation of Ontmalizer, we noticed that the TopQuadrant /

TopBraid Composer team provided their conversion guidelines through a blog entry11

. In this

guideline, the TopBraid team explains how they managed to implement transformations of XML

Schemas and XML data to RDF/OWL for version 3.6.0 of TopBraid Composer. We were happy to

see that we were following similar approaches, and we continued the implementation by taking into

account their guidelines as well.

We explain how we manage to perform conversions from XSD to RDF/OWL, and from XML data to

RDF/OWL in the next two sub-sections.

5.1.1 Transforming XSD to RDF/OWL

The transformation rules that are used in the Ontmalizer XSD to RDF/OWL algorithm are provided in

the table below.

# XSD Constructs OWL Constructs

1 xs:simpleType rdfs:Datatype with the suffix “Datatype” on datatype

name.

7 TopBraid Composer, http://www.topquadrant.com/products/TB_Composer.html

8 http://xsom.java.net/

9 http://xerces.apache.org/xerces2-j/

10 http://jena.apache.org/

11 Living in the XML and OWL World - Comprehensive Transformations of XML Schemas and XML data to

RDF/OWL, http://topquadrantblog.blogspot.com/2011/09/living-in-xml-and-owl-world.html

FP7-287800 SALUS


2 xs:simpleType with

xs:enumeration

rdfs:Datatype with the suffix “Datatype” on datatype

name.

In addition, for the enumerations, an owl:Class as a

subclass of EnumeratedValue is created. Instances

are created for every enumerated value. An instance

of Enumeration, referring to all the instances, is

created as well as the owl:oneOf union over the

instances. These are mostly informative, as they are

not used directly during the XML data to RDF/OWL

transformation.

3 xs:complexType over

xs:complexContent owl:Class

4 xs:complexType over

xs:simpleContent owl:Class

5 xs:element (global) with

complex type

owl:Class and subclass of the class generated from

the referenced complex type

6 xs:element (global) with simple

type owl:Datatype

7 xs:element (local to a type)

owl:DatatypeProperty or

owl:ObjectProperty depending on the element type.

OWL Restrictions are built for the occurrence.

8 xs:group owl:Class

9 xs:attributeGroup owl:Class

10 Anonymous Complex Type

As for Complex Type except a URI is constructed as

Anon_#. Also, the class is defined as a subclass

of Anon.

11 Anonymous Simple Type As for Simple Type except a URI is constructed as

Anon_#.

12 Substitution Groups Subclass statements are generated for the members.

13 xsi:type on an XML element Overrides the schema abstract type with the specified

type.

Table 3 Conversion from XSD Constructs to OWL Constructs

In the implementation, XSD2OWLMapper is the main class to transform XML Schemas to

RDF/OWL. The constructor of this class gets the root XSD file to be transformed. Configuration of

the transformation operation is quite simple: the caller can set the prefixes for the object property and

datatype property names to be created. Then, the call to the convertXSD2OWL() method performs the

transformation. XSD2OWLMapper is able to print the output ontology in one of these formats:

RDF/XML, RDF/XML-ABBREV, N-TRIPLE and N3. An example transformation routine is

provided below for the HL7 CDA R2 XML Schema:

// This part converts XML schema to OWL ontology. XSD2OWLMapper mapping = new XSD2OWLMapper(new File("src/test/resources/CDA/CDA.xsd")); mapping.setObjectPropPrefix(""); mapping.setDataTypePropPrefix(""); mapping.convertXSD2OWL(); // This part prints the ontology to the specified file. FileOutputStream ont;

FP7-287800 SALUS


try { File f = new File("src/test/resources/output/cda-ontology.n3"); f.getParentFile().mkdirs(); ont = new FileOutputStream(f); mapping.writeOntology(ont, "N3"); ont.close(); } catch (Exception e) { e.printStackTrace(); }

We benefit from XSD2OWLMapper in several occasions. We created the SALUS Draft Common

Information Model (CIM) as an XML Schema first, and we are able to create the CIM ontology by

using XSD2OWLMapper. The complete SALUS CIM Ontology represented in N3 syntax is available

at http://www.salusproject.eu/ontology/salus-cim-ontology.n3. Similarly, CDA/CCD Content Entity

Model Ontology, which is the outcome of HL7 CDA R2 XML Schema transformation, is available in

N3 syntax at http://www.salusproject.eu/ontology/hl7-cda-ontology.n3. We will use it for ISO/CEN

EN 13606 XML Schema transformation as well.

5.1.2 Transforming XML to RDF/OWL

In compliance with the transformation rules that are presented in the previous section, this second part

takes care of RDFizing XML data. In our implementation, XML2OWLMapper is the main class to

transform XML data to RDF/OWL by creating instances of the necessary OWL classes, RDFS

datatypes, OWL datatype and object properties. The constructor of this class gets the XML file to be

transformed together with an instance of XSD2OWLMapper that is already initialized with the

corresponding XML Schema of the XML data. No other configuration is necessary for the

transformation operation; the prefixes for the object property and datatype property names to be

created are gathered from the XSD2OWLMapper configuration. Then, the call to the

convertXML2OWL() method performs the transformation.

Briefly, the XML transformation algorithm is as follows. When convertXML2OWL() method is

called:

The Document element of the XML document is selected,

A class having the same URI as the document element is selected,

The root of the model is created according to the type of the class found,

Then, for each child of document element the traverseChildren method is called. This is a pre-

order recursive traversal of the XML DOM tree. For each element the findObjectType

method is called.

The findObjectType method finds the type of the object according to the name of the property

in a triple. This is achieved by traversing over class relations of ontology. If we think of sub-

class, super-class relationship as a tree, then this function’s algorithm resembles a level order

traversal. To illustrate from the Figure below, the implementation will find Class E as the

range of the object property “hasName” if we search starting from the Class A.

http://www.salusproject.eu/ontology/salus-cim-ontology.n3

http://www.salusproject.eu/ontology/hl7-cda-ontology.n3

FP7-287800 SALUS


If the method finds a datatype property, then this means the next processed XML node will be

a text node. So, in order for traverseChildren to process it properly, we save the property

name and its range type to a global variable. An example output for this case is provided

below:

:INS2007004_IVL_PQ_2

a v3:IVL_PQ ;

v3:unit "mg"^^v3:csDatatype ;

v3:value "250"^^v3:realDatatype .

If the method finds an object property and a text node comes after that XML node and if the

type of this property allows mixed content according to the XML Schema definition then an

instance of "textContent" datatype property, which does not exist in the original XML

Schema, is added. The text is assumed to have xs:string data type. Below, an example for this

case is provided:

:INS2007004_ST_4

a v3:ST ;

v3:textContent "History of medication use"^^xsd:string .

Similar to XSD2OWLMapper, XML2OWLMapper is able to print the output ontology instance in

one of these formats: RDF/XML, RDF/XML-ABBREV, N-TRIPLE and N3. An example

transformation routine is provided below for a complete HL7 CDA R2 instance (which is compliant

with the HL7/ASTM Continuity of Care Document [CCD] and IHE Patient Care Coordination [PCC]

templates that we identified in SALUS D4.1.1):

// This part converts XML schema to OWL ontology. XSD2OWLMapper mapping = new XSD2OWLMapper(new File("src/test/resources/CDA/CDA.xsd")); mapping.setObjectPropPrefix(""); mapping.setDataTypePropPrefix(""); mapping.convertXSD2OWL(); // This part converts XML instance to RDF data model. XML2OWLMapper generator = new XML2OWLMapper(new File("src/test/resources/CDA/SALUS-sample-full-CDA-instance.xml"), mapping); generator.convertXML2OWL(); // This part prints the RDF data model to the specified file. try{ File f = new File("src/test/resources/output/salus-cda-instance.n3"); f.getParentFile().mkdirs();

Class A

Class B

AllValuesFrom Restriction Class

AllValuesFrom Restriction Class

“hasName” Property

“hasName” Property AllValuesFrom Class D

AllValuesFrom Class E

Figure 2 An example sub-class / super-class hierarchy representation

FP7-287800 SALUS


FileOutputStream fout = new FileOutputStream(f); generator.writeModel(fout, "N3"); fout.close(); } catch (Exception e){ e.printStackTrace(); }

Again, XML2OWLMapper plays a very important role in the overall SALUS implementation. For the

moment we use it for transformation of CCD/PCC XML instances to RDF/XML. An example

medical summary in native HL7 CDA format using PCC/CCD templates, and the corresponding

RDF/OWL representation are provided in APPENDIX 6 and APPENDIX 7 respectively. Similarly,

we will use XML2OWLMapper for transforming instances of entry level CDA templates that will be

returned by the extended IHE Query Existing Data (QED) and Care Management (CM) integration

profile implementations (as a part of the SALUS Technical Interoperability Layer) instead of a

complete CDA document instance. Furthermore, we will use it for ISO/CEN EN 13606 XML data

transformation as well.

5.1.3 Notes about Ontmalizer

Below, some notes (assumptions, limitations) about the current Ontmalizer implementation are

provided:

Valid XML documents with respect to the corresponding XML Schema need to be provided.

Ontmalizer does not perform XML validation against the XSD for performance reasons.

The user needs to supply only the root XML Schema for transformation, the included schemas

are automatically imported by Ontmalizer.

The current implementation does not take into account xsd:import; yet only xsd:include is

supported.

“any”, “anyAttribute” elements and “default”, “fixed”, “nillable” attributes are not taken into

account during XSD transformation, as they are not used within XML transformation either.

Identity constraints of the schema are not processed.

Default object property prefix is “has”, and the default datatype property is “dtp”.

Ontmalizer checks if the URIs are valid. If not http://uri-not-valid.com# is used as the URI. If

URI is a relative URI, then http://uri-not-absolute.com# is used.

To uniquely name the RDF resources,

INS<X>_<resourcetypename>_<typeoccurance> pattern is used, where X is a random

number between 0 and 9999999 that is generated for each instance of class

XML2OWLMapper and remains the same within a single transformation, resourcetypename

is the name of the type of the resource, and finally typeoccurance is the sequence number of

occurrence of that type's instance in a single transformation.

5.2 EYE reasoning engine

Eye stands for "Euler yap engine" and it is a further incremental development of Euler which is an

inference engine supporting logic based proofs. Eye is a backward-forward-backward chaining

reasoner design enhanced with Euler path detection.

The backward-forward-backward chaining is realized via an underlying Prolog backward chaining, a

forward meta-level reasoning and a backward proof construction.

FP7-287800 SALUS


The Euler path detection is roughly "don't step in your own steps" to avoid vicious circles so to speak

and in that respect there is a similarity with what Leonhard Euler discovered in 1736 for the

Königsberg Bridge Problem12

.

The reasoning that Eye is performing is grounded in First Order Logic. Keeping a language less

powerful than first order predicate calculus is quite reasonable within an application, but not for the

Web13

.

Via N314

the reasoner is interoperable with W3C Cwm15

.

See also README16

and the open source software is maintained by Agfa at EulerSharp17

.

The usage of Eye is either via the command line or via a java wrapper:

Usage: eye <options>* <data>* <query>*

eye

java -jar Euler.jar [--no-install] [--swipl] [--yap]

swipl -q -f euler.yap -g main --

yap -q -f euler.yap -g main --

<options>

--nope no proof explanation

--no-branch no branch engine

--no-blank no blank nodes in output

--no-qvars no quantified variables in output

--no-qnames no qnames in output

--no-span no span control

--quiet incomplete e:falseModel explanation

--quick-false do not prove all e:falseModel

--quick-possible do not prove all e:possibleModel

--quick-answer do not prove all answers

--think generate e:consistentGives

--ances generate e:ancestorModel

--wcache <uri> <file> to tell that uri is cached as file

--tmp-file <file> temporary file used by N3 Socket

--wget-path <path> the path followed by wget

--ignore-syntax-error do not halt in case of syntax error

--image <file> output PVM code

--strings output log:outputString objects

--warn output warning info

--debug output debug info

--profile output profile info

--statistics output statistics info

--version show version info

--license show license info

--help show help info

<data>

<n3_resource> n3 facts and rules

<query>

12

Weisstein, Eric W, Königsberg Bridge Problem. From MathWorld--A Wolfram Web Resource.

http://mathworld.wolfram.com/KoenigsbergBridgeProblem.html 13

Tim Berners-Lee, The Semantic Web as a language of logic, http://www.w3.org/DesignIssues/Logic.html 14

Tim Berners-Lee, Dan Connolly, Notation3 (N3): A readable RDF syntax,

http://www.w3.org/TeamSubmission/n3/ 15

http://www.w3.org/2000/10/swap/doc/cwm 16

http://eulersharp.sourceforge.net/README 17

http://sourceforge.net/projects/eulersharp

http://mathworld.wolfram.com/KoenigsbergBridgeProblem.html

http://mathworld.wolfram.com/KoenigsbergBridgeProblem.html

http://www.w3.org/DesignIssues/Logic.html



FP7-287800 SALUS


--query <n3_resource> output filtered with filter rules

--pass output deductive closure

--pass-all output deductive closure plus rules

EYE is used to execute the N3 mediation rules, which are described in the next sections.

5.3 Semantic Interoperability Layer

The SALUS Semantic Interoperability Layer (SIL) is build with a number of RESTful semantic

services that enables semantic interoperability between clinical research systems (e.g. Case Series

Characterization Tool) and EHR sources. In the SALUS architecture, we collect the EHR data in the

local model used by the EHR systems (which can be standard based like HL7/ASTM CCD, or can be

proprietary models, like ORBIS Data Model), and then semantically lift the collected data to represent

them as RDF entities in local ontologies corresponding to the local models used. To facilitate

interoperability, we have built in task 4.3 a SALUS Common Information Model (CIM) ontology to

act as a mediator between different local ontologies. The SALUS CIM ontology not only represents

entities that can be presented within a medical summary resource like medications, conditions,

procedures and demographics, but also establishes a link with the terminology system ontologies that

are used to code patients’ medical summaries. In SALUS, while the terminology systems are

represented as ontologies, the mapping relationships among different terminology system codes are

also established through semantic links in relation to well-established ontologies like SKOS. As

examples, skos:broader, skos:exactMatch properties are used to represent the semantic relationships

between the codes within and across code systems in a machine processable way. This ensures

terminology reasoning to address semantic interoperability. Detailed information about SALUS CIM

ontology can be found in SALUS Deliverable 4.3.1-SALUS Harmonized Ontology for Post Market

Safety Studies –R1.

5.3.1 Semantic Services

We applied the REST architectural style to define the architecture of the SIL. As a result of this

decision the SIL is established using the collaboration of a number of RESTful semantic services. The

principal functionality of a semantic service is to expose an Entity (or a number of entities). Such an

entity is a resource (as defined by the REST architecture style) and is the subject of interest in a

certain domain. Because these entities are on the semantic web they are declared using an entity

model. The entity model specifies what is relevant about the entity in the domain. For expressing the

entity model different ontologies, rules and schemas are used. When the resource is retrieved by

invoking the semantic service, the RDF representation of the entity is returned.

We use the HTTP protocol to provide the uniform interface.

5.4 Semantic Services Infrastructure

In order to easily set up some of the semantic services of the SIL we developed a semantic service

framework called Athena.

5.4.1 Athena

Athena is a generic RESTful web service that can be configured to provide entity resources. The

configuration of such an entity resource exists of N3 rule files and N3 query files. The N3 rule files

are used to deduce data from input data provided to the service and the N3 query files are used to

project the reasoning result for the output of the service. Athena uses the EYE reasoning engine to

reason on the data with the configured rules of the entity.

Semantic data is supplied to the semantic service either by reference or by value. The dataUrl query

parameter can be used to pass data by reference by mentioning the URL of another entity. Athena will

FP7-287800 SALUS


resolve the URL to retrieve the representation of the referenced entity. An alternative is to POST the

data to the service. Both input and output data are serialized using Turtle18

(an RDF serialization

format).

Athena is deployed as a simple WAR file on a standard java web application container such as

Apache Tomcat. The ATHENA_HOME java property points to the configuration folder of the

entities.

The URL of the configured entities is constructed as follows:

/athena/<entitypath>?[dataUrl=<dataUrl]*

The <entitypath> is the path of the entity in the configuration folder.

Both HTTP GET and POST are supported. For POST both the “application/x-www-form-urlencoded”

and “text/turtle” content types are supported. The former one allows the client to POST the dataUrl

parameters. The latter one allows the client to post the data by value.

5.4.2 Servers

Agfa HealthCare provides the server infrastructure for hosting the (shared) semantic services.

The base URL of the SALUS semantic services is:

http://aca.agfa.net/

5.5 Semantic Services

Currently we have implemented the following semantic services:

5.5.1 ORBIS SPARQL endpoint

The UKD ORBIS System exposes the TUD SPARQL Endpoint. This SPARQL Endpoint provides a

SPARQL query interface to retrieve data from the relation tables of ORBIS and also from the generic

data model tables, which contain the data for ORBIS Forms. ORBIS Forms are customer adaptable

forms, which the customer can use to capture and represent additional data needed to support their

workflows. Thus ORBIS Forms allow a customer to extend the data capturing capabilities of the

installed ORBIS system. However, the SPARQL Endpoint exposes a very low level way of accessing

the data, because it exposes a one-to-one translation of the relation model to the corresponding

semantic model of the SPARQL Endpoint. Thus this semantic model is rather storage structure

oriented and the business domain semantics of the ORBIS system’s applications are not reflected in

the semantic model exposed by the SPARQL endpoint. For this reason, Agfa does not allow third

party applications to query this SPARQL endpoint directly. Nonetheless, this SPARQL endpoint

allows Agfa products to retrieve data in a semantic way from ORBIS concerning for example, but not

limited to: patient demographics, medication forms, diagnoses and lab results. To allow third parties

to retrieve ORBIS data using a higher semantic expressivity, the SIL-DS (TUD) is provided as

explained in section 5.5.3. An example ORBIS SPARQL query to retrieve medication information is

presented in APPENDIX 2. It becomes clear from the query presented that the semantics are difficult

to grasp without in depth ORBIS data structure knowledge. Therefore these queries are encapsulated

by the SIL-DS (TUD).

18

http://www.w3.org/TR/turtle/

FP7-287800 SALUS


The ORBIS SPARQL endpoint service is a further development of proprietary Agfa HealthCare

software and deployed as a WAR file on an application server at the customers site.

We have configured the ORBIS SPARQL endpoint to work with the UKD ORBIS System and

deployed it on an Agfa system connected to the UKD ORBIS System via a VPN connection in order

to test it. However the ORBIS SPARQL endpoint needs to be deployed on a TUD server in order to

be usable from within SALUS.

The (path part of the) URL of the ORBIS SPARQL endpoint is:

/orbis/

Only HTTP GET is supported.

The (path part of the) URL of the query interface of the ORBIS SPARQL endpoint is:

/orbis/sparql?query=<query>

The <query> query parameter is the URL encoded SPARQL query to be executed on the SPARQL

endpoint.

Both HTTP GET and POST are supported.

5.5.2 Stub ORBIS SPARQL endpoint

However because run-time access to the ORBIS system is not established yet, the mock-up data is

loaded into an in-memory Jena19

triple store. This SALUS sample triple store allows one to query the

data using SPARQL and thus it acts as a stub for the real ORBIS SPARQL endpoint that will be used

later on in the project.

The URL of the stub ORBIS SPARQL endpoint is:

http://aca.agfa.net/salussample

Only HTTP GET is supported.

The URL of the query interface of the stub ORBIS SPARQL endpoint is:

http://aca.agfa.net/salussample/sparql?query=<query>

The <query> query parameter is the URL encoded SPARQL query to be executed on the SPARQL

endpoint.


5.5.3 Semantic Interoperability Layer Data Service (TUD)

The entities exposed by the SIL-DS (TUD) make it possible to retrieve a collection of “Medication”,

“Condition” (diagnosis) and “Demographics” of all the patients matching parameters like “medication

codes in ATC” and “diagnosis codes in ICD-10-GM”. As an example, using this service it is possible

to get references to all patients who have been prescribed with a certain medication given the ATC

code of a specific drug like Nifedipine. The SIL-DS also exposes patient condition, patient medication

19

http://jena.apache.org/

FP7-287800 SALUS


and patient demographics entities. These entities respectively contain all conditions, medications and

demographics of a specified patient.

When an entity is queried via SIL-DS (TUD), the necessary ORBIS data is retrieved from the ORBIS

SPARQL endpoint. This ORBIS data is converted from the ORBIS Content Entity Model to the

SALUS Entity Model using the Convergence Service. The Convergence Service is configured with

the necessary conversion rules to translate the ORBIS Content Entity Model to the SALUS Entity

Model. Thus each of those entities is expressed using the SALUS CIM Ontology.

The SIL-DS (TUD) exposes 3 population entity types:

condition: diagnosis information of a population of patients diagnosed with a certain disease

in a certain period.

medication: medication information of a population of patients receiving a certain medication

in a certain period.

demographics: demographic information of a population of patients.

The SIL-DS (TUD) exposes 3 patient entity types:

patientcondition: all diagnoses information of a certain patient.

patientmedication: all medication information of a certain patient.

patientdemographics: all demographic information of a certain patient.

When for example the population medication entity is retrieved by resolving its URL

"http://aca.agfa.net/pavo/entities/www.salusproject.eu/medication?code=C08CA05&beginDate=2012

-01-01&endDate=2012-12-31" (patients who had nifedipine in 2012), the corresponding ORBIS

SPARQL query is invoked on the ORBIS SPARQL endpoint to retrieve the medication information

from the relevant ORBIS form.

Part of this retrieved ORBIS data contains information about the patient using the specified

medication (extract):

<https://agfa.com/orbis/SALUS/resource/Listfield/56659+69930+14578+1#this>

<http://www.agfa.com/w3c/orbis/orbis-schema/Listfield#hasName>

"PZN".


<http://www.agfa.com/w3c/orbis/orbis-schema/Listfield#hasListName>

"ListeMedikamente".


<http://www.agfa.com/w3c/orbis/orbis-schema/Listfield#belongTo>

<https://agfa.com/orbis/SALUS/resource/Form/56659#this>.

<https://agfa.com/orbis/SALUS/resource/Form/56659#this>

<http://www.agfa.com/w3c/orbis/orbis-schema/Form#hasName>

"Rezept neu".

<https://agfa.com/orbis/SALUS/resource/Form/56659#this>

<http://www.agfa.com/w3c/orbis/orbis-schema/Form#fall>

<https://agfa.com/orbis/SALUS/resource/Fall/55702#this>.

<https://agfa.com/orbis/SALUS/resource/Fall/55702#this>

<http://www.agfa.com/w3c/orbis/orbis-schema/Fall#persnr>

<https://agfa.com/orbis/SALUS/resource/Patient/76#this>.

Using the ORBIS Content Entity Model to the SALUS Entity Model conversion rule (simplified):

{

?medikament listfield:hasName "PZN".

?medikament listfield:hasListName "ListeMedikamente".

?medikament listfield:belongTo ?form.

FP7-287800 SALUS


?form form:hasName "Rezept neu".

?form form:fall ?fall.

?fall fall:persnr ?patient.

} => {

?patient salus:medication ?Medikament.

}.

The ORBIS data is converted and expressed using the SALUS CIM ontology as:

<https://agfa.com/orbis/SALUS/resource/Patient/76#this>

<http://www.salusproject.eu/ontology/common-information-model#medication>

<https://agfa.com/orbis/SALUS/resource/Listfield/56659+69930+14578+1#this>.

Example URLs of the population entities are:

http://aca.agfa.net/pavo/entities/www.salusproject.eu/condition?code=I21.0&

beginDate=2011-01-01&endDate=2012-12-31

http://aca.agfa.net/pavo/entities/www.salusproject.eu/medication?code=C08CA

05&beginDate=2012-01-01&endDate=2012-12-31

http://aca.agfa.net/pavo/entities/www.salusproject.eu/demographics

Note the code and date parameters can be changed to retrieve the required information.

Example URLs of the patient entities are: http://aca.agfa.net/pavo/entities/www.salusproject.eu/patientcondition?pati

entUri=https%3A%2F%2Fagfa.com%2Forbis%2FSALUS%2Fresource%2FPatient%2F883003

%23this

http://aca.agfa.net/pavo/entities/www.salusproject.eu/patientmedication?pat

ientUri=https%3A%2F%2Fagfa.com%2Forbis%2FSALUS%2Fresource%2FPatient%2F88300

3%23this

http://aca.agfa.net/pavo/entities/www.salusproject.eu/patientdemographics?p

atientUri=https%3A%2F%2Fagfa.com%2Forbis%2FSALUS%2Fresource%2FPatient%2F883

003%23this

Note the patientUri parameter should be changed to the identifier of the patient for who the

corresponding information needs to be retrieved.

The components used to implement the SIL-DS (TUD) are further developments of proprietary Agfa

HealthCare components. The convergence service is implemented using Agfa HealthCare’s Argus

service and the SIL-DS (TUD) itself is implemented using Agfa HealthCare’s Pavo service.

5.5.3.1 Argus

The Argus service is responsible for retrieving clinical data from SPARQL endpoints like the ORBIS

SPARQL endpoint, converting this data to the SALUS CIM ontology and aggregating the results.

The interface of Argus is also a SPARQL endpoint. However, the Argus SPARQL endpoint is not a

traditional SPARQL endpoint, where a query is executed over an underlying graph dataset. In this

case the SPARQL query is interpreted as a kind of workflow description on how to query data from

other SPARQL endpoints and to which ontology the results of those queries need to be converted.

The Argus instance for SALUS is configured with a clinical data source endpoint running at

http://aca.agfa.net/salussample and with rules to convert the retrieved data to the domain

http://www.salusproject.eu.

FP7-287800 SALUS


PREFIX qp: <http://www.debugit.eu/ontology/queryplan#>

PREFIX sparql: <http://eulersharp.sourceforge.net/2003/03swap/sparql#>

PREFIX event: <http://eulersharp.sourceforge.net/2003/03swap/event#>

CONSTRUCT { ?s ?p ?o }

WHERE {

GRAPH <http://aca.agfa.net/salussample> {

[] a sparql:Querying;

event:hasInput <sparql-query-uri>;

event:hasOutput ?g1.

}

[] a qp:Aggregation;

event:hasInput ?g1;

event:hasOutput ?result;

qp:transform <http://www.salusproject.eu>.

GRAPH ?result {

?s ?p ?o

}

}

When executing the query above, Argus will retrieve a SPARQL query by resolving the <sparql-

query-uri> uri. Next, it will launch this query on the http://aca.agfa.net/salussample

SPARQL endpoint. The query must be a CONSTRUCT query, so the data returned is an RDF graph.

This graph (?g1) is referenced as input in the aggregation phase. It is possible to specify multiple

queries on multiple endpoints this way.

In the aggregation phase Argus will select the right conversion rules for each input graph, apply them

and merge the results.

As a final step, it is possible to specify a filter query pattern on the result.

Argus is the further development of proprietary Agfa HealthCare software and is deployed as a WAR

file on a standard java web application container such as Apache Tomcat. The configuration-

root context property points to the configuration folder of Argus.

The (path part of the) URL of the Argus service is:

/argus/sparql?query=<query>

The <query> query parameter is the URL encoded SPARQL query to be executed by the Argus

service.


5.5.3.2 Pavo

The Pavo service is configured to provide the six entity types mentioned above. The service is

responsible to request the necessary data from the Argus service to represent the specified entity using

the SALUS CIM Ontology.

Pavo is the further development of proprietary Agfa HealthCare software and is deployed as a WAR

file on a standard java web application container such as Apache Tomcat. The PAVO_HOME java

property points to the configuration folder of the entities. The context.xml file needs specify the URL

of the Argus service.

The (path part of) URLs of the population entities are:

FP7-287800 SALUS


/pavo/entities/www.salusproject.eu/condition?code=<icd10gmCode>&beginDate=<

beginDate>&endDate=<endDate>

/pavo/entities/www.salusproject.eu/medication?code=<atcCode>&beginDate=<beg

inDate>&endDate=<endDate>

/pavo/entities/www.salusproject.eu/demographics

The <icd10gmCode>, <atcCode>, <beginDate> and <endDate> query parameters specify the

additional characteristics of the requested entity.

The (path part of) URLs of the patient entities are: /pavo/entities/www.salusproject.eu/patientcondition?patientUri=<patientUri>

/pavo/entities/www.salusproject.eu/patientmedication?patientUri=<patientUri

>

/pavo/entities/www.salusproject.eu/patientdemographics?patientUri=<patientU

ri>

The <patientUri> query parameter specifies the patient identifier of the requested entity.


5.5.3.3 ORBIS Diagnosis Conversion Rules

The Diagnosis conversion rules convert diagnosis data expressed in the ORBIS content model

ontology to diagnosis data in the more abstract SALUS CIM ontology. This conversion is explicit and

without interpretation. The only data added to each coded diagnosis is a codeSystem IOD, which is

derived from a fixed list of code system names used in ORBIS.

In the ORBIS content model ontology the property <http://www.agfa.com/w3c/orbis/orbis-

schema/Diagnosen#codesgbv> attached to a problem represents the code of the problem in some

terminology system. This rule adds a salus:code property to the problem with the same code:

{

?problem <http://www.agfa.com/w3c/orbis/orbis-schema/Diagnosen#codesgbv> ?code

} => {

?problem salus:code ?code

}.

The benefit of using rules is that we are not constrained to simple one-on-one equivalence mappings

as in the previous example. The next rule shows that more complex relations can be mapped too.

This rule finds the name of the terminology (code) system used to code the problem, then finds the

corresponding code system OID, and attaches it to the problem using the salus:codeSystem

property.

{

?problem <http://www.agfa.com/w3c/orbis/orbis-schema/Diagnosen#diagtypid> [

<http://www.agfa.com/w3c/orbis/orbis-schema/Diagnosetyp#hl7kurz> ?name

].

?conceptScheme a skos:ConceptScheme; rdfs:label ?name; iso:oid ?codeSystemOid.

} => {

?problem salus:codeSystem ?codeSystemOid

}.

5.5.3.4 ORBIS Medication Conversion Rules

FP7-287800 SALUS


In ORBIS, medication is stored in customized ORBIS forms. There are more than 20 different

medication forms used in UKD, among those forms, the 'Rezept neu' form and the

'Medikamentenliste_PO_ABDA9636' form are the mostly widely used, which account for more than

90% of the medication form instances. As already stated, ORBIS Forms are customer adaptable

forms; therefore, these two medication forms also have their own data structure, thus require different

conversion rules to convert the data stored as ORBIS content entity model to a SALUS entity model

represented with CIM ontology. While the prescribed drugs/drug packages are recorded in the

customized medication forms, other drug related information, e.g. the ATC code of a drug, are stored

in other ORBIS relational tables. Therefore, these tables are also queried, and the returned results are

processed by the conversion rule together with the content recorded in the medication forms. The

SALUS medication entity is thus generated using standard coding (e.g. ATC code) and represented

with SALUS CIM ontology.

Descriptions of the above mentioned two forms are given in Deliverable D4.3.1, where their

structures and corresponding content entity models are presented respectively in details. The rest of

this section will introduce the conversion rules for these two forms respectively.

Conversion Rules for the Prescription Form – Rezept neu

In the “Rezept neu” form, the PZN number, which is the unique identity of a drug package in German

market, is recorded. Drug articles used in the specified drug package can be referred and the ATC

code of a drug article can also be queried. The prescription form conversion rule takes the contents

recorded in the “Rezept neu”, together with related medical knowledge information stored in the

relational tables. The output of this rule is SALUS Medication Entity, which is represented with

SALUS CIM ontology. In the generated entity, the active drug ingredient is represented with ATC

code. The prescription form does not explicitly state the start date and end date of the medication; the

salus:indicateMedicationStartStop property has only start date salus:low, which is generated by

combining the form creation date and form creation time.

A sample medication ORBIS Content Entity for the 'Rezept neu' form, which is also presented in

Deliverable D4.3.1 is shown next.

FP7-287800 SALUS


<https://agfa.com/orbis/SALUS/resource/Fall/43865001#this> <http://www.agfa.com/w3c/orbis/orbis-schema/Fall#persnr> <https://agfa.com/orbis/SALUS/resource/Patient/883001#this> .

<https://agfa.com/orbis/SALUS/resource/Form/39450101#this> <http://www.agfa.com/w3c/orbis/orbis-schema/Form#fall> <https://agfa.com/orbis/SALUS/resource/Fall/43865001#this> .

<https://agfa.com/orbis/SALUS/resource/Form/39450101#this> <http://www.agfa.com/w3c/orbis/orbis-schema/Form#meddate> "2012-07-23+01:00"^^<http://www.w3.org/2001/XMLSchema#date> .

<https://agfa.com/orbis/SALUS/resource/Form/39450101#this> <http://www.agfa.com/w3c/orbis/orbis-schema/Form#medtime> "12:12:12"^^<http://www.w3.org/2001/XMLSchema#time> .

<https://agfa.com/orbis/SALUS/resource/Listfield/39450101+69930+14578+1#this> <http://www.agfa.com/w3c/orbis/orbis-schema/Listfield#hasListName> "ListeMedikamente" .

<https://agfa.com/orbis/SALUS/resource/Listfield/39450101+69930+14578+1#this> <http://www.agfa.com/w3c/orbis/orbis-schema/Listfield#hasName> "PZN" .

<https://agfa.com/orbis/SALUS/resource/Listfield/39450101+69930+14578+1#this> <http://www.agfa.com/w3c/orbis/orbis-schema/Listfield#hasFeldtext> "3552295" .

<https://agfa.com/orbis/SALUS/resource/Listfield/39450101+69930+14578+1#this> <http://www.agfa.com/w3c/orbis/orbis-schema/Listfield#belongTo> <https://agfa.com/orbis/SALUS/resource/Form/39450101#this> .

<https://agfa.com/orbis/SALUS/resource/Form/39450101#this> <http://www.agfa.com/w3c/orbis/orbis-schema/Form#hasName> "Rezept neu" .

<https://agfa.com/orbis/SALUS/resource/CwMedgliederung/11135801#this> <http://www.agfa.com/w3c/orbis/orbis-schema/CwMedgliederung#code> "C08CA05" .

<https://agfa.com/orbis/SALUS/resource/CwMedgliederung/11135801#this> <http://www.agfa.com/w3c/orbis/orbis-schema/CwMedgliederung#bezeichnung> "Nifedipin" .

<https://agfa.com/orbis/SALUS/resource/CwMedpraepglied/11276901#this> <http://www.agfa.com/w3c/orbis/orbis-schema/CwMedpraepglied#medpraeparatid> <https://agfa.com/orbis/SALUS/resource/CwMedpraeparat/11492601#this> .

<https://agfa.com/orbis/SALUS/resource/CwMedpraepglied/11276901#this> <http://www.agfa.com/w3c/orbis/orbis-schema/CwMedpraepglied#medgliederungid> <https://agfa.com/orbis/SALUS/resource/CwMedgliederung/11135801#this> .

<https://agfa.com/orbis/SALUS/resource/CwMedpackung/11309601#this> <http://www.agfa.com/w3c/orbis/orbis-schema/CwMedpackung#bezeichnung> "Nifedipin-ratio Tropfen 100 ml N3" .

<https://agfa.com/orbis/SALUS/resource/CwMedpackung/11309601#this> <http://www.agfa.com/w3c/orbis/orbis-schema/CwMedpackung#pzn> "3552295" .

<https://agfa.com/orbis/SALUS/resource/CwMedpackung/11309601#this> <http://www.agfa.com/w3c/orbis/orbis-schema/CwMedpackung#medpraeparatid> <https://agfa.com/orbis/SALUS/resource/CwMedpraeparat/11492601#this> .

The medication conversion rule is applied on this entity and generates the following SALUS

Medication Entity:

@prefix salus: <http://www.salusproject.eu/ontology/common-information-model#>.

@prefix listfield: <http://www.agfa.com/w3c/orbis/orbis-schema/Listfield#>.

@prefix form: <http://www.agfa.com/w3c/orbis/orbis-schema/Form#>.

@prefix fall: <http://www.agfa.com/w3c/orbis/orbis-schema/Fall#>.

@prefix cwmedgliederung: <http://www.agfa.com/w3c/orbis/orbis-

schema/CwMedgliederung#>.

@prefix cwmedpraepglied: <http://www.agfa.com/w3c/orbis/orbis-

schema/CwMedpraepglied#>.

@prefix cwmedpraeparat: <http://www.agfa.com/w3c/orbis/orbis-

schema/CwMedpraeparat#>.

@prefix cwmedpackung: <http://www.agfa.com/w3c/orbis/orbis-schema/CwMedpackung#>.

@prefix math: <http://www.w3.org/2000/10/swap/math#>.

@prefix xsd: <http://www.w3.org/2001/XMLSchema#>.

@prefix log: <http://www.w3.org/2000/10/swap/log#>.

# RULE 1: ASSIGN MEDICATION TO PATIENT.

{

1 ?fall fall:persnr ?patient.

2 ?form form:hasName "Rezept neu".

3 ?form form:fall ?fall.

4 ?form form:meddate ?formdate.

5 ?form form:medtime ?formtime.

6 (?formdate ?formtime) math:sum ?S.

7 (?LV xsd:dateTime) log:dtlit ?S.

8 (?LV xsd:dateTime) log:dtlit ?formdateTime.

9 ?Medikament listfield:hasName "PZN".

10 ?Medikament listfield:hasListName "ListeMedikamente".

11 ?Medikament listfield:belongTo ?form.

} => {

FP7-287800 SALUS


12 ?patient salus:medication ?Medikament .

13 ?Medikament salus:indicateMedicationStartStop [

14 a salus:ivlTs;

15 salus:low ?formdateTime ].

}.

A conversion rule generates conclusions when the triples requested in the premise part are presented.

In rule 1, triple 1-11 are from ORBIS Medication Content Entity, triple 1 states a medical case (?fall)

is linked with a patient (?patient), triple 2 states a form (?form) is linked with a medical case (?fall).

Triple 3 indicates the form (?form) has name ("Rezept neu"). These three triples together indicate

patient (?patient) has a prescription form (?form). Triple 4 and triple 5 records the date and time the

medication form is created. Based on ?formdate and ?formtime, triple 6-8 generate an xsd:dateTime

property (?formdateTime), where the EYE built-in functions math:sum and log:dtlit are used. Triple

9-11 is about a list field (?Medikament) where prescribed medication is stored, it indicates this list

field is named as “PZN”, it belongs to a list named as “ListeMedikamente”, and it is in the

prescription form (?form).

Based on the above mentioned ORBIS Medication Content Entity, triple 12-15 are therefore

generated as part of the SALUS Medication Entity. Triple 12 states a patient (?patient) has medication

(?Medikament). Triple 13-15 declares the medication has a start and stop period; the start date is

?formdateTime and the stop date is missing. Note: the start and stop date of a medication is not

explicitly recorded in the prescription form, therefore, the creation date of the prescription form is

used as the start date of the prescribed medication, while the stop date is considered as missing.

By applying Rule 1 on the ORBIS Medication Content Entity we receive the following result:


salus:indicateMedicationStartStop _:sk1.

_:sk1 a salus:ivlTs.

_:sk1 salus:low "2012-07-23T11:12:12.000000Z"^^xsd:dateTime.

<https://agfa.com/orbis/SALUS/resource/Patient/883001#this> salus:medication


# RULE 2: RETRIEVE MEDICATION PACKAGE.

{

16 ?cwmedpackung cwmedpackung:pzn ?hasPZN.

17 ?Medikament listfield:hasFeldtext ?hasPZN.

18 ?Medikament listfield:hasName "PZN".

19 ?Medikament listfield:hasListName "ListeMedikamente".

20 ?Medikament listfield:belongTo ?form.

21 ?form form:hasName "Rezept neu".

} => {

22 ?Medikament a salus:Medication;

23 salus:medicationInformation ?cwmedpackung.

}.

In conversion Rule 2, triple 16, 17 indicate the text stored in the ?Medikament list field is named as

?hasPZN, the PZN stored in this list field is the same as the PZN stored in the cwmedpackung

(medication package). Explanation of the cwmedpackung ontology can be found in Deliverable 4.3.1.

Triple 18-21 indicates ?Medikament is the PZN list field in the prescription form. The generated triple

state that ?Medikament is a salus:Medication and the medication information is stored in

?cwmedpackung. By applying Rule 2 on the ORBIS Medication Content Entity we receive the

following result:

<https://agfa.com/orbis/SALUS/resource/Listfield/39450101+69930+14578+1#this> a

salus:Medication.


salus:medicationInformation

<https://agfa.com/orbis/SALUS/resource/CwMedpackung/11309601#this>.

FP7-287800 SALUS


# RULE 3: MAP MEDICATION PACKAGE TO ATC CODE

{

24 ?cwmedpackung cwmedpackung:bezeichnung ?medPackname.

25 ?cwmedpackung cwmedpackung:medpraeparatid ?medpraeparatid.

26 ?cwmedpraepglied cwmedpraepglied:medpraeparatid ?medpraeparatid.

27 ?cwmedpraepglied cwmedpraepglied:medgliederungid ?cwmedgliederung.

28 ?cwmedgliederung cwmedgliederung:code ?ATCcode.

29 ?cwmedgliederung cwmedgliederung:bezeichnung ?ATCname.

} => {

30 ?cwmedpackung a salus:MedicationInformation;

31 salus:freeTextBrandName ?medPackname;

32 salus:codedActiveIngredient [

33 a salus:cd;

34 salus:displayName ?ATCname;

35 salus:codeSystemName "WC";

36 salus:codeSystem "2.16.840.1.113883.6.73";

37 salus:code ?ATCcode ].

}.

In conversion Rule 3, triple 24 indicates the brand name of the medication package (?cwmedpackung)

is ?medPackname. Triple 25-29 retrieves associated ATC code (?ATCcode) and name (?ATCname)

for the specified medication package (?cwmedpackung). The relations of the above mentioned

ontologies are explained in Deliverable 4.3.1. Triple 30-37 are generated representing both the free

text brand name of the medication package and the associated ATC code. By applying Rule 3 on the

ORBIS Medication Content Entity we receive the following result:

<https://agfa.com/orbis/SALUS/resource/CwMedpackung/11309601#this> a

salus:MedicationInformation.

<https://agfa.com/orbis/SALUS/resource/CwMedpackung/11309601#this>

salus:freeTextBrandName "Nifedipin-ratio Tropfen 100 ml N3".


salus:codedActiveIngredient _:sk1.

_:sk1 a salus:cd.

_:sk1 salus:displayName "Nifedipin".

_:sk1 salus:codeSystemName "WC".

_:sk1 salus:codeSystem "2.16.840.1.113883.6.73".

_:sk1 salus:code "C08CA05".

By applying the above mentioned three conversion rules together on the ORBIS Medication Content

Entity we generate the SALUS Medication Domain Entity represented next.


salus:indicateMedicationStartStop _:sk2.

_:sk2 a salus:ivlTs.

_:sk2 salus:low "2012-07-23T11:12:12.000000Z"^^xsd:dateTime.

<https://agfa.com/orbis/SALUS/resource/CwMedpackung/11309601#this> a

salus:MedicationInformation.


salus:freeTextBrandName "Nifedipin-ratio Tropfen 100 ml N3".


salus:codedActiveIngredient _:sk3.

_:sk3 a salus:cd.

_:sk3 salus:displayName "Nifedipin".

_:sk3 salus:codeSystemName "WC".

_:sk3 salus:codeSystem "2.16.840.1.113883.6.73".

_:sk3 salus:code "C08CA05".

<https://agfa.com/orbis/SALUS/resource/Patient/883001#this> salus:medication


<https://agfa.com/orbis/SALUS/resource/Listfield/39450101+69930+14578+1#this> a

salus:Medication.

FP7-287800 SALUS




<https://agfa.com/orbis/SALUS/resource/CwMedpackung/11309601#this>.

Conversion Rules for the Medikament Form – Medikamentenliste_PO_ABDA9636

The conversion rules for the Medikament form are quite similar with those for the prescription form,

except that in the “Rezept neu” form, the PZN number is recorded, drug articles used in those

particular drug packages are queried and the ATC codes of these drug articles are used as active

ingredients. While in the “Medikamentenliste_PO_ABDA9636” form, the drug article name, instead

of the PZN number, is recorded. The drug article name is used to search for the associated ATC code.

# RULE 1: ASSIGN MEDICATION TO PATIENT.

{


?Medikament listfield:belongTo ?form.

?Medikament listfield:hasName "T_Medikament".

?Medikament listfield:hasListName "L_Medikamente".

?form form:hasName "Medikamentenliste_PO_ABDA9636".


?form form:meddate ?formdate.

?form form:medtime ?formtime.

(?formdate ?formtime) math:sum ?S.

(?LV xsd:dateTime) log:dtlit ?S.

(?LV xsd:dateTime) log:dtlit ?formdateTime.

} => {

?patient salus:medication ?Medikament .

?Medikament salus:indicateMedicationStartStop [

a salus:ivlTs;

salus:low ?formdateTime ].

}.

# RULE 2: RETRIEVE MEDICATION ARTICLE.

{

?cwmedpraepglied cwmedpraepglied:medpraeparatid ?cwmedpraeparat.

?cwmedpraeparat cwmedpraeparat:bezeichnung ?hasMedikament.

?Medikament listfield:hasFeldtext ?hasMedikament.

?Medikament listfield:hasName "T_Medikament".

?Medikament listfield:hasListName "L_Medikamente".

?Medikament listfield:belongTo ?form.

?form form:hasName "Medikamentenliste_PO_ABDA9636".

} => {

?Medikament a salus:Medication;

salus:medicationInformation ?cwmedpraeparat.

}.

# RULE 3: MAP MEDICATION ARTICLE TO ATC CODE

{

?cwmedpraepglied cwmedpraepglied:medpraeparatid ?cwmedpraeparat.

?cwmedpraeparat cwmedpraeparat:bezeichnung ?hasMedikament.

?cwmedpraepglied cwmedpraepglied:medgliederungid ?cwmedgliederung.

?cwmedgliederung cwmedgliederung:code ?ATCcode.

?cwmedgliederung cwmedgliederung:bezeichnung ?ATCname.

} => {

?cwmedpraeparat a salus:MedicationInformation;

salus:freeTextBrandName ?hasMedikament;

salus:codedActiveIngredient [

a salus:cd;

salus:displayName ?ATCname;

salus:codeSystemName "WC";

salus:codeSystem "2.16.840.1.113883.6.73";

salus:code ?ATCcode ].

}.

FP7-287800 SALUS


5.5.3.5 ORBIS Demographics Conversion Rules

The demographic conversion rules generates SALUS patient entity with the demographic information

stored in ORBIS. The demographic information in ORBIS is stored in relational tables.


@prefix patient: <http://www.agfa.com/w3c/orbis/orbis-schema/Patient#>.

@prefix natperson: <http://www.agfa.com/w3c/orbis/orbis-schema/Natperson#>.

@prefix ukd: <http://www.agfa.com/w3c/orbis/orbis-schema/instances#>.

@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .

@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#>.

@prefix xsd: <http://www.w3.org/2001/XMLSchema#>.


@prefix e: <http://eulersharp.sourceforge.net/2003/03swap/log-rules#>.

@prefix skos: <http://www.w3.org/2004/02/skos/core#>.

#RULE 1. CONVERT ORBIS PATIENT TO SALUS PATIENT

{ ?patient patient:persnr ?natperson. } => { ?patient a salus:Patient }.

#RULE 2.1 CONVERT ORBIS GENDER (LITERAL "M") TO CODED GENDER EXPRESSION

{

?patient patient:persnr ?natperson.

?natperson natperson:geschlecht "M".

} => {

?patient salus:gender

[ rdf:type salus:cd ;

salus:code "M" ;

salus:codeSystem "2.16.840.1.113883.5.1" ;

salus:codeSystemName "AdministrativeGender" ;

salus:displayName "Male"

].

}.

#RULE 2.2 CONVERT ORBIS GENDER (LITERAL "W") TO CODED GENDER EXPRESSION

{

?patient patient:persnr ?natperson.

?natperson natperson:geschlecht "W".

} => {

?patient salus:gender

[ rdf:type salus:cd ;

salus:code "F" ;


salus:codeSystemName "AdministrativeGender" ;

salus:displayName "Female"

].

}.

#RULE 3. CALCULATE PATIENT BIRTHDATE (xsd:date) BASED ON ORBIS BIRTHDATETIME

(xsd:dateTime)

{

1 ?patient patient:persnr ?natperson.

2 ?natperson natperson:gebdat ?birthDateTime.

3 ?birthDateTime e:numeral ?birthDateTimeSeconds.

4 (?birthDateLiteral xsd:date) log:dtlit ?birthDateTimeSeconds, ?birthDate.

} => {

5 ?patient salus:dateOfBirth ?birthDate.

}.

The birth date is stored in ORBIS as xsd:dateTime, and the ‘salus:dateOfBirth’ property expects the

result as xsd:date. Therefore, in the conversion rule, line 2-4 use built-in functions to convert the birth

date from xsd:dateTime to xsd:date. In the next version of the conversion rule, we are considering to

export the birth date from ORBIS directly as xsd:date, therefore, the xsd:dateTime to xsd:date

conversion might be not required in the next version demographic conversion rules.

#RULE 4. CONVERT ORBIS ADDRESS TO SALUS ADDRESS

[] skos:notation "D"^^ukd:locationDataType;

FP7-287800 SALUS


rdfs:label "Germany".

[] skos:notation "CZ"^^ukd:locationDataType;

rdfs:label "Czech Republic".

{

6 ?patient patient:persnr ?natperson.

7 ?natperson natperson:lkz ?lkz.

8 (?lkz ukd:locationDataType) log:dtlit ?typedLKZ.

9 ?location skos:notation ?typedLKZ.

10 ?location rdfs:label ?country.

} => {

11 ?patient salus:address [ rdf:type salus:addr; salus:country ?country]

}.

In ORBIS, the country information is stored using UKD local coding, e.g. “D” stands for Germany

and “CZ” stands for Czech Republic. The salus:country property expects literals like “Germany”;

therefore a mapping is added in Rule 4. The blank nodes in the head of rule 4 create instances with

localized notation and expected label. Triple 8 creates localized notation and triple 8 and 9 together

map the localized address notation to expected country label.

<https://agfa.com/orbis/SALUS/resource/Patient/883001#this>

<http://www.agfa.com/w3c/orbis/orbis-schema/Patient#persnr>

<https://agfa.com/orbis/SALUS/resource/Natperson/883001#this> .

<https://agfa.com/orbis/SALUS/resource/Natperson/883001#this>

<http://www.agfa.com/w3c/orbis/orbis-schema/Natperson#lkz> "D" .

Apply the rule 4 to the triples above, the triples below are returned, where “Germany” is displayed as

salus:country.

<https://agfa.com/orbis/SALUS/resource/Patient/883001#this> salus:address _:sk2.

_:sk2 a salus:addr.

_:sk2 salus:country "Germany".

5.5.4 Stub Semantic Interoperability Layer Data Service (TUD)

Because the SIL-DS (TUD) contains proprietary Agfa HealthCare components we configured a stub

implementation using Athena. This allows it to be installed on servers of the SALUS partners. The

service uses the same conversion rules but applies them on a fixed data set.

The stub SIL-DS (TUD) is implemented using Athena.

The URLs of the entities provided by the stub for the background population are:

http://aca.agfa.net/athena/entities/www.salusproject.eu/salus/salus.uni-

klinikum-dresden.de/population/bg/condition


klinikum-dresden.de/population/bg/medication


klinikum-dresden.de/population/bg/demographics

The URLs of the entities provided by the stub for the foreground population are:


klinikum-dresden.de/population/fg/condition


klinikum-dresden.de/population/fg/medication

FP7-287800 SALUS



klinikum-dresden.de/population/fg/demographics


5.5.5 Semantic Interoperability Layer Data Service (LISPA)

The actual SIL-DS (LISPA) implementation and integration with the LISPA Data Warehouse (DWH)

are not finalized yet, as the work is ongoing for realizing the necessary Technical Interoperability

Layer components such as LISPA Connector and Technical Interoperability Data Source Query

Service (TIDSQS). However there is already good progress with the implementation and for the

remaining work the specifications (necessary transactions, content, etc.) are already fixed. Therefore,

in this section, we are able to present how the final SIL-DS (LISPA) will be. In the next section, we

also present the current stub SIL-DS (LISPA) that we use in the early versions of the first SALUS

prototype.

Through the Aggregation Service, the Safety Analysis Query Manager Service passes the eligibility

criteria defined in SALUS Common Information Model Ontology to SIL-DS (LISPA). An example

eligibility criteria expressed in SALUS CIM ontology is presented APPENDIX 3. Based on our

architecture, SIL-DS (LISPA) first of all translates this query to an ontological representation of HL7

Health Quality Measures Format (HQMF), and this is passed to the EHR RDF Service. EHR RDF

Service translates this to original HL7 HQMF syntax in XML, and this is passed to TIDSQS service,

which is an extended version of IHE Query Existing Data (QED) integration profile query. By

implementing this extended IHE QED (can be termed as IHE QEDExt) profile, TIDSQS accepts

population based queries in HL7 HQMF format. An example IHE QEDExt GetCareRecord Profile

Query message that will be accepted by TIDSQS is presented in APPENDIX 4.

The LISPA Connector takes this eligibility description defined in HQMF, and maps it to SQL queries

that are run over LISPA SALUS DWH, and presents the medical summaries of eligible patients

through the entry level HL7 CDA templates presented in D4.1.1, which are all reusing existing IHE

PCC and HL7/ASTM CCD templates. An example QEDExt Get Care Record Profile Query Response

Message that is returned by TIDSQS is presented in APPENDIX 5.

EHR RDF Service retrieves from TIDSQS this medical summary in its native XML format complying

with the entry level CCD/PCC templates, and translates it to a semantic representation as RDF data.

For this purpose, we have developed a tool, namely Ontmalizer (see Section 5.1 for details), that

performs comprehensive transformations of XML Schemas (XSD) and XML data to RDF/OWL

automatically. Through this tool, it is possible to create RDF/OWL representation of XML Schemas,

and XML instances that comply with such XML Schemas. EHR RDF Service uses Ontmalizer to

RDFize the medical summaries of the eligible patients retrieved from TIDSQS. The RDFized medical

summaries containing the requested data sets represented in the CDA/CCD Content Entity Model (i.e.

the local ontology of LISPA) are then returned to SIL-DS (LISPA). Please note since the TIDSQS is

not fully functional yet, in the current prototype instead of the response structure of QEDExt,

complete CDA document instances that comply with again the same CCD/PCC templates are used as

medical summaries. This is explained in Section 5.5.6.

SIL-DS (LISPA) is responsible for converting these data sets received in the local ontology of LISPA

to SALUS Common Information Model. For these, a set of conversion rules has been implemented in

EYE to do the conversion from local ontology instance to SALUS CIM ontology instance. These

conversion rules are explained in the next sub-section. By running these rules, the medical summary

data sets for eligible patients are obtained as instances of SALUS CIM Ontology. An example such

instance is available in APPENDIX 8.

The final data sets represented in SALUS CIM ontology are then passed to the Aggregation Service.

FP7-287800 SALUS


Both the SIL-DS of TUD and LISPA expose entities. However there is a difference in the kind of

entities that are exposed by the SIL-DS (TUD) and SIL-DS (LISPA). The SIL-DS (TUD) first

exposes population clinical concept and patient clinical concept entities for specified clinical concept

instances, and then merges results from these methods to create the requested medical summary

entities. On the other hand, the SIL-DS (LISPA) directly provides population medical summary

entities matching the specified eligibility criteria.

5.5.5.1 HL7 CCD Conversion Rules

To be able to convert the raw data retrieved from the EHR sources such as LISPA and TUD to the

common SALUS CIM representation which is composed of the elements determined in the D4.1.1 -

SALUS Content Models deliverable, there was a need for a set of conversion rules. These rules run on

the semantic representation of the retrieved patient population.

To realize the actual conversion operations, the EYE reasoning engine is used in such a way that EYE

takes the raw data and the conversion rules as inputs and it produces the converted patient data as the

output in SALUS CIM representation.

A modular approach has been followed while writing the conversion rules such that there is a root rule

matching with the root of the semantic representation of a CDA document regarding to a patient. This

root rule calls other sub-rules for all possible entries such as allergies, medication, conditions, etc. that

might exist in a CDA document based on the template identifiers of the entries. Such a rule calling

mechanism within another rule, like a function call, is possible since conversion rules have been

written as backward rules in EYE.

An example for backward rules can be seen below. It converts the ED data type of CDA into a string

literal.

#ED2String

{?ED :mapED ?STR}

<=

{

?ED a cda:ED;

cda:textContent ?ed_lit.

(?STR ?datatype) log:dtlit ?ed_lit.

}.

Apart from the root rule and CDA entry based rules, there is another set of rules realizing the data

type conversions for which an example is seen above.

Both the data type conversion rules and the entry specific rules are reused extensively. For instance,

the above rule is used in any place where a conversion from ED data type to string literal is needed.

Also, the CDA entry based conversion rules are reused extensively. For instance, the rule converting

CDA Condition to SALUS CIM Condition is used when both converting the "Past Medical History"

and "Active Problems" sections in a CCD document, since both sections use the same entry level

PCC/CCD templates.

Similarly, it is easily possible to reuse these conversion rules when PCC/CCD entry level templates

are used not necessarily within a CDA document, but other structures such as the response message of

the IHE QED and CM integration profiles that we will extend and use in our SALUS architecture.

5.5.6 Stub Semantic Interoperability Layer Data Service (LISPA)

As briefly mentioned in Section 5.5.5, since the TIDSQS and LISPA Connector are not fully

functional yet, in the current prototype we consider TIDSQS as a black box, and EHR RDF Service

currently processes a set of HL7 CDA R2 medical summaries compliant with IHE PCC and

FP7-287800 SALUS


HL7/ASTM CCD templates identified in SALUS D4.1.1, as if they are coming from TIDSQS. An

example such medical summary is presented in APPENDIX 6.

EHR RDF Service makes use of Ontmalizer as explained previously to perform the automatic

transformation of HL7 CDA XML data to its one-to-one RDF/OWL correspondence. First, the

RDF/OWL representation of generic HL7 CDA R2 XML Schema is created with Ontmalizer.

Similarly, when an HL7 CDA instance is received by the EHR RDF service, the OWL instance is

created in conformance to HL7 CDA OWL model using Ontmalizer. An example such instance is

available in APPENDIX 7 as a direct correspondence of the HL7 CDA XML instance provided in

APPENDIX 6.

Through the conversion rules explained in Section 5.5.5.1, SIL-DS (LISPA) then automatically

converts RDF data represented in CDA/CCD Content Entity Model to RDF data represented in

SALUS CIM.

We realized this stub implementation of SIL-DS (LISPA) by using Athena. The conversion rules are

applied by the stub SIL-DS (LISPA) on a fixed data set, which is created manually for the early

prototype demonstration. The generated population data in HL7 CDA are based on the sample data

provided in APPENDIX 1.

The URL of the entity provided by the stub for the background population is:

http://aca.agfa.net/athena/entities/www.salusproject.eu/salus/salus.lispa.i

t/population/medicalsummary/bg

The URL of the entity provided by the stub for the foreground population is:


t/population/medicalsummary/fg

Both HTTP GET and POST are supported. Having a single URL for each population is in line with

the actual LISPA SIL-DS implementation to be completed, as the medical summaries of the eligible

patients will be returned through a single service on the LISPA side, unlike TUD where dedicated

services exist for different entities such as condition, medication, demographics.

5.5.7 Case Series Characterization Query Converter Service

To be able to determine only the eligible patients where we have more complex inclusion and

exclusion criteria, further eligibility queries need to be run on top of the data sets provided by the

entities of the SIL-DS (TUD). An example of such a query is “give me all the patients having a

myocardial infarction within two weeks of Nifedipine intake”. In this case, the necessary medication

and condition entities are retrieved from the SIL-DS (TUD) and the relevant SPARQL query is

generated to determine the patients matching the specified inclusion and exclusion criteria. The

resulting SPARQL query is executed on top of the retrieved medication and condition entities. Once

the patients are determined, the relevant clinical data, i.e. all medications and diagnoses of eligible

patients, for these patients can be fetched by retrieving the proper patient entities.

The Case Series Characterization Query Converter Service (CSCQC) service is a semantic service

that accepts a HQMF like query, encoded in Turtle. Concepts from HQMF describing patient

population inclusion and exclusion criteria were added to the SALUS-CIM ontology to express these

criteria in Turtle.

The query stated above can be expressed in SALUS-CIM as

@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .

@prefix salus: <http://www.salusproject.eu/ontology/common-information-model#> .

FP7-287800 SALUS


[] a salus:EligibilityCriteria ;

salus:inclusionCriteria [

a salus:CriteriaGroup ;

salus:conjunctionCode [ a salus:cd ; salus:code "AND" ] ;

salus:groupItem _:med , _:cond ;

salus:negationIndicator "false"^^xsd:boolean

] .

_:med a salus:Criterion ;

salus:clinicalStatement [

a salus:Medication ;

salus:medicationInformation [

a salus:MedicationInformation ;

salus:codedActiveIngredient [

a salus:cd ;

salus:code "C08CA05" ;


salus:codeSystemName "ATC"

]

]

] .

_:cond a salus:Criterion ;

salus:clinicalStatement [

a salus:Condition ;

salus:problemCode [

a salus:cd ;

salus:code "I21.0" ;


salus:codeSystemName "ICD-10-GM"

]

] ;

salus:temporalRelation [

a salus:TemporalConstraint ;

salus:targetCriterion _:med ;

salus:typeCode [ a salus:cd ; salus:code "SAS" ] ;

salus:pauseQuantity [

a salus:ivlPq ;

salus:low [ a salus:pq ; salus:value "14" ; salus:unit "d" ]

] ;

] .

The patient is included if he has an intake of nifedipine (ATC code "C08CA05") and has had a

myocardial infarction (ICD-10-GM code "I21.0").

The temporal constraint expresses that the myocardial infarction starts within 2 weeks of the start

the nifedipine intake.

The CSCQC service in this case generates the SPARQL query below and executes it.

PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>

PREFIX salus: <http://www.salusproject.eu/ontology/common-information-model#>

SELECT ?patient

FROM </pavo/entities/www.salusproject.eu/condition?code=I21.0&beginDate=2011-01-

01&endDate=2013-12-31>

FROM </pavo/entities/www.salusproject.eu/medication?code=C08CA05&beginDate=2011-01-

01&endDate=2013-12-31>

WHERE {

{ ?patient salus:condition ?condition0 .

FP7-287800 SALUS


?condition0 rdf:type salus:Condition ;

salus:problemCode _:b0 .

_:b0 rdf:type salus:cd ;

salus:code "I21.0" ;

salus:codeSystem "1.2.276.0.76.5.409" .

?condition0 salus:problemDate _:b1 .

_:b1 rdf:type salus:ivlTs ;

salus:low ?condition0_start .

}

{ ?patient salus:medication ?medication0 .

?medication0 rdf:type salus:Medication ;

salus:medicationInformation _:b2 .

_:b2 rdf:type salus:MedicationInformation ;

salus:codedActiveIngredient _:b3 .

_:b3 rdf:type salus:cd ;


salus:codeSystem "2.16.840.1.113883.6.73" .

?medication0 salus:indicateMedicationStartStop _:b4 .

_:b4 rdf:type salus:ivlTs ;

salus:low ?medication0_start .

}

FILTER (?condition0_start < (?medication0_start + "P14DT0H0M0S"^^xsd:duration))

}

First the condition and medication entity uris are resolved to retrieve the dataset using the Pavo

service. The query pattern selects the eligible patients. The first graph selects patients having

condition "I21.0"; the second graph selects patients taking medication with active ingredient

"C08CA05". The 'AND' is implicit in SPARQL. Finally the temporal constraint is expressed in the

filter.

The URL of the CSCQC service is:

http://aca.agfa.net/cscqc

The URL of the query interface of the CSCQC service is:

http://aca.agfa.net/cscqc/query

The service supports POST with content-type text/turtle and application/rdf+xml.

The returned data is encoded in text/turtle or application/rdf+xml, according to the

requested format.

Note that the interfaces of the CSCQC service and the SIL-DS (LISPA) service thus will be the same.

5.5.8 Aggregation Service

The aggregation service is used to merge multiple entities. Currently this is a simple pass through of

all the data, which is already expressed using the SALUS CIM Ontology. However later on in the

project additional rules could be added to the aggregation services to further integrate data from both

data sources. Further integration rules could for example deduce that certain instances found at LISPA

and UKD are in fact the same.

The aggregation service is implemented using Athena.

The URL of the aggregation service is:

http://aca.agfa.net/athena/entities/www.salusproject.eu/salus/www.salusproj

ect.eu/aggregate

FP7-287800 SALUS


The service expects a reference to the entities to aggregate via the dataUrl query parameters.


5.5.9 Terminology Reasoning Service

In all our pilot application scenarios, there is a need for terminology reasoning because the EHR

sources and the end-users use very different medical terminology systems for coding medical data.

For example, for coding conditions (diagnoses, problems, etc.), LISPA uses ICD-9-CM, UKD uses

ICD-10-GM and UMC prefers dealing with MedDRA. Further information about the terminology

systems that are used within SALUS are provided in D4.3.1.

It is very important to utilize reliable terminology mapping information. The terminology mapping

resources that we use in our implementation are:

MedDRA (PT terms) – SNOMED CT one-to-one mappings (exact match) provided by

OntoADR of the PROTECT project.

ICD-9-CM to SNOMED CT mappings (exact or broad match) provided by OMOP

Vocabulary.

ICD-10-CM to SNOMED CT mappings (exact or broad match) provided by OMOP

Vocabulary.

ICD-10 – SNOMED CT & ICD-9-CM – SNOMED CT mappings (close match; which are

manually checked) provided by BioPortal.

ICD-10-GM – ICD-10 one-to-one mappings (exact match) based on the use of the exact same

codes.

As explained in SALUS D4.3.1, the terminology systems are represented as ontologies in SALUS

Semantic Resource Set using the SKOS vocabulary. Similarly, these mapping information are also

represented as triples in the SALUS Semantic Resource Set. The “skos:exactMatch” and

“salusc:exactOrNarrowMatch” relationships among the codes in different terminology systems are

added based on the mappings provided by OntoADR, OMOP Vocabulary and BioPortal. The

“skos:broader” relationships are added based on the original hierarchy relationships available in the

terminology systems.

Before making use of this mapping information at run time, for performance and time reasons, it is

necessary to do materialization by calculating the transitivity closure of the available mapping

information. For example, in the current demonstration of the CSCT, in the sample patient population

the conditions are coded with ICD-9-CM and ICD-10-GM codes at different levels, while we are

expected to group these conditions by MedDRA HLGT terms. Several different terms are used in the

sample patient population to code the “bleeding” problem, as can be seen in Figure 3 (the green ones

indicate the codes used in patient population):

ICD-10-GM

o R58: Blutung, anderenorts nicht klassifiziert (Haemorrhage, not elsewhere classified)

o K92.2: Gastrointestinale Blutung, nicht näher bezeichnet (Gastrointestinal

haemorrhage, unspecified)

o I60.-: Subarachnoidalblutung (Subarachnoid haemorrhage)

o I60.0: Subarachnoidalblutung, vom Karotissiphon oder der Karotisbifurkation

ausgehend (Subarachnoid haemorrhage from carotid siphon and bifurcation)

o I60.9: Subarachnoidalblutung, nicht näher bezeichnet (Subarachnoid haemorrhage,

unspecified)

ICD-9-CM

o 569.85: Angiodysplasia of intestine with hemorrhage

o 578.9: Hemorrhage of gastrointestinal tract, unspecified

o 459.0: Hemorrhage, unspecified

o 430: Subarachnoid hemorrhage

FP7-287800 SALUS


o 432.9: Unspecified intracranial hemorrhage

Figure 3 Codes used in the sample patient population to indicate bleeding problem and their relationship

with MedDRA HLGT Term: 10047075

We are using a series of terminology reasoning rules that calculate the full transitive closure of

“salusc:narrowOrExactMatch” (which is a union of skos:exactMatch and skos:narrowMatch

properties) relationships between the codes within and across code systems. As a result, the grouping

can be easily achieved, as all the codes used in the sample population are already linked with

MedDRA HLGT Term: 10047075 corresponding to “Vascular haemorrhagic disorders” through the

“salusc:narrowOrExactMatch” relationship as can be seen in Figure 4.

These materialized results are provided as static information to the Terminology Reasoning Service,

which helps a lot in improving the response times. Whenever a new mapping resource is added, it is

necessary to recalculate this materialized information, which can be easily done with a few EYE rules

that we implemented.

FP7-287800 SALUS


Figure 4 Result of terminology reasoning materialization rule to calculate salusc:exactOrNarrowMatch

relationship

Once we have these mapping information in our Terminology Reasoning Service to apply

terminology reasoning at run time on top of the retrieved population data represented in SALUS CIM

ontology, another set of EYE rules is run via a call to the RESTful Terminology Reasoning Service

implemented using Athena and deployed at the following URL (this is for the CSCT only):

http://aca.agfa.net/athena/entities/www.salusproject.eu/salus/www.salusproj

ect.eu/term-

reasoning/csct?dataUrl=<path_to_dynamic_reasoning_rules>&dataUrl=<path_to_c

onverted_patient_population>

The first part of the URL until the first dataUrl parameter is a reference to the reasoning rules

containing static mappings; e.g. mappings among MedDRA, SNOMED CT, ICD-10, ICD-10-GM and

ICD-9-CM terminology systems. The first dataUrl parameter indicates a location containing dynamic

reasoning rules that are used to calculate an equivalent closure of codes to be obtained from a certain

terminology system, e.g. MedDRA, for a certain code included in another terminology system used in

the local EHR sources; e.g. ICD-9-CM in LISPA and ICD-10-GM in TUD. And the last dataUrl

parameter indicates a location containing the patient population data already converted to SALUS

CIM representation.

An example dynamic rule to find MedDRA HLGT term correspondences of the source codes

represented in other terminology systems such as ICD-9-CM, ICD-10-GM and SNOMED CT is

presented in APPENDIX 9.

FP7-287800 SALUS


5.5.10 Query Result Calculator Service

The Query Result Calculator is a service that is used to apply additional calculations on the patient

population data obtained via the Aggregation Service in SALUS CIM format from the EHR sources to

extract the characteristics of the population. The Query Result Calculator contains functionalities to

be used by safety analysis tools such as the Case Series Characterization Tool and Post Marketing

Safety Study Tool to be implemented in the scope of SALUS project. However, these tools do not

communicate with the Query Result Calculator directly. Instead, they communicate with the Safety

Analysis Query Manager and it delegates the requests coming from these tools to the Query Result

Calculator as explained in the Section Safety Analysis Query Manager (Section 5.5.11).

In the current release, this service only serves to the CSCT by applying EYE rules for different kinds

of statistical options which are issued by the user through the graphical user interface of the CSCT.

Some of the possible statistical calculations that can be applied on the retrieved data are:

Average age of patients

Gender distribution of patients

Age distribution of patients

Country distribution of patients

Common risk factors

Common conditions

Common medications

Common conditions prior to medication of interest

Common conditions post medication of interest

Common conditions prior to condition of interest

...

The Query Result Calculator Service is an embedded java service and accepts the following

parameters:

dataUrl: URL of the patient population data enhanced with inferred knowledge produced as a

result of reasoning process

statisticalOptions: Statistical options issued by the user

conditionOfInterest: The coded condition of interest provided by the user

medicationOfInterest: The coded medication of interest provided by the user

Some of the EYE rules included in the CSCT contain placeholders within them. For instance the rule

to obtain common conditions prior to medication of interest requires a certain medication that will be

used as a base for common conditions to be chosen. The rule used for this case can be seen in

APPENDIX 10.

Using the given parameters the required statistical results are prepared to be presented in the graphical

user interface of the CSCT. Figure 5 depicts an example calculation of the results for the statistical

option of "common conditions prior to medication of interest". Although the result for the foreground

and background are presented in the same view, the CSCT calculates results for foreground and

background populations in separate processes. The results are merged by the Safety Analysis Query

Manager.

FP7-287800 SALUS


Figure 5 Common conditions prior to medication of interest

The results prepared for a statistical option include the following pieces of information:

A display name for the result calculated for a certain statistical option

A percentage indicating the occurrence of the result in the target population (either foreground

or background). Note that this information is not presented in the "Average age" information

box.

The number of patients associated with a certain result.

5.5.11 Safety Analysis Query Manager

The Safety Analysis Query Manager Service is instructed to fetch relevant medical summaries from

the EHR data sources using the SIL-DS.

Similar to the Query Result Calculator, it serves to the CSCT in the current release. The RESTful

service of this manager used by the CSCT is deployed under the following endpoint:

http://aca.agfa.net/safetyanalysisquerymanager/population

This endpoint provides an HTTP POST method which allows sending the request in either JSON or

RDF/TURTLE format. Once the request is obtained, it is split into the following 4 parts:

Eligibility criteria.

Criteria source indicating whether the eligibility criteria are for the foreground or for the

background population.

Statistical options to be processed by the Query Result Calculator to apply statistical safety

analysis queries on the data sets once they are collected from the EHR sources.

Risk factors to be processed by the Query Result Calculator to apply statistical safety analysis

queries on the data sets once they are collected from the EHR sources.

Based on the given parameters it determines the necessary data sources and discovers these data

sources to include the necessary data sets. It collaborates with the Aggregation Service to collect the

required data sets to calculate the aggregated statistics from the EHR Sources. In the current case

series characterization implementation, the data sets to be collected include all medications,

conditions and demographics information of all the eligible patients for the background and

foreground population in SALUS CIM Ontology.

The eligibility criteria for the foreground population and the eligibility criteria for background

population are sent as two separate requests to the SALUS Aggregation Service, since the CSCT

already sends separate queries for foreground and background populations. Furthermore, this manager

gathers patient populations from different sources (LISPA and TUD in the current case) in a

concurrent way. Once the whole data is collected from all of the sources, all pieces are merged,

further processed for terminology reasoning and query result calculation, and final results are passed

to the CSCT.

FP7-287800 SALUS


After the data sets are retrieved through the Aggregation Service, first terminology reasoning is

applied. Because the patient data represented in SALUS CIM is already linked with terminology

system ontologies, before the statistical queries are run on top of patient data entities, terminology

reasoning is automatically handled with the implemented rules on top of the semantically represented

terminology mapping information.

To retrieve a data set specific to a certain source the Safety Analysis Query Manager calls the SIL-DS

services implemented using Athena. For instance, in the early prototype to obtain the eligible patient

data for background population from the LISPA source, the following RESTful service of Athena

framework is called with an HTTP GET:


t/population/medicalsummary/bg

This will run the conversion rules located in the corresponding Athena service folder to convert the

patient data obtained from the EHR sources in local entity model representations into SALUS CIM

ontology representation, as explained in Sections 5.5.3 and 5.5.5.

To apply reasoning on top of the retrieved data, another set of EYE rules is run via a RESTful call to

the Terminology Reasoning Service, as explained in Section 5.5.9. After the terminology reasoning is

done, the statistical safety analysis queries are run by using the Query Result Calculator as explained

in Section 5.5.10. Finally, the statistical results are sent to the caller, i.e. the Case Series

Charaterization Tool in the early prototype.

FP7-287800 SALUS


6 CONCLUSION AND FUTURE WORK

The current version of the semantic mediation framework provides the services and tools to support

the Case Series Characterization pilot scenario. The resulting semantic interoperability layer Stub

Semantic Interoperability Layer Data Services provide access to mock-up data of both LISPA and

TUD. Using the developed conversion rules both data sets are translated from their Content Model

Ontologies to the harmonized SALUS Common Information Model Ontology. In parallel the real

SIL-DS of TUD has been further developed and configured and already works with a stub of the real

TUD ORBIS SPARQL endpoint. The real TUD ORBIS SPARQL endpoint has been further

developed and is configured to use the UKD ORBIS system. The TUD ORBIS SPARQL endpoint has

been installed in the Agfa HealthCare’s VPN environment to UKD and has been tested on this real

UKD ORBIS system. However it has not been released yet to be used by the other SALUS services

because the security services to anonymize the extracted data are not in place yet. The other semantic

services needed to further augment the retrieved data are also developed and installed in the test

environment. Specifically the semantic services to aggregate the data from both sources (Aggregation

Service), to perform terminology reasoning and unification (Terminology Reasoning Service), to

perform the analysis on the result set for determining the characteristics of the data (Query Result

Calculator Service) and finally the overarching workflow manager (Safety Analysis Query Manager)

are developed and made available in the test environment.

In the next version of the prototype the real data sources of TUD and LISPA will be integrated. The

SIL-DS of LISPA needs to be developed and integrated. The privacy and security services need to be

integrated. The necessary model converters and model formatters need to be developed and

integrated. Finally the necessary workflow managers for the other scenarios need to be provided.

FP7-287800 SALUS


APPENDIX 1 MOCK-UP DATA

FP7-287800 SALUS


APPENDIX 2 AN EXAMPLE ORBIS SPARQL QUERY TO

RETRIEVE MEDICATION INFORMATION PREFIX cwmedgliederung: <http://www.agfa.com/w3c/orbis/orbis-schema/CwMedgliederung#>

PREFIX cwmedpraepglied: <http://www.agfa.com/w3c/orbis/orbis-schema/CwMedpraepglied#>

PREFIX cwmedpraeparat: <http://www.agfa.com/w3c/orbis/orbis-schema/CwMedpraeparat#>

PREFIX cwmedpackung: <http://www.agfa.com/w3c/orbis/orbis-schema/CwMedpackung#>

PREFIX fall: <http://www.agfa.com/w3c/orbis/orbis-schema/Fall#>

PREFIX form: <http://www.agfa.com/w3c/orbis/orbis-schema/Form#>

PREFIX listfield: <http://www.agfa.com/w3c/orbis/orbis-schema/Listfield#>

PREFIX xsd: <http://www.w3.org/2001/XMLSchema#>

CONSTRUCT {

?cwmedpackung cwmedpackung:pzn ?hasPZN.

?cwmedpackung cwmedpackung:bezeichnung ?medPackname.

?cwmedpackung cwmedpackung:medpraeparatid ?medpraeparatid.

?cwmedpraepglied cwmedpraepglied:medpraeparatid ?medpraeparatid.




?pzn listfield:hasFeldtext ?hasPZN.

?pzn listfield:hasName "PZN".

?pzn listfield:hasListName "ListeMedikamente".

?pzn listfield:belongTo ?form.

?form form:hasName ?formName.





} WHERE {

?cwmedpackung cwmedpackung:pzn ?hasPZN.

?cwmedpackung cwmedpackung:bezeichnung ?medPackname.

?cwmedpackung cwmedpackung:medpraeparatid ?medpraeparatid.

?cwmedpraepglied cwmedpraepglied:medpraeparatid ?medpraeparatid.




?pzn listfield:hasFeldtext ?hasPZN.

?pzn listfield:hasName "PZN".

?pzn listfield:hasListName "ListeMedikamente".

?pzn listfield:belongTo ?form.

?form form:hasName ?formName.





FILTER (?formName = "Rezept neu")

FILTER (?ATCcode = "C08CA05")

}

http://gnela179.agfahealthcare.com:8080/pavo/entities/www.salusproject.eu/medication?atcCode=C08CA05&beginDate=2011-01-01&endDate=2011-12-31

FP7-287800 SALUS


APPENDIX 3 AN EXAMPLE ELIGIBILITY CRITERIA

EXPRESSED IN SALUS CIM ONTOLOGY @prefix : <http://www.srdc.com.tr/ontmalizer/instance#> .

@prefix dtype: <http://www.srdc.com.tr/ontmalizer#> .

@prefix owl: <http://www.w3.org/2002/07/owl#> .


@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .

@prefix salus: <http://www.salusproject.eu/ontology/common-information-model#> .


<http://www.srdc.com.tr/ontmalizer/instance>

rdf:type owl:Ontology ;

owl:imports <http://www.salusproject.eu/ontology/common-information-model> .

:Condition_MI

rdf:type salus:Condition ;

salus:problemCode :cd_MI_ICD9CM .

:Criterion_MI

rdf:type salus:Criterion ;

salus:clinicalStatement

:Condition_MI ;

salus:temporalRelation

:TemporalConstraint_1 .

:Criterion_Nifedipine

rdf:type salus:Criterion ;

salus:clinicalStatement

:Medication_Nifedipine .

:EligibilityCriteria_DEMO

rdf:type salus:EligibilityCriteria ;

salus:inclusionCriteria

:Inclusion_CriteriaGroup .

:Inclusion_CriteriaGroup

rdf:type salus:CriteriaGroup ;

salus:conjunctionCode

:cd_AND ;

salus:groupItem :Criterion_MI , :Criterion_Nifedipine ;

salus:negationIndicator

"false"^^xsd:boolean .

:MedicationInformation_Nifedipine

rdf:type salus:MedicationInformation ;

salus:codedActiveIngredient

:cd_Nifedipine .

:Medication_Nifedipine

rdf:type salus:Medication ;


:MedicationInformation_Nifedipine .

:TemporalConstraint_1

rdf:type salus:TemporalConstraint ;

salus:pauseQuantity :ivlPq_2wk ;

salus:targetCriterion

:Criterion_Nifedipine ;

salus:typeCode :cd_SBS .

:cd_AND

rdf:type salus:cd ;

salus:code "AND" .

FP7-287800 SALUS


:cd_MI_ICD9CM

rdf:type salus:cd ;

salus:code "410" ;


salus:codeSystemName

"ICD-9-CM" .

:cd_Nifedipine

rdf:type salus:cd ;




"ATC" .

:cd_SBS

rdf:type salus:cd ;

salus:code "SBS" .

:ivlPq_2wk

rdf:type salus:ivlPq ;

salus:low :pq_2wk .

:pq_2wk

rdf:type salus:pq ;

salus:unit "wk" ;

salus:value "2" .

FP7-287800 SALUS


APPENDIX 4 AN EXAMPLE QEDEXT GET CARE

RECORD PROFILE QUERY MESSAGE <QUPC_IN043100UVext xmlns="urn:hl7-org:v3" ITSVersion="XML_1.0"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

<id root=' ' extension=' '/>

<creationTime value=' '/>

<interactionId extension='QUPC_IN043100UVext' root='2.16.840.1.113883.5'/>

<processingCode code='D|P|T'/>

<processingModeCode code='T'/>

<acceptAckCode code='AL'/>

<receiver typeCode="RCV">

<device determinerCode="INSTANCE">

<id/>

<name/>

<telecom value=' ' />

<manufacturerModelName/>

<softwareName/>

</device>

</receiver>

<sender typeCode="SND">


<id/>

<name/>

<telecom value=' ' />


<softwareName/>

</device>

</sender>

<controlActProcess moodCode="RQO">


<code code='QUPC_TE043100UV'/>

<effectiveTime value=' '/>

<languageCode code=' '/>

<authorOrPerformer typeCode=' '></authorOrPerformer>

<queryByParameter>


<statusCode code='new'/>

<responseModalityCode code='R'/>

<responsePriorityCode code='I'/>

<initialQuantity value=/>

<initialQuantityCode code='REPC_RM000100UV' codeSystem='2.16.840.1.113883'>

<parameterList>

<populationBasedQuery>

<QualityMeasureDocument>

<component>

<measureDescriptionSection>

<title> Example HQMF Query</title>

<text>This measure document is used to express a population based query in SALUS project.</text>

</measureDescriptionSection>

</component>

<component>

<dataCriteriaSection>

<entry>

<localVariableName>NifedipineMedication</localVariableName>

<substanceAdministrationCriteria moodCode="EVN">

<id root="0" extension="NifedipineMedication"/>

<participation typeCode="CSM">

<role classCode="MANU">

<playingMaterial classCode="MMAT" determinerCode="KIND">

<code code="C08CA05" codeSystem="2.16.840.1.113883.6.73"

codeSystemName="ATC">

</code>

</playingMaterial>

</role>

FP7-287800 SALUS


</participation>

<temporallyRelatedInformation typeCode="SBS">

<pauseQuantity xsi:type="IVL_PQ">

<any value='2' unit='wk'/>

</pauseQuantity>

<ObservationReference>

<id root="0" extension="MIEvent”/>

</ObservationReference>

</temporallyRelatedInformation>

</substanceAdministrationCriteria>

</entry>

<entry>

<localVariableName> MIEvent </localVariableName>

<observationCriteria>

<id root="0" extension=" MIEvent "/>

<statusCode code="completed"/>

<value xsi:type="CD" code="410" displayName="Acute myocardial Infarction"

codeSystem="2.16.840.1.113883.6.2" codeSystemName="ICD-9-CM">

</observationCriteria>

</entry>

</dataCriteriaSection>

</component>

<component>

<populationCriteriaSection>

<entry>

<patientPopulationCriteria classCode="OBS" moodCode="EVN">

<id root="c75181d0-73eb-11de-8a39-0800200c9a66"/>

<code code="IPP" codeSystem="2.16.840.1.113883.5.1063"

codeSystemName="HL7 Observation Value">

<displayName value="Included in Initial Patient Population"/>

</code>

<isCriterionInd value="true"/>

<precondition typeCode="PRCN">

<allTrue>

<precondition>

<observationReference classCode="OBS" moodCode="EVN">

<id root="0" extension="MIEvent“/>

</observationReference>

</precondition>

<precondition>

<substanceAdministrationReference moodCode="EVN">

<id root="0" extension="NifedipineMedication“/>

</substanceAdministrationReference>

</precondition>

</allTrue>

</precondition>

</patientPopulationCriteria>

</entry>

</populationCriteriaSection>

</component>

</QualityMeasureDocument>

</populationBasedQuery>

<includeCarePlanAttachment><value value='false'/></includeCarePlanAttachment>

</parameterList>

</queryByParameter>

</controlActProcess>

</QUPC_IN043100UV>

FP7-287800 SALUS


APPENDIX 5 AN EXAMPLE QEDEXT GET CARE

RECORD PROFILE QUERY RESPONSE MESSAGE <QUPC_IN043200UVext xmlns="urn:hl7-org:v3" ITSVersion="XML_1.0"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

<id root='1' extension='1'/>

<creationTime value='201302111111'/>

<interactionId extension='QUPC_IN043200UVext' root='2.16.840.1.113883.5'/>

<processingCode code='P'/>

<processingModeCode code='T'/>

<acceptAckCode code='NE'/>

<receiver typeCode="RCV">


<id root='1' extension='SIL'/>

<name/>

<telecom value='1' />


<softwareName/>

</device>

</receiver>

<sender typeCode="SND">


<id root='1' extension='LISPA-Adaptor'/>

<name/>

<telecom value='1' />


<softwareName/>

</device>

</sender>

<controlActProcess moodCode="EVN">


<code code='QUPC_TE043200UV'/>

<effectiveTime value='1'/>

<authorOrPerformer typeCode='1'></authorOrPerformer>

<subject>



<registrationEvent>

<statusCode code='active'/>

<custodian>

<assignedEntity>


<addr></addr>

<telecom></telecom>

<assignedOrganization>

<name></name>

</assignedOrganization>

</assignedEntity>

</custodian>

<subject2>

<careProvisionEvent>



<recordTarget>

<patient>

<id root='1.2.826.0.1.3680043.2.44.248240.1' extension='191'/>

<addr nullFlavor="MSK"/>

<telecom nullFlavor="MSK"/>

FP7-287800 SALUS



<patientPerson>

<name nullFlavor="MSK"/>

<administrativeGenderCode code='F' displayName=''

codeSystem='2.16.840.1.113883.5.1' codeSystemName='AdministrativeGender'/>

<birthTime value='1973'/>

</patientPerson>

</patient>

</recordTarget>



<pertinentInformation3>

<observation classCode="OBS" moodCode="EVN">

<templateId root="2.16.840.1.113883.10.20.1.28"/>

<templateId root="1.3.6.1.4.1.19376.1.5.3.1.4.5"/>

<id root="46190165-a977-4066-be72-1ba9a4f4025c"/>

<code code="55607006" displayName="Problem" codeSystem="2.16.840.1.113883.6.96"

codeSystemName="SNOMED CT"/>

<text>

Sample text

</text>


<effectiveTime>

<low value="20030801"/>

</effectiveTime>

<value xsi:type="CD" code="493" displayName="Asthma" codeSystem="2.16.840.1.113883.6.2"

codeSystemName="ICD-9-CM">

<originalText>Asthma</originalText>

</value>



<performer>

<assignedEntity>

<id extension="54321678906" root="2.16.840.1.113883.2.9.4.3.2" assigningAuthorityName="MEF

- Italian Citizen Identity Authority"/>

<code code="309345004" displayName="Chest Physicians"

codeSystem="2.16.840.1.113883.6.96" codeSystemName="SNOMED CT"/>

<addr use="WP">

<streetAddressLine>Via Don Giovanni Minzoni, No 24</streetAddressLine>

<city>Milan</city>

<state>MI</state>

<country>Italy</country>

<postalCode>20158</postalCode>

</addr>

<telecom use="WP" value="tel:+390239445566"/>

<assignedPerson>

<name>

<prefix>Dr.</prefix>

<given>Fabiola</given>

<family>Passerini</family>

</name>

</assignedPerson>

<representedOrganization>

<id root="2.16.840.1.113883.2.9.4.3.2.4" extension="65432178902"/>

<name>Wellness Care Clinic</name>

</representedOrganization>

</assignedEntity>

</performer>

<entryRelationship typeCode="SUBJ" inversionInd="true">

FP7-287800 SALUS



<templateId root="1.3.6.1.4.1.19376.1.5.3.1.4.1"/>

<templateId root="2.16.840.1.113883.10.20.1.55"/>

<code code="SEV" displayName="Severity" codeSystem="2.16.840.1.113883.5.4"

codeSystemName="ActCode"/>

<text>

Sample text

</text>


<value xsi:type="CD" code="H" displayName="High" codeSystem="2.16.840.1.113883.5.1063"

codeSystemName="ObservationValue"/>

</observation>

</entryRelationship>

<entryRelationship typeCode="REFR" inversionInd="false">


<templateId root="2.16.840.1.113883.10.20.1.57"/>

<templateId root="2.16.840.1.113883.10.20.1.50"/>

<templateId root="1.3.6.1.4.1.19376.1.5.3.1.4.1.1"/>

<code code="33999-4" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC"

displayName="Status"/>

<text>

Sample text

</text>


<value xsi:type="CE" code="55561003" codeSystem="2.16.840.1.113883.6.96"

codeSystemName="SNOMED CT" displayName="Active"/>

</observation>


</observation>

</pertinentInformation3>





<templateId root="2.16.840.1.113883.10.20.1.28"/>

<templateId root="1.3.6.1.4.1.19376.1.5.3.1.4.5"/>

<id root="46190165-a977-4066-be72-1ba9a4f4025c"/>



<text>

Sample text

</text>


<effectiveTime>

<low value="20110801"/>

</effectiveTime>

<value xsi:type="CD" code="648" displayName="Diabetes" codeSystem="2.16.840.1.113883.6.2"

codeSystemName="ICD-9-CM">

<originalText>Diabetes</originalText>

</value>

</observation>






<templateId root="2.16.840.1.113883.10.20.1.28"/>

<templateId root="1.3.6.1.4.1.19376.1.5.3.1.4.5"/>

<id root="46190165-a977-4066-be72-1ba9a4f4025c"/>

FP7-287800 SALUS




<text>

Sample text

</text>


<effectiveTime>

<low value="20120215"/>

</effectiveTime>

<value xsi:type="CD" code="410" displayName="Acute myocardial Infarction"


<originalText>Acute myocardial Infarction</originalText>

</value>

</observation>






<templateId root="1.3.6.1.4.1.19376.1.5.3.1.4.13"/>

<templateId root="1.3.6.1.4.1.19376.1.5.3.1.4.13.5"/>

<id root="97531584-aae3-4dc1-9290-2a496a151b30"/>

<code code="11778-8" displayName="Delivery Date (Clinical Estimate)"

codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC"/>

<text>

Sample text

</text>


<effectiveTime value="20110406"/>

<value xsi:type="TS" value="20111205"/>

</observation>





<procedure classCode="PROC" moodCode="EVN">

<templateId root="1.3.6.1.4.1.19376.1.5.3.1.4.19"/>

<templateId root="2.16.840.1.113883.10.20.1.29"/>

<id root="c1469c71-f76e-43d1-9003-4d2b0052f5988"/>

<code code="52734007" codeSystem="2.16.840.1.113883.6.96" codeSystemName="SNOMED CT"

displayName="Total replacement of hip">

<originalText>Total replacement of hip</originalText>

</code>

<text>

Sample text

</text>


<effectiveTime>

<low value="20080701"/>

</effectiveTime>

<targetSiteCode code="182201002" codeSystem="2.16.840.1.113883.6.96"

codeSystemName="SNOMED CT" displayName="Entire hip joint"/>

</procedure>

FP7-287800 SALUS


<templateId root="2.16.840.1.113883.10.20.1.18"/>

<templateId root="1.3.6.1.4.1.19376.1.5.3.1.4.6"/>

<id root="4adc1020-7b14-11db-9fe1-0800200c9a66"/>

<code code="ALG" displayName="Allergy" codeSystem="2.16.840.1.113883.5.4"

codeSystemName="ObservationIntoleranceType"/>

<text>

Sample text

</text>


<effectiveTime>

<low value="20080624"/>

</effectiveTime>

<value xsi:type="CD" code="419199007" codeSystem="2.16.840.1.113883.6.96"

codeSystemName="SNOMED CT" displayName="Allergy to substance">

<originalText>Allergy to substance</originalText>

</value>

<participant typeCode="CSM">

<participantRole classCode="MANU">

<playingEntity classCode="MMAT">

<code code="J01CA" codeSystem="2.16.840.1.113883.6.73" codeSystemName="ATC"

displayName="Penicillins with extended spectrum">

<originalText>Penicillin</originalText>

</code>

</playingEntity>

</participantRole>

</participant>

<entryRelationship typeCode="MFST" inversionInd="true">

<templateId root="1.3.6.1.4.1.19376.1.5.3.1.4.6.1"/>


<templateId root="2.16.840.1.113883.10.20.1.54"/>

<templateId root="2.16.840.1.113883.10.20.1.28"/>

<templateId root="1.3.6.1.4.1.19376.1.5.3.1.4.5"/>

<id root="723c3d9b-655d-44ae-8ac0-9f410fbd28e2"/>



<text>

Sample text

</text>


<value xsi:type="CD" code="519.11" codeSystem="2.16.840.1.113883.6.2"

codeSystemName="ICD-9 CM" displayName="Bronchospasm"/>

</observation>




<templateId root="2.16.840.1.113883.10.20.1.57"/>

<templateId root="2.16.840.1.113883.10.20.1.50"/>

<templateId root="1.3.6.1.4.1.19376.1.5.3.1.4.1.1"/>


displayName="Status"/>

<text>

Sample text

</text>


<value xsi:type="CE" code="55561003" codeSystem="2.16.840.1.113883.6.96"

codeSystemName="SNOMED CT" displayName="Active"/>

</observation>


<entryRelationship typeCode="SUBJ" inversionInd="true">


<templateId root="1.3.6.1.4.1.19376.1.5.3.1.4.1"/>

<templateId root="2.16.840.1.113883.10.20.1.55"/>

<code code="SEV" displayName="Severity" codeSystem="2.16.840.1.113883.5.4"

codeSystemName="ActCode"/>

<text>

Sample text

</text>

FP7-287800 SALUS



<value xsi:type="CD" code="H" displayName="High" codeSystem="2.16.840.1.113883.5.1063"

codeSystemName="ObservationValue"/>

</observation>


</observation>





<substanceAdministration classCode="SBADM" moodCode="INT">

<templateId root="2.16.840.1.113883.10.20.1.24"/>

<templateId root="1.3.6.1.4.1.19376.1.5.3.1.4.7"/>

<id root="9e4c4be7-0d46-49cf-ba1e-170b534tgd54"/>

<text>

Sample text

</text>


<effectiveTime xsi:type="IVL_TS">

<low value="20080201"/>

<high value="20080210"/>

</effectiveTime>

<effectiveTime xsi:type="PIVL_TS" institutionSpecified="true" operator="A">

<period value="12" unit="h"/>

</effectiveTime>

<routeCode code="IPINHL" codeSystem="2.16.840.1.113883.5.112"

codeSystemName="RouteOfAdministration" displayName="Inhalation, oral"/>

<approachSiteCode code="181195007" displayName="Entire nose"


<doseQuantity value="5" unit="mL"/>

<maxDoseQuantity>

<numerator value="5" unit="mL"/>

<denominator value="10" unit="mL"/>

</maxDoseQuantity>

<administrationUnitCode code="415215001" displayName="Puff"


<consumable>

<manufacturedProduct classCode="MANU">

<templateId root="2.16.840.1.113883.10.20.1.53"/>

<templateId root="1.3.6.1.4.1.19376.1.5.3.1.4.7.2"/>

<manufacturedMaterial>

<code code="Code_to_be_found" codeSystem="OID_to_be_found" codeSystemName="AIC"

displayName="Albuterol 1 MG/ML Inhalant Solution">

<originalText>Albuterol 1 MG/ML Inhalant Solution</originalText>

<translation code="R03AC02" displayName="Salbutamol"

codeSystem="2.16.840.1.113883.6.73" codeSystemName="ATC"/>

</code>

<name>Albuterol 1 MG/ML Inhalant Solution [Ventolin]</name>

</manufacturedMaterial>

</manufacturedProduct>

</consumable>

<entryRelationship typeCode="RSON">


<templateId root="1.3.6.1.4.1.19376.1.5.3.1.4.5"/>

<templateId root="2.16.840.1.113883.10.20.1.28"/>

<id root="45ae5968-7cf1-4fc2-8705-f639cb6d12d3"/>




<effectiveTime>

<low value="20080201"/>

</effectiveTime>

FP7-287800 SALUS


<value xsi:type="CD" code="493" displayName="Asthma" codeSystem="2.16.840.1.113883.6.2"

codeSystemName="ICD-9-CM"/>

</observation>





<supply classCode="SPLY" moodCode="INT">

<templateId root="2.16.840.1.113883.10.20.1.34"/>

<templateId root="1.3.6.1.4.1.19376.1.5.3.1.4.7.3"/>


<repeatNumber value="2"/>

<quantity value="1"/>

<author>

<time value="20080201"/>

<assignedAuthor>

<id extension="54321678905" root="2.16.840.1.113883.2.9.4.3.2"

assigningAuthorityName="MEF - Italian Citizen Identity Authority"/>

<assignedPerson>

<name>


<given>Ersilia</given>

<family>Palladino</family>

</name>

</assignedPerson>



<name>Good Health Clinic</name>


</assignedAuthor>

</author>

</supply>





<sequenceNumber value="1"/>

<supply classCode="SPLY" moodCode="EVN">

<templateId root="2.16.840.1.113883.10.20.1.34"/>

<templateId root="1.3.6.1.4.1.19376.1.5.3.1.4.7.3"/>



<quantity value="1"/>

<performer typeCode="PRF">

<time value="20080201"/>

<assignedEntity>

<id extension="54321678908" root="2.16.840.1.113883.2.9.4.3.2"

assigningAuthorityName="MEF - Italian Citizen Identity Authority"/>

<assignedPerson>

<name>


<given>Ottone</given>

<family>Salucci</family>

</name>

</assignedPerson>



<name>Good Health Pharmacy</name>


</assignedEntity>

</performer>

</supply>




<entryRelationship typeCode="SUBJ">

<act classCode="ACT" moodCode="INT">

<templateId root="2.16.840.1.113883.10.20.1.49"/>

<templateId root="1.3.6.1.4.1.19376.1.5.3.1.4.3"/>

FP7-287800 SALUS


<code code="PINSTRUCT" codeSystem="1.3.6.1.4.1.19376.1.5.3.2"

codeSystemName="IHEActCode"/>

<text>

Sample text

</text>


</act>





<act classCode="ACT" moodCode="INT">

<templateId root="2.16.840.1.113883.10.20.1.49"/>

<templateId root="1.3.6.1.4.1.19376.1.5.3.1.4.3.1"/>

<code code="FINSTRUCT" codeSystem="1.3.6.1.4.1.19376.1.5.3.2"

codeSystemName="IHEActCode"/>

<text>

Sample text

</text>


</act>




<entryRelationship typeCode="CAUS">


<templateId root="2.16.840.1.113883.10.20.1.54"/>

<code code="ASSERTION" codeSystem="2.16.840.1.113883.5.4"/>


<value xsi:type="CD" code="56018004" displayName="Wheezing"


</observation>


</substanceAdministration>






<templateId root="2.16.840.1.113883.10.20.1.24"/>

<templateId root="1.3.6.1.4.1.19376.1.5.3.1.4.7"/>

<id root="9e4c4be7-0d46-49cf-ba1e-170b58545gba"/>

<text>

Sample text

</text>



<low value="20120201"/>

<high value="20120210"/>

</effectiveTime>



</effectiveTime>

<routeCode code="PO" codeSystem="2.16.840.1.113883.5.112"


<doseQuantity value="1"/>

<consumable>


<templateId root="2.16.840.1.113883.10.20.1.53"/>

<templateId root="1.3.6.1.4.1.19376.1.5.3.1.4.7.2"/>



displayName="Procardia Oral">

<originalText>Procardia Oral</originalText>

<translation code="C08CA05" displayName="Nifedipine"

FP7-287800 SALUS


</code>

<name>Procardia Oral</name>



</consumable>






<encounter classCode="ENC" moodCode="EVN">

<templateId root="1.3.6.1.4.1.19376.1.5.3.1.4.14"/>

<templateId root="2.16.840.1.113883.10.20.1.21"/>

<id root="2a620155-9d11-439e-92b3-5d9815ff4de8"/>

<code code="GENRL" displayName="General" codeSystem="2.16.840.1.113883.5.4"

codeSystemName="ActEncounterCode">

<originalText>Checkup Examination</originalText>

</code>

<effectiveTime>

<low value="20090331"/>

<high value="20090331"/>

</effectiveTime>

<performer>

<assignedEntity>

<id extension="54321678906" root="2.16.840.1.113883.2.9.4.3.2" assigningAuthorityName="MEF

- Italian Citizen Identity Authority"/>

<code code="309345004" displayName="Chest Physicians"


<addr use="WP">


<city>Milan</city>

<state>MI</state>



</addr>

<telecom use="WP" value="tel:+390239445566"/>

<assignedPerson>

<name>


<given>Fabiola</given>

<family>Passerini</family>

</name>

</assignedPerson>





</assignedEntity>

</performer>

<participant typeCode="LOC">

<templateId root="2.16.840.1.113883.10.20.1.45"/>

<participantRole classCode="SDLOC">


<addr use="WP">


<city>Milan</city>

<state>MI</state>



</addr>

<playingEntity classCode="PLC">

FP7-287800 SALUS


</playingEntity>

</participantRole>

</participant>

<entryRelationship typeCode="RSON">


<templateId root="1.3.6.1.4.1.19376.1.5.3.1.4.5"/>

<templateId root="2.16.840.1.113883.10.20.1.28"/>

<id root="d11275e7-67ae-11db-bd13-0800200c9a66"/>

<code code="282291009" displayName="Diagnosis" codeSystem="2.16.840.1.113883.6.96"



<effectiveTime>

<low value="20090331"/>

</effectiveTime>

<value xsi:type="CD" code="578.9" displayName="Hemorrhage of gastrointestinal tract,

unspecified" codeSystem="2.16.840.1.113883.6.2" codeSystemName="ICD-9-CM"/>

</observation>


</encounter>


</careProvisionEvent>

</subject2>

</registrationEvent>



<registrationEvent>


<custodian>

<assignedEntity>


<addr></addr>

<telecom></telecom>

<assignedOrganization>

<name></name>

</assignedOrganization>

</assignedEntity>

</custodian>

<subject2>

<careProvisionEvent>

<recordTarget>

<patient>

<id root='1.2.826.0.1.3680043.2.44.248240.1' extension='2345'/>

<addr nullFlavor="MSK"/>

<telecom nullFlavor="MSK"/>


<patientPerson>

<name nullFlavor="MSK"/>

<administrativeGenderCode code='M' displayName=''

codeSystem='2.16.840.1.113883.5.1' codeSystemName='AdministrativeGender'/>

<birthTime value='1956'/>

</patientPerson>

</patient>

</recordTarget>





<templateId root="2.16.840.1.113883.10.20.1.28"/>

<templateId root="1.3.6.1.4.1.19376.1.5.3.1.4.5"/>

<id root="2a29b507-3416-4a50-9e6a-9e05fa9f2af0"/>

FP7-287800 SALUS




<text>

Sample text

</text>


<effectiveTime>

<low value="20090101"/>

</effectiveTime>

<value xsi:type="CD" code="278" displayName="Obesity, unspecified"


<originalText>Obesity, unspecified</originalText>

</value>

</observation>






<templateId root="2.16.840.1.113883.10.20.1.28"/>

<templateId root="1.3.6.1.4.1.19376.1.5.3.1.4.5"/>




<text>

Sample text

</text>


<effectiveTime>

<low value="20090401"/>

</effectiveTime>

<value xsi:type="CD" code="410.7" displayName="Non-ST elevation myocardial infarction

(NSTEMI)" codeSystem="2.16.840.1.113883.6.2" codeSystemName="ICD-9-CM">

<originalText>Non-ST elevation myocardial infarction (NSTEMI)</originalText>

</value>

</observation>






<templateId root="2.16.840.1.113883.10.20.1.24"/>

<templateId root="1.3.6.1.4.1.19376.1.5.3.1.4.7"/>

<id root="9e4c4be7-0d46-49cf-ba1e-170aa855bb5a"/>

<text>

Sample text

</text>



<low value="20090325"/>

</effectiveTime>



</effectiveTime>




<consumable>


<templateId root="2.16.840.1.113883.10.20.1.53"/>

<templateId root="1.3.6.1.4.1.19376.1.5.3.1.4.7.2"/>

FP7-287800 SALUS




displayName="Procardia Oral">

<originalText>Procardia Oral</originalText>

<translation code="C08CA05" displayName="Nifedipine"


</code>

<name>Procardia Oral</name>



</consumable>







<templateId root="2.16.840.1.113883.10.20.1.24"/>

<templateId root="1.3.6.1.4.1.19376.1.5.3.1.4.7"/>

<id root="9e4c4be7-0d46-49cf-ba1e-170b5856bb5d"/>

<text>

Sample text

</text>



<low value="20090310"/>

</effectiveTime>



</effectiveTime>




<consumable>


<templateId root="2.16.840.1.113883.10.20.1.53"/>

<templateId root="1.3.6.1.4.1.19376.1.5.3.1.4.7.2"/>


<code code="Code_to_be_found" codeSystem="OID_to_be_found"

codeSystemName="AIC" displayName="Advil 200 Mg Caplets">

<originalText>Advil 200 Mg Caplets</originalText>

<translation code="C01EB16" displayName="ibuprofen"


</code>

<name>Advil 200 Mg Caplets</name>



</consumable>



</careProvisionEvent>

</subject2>

</registrationEvent>

</subject>

<queryAck>

<queryId root='1' extension='11'/>

<statusCode code='1'/>

<queryResponseCode code='1'/>

<resultCurrentQuantity value='1'/>

<resultRemainingQuantity value='1'/>

</queryAck>

</controlActProcess>

</QUPC_IN043200UVext>

FP7-287800 SALUS


APPENDIX 6 AN EXAMPLE MEDICAL SUMMARY IN HL7

CDA FORMAT USING PCC/CCD TEMPLATES <?xml version="1.0" encoding="UTF-8" standalone="yes"?>

<ClinicalDocument xmlns="urn:hl7-org:v3" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">



<typeId root="2.16.840.1.113883.1.3" extension="POCD_HD000040"/>

<templateId root="2.16.840.1.113883.10.20.1"/>

<id root="db734647-fc99-424c-a864-7e3cda82e703"/>


displayName="Summarization of episode note"/>

<title>SALUS Patient Summary Instance</title>

<effectiveTime value="20130307130000+0200"/>

<confidentialityCode code="N" codeSystem="2.16.840.1.113883.5.25"/>

<languageCode code="en-US"/>

<recordTarget>

<patientRole>

<id extension="547001" root="2.16.840.1.113883.2.9.4.3.2" assigningAuthorityName="MEF - Italian Citizen

Identity Authority"/>

<addr use="HP">

<city>Milan</city>

<state>MI</state>


</addr>

<patient>

<name>

<given>Patient1</given>

<family>Cremona</family>

</name>

<administrativeGenderCode code="M" displayName="Male" codeSystem="2.16.840.1.113883.5.1"

codeSystemName="AdministrativeGender"/>

<birthTime value="19450201"/>

</patient>

<providerOrganization>


</providerOrganization>

</patientRole>

</recordTarget>

<author>

<time value="20130307130000+0200"/>

<assignedAuthor>


<assignedAuthoringDevice>

<softwareName>SALUS LISPA Connector v0.1</softwareName>

</assignedAuthoringDevice>




</assignedAuthor>

</author>

<custodian>

<assignedCustodian>

<representedCustodianOrganization>


<name>Lombardy Region</name>

</representedCustodianOrganization>

</assignedCustodian>

</custodian>

<component>

<structuredBody>

<!--

FP7-287800 SALUS


********************************************************

Active problems section

********************************************************

-->

<component>

<section>

<templateId root="2.16.840.1.113883.10.20.1.11"/>

<templateId root="1.3.6.1.4.1.19376.1.5.3.1.3.6"/>

<id root="087e4130-770a-42ee-879e-e60a1fc76110"/>


displayName="Problem list - Reported"/>

<title>Problem List</title>

<text>

<table>

<thead>

<tr>

<th>Condition</th>

<th>Effective Dates</th>

</tr>

</thead>

<tbody>

<tr ID="actprob1">

<td ID="actprob1_condition">Malignant essential hypertension</td>

<td ID="actprob1_date">01.07.2009</td>

</tr>

<tr ID="actprob2">

<td ID="actprob2_condition">New daily persistent headache</td>


</tr>

<tr ID="actprob3">

<td ID="actprob3_condition">Obesity, unspecified</td>


</tr>

</tbody>

</table>

</text>

<entry>

<act classCode="ACT" moodCode="EVN">

<templateId root="2.16.840.1.113883.10.20.1.27"/>

<templateId root="1.3.6.1.4.1.19376.1.5.3.1.4.5.1"/>

<templateId root="1.3.6.1.4.1.19376.1.5.3.1.4.5.2"/>

<id root="37e7fef6-2c79-41fe-850e-b1994cdbf869"/>

<code nullFlavor="NA"/>

<text>

<reference value="#actprob1"/>

</text>



<templateId root="2.16.840.1.113883.10.20.1.28"/>

<templateId root="1.3.6.1.4.1.19376.1.5.3.1.4.5"/>

<id root="46190165-a977-4066-be72-1ba9a4f4025c"/>



<text>

<reference value="#actprob1_condition"/>

</text>


<effectiveTime>

<low value="20090701"/>

</effectiveTime>

<value xsi:type="CD" code="401.0" displayName="Malignant essential hypertension"


<originalText>Malignant essential hypertension</originalText>

</value>

</observation>


</act>

FP7-287800 SALUS


</entry>

<entry>


<templateId root="2.16.840.1.113883.10.20.1.27"/>

<templateId root="1.3.6.1.4.1.19376.1.5.3.1.4.5.1"/>

<templateId root="1.3.6.1.4.1.19376.1.5.3.1.4.5.2"/>



<text>


</text>



<templateId root="2.16.840.1.113883.10.20.1.28"/>

<templateId root="1.3.6.1.4.1.19376.1.5.3.1.4.5"/>

<id root="46190165-a977-4066-be72-1ba9a4f4025c"/>



<text>


</text>


<effectiveTime>

<low value="20090725"/>

</effectiveTime>

<value xsi:type="CD" code="339.42" displayName="New daily persistent headache"


<originalText>New daily persistent headache</originalText>

</value>

</observation>


</act>

</entry>

<entry>


<templateId root="2.16.840.1.113883.10.20.1.27"/>

<templateId root="1.3.6.1.4.1.19376.1.5.3.1.4.5.1"/>

<templateId root="1.3.6.1.4.1.19376.1.5.3.1.4.5.2"/>



<text>


</text>



<templateId root="2.16.840.1.113883.10.20.1.28"/>

<templateId root="1.3.6.1.4.1.19376.1.5.3.1.4.5"/>

<id root="46190165-a977-4066-be72-1ba9a4f4025c"/>



<text>


</text>


<effectiveTime>

<low value="20060601"/>

</effectiveTime>

<value xsi:type="CD" code="278.00" displayName="Obesity, unspecified"


<originalText>Obesity, unspecified</originalText>

</value>

</observation>


</act>

</entry>

</section>

</component>

FP7-287800 SALUS




<component>

<section>

<templateId root="1.3.6.1.4.1.19376.1.5.3.1.3.8"/>

<id root="93939ef9-05f7-4ad1-83e3-c23917d51d19"/>


displayName="History of past illness"/>

<title>History of past illness</title>

<text>

<table>

<thead>

<tr>

<th>Condition</th>

<th>Effective Dates</th>

</tr>

</thead>

<tbody>

<tr ID="pastprob1">

<td ID="pastprob1_condition">Acute myocardial infarction</td>

<td ID="pastprob1_date">01.08.2009</td>

</tr>

</tbody>

</table>

</text>

<entry>


<templateId root="2.16.840.1.113883.10.20.1.27"/>

<templateId root="1.3.6.1.4.1.19376.1.5.3.1.4.5.1"/>

<templateId root="1.3.6.1.4.1.19376.1.5.3.1.4.5.2"/>

<id root="a0fff30c-b94e-4eee-b5f5-bf5a79ebb929"/>


<text>

<reference value="#pastprob1"/>

</text>



<templateId root="2.16.840.1.113883.10.20.1.28"/>

<templateId root="1.3.6.1.4.1.19376.1.5.3.1.4.5"/>




<text>

<reference value="#pastprob1_condition"/>

</text>


<effectiveTime>

<low value="20090801"/>

<high value="20090801"/>

</effectiveTime>

<value xsi:type="CD" code="410" displayName="Acute myocardial infarction"


<originalText>Acute myocardial infarction</originalText>

</value>

</observation>


</act>

</entry>

</section>

</component>

<!--

********************************************************

Medications section

********************************************************

FP7-287800 SALUS


-->

<component>

<section>

<templateId root="2.16.840.1.113883.10.20.1.8"/>

<templateId root="1.3.6.1.4.1.19376.1.5.3.1.3.19"/>

<id root="3876f056-6ed4-4f77-9e6a-fdee4f88411d"/>


displayName="History of medication use"/>

<title>History of medication use</title>

<text>

<table>

<thead>

<tr>

<th>Medication</th>

<th>Date</th>

</tr>

</thead>

<tbody>

<tr ID="med1">

<td ID="med1_name">nifedipine</td>

<td ID="med1_date">20.07.2009</td>

</tr>

<tr ID="med2">

<td ID="med2_name">acetylsalicylic acid</td>

<td ID="med2_date">02.08.2009</td>

</tr>

<tr ID="med3">

<td ID="med3_name">losartan</td>

<td ID="med3_date">20.07.2009</td>

</tr>

</tbody>

</table>

</text>

<entry>


<templateId root="2.16.840.1.113883.10.20.1.24"/>

<templateId root="1.3.6.1.4.1.19376.1.5.3.1.4.7"/>

<id root="9e4c4be7-0d46-49cf-ba1e-170b5855bb5a"/>

<text>

<reference value="#med1"/>

</text>



<low value="20090720"/>

</effectiveTime>



</effectiveTime>


codeSystemName="RouteOfAdministration" displayName="Swallow, oral"/>

<doseQuantity value="10" unit="mg"/>

<consumable>


<templateId root="2.16.840.1.113883.10.20.1.53"/>

<templateId root="1.3.6.1.4.1.19376.1.5.3.1.4.7.2"/>


<code code="316352" codeSystem="2.16.840.1.113883.6.88" codeSystemName="RxNorm"

displayName="Nifedipine 10 MG">

<originalText>Nifedipine 10 MG</originalText>

<translation code="C08CA05" displayName="nifedipine"


</code>



</consumable>


</entry>

FP7-287800 SALUS


<entry>


<templateId root="2.16.840.1.113883.10.20.1.24"/>

<templateId root="1.3.6.1.4.1.19376.1.5.3.1.4.7"/>


<text>


</text>



<low value="20090802"/>

</effectiveTime>


<period value="1" unit="d"/>

</effectiveTime>




<consumable>


<templateId root="2.16.840.1.113883.10.20.1.53"/>

<templateId root="1.3.6.1.4.1.19376.1.5.3.1.4.7.2"/>



displayName="Aspirin 250 MG">

<originalText>Aspirin 250 MG</originalText>

<translation code="B01AC06" displayName="acetylsalicylic acid"


</code>



</consumable>


</entry>

<entry>


<templateId root="2.16.840.1.113883.10.20.1.24"/>

<templateId root="1.3.6.1.4.1.19376.1.5.3.1.4.7"/>


<text>


</text>



<low value="20090720"/>

</effectiveTime>


<period value="1" unit="d"/>

</effectiveTime>




<consumable>


<templateId root="2.16.840.1.113883.10.20.1.53"/>

<templateId root="1.3.6.1.4.1.19376.1.5.3.1.4.7.2"/>



displayName="Losartan Potassium 50 MG Oral Tablet">

<originalText>Losartan Potassium 50 MG Oral Tablet</originalText>

<translation code="C09CA01" displayName="losartan" codeSystem="2.16.840.1.113883.6.73"

codeSystemName="ATC"/>

</code>



</consumable>


FP7-287800 SALUS


</entry>

</section>

</component>

</structuredBody>

</component>

</ClinicalDocument>

FP7-287800 SALUS


APPENDIX 7 AN EXAMPLE MEDICAL SUMMARY AS AN

INSTANCE OF HL7 CDA OWL MODEL @prefix : <http://www.srdc.com.tr/ontmalizer/instance#> .


@prefix v3: <urn:hl7-org:v3#> .

@prefix owl: <http://www.w3.org/2002/07/owl#> .


@prefix dtype: <http://www.srdc.com.tr/ontmalizer#> .


:INS2007004_II_2

a v3:II ;

v3:assigningAuthorityName

"MEF - Italian Citizen Identity Authority"^^v3:stDatatype ;

v3:extension "547001"^^v3:stDatatype ;

v3:root "2.16.840.1.113883.2.9.4.3.2"^^v3:uidDatatype .

:INS2007004_CS_7

a v3:CS ;

v3:code "completed"^^v3:csDatatype .

<http://www.srdc.com.tr/ontmalizer/instance#INS2007004_POCD_MT000040.Entry_7>

a <urn:hl7-org:v3#POCD_MT000040.Entry> ;

v3:substanceAdministration

<http://www.srdc.com.tr/ontmalizer/instance#INS2007004_POCD_MT000040.SubstanceAdministration_3> .

:INS2007004_ED_3

a v3:ED ;

v3:textContent "Malignant essential hypertension"^^xsd:string .

:INS2007004_TEL_11

a v3:TEL ;

v3:value "#med3"^^v3:urlDatatype .

:INS2007004_IVXB_TS_3

a v3:IVXB_TS ;

v3:value "20060601"^^v3:tsDatatype .

:INS2007004_CE_4

a v3:CE ;

v3:code "11450-4"^^v3:csDatatype ;

v3:codeSystem "2.16.840.1.113883.6.1"^^v3:uidDatatype ;

v3:codeSystemName "LOINC"^^v3:stDatatype ;

v3:displayName "Problem list - Reported"^^v3:stDatatype .

<http://www.srdc.com.tr/ontmalizer/instance#INS2007004_POCD_MT000040.InfrastructureRoot.templateId_37>

a <urn:hl7-org:v3#POCD_MT000040.InfrastructureRoot.templateId> ;

v3:root "2.16.840.1.113883.10.20.1.53"^^v3:uidDatatype .

:INS2007004_TEL_4

a v3:TEL ;

v3:value "#actprob2_condition"^^v3:urlDatatype .

<http://www.srdc.com.tr/ontmalizer/instance#INS2007004_StrucDoc.Td_9>

a <urn:hl7-org:v3#StrucDoc.Td> ;

v3:ID "med1_name"^^xsd:ID ;

v3:textContent "nifedipine"^^xsd:string .

:INS2007004_CD_13

a v3:CD ;

v3:code "C08CA05"^^v3:csDatatype ;


v3:codeSystemName "ATC"^^v3:stDatatype ;

v3:displayName "nifedipine"^^v3:stDatatype .

FP7-287800 SALUS


:INS2007004_CS_8

a v3:CS ;


:INS2007004_ED_4

a v3:ED ;

v3:reference :INS2007004_TEL_3 .

:INS2007004_CE_5

a v3:CE ;




v3:displayName "History of past illness"^^v3:stDatatype .

:INS2007004_II_3

a v3:II ;


v3:root "2.16.840.1.113883.2.9.4.3.2.4"^^v3:uidDatatype .

<http://www.srdc.com.tr/ontmalizer/instance#INS2007004_POCD_MT000040.CustodianOrganization_1>

a <urn:hl7-org:v3#POCD_MT000040.CustodianOrganization> ;

v3:id :INS2007004_II_6 ;

v3:name :INS2007004_ON_1 .






a v3:IVXB_TS ;


<http://www.srdc.com.tr/ontmalizer/instance#INS2007004_StrucDoc.Tr_1>

a <urn:hl7-org:v3#StrucDoc.Tr> ;

v3:th <http://www.srdc.com.tr/ontmalizer/instance#INS2007004_StrucDoc.Th_1> ,

<http://www.srdc.com.tr/ontmalizer/instance#INS2007004_StrucDoc.Th_2> .



v3:root "1.3.6.1.4.1.19376.1.5.3.1.4.7.2"^^v3:uidDatatype .

:INS2007004_TEL_3

a v3:TEL ;

v3:value "#actprob2"^^v3:urlDatatype .

<http://www.srdc.com.tr/ontmalizer/instance#INS2007004_POCD_MT000040.SubstanceAdministration_1>

a <urn:hl7-org:v3#POCD_MT000040.SubstanceAdministration> ;

v3:classCode "SBADM"^^v3:ActClassDatatype ;

v3:consumable <http://www.srdc.com.tr/ontmalizer/instance#INS2007004_POCD_MT000040.Consumable_1> ;

v3:doseQuantity :INS2007004_IVL_PQ_1 ;

v3:effectiveTime :INS2007004_IVL_TS_5 , :INS2007004_PIVL_TS_1 ;

v3:id :INS2007004_II_18 ;

v3:moodCode "INT"^^v3:x_DocumentSubstanceMoodDatatype ;

v3:routeCode :INS2007004_CE_7 ;

v3:statusCode :INS2007004_CS_6 ;

v3:templateId

<http://www.srdc.com.tr/ontmalizer/instance#INS2007004_POCD_MT000040.InfrastructureRoot.templateId_27> ,

<http://www.srdc.com.tr/ontmalizer/instance#INS2007004_POCD_MT000040.InfrastructureRoot.templateId_28> ;

v3:text :INS2007004_ED_13 .

:INS2007004_CD_12

a v3:CD ;

v3:code "410"^^v3:csDatatype ;


FP7-287800 SALUS


v3:codeSystemName "ICD-9-CM"^^v3:stDatatype ;

v3:displayName "Acute myocardial infarction"^^v3:stDatatype ;

v3:originalText :INS2007004_ED_12 .

<http://www.srdc.com.tr/ontmalizer/instance#INS2007004_en.given_1>

a <urn:hl7-org:v3#en.given> ;

v3:textContent "Patient1"^^xsd:string .

:INS2007004_TEL_6

a v3:TEL ;


:INS2007004_ST_3

a v3:ST ;

v3:textContent "History of past illness"^^xsd:string .

:INS2007004_CE_6

a v3:CE ;




v3:displayName "History of medication use"^^v3:stDatatype .

:INS2007004_II_10

a v3:II ;

v3:root "37e7fef6-2c79-41fe-850e-b1994cdbf869"^^v3:uidDatatype .

:INS2007004_ED_5

a v3:ED ;






a v3:IVXB_TS ;


:INS2007004_IVL_TS_7

a v3:IVL_TS ;

v3:low :INS2007004_IVXB_TS_8 .

:INS2007004_CD_11

a v3:CD ;



v3:codeSystemName "SNOMED CT"^^v3:stDatatype ;

v3:displayName "Problem"^^v3:stDatatype .






v3:effectiveTime :INS2007004_PIVL_TS_2 , :INS2007004_IVL_TS_6 ;

v3:id :INS2007004_II_19 ;




v3:templateId



v3:text :INS2007004_ED_15 .



FP7-287800 SALUS


v3:ID "pastprob1_condition"^^xsd:ID ;

v3:textContent "Acute myocardial infarction"^^xsd:string .

:INS2007004_ST_4

a v3:ST ;

v3:textContent "History of medication use"^^xsd:string .

:INS2007004_CE_7

a v3:CE ;

v3:code "PO"^^v3:csDatatype ;


v3:codeSystemName "RouteOfAdministration"^^v3:stDatatype ;

v3:displayName "Swallow, oral"^^v3:stDatatype .

:INS2007004_II_11

a v3:II ;

v3:root "46190165-a977-4066-be72-1ba9a4f4025c"^^v3:uidDatatype .

<http://www.srdc.com.tr/ontmalizer/instance#INS2007004_POCD_MT000040.AuthoringDevice_1>

a <urn:hl7-org:v3#POCD_MT000040.AuthoringDevice> ;

v3:softwareName :INS2007004_SC_1 .

:INS2007004_II_1

a v3:II ;

v3:root "db734647-fc99-424c-a864-7e3cda82e703"^^v3:uidDatatype .

:INS2007004_ED_6

a v3:ED ;

v3:textContent "New daily persistent headache"^^xsd:string .

<http://www.srdc.com.tr/ontmalizer/instance#INS2007004_POCD_MT000040.Section_3>

a <urn:hl7-org:v3#POCD_MT000040.Section> ;

v3:code :INS2007004_CE_6 ;

v3:entry <http://www.srdc.com.tr/ontmalizer/instance#INS2007004_POCD_MT000040.Entry_7> ,

<http://www.srdc.com.tr/ontmalizer/instance#INS2007004_POCD_MT000040.Entry_6> ,

<http://www.srdc.com.tr/ontmalizer/instance#INS2007004_POCD_MT000040.Entry_5> ;

v3:id :INS2007004_II_17 ;

v3:templateId



v3:text <http://www.srdc.com.tr/ontmalizer/instance#INS2007004_StrucDoc.Text_3> ;

v3:title :INS2007004_ST_4 .


a v3:IVL_TS ;



a v3:IVXB_TS ;







v3:effectiveTime :INS2007004_PIVL_TS_3 , :INS2007004_IVL_TS_7 ;

v3:id :INS2007004_II_20 ;




v3:templateId



v3:text :INS2007004_ED_17 .


FP7-287800 SALUS



v3:ID "pastprob1_date"^^xsd:ID ;

v3:textContent "01.08.2009"^^xsd:string .

:INS2007004_CD_10

a v3:CD ;

v3:nullFlavor "NA"^^v3:NullFlavorDatatype .

:INS2007004_TEL_5

a v3:TEL ;


:INS2007004_CE_10

a v3:CE ;



v3:codeSystemName "RxNorm"^^v3:stDatatype ;

v3:displayName "Aspirin 250 MG"^^v3:stDatatype ;

v3:originalText :INS2007004_ED_16 ;

v3:translation :INS2007004_CD_14 .

<http://www.srdc.com.tr/ontmalizer/instance#INS2007004_POCD_MT000040.Component3_1>

a <urn:hl7-org:v3#POCD_MT000040.Component3> ;

v3:section <http://www.srdc.com.tr/ontmalizer/instance#INS2007004_POCD_MT000040.Section_1> .



v3:code :INS2007004_CE_5 ;

v3:entry <http://www.srdc.com.tr/ontmalizer/instance#INS2007004_POCD_MT000040.Entry_4> ;

v3:id :INS2007004_II_14 ;

v3:templateId





a v3:IVXB_TS ;


:INS2007004_CS_3

a v3:CS ;


:INS2007004_ST_1

a v3:ST ;

v3:textContent "SALUS Patient Summary Instance"^^xsd:string .

:INS2007004_II_12

a v3:II ;


:INS2007004_CE_8

a v3:CE ;




v3:displayName "Nifedipine 10 MG"^^v3:stDatatype ;



<http://www.srdc.com.tr/ontmalizer/instance#INS2007004_StrucDoc.Th_5>

a <urn:hl7-org:v3#StrucDoc.Th> ;

v3:textContent "Medication"^^xsd:string .


a v3:IVL_PQ ;


FP7-287800 SALUS






:INS2007004_II_6

a v3:II ;



:INS2007004_TEL_8

a v3:TEL ;

v3:value "#pastprob1_condition"^^v3:urlDatatype .



v3:ID "med3_date"^^xsd:ID ;




v3:act <http://www.srdc.com.tr/ontmalizer/instance#INS2007004_POCD_MT000040.Act_3> .

:INS2007004_CD_8

a v3:CD ;





<http://www.srdc.com.tr/ontmalizer/instance#INS2007004_StrucDoc.Thead_3>

a <urn:hl7-org:v3#StrucDoc.Thead> ;

v3:tr <http://www.srdc.com.tr/ontmalizer/instance#INS2007004_StrucDoc.Tr_7> .






v3:ID "actprob3"^^xsd:ID ;

v3:td <http://www.srdc.com.tr/ontmalizer/instance#INS2007004_StrucDoc.Td_6> ,

<http://www.srdc.com.tr/ontmalizer/instance#INS2007004_StrucDoc.Td_5> .

:INS2007004_II_7

a v3:II ;

v3:root "087e4130-770a-42ee-879e-e60a1fc76110"^^v3:uidDatatype .







:INS2007004_CE_11

a v3:CE ;





:INS2007004_CS_4

a v3:CS ;


FP7-287800 SALUS



a v3:IVXB_TS ;




v3:code :INS2007004_CE_4 ;

v3:entry <http://www.srdc.com.tr/ontmalizer/instance#INS2007004_POCD_MT000040.Entry_1> ,

<http://www.srdc.com.tr/ontmalizer/instance#INS2007004_POCD_MT000040.Entry_2> ,

<http://www.srdc.com.tr/ontmalizer/instance#INS2007004_POCD_MT000040.Entry_3> ;

v3:id :INS2007004_II_7 ;

v3:templateId







v3:textContent "Date"^^xsd:string .

:INS2007004_II_13

a v3:II ;


:INS2007004_ST_2

a v3:ST ;

v3:textContent "Problem List"^^xsd:string .




:INS2007004_CE_9

a v3:CE ;






a v3:IVL_PQ ;



:INS2007004_TEL_7

a v3:TEL ;

v3:value "#pastprob1"^^v3:urlDatatype .

<http://www.srdc.com.tr/ontmalizer/instance#INS2007004_StrucDoc.Tbody_3>

a <urn:hl7-org:v3#StrucDoc.Tbody> ;

v3:tr <http://www.srdc.com.tr/ontmalizer/instance#INS2007004_StrucDoc.Tr_8> ,

<http://www.srdc.com.tr/ontmalizer/instance#INS2007004_StrucDoc.Tr_10> ,

<http://www.srdc.com.tr/ontmalizer/instance#INS2007004_StrucDoc.Tr_9> .

:INS2007004_CD_7

a v3:CD ;


:INS2007004_II_14

a v3:II ;

v3:root "93939ef9-05f7-4ad1-83e3-c23917d51d19"^^v3:uidDatatype .

<http://www.srdc.com.tr/ontmalizer/instance#INS2007004_POCD_MT000040.Material_3>

a <urn:hl7-org:v3#POCD_MT000040.Material> ;

v3:code :INS2007004_CE_12 .

FP7-287800 SALUS


<http://www.srdc.com.tr/ontmalizer/instance#INS2007004_POCD_MT000040.AssignedCustodian_1>

a <urn:hl7-org:v3#POCD_MT000040.AssignedCustodian> ;

v3:representedCustodianOrganization

<http://www.srdc.com.tr/ontmalizer/instance#INS2007004_POCD_MT000040.CustodianOrganization_1> .







v3:root "1.3.6.1.4.1.19376.1.5.3.1.4.5"^^v3:uidDatatype .

:INS2007004_CS_5

a v3:CS ;


:INS2007004_CE_12

a v3:CE ;




v3:displayName "Losartan Potassium 50 MG Oral Tablet"^^v3:stDatatype ;










:INS2007004_ClinicalDocument_1

a v3:ClinicalDocument ;

v3:author <http://www.srdc.com.tr/ontmalizer/instance#INS2007004_POCD_MT000040.Author_1> ;

v3:code :INS2007004_CE_1 ;

v3:component <http://www.srdc.com.tr/ontmalizer/instance#INS2007004_POCD_MT000040.Component2_1> ;

v3:confidentialityCode

:INS2007004_CE_2 ;

v3:custodian <http://www.srdc.com.tr/ontmalizer/instance#INS2007004_POCD_MT000040.Custodian_1> ;

v3:effectiveTime :INS2007004_TS_1 ;

v3:id :INS2007004_II_1 ;

v3:languageCode :INS2007004_CS_1 ;

v3:recordTarget <http://www.srdc.com.tr/ontmalizer/instance#INS2007004_POCD_MT000040.RecordTarget_1> ;

v3:templateId


v3:title :INS2007004_ST_1 ;

v3:typeId <http://www.srdc.com.tr/ontmalizer/instance#INS2007004_POCD_MT000040.InfrastructureRoot.typeId_1> .



v3:textContent "Condition"^^xsd:string .




:INS2007004_II_4

a v3:II ;



FP7-287800 SALUS


:INS2007004_Anon_3_1

a v3:Anon_3 ;

v3:textContent "MI"^^xsd:string .

:INS2007004_ED_1

a v3:ED ;







a v3:IVL_PQ ;



:INS2007004_II_15

a v3:II ;

v3:root "a0fff30c-b94e-4eee-b5f5-bf5a79ebb929"^^v3:uidDatatype .















:INS2007004_ED_17

a v3:ED ;


:INS2007004_II_20

a v3:II ;

v3:root "9e4c4be7-0d46-49cf-ba1e-170b5855bb5a"^^v3:uidDatatype .




<http://www.srdc.com.tr/ontmalizer/instance#INS2007004_POCD_MT000040.Patient_1>

a <urn:hl7-org:v3#POCD_MT000040.Patient> ;

v3:administrativeGenderCode

:INS2007004_CE_3 ;

v3:birthTime :INS2007004_TS_2 ;

v3:name :INS2007004_PN_1 .

:INS2007004_CS_6

a v3:CS ;



a v3:IVXB_TS ;


FP7-287800 SALUS


:INS2007004_Anon_2_1

a v3:Anon_2 ;

v3:textContent "Italy"^^xsd:string .







v3:textContent "losartan"^^xsd:string .



v3:ID "med3"^^xsd:ID ;



:INS2007004_TEL_9

a v3:TEL ;


:INS2007004_ED_2

a v3:ED ;


:INS2007004_II_5

a v3:II ;





v3:structuredBody <http://www.srdc.com.tr/ontmalizer/instance#INS2007004_POCD_MT000040.StructuredBody_1> .



v3:textContent "Effective Dates"^^xsd:string .

:INS2007004_TEL_10

a v3:TEL ;


:INS2007004_CD_15

a v3:CD ;

v3:code "C09CA01"^^v3:csDatatype ;



v3:displayName "losartan"^^v3:stDatatype .

:INS2007004_CD_14

a v3:CD ;

v3:code "B01AC06"^^v3:csDatatype ;



v3:displayName "acetylsalicylic acid"^^v3:stDatatype .

<http://www.srdc.com.tr/ontmalizer/instance#INS2007004_POCD_MT000040.Custodian_1>

a <urn:hl7-org:v3#POCD_MT000040.Custodian> ;

v3:assignedCustodian

<http://www.srdc.com.tr/ontmalizer/instance#INS2007004_POCD_MT000040.AssignedCustodian_1> .

:INS2007004_II_16

a v3:II ;

v3:root "2a29b507-3416-4a50-9e6a-9e05fa9f2af0"^^v3:uidDatatype .

FP7-287800 SALUS




v3:tr <http://www.srdc.com.tr/ontmalizer/instance#INS2007004_StrucDoc.Tr_2> ,

<http://www.srdc.com.tr/ontmalizer/instance#INS2007004_StrucDoc.Tr_3> ,

<http://www.srdc.com.tr/ontmalizer/instance#INS2007004_StrucDoc.Tr_4> .

<http://www.srdc.com.tr/ontmalizer/instance#INS2007004_POCD_MT000040.AssignedAuthor_1>

a <urn:hl7-org:v3#POCD_MT000040.AssignedAuthor> ;

v3:assignedAuthoringDevice

<http://www.srdc.com.tr/ontmalizer/instance#INS2007004_POCD_MT000040.AuthoringDevice_1> ;

v3:id :INS2007004_II_4 ;

v3:representedOrganization

<http://www.srdc.com.tr/ontmalizer/instance#INS2007004_POCD_MT000040.Organization_2> .

:INS2007004_CD_9

a v3:CD ;

v3:code "278.00"^^v3:csDatatype ;



v3:displayName "Obesity, unspecified"^^v3:stDatatype ;








:INS2007004_ED_18

a v3:ED ;

v3:textContent "Losartan Potassium 50 MG Oral Tablet"^^xsd:string .









:INS2007004_ED_15

a v3:ED ;


<http://www.srdc.com.tr/ontmalizer/instance#INS2007004_en.family_1>

a <urn:hl7-org:v3#en.family> ;

v3:textContent "Cremona"^^xsd:string .



v3:ID "actprob1_date"^^xsd:ID ;


:INS2007004_CD_4

a v3:CD ;


<http://www.srdc.com.tr/ontmalizer/instance#INS2007004_POCD_MT000040.Consumable_2>

a <urn:hl7-org:v3#POCD_MT000040.Consumable> ;

v3:manufacturedProduct

<http://www.srdc.com.tr/ontmalizer/instance#INS2007004_POCD_MT000040.ManufacturedProduct_2> .


FP7-287800 SALUS




<http://www.srdc.com.tr/ontmalizer/instance#INS2007004_POCD_MT000040.PatientRole_1>

a <urn:hl7-org:v3#POCD_MT000040.PatientRole> ;

v3:addr :INS2007004_AD_1 ;

v3:id :INS2007004_II_2 ;

v3:patient <http://www.srdc.com.tr/ontmalizer/instance#INS2007004_POCD_MT000040.Patient_1> ;

v3:providerOrganization

<http://www.srdc.com.tr/ontmalizer/instance#INS2007004_POCD_MT000040.Organization_1> .

<http://www.srdc.com.tr/ontmalizer/instance#INS2007004_POCD_MT000040.Act_3>

a <urn:hl7-org:v3#POCD_MT000040.Act> ;

v3:classCode "ACT"^^v3:x_ActClassDocumentEntryActDatatype ;

v3:code :INS2007004_CD_7 ;

v3:entryRelationship

<http://www.srdc.com.tr/ontmalizer/instance#INS2007004_POCD_MT000040.EntryRelationship_3> ;

v3:id :INS2007004_II_12 ;

v3:moodCode "EVN"^^v3:x_DocumentActMoodDatatype ;

v3:templateId




v3:text :INS2007004_ED_7 .




<http://www.srdc.com.tr/ontmalizer/instance#INS2007004_POCD_MT000040.Organization_1>

a <urn:hl7-org:v3#POCD_MT000040.Organization> ;

v3:id :INS2007004_II_3 .









:INS2007004_II_17

a v3:II ;

v3:root "3876f056-6ed4-4f77-9e6a-fdee4f88411d"^^v3:uidDatatype .

<http://www.srdc.com.tr/ontmalizer/instance#INS2007004_POCD_MT000040.Observation_2>

a <urn:hl7-org:v3#POCD_MT000040.Observation> ;

v3:classCode "OBS"^^v3:ActClassObservationDatatype ;

v3:code :INS2007004_CD_5 ;

v3:effectiveTime :INS2007004_IVL_TS_2 ;

v3:id :INS2007004_II_11 ;

v3:moodCode "EVN"^^v3:x_ActMoodDocumentObservationDatatype ;


v3:templateId



v3:text :INS2007004_ED_5 ;

v3:value :INS2007004_CD_6 .

<http://www.srdc.com.tr/ontmalizer/instance#INS2007004_StrucDoc.Table_2>

a <urn:hl7-org:v3#StrucDoc.Table> ;

v3:tbody <http://www.srdc.com.tr/ontmalizer/instance#INS2007004_StrucDoc.Tbody_2> ;

v3:thead <http://www.srdc.com.tr/ontmalizer/instance#INS2007004_StrucDoc.Thead_2> .


FP7-287800 SALUS



v3:textContent "Condition"^^xsd:string .




v3:textContent "acetylsalicylic acid"^^xsd:string .


a v3:IVL_TS ;




v3:ID "actprob1_condition"^^xsd:ID ;

v3:textContent "Malignant essential hypertension"^^xsd:string .

:INS2007004_ED_16

a v3:ED ;

v3:textContent "Aspirin 250 MG"^^xsd:string .

:INS2007004_CD_3

a v3:CD ;




v3:displayName "Malignant essential hypertension"^^v3:stDatatype ;












<http://www.srdc.com.tr/ontmalizer/instance#INS2007004_POCD_MT000040.Organization_2>

a <urn:hl7-org:v3#POCD_MT000040.Organization> ;

v3:id :INS2007004_II_5 .






:INS2007004_II_18

a v3:II ;








v3:code :INS2007004_CD_10 ;



v3:id :INS2007004_II_15 ;

FP7-287800 SALUS



v3:templateId




v3:text :INS2007004_ED_10 .




v3:code :INS2007004_CD_8 ;


v3:id :INS2007004_II_13 ;



v3:templateId



v3:text :INS2007004_ED_8 ;














v3:textContent "Effective Dates"^^xsd:string .





:INS2007004_TS_1

a v3:TS ;

v3:value "20130307130000+0200"^^v3:tsDatatype .



v3:code :INS2007004_CE_8 .




v3:code :INS2007004_CD_1 ;



v3:id :INS2007004_II_8 ;


v3:templateId




v3:text :INS2007004_ED_1 .



FP7-287800 SALUS






:INS2007004_ED_13

a v3:ED ;


:INS2007004_II_19

a v3:II ;





:INS2007004_CD_6

a v3:CD ;




v3:displayName "New daily persistent headache"^^v3:stDatatype ;




v3:ID "pastprob1"^^xsd:ID ;



:INS2007004_Anon_5_1

a v3:Anon_5 ;

v3:textContent "Milan"^^xsd:string .




:INS2007004_ED_12

a v3:ED ;

v3:textContent "Acute myocardial infarction"^^xsd:string .

:INS2007004_CS_2

a v3:CS ;


<http://www.srdc.com.tr/ontmalizer/instance#INS2007004_StrucDoc.Text_3>

a <urn:hl7-org:v3#StrucDoc.Text> ;

v3:table <http://www.srdc.com.tr/ontmalizer/instance#INS2007004_StrucDoc.Table_3> .







v3:code :INS2007004_CD_4 ;



v3:id :INS2007004_II_10 ;


v3:templateId


FP7-287800 SALUS




v3:text :INS2007004_ED_4 .



v3:code :INS2007004_CE_10 .




:INS2007004_CD_5

a v3:CD ;





:INS2007004_SC_1

a v3:SC ;

v3:textContent "SALUS LISPA Connector v0.1"^^xsd:string .

:INS2007004_ED_14

a v3:ED ;

v3:textContent "Nifedipine 10 MG"^^xsd:string .




v3:code :INS2007004_CD_2 ;


v3:id :INS2007004_II_9 ;



v3:templateId



v3:text :INS2007004_ED_2 ;












<http://www.srdc.com.tr/ontmalizer/instance#INS2007004_POCD_MT000040.StructuredBody_1>

a <urn:hl7-org:v3#POCD_MT000040.StructuredBody> ;

v3:component <http://www.srdc.com.tr/ontmalizer/instance#INS2007004_POCD_MT000040.Component3_2> ,

<http://www.srdc.com.tr/ontmalizer/instance#INS2007004_POCD_MT000040.Component3_1> ,

<http://www.srdc.com.tr/ontmalizer/instance#INS2007004_POCD_MT000040.Component3_3> .

:INS2007004_CS_1

a v3:CS ;

v3:code "en-US"^^v3:csDatatype .




FP7-287800 SALUS


:INS2007004_II_9

a v3:II ;


<http://www.srdc.com.tr/ontmalizer/instance#INS2007004_POCD_MT000040.EntryRelationship_4>

a <urn:hl7-org:v3#POCD_MT000040.EntryRelationship> ;

v3:observation <http://www.srdc.com.tr/ontmalizer/instance#INS2007004_POCD_MT000040.Observation_4> ;

v3:typeCode "SUBJ"^^v3:x_ActRelationshipEntryRelationshipDatatype .





<http://www.srdc.com.tr/ontmalizer/instance#INS2007004_POCD_MT000040.ManufacturedProduct_3>

a <urn:hl7-org:v3#POCD_MT000040.ManufacturedProduct> ;

v3:classCode "MANU"^^v3:RoleClassManufacturedProductDatatype ;

v3:manufacturedMaterial

<http://www.srdc.com.tr/ontmalizer/instance#INS2007004_POCD_MT000040.Material_3> ;

v3:templateId


<http://www.srdc.com.tr/ontmalizer/instance#INS2007004_POCD_MT000040.InfrastructureRoot.templateId_38> .








a v3:IVL_TS ;





:INS2007004_ED_10

a v3:ED ;





:INS2007004_II_8

a v3:II ;








v3:textContent "Obesity, unspecified"^^xsd:string .






FP7-287800 SALUS






v3:templateId







a v3:IVL_TS ;

v3:high :INS2007004_IVXB_TS_5 ;





:INS2007004_AD_1

a v3:AD ;

v3:city :INS2007004_Anon_5_1 ;

v3:country :INS2007004_Anon_2_1 ;

v3:state :INS2007004_Anon_3_1 ;

v3:use "HP"^^v3:set_PostalAddressUseDatatype .

:INS2007004_CE_1

a v3:CE ;




v3:displayName "Summarization of episode note"^^v3:stDatatype .

:INS2007004_ED_11

a v3:ED ;



a v3:IVXB_TS ;


:INS2007004_PQ_1

a v3:PQ ;

v3:unit "h"^^v3:csDatatype ;


:INS2007004_ED_9

a v3:ED ;

v3:textContent "Obesity, unspecified"^^xsd:string .




:INS2007004_PIVL_TS_2

a v3:PIVL_TS ;

v3:institutionSpecified

"true"^^v3:blDatatype ;

v3:operator "A"^^v3:SetOperatorDatatype ;

v3:period :INS2007004_PQ_2 .





FP7-287800 SALUS



v3:templateId






v3:code :INS2007004_CD_11 ;


v3:id :INS2007004_II_16 ;



v3:templateId



v3:text :INS2007004_ED_11 ;

v3:value :INS2007004_CD_12 .





:INS2007004_PN_1

a v3:PN ;

v3:family <http://www.srdc.com.tr/ontmalizer/instance#INS2007004_en.family_1> ;

v3:given <http://www.srdc.com.tr/ontmalizer/instance#INS2007004_en.given_1> .

:INS2007004_TEL_2

a v3:TEL ;


:INS2007004_CD_2

a v3:CD ;







v3:root "2.16.840.1.113883.10.20.1"^^v3:uidDatatype .


a v3:IVL_TS ;


:INS2007004_CE_2

a v3:CE ;

v3:code "N"^^v3:csDatatype ;

v3:codeSystem "2.16.840.1.113883.5.25"^^v3:uidDatatype .

:INS2007004_TS_2

a v3:TS ;








:INS2007004_ED_8

a v3:ED ;

FP7-287800 SALUS



:INS2007004_PQ_2

a v3:PQ ;

v3:unit "d"^^v3:csDatatype ;



a v3:PIVL_TS ;









:INS2007004_TEL_1

a v3:TEL ;


<http://www.srdc.com.tr/ontmalizer/instance#INS2007004_POCD_MT000040.InfrastructureRoot.typeId_1>

a <urn:hl7-org:v3#POCD_MT000040.InfrastructureRoot.typeId> ;

v3:extension "POCD_HD000040"^^v3:stDatatype ;

v3:root "2.16.840.1.113883.1.3"^^v3:uidDatatype .


a v3:PIVL_TS ;





<http://www.srdc.com.tr/ontmalizer/instance#INS2007004_POCD_MT000040.Author_1>

a <urn:hl7-org:v3#POCD_MT000040.Author> ;

v3:assignedAuthor <http://www.srdc.com.tr/ontmalizer/instance#INS2007004_POCD_MT000040.AssignedAuthor_1> ;

v3:time :INS2007004_TS_3 .





<http://www.srdc.com.tr/ontmalizer/instance#INS2007004_POCD_MT000040.RecordTarget_1>

a <urn:hl7-org:v3#POCD_MT000040.RecordTarget> ;

v3:patientRole <http://www.srdc.com.tr/ontmalizer/instance#INS2007004_POCD_MT000040.PatientRole_1> .

:INS2007004_CD_1

a v3:CD ;





v3:textContent "New daily persistent headache"^^xsd:string .


a v3:IVL_TS ;


:INS2007004_CE_3

a v3:CE ;

v3:code "M"^^v3:csDatatype ;


v3:codeSystemName "AdministrativeGender"^^v3:stDatatype ;

FP7-287800 SALUS


v3:displayName "Male"^^v3:stDatatype .




:INS2007004_TS_3

a v3:TS ;

v3:value "20130307130000+0200"^^v3:tsDatatype .

:INS2007004_ED_7

a v3:ED ;


:INS2007004_ON_1

a v3:ON ;

v3:textContent "Lombardy Region"^^xsd:string .









:INS2007004_PQ_3

a v3:PQ ;

v3:unit "d"^^v3:csDatatype ;


FP7-287800 SALUS


APPENDIX 8 AN EXAMPLE MEDICAL SUMMARY

EXPRESSED IN SALUS CIM ONTOLOGY @prefix foaf: <http://xmlns.com/foaf/0.1/>.

@prefix owl: <http://www.w3.org/2002/07/owl#>.

@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>.

@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#>.


[] a salus:Patient ;

salus:ID

[ a salus:ii ;

salus:extension "547001" ;

salus:root "2.16.840.1.113883.2.9.4.3.2"

] ;

salus:address

[ a salus:addr ;

salus:city "Milan" ;

salus:country "Italy" ;

salus:state "MI"

] ;

salus:condition

[ a salus:Condition ;

salus:problemCode

[ a salus:cd ;

salus:code "339.42" ;



"ICD-9-CM" ;

salus:displayName "New daily persistent headache"

] ;

salus:problemDate

[ a salus:ivlTs ;

salus:low "2009-07-25T00:00:00"^^xsd:dateTime

] ;

salus:problemName "New daily persistent headache" ;

salus:problemType

[ a salus:cd ;

salus:code "55607006" ;



"SNOMED CT" ;

salus:displayName "Problem"

]

] ;

salus:condition


salus:problemCode

[ a salus:cd ;




"ICD-9-CM" ;

salus:displayName "Obesity, unspecified"

] ;

salus:problemDate

[ a salus:ivlTs ;


] ;

salus:problemName "Obesity, unspecified" ;

salus:problemType

[ a salus:cd ;

salus:code "55607006" ;



FP7-287800 SALUS


"SNOMED CT" ;


]

] ;

salus:condition


salus:problemCode

[ a salus:cd ;




"ICD-9-CM" ;

salus:displayName "Malignant essential hypertension"

] ;

salus:problemDate

[ a salus:ivlTs ;


] ;

salus:problemName "Malignant essential hypertension" ;

salus:problemType

[ a salus:cd ;

salus:code "55607006" ;



"SNOMED CT" ;


]

] ;

salus:condition


salus:problemCode

[ a salus:cd ;

salus:code "410" ;



"ICD-9-CM" ;

salus:displayName "Acute myocardial infarction"

] ;

salus:problemDate

[ a salus:ivlTs ;

salus:high "2009-08-01T00:00:00"^^xsd:dateTime ;


] ;

salus:problemName "Acute myocardial infarction" ;

salus:problemType

[ a salus:cd ;

salus:code "55607006" ;



"SNOMED CT" ;


]

] ;

salus:dateOfBirth "1945-02-01"^^xsd:date ;

salus:gender

[ a salus:cd ;

salus:code "M" ;



"AdministrativeGender" ;

salus:displayName "Male"

] ;

salus:medication

[ a salus:Medication ;

salus:administrationTiming

[ a salus:pivlTs ;

salus:operator "A" ;

FP7-287800 SALUS


salus:period

[ a salus:pq ;

salus:unit "h" ;

salus:value "8"

]

] ;

salus:dose

[ a salus:pq ;

salus:unit "mg" ;

salus:value "10"

] ;

salus:indicateMedicationStartStop

[ a salus:ivlTs ;


] ;


[ a salus:MedicationInformation ;


[ a salus:cd ;




"ATC" ;

salus:displayName "nifedipine"

] ;

salus:codedProductName

[ a salus:cd ;

salus:code "316352" ;



"RxNorm" ;

salus:displayName "Nifedipine 10 MG"

] ;

salus:freeTextProductName

"Nifedipine 10 MG"

] ;

salus:route

[ a salus:cd ;

salus:code "PO" ;



"RouteOfAdministration" ;

salus:displayName "Swallow, oral"

]

] ;

salus:medication



[ a salus:pivlTs ;


salus:period

[ a salus:pq ;

salus:unit "d" ;

salus:value "1"

]

] ;

salus:dose

[ a salus:pq ;

salus:unit "mg" ;

salus:value "250"

] ;


[ a salus:ivlTs ;


] ;



FP7-287800 SALUS



[ a salus:cd ;

salus:code "B01AC06" ;



"ATC" ;

salus:displayName "acetylsalicylic acid"

] ;


[ a salus:cd ;




"RxNorm" ;

salus:displayName "Aspirin 250 MG"

] ;


"Aspirin 250 MG"

] ;

salus:route

[ a salus:cd ;

salus:code "PO" ;





]

] ;

salus:medication



[ a salus:pivlTs ;


salus:period

[ a salus:pq ;

salus:unit "d" ;

salus:value "1"

]

] ;

salus:dose

[ a salus:pq ;

salus:unit "mg" ;

salus:value "50"

] ;


[ a salus:ivlTs ;


] ;




[ a salus:cd ;




"ATC" ;

salus:displayName "losartan"

] ;


[ a salus:cd ;




"RxNorm" ;

salus:displayName "Losartan Potassium 50 MG Oral Tablet"

] ;


FP7-287800 SALUS


"Losartan Potassium 50 MG Oral Tablet"

] ;

salus:route

[ a salus:cd ;

salus:code "PO" ;





]

] ;

salus:providerOrganization

[ a salus:OrganizationInformation ;

salus:organizationID

[ a salus:ii ;

salus:extension "65432178901" ;

salus:root "2.16.840.1.113883.2.9.4.3.2.4"

]

] ;

foaf:familyName "Cremona" ;

foaf:givenName "Patient1" .

FP7-287800 SALUS


APPENDIX 9 A TERMINOLOGY REASONING RULE TO

FIND MEDDRA HLGT TERM CORRESPONDENCES OF

SOURCE CODES @prefix iso: <uri:iso.org:9834#> .


@prefix MDR: <http://purl.bioontology.org/ontology/MDR/> .


@prefix skos: <http://www.w3.org/2004/02/skos/core#>.


@prefix salusc: <http://www.salusproject.eu/ontology/core#> .

@prefix : <http://www.salusproject.eu/rule/terminology-reasoning#>.

{

?CONDITION a salus:Condition.

?CONDITION salus:problemCode ?probcode.

?probcode salus:code ?probcode_cd.

?probcode salus:codeSystem ?probcode_cs.

?sConcept a skos:Concept.

?sConcept skos:notation (?probcode_cd ?type)!log:dtlit.

?sConcept skos:inScheme ?sConcept_sch.

?sConcept_sch iso:oid ?probcode_cs.

?tConcept salusc:exactOrNarrowMatch ?sConcept.

?tConcept skos:inScheme ?tConcept_sch.

?tConcept_sch iso:oid "2.16.840.1.113883.6.163".

?tConcept_sch rdfs:label ?targetcode_csn.

?tConcept MDR:level "HLGT".

?tConcept skos:notation ?targetcode_cd.

?tConcept skos:prefLabel ?targetcode_dsn.

}

=>

{

?CONDITION salus:problemCode [

a salus:cd;

salus:code ?targetcode_cd;

salus:codeSystem "2.16.840.1.113883.6.163";

salus:codeSystemName ?targetcode_csn;

salus:displayName ?targetcode_dsn

].

}.

FP7-287800 SALUS


APPENDIX 10 RULE FOR OBTAINING COMMON

CONDITIONS PRIOR TO MEDICATION OF INTEREST # Common Conditions Prior to Medication of Interest

{

:root salusc:patientCount ?PATIENTCOUNT.

?SCOPE e:findall (

((?CONDITION_NAME) (?PERCENTAGE) (?COUNT))

{ ?PATIENT rdf:type salus:Patient.

?PATIENT salus:condition ?CONDITION.

?CONDITION salus:problemCode ?CONDITION_CODE.

?CONDITION_CODE salus:code ?CONDITION_CODE_CODE.

?CONDITION_CODE salus:codeSystem "2.16.840.1.113883.6.163".

?CONDITION_CODE salus:displayName ?CONDITION_NAME.

# count the number of cases with ?CONDITION_CODE_CODE

?SCOPE e:findall (

(?P ?CONDITION_CODE_CODE)

{

?P rdf:type salus:Patient.

(?P %s) :getPivotMedicationDate ?BMDT.

?P salus:condition ?C.

?C salus:problemCode ?CD.

?CD salus:code ?CONDITION_CODE_CODE.

?C salus:problemDate ?CDT.

?CDT salus:low ?CDTV.

(?CDTV ?BMDT) math:difference ?DIFFERENCE.

(?DIFFERENCE 0) pred:numeric-less-than-or-equal true.

}

?LIST

).

?LIST e:distinct ?DISTINCT_CONDITIONS.

?DISTINCT_CONDITIONS math:memberCount ?COUNT.

(?COUNT 0) pred:numeric-greater-than true.

(?PATIENTCOUNT 0) pred:numeric-greater-than true.

((?COUNT ?PATIENTCOUNT)!math:quotient 100) math:product ?PERCENTAGE.

}

?BAG

).

?BAG e:distinct ?SETT.

(((("ccbm"))) ?SETT) list:append ?SET.

} => {

:ccbm salusc:results ?SET.

}.

d4.4.1 salus semantic mediation framework -r1 · pdf file4 ehr data sources ... 5.4.1 athena...

Documents