d5.1.2 subscription based interoperability profiles and ... · “scalable, standard based...
TRANSCRIPT
FP7-287800 SALUS
SALUS-FP7-287800• D5.1.2 • Version 1.0, dated January 31, 2014 Page 1 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
SALUS-FP7-287800• D5.1.2 • Version 1.0, dated January 31, 2014 Page 2 of 73
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-FP7-287800• D5.1.2 • Version 1.0, dated January 31, 2014 Page 3 of 73
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
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-
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
SALUS-FP7-287800• D5.1.2 • Version 1.0, dated January 31, 2014 Page 4 of 73
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
SALUS-FP7-287800• D5.1.2 • Version 1.0, dated January 31, 2014 Page 5 of 73
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
SALUS-FP7-287800• D5.1.2 • Version 1.0, dated January 31, 2014 Page 6 of 73
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
SALUS-FP7-287800• D5.1.2 • Version 1.0, dated January 31, 2014 Page 7 of 73
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
SALUS-FP7-287800• D5.1.2 • Version 1.0, dated January 31, 2014 Page 8 of 73
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
SALUS-FP7-287800• D5.1.2 • Version 1.0, dated January 31, 2014 Page 9 of 73
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
SALUS-FP7-287800• D5.1.2 • Version 1.0, dated January 31, 2014 Page 10 of 73
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
SALUS-FP7-287800• D5.1.2 • Version 1.0, dated January 31, 2014 Page 11 of 73
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
SALUS-FP7-287800• D5.1.2 • Version 1.0, dated January 31, 2014 Page 12 of 73
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
SALUS-FP7-287800• D5.1.2 • Version 1.0, dated January 31, 2014 Page 13 of 73
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"/>
<eligibilityCriterion classCode="OBS" moodCode="CRT">
<id extension="INCL011"/>
<text>STEMI</text>
<code code=“64572001" codeSystem="2.16.840.1.113883.6.96" displayName=“Condition"/>
<value xsi:type='CD' code=‘401303003 ' codeSystem=' 2.16.840.1.113883.6.96' displayName=‘Acute ST
segment elevation myocardial infarction (disorder) '>
</eligibilityCriterion>
</precondition>
<precondition typeCode=“PRCN” >
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
SALUS-FP7-287800• D5.1.2 • Version 1.0, dated January 31, 2014 Page 14 of 73
<conjunctionCode code=“OR"/>
<eligibilityCriterion classCode="OBS" moodCode="CRT">
<id extension="INCL012"/>
<text>NSTEMI</text>
<code code=“64572001" codeSystem="2.16.840.1.113883.6.96" displayName=“Condition"/>
<value xsi:type='CD' code='401314000 ' codeSystem=' 2.16.840.1.113883.6.96' displayName=‘Acute
non-ST segment elevation myocardial infarction (disorder)'>
</eligibilityCriterion>
</precondition>
<precondition typeCode=“PRCN” >
<conjunctionCode code=“OR"/>
<eligibilityCriterion classCode="OBS" moodCode="CRT">
<id extension="INCL012"/>
<text>Unstable Angina</text>
<code code=“64572001" codeSystem="2.16.840.1.113883.6.96" displayName=“Condition"/>
<value xsi:type='CD' code=59021001' codeSystem=' 2.16.840.1.113883.6.96' displayName=‘Angina at
Rest'>
</eligibilityCriterion>
</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
SALUS-FP7-287800• D5.1.2 • Version 1.0, dated January 31, 2014 Page 15 of 73
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
5 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
SALUS-FP7-287800• D5.1.2 • Version 1.0, dated January 31, 2014 Page 16 of 73
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.
6 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
SALUS-FP7-287800• D5.1.2 • Version 1.0, dated January 31, 2014 Page 17 of 73
• 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
SALUS-FP7-287800• D5.1.2 • Version 1.0, dated January 31, 2014 Page 18 of 73
< 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
SALUS-FP7-287800• D5.1.2 • Version 1.0, dated January 31, 2014 Page 19 of 73
- 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
SALUS-FP7-287800• D5.1.2 • Version 1.0, dated January 31, 2014 Page 20 of 73
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
SALUS-FP7-287800• D5.1.2 • Version 1.0, dated January 31, 2014 Page 21 of 73
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
SALUS-FP7-287800• D5.1.2 • Version 1.0, dated January 31, 2014 Page 22 of 73
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
SALUS-FP7-287800• D5.1.2 • Version 1.0, dated January 31, 2014 Page 23 of 73
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
SALUS-FP7-287800• D5.1.2 • Version 1.0, dated January 31, 2014 Page 24 of 73
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>
<statusCode code="completed"/>
<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
SALUS-FP7-287800• D5.1.2 • Version 1.0, dated January 31, 2014 Page 25 of 73
</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>
<statusCode code="completed"/>
<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"
codeSystemName="SNOMED CT"/>
<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"
codeSystemName="SNOMED CT"/>
<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
SALUS-FP7-287800• D5.1.2 • Version 1.0, dated January 31, 2014 Page 26 of 73
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
SALUS-FP7-287800• D5.1.2 • Version 1.0, dated January 31, 2014 Page 27 of 73
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
SALUS-FP7-287800• D5.1.2 • Version 1.0, dated January 31, 2014 Page 28 of 73
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
SALUS-FP7-287800• D5.1.2 • Version 1.0, dated January 31, 2014 Page 29 of 73
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
FP7-287800 SALUS
SALUS-FP7-287800• D5.1.2 • Version 1.0, dated January 31, 2014 Page 30 of 73
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
SALUS-FP7-287800• D5.1.2 • Version 1.0, dated January 31, 2014 Page 31 of 73
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">
<device determinerCode="INSTANCE">
<id/>
<name/>
<telecom value=' ' />
<manufacturerModelName/>
<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
SALUS-FP7-287800• D5.1.2 • Version 1.0, dated January 31, 2014 Page 32 of 73
<controlActProcess moodCode="RQO">
<id root=' ' extension=' '/>
<code code='QUPC_TE043100UV'/>
<effectiveTime value=' '/>
<languageCode code=' '/>
<authorOrPerformer typeCode=' '></authorOrPerformer>
<queryByParameter>
<id root=' ' extension=' '/>
<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>
</controlActProcess>
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>
</QualityMeasureDocument>
…
</QualityMeasureDocument>
<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
SALUS-FP7-287800• D5.1.2 • Version 1.0, dated January 31, 2014 Page 33 of 73
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
SALUS-FP7-287800• D5.1.2 • Version 1.0, dated January 31, 2014 Page 34 of 73
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">
<id root=' ' extension=' '/>
<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">
<device determinerCode="INSTANCE">
<id/>
<name/>
<telecom value=' ' />
FP7-287800 SALUS
SALUS-FP7-287800• D5.1.2 • Version 1.0, dated January 31, 2014 Page 35 of 73
<manufacturerModelName/>
<softwareName/>
</device>
</receiver>
<sender typeCode="SND">
<device determinerCode="INSTANCE">
<id/>
<name/>
<telecom value=' ' />
<manufacturerModelName/>
<softwareName/>
</device>
</sender>
<controlActProcess>
See Control Act Wrapper below
</controlActProcess>
</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">
<id root=' ' extension=' '/>
<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>
</controlActProcess>
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
SALUS-FP7-287800• D5.1.2 • Version 1.0, dated January 31, 2014 Page 36 of 73
<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>
<!-- Domain Content -->
</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
SALUS-FP7-287800• D5.1.2 • Version 1.0, dated January 31, 2014 Page 37 of 73
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
SALUS-FP7-287800• D5.1.2 • Version 1.0, dated January 31, 2014 Page 38 of 73
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
SALUS-FP7-287800• D5.1.2 • Version 1.0, dated January 31, 2014 Page 39 of 73
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
SALUS-FP7-287800• D5.1.2 • Version 1.0, dated January 31, 2014 Page 40 of 73
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
SALUS-FP7-287800• D5.1.2 • Version 1.0, dated January 31, 2014 Page 41 of 73
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
SALUS-FP7-287800• D5.1.2 • Version 1.0, dated January 31, 2014 Page 42 of 73
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
SALUS-FP7-287800• D5.1.2 • Version 1.0, dated January 31, 2014 Page 43 of 73
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
SALUS-FP7-287800• D5.1.2 • Version 1.0, dated January 31, 2014 Page 44 of 73
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
SALUS-FP7-287800• D5.1.2 • Version 1.0, dated January 31, 2014 Page 45 of 73
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
SALUS-FP7-287800• D5.1.2 • Version 1.0, dated January 31, 2014 Page 46 of 73
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
SALUS-FP7-287800• D5.1.2 • Version 1.0, dated January 31, 2014 Page 47 of 73
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
SALUS-FP7-287800• D5.1.2 • Version 1.0, dated January 31, 2014 Page 48 of 73
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
SALUS-FP7-287800• D5.1.2 • Version 1.0, dated January 31, 2014 Page 49 of 73
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
SALUS-FP7-287800• D5.1.2 • Version 1.0, dated January 31, 2014 Page 50 of 73
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
SALUS-FP7-287800• D5.1.2 • Version 1.0, dated January 31, 2014 Page 51 of 73
Figure 23: Schema of the SALUS data warehouse at LISPA
FP7-287800 SALUS
SALUS-FP7-287800• D5.1.2 • Version 1.0, dated January 31, 2014 Page 52 of 73
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
SALUS-FP7-287800• D5.1.2 • Version 1.0, dated January 31, 2014 Page 53 of 73
Address x(o)
Investigation number x (o)
Table 1: SALUS data requirements for EHR Section: “Patient” – Mapping to SALUS LISPA DWH
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
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
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
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
SALUS-FP7-287800• D5.1.2 • Version 1.0, dated January 31, 2014 Page 54 of 73
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
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
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
SALUS-FP7-287800• D5.1.2 • Version 1.0, dated January 31, 2014 Page 55 of 73
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
is the diagnosis sub-
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
Describes the date of
occurrence.
End Date x x (o) x x x x (o)
AMBULATORY.END_DATE; HOSPITALIZATION.DISCHARGE_DAY
The date the condition
was noted to be ended
Problem Status x x (o) x
Depending on start and end date it is “active” or “inactive”
Date of Entry x x
HOSPITALIZATION.INSERT_DATE; AMBULATORY.INSERT_DATE
Describes the day the entry was made
Related Encounter x x
FP7-287800 SALUS
SALUS-FP7-287800• D5.1.2 • Version 1.0, dated January 31, 2014 Page 56 of 73
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
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
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
is the diagnosis sub-
hierarchy of ICD-9-
CM consisting of
FP7-287800 SALUS
SALUS-FP7-287800• D5.1.2 • Version 1.0, dated January 31, 2014 Page 57 of 73
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
AMBULATORY.START_DATE; HOSPITALIZATION.DATE_OF_EVENT
Describes the date of
occurrence.
Severity x (o)
x (o) (seriousness)
Date of end of reaction/event x (o) x (o)
AMBULATORY.END_DATE; HOSPITALIZATION.DISCHARGE_DAY
The date the condition
was noted to be ended
Outcome of reaction/event at the time of last observation x (o) x (o)
Date of Entry x x
HOSPITALIZATION.INSERT_DATE; AMBULATORY.INSERT_DATE
Describes the day the entry was made
Table 5: SALUS data requirements for EHR Section: “Allergies/Intolerances” – Mapping to SALUS
LISPA DWH
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
Kinship Type x (o)
Family History x (o)
FP7-287800 SALUS
SALUS-FP7-287800• D5.1.2 • Version 1.0, dated January 31, 2014 Page 58 of 73
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
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
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 Encounter 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
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
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
SALUS-FP7-287800• D5.1.2 • Version 1.0, dated January 31, 2014 Page 59 of 73
ON.START_DATE; AMBULATORY.START_DATE
Procedure Status x (o)
Indication x (o)
Related Encounter 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
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
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
SALUS-FP7-287800• D5.1.2 • Version 1.0, dated January 31, 2014 Page 60 of 73
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.
Related Encounter x (o)
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
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
Start Date x x
AMBULATORY.START_DATE; HOSPITALIZATION.DATE_OF_EVENT
Describes the date of
occurrence.
End Date x x AMBULA The date the condition
was noted to be ended
FP7-287800 SALUS
SALUS-FP7-287800• D5.1.2 • Version 1.0, dated January 31, 2014 Page 61 of 73
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
is the diagnosis sub-
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
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
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
SALUS-FP7-287800• D5.1.2 • Version 1.0, dated January 31, 2014 Page 62 of 73
Result Interpretation x
Related Encounter x (o)
Related Condition x (o)
Result Provider x (o)
Table 11: SALUS data requirements for EHR Section: “Vital Signs” – Mapping to SALUS LISPA DWH
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
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
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
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
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
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
SALUS-FP7-287800• D5.1.2 • Version 1.0, dated January 31, 2014 Page 63 of 73
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
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
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
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
SALUS-FP7-287800• D5.1.2 • Version 1.0, dated January 31, 2014 Page 64 of 73
<statusCode code="active"/>
<custodian>
...
</custodian>
<subject2>
<careProvisionEvent>
<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>
<statusCode code="active"/>
<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&amp;2"/>
</observation>
</pertinentInformation3>
</careProvisionEvent>
</subject2>
</registrationEvent>
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
SALUS-FP7-287800• D5.1.2 • Version 1.0, dated January 31, 2014 Page 65 of 73
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>
<statusCode code="active"/>
<custodian>
...
</custodian>
<subject2>
<careProvisionEvent>
<recordTarget>
<patient>
<id root="Drugs.PATIENT_ID"/>
...
</patient>
</recordTarget>
...
<pertinentInformation3 contextConductionInd="false">
<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>
<statusCode code="completed"/>
<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>
<effectiveTime xmlns:xsi="http://www.w3.org/2001/XMLSchema-
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"/>
<administerableMaterial>
FP7-287800 SALUS
SALUS-FP7-287800• D5.1.2 • Version 1.0, dated January 31, 2014 Page 66 of 73
<code code="Drugs.ATC_CODE" codeSystem="OID_to_be_found"
codeSystemName="ATC" displayName="Drugs_Code.ATC_DESC"/>
<desc>Drugs_Code.ATC_DESC</desc>
</administerableMaterial>
</administerableMaterial>
</consumable>
</substanceAdministration>
</pertinentInformation3>
</careProvisionEvent>
</subject2>
</registrationEvent>
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>
<statusCode code="active"/>
<custodian>
...
</custodian>
<subject2>
<careProvisionEvent>
<recordTarget>
<patient>
<id root=" Vaccination.PATIENT_ID"/>
...
</patient>
</recordTarget>
...
<pertinentInformation3 contextConductionInd="false">
<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>
<statusCode code="completed"/>
<effectiveTime xmlns:xsi="http://www.w3.org/2001/XMLSchema-
instance" xsi:type="IVL_TS">
<low value="Vaccination.TREATMENT_DATE"/>
FP7-287800 SALUS
SALUS-FP7-287800• D5.1.2 • Version 1.0, dated January 31, 2014 Page 67 of 73
</effectiveTime>
<effectiveTime xmlns:xsi="http://www.w3.org/2001/XMLSchema-
instance" xsi:type="PIVL_TS" institutionSpecified="true" operator="A">
<period value="30.0" unit="d"/>
</effectiveTime>
<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"/>
<administerableMaterial>
<code code="Vaccination.VACCINE_CODE"
codeSystem="OID_to_be_found" codeSystemName="ATC"
displayName="Vaccination.VACCINE_DESC"/>
<desc>Vaccination.VACCINE_DESC</desc>
</administerableMaterial>
</administerableMaterial>
</consumable>
</substanceAdministration>
</pertinentInformation3>
</careProvisionEvent>
</subject2>
</registrationEvent>
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.10.20.1.28 (CCD template conform)
Template-ID: 1.3.6.1.4.1.19376.1.5.3.1.4.5 (Problem Entry)
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
SALUS-FP7-287800• D5.1.2 • Version 1.0, dated January 31, 2014 Page 68 of 73
diagnosis
Hospitalization.DIAGNOSIS_DESC2_ICD9CM The day the patient was discharged
from hospital
Hospitalization.DIAGNOSIS_CODE2_ICD9CM Textual description of a side diagnosis
Hospitalization.DIAGNOSIS_DESC3_ICD9CM The day the patient was discharged
from hospital
Hospitalization.DIAGNOSIS_CODE3_ICD9CM Textual description of a side diagnosis
Hospitalization.DIAGNOSIS_DESC4_ICD9CM The day the patient was discharged
from hospital
Hospitalization.DIAGNOSIS_CODE4_ICD9CM Textual description of a side diagnosis
Hospitalization.DIAGNOSIS_DESC5_ICD9CM The day the patient was discharged
from hospital
Hospitalization.DIAGNOSIS_CODE5_ICD9CM Textual description of a side diagnosis
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
deepest level also containing patient information.
<registrationEvent>
<statusCode code="active"/>
<custodian>
...
</custodian>
<subject2>
<careProvisionEvent>
<recordTarget>
<patient>
<id root="Hospitalization.PATIENT_ID"/>
...
</patient>
</recordTarget>
<pertinentInformation3 contextConductionInd="false">
<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"/>
<code xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="CE" code="IMP" codeSystem="2.16.840.1.113883.5.4"
codeSystemName="ActEncounterCode" displayName="Inpatient"/>
<text>DATO MANCANTE</text>
<effectiveTime xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="IVL_TS"/>
<sourceOf typeCode="RSON">
<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="Hospitalization.ID" extension="0"/>
<code xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
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>
<statusCode code="active"/>
<effectiveTime xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="IVL_TS">
<low value="Hospitalization.DATE_OF_EVENT"/>
<high value="Hospitalization.DISCHARGE_DAY"/>
</effectiveTime>
FP7-287800 SALUS
SALUS-FP7-287800• D5.1.2 • Version 1.0, dated January 31, 2014 Page 69 of 73
<value xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="CS" code="Hospitalization.PRIMARY_DIAGNOSIS_CODE_ICD9CM"
codeSystem="2.16.840.1.113883.6.2" codeSystemName="ICD-9-CM"
codeSystemVersion="ICD-9-CM, Volume 1&amp;2"/>
</observation>
</sourceOf>
</encounter>
</pertinentInformation3>
</careProvisionEvent>
</subject2>
</registrationEvent>
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.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.10.20.1.28 (CCD template conform)
Template-ID: 1.3.6.1.4.1.19376.1.5.3.1.4.5 (Problem Entry)
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
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
deepest level also containing patient information.
<registrationEvent>
<statusCode code="active"/>
<custodian>
...
</custodian>
<subject2>
<careProvisionEvent>
<recordTarget>
<patient>
<id root="Ambulatory.PATIENT_ID"/>
...
</patient>
FP7-287800 SALUS
SALUS-FP7-287800• D5.1.2 • Version 1.0, dated January 31, 2014 Page 70 of 73
</recordTarget>
<pertinentInformation3 contextConductionInd="false">
<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"/>
<code xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="CE" code="IMP" codeSystem="2.16.840.1.113883.5.4"
codeSystemName="ActEncounterCode" displayName="Inpatient"/>
<text>DATO MANCANTE</text>
<effectiveTime xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="IVL_TS"/>
<sourceOf typeCode="RSON">
<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=" Ambulatory.ID" extension="0"/>
<code xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="CS" code="Condition" codeSystem="2.16.840.1.113883.6.96"
codeSystemName="SNOMED CT" codeSystemVersion="64572001"/>
<text> Ambulatory.DIAGNOSIS_DESC_ICD9CM</text>
<statusCode code="active"/>
<effectiveTime xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="IVL_TS">
<low value=" Ambulatory.START_DATE"/>
<high value=" Ambulatory.END_DATE"/>
</effectiveTime>
<value xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="CS" code="Ambulatory.DIAGNOSIS_CODE_ICD9CM"
codeSystem="2.16.840.1.113883.6.2" codeSystemName="ICD-9-CM"
codeSystemVersion="ICD-9-CM, Volume 1&amp;2"/>
</observation>
</sourceOf>
</encounter>
</pertinentInformation3>
</careProvisionEvent>
</subject2>
</registrationEvent>
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.
DB field template and fields in condition template
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
SALUS-FP7-287800• D5.1.2 • Version 1.0, dated January 31, 2014 Page 71 of 73
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>
<statusCode code="active"/>
<custodian>
...
</custodian>
<subject2>
<careProvisionEvent>
<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>
</careProvisionEvent>
</subject2>
</registrationEvent>
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.
DB field template and fields in condition template
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>
<statusCode code="active"/>
<custodian>
...
</custodian>
<subject2>
<careProvisionEvent>
<recordTarget>
<patient>
<id root="Patient.PATIENT_ID"/>
<addr nullFlavor="MSK"/>
<telecom nullFlavor="MSK"/>
FP7-287800 SALUS
SALUS-FP7-287800• D5.1.2 • Version 1.0, dated January 31, 2014 Page 72 of 73
<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>
</careProvisionEvent>
</subject2>
</registrationEvent>
FP7-287800 SALUS
SALUS-FP7-287800• D5.1.2 • Version 1.0, dated January 31, 2014 Page 73 of 73
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.