d5.1.2 subscription based interoperability profiles and ... · “scalable, standard based...

FP7-287800 SALUS

SALUS-FP7-287800• D5.1.2 • Version 1.0, dated January 31, 2014 of 73

SALUS “Scalable, Standard based Interoperability Framework for

Sustainable Proactive Post Market Safety Studies”

SPECIFIC TARGETED RESEARCH PROJECT

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

electronic health records

SALUS D5.1.2 Subscription Based Interoperability Profiles and

Open Source Toolsets –R2

Due Date: January 31, 2014

Actual Submission Date: January 31, 2014

Project Dates: Project Start Date : February 01, 2012

Project End Date : January 31, 2015

Project Duration : 36 months

Deliverable Leader: OFFIS

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


Document History:

Version Date Changes From Review

V0.1 2013-02-01 Initial Document OFFIS

V0.2 2013-12-20 First version OFFIS SRDC

V0.3 2013-12-26 Review Version SRDC OFFIS

V0.4 2014-01-27 Second Version OFFIS All Consortium

V1.0 2014-01-31 Final Version SRDC EU-commission

Contributors (Benef.) Frerk Müller (OFFIS)

Gokce Banu Laleci Erturkmen (SRDC)

Mustafa Yuksel (SRDC)

Gerard Freriks (ERS)

Tobias Krahn (OFFIS)

Marco Eichelberg (OFFIS)

Sara Facchinetti (LISPA)

Responsible Author Frerk Müller Email [email protected]

Beneficiary OFFIS Phone +49-441-9722-146

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 Davide Rovera +3902393311 +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 document describes the Technical Interoperability Layer (TIL) of SALUS. It sets up the

communication layer between external parties and SALUS semantic layer as well as SALUS semantic

layer and EHR systems by using existing standards. This document describes the data to be

exchanged, the profiles developed for communication, the extension of an existing profile to be made

to fulfil SALUS requirements and the Open Source Toolset including the software implemented for

the Technical Interoperability Layer. This deliverable is focusing on subscription based queries. This

is the second version of TIL specification for subscription based communication protocols; the first

version was due to Month 12.

Within the first project year the IHE CM profile extension was developed theoretically and only first

implementation steps could be made. Within the second project year the IHE CM profile and also its

extensions have been implemented. For SALUS project the PCC-9 (Get Care Record Query) and

PCC-10 (Get Care Record Profile Response) transactions were needed. These transactions including

the extensions have been derived from the HL7 messages and implemented to JAVA classes. Next to

web services also message builder and message parser for the transactions have been developed. As

the EHR connector for LISPA system also needs to query directly the database, it was also necessary

to parse and understand the IHE CM profile query and to build the corresponding result sets for

returning them to the Clinical Data Consumer. The implementation of the communication protocol

itself was one of the major goals to achieve during second project year.

FP7-287800 SALUS


TABLE OF CONTENTS

Executive Summary .............................................................................................................................. 4 Table of contents ................................................................................................................................... 5 1 INTRODUCTION ........................................................................................................................ 6

1.1 Purpose .................................................................................................................................... 6 1.2 Reference documents .............................................................................................................. 8 1.3 Abbreviations and Acronyms.................................................................................................. 8

2 Conceptual Design of SUBSCRIPTION based Profiles .......................................................... 10 2.1 Definition of data profiles for querying between SALUS actors .......................................... 11

2.1.1 Query data types............................................................................................................ 12 2.1.1.1 Standard based query definitions for population queries ....................................................................... 12 2.1.1.2 EN13606 query definition ...................................................................................................................... 18

2.1.2 Result data types ........................................................................................................... 23 2.1.2.1 CDA / CCD data definition .................................................................................................................... 24 2.1.2.2 EN13606 archetypes definition .............................................................................................................. 25

3 Communication protocol for connection from SALUS system to external data sources

based on IHE profiles ......................................................................................................................... 28 3.1 Actors .................................................................................................................................... 29 3.2 Transactions .......................................................................................................................... 30

3.2.1 Care Management Data Query [PCC-9] ....................................................................... 30 3.2.2 V3 Care Management Update [PCC-10]: ..................................................................... 34 3.2.3 V2 Care Management Update [PCC-11] ...................................................................... 36

4 Open Source Toolset .................................................................................................................. 37 4.1 Introduction ........................................................................................................................... 37 4.2 Component definition used for subscription to data ............................................................. 38

4.2.1 Technical Interoperability Layer Data Service (TILDS) and Technical Interoperability

Query Source Data Service (TIQSDS) ......................................................................................... 38 4.2.2 Workflow Management ................................................................................................ 38

4.2.2.1 SALUS workflow model ....................................................................................................................... 39 4.2.2.2 Workflow management implementation ................................................................................................ 42

4.2.3 LISPA connector ........................................................................................................... 49 5 Conclusion ................................................................................................................................... 73

FP7-287800 SALUS


1 INTRODUCTION

1.1 Purpose

The goal of the SALUS is to establish an interoperability layer between post market safety analysis

and reporting tools and the underlying EHR systems. There are two kinds of interoperability

challenges we need to address: technical and syntactic interoperability and semantic interoperability.

SALUS workpackage 5 addresses technical and syntactic interoperability challenge, by enabling the

post market safety analysis and reporting tools seamlessly exchange information with the EHR

systems. On the other hand, workpackage 4 addresses the semantic interoperability challenge, i.e.

ensures that the exchanged information can be meaningfully interpreted by the communicating

parties.

When we have analysed the selected SALUS pilot use cases (described in detail in SALUS

Deliverable D8.1.1), we have seen that there is a need for standard based interfaces:

(1) to seamlessly query heterogeneous EHR systems for analysing and detecting possible

ADEs, pre-filling case safety reports and for enabling signal follow-up studies to trace the

safety reports back to the related EHRs

(2) to seamlessly specify the target eligible patient group for enabling set up of continuous

safety studies that screen EHRs

(3) to specify the requested clinical data by intelligent data analysis tools for the selected

group of patients

(4) to transfer the specified de-identified clinical data to the clinical data registries for the

selected patients for safety analysis

A further analysis showed that, two kinds of interactions should be supported between post market

safety analysis and reporting tools and the underlying EHR systems: query based and subscription

based. This deliverable focuses on subscription based communication protocol, while Deliverable

5.2.2 focuses on a query based protocol.

The purpose of the document is to explain which existing standards have been analyzed to perform

the standard based subscription oriented communication between SALUS system and existing EHR

systems as well as between external safety analysis tools and the SALUS system. Next to this it will

be described how the chosen existing standards have been adapted to transport all information needed

to/from SALUS. We have chosen the IHE Care Management (CM) Profile as the basis of this

communication protocol. To address SALUS requirements, this profile had to be adapted to also carry

population based queries which is not supported by IHE CM yet as also EN13606 result sets. To fulfil

this task, the HL7 messages of the PCC-9 and PCC-10 transactions of the IHE CM profile had to be

adapted. This document will show how this was done. Secondly the Open Source Toolset that

implements and extends the IHE CM profile is described.

This document is closely related to D5.2.2. As the subscription based interoperability profiles also the

query based profiles both need to transport SALUS specific queries and EN13606 related content.

This document will refer to D5.2.2 in case of duplicated information to avoid any unnecessary

redundancies within these two documents.

1.2 Achievements in the 2nd release

Whereas the first project year was focusing on the selection of the profile and the changes to be made,

the second project year focused on the implementation, testing and debugging of the profile. Within

the second year, the web services for the transactions, the message generation and parsing as well as

the components connecting the profiles to the EHR system have been integrated to SALUS system.

FP7-287800 SALUS


During implementation also some minor changes of the IHE CMext module have been made. Those

issues have been found during implementation of the profile and were necessary for satisfying the

SALUS use cases. Next to the implementation also the integration and deployment tests to the target

system at LISPA site have been performed. Due to data protection issues the code has been mostly

developed and debugged on developer systems using fake data and afterwards transported to LISPA

system. On LISPA systems the technical crew performed a checkout and tested the implementation

against a given deployment guide. The results have been sent back to the developer to check if the test

results were satisfying. Once the test on the LISPA IT system runs smooth on the fake data, the same

tests have been applied to the real database (including about 16 millions of patients), to figure out if

the system is still stable against big sets of data. A meeting in February 2014 will make the integration

of TIL to SALUS system complete. As the remote testing was satisfying so far, it is expected to have

TIL ready for evaluation during the meeting.

FP7-287800 SALUS


1.3 Reference documents

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

- SALUS Deliverable 5.2.2 - Query Based Interoperability Profiles and Open Source Toolsets -

-R2

- Deliverable 5.1.1 – Subscription Based Interoperability Profiles and Open Source Toolsets –

R1

- SALUS Deliverable 4.1.1 - SALUS Content models for the Functional Interoperability

Profiles for Post Market Safety Studies - R1

- SALUS Description of Work (SALUSPartB_20110118.pdf)

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

Pilot Application

- SALUS D8.2.1: Design of SALUS Pilot Application (LISPA and TUD)

- SALUS Deliverable 3.3.1- Requirement Specification of the SALUS Architecture

- SALUS Deliverable 3.2.1 – Survey of the state of the art

1.4 Abbreviations and Acronyms

Table 1 List of Abbreviations and Acronyms

Abbreviation/

Acronym DEFINITION

ADE Adverse Drug Event

ANT ADE Notification Tool

CCD Continuity of Care Document

CDA Clinical Document Architecture

CEN European committee for standardization

CRFQ Clinical Research Filtered Query

EHR Electronic Health Record

EN13606 Health informatics - Electronic Health Record Communication

HISA Health Information Services Architecture

HL7 Health Level 7

HQMF Health Quality Measurement Format

ICSR Individual Case Safety Report

IHE Integrating the Healthcare Enterprise

IHE CM IHE Care Management profile

IHE QED IHE Query for Existing Data profile

IHE RFD IHE Request Form for Data capture profile

IHE CRD IHE Clinical Research Document profile

IHE DSC IHE Drug Safty Content profile

IPP Initial Patient Population

ISO International Organisation for standardization

OMOP Observational Medical Outcome Partnership

PCC Patient Care Coordination

QRDA Quality Reporting Document Architecture

RDF Resource Description Framework

RIM Reference Information Model

SFM Service Functional Model

SIAMM Semantic Interoperability Artifact Modeling Method

SIL Semantic Interoperability Layer

SNOMED CT Systematized Nomenclature Of MEDicine – Clinical Terms

SPARQL SPARQL Protocol And RDF Query Language

FP7-287800 SALUS


TIL Technical Interoperability Layer

TIQSDS Technical Interoperability Query Source Data Service

TILDS Technical Interoperability Layer Data Service

UMC Uppsala Monitoring Centre

UML Unified Modelling Language

XMI XML Metadata Interchange

XML eXtensible Markup Language

XSD XML Schema Definition

FP7-287800 SALUS


2 CONCEPTUAL DESIGN OF SUBSCRIPTION BASED

PROFILES

This section focuses on the design of a profile to subscribe to data of an existing EHR system for

safety analysis applications. The profile needed is explicitly used for subscribing to data not for

querying data. A subscription does not require a direct feedback. The subscription call leads to an

update result message if and when data is available. Any time during a valid subscription new data

can be sent as an update message. Query and result are exchanged asynchronously. For designing the

subscription based profile this section is divided into two subsections describing the query definition,

results sets and the communication protocol for transportation of the subscription query and the

update results.

As the system should be connected at the end to an existing EHR system which already may follow

the standards used in health care it was decided not to design a new protocol but to follow existing

protocols and extend them if needed. Therefore we have chosen to extend the existing Integrating the

Healthcare Enterprise (IHE) profiles. IHE profiles are not standards themselves but using several

existing standards to fulfil certain tasks. This also includes combination and restriction of standards

within one profile.

Already within SALUS Deliverable 3.2.1, several of the IHE profiles have been analyzed with respect

to the SALUS needs. IHE RFD (Request Form for Data capture), IHE DSC (Drug Safety Content

profile), IHE CRD (Clinical Research Document), IHE QED (Query for Existing Data profile) and

also IHE CM (Care Management) have been analysed. IHE RFD is focusing on transportation of data

with the goal of filling or pre-filling forms. Also the forms itself can be transported by IHE RFD. As

SALUS will have to pre-fill forms for the case safety reports this was analyzed. IHE DSC and IHE

CRD are extensions of this profile, providing conversion guidelines between selected content models.

After examining the use cases described in D8.1.1, it was found that in case of the SALUS

architecture an additional profile will be needed which does not focus on the forms but on the

synchronous and asynchronous queries. Therefore IHE RFD was eliminated from the option list. As

IHE QED enables querying data from a Data Repository synchronously and IHE CM enables

subscribing to data, IHE CM was chosen to perform the subscription.

For SALUS, IHE CM was still needed to be extended to fulfil all features of SALUS. During the state

of the art analysis it was found that there is no profile fulfilling all needs of SALUS. Therefore IHE

CM was chosen as it is an industry led initiative in healthcare domain and only needs slight

adaptations. Basically two major issues have to be addressed. IHE CM is a patient centred profile

which does mean that it is focusing on subscription queries for a single patient. SALUS also needs to

query for population based information not related to a single patient. An example for such a query

may be: “Bring me the de-identified medical summaries of patients got a diagnosis A after taking a

drug B; please keep me informed on updates”. Such a population based query and also the result are

not directly covered by IHE CM profile. We have analysed the HL7 Health Quality Measures Format

(HQMF)1 as an option to express population based queries, and agreed that a subset of HQMF might

be integrated to the extended IHE CM profile to express population based queries. Therefore new

fields had to be added to the IHE CM profile; these extensions will be described in the following

sections as CMext profile. When it comes to results sets, in IHE CM itself, the results of the queries

are shared in terms of HL7 CCD based entry templates. As we will be also subscribing to de-

identified medical summaries of eligible patient populations, we will again aim to use CCD templates.

For addressing the requirements of SALUS pilot applications, in D4.1.2 the required CCD templates

have already been defined, these will be used for representing the result sets of CMext response

1 Representation of the Health Quality Measures Format (eMeasure),

http://www.hl7.org/implement/standards/product_brief.cfm?product_id=97

FP7-287800 SALUS


messages. A brief overview of these content models is presented in Section 2.1, while these templates

are presented in detail in D4.1.2.

In SALUS we do not want to stick only to one standard to carry patient data, such as HL7 CCD based

templates. We would like to also cover a second standard, which is EN13606. The respective

EN13606 based artefacts are already described in D4.1.2, and briefly summarized in D5.1.1. The data

transported by IHE CM EN13606 is represented in an XML structure. This allows easy integration of

EN13606 into the transport process within CM transactions. EN13606 itself does not specify any

transportation or communication layer. It just describes the medical data to be transported. Next to

this EN13606 will also add a subscription query format to the project, which will allow defining a

query for all data needed in EN136062.

Task 5.1 does not only contain definition of an IHE profile but also implementation of the extended

IHE CM profile. Therefore the software developed within this task is integrated to the prototype

tested at LISPA site. This allows the proof that the design is working. Within the prototype the

subscription mechanism based on IHE CM is used to update the OMOP database of SALUS for

enabling statistical safety analysis studies to be conducted by UMC. Once all data has been imported

to the SALUS semantic layer all updates will be pushed by using IHE CMext. These updates will be

performed once a month and lead to a huge amount of new data to proof the profile implementation is

working as expected.

This section describes the structure of the data to be communicated between Data Consumer and Data

Repository. These communication partners are the source and the destination of data to be subscribed

to. In SALUS architecture EHR Systems act as Data Repositories, while safety analysis tools act as a

Data Consumer. The Data Repository delivers data queried by the Data Consumer. The following

subsections describe the structure of the queries in the different standards used within SALUS and

also the structure of the data returned. The message templates to be exchange are described more in

detail in D4.1.2.

2.1 Definition of data profiles for querying between SALUS actors

This section focuses on the data to be passed between the Data Consumer and the Data Repository. It

defines both the query format and also the result format. As IHE CM was chosen most of the patient

specific queries needed can be already performed. This section explains the extension which has been

developed. The first extension required is to represent population based queries as inclusion and

exclusion criteria in HL7 HQMF format, and also to be able to pass queries represented in EN13606

query format. In this section we also briefly describe the content models that we will use to transfer

the medical data sets that will be shared as a result of subscriptions. In SALUS Deliverable 4.1.1, two

different content models have been defined for representing result sets: through HL7 CCD templates

(as used by the IHE CM profile), and through EN13606 templates. These will be passed as a part of

the message payloads within the extended IHE CM profile while the updates for a previous

subscription are being shared.

2 It should be noted that HQMF is designed for collecting statistics as quality measures from the

selected population. As a response set, Quality Reporting Document Architecture (QRDA) documents

are collected. In SALUS on the other hand we would like to collect de-identified medical summaries

of the selected population to be analyzed further by post market safety analysis tools, rather than

already calculated eMeasures. Hence, for the time being, we will stick with HL7 CCD based

templates and 13606 EHR-Extract templates as the query results.

FP7-287800 SALUS


2.1.1 Query data types

This section discusses the queries in detail which are not already covered by IHE CM. This section

will discuss how queries might be represented in HL7 HQMF and also EN13606.

2.1.1.1 Standard based query definitions for population queries

In SALUS we need to enable querying both patient based (for ICSR Reporting cases and case series

characterization pilots) and also population based queries (for ADE notification, temporal pattern

characterization and temporal association screening and observational cohort studies).

In IHE QED Profile it is possible to specify patient based queries through the <queryByParameter>

element within the control act wrapper QUQI_MT020001UV01 that will be exchanged within a

“Query Care Record Event Profile Query” trigger event in IHE-PCC-1 Query Existing Data

Transaction. Similarly in IHE CM Profile it is possible to use the <queryByParameter> element

within the same control act wrapper that will be exchanged within a “Get Care Record Profile Query”

trigger event in IHE-PCC-9 Care Management Data Query Transaction.

A number of pre-defined query parameters are allowed within the <queryByParameter> as presented

in section 3.2.1 on page 30. Among these the following parameters allow defining patient based

queries:

patientAdministrativeGender

patientBirthtime

patientId

patientName

In IHE CM specifications, it has been presented that for population based queries, the extension

attribute of the value element of the patientID parameter shall be set to “*”. However currently it is

not possible to specify inclusion/exclusion criteria for selecting a population through the

<queryByParameter> element.

On the other hand, there are two separate ongoing efforts in HL7 that presents possible ways to

specify population criteria, namely HL7 Study Design Message and HL7 HQMF specification. In the

following subsections these will be briefly introduced.

Defining Population Criteria within a HL7 Study Design Message

Within a Study Design Message, a population criteria definition is used to represent the target

population that is of interest to the planned clinical study. A population criteria definition is

associated with the <plannedStudy> element in a StudyDesign Message through the

Precondition act relationship. Eligibility Criteria can be represented as a complex hierarchy of

EligibilityCriterion class. These criteria can be logically conjuncted through the use of

<conjunctionCode> element within <precondition> element. The type of the logical

conjunction can be set through the “code” attribute of <conjunctionCode> element, which can

be and, or, exlusive-or. The sets of "AND", "OR", and "XOR" criteria are in turn combined

by a logical "AND" operator (all "AND" criteria and at least one "OR" criterion and exactly

one "XOR" criterion). To overcome this ordering, criteria can be nested as necessary by

adding recursive <precondition> act relationship attached to the EligibilityCriterion class.

Each single EligibilityCrierionClass can be through as a “Query by example” expression

defined over an HL7 Observation Class in RIM. It is possible to present constrains on:

o code: To set the type of the Eligibility Criteria (e.g. age, sex)

FP7-287800 SALUS


o value: Computable range or value of the eligibility criteria

o effectiveTime: How long the criteria need to be true. e.g. disease must exist for 6

months.

o negationInd: Optional. Used to explain a negative (or exclusion) criteria

Figure 1 Population Criteria in an HL7 Study Design Message

An example Eligibility Criteria is presented in Figure 1. Please note that the use of “code” and

“value” elements within an eligibityCriterion class is not standardized yet. In the

Implementation Guide for Study Design (Release 1 May 2011), the code element is used to

identify whether the criterion is an inclusion or exclusion criterion, while the value element is

used to represent the eligibility condition in a textual way. It is also mentioned that ASPIRE

(Agreement on Standardized Protocol Inclusion Requirements for Eligibility)3 coded set of

eligibility criteria is aimed to be used. In the example below (Figure 2), we have used the

code element to specify the observation on which we are putting restrictions by specifying the

“Condition” code from SNOMED CT, and used the value element to represent the type of

“Condition” that is sought for inclusion or exclusion in a coded way. It should be noted that

through this representation it is not possible to define complex criteria for example on Drug

Exposure attributes (like route code, dose quantity) as the Criterion is defined only on

Observation Acts.

<precondition typeCode="PRCN">

<conjunctionCode code=“AND"/>

<eligibilityCriterion classCode="OBS" moodCode="CRT">

<id extension="INCL01"/>

<text>Has diabetes</text>

<code code=“64572001" codeSystem="2.16.840.1.113883.6.96" displayName=“Condition"/>

<value xsi:type='CD' code=' ' codeSystem=' 2.16.840.1.113883.6.96' displayName=‘Diabetes '>

</eligibilityCriterion>

</precondition>

<precondition typeCode=“PRCN” >

<conjunctionCode code=“OR"/>



<text>STEMI</text>


<value xsi:type='CD' code=‘401303003 ' codeSystem=' 2.16.840.1.113883.6.96' displayName=‘Acute ST

segment elevation myocardial infarction (disorder) '>


</precondition>


3 ASPIRE (Agreement on Standardized Protocol Inclusion Requirements for Eligibility) Data Set is available in

Clinical Research Filtered Query (CRFQ) Service Functional Model (SFM) Specifications- Version 1.0

November 25, 2007 – pp.20-28

FP7-287800 SALUS





<text>NSTEMI</text>


<value xsi:type='CD' code='401314000 ' codeSystem=' 2.16.840.1.113883.6.96' displayName=‘Acute

non-ST segment elevation myocardial infarction (disorder)'>


</precondition>





<text>Unstable Angina</text>


<value xsi:type='CD' code=59021001' codeSystem=' 2.16.840.1.113883.6.96' displayName=‘Angina at

Rest'>


</precondition>

Figure 2: An example Eligibility Criteria definition within a Study Design message (Patients with

Diabetes and having one of the following conditions {STEMI, NSTEMI, Unstable Angina}

Defining Population Criteria within a HL7 HQMF Document

The Health Quality Measures Format (HQMF) is a standard for representing a health quality measure

as an electronic document. As defined by HQMF specifications4: “A quality measure is a quantitative

tool that provides an indication of an individual or organization’s performance in relation to a

specified process or outcome via the measurement of an action, process or outcome of clinical care”.

HQMF defines a standardized document structure (as depicted in Figure 3) listing the sections to be

included to present measure specific definitions (e.g. data criteria, numerator, initial patient

population) and a header part to present metadata (e.g. author, verifier).

4 Health Quality Measures Format: Representation of the Health Quality Measures Format (eMeasure), Release

2, Draft Standard for Trial Use, V3_HQMF_DSTUR2_U1_2012SEP, July 2012

FP7-287800 SALUS


Figure 3 HL7 HQMF Document Structure5

As presented, the main objective of this document specification is to define healthcare e-measures,

which is not directly related with SALUS project; however within the Data Criteria Section and

Population Criteria Section a patient population definition including inclusion/exclusion criteria can

be defined. This subset of HQMF document can be used in SALUS to represent eligibility criteria

declaratively.

In the Data Criteria section, a set of data criteria is defined to identify the various constraints and

filters that can be applied on patient data to identify populations. For example, a data criterion can be

written to “Identify people with Myocardial Infarction”, or “Identify people who has been

administered Nifedipine recently”.

Different from the approach in Eligibility Criterion specification in HL7 Study Design Message,

where criterions are only defined on HL7 Observation Acts, here it is possible to define the data

criteria on the following clinical data elements:

Patient Demographics

Encounters

Medications

Lab Results

Vital Signs

Problems

Procedures

Allergies

Immunizations



FP7-287800 SALUS


In the recent HQMF specifications6 the attributes of each Act Criterion (like ObservationCritera.

SubstanceAdministrationCritera, SupplyCriteria, etc.) can be used as query parameters and are

presented in detail.

These criterion definitions are analogous to a "query by example": When an Act Criterion is defined

as an example Act definition by filling a number of possible attributes, this Act definition in fact

represents query parameters. The filled attributes will be checked if they match the Act definitions

within an EHR document, and if there is a match, then this particular EHR can be considered to be

satisfying the query parameters.

In addition to this, HQMF specifications also specify a number of predefined Act Relationships

between Act Criteria, like “temporallyRelatedInformation” and “excerpt”. The “excerpt” relationship

allows selecting one of a set of similar acts to be considered in a criterion, e.g., the first, last, or most

recent act of a series of similar acts. The “temporallyRelatedInformation” relationship allows two acts

to be related by when they occur with respect to each other. Code sets to identify the subtypes of these

relationships are also provided. For example SAE (starts after end of) and SAS (starts after start of)

are two of the typeCodes provided for “temporallyRelatedInformation” relationship. Through these

constructs it is possible to set complex data criterion definitions.

Population Criteria identifies a population by grouping one or more Data Criteria elements. It is

possible to use logical expressions like AND/OR/XOR to group several data criteria. HQMF

specifications define number of different type of population query that can be used differently in the

context of a query. These are: “Initial Patient Population”, “Denominators”, “Numerators”,

“Exceptions”, and “Exclusions”. The following diagram (taken from HQMF Specifications) shows

the relationships between the populations pictorially.

Figure 4 Population Criteria Illustration

• Initial Patient Population (IPP): IPP can be thought of as the population relevant to the query.

– For example: All patients between the age of 18 and 85.

• Denominator: Denominator can be thought of as a subset of the IPP based on specific criteria.

– For e.g. All patients between the age of 18 and 85 having the problem of Diabetes

• Numerator: Numerator can be thought of as a subset of the Denominator based on more

granular or specific criteria.

– For example: All patients between the age of 18 and 85 having the problem of

Diabetes and has recently used Nifedipine.



FP7-287800 SALUS


• Exclusions or Exceptions: Exclusions identify a subset of the population that needs to be

removed from the Denominator based on specific criteria.

In Figure 5, an example Population Criteria (Patients who have experienced acidosis as an adverse

event after the use of Vancomycin medication) is presented where the predefined Data Criterion are

referred.

<QualityMeasureDocument>

…

<component>

<measureDescriptionSection>

<title> Sample Measure </title>

<text>This is a description of the measure.</text>

</measureDescriptionSection>

</component>

<component>

<dataCriteriaSection>

<entry>

<localVariableName>VancomycinMedication</localVariableName>

<substanceAdministrationCriteria moodCode="EVN">

<id root="0" extension="VancomycinMedication"/>

<participation typeCode="CSM">

<role classCode="MANU">

<playingMaterial classCode="MMAT" determinerCode="KIND">

<code code=’21600611' codeSystem='2.16.840.1.113883.6.73' codeSystemName='ATC'>

</code>

</ playingMaterial >

</role>

</ participation >

<temporallyRelatedInformation typeCode="SAS">

<ObservationReference>

<id root="0" extension="AcidosisEvent”/>

</ObservationReference>

</temporallyRelatedInformation>

</substanceAdministrationCriteria>

</entry>

<entry>

<localVariableName> AcidosisEvent </localVariableName>

<observationCriteria>

<id root="0" extension=" AcidosisEvent "/>

<statusCode code="completed"/>

<value xsi:type="CD" code="10000486" codeSystem=' 2.16.840.1.113883.6.163' codeSystemName='MedDRA'/>

</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=" AcidosisEvent “/>

</observationReference>

</precondition>

<precondition>

FP7-287800 SALUS


< substanceAdministrationReference moodCode="EVN">

<id root="0" extension=" VancomycinMedication “/>

</ substanceAdministrationReference >

</precondition>

</allTrue>

</precondition>

</patientPopulationCriteria>

</entry>

</populationCriteriaSection>

</component>

……

</QualityMeasureDocument>

Figure 5 An example Eligibility Criteria definition through HQMF Constructs

2.1.1.2 EN13606 query definition

Queries in the CEN/ISO 13606 context

For queries to be functional in the context of the CEN/ISO 13606 and associated archetypes several

layers need to be in place:

Definition of the query using the archetype mechanism

Translation of this archetype based query content to the query language in the target system

Transport of the query to the target system

Transport of the query result to the requesting system

Conversion of the format of the query result to the archetype based 13606 format

The CEN/ISO 13606 EHRcom standard is a communication standard to transport in an EHR-Extract

data and information between two or more EHR-systems. The 13606 standard is not a specification

that defines queries explicitly. As part of the EHR-Extract specification it is possible to include the

query that gave rise to the EHR-Extract.

EN13606 archetypes define with all semantic details that what can be documented about any topic. In

particular ENTRY, CLUSTER and ELEMENT classes contain the full semantics. The

EHR_EXTRACT, COMPOSITION and SECTION classes define the structure of documents/screens,

etc. The structural classes are supposed not to contain clinical fact defining semantics.

ERS and the EN13606 Association are in process of rethinking the way in which archetypes are

produced, specified and used. The present draft specification (Semantic Interoperability Artifact

Modeling Method, SIAMM) defines standardized patterns to construct artifacts such as 13606

archetypes. SIAMM is targeted to become part of the new 13606 part 3 specification during the

renewal of the CEN/ISO 13606 EHRcom standard. During 2013 and 2014 the renewal will take place.

At the same time 13606 and other CEN/ISO standards will be harmonized:

CEN/ISO 13940 System of Concepts for Continuity of Care (ContSys) and CEN/ISO 12967 Health

Information Services Architecture (HISA).

The purpose of this section is to explain how the Semantic Interoperability Modeling Method

(SIAMM ) can be used to define queries. Most experience so far was obtained to define screen and

report templates using specially designed archetype for that context.

In the course of time it became clear that a more fundamental method was needed to produce

archetypes that can be used in full semantic interoperability.

Archetypes can and will be used for many purposes:

- persistence

FP7-287800 SALUS


- querying

- presentation

- data capture

- input/exchange

- output/exchange

This chapter specifies how the archetype can be used for the expression of a query and collection of

the result(s).

Semantic Interoperability Modeling Method

Because there were too many degrees of freedom possible it was decided to develop one method for

the design of these artefacts. One generic pattern was designed that specifies:

- Meta data about the file the artefact is specified in

- Meta data about the artefact

- What as the topic that is modeled in the artefact

- Results that specify what is recorded about the topic as result

- Context matters around the What/Result pair

- Localisation in the Patient System

- Localisation in Space

- Localisation in Time

- Why the data is recorded about the topic

- Who are involved in the topic?

- How the results were obtained; environmental factors that influence the interpretation of the

result.

The nodes of the artefact are labelled with the CIMI notation that specifies the Name of the node in

the colour purple, whether if it is Slot specification referencing another artefact in the color green, the

constraints in the colour green and the type of the Class that is constrained in the color blue.

FP7-287800 SALUS


SIAMM: Generic Pattern

The picture above shows the framework of the generic pattern. Using slots the branches are defined.

Observe that at the bottom the SCP slot is located.

SCP is a slot that can appear in any place with the function of attaching to the node above modifiers

such as: Status, Certainty and Presence. The latter is a specification that other name as Negation.

Observe that all ENTRY archetypes will have the same structural nodes. The specialisation of these

artefacts is performed by changing the data field in one or more leaf nodes (ELEMENTS). All

defining elements are coded via the ELEMENT classes; the nodes provide to a degree the semantic

context of the topic.

The ENTRY archetype defines how data is persisted and exchanged. ENTRY Archetypes will be used

for queries.

SIAMM: Meta Artefact

This branch specifies meta data about the artefact.

FP7-287800 SALUS


The MetaDataArtefact subarchetype specifies:

Name Use

TargetReferenceModel Specifies is the Reference Model (RM) that is used.

TargetReferenceModelClass Specifies the class in the (RM) that is the starting point

for this artefact. In SIAMM this will be an ENTRY class.

TargetReferenceModelClassType Specifies the specialised name of the entry class.

TargetReferenceModelClassName Specifies the ContSys concept that describes this artefact

.

ProcessPattern

Specifies the specific pattern that is needed to express the

topic for: ordering, execution, assessment, and result

collection (summary) of a process. Plus it can specify an

inference. Processes are modeled in ENTRY classes.

ProcessContext Specifies the context in which the artefact is used:

Diagnostic, Therapeutic, Administrative, Management or

Research.

ArtefactUse Specifies for what purpose the artefact was designed:

Persistence, Querying, Input/Exchange,

Output/Exchange, Presentation, Data Capture.

SIAMM: What/Result

FP7-287800 SALUS


The “What” is specified using the NamedObject sub-pattern that is re-used in several places. The

ResultValues sub-pattern specifies the possible ways in which results can be defined.

Complex structures that specify characteristics of any Non Living Named Object can be inserted

when needed via a SLOT in the NonLivingObjectCharacteristics. E.g. the characteristics of me-

dicinal products described.

SIAMM: Context

The context around the data point as defined by the NamedObject and ResultValues is cap-tured via:

- ContextLocalisationInatientSystem: codes for what part of the Patient System is affected.

- ContextLocalisationInSpace: Allows coding the location in absolute and relative terms.

- ContextLocalisationInTime: Allows to code for a point in time or a period in absolute and

relative terms.

- ContextWhy: Allows to code for semantic links to other stored data.

- ContextWho: Allows to code for who/what is participating.

- ContextHow: Allows to code for environmental factors in the patient system that are

important and can influence the interpretation of the result.

SIAMM: Query Rules:

Introduction

ENTRY archetypes are used to persist, query data in an EHR or EHR-extract. In addition archetypes

are used in Templates to define the content of a screen, or report or EHR-extract, or collect data

during data capture.

Since each archetype is derived from one generic archetype and since specialization takes place via

data fields associated with ELEMENTS, these data fields will be used for the expression of query but

also serve as receptacle for the queried data.

Data fields associated with ELEMENTS are defined using the Data Types. Most Data Types allow the

expression of constraints for numbers and times. In addition the SemanticOrdinal allows defining

constraints via the Inclusion and Exclusion options.

FP7-287800 SALUS


The MetaArtefact branch ArtefactUse allows to code for the purpose the artefact was designed and

will be used. Depending on the choice predefined rules become effective.

This feature is essential because there are subtle differences between the same artefact used to send

data or receive data, present data or capture data, to query data or collect queried data.

SIAMM: Rules for specification of Query

The following rules apply for querying:

- MetaDataArtefact: ArtefactUse must be set to ‘Querying’

- Any ELEMENT node that is not needed to express the query or receive queried data must be

removed.

- Any ELEMENT node that is empty indicates that this is the result of the query.

- Any ELEMENT node that is not-empty specifies a constraint that is logically added to other

constraints

- All ELEMENT nodes via the Data Types can place detailed constraints, such as: number

ranges, ranges of time. (see below)

SIAMM: Rules for specification of Query Results

The following rules apply for collecting the results of a query:

- MetaDataArtefact: ArtefactUse must be set to ‘Querying’.

- Any ELEMENT node that is not needed to express the result of query must be removed.

- Any ELEMENT node that is empty indicates that this queried and will hold the result of the

query.

2.1.2 Result data types

The result data types define how the results will be presented to the Data Consumer. In fact IHE CM

(in PCC-10 message payload) and QED (in PCC-1 Query Response message payload) already use

CCD based entry templates to describe data. In SALUS Deliverable 4.1.1, we have already defined a

number of Entry-level templates by also indicating the possible sections in which they can be carried

in an EHR document. These templates can be used as they are to carry result data sets in QED and

CM transactions. However as we will be extending IHE CM profile in order to represent population-

based queries through HQMF, another option to carry resulting datasets could be the HL7 Quality

Reporting Document Architecture (QRDA)7 document templates. Within the two project years this

IHE CMext profile has been developed we figured out that all data requested from the EHR could be

represented in the entry level templates so the result data set needed no adaption for carrying also

QRDA results. The entry level templates identified are described in D4.1.2 more in detail.

In addition to this, as expressed in Section 2, in SALUS project we also aim to carry resulting patient

data through ISO EN 13606 EHR Extract sections. EN13606 templates are also described in depth in

D4.1.2.

Within the following subsections, short information about these possible result sets is given, for

details the readers are invited to check SALUS Deliverable 4.1.1.

7 http://wiki.hl7.org/index.php?title=Quality_Reporting_Document_Architecture

FP7-287800 SALUS


2.1.2.1 CDA / CCD data definition

In SALUS Deliverable 8.1.1, the data requirements of the selected SALUS use cases have been

defined verbally. In D4.1.2, Entry Level CDA content modules (templates) that can carry the

information required in the SALUS Pilot application scenarios are presented. The specifications of the

Entry Level content modules are based on the IHE Patient Care Coordination (PCC) templates, and

ASTM/HL7 Continuity of Care Document (CCD) templates. When necessary these templates are

extended by adding new restrictions in conformance to HL7 CDA RMIM, to be able to represent

additional data items that are required by SALUS Pilot applications. For each Entry Level content

module, the sections that can include the respective content module are also presented by providing

references to Template IDs.

In particular the following Entry Level templates are defined to represent subsets of medical

summaries:

Conditions within a Past Medical History Section or Active Problems Section

Lab Observations to represent Lab Results in a Codes Results Section

Vital Signs observations in a Coded Vital Signs Section

Procedures within a Procedures and Interventions Section or Coded List of Surgeries Section

or Coded Hospital Studies Summary Section

Allergies and Intolerances within a Allergies and Other Adverse Reactions Section

Medications listed in Medications Section or Medications on Admission or Medications

Administered Section or Hospital Discharge Medications

Encounters listed within an encounters Section

Family History Observations within a Coded Family History Section

Social History Observations within a Coded Social History Section

Pregnancy Observations within a Pregnancy History Section

List of Immunizations

Demographics information recorded in the Clinical Document Header

These Entry Level templates will be exchanged within the payloads of the PCC-10 transaction

extension in Section 3.2.2.

<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="a0fff30c-b94e-4eee-b5f5-bf5a79ebb929"/>

<code nullFlavor="NA"/>

<text>

<reference value="#pastprob1"/>

</text>

<entryRelationship typeCode="SUBJ">

<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="2a29b507-3416-4a50-9e6a-9e05fa9f2af0"/>

<code code="55607006" displayName="Problem" codeSystem="2.16.840.1.113883.6.96"

codeSystemName="SNOMED CT"/>

<text>

<reference value="#pastprob1_condition"/>

</text>


<effectiveTime>

<low value="20090401"/>

<high value="20090401"/>

</effectiveTime>

<value xsi:type="CD" code="410.0" displayName="Acute myocardial infarction, of anterolateral wall"

codeSystem="2.16.840.1.113883.6.2" codeSystemName="ICD-9-CM">

<originalText>Acute myocardial infarction, of anterolateral wall</originalText>

FP7-287800 SALUS


</value>

</observation>

</entryRelationship>

</act>

Figure 6: A CDA Snippet conforming to Entry Level templates defined in D4.1.2 for representing an

Active Problem

<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-170b5855bb5a"/>

<text>

<reference value="#med1"/>

</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" codeSystem="2.16.840.1.113883.6.96"


<doseQuantity value="5" unit="mL"/>

<maxDoseQuantity>

<numerator value="5" unit="mL"/>

<denominator value="10" unit="mL"/>

</maxDoseQuantity>

<administrationUnitCode code="415215001" displayName="Puff" codeSystem="2.16.840.1.113883.6.96"


<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="245314" codeSystem="2.16.840.1.113883.6.88" codeSystemName="RxNorm" displayName="Albuterol

1 MG/ML Inhalant Solution">

<originalText>Albuterol 1 MG/ML Inhalant Solution</originalText>

<translation code="795354" displayName="Albuterol 1 MG/ML Inhalant Solution [Ventolin]"

codeSystem="2.16.840.1.113883.6.88" codeSystemName="RxNorm"/>

<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>

</substanceAdministration>

Figure 7: A CDA Snippet conforming to Entry Level templates defined in D4.1.2 for representing an

Medication

2.1.2.2 EN13606 archetypes definition

In Deliverable 4.1.1, first of all, SALUS specialized 13606 artifacts have been designed to represent

basic building blocks of the medical data sets that needs to be shared within the scope of SALUS pilot

use cases, such as Diagnosis, Medications, Allergies, Lab Tests and so on. On top of this archetype

library, the high level 13606 SALUS Template is defined in detail in its ADL1.4 computer

FP7-287800 SALUS


processable formalism via the CESIL tool.

A mind map that reflects its generic structure is provided.

This depicts the general structure. At the leaf nodes complex cluster models fill the archetype slots.

An example of a concrete instantiation of an EN13606 instance can be seen below:

FP7-287800 SALUS


Figure 8: A derived example of an instantiation in EN13606.

XML representations of the medical data sets instantiating this template will be exchanged within the

payloads of the PCC-10 transaction extension in Section 3.2.2.

FP7-287800 SALUS


3 COMMUNICATION PROTOCOL FOR CONNECTION

FROM SALUS SYSTEM TO EXTERNAL DATA SOURCES

BASED ON IHE PROFILES

In this section, first of all a brief overview of the original IHE CM profile is presented, afterwards the

extensions we envision on top of IHE CM profile is described in detail.

To manage care specific data it is necessary to exchange data between applications and Health IT

systems. For this purpose the IHE Care Management profile (CM) was specified. Examples for Care

Management system can be Cancer Registries or Chronic Disease Management Systems.

By collecting data from several health care IT systems such applications can improve health

management and therefore reduce health care cost substantially. There are more and more special

purpose care management systems available to manage the care of a patient especially for chronic

diseases such as diabetes or cancer.

Within the health care domain often guidelines are developed to define how to treat a certain disease

and to take care of the patient. Therefore often evidence-based decision support systems are used. In

most cases a lot of systems are involved to gather all information needed as these are typically

distributed to the clinical infrastructure. The Care Management Profile defines how actors

communicate to each other to handle the information needed to treat a patient by following a specific

guideline.

Figure 9: Care Management actor diagram

Figure 9 gives a brief overview about the Care Management (IHE CM) profile. The Guideline

Manager is responsible for managing guideline used to create care plan and to communicate these

guidelines to Care Managers. The Care Manager manages the care of the patient and health status

related data. A Care Manager can be designed to manage a single condition, such as the management

of cardiac diseases, or may be designed as general purpose system. It is capable of querying data from

a Clinical Data Source. Therefore this system is able to collect data from several systems related to a

certain condition defined within a guideline.

To get a better impression on how the Care Management profile works, a process flow (see Figure 10)

as presented within IHE CM profile specification can be examined.

FP7-287800 SALUS


Figure 10: Process flow for IHE Care Management profile

The steps taken in this process flow are explained top-down and copied from IHE CM profile

specification.8

1. A guideline is defined and activated in the Guideline Manager. The set of data variables are

communicated in electronic format to the Care Manager.

2. The Care Manager sends a query for the clinical data identified by the guideline to Clinical

Data Source 1 and Clinical Data Source 2.

3. Clinical Data Source 1 is configured out of band to respond appropriately to the query

identified by the Guideline Manager.

4. Clinical Data Source 2 queries the Care Manager for the guideline identified in the query,

and configures itself to respond appropriately based on the data variables identified in the

guideline.

5. Upon updating applicable patient data, Clinical Data Source 1 sends an HL7 V2 message

specified by the guideline to the Care Manager.

6. Upon updating applicable patient data, Clinical Data Source 2 sends an HL7 V3 Care Record

Update to the Care Manager, based on the configuration computed in step 4.

3.1 Actors

Within Figure 9 three actors have been defined. These are Guideline Manager, Care Manager and

Clinical Data Source. These actors will be described more in detail within the following.

Guideline Manager: By using the Request for Guideline Data transaction [PCC-8] the Guideline

Manager requests information about guidelines. If a guideline was updated or a new guideline is

8 IHE Care Management (CM) profile specification:

http://www.ihe.net/Technical_Framework/upload/IHE_PCC_Care_Management_CM_Supplement_TI_2008-

08-22.pdf

http://www.ihe.net/Technical_Framework/upload/IHE_PCC_Care_Management_CM_Supplement_TI_2008-08-22.pdf

http://www.ihe.net/Technical_Framework/upload/IHE_PCC_Care_Management_CM_Supplement_TI_2008-08-22.pdf

FP7-287800 SALUS


available it informs the Care Manager by using the Guideline Notification [PCC-7] to trigger a data

update.

Care Manger: The Care Manager receives Guideline Notifications [PCC-7] analysis them and

queries information to be gathered from one or more Data Sources by using Care Management Data

Query transaction [PCC-9]. For data exchange between Care Manager and Clinical Data Source HL7

V2 and HL7 V3 messages can be used. The Care Manager has to implement both standards.

Clinical Data Source: The Clinical Data Source transmits information queried by Care Management

Data Query transaction [PCC-9] to the Care Manager by using ether V3 Care Management Update

[PCC-10] or V2 Care Management Update transaction [PCC-11]. It is left to the Clinical Data Source

which kind of HL7 version to use. Therefore only HL7 V2 or HL7 V3 has to be implemented.

3.2 Transactions

Within Figure 9, five transactions have been defined. These are Request Guideline Data, Guideline

Notification, Care Management Data Query, V3 Care Management Update and V2 Care Management

Update.

Among these in particular the Care Management Data Query, V3 Care Management Update

transactions will be utilized in SALUS Project to collect medical summaries of eligible patients in a

subscription based manner. These transactions will be described more in detail within the following,

the rest will be skipped.

As the scope of this task is to subscribe to clinical data which might be not patient centered or HL7

based, this profile has to be adapted to fulfill the SALUS needs. Therefore some of the transactions

have been extended to transport all of the SALUS data packages needed. The goal is to keep the IHE

CM profile 100% backwards compatible so every actor fulfilling IHE CMext will automatically

support IHE CM. The transactions and the necessary modifications will be described within the

following.

3.2.1 Care Management Data Query [PCC-9]

This transaction is supposed to be used to query health status or patient care related data. It can collect

this information from more than one system which may have it. This transaction is marked as

required. The transaction itself is an extended version of the “Get Care Record Profile Query”

transaction defined in the Query for Existing Data (QED) profile. The Query Care Record Event

Profile Query corresponds to the HL7 Interaction QUPC_IN043100UV and contains the Transmission

Act Wrapper (MCCI_MT000100UV01), the Control Act Wrapper (QUQI_MT020001UV01) and the

message payload itself (QUPC_MT040100UV). These modules and there modifications will be

described within the following.

An example of the Transmission Wrapper can be found below. All colored lines are remaining to be

explicitly affected by the IHE CM profile. Furthermore the green marked lines will have to be adapted

for the IHE CMext profile. It may be necessary to introduce a new HL7 message called “Get Care

Record Profile Query extension” which will lead to a new “QUPC_IN043100UVext” name which has

to be changed within the Transmission Wrapper. The transmission wrapper to be adapted is the based

on the HL7 message “MCCI_MT000100UV01”.

Within validation schema of the “MCCI_MT000100UV01” HL7 message it is shown that this

message will be not affected by the changes made for the IHE CMext profile

(“QUPC_IN043100UVext”). Therefore the Transmission Wrapper will be not described in more

detail. To distinguish clearly between these two messages: “QUPC_IN043100UV” describes the

usage of the Transmission Wrapper and the Control Act Wrapper. This needs adaption within the

Transmission Wrapper part as the message will get a new name and root-ID. The Transmission

FP7-287800 SALUS


Wrapper definition itself will be left unchanged as the exchange of name and root-ID will be still a

valid “MCCI_MT000100UV01” 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/>



<softwareName/>

</device>

</sender>

<respondTo typeCode="RSP">

<entityRsp determinerCode="INSTANCE">

<id/>

<name/>

<telecom value=' '/>

</entityRsp>

</respondTo>

<controlActProcess>

See Control Act Wrapper below

</controlActProcess>

</QUPC_IN043100UV>

As the Transmission Wrapper of “QUPC_IN043100UV” needs no further adaption the next message

to analyze is the Control Act Wrapper “QUQI_MT020001UV01”. This Control Act Wrapper

transports the payload defined in HL7 message “QUQI_MT020001UV01”. This will be described

later in the document. Below it is shown an example of the Control Act Wrapper. As for the

Transmission Wrapper it is also colored to label the adoptions.

Blue marked sequences are affecting the HL7 message “QUQI_MT020001UV01” directly within the

IHE CM profile and do not belong to any of the extensions to be made for SALUS. Within the

example the executionDeliveryTime is set to a periodical update. SALUS may need also updates as

soon as they are available. This can be achieved by not using the “DEFERRED” option from HL7

RIM but the “IMMIDIATE” option stating about a delivery as soon as possible within the time

defined in the tag. In that case the period defined in the tag can be as seen as a timeout. However the

green marked field in this example does not indicate an adaption but a region of interest for SALUS

project.

FP7-287800 SALUS


<controlActProcess moodCode="RQO">


<code code='QUPC_TE043100UV'/>

<effectiveTime value=' '/>

<languageCode code=' '/>

<authorOrPerformer typeCode=' '></authorOrPerformer>

<queryByParameter>


<statusCode code='new'/>

<responseModalityCode code='R|B'/>

<responsePriorityCode code='D'/>

<initialQuantity value=/>

<initialQuantityCode code='REPC_RM000100UV' codeSystem='2.16.840.1.113883'/>

<executionAndDeliveryTime xsi:type="PIVL_TS">

<phase value="20080601000000"/>

<period value='24' unit='h|d|wk|mo|a'/>

</executionAndDeliveryTime>

<parameterList>

see Query Parameter List below

</parameterList>

</queryByParameter>


Depending on the type of query the Parameter List will hold the information which queries to

perform. Therefore the Parameter List will have to be adapted within the payload field. The payload

is defined in HL7 message “QUPC_MT040100UV”. An example is shown below.

<parameterList>

<queryByEn13606/>

<populationBasedQuery>


…


<populationBasedQuery>

<careProvisionCode>

<value code=' ' displayName=' ' codeSystem=' ' codeSystemName=/>

</careProvisionCode>

<careProvisionReason>

<value code=' ' displayName=' ' codeSystem=' ' codeSystemName=/>

</careProvisionReason>

<careRecordTimePeriod>

<value><low value=' '/><high value=' '/></value>

</careRecordTimePeriod>

<clinicalStatementTimePeriod>

<value><low value=' '/><high value=' '/></value>

</clinicalStatementTimePeriod>

<includeCarePlanAttachment><value value='true|false'/></includeCarePlanAttachment>

<maximumHistoryStatements><value value=' '/></maximumHistoryStatements>

<patientAdministrativeGender>

<value code=' ' displayName=' '

codeSystem='2.16.840.1.113883.5.1' codeSystemName='AdministrativeGender'/>

</patientAdministrativeGender>

<patientBirthTime><value value=' '/></patientBirthTime>

<patientId><value root=' ' extension=' '/></patientId>

<patientName><value></value></patientName> </parameterList>

The payload defines the type of data to be queried for. Within the IHE CM profile this part contains

the medical information and is therefore the most interesting part of the whole message. As shown in

the example this payload does not only define the data to query for by the options, but also the

patientID or some other patient related data. As this new extension will also allow querying for none

patient centered data (i.e. population based queries) the Parameter List has to be adapted. The most

obvious thing to change is that the Parameter List has to carry exactly one Patient-ID. As this query

will also be used for HQMF which may have as a result a measured count which does not necessarily

FP7-287800 SALUS


belong to a single patient, but may contain statistical data of a cohort of patients, this field is changed

in cardinality from [1..1] to [0..1]. If the patient Id is left empty the HQMF tag within the payload has

to be used. Next to this a second update to the cardinality has to be made. SALUS needs to keep track

of all patient data update. Therefore the “*”-operator was introduced. This allows subscribing to the

updates of all patients. This changes the cardinality once again from [0..1] to [0..n].

The 2 green marked tags labeled “<queryByEn13606/>” and “<populationBasedQuery/>” are added

to the message to transport this new information. Only one of these tags should be present depending

on the information to be carried. Both tags should extend the ACT-definition of HL7-RIM to be

HL7v3 compatible.

In case of a query defined in EN13606 content model the “<queryByEn13606/>” has to be used. In

case of a HQMF query the “<populationBasedQuery/>” tag will carry the information. Within this tag

a complete HQMF document encapsulated into <QualityMeasureDocument> section has to be placed.

HQMF was already described in 2.1.1.1. In the final year of the project, it will be checked whether the

same information coded in HQMF can also be expressed in EN13606 through archetypes. We will

update this Deliverable accordingly to reflect the results. As HL7 message format was not designed

to carry EN13606 content the “<queryByEn13606/>” was introduced to the Payload. EN13606 is also

based on XML and can therefore be fitted to the structure of the message: In the simplest way as

structured XML. The validation of this private tag will just stick to XML and not analyze the

EN13606 content as this is not part of the HL7 RIM or R-MIM objects.

This adaption of this two new fields lead to new modified Parameter List as defined below:

Parameter Name Cardinality Data

Type

Vocabulary Domain

Consumer Source

careProvisionCode 0..1 CD O R

careProvisionReason 0..* CD O O

careRecordTimePeriod 0..1 IVL<TS> O R

clinicalStatementTimePeriod 0..1 IVL<TS> O R

includeCarePlanAttachment 0..1 BL R R

maximumHistoryStatements 0..1 INT O R

patientAdministrativeGender 0..1 CE AdministrativeGender O R

patientBirthTime 0..1 TS O R

patientId 0..n II R R

patientName 0..1 PN O R

populationBasedQuery 0..1 ED HQMF O R

queryByEn13606 0..1 ED EN13606 O R

Colored entries within the table mark modifications to the original IHE CM profile. The

CareProvisionCode is not changed in cardinality or data type but needs to extend the list of options to

be described later. The Patient ID is changed in cardinality and can be now left out in case of an

HQMF or EN13606 based query, but also be set to “*”-operator to define that information is

requested for all a patients of the data source. The two green marked entries are totally new to the IHE

CM extension. Both entries can be left out as it is in this case compatible to IHE CM. The data type is

set to encapsulate data (ED) and is not further constrained. This would allow also transportation of

other content then XML based data. The vocabulary domains are mapped to EN13606 or HQMF

depending on the tag. Both fields must be supported by a Data Source if the extension should be used,

but can be left out by the Data Consumer.

To decide whether an EN13606 query, a HQMF query or an IHE CM standard query should be

performed a priority listing was introduced. If the “populationBasedQuery” parameter is not left

empty the defined HQMF query will be performed. If it is empty it is checked if an EN13606 query

was defined. If so, the query will be performed otherwise the standard IHE CM query will be

FP7-287800 SALUS


executed. The result set of a population based query as well as the standard query is defined by the

care provision code defined in “<carProcisionCode>” tag. In the first version of this document this

field was defined if an HQMF or EN13606 query should be performed, but as this field now also

describes the result set of the HQMF query, this can’t be done. In the end, if a population based query

has been sent, a list of patients will be found in the database fulfilling the HQMF query, for those

patients the result set as described in the care provision code will be produced and delivered to the

data consumer.

Below the possible result sets of IHE CMext are listed. The green marked Options are the options that

can be tested on LISPA dataset. Other cannot be tested due to the fact that the information is not

available in LISPA Datawarehouse. However, the implementation of the toolset was made to transport

all of the options.

Actor Option

Clinical Data Source

Vital Signs Option

Problems and Allergies Option

Diagnostic Data Option

Medications Option

Immunizations Option

Professional Services Option

Clinical Data Consumer

Vital Signs Option

Problems and Allergies Option

Diagnostic Data Option

Medications Option

Immunizations Option

Professional Services Option

3.2.2 V3 Care Management Update [PCC-10]:

This transaction uses HL7 V3 messages to share health status or patient care related information with

other external systems by using profiles of HL7 V3 Care Record standard messages. This transaction

is left optional to Clinical Data Sources but remains to be required for Care Managers. The response

contains information about the owner of the returned document as well as the content of the

document. This message carries in IHE CM the result on a query and needs to be adapted in case of

EN13606 content. As the “Get Care Record Profile Query” also the “Get Care Record Profile

Response” sends a Transmission Wrapper and a Control Act Wrapper.

The first message to look into is the Transmission Wrapper. An example can be seen below. All

colored lines are remaining to be explicitly affected by the IHE CM profile. Furthermore the green

marked lines will have to be adapted for the IHE CMext profile. It was necessary to introduce a new

HL7 message called “Get Care Record Profile Response extension” which will lead to a new

“QUPC_IN043200UVext” name which has to be changed within the Transmission Wrapper. The

transmission wrapper to be adapted is the based on the HL7 message “MCCI_MT000300UV01”.

<QUPC_IN043200UVext xmlns="urn:hl7-org:v3" ITSVersion="XML_1.0"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">


<creationTime value=' '/>

<interactionId extension='QUPC_IN043200UVext' root='2.16.840.1.113883.5'/>

<processingCode code='D|P|T'/>

<processingModeCode code='T'/>

<acceptAckCode code='AL'/>

<receiver typeCode="RCV">


<id/>

<name/>


FP7-287800 SALUS



<softwareName/>

</device>

</receiver>

<sender typeCode="SND">


<id/>

<name/>



<softwareName/>

</device>

</sender>

<controlActProcess>

See Control Act Wrapper below


</QUPC_IN043200UV>

Within validation schema of the “MCCI_MT000300UV01” HL7 message it is shown that this

message will not be affected by the changes made for the IHE CMext profile

(“QUPC_IN043200UVext”). Therefore the Transmission Wrapper is described in more detail. To

distinguish clearly between these two messages: “QUPC_IN043200UV” describes the usage of the

Transmission Wrapper and the Control Act Wrapper. This needs adaption within the Transmission

Wrapper part as the message will get a new name and root-ID. The Transmission Wrapper definition

itself will be left unchanged as the exchange of name and root-ID will be still a valid

“MCCI_MT000300UV01” message.

Next to the Transmission Wrapper the Control Act Wrapper “MFMI_MT700712UV01” is sent and

has to be adapted. The Control Act Wrapper carries the payload. An example of the Control Act

Wrapper is shown below.

<controlActProcess moodCode="EVN">


<code code='QUPC_TE043200UV'/>

<effectiveTime value=' '/>

<languageCode code=' '/>

<authorOrPerformer typeCode=' '></authorOrPerformer>

<subject>

See Query Response below

</subject>

<queryAck>

<queryId root=' ' extension=' '/>

<statusCode code=' '/>

<queryResponseCode code=' '/>

<resultTotalQuantity value=' '/>

<resultCurrentQuantity value=' '/>

<resultRemainingQuantity value=' '/>

</queryAck>


Everything marked in blue is affected by the IHE CM profile and has to be used the same way

specified in IHE CM. The green labeled tag is the subject tag. It carries the payload which has to be

adapted due to the restriction that the result is in IHE CM a patient centered CDA/CCD document

which does not allow carrying EN13606 content. The following example is an example for a payload

“REPC_MT004000UV” already adapted for IHE CMext.

The fields marked green are the fields to be adapted by this profile. The field

“<pertinentInformation3>” carries the CDA based payload. The entry level CDA based templates

defined in D4.1.2, can be carried within the “<pertinentInformation3>” without compromising the

conformance to PCC 10 transaction definitions. This option will be followed for the time being.

FP7-287800 SALUS


<subject>

<registrationEvent>

<statusCode code='active'/>

<custodian>

<assignedEntity>

<id root='' extension=''/>

<addr></addr>

<telecom></telecom>

<assignedOrganization>

<name></name>

</assignedOrganization>

</assignedEntity>

</custodian>

<subject2>

<careProvisionEvent>

<recordTarget>

<patient>

<id root='' extension=''/>

<addr></addr>

<telecom value='' use=''/>

<statusCode code='active'/>

<patientPerson>

<name></name>

<administrativeGenderCode code='' displayName=''

codeSystem='2.16.840.1.113883.5.1' codeSystemName='AdministrativeGender'/>

<birthTime value=''/>

</patientPerson>

</patient>

</recordTarget>

<pertinentInformation3>



</pertinentInformation3>

</careProvisionEvent>

<parameterList>

</parameterList>

</subject2>

</registrationEvent>

</subject>

This message has to be adapted to carry also EN13606 based content. In this case, the result may be

represented in conformance to EN13606 archetypes. As the “<parameterList>” field should be the

same as in the query it has also to follow the same structure. Therefore also the query based on

EN13606, the HQMF query or the adapted option list in the Care Provision Code has to be respected.

The “<patient>” tag must be switched to optional as it will be possible that the query is not patient

centered and therefore does not contain a single patient. This modification will lead to an adaption of

the Care Provision Event (“REPC_MT004000UV01”) defined in HL7v3. The Pertinent Information

3 field will be switched to a new defined ACT derived from HL7 RIM to either respect the Pertinent

Information 3 as it was defined for IHE CM, but also a result set of a HQMF query which may be an

EN13606 based content.

It should be noted that HQMF is designed for collecting statistics as quality measures from the

selected population. As a response set, Quality Reporting Document Architecture (QRDA) documents

are collected. In SALUS on the other hand we would like to collect de-identified medical summaries

of the selected population to be analyzed further by post market safety analysis tools, rather than

eMeasures. The result set in SALUS is defined in the care provision code tag of the query. The parts

of HQMF used in SALUS are leading to results completely covered by the CCD templates.

3.2.3 V2 Care Management Update [PCC-11]

This transaction uses HL7 V2 messages to share health status or patient care related information with

other external systems by using profiles of HL7 V2 standard messages. This transaction is left

optional to Clinical Data Sources but remains to be required for Care Managers.

FP7-287800 SALUS


As within SALUS project only data related to HL7V3 will be used for the semantic layer the HL7V2

transaction of this profile will be left unchanged. The [PCC-11] transaction will be used as defined in

IHE CM original profile definition. Therefore the IHE CMext profile will be completely backwards

compatible to IHE CM.

4 OPEN SOURCE TOOLSET

4.1 Introduction

This section shows how the Technical Interoperability Layer is placed within the SALUS system and

how the components are technically implemented as Open Source Toolset. For technical

interoperability two major components are be placed within the core. The first component is the

Technical Interoperability Layer Data Service (TILDS). This will the interface of SALUS core to

external safety analysis systems which want to query (or subscribe to) de-identified medical data sets

for post market safety analysis studies and ICSR reporting. TILDS enables this communication

through the extended profiles described in this deliverable and in D5.2.1. TILDS will for example be

triggered by a tool as the Adverse Drug Event Notification Tool (ANT) or also the ICSR reporting

tool. If one of those tools needs medical information it can trigger TILDS by using the transactions

enabled by the extended profiles. Alternatively, SALUS also provides a direct semantic interface for

semantically enabled toolsets (detailed information about this semantic interface will be available in

D4.4.1). Technical Interoperability Query Source Data Service (TIQSDS) on the other hand is the

interface of SALUS core to the underlying EHRs and Data warehouses.

Figure 11: Overview of TILDS and TIQSDS in SALUS system

Figure 11 gives a simplified overview of the SALUS system focusing on TILDS and TIQSDS in case

of an IHE CMext transaction. Gray boxes or arrows within the graph are only placed for orientation

and completeness, but does not affect the IHE CM part or TIL. A CMext subscription is always

initiated by a Data Consumer. In case of this example this might be the ANT or ICSR reporting tool.

FP7-287800 SALUS


Both tools also be allowed to use SPARQL, but this will be not explained here in more detail (please

refer to SALUS Deliverable 4.4.1). The Data Consumer subscribes to the Data Repository of TILDS.

This extracts the payload of the IHE CMext transaction including the parameterList and sends it to the

SALUS semantic layer. The semantic interoperability layer decides what kind of data source to query

in the end for initiating the subscription. This could be for example a SPARQL endpoint (in case that

the EHR system already exposes a SPARQL endpoint) or an EHR system connected by IHE CMext

(in case that the EHR system has opted to implement the IHE based profile). In all cases the SALUS

semantic interoperability layer generates the query in the standard needed. In case of IHE CMext it

would be the same parameter list as already accepted from TILDS. Focusing on the example SALUS

semantic interoperability layer will also send the payload to TIQSDS. Depending on the workflow

TIQSDS might decide to subscribe to the EHR system by using IHE CMext. The subscription will be

handed over to the LISPA connector in SALUS architecture (LISPA connector is an adopter to be

developed on top of the data warehouse of Lombardy Region, see section 4.2.3). The LISPA

connector performs the SQL queries needed to prepare the resulting dataset and returns it through IHE

CMext update messages to the SALUS semantic interoperability layer to be translated and afterwards

through TILDS by using IHE CM to the querying party which might be ether ANT or ICSR in this

example.

To offer higher interoperability with other software tools all workflow connections can also be

replaced by native JAVA calls. This might lead to easier integration, but will miss the debugging

features and flexibility of the workflow management. Within the following the components of TIL as

well as the components connected to TIL will be described more in detail.

4.2 Component definition used for subscription to data

The components described within the following are directly related to TIL or parts of TIL.

Components closely related to TIL are just described here to explain how TIL reacts and

communicates to external triggers; parts of TIL are described in more detail. These parts are TILDS

and TIQSDS and its subcomponents. As some of the components are also related to D5.2.1 for direct

queries these sections will refer to D5.2.1 and not described here to avoid unnecessary redundancies

within the deliverables.

4.2.1 Technical Interoperability Layer Data Service (TILDS) and Technical

Interoperability Query Source Data Service (TIQSDS)

The two main components of TIL are the Technical Interoperability Layer Data Service (TILDS) and

Technical Interoperability Query Source Data Service (TIQSDS). As already explained above these

components control the communication between an external Data Consumer or external Data

Repository and SALUS semantic interoperability layer. The internal modules of communication are

IHE CMext and IHE QEDext to be developed within Task 5.1 and 5.2. As for task 5.2 already first

implementations were available after the first project year (and therefore also for TILDS and

TIQSDS), the description of TILDS and TIQSDS is shifted to D5.2.1 and updated in D5.2.2 where

also the implementation of the IHE QEDext module is described. The PCC-1 transaction in IHE QED

and the PCC-9 and PCC-10 transaction in IHE CM are using the same message structure. Therefore

the message builder and message parser are located in the same component and also described in

D5.2.2 more in detail.

4.2.2 Workflow Management

The workflow management is a component needed to coordinate the data flow between several

services running on one machine. Introduction of a workflow management to TIL allows all services

to fulfil the same interface and therefore to communicate easily with each other. The workflow system

bases on a payload containing the workflow to perform as well as the payload to be sent around and to

be modified. As one of the SALUS key features will be the transformation and translation of

documents from one standard to another it is obvious that transportation of documents is needed. This

section will describe the mechanisms needed to pass this information around and how to use the tools

FP7-287800 SALUS


implemented for developing and debugging. In the first step the basic idea of workflow organisation

for TIL will be described.

4.2.2.1 SALUS workflow model

The SALUS workflow model consists of several parts to be explained further in detail within the

following. The first part to be described will be the Service Definition. It defines the name, possible

actions and corresponding results of a service. This definition can afterwards be used to define a

workflow over several services (described within their definition) and at the end this workflow model

will result in a workflow object which than can be send around between the participating parties to

fulfil the workflow.

Basic structure of a workflow definition (Service description)

To define workflow first of all it has to be defined what services are available participating in the

workflow and what kind of actions can be performed on these services. Figure 12 gives a brief

example of how a workflow definition for a service will look like within TIL. A workflow definition

for a service is always described as directed graph excluding cycles. Next to the graph structure it is

divided into three layers.

Figure 12: Example of a workflow definition for the TILDS service

The first layer is the service layer. It defines the name of the service. In the example it is the “TILDS

service”. This name will be used by the workflow management system to identify the next recipient of

a workflow message. The service node is always the root node of a service to communicate to. The

second level within a service definition is the action layer. This layer defines within the graph what

kind of action can be performed by this service. Within this example the actions defined are

“subscribe”, “handle update”, and “cancel subscription”. If a workflow should be defined by using

also the TILDS service exactly one of these three actions has to be included into the workflow graph.

As an action will often result in several different results this has also to be defined within the service

definition. Every action can have 1 to n different results. Every result possible has to be defined in

advance and cannot be produced during runtime. In this example a simple solution was chosen. All

actions can end up in a success or an exception. Of course there can be a lot of more different results

which are specific to a specific action.

Basic structure of a workflow (task to be performed by the system)

Once all services of the system have been defined within the structure above a workflow can be

defined and performed as a task by the workflow engine and the participating services. A workflow is,

as the service definition, defined as a directed graph excluding cycles. In formal a workflow is a

concatenation of service definition sub-graphs. This will be described within the following.

FP7-287800 SALUS


Figure 13: Example of a workflow task definition using the TILDS service and the IHE CM service

Figure 13 gives an example of a workflow definition (the task to be performed). In the upper right

corner the already introduced TILDS service is placed. In the lower left corner also the IHE CM

service is part of the task to be performed. Both are in general defined by the same actions and results

(which of course does not mean that they will execute exactly the same source code). To define a

workflow all services and actions participating in the task have to be defined. In this example the

TILDS service is the first service within the workflow. Its root node was also defined to be the root

node of the task and it was decided that also the subscribe action has to be called on the TILDS

service which will lead to two possible results decided during runtime. In case on an exception it was

defined that the exception node will result in the final node defining the workflow to end there. The

final node defines that the exception is an expected result within the workflow. If the final node would

not have been added here and the subscribe action would have ended in an exception, a warning

would have been thrown by the workflow engine stating an unexpected ending of the task. In case the

subscribe action of the TILDS service was successful it is defined within the workflow to call the

subscribe action of the IHE CM. This would also lead to two possible results: A success ending up

with the final node stating the end of the task or an exception which was not defined any further and

would therefore end up in a warning by the workflow engine that the task ended unexpected.

Basic structure of a workflow (Extension of the workflow model for execution)

Up to now it is possible to define a service, its actions, and also the results of every action. Also these

services can be lined up in directed graph to a workflow task description. What is missing so far is an

extension to allow this model also to be executed as a workflow. Therefore a simple token based

model is introduced within the following.

FP7-287800 SALUS


Figure 14: Example of a workflow task execution using the TILDS service and the IHE CM module

Figure 14 shows the example used so far extended by a token based approach. By looking on the

graph all nodes (colour independent) within could have been part of the workflow. By restricting the

graph to the actions to be performed all green nodes can be now part of the execution. At every action

node within the graph a decision has to be made. The execution will follow the graph depending on

the action result. Within the example the red marked arrows show the path through the possible

workflow taken so far. The red marked node defines the current execution point within the workflow.

In this example the IHE CM module is performing currently the subscribe action and the result of this

action has not be set so far. Depending on the result the next position of the token will be ether the

success node or the exception node.

In the end this construction leads to three simple algorithms: An algorithm for creating service

definitions, an algorithm to create workflow definitions out of service definitions and an algorithm for

execution of the graph to handle it during runtime. These three algorithms will be shortly described

now:

Defining services:

1. Define a service root node, mark it blue and attach a name to it

2. On the second layer define an action, label it by name, mark it blue and connect it to the

service root node

3. Repeat 2 as long as there are new actions to be defined and make sure the action does not

exist so far.

4. On the third layer define a result, label it by name, mark it blue and connect it to the action

node to which the result belongs.

5. Repeat 4 as long as not all possible results are mapped to all possible actions.

FP7-287800 SALUS


Defining workflow task:

1. Take a service definition, mark it to be the root of the workflow task

2. Colorize the service root node green

3. Choose an action to be performed on the service and mark it green

4. Mark all results of the chosen action green

5. For all green marked results append a new service node or the final node. If not the final node

handle this service node as described in 2.

6. Stop when all green marked results have a final node attached.

Executing workflow task:

1. Mark the root node red

2. Move the red token to the green marked action of the currently red marked service node

3. Perform the action

4. Move the red token to the result given by the service

5. Move the red token to the connected final node, mark it red and end the task or move it to the

next service node, mark it red and proceed as defined in 2.

6. The task ends in reaching a final node

4.2.2.2 Workflow management implementation

Whereas the description of the workflow management and the participating parties was more based on

the models the following will focus on the implementation of the workflow management. Therefore

the system is divided into two major categories. The first category includes all tools, engines and

routers needed to perform, develop and debug workflow task whereas the second category focuses on

all services which can be connected to the workflow engine to be executed or debug.

Setting up a workflow service definition (as part of the “defining services algorithm”)

As already shown in Figure 12 a service has to be defined as a service definition. This will be

currently done in JAVA native language, but can be extended in further development steps to be also

configurable in a language and system independent manner e.g. by using XML as service node

description language.

FP7-287800 SALUS


Figure 15: Example of a service node definition in JAVA native language

Figure 15 gives an overview of how a service should be defined to be used within the workflow

management. First of all it should extend the NodeDefinition. This is essential to be used within the

workflow management tool. As a second step a final String for defining the name of the service

should be included as well as final Strings for all actions and results. For all developers it would be

helpful if these field names would start with “ACTION_” or “RESULT_” and have as content a

human understandable String which must be unique within the service. Once all final Strings have

been defined the results have to be attached to the corresponding actions. This will be done within the

constructor as described by the example. The exception result is added within the example only for

the completeness. It will be added by the system automatically and can be left in the constructor. The

exception case will be always valid as it is likely that for every code an exception can be thrown.

Setting up a workflow service based on the workflow service definition made (as part of the

“defining services algorithm”)

Basing on above described service definition an example service will be developed and explained

within the following. This service is performing no real action within the code, but shows how

workflow services will be implemented. All workflow services will have to implements the

WorkflowService interface as shown below.

FP7-287800 SALUS


Figure 16: WorkflowService interface that has to be implemented by every service connected to the

workflow management

The interface shown above consists of two simple methods. The method “public String getName()”

simple returns the name of the service as defined within the node definition and should be therefore

automatically be answered without any new implementation if the implementation guide is followed

and all services extend their service node. The second method is the “public String

receivePayload(String action, Payload payload)”. This method will be called by the workflow router

to inform the service implementing this interface about an action to be performed. Its action to

perform will be included in the call as well as the payload. This payload object contains the workflow

object as well as the payload itself that should be passed around and modified.

This object will be returned to the workflow router indirectly by reference next to the result which is

the defined return value of the method. The workflow router searches for the token marking the next

recipient in the workflow, looking for the action being performed and sends it to the corresponding

service. This service will perform the action called, modifies the payload if needed and returns the

result back to the workflow router. The router will find the next recipient depending on the result or

end the workflow if a final node was reached. If any undefined state will be reached, the engine will

throw a warning to state that the workflow has to be adapted. At least a final node is missing in the

workflow object.

FP7-287800 SALUS


To have a better understanding on how a service implementation will look like the following figure

will give you an overview.

Figure 17: Example of the TIQSDS service node implementation

As the example in Figure 17 shows, the TiqsdsService extends its own service definition

(TiqsdsServiceNode) and also implements the WorkflowService interface. This combination allows

the participation on the workflow management system and reduces the effort for implementation to a

maximum. Only the “receivePayload” method needs to be implemented in this case. As shown in the

example this method should just contain several if-case-statements to start operation on a certain

action and return the result as String defined in the service node definition.

After implementing a service it just has to be registered as a new instance of its class to the workflow

engine and can be used during execution. SALUS project already provides code examples for using

the workflow management within the SALUS GIT repository.

FP7-287800 SALUS


Setting up a workflow task based on the workflow service definition made (as part of the

“defining workflow task algorithm”)

As already described within the workflow model section of this document workflow tasks have to be

defined also in code. This will be currently done in JAVA native language and may change over

project runtime. As the definition of a workflow is not easily readable in code a tool was developed to

give a graphical interpretation of the workflow defined so far. Within the following the tool for

developing and debugging of workflow tasks will be described further in detail.

Figure 18: Code example for the definition of the subscription workflow

Figure 18 gives an example of the subscription use case already introduced before in the theoretical

section about workflow management (see Figure 13). This example shows how a workflow can be

defined within code. All workflows defined have to extend the Workflow object already defined in

the workflow API. This is necessary to execute the workflow on the workflow engine. Next to this for

every action to be performed on a service an instance of its service node definition has to be created:

In this example one instance of the TiqsdsServiceNode and one instance of the IheCmServiceNode.

The instance of the TiqsdsServiceNode was also defined to be the root node. If no root node is defined

no starting point for the workflow will be available and therefore the workflow will be empty. Once

the root node is defined the other nodes have to be appended to results of the root node or other

services. This can be done by the “appendWorkflowToResult”-method. In this case for the

IheCmServiceNode the FinalNode was appended to the success result of the subscribe action and the

IheCmServiceNode was appended to the subscription successful result of the TiqsdsServiceNode.

This completes the workflow task for subscription as defined in Figure 13. As it might be pretty

confusing to a developer by looking at the code a graphical user interface was designed check the

workflow task more in detail.

FP7-287800 SALUS


Figure 19: Graphical tool for visualizing workflow task for developing and debugging workflow tasks

Figure 19 gives a graphical visualization of the workflow task described in Figure 18 as code. The

first node in the tree is marked as being a service and named “eu.salus.de.offis.tiqsds” which is the

name given in the node definition e.g. seen in Figure 15. As a sub node of the service node the chosen

action is represented. In this case “subscription to EHR” followed by two possible results. At this

point the developer can check whether all results are included into the workflow or not. In this case no

following action is added to the exception result, because it is marked as a leaf in the tree. It should at

least the final node be added here. In case of success another service named

“eu.salus.de.offis.iheCmExt” is triggered by its subscription action which is also missing the final

node for the exception result. In case of a success the final node is marked by “[SERVICE] end”. The

tree can be expanded step by step so a developer can navigate through the whole tree and checking if

the workflow is modelled the way it should be.

Execution of a workflow task based on the workflow tasks and services implemented (as part of

the “Executing workflow task algorithm”)

During runtime the workflow engine is controlling the routing, representation and handling of several

workflows and services connected to the workflow system. Therefore the workflow engine was split

into three sub modules.

The first one is the engine itself. It is responsible for registering new services to be used by the

workflow management and also for initiating new workflows. If some application needs a workflow

to be executed it creates a workflow object as defined above and hands it over to the workflow engine.

The engine than will check its runtime mode first and create a new workflow router for the task. The

engine can be used in two different modes. The first one is the standard mode which allows the engine

to run stand alone without any help from the outside. This mode is developed for productive operation

at the end. The second mode is a debug mode. This will stop the workflow right after performing any

action on a service. This allows the developer to have a look on the data to be handled every step and

to check whether it is correct or not.

The second module is the workflow router. There are always as much workflow routers active within

the system as currently active workflow tasks. Every workflow task gets its own workflow router to

allow multi-tasking on workflows without blocking services against each other. To keep the system

consistent every service called on its receivePayload-method is synchronized and therefore will block

until the method has returned. The main work of a workflow router is to route the workflow payload

from one service to another. It takes care for the red token defined in the model as seen in Figure 14.

At the beginning it sets the token to the root node and extracts the first service and the action to be

called. At the next step it retrieves the result, sets the token to the corresponding result node, figures

out the next service to call, sets the token to this service and waits for the result. This will be repeated

until a final node is reached and the workflow has ended or an undefined state is reached. This will

lead to a warning, but will end the workflow anyway without affecting new already running

workflows.

FP7-287800 SALUS


To get a better impression of the system during development and debugging of the system a graphical

user interface was designed.

Figure 20: Graphical user interface of the workflow engine

Figure 20 gives an overview of the main window of the graphical user interface of the workflow

engine. On the left side all active workflow are listed. The user can choose a workflow he/she would

like to look into just by right clicking on the workflow and choosing one of the four spaces where

workflows can be placed on the center side of the screenshot. On the lower left part also the “next

step” button (in this case grayed out) is placed, which allows the user during debug mode to go step

by step though the workflows. The “show payload” button also placed on the lower left allows the

user to have a deeper look in the payloads of the four presented workflows. This can be seen in Figure

21. On this screenshots only workflow 1 and 2 do contain payloads whereas the workflows 3 and 4 do

not contain data to be send between services.

This graphical user interface was designed for workflow developers to enable easy and simple

development and debugging by using this system. In productive operations of course it should not be

needed to look in the data in between and also not to go stepwise through the data.

FP7-287800 SALUS


Figure 21: Graphical user interface for looking at the payloads of the currently active workflow tasks

4.2.3 LISPA connector

The LISPA-Connector builds the interface between the SALUS components and the LISPA data

warehouse. In SALUS project the LISPA data warehouse is connected by using existing standards

like IHE QED or IHE CM. It will be connected to TIQSDS as a data repository in terms of IHE.

Figure 22 shows the overview of the SALUS system and the position of the LISPA connector within

it. The red marked box shows the communication between TIQSDS and LISPA connector. Data

queried by IHE QED or IHE CM by TIQSDS (in this graphic through IHE QEDext) as Data

Consumer will be sent to the corresponding IHE module on the EHR side of TIQSDS acting as Data

Repository. The payload carrying the query will be passed to the LISPA connector. Once the query is

received by the LISPA connector it will analyse the query and send an exception if the data is not

valid. In case of a valid query the LISPA connector will query the pseudonymized EHR tables by

using SQL and prepare a result data set using the standard queried for. This might be either EN13606

or HL7 CDA Entries. The result is fed to TIQSDS and sent back to the SALUS core side of TIQSDS

by using the selected profile of the query.

FP7-287800 SALUS


Figure 22: SALUS Overview and position of LISPA connector

For SALUS purposes, LISPA sets up a separate data warehouse as a copied data subset that fulfills

the needs of the project pilots (see Figure 23). This subset is called “SALUS LISPA DWH” and

contains only pseudonymized data. Therefore every patient ID will be pseudonyms within the

prototype.

FP7-287800 SALUS


Figure 23: Schema of the SALUS data warehouse at LISPA

FP7-287800 SALUS


In the following tables the SALUS data requirements with respect to different SALUS end user

scenarios (for more details, see Deliverable D4.1.2) are listed with their correlated mapping to the

data fields of the SALUS LISPA DWH. From these tables and the knowledge about the information

being available at LISPA site the final database structure of the LISPA connector was derived. This

will be explained more in detail within the following

x =Required

x(o)= Optional

Sc. 1: Enabling notification of suspected ADEs

Sc. 2: Enabling semi-automatic ADE Reporting

Sc. 3: Characterizing the cases and contrasting them to a background population

Sc. 4: Temporal pattern characterization

Sc. 5: Running Exploratory Analysis Studies over EHRs for Signal Detection

Sc. 6: Calculating incidence rates of CHF in diabetic patients with a recent acute coronary syndrome

(ACS) event)

Selected SALUS Scenarios/Related EHR Data Items

Sc. 1

Sc. 2

Sc. 3

Sc. 4

Sc. 5

Sc. 6

SA

LU

S

LISP

A

DW

H

ma

pp

in

g

Ma

pp

in

g

field

descrip

ti

on

Patient Name or Initials x(o)

ID x (o) PATIENT.ID

Pseudonymized ID key

Date of Birth x x x x x

PATIENT.DATE_OF_BIRTH

Date of birth

Gender x x (o) x x x

PATIENT.GENDER

Gender of a patient

Race x (o) x (o)

Birth Place (Region or City)

Patient registration date x (o)

PATIENT_REGISTRATION_DATE

Patient de-registration date x (o)

PATIENT_DEREGISTRATION_DATE

Specialist Record Number x (o)

GP medical record number x (o)

Hospital record number x (o)

Ethnicity x(o)

Provider ID x(o)

Provider Organisation ID x(o)

PROVIDER_ORGANIZATION_ID

FP7-287800 SALUS


Address x(o)

Investigation number x (o)

Table 1: SALUS data requirements for EHR Section: “Patient” – Mapping to SALUS LISPA DWH


Sc. 1

Sc. 2

Sc. 3

Sc. 4

Sc. 5

Sc. 6

SA

LU

S

LISP

A

DW

H

ma

pp

in

g

Ma

pp

in

g

field

descrip

ti

on

YES/NO x (o)

HOSPITALISATION.

DIAGx(x:

1-5)_ID;

AMBUL

ATORY.

DIAG_ID

Pregnancy coded as a

diagnosis.

Delivery Date x (o)

PATIENT_PREGNANCY.END_DATE

Pregnancy Status x (o)

Last Menstrual Period Date x (o) x (o)

PATIENT_PREGNANCY.LAST_MESTRUAL_DATE

Table 2: SALUS data requirements for EHR Section: “Pregnancy” – Mapping to SALUS LISPA DWH


Sc. 1

Sc. 2

Sc. 3

Sc. 4

Sc. 5

Sc. 6

SA

LU

S

LISP

A

DW

H

ma

pp

in

g

Ma

pp

in

g

field

descrip

ti

on

Problem Name x(o) x(o) x x x

The problem code is

available – problem

name can be derived

from the problem

code.

Problem code x(o) x(o) x x x x

HOSPITALISATION.

DIAGx(x:

1-5)_ID;

AMBUL

ATORY.

DIAG_ID

Diagnoses coded in

DRG and ICD9. DRG

is the diagnosis sub-

hierarchy of ICD-9-

CM consisting of

values from 001 -

999.0.

Start Date x(o) x(o) x x x x

AMBULATORY.START_DATE; HOSPITALIZATION.DAT

Describes the date of

occurrence.

FP7-287800 SALUS


E_OF_EVENT

End Date x(o) x(o) x x (o) x x (o)

AMBULATORY.END_DATE

The date the condition

was noted to be ended

Problem Status x(o) x(o) x

Depending on start and end date it is “active” or “inactive”

Date of Entry x x x

HOSPITALIZATION.INSERT_DATE; AMBULATORY.INSERT_DATE

Describes the day the entry was made

Related Encounter x (o)

Treating Provider x (o)

GP.FISCAL_CODE

The GP that currently takes care for the patient. This needs to be queried from the DB by the HAS_GP table

Severity x(o)

Comments / text describing Problem x(o)

HOSPITALISATION.

DIAGNO

SIS_DES

C_ISCD9

CM(x:1-

5);

AMBUL

ATORY.

DIAGNO

SIS_DES

C_ISCD9

CM(x:1-

5);

Textual description of the ICD9 code

Table 3: SALUS data requirements for EHR Section: “Condition (past medical history)” – Mapping to

SALUS LISPA DWH


Sc. 1

Sc. 2

Sc. 3

Sc. 4

Sc. 5

Sc. 6

SA

LU

S

LISP

A

DW

H

ma

pp

in

g

Ma

pp

in

g

field

descrip

ti

on

Problem Name x x (o) x x x

The problem code is

available – problem

name can be derived

from the problem

code.

Problem code x x (o) x x x x HOSPIT Diagnoses coded in

FP7-287800 SALUS


ALISATION.

DIAGx(x:

1-5)_ID;

HOSPIT

ALIZATI

ON.PRIM

ARY_DI

AGNOSI

S_CODE

_ICD9C

M;

HOSPIT

ALIZATI

ON.COM

PLICATI

ON_DIA

G_CODE

_ICD9C

M;

AMBUL

ATORY.

DIAG_ID

DRG and ICD9. DRG


hierarchy of ICD-9-

CM consisting of

values from 001 -

999.0.

Start Date x x (o) x x x x

AMBULATORY.START_DATE; HOSPITALIZATION.DATE_OF_EVENT


occurrence.

End Date x x (o) x x x x (o)

AMBULATORY.END_DATE; HOSPITALIZATION.DISCHARGE_DAY



Problem Status x x (o) x

Depending on start and end date it is “active” or “inactive”

Date of Entry x x



Related Encounter x x

FP7-287800 SALUS


Treating Provider x

GP.FISCAL_CODE

The GP that currently takes care for the patient. This needs to be queried from the DB by the HAS_GP table

Severity x

Comments / text describing Problem x(o)

HOSPITALISATION.

DIAGNO

SIS_DES

C_ISCD9

CM(x:1-

5);

HOSPIT

ALIZATI

ON.PRIM

ARY_DI

AGNOSI

S_DESC_

ICD9CM;

HOSPIT

ALIZATI

ON.COM

PLICATI

ON_DIA

G_DESC

_ICD9C

M;AMBU

LATORY

.

DIAGNO

SIS_DES

C_ISCD9

CM(x:1-

5);

Textual description of the ICD9 code

Table 4: SALUS data requirements for EHR Section: “Condition (active problems/symptoms)” –

Mapping to SALUS LISPA DWH


Sc. 1

Sc. 2

Sc. 3

Sc. 4

Sc. 5

Sc. 6

SA

LU

S

LISP

A

DW

H

ma

pp

in

g

Ma

pp

in

g

field

descrip

ti

on

Adverse Event Type (text) x (o) x (o) x x

Adverse Event Type (coded) x (o) x x x

Product Code x (o) x

Product Name x (o) x

Reaction x (o) x

HOSPITALISATION.

DIAGx(x:

1-5)_ID;

Diagnoses coded in

DRG and ICD9. DRG


hierarchy of ICD-9-

CM consisting of

FP7-287800 SALUS


HOSPIT

ALIZATI

ON.PRIM

ARY_DI

AGNOSI

S_CODE

_ICD9C

M;

AMBUL

ATORY.

DIAG_ID

values from 001 -

999.0.

Start Date and Time x (o) x (o) x x



occurrence.

Severity x (o)

x (o) (seriousness)

Date of end of reaction/event x (o) x (o)

AMBULATORY.END_DATE; HOSPITALIZATION.DISCHARGE_DAY



Outcome of reaction/event at the time of last observation x (o) x (o)

Date of Entry x x



Table 5: SALUS data requirements for EHR Section: “Allergies/Intolerances” – Mapping to SALUS

LISPA DWH


Sc. 1

Sc. 2

Sc. 3

Sc. 4

Sc. 5

Sc. 6

SA

LU

S

LISP

A

DW

H

ma

pp

in

g

Ma

pp

in

g

field

descrip

ti

on

Kinship Type x (o)

Family History x (o)

FP7-287800 SALUS


Observation name

Family History Observation code x (o)

Age at Onset x (o)

Table 6: SALUS data requirements for EHR Section: “Family History” – Mapping to SALUS LISPA

DWH


Sc. 1

Sc. 2

Sc. 3

Sc. 4

Sc. 5

Sc. 6

SA

LU

S

LISP

A

DW

H

ma

pp

in

g

Ma

pp

in

g

field

descrip

ti

on

Result Type (text) x x (o) x x

Result Type (Coded) x x (o) x x x

Result Value (Numeric) x x (o) x x x

Result Value (Coded) x x (o) x x x

Result Value (String) x x (o) x x x

Unit x x (o) x (o)

Result Date x x (o) x

Result Reference range x x (o) x (o) x (o) x (o)

Result Interpretation x x (o)


Related Condition x (o)

Result Provider x (o)

Table 7: SALUS data requirements for EHR Section: “Lab results” – Mapping to SALUS LISPA DWH


Sc. 1

Sc. 2

Sc. 3

Sc. 4

Sc. 5

Sc. 6

SA

LU

S

LISP

A

DW

H

ma

pp

in

g

Ma

pp

in

g

field

descrip

ti

on

Procedure Type (text) x (o)

Procedure Type (coded) x x (o) x

HOSPITALIZATION.INTERVx(from 1 to 5)_CODE_ICD9CM; AMBULATORY.AMB_ORDER_CODE

Code of the main

intervention.

Body Site x (o)

Procedure Date x (o) x HOSPITALIZATI

Date of the main

intervention.

FP7-287800 SALUS


ON.START_DATE; AMBULATORY.START_DATE

Procedure Status x (o)

Indication x (o)


Procedure Provider x (o)

Comments / text describing Procedure x(o)

Table 8: SALUS data requirements for EHR Section: “Procedures” – Mapping to SALUS LISPA DWH


Sc. 1

Sc. 2

Sc. 3

Sc. 4

Sc. 5

Sc. 6

SA

LU

S

LISP

A

DW

H

ma

pp

in

g

Ma

pp

in

g

field

descrip

ti

on

Product Name x x x x x x

Product Code x x x x x x

Brand name x x (o)

DRUGS_CODE.COMPANY_DESC

Brand code x x (o)

DRUGS_CODE.COMPANY_CODE

Active Ingredient Name x x x x x

DRUGS_CODE.ATC_DESC

The active ingredient

code is available –

ingredient name can

be derived from the

problem code.

Active Ingredient Code x x x x x

DRUGS_CODE.ATC_CODE

The ATC code of the

active ingredient.

Product Form (of administration x x (o)

Dose x x (o) x

DRUGS.NUM_DDD

The Daily dose for a

drug. The unit of the

dose is available as

well:

“DRUGS.MEASURE

_UNIT”

Frequency x x (o) x

Route (Coded) x x (o) x

DRUGS_CODE.ROUTE_ADM_CODE_ENG

Start Date x x (o) x x x x

DRUGS.DELIVERY_DAT

The delivery date of a

drug (=sale date).

FP7-287800 SALUS


E

End Date x x (o) x x (o) x x (o)

Can be calculated by

“start date + days

supply”

Duration x x (o)

Indication x x (o) x (o)

Order Date x

DRUGS.START_DATE

Date of Entry x x x

DRUGS.INSERT_DATE

Refills x (o)

Quantity x (o)

DRUGS.AMOUNT_OF_DRUG_DISTRIBUTED

Total amount of the

drug distributed. If the

drug has been

distributed a pack

whole or more, the

amount corresponds to

the number of packs.

If the drug was not

distributed by a pack

whole but a part

(pieces, vials), the

amount corresponds to

the number of pieces.

Days Supply x (o)

DRUG.DDD_DAY

Please note: Most

probably the

frequency information

specific to a patient is

not available in the

DWH; only the

administrative

information is.


Fulfillment Instructions x (o)

Prescribing Provider x (o)

Stop reason x (o) x (o)

Table 9: SALUS data requirements for EHR Section: “Medications” – Mapping to SALUS LISPA DWH


Sc. 1

Sc. 2

Sc. 3

Sc. 4

Sc. 5

Sc. 6

SA

LU

S

LISP

A

DW

H

ma

pp

in

g

Ma

pp

in

g

field

descrip

ti

on

Start Date x x



occurrence.

End Date x x AMBULA The date the condition


FP7-287800 SALUS


TORY.END_DATE; HOSPITALIZATION.DISCHARGE_DAY

or discharge day,

depending on table

Encounter Performer (Provider)

Encounter Type x (o)

AMBULATORY.FLAG_LAB_EXAM_AMB

Examination=0;

Laboratory = 1;

Procedure=2

Care Provider Location (Organisation) x (o)

Reason for Encounter x

HOSPITALISATION.

DIAGx(x:

1-5)_ID;

HOSPIT

ALIZATI

ON.PRIM

ARY_DI

AGNOSI

S_CODE

_ICD9C

M;

AMBUL

ATORY.

DIAG_ID

Diagnoses coded in

DRG and ICD9. DRG


hierarchy of ICD-9-

CM consisting of

values from 001 -

999.0.

Table 10: SALUS data requirements for EHR Section: “Encounters” – Mapping to SALUS LISPA DWH


Sc. 1

Sc. 2

Sc. 3

Sc. 4

Sc. 5

Sc. 6

SA

LU

S

LISP

A

DW

H

ma

pp

in

g

Ma

pp

in

g

field

descrip

ti

on

Result Type (text) x x (o) x

Result Type (Coded) x x (o) x x

Result Value (Numeric) x x (o) x x

Result Value (Coded) x x (o) x

Result Value (String) x x (o) x

Unit x x (o) x (o) x

Result Date x x x

Result Reference range x x (o)

FP7-287800 SALUS


Result Interpretation x


Related Condition x (o)

Result Provider x (o)

Table 11: SALUS data requirements for EHR Section: “Vital Signs” – Mapping to SALUS LISPA DWH


Sc. 1

Sc. 2

Sc. 3

Sc. 4

Sc. 5

Sc. 6

SA

LU

S

LISP

A

DW

H

ma

pp

in

g

Ma

pp

in

g

field

descrip

ti

on

Social history type x x

Social history status x x

Social history dates

Table 12: SALUS data requirements for EHR Section: “Social History” – Mapping to SALUS LISPA

DWH


Sc. 1

Sc. 2

Sc. 3

Sc. 4

Sc. 5

Sc. 6

SA

LU

S

LISP

A

DW

H

ma

pp

in

g

Ma

pp

in

g

field

descrip

ti

on

Reporter title x(o)

Reporter given name x(o)

Reporter family name x(o)

Reporter organization x(o)

Reporter address x(o)

Table 13: SALUS data requirements for EHR Section: “Data Reporter” – Mapping to SALUS LISPA

DWH


Sc. 1

Sc. 2

Sc. 3

Sc. 4

Sc. 5

Sc. 6

SA

LU

S

LISP

A

DW

H

ma

pp

in

g

Ma

pp

in

g

field

descrip

ti

on

Date of Death x (o) x (o)

PATIENT.DATE_OF_DEATH

The Date when the

patient died.

Cause(s) of death x (o)

Was autopsy done? x (o) PATIENT.AUTOPSY_DONE

Autopsy-determined cause(s) of death

x (o)

Table 14: SALUS data requirements for EHR Section: “Death” – Mapping to SALUS LISPA DWH

FP7-287800 SALUS



Sc. 1

Sc. 2

Sc. 3

Sc. 4

Sc. 5

Sc. 6

SA

LU

S

LISP

A

DW

H

ma

pp

in

g

Ma

pp

in

g

field

descrip

ti

on

Provider ID x

GP.FISCAL_CODE

ID of the GP being

responsible for the

patient

ProviderType x (o)

Organisation x (o)

Table 15: SALUS data requirements for EHR Section: “Healthcare Provider” – Mapping to SALUS

LISPA DWH


Sc. 1

Sc. 2

Sc. 3

Sc. 4

Sc. 5

Sc. 6

SA

LU

S

LISP

A

DW

H

ma

pp

in

g

Ma

pp

in

g

field

descrip

ti

on

OrganisationID x x

organisationAddress x x (o)

organisationType x (o)

organisationName x x (o)

Table 16: SALUS data requirements for EHR Section: “Organisation” – Mapping to SALUS LISPA

DWH

Some attributes that are required by the SALUS pilots are not available in the LISPA setting. Other

values can be derived, for example (problem) names via (problem) codes or counts by counting table

instantiations. For further information regarding the LISPA DWH see D.8.1.1 and regarding the

SALUS LISPA DWH see D.8.2.1.

Within the following it will be described which fields are used by SALUS and how they are mapped

to the CCD templates.

Allergies-Table

Allergies are based on ICD9CM codes related to diagnosis and can be therefore transported in HL7

messages as observations. The template ids used for allergies are the following:

Template-ID: 2.16.840.1.113883.10.20.1.18 (Observation)

Template-ID: 1.3.6.1.4.1.19376.1.5.3.1.4.5 (Problem Entry)

Template-ID: 1.3.6.1.4.1.19376.1.5.3.1.4.6 (Allergies and Intolerances)

DB field Meaning of the field

Allergy.ID Primary key of the DB entry.

Allergy.PATIENT_ID Global ID of the patient

Allergy.ALLERGY_CODE_ICD9CM ICD9CM code of the allergy

Allergy.ALLERGY_DESC_ICD9CM ICD9CM description of the ICD9CM code

Allergy.START_DATE The date when the allergy was entered to the database by

the physician

Allergy.END_DATE If the allergy is not longer active. This field contains the

end date even if this is not likely to happen. SALUS-LISPA

DWH doesn't have a specific end date for an Allergy

The following example shows an observation template examples with field of the database marked

bold. As top level the registration event embedding the observation template was chosen, as this is the

deepest level also containing patient information.

<registrationEvent>

FP7-287800 SALUS


<statusCode code="active"/>

<custodian>

...

</custodian>

<subject2>


<recordTarget>

<patient>

<id root="Allergy.PATIENT_ID"/>

...

</patientPerson>

</patient>

</recordTarget>

...

<pertinentInformation3 contextConductionInd="false">

<observation classCode="OBS" moodCode="EVN" negationInd="false">

<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"/>

<templateId root="1.3.6.1.4.1.19376.1.5.3.1.4.5"/>

<id root=" Allergy.ID "/>

<code xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xsi:type="CS" code="ALG" codeSystem="2.16.840.1.113883.5.4"

codeSystemName="ObservationIntoleranceType"/>

<text>Allergy.ALLERGY_DESC_ICD9CM</text>


<effectiveTime xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xsi:type="IVL_TS">

<low value="Allergy.START_DATE"/>

<high value="Allergy.END_DATE"/>

</effectiveTime>

<value xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xsi:type="CS" code=" Allergy.ALLERGY_CODE_ICD9CM"

codeSystem="2.16.840.1.113883.6.2" codeSystemName="ICD-9-CM"

codeSystemVersion="ICD-9-CM, Volume 1&2"/>

</observation>



</subject2>


Condition-Table

This table is not used even though it was planned before. The content of this table does contain

administrative data which is not accurate on start and end date. All information which can be found in

this table is also available in ether the hospitalization table or the ambulatory table. Therefore the

condition template is fed by the ambulatory and hospitalization table

Drugs-Table

This table is containing the administrative data of the pharmacy. Therefore start and end date are not

related to the prescription and do not contain the real start end date of the intake. The start date

represents the date on which the drug was bought. The end date is estimated date at which the drug

should be completely taken based on package size and daily dosage.

The following template IDs and fields have been used of the Drugs table.

Template-ID: 2.16.840.1.113883.10.20.1.24 (Substance Administration)

Template-ID: 1.3.6.1.4.1.19376.1.5.3.1.4.7 (Medications)

Template-ID: 1.3.6.1.4.1.19376.1.5.3.1.4.7.1 (Normal Dosing)

FP7-287800 SALUS


DB field Meaning of the field

Drugs.ATC_CODE ATC code of the drug

Drugs_Code.ATC_DESC ATC code description in clear words to be read

by the physician

Drugs.ID Primary key of the database entry

Drugs.PATIENT_ID Global ID of the patient

Drugs.NUM_DDD Daily dosage of the drug as written in the

product insert

Drugs.AMOUNT_OF_DRUG_DISTRIBUTED Amount of drugs distributed in the package

Drugs.MEASURE_UNIT The unit of the drug

Drugs.DELIVERY_DATE The date the drug was bought. In CCD template

coded as start date in case of SALUS

Drugs.END_DATE_ESTIMATION The date when the last intake should take place,

depending on amount of drugs delivered and

daily dosage.

The following example shows a substance administration template examples with field of the database

marked bold. As top level the registration event embedding the substance administration template was

chosen, as this is the deepest level also containing patient information.

<registrationEvent>


<custodian>

...

</custodian>

<subject2>


<recordTarget>

<patient>

<id root="Drugs.PATIENT_ID"/>

...

</patient>

</recordTarget>

...


<substanceAdministration classCode="SBADM" moodCode="EVN">

<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"/>

<templateId root="1.3.6.1.4.1.19376.1.5.3.1.4.7.1"/>

<id root="Drugs.ID"/>

<text>Drugs_Code.ATC_DESC</text>


<effectiveTime xmlns:xsi="http://www.w3.org/2001/XMLSchema-

instance" xsi:type="IVL_TS">

<low value="Drugs.DELIVERY_DATE"/>

<high value="Drugs.END_DATE_ESTIMATION"/>

</effectiveTime>


instance" xsi:type="PIVL_TS" institutionSpecified="true" operator="A">

<period value="30.0" unit="d"/>

</effectiveTime>

<doseQuantity value="Drugs. AMOUNT_OF_DRUG_DISTREBUTED"

unit="Drugs.MEASURE_UNIT"/>

<consumable>

<administerableMaterial>

<templateId root="1.3.6.1.4.1.19376.1.5.3.1.4.7.2"/>

<templateId root="2.16.840.1.113883.10.20.1.53"/>


FP7-287800 SALUS


<code code="Drugs.ATC_CODE" codeSystem="OID_to_be_found"

codeSystemName="ATC" displayName="Drugs_Code.ATC_DESC"/>

<desc>Drugs_Code.ATC_DESC</desc>

</administerableMaterial>


</consumable>




</subject2>


Vaccination-Table

Vaccinations are a subgroup of medications and are therefore treated the same way as medications in

HL7 message format. Vaccinations are sent through IHE QED and CM as Substance Administration.

The template-IDs used are the following:

Template-ID: 2.16.840.1.113883.10.20.1.24 (Substance Administration)

Template-ID: 1.3.6.1.4.1.19376.1.5.3.1.4.7 (Medications)

Template-ID: 1.3.6.1.4.1.19376.1.5.3.1.4.7.1 (Normal Dosing)

DB field template and fields in condition template

Vaccination.ID Primary key of the database entry

Vaccination.PATIENT_ID Global ID of the patient

Vaccination.VACCINE_CODE ATC code of the vaccination

Vaccination.VACCINE_DESC ATC description of the vaccination

Vaccination.TREATMENT_DATE The date the vaccination was provided

The following example shows a substance administration template examples with field of the database

marked bold. As top level the registration event embedding the substance administration template was

chosen, as this is the deepest level also containing patient information.

<registrationEvent>


<custodian>

...

</custodian>

<subject2>


<recordTarget>

<patient>

<id root=" Vaccination.PATIENT_ID"/>

...

</patient>

</recordTarget>

...


<substanceAdministration classCode="SBADM" moodCode="EVN">

<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"/>

<templateId root="1.3.6.1.4.1.19376.1.5.3.1.4.7.1"/>

<id root=" Vaccination.ID"/>

<text>Vaccination.VACCINE_DESC</text>



instance" xsi:type="IVL_TS">

<low value="Vaccination.TREATMENT_DATE"/>

FP7-287800 SALUS


</effectiveTime>


instance" xsi:type="PIVL_TS" institutionSpecified="true" operator="A">

<period value="30.0" unit="d"/>

</effectiveTime>

<consumable>


<templateId root="1.3.6.1.4.1.19376.1.5.3.1.4.7.2"/>

<templateId root="2.16.840.1.113883.10.20.1.53"/>


<code code="Vaccination.VACCINE_CODE"

codeSystem="OID_to_be_found" codeSystemName="ATC"

displayName="Vaccination.VACCINE_DESC"/>

<desc>Vaccination.VACCINE_DESC</desc>



</consumable>




</subject2>


Hospitalization-Table

The hospitalization table and also the ambulatory table following are both transported via IHE profile

as encounters containing conditions. This leads to the fact that SALUS system is not able to

distinguish between hospitalizations and ambulatory treatment. For SALUS this is a functional

requirement. The template-IDs used for the encounters are:

Encounters:

Template-ID: 1.3.6.1.4.1.19376.1.5.3.1.4.14 (Encounter)

Template-ID: 2.16.840.1.113883.10.20.1.21 (CCD template conform)

Template-ID: 2.16.840.1.113883.5.4 (Inpatient encounter)

Conditions:



Template-ID: 2.16.840.1.113883.6.96 (SnoMed CT)

Template-ID: 2.16.840.1.113883.6.2 (ICD-9-CM)

DB field template and fields in condition

template

Hospitalization.ID Primary key of the database entry

Hospitalization.PATIENT_ID The ID of the patient

Hospitalization.PRIMARY_DIAGNOSIS_DESC_ICD9CM Primary ICD9 code of the diagnosis.

In case of SALUS handled the same

way as the side diagnosis

Hospitalization.PRIMARY_DIAGNOSIS_CODE_ICD9CM Textual description of the primary

diagnosis

Hospitalization.DATE_OF_EVENT The date the ICD9 coded diagnosis

occurred.

Hospitalization.DISCHARGE_DAY The day the patient was discharged

from hospital

Hospitalization.DIAGNOSIS_DESC1_ICD9CM Textual description of a side diagnosis

Hospitalization.DIAGNOSIS_CODE1_ICD9CM ICD9 coded description of a side

FP7-287800 SALUS


diagnosis

Hospitalization.DIAGNOSIS_DESC2_ICD9CM The day the patient was discharged

from hospital

Hospitalization.DIAGNOSIS_CODE2_ICD9CM Textual description of a side diagnosis


from hospital



from hospital



from hospital


The following example shows a encounter template examples with field of the database marked bold.

As top level the registration event embedding the encounter template was chosen, as this is the


<registrationEvent>


<custodian>

...

</custodian>

<subject2>


<recordTarget>

<patient>

<id root="Hospitalization.PATIENT_ID"/>

...

</patient>

</recordTarget>


<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="Hospitalization.ID"/>


xsi:type="CE" code="IMP" codeSystem="2.16.840.1.113883.5.4"

codeSystemName="ActEncounterCode" displayName="Inpatient"/>

<text>DATO MANCANTE</text>


xsi:type="IVL_TS"/>

<sourceOf typeCode="RSON">


<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="Hospitalization.ID" extension="0"/>


xsi:type="CS" code="Condition" codeSystem="2.16.840.1.113883.6.96"

codeSystemName="SNOMED CT" codeSystemVersion="64572001"/>

<text>Hospitalization.PRIMARY_DIAGNOSIS_DESC_ICD9CM</text>



xsi:type="IVL_TS">

<low value="Hospitalization.DATE_OF_EVENT"/>

<high value="Hospitalization.DISCHARGE_DAY"/>

</effectiveTime>

FP7-287800 SALUS



xsi:type="CS" code="Hospitalization.PRIMARY_DIAGNOSIS_CODE_ICD9CM"



</observation>

</sourceOf>

</encounter>



</subject2>


In case die information of the hospitalization table is returned on a query for observations. All ICD9

codes including the max 5 side diagnoses are returned as diagnosis. Each IDC9 code is send as an

encounter, but all in one single registration event.

Ambulatory-Table:

The ambulatory table is treated the same way as the hospitalization table for above described reasons.

However this section is presenting the mapping between ambulatory table and the template fields.

Encounters:

Template-ID: 1.3.6.1.4.1.19376.1.5.3.1.4.14 (Encounter)


Template-ID: 2.16.840.1.113883.5.4 (Inpatient encounter)

Conditions:



Template-ID: 2.16.840.1.113883.6.96 (SnoMed CT)

Template-ID: 2.16.840.1.113883.6.2 (ICD-9-CM)


Ambulatory.ID Primary key of the database entry

Ambulatory.PATIENT_ID The ID of the patient

Ambulatory.START_DATE Start date of the condition

Ambulatory.END_DATE End date of the condition

Ambulatory.DIAGNOSIS_CODE_ICD9CM Primary ICD9 code of the diagnosis. In case

of SALUS handled the same way as the side

diagnosis

Ambulatory.DIAGNOSIS_DESC_ICD9CM Textual description of the primary diagnosis

The following example shows an encounter template examples with field of the database marked

bold. As top level the registration event embedding the encounter template was chosen, as this is the


<registrationEvent>


<custodian>

...

</custodian>

<subject2>


<recordTarget>

<patient>

<id root="Ambulatory.PATIENT_ID"/>

...

</patient>

FP7-287800 SALUS


</recordTarget>


<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=" Ambulatory.ID"/>


xsi:type="CE" code="IMP" codeSystem="2.16.840.1.113883.5.4"

codeSystemName="ActEncounterCode" displayName="Inpatient"/>

<text>DATO MANCANTE</text>


xsi:type="IVL_TS"/>

<sourceOf typeCode="RSON">


<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=" Ambulatory.ID" extension="0"/>


xsi:type="CS" code="Condition" codeSystem="2.16.840.1.113883.6.96"

codeSystemName="SNOMED CT" codeSystemVersion="64572001"/>

<text> Ambulatory.DIAGNOSIS_DESC_ICD9CM</text>



xsi:type="IVL_TS">

<low value=" Ambulatory.START_DATE"/>

<high value=" Ambulatory.END_DATE"/>

</effectiveTime>


xsi:type="CS" code="Ambulatory.DIAGNOSIS_CODE_ICD9CM"



</observation>

</sourceOf>

</encounter>



</subject2>


In case die information of the ambulatory table is returned on a query for observations all

observations on a patient will be returned each in a single encounter but all in the same registration

event. It will always be one registration event per patient.

GP-Table

The GP-table is used within the conditions template. If a condition independent from hospitalization

or ambulatory case is send through the IHE profile this information is added to the encounter

information. Therefore no template ids have to be defined. This is already included by the registration

event.


Gp.FISCAL_CODE The global ID of the physician

Gp.NAME The name of the physician, due to privacy

issues always NULL

Gp.LAST_NAME The name of the physician, due to privacy

issues always NULL

Has_gp.START_DATE The point in time when the GP was in

charge for the patient

Has_gp.END_DATE The point in time when the physician was

FP7-287800 SALUS


not in charge of the patient anymore. NULL

if still is in charge

Has_gp.PATIENT_ID Global ID of the patient

The following example shows a registration event template with field of the database marked bold.

<registrationEvent>


<custodian>

...

</custodian>

<subject2>


<recordTarget>

<patient>

<id root="Has_gp.PATIENT_ID"/>

...

</patient>

</recordTarget>

<performer>

<assignedParty1>

<id extension="Gp.FISCAL_CODE"/>

<effectiveTime>

<low value="Has_gp.START_DATE"/>

<high value="Has_gp.START_END"/>

</effectiveTime>

</assignedParty1>

</performer>


</subject2>


Patient-Table

As the GP information the patient information is send as part of the registration event and is therefore

based on this template and does not use a template for separate patient information.


Patient.PATIENT_ID Global ID of the patient as also used for all other database tables

Patient.GENDER Gender of the patient which can be also UNKNOWN

Patient.DATE_OF_BIRTH Date of birth of the patient; coded in Unix time (milliseconds since

1970-01-01 00:00:000)

Patient.DATA_OF_DEATH Date of death or NULL if patient is still alive; coded in Unix time

(milliseconds since 1970-01-01 00:00:000)

The following example shows a registration event template with field of the database marked bold.

<registrationEvent>


<custodian>

...

</custodian>

<subject2>


<recordTarget>

<patient>

<id root="Patient.PATIENT_ID"/>

<addr nullFlavor="MSK"/>

<telecom nullFlavor="MSK"/>

FP7-287800 SALUS


<statusCode code="normal"/>

<patientPerson>

<name nullFlavor="MSK"/>

<administrativeGenderCode code="F" codeSystem="2.16.840.1.113883.5.1"

codeSystemName="HL7 administrative gender" displayName="Patient.GENDER"/>

<birthTime ="Patient.DATE_OF_BIRTH"/>

</patientPerson>

</patient>

</recordTarget>

<performer>

...

</performer>


</subject2>


FP7-287800 SALUS


5 CONCLUSION

Within the first two years of the project, a lot of state of the art analysis and implementation have

been made. One of the results was that using IHE profiles for communication between Data

Consumer and Data Repositories is the most common way in especially if the communication should

be established between systems of different vendors. Among these, the IHE CM profile is one of the

best fit for addressing a subscription based communication protocol between safety analysis systems

and EHR systems using the PCC-9 and PCC-10 transaction of the PCC technical framework. As this

transaction fulfils already all needs regarding the subscription to patient centred data, this one was

chosen. Next to patient centred information also population-based subscriptions have to be performed

in SALUS project. Therefore we have decided to extend the existing IHE CM transactions to carry the

HL7 Health Quality Measurement Format (HQMF) to be able to represent population-based queries.

In this extension the result data sets of this population based subscription is requested through the

HL7 CCD templates defined in Deliverable 4.1.1.

In addition to this, we have also extended the IHE CM transactions to carry not only HL7 CCD based

results sets but also EN13606 based EHR Extracts. As EN13606 does currently not define its own

transport profiles and no other transport profiles are available, it was decided to add also an EN13606

related data field to the PCC-10 transaction of the IHE CM profile. This extension should not harm

the HL7-RIM specification and will therefore just be a necessary extension to fulfil the SALUS needs.

At the end only one common subscription based profile has to be adapted by adding population based

queries and transportation of EN13606 based data to fulfil SALUS requirements.

As a result of this task the extension developed for the SALUS seems to fulfil all needs of the use

cases. The components have been developed on a theoretical basis and shown as a proof of concept.

The implementation proofs that the profile developed is working properly and will be further

evaluated during the test phase within the last project year. In principal this work package showed that

integration of EN13606 and population based query format (in this case HQMF) to IHE CM for

subscription can be done and has been successfully implemented.

d5.1.2 subscription based interoperability profiles and ... · “scalable, standard based...

Documents