d4.1.2 salus content models for the functional interoperability … · 2017-04-17 · salus d4.1.2...

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 D4.1.2 SALUS Content models for the

Functional Interoperability Profiles for Post Market

Safety Studies – 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: ERS

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

Dissemination Level

PU Public X

PP Restricted to other programme participants (including the Commission Services) RE Restricted to a group specified by the consortium (including the Commission Services) CO Confidential, only for members of the consortium (including the Commission Services)

FP7-287800 SALUS

SALUS-FP7-287800 • D4.1.2 • Version 1.4, dated January 28, 2014 of 90

Document History:

Version Date Changes From Review

v0.1 2013-10-28 SRDC and ROCHE initial input for the

content models used in ROCHE Pilot

application

SRDC, ROCHE ERS

V1.0 2014-01-07 ERS updated Section 7 ERS SRDC

V1.1 2014-01-08 SRDC Reviewed, formatted the document,

updated executive summary and

introduction

SRDC All partners

V1.2 2014-01-14 AGFA Input for Section 9 AGFA ERS

V1.3 2014-01-23 LISPA INPUT LISPA -

V1.4 2014-01-23 SRDC updated the data element mappings

based on the 2nd release of SALUS

Common Data Elements

SRDC All partners

Contributors(Benef.) Gerard Freriks (ERS)

Gokce Banu Laleci Erturkmen (SRDC)

Ali Anil Sinaci (SRDC)

Tomas Bergvall (UMC)

Tobias Krahn (OFFIS)

Gunnar Declerck (INSERM)

Hans Cools (ROCHE)

Hong Sun (AGFA)

ResponsibleAuthor Gerard Freriks Email [email protected]

Beneficiary ERS Phone +31620347088

FP7-287800 SALUS


SALUS Consortium Contacts:

Beneficiary Name Phone Fax E-Mail

SRDC Gokce Banu Laleci

Erturkmen

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

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

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

OFFIS Wilfried Thoben

+49-441-9722131

+49-441-9722111

[email protected]

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

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

LISPA Davide Rovera +3902393311 +39 02 39331207 [email protected]

INSERM Marie-Christine Jaulent +33142346983 +33153109201 marie-

[email protected]

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

dresden.de

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

FP7-287800 SALUS


EXECUTIVE SUMMARY

This Deliverable aims to define content models, i.e. standard based specifications of message

payloads that are exchanged through the transactions between EHR Systems and tools supporting

patient safety within the scope of selected SALUS Pilot applications. This is the first task to be

coordinated for SALUS semantic interoperability architecture: it is an effort to understand the

information requirements for the selected SALUS use cases and the respective transactions.

Within the scope of SALUS Pilot applications, we aim to enable querying and subscription of subsets

of medical summaries from EHR Systems and supporting data warehouses, and provide these

collected medical data sets to specialized SALUS Pilot applications for running Adverse Drug Event

(ADE) notification, safety analysis methods and Individual Case Safety Report (ICSR) reporting

tools. While collecting the medical summaries from underlying EHR Systems, we have chosen to

comply with well-defined EHR interface standards, namely HL7 Clinical Document Architecture

Release 2 (CDA) based templates, and ISO/CEN EN 13606 EHRExtract based archetypes and

templates. On top of this, we also allow EHR Systems to open up SPARQL endpoints to expose

anonymized medical data sets. On the research side, each of these applications and methods presented

above may require to retrieve medical data sets in different formats. Based on our initial analysis in

D8.1.1, Temporal Pattern Discovery, Temporal Association Screening and Patient History tools prefer

to retrieve data in conformance to Observational Medical Outcomes Partnership (OMOP) Common

Data Model (CDM)1, while ICSR Reporting tool produces case safety reports in E2B(R2)2

specifications along with local models like the ICSR template provided by Italian Medicines Agency

(AIFA) which slightly differs from E2B. These templates and data models used at the EHR side and

by the tools to analyse them at the research side constitute the SALUS Content Model Library. The

objective of this deliverable is to formally define the contents of this library.

The first version of D4.1.1 covers two content models at the EHRs side, and two content models at

the clinical research side (based on the requirements set in D8.1.1 and in our DoW):

We have defined content model templates as HL7 CDA templates. One of our pilot sites,

Lombardy Region exposes medical summaries as HL7 CDA documents. These templates are

provided in Section 4.

We have defined an archetype library, and an EHRExtract template that makes use of these

archetypes to represent medical data sets in ISO/CEN EN 13606 format. Although we will

not have a physical pilot site that will produce and share medical data sets in EN 13606

format, based on the principles set in SALUS DoW, we have produced these templates and

will demonstrate that SALUS System, in particular the semantic interoperability framework,

is capable of processing these and can prepare medical data sets that can be consumed by

SALUS clinical research applications. This archetype library and the EHRExtract template

are introduced in Section 7.

As several of the clinical research applications that have been developed in SALUS pilots

would like to receive medical datasets in OMOP CDM format, in Section 5, OMOP CDM is

introduced and examined.

SALUS ICSR Reporting Tool supports semi-automatic reporting of ADEs to regulatory

authorities using the ICH E2B(R2) Electronic Transmission of Individual Case Safety

1 http://omop.fnih.org/CDMvocabV4

2 ICH guideline E2B (R2), Electronic transmission of individual case safety reports - Message specification

(ICH ICSR DTD Version 2.1), Final Version 2.3, Document Revision Feb. 1, 2001.

FP7-287800 SALUS


Reports Message Specification. For this reason as one of the target content models, E2B(R2)

model is introduced and examined in Section 6. The second release of the Deliverable, namely D4.1.2 built on top of D4.1.1. The following updates,

additions are made in the second reporting period:

The SALUS archetype library has been updated. SALUS archetypes are based on the

CEN/ISO 13606 EHR communication standard. ERS B.V. has developed a method for the

production of archetypes (SIAMM: Semantic Interoperability Artefact Modelling Method).

Early 2013 SIAMM Release 2 has been produced. The present SALUS archetypes conform to

this modelling method. Based on the updated 13606 archetype library, Section 7 is rewritten,

and Appendix 4 is updated. It consists of various human and machine readable exports

produced using the most recent Link-EHR editor The exports include FreeMind Map, Excel,

HTML, ADL1.4, Schematron, XML Data Instantiation.

The content models used in the ROCHE Pilot, namely the Post Marketing Safety Study Tool,

are described in Section 8. In this section the selected standards such as CDISC SDTM, and

Define.XML are briefly described, then the definition of the data collection set through

SDTM variables and the selected terminology system codes is presented.

In Section 9, the local semantic model used in one of our EHRs sources, UKD-TUD, i.e.

ORBIS RDF model is introduced briefly.

FP7-287800 SALUS


TABLE OF CONTENTS

1 PURPOSE ......................................................................................................................................... 7 2 REFERENCE DOCUMENTS ......................................................................................................... 7

2.1 Definitions and Acronyms ........................................................................................................ 7 3 Introduction ...................................................................................................................................... 8

3.1 Data Requirements of SALUS Pilot Application Scenarios ................................................... 11 4 HL7 CDA BASED TEMPLATES ................................................................................................. 15

4.1 Entry Content Modules ........................................................................................................... 15 4.1.1 Conditions ........................................................................................................................ 15 4.1.2 Coded Results .................................................................................................................. 17 4.1.3 Procedures ........................................................................................................................ 20 4.1.4 Allergies & Intolerances .................................................................................................. 21 4.1.5 Medications ...................................................................................................................... 23 4.1.6 Encounters........................................................................................................................ 25 4.1.7 Family History ................................................................................................................. 26 4.1.8 Social History................................................................................................................... 27 4.1.9 Demographics .................................................................................................................. 28 4.1.10 Pregnancies .................................................................................................................... 30 4.1.11 Immunizations................................................................................................................ 31

5 OMOP CDM BASED CONTENT MODEL TEMPLATES .......................................................... 34 5.1 OMOP CDM Tables and Mapping to Common Data Elements ............................................. 35

5.1.1 Person ............................................................................................................................... 35 5.1.2 Drug Exposure ................................................................................................................. 37 5.1.3 Condition Occurrence ...................................................................................................... 40 5.1.4 Visit Occurrence .............................................................................................................. 42 5.1.5 Procedure Occurrence ...................................................................................................... 43 5.1.6 Observation ...................................................................................................................... 45 5.1.7 Observation Period ........................................................................................................... 50 5.1.8 Death ................................................................................................................................ 51 5.1.9 Location ........................................................................................................................... 52 5.1.10 Provider .......................................................................................................................... 52 5.1.11 Organisation ................................................................................................................... 53 5.1.12 Care Site ......................................................................................................................... 54

6 ICH E2B(R2) SPECIFICATION BASED CONTENT MODEL TEMPLATES........................... 56 1.1 E2B(R2) sections and Mapping to Common Data Elements .................................................. 57

1.1.1 Patient characteristics. Demographics (B.1.1 to B.1.6) ................................................... 58 1.1.2 Relevant medical history and concurrent conditions (B1.7) ............................................ 59 1.1.3 Relevant past drug history (B1.8) .................................................................................... 60 1.1.4 Reaction(s)/event(s) (B.2) ................................................................................................ 60 1.1.5 Results of tests and procedures relevant to the investigation of the patient (B.3) ........... 61 1.1.6 Drug(s) information (B.4) ................................................................................................ 62

7 SALUS 13606 ARCHETYPE LIBRARY ...................................................................................... 63 7.1 EN13606 Archetype Library ................................................................................................... 65

7.1.1 EN13606 Artefacts Introduction ...................................................................................... 65 7.1.2 Source Generic Artefacts/SIAMM................................................................................... 67 7.1.3 Archetype Libraries used in SALUS Template ............................................................... 70 7.1.4 SALUS Specialised Generic Artefacts and SALUS COMPOSITION Template ............ 70

8 CONTENT MODULES to be used in ROCHE Scenario............................................................... 73 8.1 CDISC Study Data Tabulation Model (SDTM) and Define.xml ............................................ 74 8.2 Definition of Data Collection set through SDTM variables and Terminology System codes 75

9 ORBIS CONTENT ENTITY MODELS ........................................................................................ 83

FP7-287800 SALUS


9.1 Diagnosis ................................................................................................................................. 83 9.2 Medication ............................................................................................................................... 85

9.2.1 Prescription Form – Rezept neu ....................................................................................... 86 9.2.2 Medikament Form – Medikamentenliste_PO_ABDA9636 ............................................. 88

1 PURPOSE

The purpose of this deliverable is to define content models, i.e. standard based specifications of

message payloads that are being exchanged through the transactions between EHR Systems and tools

supporting patient safety within the scope of selected SALUS Pilot applications.

2 REFERENCE DOCUMENTS

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

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)

Implementation Guide for CDA Release 2.0, Consolidated CDA Templates, December 2011

IHE Patient Care Coordination Technical Framework (PCC TF) CDA R2 Content Modules

Observational Medical Outcomes Partnership (OMOP) Common Data Model (CDM)

specifications

ICH E2B(R2) Electronic Transmission of Individual Case Safety Reports Message

Specification

CEN/ISO 13940 System of Concepts for Continuity of Care

CEN/ISO ISO 13606-1:2008 Health informatics -- Electronic health record communication

2.1 Definitions and Acronyms

Table 1 List of Abbreviations and Acronyms

Abbreviation/

Acronym DEFINITION

13606 CEN/ISO 13606 EHR-Communication standard

ADE Adverse Drug Event

AIFA Italian Medicines Agency

CCD Continuity of Care Document

CDA Clinical Document Architecture

CDE Common Data Elements

FP7-287800 SALUS


Abbreviation/

Acronym DEFINITION

13606 CEN/ISO 13606 EHR-Communication standard

ADE Adverse Drug Event

AIFA Italian Medicines Agency

CCD Continuity of Care Document

CEN European Committee for Standardization

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

DWH Data warehouse

E2B (R2) ICH message standard based on HL7 for Individual Case Safety Reports

EMA The European Medicines Agency

FDA Food and Drug Administration

HISA CEN/ISO Health Information Services Architecture

HL7 Health Level Seven

ICSR Individual Case Safety Report

ISO International Standardisation Organisation

MDR Metadata Registry

OMOP Observational medical Outcomes Partnership

OMOP CDM Observational medical Outcomes Partnership - Common Data Model

PCC Patient Care Coordination

SIAMM Semantic Interoperability Artefact Modeling Method

3 Introduction

Task 4.1 aims to define content models, i.e. standard based specifications of message payloads that

are being exchanged through the transactions between EHR Systems and tools supporting patient

safety within the scope of selected SALUS Pilot applications. This is the first task coordinated for

SALUS semantic interoperability architecture: it is an effort to understand the information

requirements for the selected SALUS use cases and the respective transactions.

Task 4.1 activities have been initiated by examining the pilot application descriptions presented in

Deliverable 8.1.1: Pilot Application Scenario and Requirement Specifications of the Pilot Application.

Within the scope of SALUS Pilot applications, we aim to enable querying and subscription of subsets

of medical summaries from EHR Systems and supporting data warehouses (through the Technical

Interoperability Profiles (WP5) and Semantic Interoperability Platform (Task 4.4)), and provide these

collected medical data sets to specialized SALUS Pilot applications for running Adverse Drug Event

(ADE) notification, safety analysis methods and Individual Case Safety Report (ICSR) reporting

tools. The list of tools to be developed for supporting patient safety that re-use the medical data sets

collected in EHRs are as follows:

ADE Notification Tool: The SALUS ADE Notification Tool analyses clinical events within

an EHR to detect potential ADEs.

ICSR Reporting Tool: This Tool enables filling of ICSR forms by querying the necessary

fields from the underlying EHRs. It can be automatically triggered by the ADE Notification

Tool, or initiated manually.

FP7-287800 SALUS


Case Series Characterization Tool: This tool enables querying Data Sources for EHR extracts

of selected patient populations to characterize ADE cases that originate from SALUS EHR

data and compare the statistics against a custom background population.

Temporal Pattern Discovery Tool: This tool enables subscription to Data Sources for

collecting the EHR extracts of selected patient populations for temporal pattern

characterization of a drug of interest and a medication of interest to visualize the association

between a medication and an event.

Temporal Association Screening Tool: This tool enables subscription to Data Sources for

EHR extracts of selected patient populations for exploratory temporal association screening

analysis between adverse drug events and prescriptions.

Post Marketing Safety Study Tool: This tool enables querying Data Sources for EHR extracts

of selected patient populations to realize patient cohort studies.

Please see SALUS Deliverable 3.3.1 (Requirement Specification of the SALUS Architecture) and

3.4.1(Conceptual Design of the SALUS Architecture) for more detailed descriptions of these tools.

While collecting the medical summaries from underlying EHR Systems, we have chosen to comply

with well-defined EHR interface standards, namely HL7 Clinical Document Architecture Release 2

(CDA) based templates, and ISO/CEN EN 13606 EHRExtract based archetypes and templates. HL7

CDA based templates are being used in one of our pilot sites, LISPA, On top of this, we also allow

EHR Systems to open up SPARQL endpoints to expose anonymized medical data sets. In particular,

our second EHR source, UKD-TUD chooses this option, and a SPARQL endpoint is implemented on

top of the ORBIS installation at TUD. On the research side, each of these applications and methods

presented above may require to retrieve medical data sets in different formats. Temporal Pattern

Discovery, Temporal Association Screening and Patient History tools prefer to retrieve data in

conformance to Observational Medical Outcomes Partnership (OMOP) Common Data Model

(CDM)3, while ICSR Reporting tool produces case safety reports in E2B(R2)4 specifications along

with local models like the ICSR template provided by Italian Medicines Agency (AIFA). PMSST tool

uses CDISC SDTM variables to define data collection sets. These templates and data models used at

the EHR side and by the tools to analyse them at the research side constitute the SALUS Content

Model Library. The objective of this deliverable is to formally define the contents of this library.

The first version of D4.1.1 covers two content models at the EHRs side, and two content models at

the clinical research side (based on the requirements set in D8.1.1 and in our DoW):

We have defined content model templates as HL7 CDA templates. One of our pilot sites,

Lombardy Region exposes medical summaries as HL7 CDA documents. These templates are

provided in Section 4.

We have defined an archetype library, and an EHRExtract template that makes use of these

archetypes to represent medical data sets in ISO/CEN EN 13606 format. Although we will

not have a physical pilot site that will produce and share medical data sets in EN 13606

format, based on the principles set in SALUS DoW, we have produced these templates and

will demonstrate that SALUS System, in particular the semantic interoperability framework,

is capable of processing these and can prepare medical data sets that can be consumed by

SALUS clinical research applications. This archetype library and the EHRExtract template

are introduced in Section 7.

As several of the clinical research applications that have been developed in SALUS pilots

would like to receive medical datasets in OMOP CDM format, in Section 5, OMOP CDM is

introduced and examined.

SALUS ICSR Reporting Tool supports semi-automatic reporting of ADEs to regulatory

authorities using the ICH E2B(R2) Electronic Transmission of Individual Case Safety

3 http://omop.fnih.org/CDMvocabV4

4 ICH guideline E2B (R2), Electronic transmission of individual case safety reports - Message specification

(ICH ICSR DTD Version 2.1), Final Version 2.3, Document Revision Feb. 1, 2001.

FP7-287800 SALUS


Reports Message Specification. For this reason as one of the target content models, E2B(R2)

model is introduced and examined in Section 6. The second release of the Deliverable, namely D4.1.2 built on top of D4.1.1. The following updates,

additions are made in the second reporting period:

The SALUS archetype library is updated. SALUS archetypes are based on the

CEN/ISO 13606 EHR communication standard. ERS B.V. has developed a method for the

production of archetypes (SIAMM: Semantic Interoperability Artefact Modelling Method).

Since early 2013 SIAMM Release 2 has been produced. The present SALUS archetypes

conform to this modelling method. Based on the updated 13606 archetype library, Section 7

is rewritten, and Appendix 4 is updated. It consists of various human and machine readable

exports produced using the most recent Link-EHR editor The exports include FreeMind Map,

Excel, HTML, ADL1.4, Schematron, XML Data Instantiation.

The content models used in the ROCHE Pilot, namely the Post Marketing Safety

Study Tool, are described in Section 8. In this section the selected standards such as CDISC

SDTM, and Define.XML are briefly described, then the definition of the data collection set

through SDTM variables and the selected terminology system codes is presented.

In Section 9, the local semantic model used in TUD, i.e. ORBIS RDF model is

introduced briefly.

In D8.1.1 for each pilot application scenario, the data requirements of each pilot scenario, i.e. the data

that needs to be collected from the underlying EHRs have been verbally identified. While defining the

content model templates at the EHRs side, i.e. HL7 CDA templates and EN 13606 archetype library,

we have analysed these data requirements and designed the templates and archetypes that would allow

us to represent sections and entries in a medical summary document to carry these data sets. For this,

these data requirements that have been verbally presented in D8.1.1 have been analysed, and we have

created a table to list these data requirements in a tabular form. This table is presented in Section 3.1,

where data elements are organized in data objects, and the requirements of each SALUS pilot

application have been marked as “required” or “optional”. This initial data model consisting of data

elements bound to data objects is in fact a first attempt to create the list of Common Data Elements

that are being used in SALUS Pilot application, hence Task 4.1 and Task 4.2 (which aims to deliver

SALUS Common Data Element List) have worked in parallel in cooperation with each other. In

Deliverable 4.2.1, and D4.2.2 a formal definition of these Common Data Elements has been provided

in conformance to ISO/IEC 11179 Meta Model5.

While the content models are being developed, this table introducing the first list of SALUS Common

Data Elements is used as an input. In addition to this, while entry level CDA templates are presented

in Section 4.1, the matching CDA attributes to the initial set of SALUS Common Data Elements are

clearly marked by providing an XPATH expression for each Common Data Element. Similarly, this

SALUS Common Data element table has been used while SALUS archetype library is created.

While OMOP CDM and E2B(R) are presented, mappings to SALUS Common Data Elements are

separately analysed and presented in sections 5.1 and 6.1 respectively. Finally for both of these

models, mappings to HL7 CDA based content models are provided as a guidance to the semantic

mediation tools to be developed in Task 4.4 (Developing the Semantic Mediation Framework), that

processes and translates medical summaries in HL7 CDA documents to these content models (OMOP

CDM and E2B(R)) used by ICSR reporting and clinical safety analysis tools. These are presented in a

separate spread sheet (presented as Appendix 1) introducing the mappings of both OMOP CDM and

E2B(R) models to HL7 CDA based content models.

5 ISO/IEC 11179, Information Technology -- Metadata registries (MDR), http://metadata-standards.org/11179/

FP7-287800 SALUS


3.1 Data Requirements of SALUS Pilot Application Scenarios Legend: x =Required, x(o)= Optional

Selected SALUS Scenarios/Related EHR Sections

Selected SALUS Scenarios/Related EHR Data Items

Enabling Notification of Suspected ADEs

Enabling Semi-automatic ADE Reporting

Characterizing the cases and contrasting them to a background population

Temporal pattern characterization

Running Exploratory Analysis Studies over EHRs for Signal Detection

Calculating incidence rates of CHF in diabetic patients with a recent acute coronary syndrome (ACS) event)

Patient Patient Name or Initials x (o)

ID

x (o)(Pseudonym)

Date of Birth x

x (Age is to be derived)

x (Year of Birth is Adequate)



Gender x x (o) x x x

Race x (o) x (o)

Birth Place (Region or City)

Patient registration date x (o)

Patient de-registration date x (o)

Ethnicity x(o) x(o)

Provider ID x(o)

Provider Organisation ID x(o)

Address x(o)

Investigation number x (o)

Pregnancy YES/NO x (o)

Delivery Date x (o)

Pregnancy Status x (o)

Last Menstrual Period Date x (o) x (o)

Condition (Past Medical History) Problem Name x(o) x(o) x x x

Problem code x(o) x(o) x x x x

Start Date x(o) x(o) x x x x

End Date x(o) x(o) x x (o) x x (o)

Problem Status x(o) x(o) x

Date of Entry x x x

Related Encounter x (o)

Treating Provider x (o)

Severity x(o)

Comments / text describing Problem x(o)

Condition (Active Problems/Symptoms) Problem Name x x (o) x x x

Problem code x x (o) x x x x

FP7-287800 SALUS


Start Date x x (o) x x x x

End Date x x (o) x x x x (o)

Problem Status x x (o) x

Date of Entry x x

Related Encounter x x

Treating Provider x

Severity x

Comments / text describing Problem x(o)

Allergies/Intolerance 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

Start Date and Time x (o) x (o) x x

Severity x (o)

x (o) (seriousness)

Date of end of reaction/event x (o) x (o)

Outcome of reaction/event at the time of last observation x (o) x (o)

Date of Entry x x

Comments / text describing the allergy/intolerance x (o)

Family History Kinship Type x (o)

Family History Observation name x (o)

Family History Observation code x (o)

Age at Onset x (o)

Lab Results Result Type (text) x x (o) x x

Result Type (Coded) x x (o) x x x

Result Value (Numeric) x x (o) x x x

Result Value (Coded) x x (o) x x x

Result Value (String) x x (o) x x x

Unit x x (o) x (o)

Result Date x x (o) x

Result Reference range x x (o) x (o) x (o) x (o)

Result Interpretation x x (o)


Related Condition x (o)

Result Provider x (o)

Procedures Procedure Type (text) x (o)

Procedure Type (coded) x x (o) x

Body Site x (o)

Procedure Date x x (o) x

Procedure Status x (o)

Indication x (o)


Procedure Provider x (o)

FP7-287800 SALUS


Comments / text describing Procedure x(o)

Medications Product Name x x x x x x

Product Code x x x x x x

Brand name x x (o)

Brand code x x (o)

Active Ingredient Name x x x x x

Active Ingredient Code x x x x x

Product Form (of administration x x (o)

Dose x x (o) x

Unit x x (o) x

Frequency x x (o) x

Route (Coded) x x (o) x

Start Date x x (o) x x x x

End Date x x (o) x x (o) x x (o)

Indication x x (o) x (o)

Order Date x

Date of Entry x x x

Refills x (o)

Quantity x (o)

Days Supply x (o)


Fulfillment Instructions x (o)

Prescribing Provider x (o)

Stop reason x (o) x (o)

Encounters Start Date x x

End Date x x

Encounter Performer (Provider)

Encounter Type x (o)

Care Provider Location (Organisation) x (o)

Reason for Encounter x

Vital Signs 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)

Result Interpretation x


Related Condition x (o)

Result Provider x (o)

Social History Social history type x x

Social history status x x

Social history dates

Data Reporter Reporter title x(o)

Reporter given name x(o)

FP7-287800 SALUS


Reporter family name x(o)

Reporter organization x(o)

Reporter address x(o)

Reporter qualification x(o)

Death Date of Death x (o) x (o)

Cause(s) of death x (o)

Healthcare Provider Provider ID x

ProviderType x (o)

Organisation x (o)

Organisation organisationID x x

organisationAddress x (o)

organisationType x (o)

organisationName x (o)

Code code

codeSystem

codeSystemName

codeSystemVersion

displayName

FP7-287800 SALUS


4 HL7 CDA BASED TEMPLATES

4.1 Entry Content Modules

In this section the entry level CDA content modules (templates) that can carry the information

required in the SALUS Pilot application scenarios (see Section 3.1) will be presented. For each Entry

Level content module, the sections that can include the respective content module will be presented

by providing references to Template IDs. 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. In each content module table, for each SALUS Common Data Element

Name, the location of the corresponding data element within the specified CDA sections are presented

through XPath expressions. These entry level content models and their mappings to SALUS Common

Data elements are also presented in Appendix 1 as a spread sheet. In addition to this, in Appendix 2, a

sample medical summary document including all the data elements identified in the entry level

templates described in this section is provided.

4.1.1 Conditions Possible Sections: Past Medical History Section or Active Problems Section

//cda:section[cda:templateId/@root='1.3.6.1.4.1.19376.1.5.3.1.3.8' OR

cda:templateId/@root='1.3.6.1.4.1.19376.1.5.3.1.3.6' ]

Location in CDA Document in the specified

sections

Common Data Element Name Cardinality Data Type

cda:entry/cda:act[cda:templateId/@root=

'1.3.6.1.4.1.19376.1.5.3.1.4.5.2']/

cda:entryRelationship[@typeCode='SUBJ']/cda:observation[ cda:templateId/@root=

'1.3.6.1.4.1.19376.1.5.3.1.4.5'] Condition

cda:code/ Problem Type 1..1 CD

cda:text/ Comments / text describing

Problem 0..1 ED

cda:statusCode/ - 1..1 CS

cda:effectiveTime/low Start Date 0..1 TS or IVL<TS> (for effective

Time)

cda:effectiveTime/high End Date

0..1 TS or IVL<TS> (for effective

Time)

cda:value/cda:originalText Problem Name 0..1 ED

cda:value/

Problem Code (can also indicate

Death.cause of death)

1..1 CD

cda:performer Treating Provider 0..1

cda:entryRelationship/cda:observation [cda:templateId/@root =

'1.3.6.1.4.1.19376.1.5.3.1.4.1.1']/ value/

Problem Status

0..1 CD

cda:entryRelationship/cda:observation [cda:templateId/@root =

'1.3.6.1.4.1.19376.1.5.3.1.4.1']/ value/ Severity

0..1 CD

cda:entryRelationship[typeCode='CAUS']/

cda:observation/[cda:code /@code = '419620001'] AND cda:code

/@codeSystem='2.16.840.1.113883.6.96'/] Death

0..1

cda:effectiveTime Date of Death 0..1 TS

FP7-287800 SALUS


1) SHALL contain exactly one [1..1] code. The recommended vocabulary for describing problems is

SNOMED CT where codeSystem is '2.16.840.1.113883.6.96':

Table 2 Recommended Vocabulary for Problem Code

Code Description

64572001 Condition

418799008 Symptom

404684003 Finding

409586006 Complaint

248536006 Functional limitation

55607006 Problem

282291009 Diagnosis

2) MAY contain contain zero or one [0..1] text describing the problem being recorded; including any

dates, comments, et cetera.

3) SHALL contain exactly one [1..1] statusCode. A clinical document normally records only those

observations that have been completed, not observations that are in any other state (not to be

mixed with the clinical status of the problem). Therefore, it

4) SHALL contain exactly one [1..1] @code="completed"

5) SHOULD contain zero or one [0..1] effectiveTime. The onset date SHALL be recorded in the

low element of the effectiveTime element when known. The resolution date SHALL be recorded

in the high element of the effectiveTime element when known. If the problem is known to be

resolved, but the date of resolution is not known, then the high element SHALL be present, and

the nullFlavor attribute SHALL be set to 'UNK'. Therefore, the existence of an high element

within a problem does indicate that the problem has been resolved.

6) SHALL contain exactly one [1..1] value with @xsi:type="CD"

7) SHOULD contain zero or one [0..1] originalText in order to link the coded value to the problem

narrative text (minus any dates, comments, et cetera)

8) MAY contain zero or one [0..1] entryRelationship such that it

a. SHALL contain exactly one [1..1] @typeCode="REFR"

b. SHALL contain exactly one [1..1] Problem Status Observation (Template ID:

'1.3.6.1.4.1.19376.1.5.3.1.4.1.16') where the status is represented in a coded manner in

the value element of the Problem Status Observation. The mandatory vocabulary for

problem status value is a subset from SNOMED CT, with

@codeSystem="2.16.840.1.113883.6.96" and @codeSystemName="SNOMED CT"

Table 3 Mandatory Problem Status Vocabulary

Code Designation

55561003 Active

73425007 Inactive

90734009 Chronic

7087005 Intermittent

255227004 Recurrent

415684004 Rule out

410516002 Ruled out

413322009 Resolved

6http://wiki.ihe.net/index.php?title=1.3.6.1.4.1.19376.1.5.3.1.4.1.1

FP7-287800 SALUS


9) MAY contain zero or one [0..1] entryRelationship such that it

a. SHALL contain exactly one [1..1] @typeCode="SUBJ"

b. SHALL contain exactly one [1..1] Severity Entry Template (Template ID:

1.3.6.1.4.1.19376.1.5.3.1.4.17') where the severity of the problem is represented in a

coded manner in the value element of the Severity Observation. The recommended

vocabulary for severity value is HL7 Observation Value, with

@codeSystem="2.16.840.1.113883.5.1063" and

@codeSystemName="ObservationValue"

Table 4 Recommended Severity Value Vocabulary

Code Designation

H High

L Low

M Moderate

10) MAY contain contain zero or one [0..1] performer for recording the healthcare providers involved

in problem observation

11) MAY contain zero or one [0..1] entryRelationship to record whether this problem is considered as

cause of death such that it

a. SHALL contain exactly one [1..1] @typeCode="CAUS"

b. SHALL contain exactly one [1..1] Observation where code element is selected as

'419620001' from SNOMED CT (codeSystem='2.16.840.1.113883.6.96').

c. SHALL contain exactly one [1..1] effectiveTime to record time of death.

4.1.2 Coded Results

4.1.2.1 Coded Test Results Possible Sections: Coded Results Section

//cda:section[cda:templateId/@root='1.3.6.1.4.1.19376.1.5.3.1.3.28']

Location in CDA Document in the specified sections


cda:entry/cda:observation[cda:templateId/@root

='1.3.6.1.4.1.19376.1.5.3.1.4.13'] Result

cda:code/ Result Type (coded) 1..1 CD

cda:originalText/ Result Type (text) 0..1 ED

cda:effectiveTime Result Date 1..1 IVL<TS>

cda:value/

Result Value (Numeric), Unit Result Value (Coded)

Result Value (String)

1..1 ANY

cda:interpretationCode Result Interpretation 0..* SET<CE>

cda:methodCode 0..* SET<CE>

cda:targetSiteCode 0..* SET<CE>

cda:performer Result Provider 0..1

cda:referenceRange Result Reference range 0..* cda:entryRelationship[typeCode=’RSON’]

/cda:observation [cda:templateId/@root

=’1.3.6.1.4.1.19376.1.5.3.1.4.5’] Related Condition

0..1

7http://wiki.ihe.net/index.php?title=1.3.6.1.4.1.19376.1.5.3.1.4.1

FP7-287800 SALUS


1. SHALL contain exactly one [1..1] code.

a. SHOULD contain zero or one [0..1] originalText

2. SHALL contain exactly one [1..1] effectiveTime representing clinically effective time of the

measurement, which may be when the measurement was performed (e.g., a BP

measurement), or may be when sample was taken (and measured some time afterwards)

3. SHALL contain exactly one [1..1] value with @xsi:type="ANY"

4. SHOULD contain zero or more [0..*] interpretationCode. The recommended vocabulary is

HL7 Observation Interpretation, with @codeSystem="2.16.840.1.113883.5.83" and

@codeSystemName="ObservationInterpretation"

Table 5 Recommended Observation Interpretation Vocabulary

Code Designation

A Abnormal

H High

L Low

N Normal

EX Outside threshold

HX Above high threshold

LX Below low threshold

5. MAY contain zero or more [0..*] methodCode.

6. MAY contain zero or more [0..*] targetSiteCode.

7. MAY contain zero or one [0..1] performer.

8. SHOULD contain zero or more [0..*] referenceRange

9. MAY contain zero or one [0..1] entryRelationship such that it

a. SHALL contain exactly one [1..1] @typeCode="RSON"

b. SHALL contain exactly one [1..1] Problem Entry Template (Template

ID:1.3.6.1.4.1.19376.1.5.3.1.4.5’8) to record information about the related condition

of the patient.

4.1.2.2 Coded Vital Signs

Possible Sections: Coded Vital Signs Section

//cda:section[cda:templateId/@root='1.3.6.1.4.1.19376.1.5.3.1.1.5.3.2']



cda:entry/cda:organizer[cda:templateId/@root ='

1.3.6.1.4.1.19376.1.5.3.1.4.13.1']

cda:statusCode - 1..1 CS

cda:component/cda:observation[cda:templateI

d/@root ='1.3.6.1.4.1.19376.1.5.3.1.4.13.2'] Result

1..*

cda:code/ Result Type (coded) 1..1 CD

cda:originalText/ Result Type (text) 0..1 ED

cda:effectiveTime Result Date 1..1 IVL<TS>

cda:value/

Result Value (Numeric), Unit

1..1 PQ


FP7-287800 SALUS


cda:interpretationCode Result Interpretation 0..* SET<CE>

cda:methodCode 0..* SET<CE>

cda:targetSiteCode 0..* SET<CE>

cda:performer Result Provider 0..1

cda:referenceRange Result Reference range 0..* cda:entryRelationship[typeCode=’RSON’]

/cda:observation [cda:templateId/@root

=’1.3.6.1.4.1.19376.1.5.3.1.4.5’] Related Condition

0..1

1. SHALL contain exactly one [1..1] code where @code="46680005", @displayName="Vital

signs", @codeSystem="2.16.840.1.113883.6.96" and @codeSystemName="SNOMED CT"

2. SHALL contain exactly one [1..1] statusCode where @statusCode="completed"

3. SHALL contain one or more [1..*] Vital Signs Observation Template (Template ID:

'1.3.6.1.4.1.19376.1.5.3.1.4.13.2')

a. This observation SHALL contain exactly one [1..1] code where the @code SHOULD

be selected from a subset of LOINC Codes:

Table 6 Selected LOINC Codes for Vital Signs Observations

i. SHOULD contain zero or one [0..1] originalText

b. This observation SHALL contain exactly one [1..1] effectiveTime representing

clinically effective time of the measurement, which may be when the measurement

was performed (e.g., a BP measurement), or may be when sample was taken (and

measured some time afterwards)

c. This observation SHALL contain exactly one [1..1] value with @xsi:type="PQ"

where appropriate data type specified for measure in the table above shall be recorded

in @unit attribute.

d. This observation SHOULD contain zero or more [0..*] interpretationCode. The

recommended vocabulary is HL7 Observation Interpretation, with

@codeSystem="2.16.840.1.113883.5.83" and

@codeSystemName="ObservationInterpretation", as presented in Table 5.

e. This observation MAY contain zero or more [0..*] methodCode.

f. This observation MAY contain zero or more [0..*] targetSiteCode.

g. This observation MAY contain zero or one [0..1] performer.

Code Description Units

9279-1 RESPIRATION RATE /min

8867-4 HEART BEAT

2710-2 OXYGEN SATURATION %

8480-6 INTRAVASCULAR SYSTOLIC mm[Hg]

8462-4 INTRAVASCULAR DIASTOLIC

8310-5 BODY TEMPERATURE Cel or [degF]

8302-2 BODY HEIGHT (MEASURED) m, cm,[in_us] or [in_uk]

8306-3 BODY HEIGHT^LYING

8287-5 CIRCUMFRENCE.OCCIPITAL-FRONTAL (TAPE MEASURE)

3141-9 BODY WEIGHT (MEASURED) kg, g, [lb_av] or [oz_av]

FP7-287800 SALUS


h. This observation SHOULD contain zero or more [0..*] referenceRange

i. This observation MAY contain zero or one [0..1] entryRelationship such that it

i. SHALL contain exactly one [1..1] @typeCode="RSON"

ii. SHALL contain exactly one [1..1] Problem Entry Template (Template ID:

1.3.6.1.4.1.19376.1.5.3.1.4.5’9) to record information about the related

condition of the patient.

4.1.3 Procedures Possible Sections: Procedures and Interventions Section or Coded List of Surgeries Section or Coded Hospital Studies

Summary Section

//cda:section[cda:templateId/@root='1.3.6.1.4.1.19376.1.5.3.1.1.13.2.11' OR

cda:templateId/@root='1.3.6.1.4.1.19376.1.5.3.1.3.12' OR cda:templateId/@root='1.3.6.1.4.1.19376.1.5.3.1.3.30']



cda:entry/cda:procedure[cda:templateId/@root

='1.3.6.1.4.1.19376.1.5.3.1.4.19'] Procedure

cda:code/cda:originalText/ Procedure Type (text) 0..1 ED

cda:code/ Procedure Type (coded) 1..1 CD

cda:statusCode Procedure Status 1..1 CS

cda:effectiveTime Procedure Date 0..1 TS or IVL<TS>

cda:priorityCode - 0..1 CE

cda:methodCode - 0..1 SET<CE>

cda:targetSiteCode Body Site 0..* SET<CD>

cda:performer/cda:assignedEntity Procedure Provider 0..*

cda:entryRelationship[@typeCode='RSON

']/

cda:observation[cda:templateId/@root='1.3.6.1.4.1.19376.1.5.3.1.4.5']

Indication 0..1

cda:entryRelationship[@typeCode='COM

P']/ cda:encounter[cda:templateId/@root='1.3.6.1.4.1.

19376.1.5.3.1.4.14']

Related Encounter 0..1

1. SHALL contain exactly one [1..1] code

a. This code SHOULD contain zero or one [0..1] originalText

2. SHALL contain exactly one [1..1] statusCode. The statusCode can be either

completed|active|aborted|cancelled. It shall have the value 'completed' for procedures that

have been completed, and 'active' for procedures that are still in progress. Procedures that

were stopped prior to completion shall use the value 'aborted', and procedures that were

cancelled before being started shall use the value 'cancelled'.

3. SHOULD contain zero or one [0..1] effectiveTime

4. MAY contain zero or one [0..1] priorityCode

5. MAY contain zero or one [0..1] methodCode

6. SHOULD contain zero or more [0..*] targetSiteCode

7. SHOULD contain zero or more [0..*] performer

a. SHALL contain exactly one [1..1] assignedEntity





of the patient.


a. SHALL contain exactly one [1..1] @typeCode="COMP"

9http://wiki.ihe.net/index.php?title=1.3.6.1.4.1.19376.1.5.3.1.4.5 10http://wiki.ihe.net/index.php?title=1.3.6.1.4.1.19376.1.5.3.1.4.5

FP7-287800 SALUS


b. SHALL contain exactly one [1..1] @inversionInd="true"

c. SHALL contain exactly one [1..1] Encounters Entry Template (Template

ID:'1.3.6.1.4.1.19376.1.5.3.1.4.14’11) to record information about the encounter in

which the procedure was performed.

4.1.4 Allergies & Intolerances Possible Sections: Allergies and Other Adverse Reactions Section

//cda:section[cda:templateId/@root='1.3.6.1.4.1.19376.1.5.3.1.3.13']/



cda:entry/cda:act[cda:templateId/@root=

'1.3.6.1.4.1.19376.1.5.3.1.4.5.3']/

cda:entryRelationship[@typeCode='SUBJ']/ cda:observation[

cda:templateId/@root=

'1.3.6.1.4.1.19376.1.5.3.1.4.6'] Allergy/Intolerance

cda:text/

Comments / text describing the

allergy/ intolerance

0..1 ED

cda:effectiveTime/low Start Date and Time 1..1 TS

cda:effectiveTime/high Date of end of reaction/event 0..1 TS

cda:value/cda:originalText Adverse Event Type (text) 0..1 ED

cda:code/ or cda:value Adverse Event Type (coded) 1..1 CD

cda:participant[@typeCode='CSM']/participantRole[@classCode='MANU']/playingEntity[@

classCode='MMAT']/cda:code/ Product Code

0..1 CE

cda:participant[@typeCode='CSM']/partici

pantRole[@classCode='MANU']/playingEntity[@classCode='MMAT']/cda:code/cda:originalText Product Name

0..1 ED

cda:entryRelationship[@typeCode='MFST'

]/ cda:observation[templateId/@root='2.16.840.1.11

3883.10.20.1.54'] Reaction

0..*

cda:entryRelationship[@typeCode='SUBJ']/ cda:observation[templateId/@root=

'1.3.6.1.4.1.19376.1.5.3.1.4.1'] Severity

0..1

cda:entryRelationship[@typeCode='REFR'

]/ cda:observation[templateId/@root= '1.3.6.1.4.1.19376.1.5.3.1.4.1.1']

Outcome of reaction/event at the time of last observation

0..1

1. SHALL contain exactly one [1..1] code. The recommended vocabulary is HL7 Observation

Intolerance Type, with @codeSystem="2.16.840.1.113883.5.4" and

@codeSystemName="ObservationIntoleranceType"

Table 7 Recommended Allergy/Intolerance Type Code Vocabulary

Code Designation

ALG Allergy

DALG Drug Allergy

EALG Environmental Allergy

FALG Food Allergy

OINT Intolerance

DINT Drug Intolerance

DNAINT Drug Non-Allergy Intolerance


FP7-287800 SALUS


EINT Environmental Intolerance

ENAINT Environmental Non-Allergy Intolerance

FINT Food Intolerance

FNAINT Food Non-Allergy Intolerance

NAINT Non-Allergy Intolerance

2. SHALL contain zero or one [0..1] value with @xsi:type="CD". Note: Allergy Type can be

recorded either in the code or in value element, depending on the data source.

a. This value SHOULD contain zero or one [0..1] originalText

3. MAY contain contain zero or one [0..1] text describing the allergy / intolerance being

recorded; including any dates, comments, et cetera.

4. SHALL contain exactly one [1..1] effectiveTime

a. If it is unknown when the allergy began, this effectiveTime SHALL contain

low/@nullFLavor="UNK"

b. If the allergy is no longer a concern, this effectiveTime MAY contain zero or one [0..1]

high

5. SHOULD contain zero or one [0..1] participant such that it

a. SHALL contain exactly one [1..1] @typeCode="CSM" Consumable

b. SHALL contain exactly one [1..1] participantRole

i. This participantRole SHALL contain exactly one [1..1]

@classCode="MANU" Manufactured Product

ii. This participantRole SHALL contain exactly one [1..1] playingEntity

1. This playingEntity SHALL contain exactly one [1..1]

@classCode="MMAT" Manufactured Material

2. This playingEntity SHALL contain exactly one [1..1] code


6. SHOULD contain zero or more [0..*] entryRelationship such that it

a. SHALL contain exactly one [1..1] @typeCode="MFST" Is Manifestation of

b. SHALL contain exactly one [1..1] @inversionInd="true" True.

c. SHALL contain exactly one [1..1] templateId with

@root="1.3.6.1.4.1.19376.1.5.3.1.4.6.1"

d. SHALL contain exactly one [1..1] Reaction Observation (Template id:

'2.16.840.1.113883.10.20.1.54)

7. SHALL contain zero or one [0..1] entryRelationship such that it

a. SHALL contain exactly one [1..1] @typeCode="SUBJ" Has Subject

b. SHALL contain exactly one [1..1] @inversionInd="true" True

c. SHALL contain exactly one [1..1] Severity Observation (Template ID:

1.3.6.1.4.1.19376.1.5.3.1.4.1'12)

i. The recommended vocabulary for severity value is HL7 Observation Value,

with @codeSystem="2.16.840.1.113883.5.1063" and

@codeSystemName="ObservationValue", as presented in Table 4.



b. SHALL contain exactly one [1..1] @inversionInd="false" False

c. SHALL contain exactly one [1..1] Problem Status Observation (Template ID:

'1.3.6.1.4.1.19376.1.5.3.1.4.1.1'). The mandatory vocabulary for problem status value

is a subset from SNOMED CT, with @codeSystem="2.16.840.1.113883.6.96" and

@codeSystemName="SNOMED CT", as presented in Table 3.


FP7-287800 SALUS


4.1.5 Medications Possible Sections: Medications Section, Medications on Admission, Medications Administered Section, Hospital Discharge

Medications

//cda:section[cda:templateId/@root='1.3.6.1.4.1.19376.1.5.3.1.3.19' OR

cda:templateId/@root='1.3.6.1.4.1.19376.1.5.3.1.3.20' OR cda:templateId/@root='1.3.6.1.4.1.19376.1.5.3.1.3.21' OR cda:templateId/@root='1.3.6.1.4.1.19376.1.5.3.1.3.22' ]


sections


cde:entry/cda:substanceAdministration[templateId

/@root = '1.3.6.1.4.1.19376.1.5.3.1.4.7' ] Medication

cda:code

0..1 CD


cda:effectiveTime[@xsi:type='IVL_TS'] Medication Start/Stop Date 1..1 IVL<TS>

cda:effectiveTime[@operator='A']

Frequency

0..1 PIVL<TS> or EIVL<TS>

cda:routeCode

Route

0..1 CE

cda:approachSiteCode - 0..* SET<CD>

cda:doseQuantity/@value

Dose

0..1

cda:doseQuantity/@unit

Unit

0..1

cda:maxDoseQuantity

Structured regular dosing scheme

0..1 RTO<PQ, PQ>

cda:administrationUnitCode

Product Form

0..1 CE

cda:consumable/cda:manufacturedProduct[@

classCode=’MANU’]/cda:manufacturedMaterial/cda:code Product Code

1..1 CE

cda:originalText Product Name 0..1 ED

cda:translation/cda:code Brand Code 0..* CE

cda:translation/cda:code Active Ingredient Code 0..* CE

cda:consumable/cda:manufacturedProduct[

@classCode=’MANU’]/cda:manufacturedMaterial

/cda:name Brand Name

0..1 EN

cda:entryRelationship[@typeCode='RSON']/

cda:observation[cda:templateId/@root='1.3.6.1.4.1

.19376.1.5.3.1.4.5']

Indication

0..*

cda:entryRelationship[@typeCode='REFR']/

cda:supply[moodCode='INT'] 0..1

cda:author/cda: assignedAuthor/ Prescribing Provider 0..1

cda:author/cda:time Order Date 0..1 TS

cda:quantity Quantity 0..1 PQ

cda:entryRelationship[@typeCode='SUBJ']//

cda:act[cda:templateId/@root= '1.3.6.1.4.1.19376.1.5.3.1.4.3']/ cda:text

0..1

cda:entryRelationship[@typeCode='REFR']/

cda:supply[moodCode='EVN'] 1..1

../cda:sequenceNumber Refills 0..1 INT

cda:quantity Quantity 0..1 PQ

cda:entryRelationship[@typeCode='CAUS']/

cda:observation[cda:templateId/@root= ’2.16.840.1.113883.10.20.1.54’]/code

0..1

cda:entryRelationship[@typeCode='SUBJ']//

cda:act[cda:templateId/@root= '1.3.6.1.4.1.19376.1.5.3.1.4.3.1']/ cda:text

Fulfillment Instructions

0..1

FP7-287800 SALUS


1. MAY contain zero or one [0..1] code

2. SHALL contain exactly one [1..1] statusCode. The status of all <substanceAdministration>

elements must be "completed". The act has either occurred, or the request or order has been

placed. Therefore, it

a. SHALL contain exactly one [1..1] @code="completed"

3. SHALL contain exactly one [1..1] effectiveTime such that it

a. SHALL contain exactly one [1..1] @xsi:type, where the @code="IVL_TS"

b. SHALL contain exactly one [1..1] low

c. SHALL contain exactly one [1..1] high).

4. SHOULD contain zero or one [0..1] effectiveTime such that it

a. SHALL contain exactly one [1..1] @xsi:type=”PIVL_TS” or “EIVL_TS”

b. SHALL contain exactly one [1..1] @operator="A"

5. MAY contain zero or one [0..1] routeCode

6. MAY contain zero or more[0..*] approachSiteCode

7. SHOULD contain zero or one [0..1] doseQuantity

8. MAY contain zero or one [0..1] maxDoseQuantity

9. MAY contain zero or one [0..1] administrationUnitCode

10. SHALL contain exactly one [1..1] consumable

a. This consumable SHALL contain exactly one [1..1] manufacturedProduct

i. SHALL contain exactly one [1..1] @classCode="MANU"

ii. SHALL contain exactly one [1..1] templateId with

@root="1.3.6.1.4.1.19376.1.5.3.1.4.7.2"

iii. SHALL contain exactly one [1..1] templateId with

@root="2.16.840.1.113883.10.20.1.53"

iv. SHALL contain exactly one [1..1] manufacturedMaterial

1. This manufacturedMaterial SHALL contain exactly one [1..1] code


b. This code MAY contain zero or more [0..*] translation

11. MAY contain zero or more [0..*] entryRelationship such that it


b. SHALL contain exactly one [1..1] Problem Entry Template (Template ID:

1.3.6.1.4.1.19376.1.5.3.1.4.5’ ) to record information about the related indication.



b. SHALL contain exactly one [1..1] Supply Entry Template (Template ID:

'1.3.6.1.4.1.19376.1.5.3.1.4.7.3') with @moodCode="INT"

i. SHOULD contain zero or one [0..1] repeatNumber

ii. SHOULD contain zero or one [0..1] quantity

iii. MAY contain zero or one [0..1] author

1. MAY contain zero or one [0..1] time

2. MAY contain zero or one [0..1] assignedAuthor

13. MAY contain contain exactly one [1..1] entryRelationship such that it


b. SHOULD contain zero or one [0..1] sequenceNumber

c. SHALL contain exactly one [1..1] Supply Entry Template (Template ID:

'1.3.6.1.4.1.19376.1.5.3.1.4.7.3') with @moodCode="EVN"



iii. MAY contain zero or one [0..1] performer


a. SHALL contain exactly one [1..1] @typeCode="SUBJ"

b. SHALL contain exactly one [1..1] @inversionInd="true" True.

c. SHALL contain exactly one [1..1] Patient Medication Instructions Template

(Template ID: '1.3.6.1.4.1.19376.1.5.3.1.4.3')


FP7-287800 SALUS


a. SHALL contain exactly one [1..1] @typeCode="CAUS".

b. SHALL contain exactly one [1..1] Reaction Observation (Template ID:

'2.16.840.1.113883.10.20.1.54')


a. SHALL contain exactly one [1..1] @typeCode="SUBJ".

b. SHALL contain exactly one [1..1] Medication Fulfillment Instructions

Template(Template ID: '1.3.6.1.4.1.19376.1.5.3.1.4.3.1')

4.1.6 Encounters Possible Sections: Encounter Histories Section

//cda:section[cda:templateId/@root='1.3.6.1.4.1.19376.1.5.3.1.1.5.3.3']/



cda:entry/cda:encounter[cda:templateId/@root =

'1.3.6.1.4.1.19376.1.5.3.1.4.14'] Encounter

cda:effectiveTime/low Start Date 1..1

cda:effectiveTime/high End Date 1..1

cda:performer/cda:assignedEntity Encounter Performer 0..*

cda:code Encounter Type 0..1 CD

cda:participant[@typeCode='LOC']/participa

ntRole[@classCode='SDLOC'] Care Provider Location

0..1

cda:entryRelationship[@typeCode='RSON’]/

cda:observation[cda:templateId/@root='1.3.6.1.4.1.19376.1.5.3.1.4.5'] Reason for Encounter

0..*

1. SHOULD contain zero or one [0..1] code. The recommended vocabulary is HL7 Act

Encounter Code, with @codeSystem="2.16.840.1.113883.5.4" and

@codeSystemName="ActEncounterCode"

Table 8 Recommended Encounter Code Vocabulary

Code Designation

AMB Ambulatory

ACUTE Inpatient Acute

ALC Alternative Level of Care

CARD Cardiology

CHR Chronic

DNTL Dental

DRGRHB Drug Rehab

EMER Emergency

FLD Field

GENRL General

HH Home Health

IMP Inpatient Encounter

MED Medical

NONAC Inpatient Non-acute

OBS Obstetrics

ONC Oncology

FP7-287800 SALUS


PALL Palliative

PED Pediatrics

PHAR Pharmaceutical

PHYRHB Physical Rehab

PSYCH Psychiatric

SS Short Stay

SURG Surgical

VR Virtual

2. SHALL contain exactly one [1..1] effectiveTime

3. MAY contain zero or more [0..*] performer

a. The performer, if present, SHALL contain exactly one [1..1] assignedEntity

4. MAY contain zero or more [0..*] participant such that it

a. SHALL contain exactly one [1..1] @typeCode="LOC" Location

b. SHALL contain exactly one [1..1] Service Delivery Location

5. MAY contain zero or more [0..*] entryRelationship such that it

a. SHALL contain exactly one [1..1] @typeCode="RSON" Has Reason



of the patient.

4.1.7 Family History Possible Sections: Coded Family History Section



sections


cda:entry/cda:organizer[cda:templateId/@root=' 1.3.6.1.4.1.19376.1.5.3.1.4.15']

Family History

cda:subject/cda:relatedSubject/cda:code[@codeSystem='2.16.840.1.113883.5.111'] Kinship Type

1..1 CE

cda:subject/cda:relatedSubject/cda:subject 0..1

cda:administrativeGenderCode - 0..1 CE

cda:birthTime - 0..1 TS

cda:component/ 1..* cda:observation[cda:templateId/@root

= '1.3.6.1.4.1.19376.1.5.3.1.4.13.3'] 1..1

cda:code 1..1 CD

cda:effectiveTime 0..1 IVL<TS>

cda:value/cda:code Family History Observation code 1..1 CD

cda:originalText Family History Observation name 0..1 ED

cda:entryRelationship[@typeCode

='SUBJ’]/cda:observation[ cda:templateId/@root='2.16.840.1.1138

83.10.20.1.38']/cda:value[@xsi:type="I

NT"] Age at Onset

0..1 INT


FP7-287800 SALUS


1. This organizer SHALL contain exactly one [1..1] subject

a. This subject SHALL contain exactly one [1..1] relatedSubject/@classCode="PRS"

Person

i. This relatedSubject SHALL contain exactly one [1..1] code. The

recommended vocabulary is HL7 Family Member, with

@codeSystem="2.16.840.1.113883.5.111" and

@codeSystemName="FamilyMember". The vocabulary is not presented here

since it is long.

ii. This relatedSubject SHOULD contain zero or one [0..1] subject

1. This subject SHOULD contain zero or one [0..1]

administrativeGenderCode

2. This subject MAY contain zero or one [0..1] birthTime

2. SHALL contain at least one [1..*] component

a. Such components SHOULD contain exactly one [1..1] Family History Observation

(Template ID: '1.3.6.1.4.1.19376.1.5.3.1.4.13.3')

i. SHALL contain exactly one [1..1] code. The recommended vocabulary for

describing the type of observation is SNOMED CT, where @codeSystem is

'2.16.840.1.113883.6.96':

Table 9 Recommended Vocabulary for Problem Code

Code Description

64572001 Condition

418799008 Symptom

404684003 Finding

409586006 Complaint

248536006 Functional limitation

55607006 Problem

282291009 Diagnosis

ii. SHOULD contain zero or one [0..1] effectiveTime

iii. SHALL contain exactly one [1..1] value with @xsi:type="CD"

1. MAY contain zero or one [0..1] originalText

iv. MAY contain zero or one [0..1] entryRelationship such that it

1. SHALL contain exactly one [1..1] @typeCode="SUBJ" Subject

2. SHALL contain exactly one [1..1] @inversionInd="true" True

3. SHALL contain exactly one [1..1] Age Observation Template

(Template ID: '2.16.840.1.113883.10.20.1.38'), which

a. SHALL contain exactly one [1..1]code with

@code="397659008" and

@codeSystem="2.16.840.1.113883.6.96" ("Age"from

SNOMEDCT)

b. SHALL contain exactly one [1..1] value with

@xsi:type="INT"

4.1.8 Social History Possible Sections: Coded SocialHistory Section




cda:entry/cda:observation[cda:templateId/@root='

1.3.6.1.4.1.19376.1.5.3.1.4.13.4']

Social History

FP7-287800 SALUS


cda:code Social history type 1..1 CD


cda:effectiveTime Social history dates 0..1 IVL<TS>

cda:value Social history status 0..1 ANY

1. SHALL contain exactly one [1..1] code. The recommended vocabulary for describing social

history type is SNOMED CT where codeSystem is '2.16.840.1.113883.6.96':

Table 10 RecommendedVocabulary for Social History Types

Code Description Data Type Units

229819007 Tobacco use and exposure

PQ

{pack}/d or {pack}/wk or {pack}/a

256235009 Exercise {times}/wk

160573003 Alcohol intake {drink}/d or {drink}/wk

364393001 Nutritional observable

CD NA

364703007 Employment detail

425400000 Toxic exposure status

363908000 Details of drug misuse behavior

228272008 Health-related behavior

105421008 Educational Achievement

228272008 Other social history ANY

2. SHALL contain exactly one [0..1] statusCode with @code="completed" to state that this is an

observation that has already taken place.

3. SHOULD contain zero or one [0..1] effectiveTime

4. SHOULD contain zero or one [0..1] value to record the value associated with the social

history observation. The data types for the recommended social history type vocabulary is

presented in the table above.

4.1.9 Demographics Possible Sections: These are recorded in the Clinical Document Header


sections


/cda:ClinicalDocument/cda:recordTarget/cda:patientRole/ Patient

1..1

cda:id id 1..1 SET<II>

cda:addr address 1..* SET<AD>

cda:telecom 1..* SET<TEL>

cda:patient 1..1

cda:name name 1..1 SET<PN>

cda:administrativeGenderCode gender 1..1 CE

cda:birthTime date Of Birth 1..1 TS

cda:maritalStatusCode -

0..1 CE

cda:religiousAffiliationCode -

0..1 CE

cda:raceCode race 0..1 CE

cda:ethnicGroupCode ethnicity 0..1 CE

cda:birthplace/cda:place/cda:addr birth Place 1..1 AD

FP7-287800 SALUS


cda:providerOrganization/cda:id Provider Organization ID 0..* SET<II>

/cda:ClinicalDocument/cda:documentationOf/ cda:serviceEvent/

0..*

cda:effectiveTime/cda:low patient registration date 0..1

cda:effectiveTime/cda:high patient de-registration date 0..1

cda:performer/cda:assignedEntity/cda:id Provider id 0..* SET<II>

Investigation number

1. SHALL contain at least one [1..*] recordTarget

a. Such recordTargets SHALL contain exactly one [1..1] patientRole

i. This patientRole SHALL contain at least one [1..*] id

ii. This patientRole SHALL contain at least one [1..*] addr

iii. This patientRole SHALL contain at least one [1..*] telecom

iv. This patientRole MAY contain zero or more [0..*] providerOrganization

1. This providerOrganization SHALL contain one or more [1..*] id

v. This patientRole SHALL contain exactly one [1..1] patient

1. This patient SHALL contain exactly one [1..1] name

2. This patient SHALL contain exactly one [1..1]

administrativeGenderCode. The recommended vocabulary is HL7

Administrative Gender, with @codeSystem="2.16.840.1.113883.5.1"

and @codeSystemName="AdministrativeGender"

Table 11 Recommended Vocabulary for Administrative Gender Code

Code Designation

F Female

M Male

UN Undifferentiated

3. This patient SHALL contain exactly one [1..1] birthTime

a. SHALL be precise to year

b. SHOULD be precise to day

4. This patient SHOULD contain zero or one [0..1] maritalStatusCode.

The recommended vocabulary is HL7 Marital Status, with

@codeSystem="2.16.840.1.113883.5.2" and

@codeSystemName="MaritalStatus"

Table 12 Recommended Vocabulary for Marital Status Code

Code Designation

A Annulled

D Divorced

I Interlocutory

L Legally Separated

M Married

P Polygamous

S Never Married

T Domestic partner

W Widowed

FP7-287800 SALUS


5. This patient MAY contain zero or one [0..1] religiousAffiliationCode.

The recommended vocabulary is HL7 Religious Affiliation, with

@codeSystem="2.16.840.1.113883.5.1076" and

@codeSystemName="ReligiousAffiliation". The vocabulary is not

presented here since it is long.

6. This patient MAY contain zero or one [0..1] raceCode. The

recommended vocabulary is CDC Race and Ethnicity, with

@codeSystem="2.16.840.1.113883.6.238" and

@codeSystemName="CDC Race and Ethnicity". The vocabulary is

not presented here since it is long.

7. This patient MAY contain zero or one [0..1] ethnicGroupCode. The

recommended vocabulary is CDC Race and Ethnicity, with

@codeSystem="2.16.840.1.113883.6.238" and

@codeSystemName="CDC Race and Ethnicity". The vocabulary is

not presented here since it is long.

8. This patient MAY contain zero or one [0..1] birthplace

a. This birthplace, if present, SHALL contain exactly one [1..1]

place

i. This place SHALL contain exactly one [1..1] addr

2. SHALL contain exactly one [1..1] documentationOf

a. This documentationOf SHALL contain exactly one [1..1] serviceEvent

i. This serviceEventMAY contain zero or one [0..1] effectiveTime indicating

date range of the service event

ii. This serviceEvent SHOULD contain zero or more [0..*] performer

1. This performer MAY contain zero or more [0..*] assignedEntity

a. This assignedEntity SHALL contain exactly one [1..1] id.

4.1.10 Pregnancies Possible Sections: Pregnancy History Section

//cda:section[cda:templateId/@root='1.3.6.1.4.1.19376.1.5.3.1.1.5.3.4']/


sections


cda:entry/cda:observation[cda:templateId/@root = '1.3.6.1.4.1.19376.1.5.3.1.4.13.5']

Pregnancy Observation

cda:code 1..1 CD

cda:effectiveTime 0..1 IVL<TS>

cda:value[../cda:code/@code="11778-8"OR ../cda:code/@code="11779-8"OR

../cda:code/@code="11780-8" AND

../cda:code/@codeSystem="2.16.840.1.113883.6.1"] Delivery Date

0..1 (cardinality of

value element)

TS

cda:value[../cda:code/@code="11449-6"

AND ../cda:code/@codeSystem="2.16.840.1.113883.6.1

"]

Pregnancy Status

0..1

(cardinality of value element)

CE

cda:value[../cda:code/@code="8665-2"

AND ../cda:code/@codeSystem="2.16.840.1.113883.6.1

"] Last Menstrual Period Date

0..1

(cardinality of value element)

TS

1. SHALL contain exactly one [1..1] codedescribing what facet of patient's pregnancy history is

being recorded. These codes should come from a selected list of codes from LOINC

(templateId: 2.16.840.1.113883.6.1) as shown below:

FP7-287800 SALUS


Table 13Pregnancy Observation Codes

2. SHOULD contain [0..1] effectiveTime to record the observation date.

3. SHALL contain [0..1] value which shall be recorded using a data type appropriate to the

coded observation. The data types and units (or vocabularies) for the according to the

recommended codes are provided in the table above.

4.1.11 Immunizations

Immunization data is not identified as a requirement within the scope of SALUS pilot application

scenarios. However, considering that immunization is also a kind of medication, it is taken into

account as a relevant content template as presented below. For this reason, the names for the common

data elements are written in a special way in the table; e.g. "* (Immunization dose)".

Its mapping to OMOP CDM is provided as well, in the next section.

Code Description Data Type Units or

Vocabulary

11636-8 BIRTHS LIVE (REPORTED)

INT NA

11637-6 BIRTHS PRETERM (REPORTED)

11638-4 BIRTHS STILL LIVING (REPORTED)

11639-2 BIRTHS TERM (REPORTED)

11640-0 BIRTHS TOTAL (REPORTED)

11612-9 ABORTIONS (REPORTED)

11613-7 ABORTIONS INDUCED (REPORTED)

11614-5 ABORTIONS SPONTANEOUS (REPORTED)

33065-4 ECTOPIC PREGNANCY (REPORTED)

11449-6 PREGNANCY STATUS

CE

SNOMED CT, ICD-9-CM

8678-5 MENSTRUAL STATUS SNOMED CT

8665-2 DATE LAST MENSTRUAL PERIOD TS

NA

11778-8 DELIVERY DATE (CLINICAL ESTIMATE)

TS 11779-6 DELIVERY DATE (ESTIMATED FROM LAST

MENSTRUAL PERIOD)

11780-4 DELIVERY DATE (ESTIMATED FROM OVULATION DATE)

11884-4 FETUS, GESTATIONAL AGE (CLINICAL ESTIMATE)

PQ

d, wk, or mo

11885-1 FETUS, GESTATIONAL AGE (ESTIMATED FROM LAST MENSTRUAL PERIOD)

11886-9 FETUS, GESTATIONAL AGE (ESTIMATED FROM OVULATION DATE)

11887-7 FETUS, GESTATIONAL AGE (ESTIMATED FROM SELECTED DELIVERY DATE)

453712 MULTIPLE PREGNANCY - -

FP7-287800 SALUS


Possible

Sections:

Immunizations Section

//cda:section[cda:templateId/@root='1.3.6.1.4.1.19376.1.5.3.1.3.23']

Location in CDA Document in the specified sections Common Data Element Name Cardinality Data Type

cde:entry/cda:substanceAdministration[templateId/@root = '1.3.6.1.4.1.19376.1.5.3.1.4.12' ]

* (Immunization)

cda:code - 1..1 CD


cda:effectiveTime * (Immunization date) 1..1 SXCM<TS>

cda:routeCode * (Immunization route) 0..1 CE

cda:approachSiteCode * (Immunization approach site) 0..* SET<CD>

cda:doseQuantity * (Immunization dose) 0..1 IVL<PQ>

cda:consumable/cda:manufacturedProduct[cda:templ

ateId/@root='1.3.6.1.4.1.19376.1.5.3.1.4.7.2']/cda:manufacturedMaterial/

1..1

cda:code * (Immunization Product Code) 1..1 CE

cda:originalText * (Product Name) 0..1 ED

cda:translation/cda:code * (Brand Code) 0..* CE

cda:translation/cda:code * (Active Ingredient Code) 0..* CE

cda:name * (Brand Name) 0..1 EN

cda:entryRelationship[@typeCode='REFR']/cda:sup

ply[cda:templateId/@root='1.3.6.1.4.1.19376.1.5.3.1.4.7.

3']/

* (Immunization supply) 0..1

cda:entryRelationship[@typeCode='SUBJ']/

cda:observation[cda:templateId/@root=

’2.16.840.1.113883.10.20.1.46’]/

* (Immunization series number) 0..1

cda:entryRelationship[@typeCode='CAUS']/

cda:observation[cda:templateId/@root=

’2.16.840.1.113883.10.20.1.54’]/

* (Immunization reaction) 0..1

1. SHALL contain exactly one [1..1] code with @code="IMMUNIZ" and

@codeSystem="2.16.840.1.113883.5.4", corresponding to @codeSystem="ActCode" and

@displayName="Immunization"

2. SHALL contain exactly one [1..1] statusCode. The status of all <substanceAdministration>

elements must be "completed". The act has either occurred, or the request or order has been

placed. Therefore, it

a. SHALL contain exactly one [1..1] @code="completed"

3. SHALL contain exactly one [1..1] effectiveTime such that @value presents the date & time of

the immunization

4. MAY contain zero or one [0..1] routeCode

5. MAY contain zero or more [0..*] approachSiteCode

6. SHOULD contain zero or one [0..1] doseQuantity

7. SHALL contain exactly one [1..1] consumable

a. This consumable SHALL contain exactly one [1..1] manufacturedProduct

i. SHALL contain exactly one [1..1] @classCode="MANU"

ii. SHALL contain exactly one [1..1] templateId with

@root="1.3.6.1.4.1.19376.1.5.3.1.4.7.2"

iii. SHALL contain exactly one [1..1] templateId with

@root="2.16.840.1.113883.10.20.1.53"

FP7-287800 SALUS


iv. SHALL contain exactly one [1..1] manufacturedMaterial

1. This manufacturedMaterial SHALL contain exactly one [1..1] code


b. This code MAY contain zero or more [0..*] translation



b. SHALL contain exactly one [1..1] Supply Entry Template (Template ID:

'1.3.6.1.4.1.19376.1.5.3.1.4.7.3') with @moodCode="EVN"



iii. MAY contain zero or one [0..1] performer


a. SHALL contain exactly one [1..1] @typeCode="SUBJ".

b. SHALL contain exactly one [1..1] Medication Series Number Observation Template

(Template ID: 2.16.840.1.113883.10.20.1.46)

i. SHALL contain exactly one [1..1] code with @code="30973-2" and

@codeSystem="2.16.840.1.113883.6.1", corresponding to

@codeSystemName="LOINC" and @displayName="Dose number"

ii. SHALL contain exactly one [1..1] statusCode with @code="completed"

iii. SHALL contain exactly one [1..1] value with @xsi:type="INT" and @value

that indicates the immunization series number


a. SHALL contain exactly one [1..1] @typeCode="CAUS".

b. SHALL contain exactly one [1..1] Reaction Observation (Template ID:

'2.16.840.1.113883.10.20.1.54')

FP7-287800 SALUS


5 OMOP CDM BASED CONTENT MODEL TEMPLATES

In two of our pilot application scenarios, namely “Temporal Pattern Characterisation (Discovery)”

and “Running Exploratory Analysis Studies over EHRs for Signal Detection (Temporal Association

Screening)”, our pilot end user partner UMC has identified the target data model as Observational

Medical Outcomes Partnership (OMOP)14 Common Data Model (CDM). OMOP is a public-private

partnership funded and managed through the Foundation for the National Institutes of Health, with the

overall aim to improve the safety monitoring of medicines. The partnership is conducting a multi-year

comparative evaluation of analytical methods for safety surveillance of longitudinal observational

databases across a spectrum of disparate (administrative claims as well as electronic health records)

data sources. OMOP is based on a model where data from various sources is extracted and

transformed to a common structure and framework for further analysis. This is referred to as the

OMOP Common Data Model (CDM); it organizes and standardizes observational data to ensure that

analytical methods for surveillance can be systematically applied across disparate data sources to

produce comparable results. In Figure 1, an overview if OMOP CDM is presented.

Figure 1 An Overview of OMOP CDM

OMOP CDM itself is a database schema. In the following subsections the main parts of the data base

schema that are of interest to SALUS pilot application scenarios will be introduced briefly based on

the information provided in “Observational Medical Outcomes Partnership Common Data Model

Specifications Version 4.015). For each of the field in the respective database schema, the

corresponding SALUS Common Data Element (see Section 3.1) will be presented. These mappings

are also available as a spreadsheet in Appendix 1.

14http://omop.fnih.org/. 15http://75.101.131.161/download/loadfile.php?docname=CDM%20Specification%20V4.0

http://omop.fnih.org/

FP7-287800 SALUS


5.1 OMOP CDM Tables and Mapping to Common Data Elements

5.1.1 Person The Person table is one of the basic four mandatory dimensions of analysis carried out in

observational studies, and when combined with the Drug Exposure, Condition, Observation, and

Procedure entities, presents the framework for active drug surveillance. The source data for the Person

table comes from person demographics data that will be de-identified to ensure patient privacy.

Field Required Type Standard Description Corresponding Common Data Item Notes

Table: Person Patient

person_id Yes integer

A system-generated unique identifier for each person. -

gender_concept_id Yes integer HL7

A foreign key that refers to a standard concept identifier in the vocabulary for the gender of the person. gender (derived)

year_of_birth Yes number(4)

The year of birth of the person. For data sources with date of birth, the year is extracted. For data sources where the year of birth is not available, the approximate year of birth is derived based on any age group categorization available. date of Birth

month_of_birth No number(2)

The month of birth of the person. For data sources that provide the precise date of birth, the month is extracted and stored in this field. date of Birth

day_of_birth No number(2)

The day of the month of birth of the person. For data sources that provide the precise date of birth, the day is extracted and stored in this field. date of Birth

race_concept_id No integer OMB, CDC

A foreign key that refers to a standard concept identifier in the vocabulary for the race of the person. race (derived)

FP7-287800 SALUS


ethnicity_concept_id No integer OMB

A foreign key that refers to the standard concept identifier in the vocabulary for the ethnicity of the person. ethnicity (derived)

location_id No integer

A foreign key to the place of residency for the person in the location table, where the detailed address information is stored. address

provider_id No integer

A foreign key to the primary care provider the person is seeing in the provider table.

provider ID (Provider)

care_site_id No integer

A foreign key to the primary care site in the care site table, where the details of the care site are stored.

provider organisation id (Organisation)

person_source_value No string(50)

An encrypted key derived from the person identifier in the source data. This is necessary when a drug safety issue requires a link back to the person data at the source dataset. No value with any medical or demographic significance must be stored. ID

gender_source_value No string(50)

The source code for the gender of the person as it appears in the source data. The person gender is mapped to a standard gender concept in the vocabulary and the corresponding concept identifier is, stored here for reference. gender

FP7-287800 SALUS


race_source_value No string(50)

The source code for the race of the person as it appears in the source data. The person race is mapped to a standard race concept in the vocabulary and the original code is, stored here for reference. race

ethnicity_source_value No string(50)

The source code for the ethnicity of the person as it appears in the source data. The person ethnicity is mapped to a standard ethnicity concept in the vocabulary and the original code is, stored here for reference. ethnicity

5.1.2 Drug Exposure

Drug Exposure table contains individual records that reflect drug utilization from within the source

data. Drug Exposure indicators include drug details (captured as standard Concept identifiers in the

Vocabulary), drug quantity, number of days supply, period of exposure, and prescription refill data.

Field Required Type Standard Description

Corresponding Common Data Item Notes

Table: Drug_Exposure Medication

drug_exposure_id yes integer

A system-generated unique identifier for each drug utilization event.

person_id yes integer

A foreign key identifier to the person who is subjected to the drug. The demographic details of that person are stored in the person table. Person.ID

FP7-287800 SALUS


drug_concept_id yes integer RxNorm

A foreign key that refers to a standard concept identifier in the vocabulary for the drug concept.

Product Code

If the source codes are not available as RxNorm Codes, they need to be mapped to RxNorm Codes in OMOP CDM

drug_exposure_start_date yes date

The start date for the current instance of drug utilization. Valid entries include a start date of a prescription, the date a prescription was filled, or the date on which a drug administration procedure was recorded. Start Date

drug_exposure_end_date No date

The end date for the current instance of drug utilization. It is not available from all sources. End Date

drug_type_concept_id yes integer OMOP

A foreign key to the predefined concept identifier in the vocabulary reflecting the type of drug exposure recorded. It indicates how the drug exposure was represented in the source data: as medication history, filled prescriptions, etc.

This is automatically set as to one of the following: -38000177 (Prescription written) -38000178 (Medication list) -38000180-Inpatient administration from EHR -38000179-Physician administered drug (identified as procedure)

stop_reason No string(20)

The reason the medication was stopped, where available. Reasons include regimen completed, changed, removed, etc. Stop Reason

FP7-287800 SALUS


refills No number(3)

The number of refills after the initial prescription. The initial prescription is not counted, values start with 0. Refills

quantity No number(4)

The quantity of drug as recorded in the original prescription or dispensing record. Quantity

days_supply No number(4)

The number of days of supply of the medication as recorded in the original prescription or dispensing record. Days Supply

sig No string(500)

The directions ("signetur") on the drug prescription as recorded in the original prescription (and printed on the container) or dispensing record.

Fulfillment Instructions

prescribing_provider_id No integer

A foreign key to the provider in the provider table who initiated (prescribed) the drug exposure.

Prescribing Provider

visit_occurrence_id No integer

A foreign key to the visit in the visit table during which the drug exposure initiated.

Related Encounter

relevant_condition_concept_id No integer

SNOMED

A foreign key to the predefined concept identifier in the vocabulary reflecting the condition that was the cause for initiation of the drug exposure. Note that this is not a direct reference to a specific condition record in the condition table, but rather a condition concept in the vocabulary. Indication

FP7-287800 SALUS


drug_source_value No string(50)

The source code for the drug as it appears in the source data. This code is mapped to a standard drug concept in the vocabulary and the original code is, stored here for reference.

Product Code

5.1.3 Condition Occurrence

Condition Occurrences table records individual instances of the conditions suffered by Persons as

extracted from source data.


Table: Condition_Occurance

Condition/ Allergies and Intolerances

condition_occurrence_id yes integer

A system-generated unique identifier for each condition occurrence event. -


A foreign key identifier to the person who is experiencing the condition. The demographic details of that person are stored in the person table. Patient.ID

condition_concept_id yes integer

SNOMED

A foreign key that refers to a standard condition concept identifier in the vocabulary.

Condition.problem code (derived) Allergies and Intolerances. Adverse Event Type (coded) (derived)

If the source attributes are not available as SNOMED CT Codes, they need to be mapped to SNOMED CT Codes in OMOP CDM

condition_start_date yes date

The date when the instance of the condition is recorded.

Condition.start date Allergies and Intolerances.start date and time

FP7-287800 SALUS


condition_end_date No date

The date when the instance of the condition is considered to have ended. This is not typically recorded

Condition.end date Allergies and Intolerances. Date of end of reaction/event

condition_type_concept_id yes integer OMOP

A foreign key to the predefined concept identifier in the vocabulary reflecting the source data from which the condition was recorded, the level of standardization, and the type of occurrence. Conditions are defined as primary or secondary diagnoses, problem lists and person statuses.

This is automatically set as 38000245 (EHR problem list entry) in SALUS in OMOP instances

A Condition Occurrence Type is assigned based on the data source and type of condition attribute, including: o ICD-9-CM Primary Diagnosis from Inpatient and Outpatient Claims o ICD-9-CM Secondary Diagnoses from Inpatient and Outpatient Claims o Problem Concepts from EHRs

stop_reason No string (20)

The reason, if available, that the condition was no longer recorded, as indicated in the source data. Valid values include discharged, resolved, etc.

Condition.problem status Allergies and Intolerances. Outcome of reaction/event at the time of last observation

associated_provider_id No integer

A foreign key to the provider in the provider table who was responsible for determining (diagnosing) the condition.

Condition.treating provider


A foreign key to the visit in the visit table during which the condition was determined (diagnosed).

Condition.related encounter

FP7-287800 SALUS


condition_source_value No

string(50)

The source code for the condition as it appears in the source data. This code is mapped to a standard condition concept in the vocabulary and the original code is, stored here for reference. Condition source codes are typically ICD-9-CM diagnosis codes from medical claims or discharge status/disposition codes from EHRs.

Condition.problem code Allergies and Intolerances. Adverse Event Type (coded) (derived)

5.1.4 Visit Occurrence

The Visit Occurrence table contains all Person visits to health care providers, including inpatient,

outpatient, and ER visits. A Visit is an encounter for a patient at a point of care for a duration of time.

There could be several Providers involved in the patient's care during the Visit.


Table: Visit_Occurance Encounter

visit_occurrence_id yes integer

A system-generated unique identifier for each person's visit or encounter at a healthcare provider. -


A foreign key identifier to the person for whom the visit is recorded. The demographic details of that person are stored in the person table. Patient.ID

visit_start_date yes date The start date of the visit. Start Date

visit_end_date yes date

The end date of the visit. If this is a one-day visit the end date should match the start date. End Date

FP7-287800 SALUS


place_of_service_concept_id yes integer

OMOP CMS

A foreign key that refers to a place of service concept identifier in the vocabulary. EncounteryType?


A foreign key to the care site in the care site table that was visited.

Care Provider Location (Organisation)

place_of_service_source_value No string(50)

The source code used to reflect the type or source of the visit in the source data. Valid entries include office visits, hospital admissions, etc. These source codes can also be type-of service codes and activity type codes. EncounteryType?

5.1.5 Procedure Occurrence

Procedure occurrences table records individual instances of procedures performed on Persons

extracted from the source data.

Field Required Type

Standard Description


Table: Procedure_Occurance Procedure

procedure_occurrence_id yes integer

A system-generated unique identifier for each procedure occurrence. -


A foreign key identifier to the person who is subjected to the procedure. The demographic details of that person are stored in the person table. Patient.ID

FP7-287800 SALUS


procedure_concept_id yes integer

CPT-4 HCPCS ICD-9-Proc, ICD-9-CM, LOINC

A foreign key that refers to a standard procedure concept identifier in the vocabulary.

Procedure Type (coded) (derived)

Procedure Type codes shouls be converted in to CPT-4 HCPCS ICD-9-Proc, ICD-9-CM, LOINC codes

procedure_date yes date

The date on which the procedure was performed. Procedure Date

procedure_type_concept_id yes integer OMOP

A foreign key to the predefined concept identifier in the vocabulary reflecting the type of the procedure.

Procedure_Occurrence>procedure_type_concept_id automatically set as : -38003622-Procedure recorded as diagnostic code -38003621-Procedure recorded as lab test -380002750EHR order list entry

associated_provider_id no integer

A foreign key to the provider in the provider table who was responsible for carrying out the procedure. Procedure Provider

visit_occurrence_id no integer

A foreign key to the visit in the visit table during which the procedure was carried out. Related Encounter

FP7-287800 SALUS


relevant_condition_concept_id no integer

SNOMED

A foreign key to the predefined concept identifier in the vocabulary reflecting the condition that was the cause for initiation of the procedure. Note that this is not a direct reference to a specific condition record in the condition table, but rather a condition concept in the vocabulary. Indication

procedure_source_value no

string(50)

The source code for the procedure as it appears in the source data. This code is mapped to a standard procedure concept in the vocabulary and the original code is, stored here for reference. Procedure source codes are typically ICD-9-Proc, CPT-4 or HCPCS codes

Procedure Type (coded)

5.1.6 Observation

The Observation table contains all general observations from the following categories:

Lab observations (i.e., test results) from Medical Claims

Lab and other observations from Electronic Health Records

Chief complaints as captured in Electronic Health Records

General clinical findings, signs and symptoms

Radiology and pathology reports

General catch-all categories from various data sources that cannot be otherwise

categorized within the entities provided (Drug, Condition, Procedure)

FP7-287800 SALUS




Table:Observation Result

observation_id yes integer

A system-generated unique identifier for each observation. -


A foreign key identifier to the person about whom the observation was recorded. The demographic details of that person are stored in the person table. Patient.ID

observation_concept_id yes integer

LOINC SNOMED

A foreign key to the standard observation concept identifier in the vocabulary.

Result Type (Coded) (Dervived)

If the source codes are not available as LOINC or SNOMED Codes, they need to be mapped to LOINC or SNOMED Codes in OMOP CDM

observation_date yes date

The date of the observation Result Date

observation_time No date

The time of the observation. Result Date

FP7-287800 SALUS


value_as_number No number(14,3)

The observation result stored as a number. This is applicable to observations where the result is expressed as a numeric value. Result Value (Numeric)

value_as_string No string(60)

The observation result stored as a string. This is applicable to observations where the result is expressed as verbatim text, such as in radiology or pathology reports. Result Value (String)

value_as_concept_id No integer

A foreign key to an observation result stored as a concept identifier. This is applicable to observations where the result can be expressed as a standard concept from the vocabulary (e.g., positive/negative, present/absent, low/high, etc.). Result Value (Coded)

unit_concept_id No integer UCUM

A foreign key to a standard concept identifier of measurement units in the vocabulary. Unit (derived)

Unit should be converted to UCUM codes

FP7-287800 SALUS


range_low No number(14,3)

The lower limit of the normal range of the observation. It is not applicable if the observation results are non-numeric or categorical, and must be in the same units of measure as the observation value. Result Reference range

range_high No number(14,3)

The upper limit of the normal range of the observation. It is not applicable if the observation results are non-numeric or categorical, and must be in the same units of measure as the observation value. Result Reference range

observation_type_concept_id yes integer OMOP

A foreign key to the predefined concept identifier in the vocabulary reflecting the type of the observation

Automaticallt set as one of the following: 38000277: Lab observation numeric result 38000278: Lab observation text 38000279: Lab observation concept code result

FP7-287800 SALUS


associated_provider_id no integer

A foreign key to the provider in the provider table who was responsible for making the observation. Result Provider


A foreign key to the visit in the visit table during which the observation was recorded. Related Encounter

relevant_condition_concept_id No integer

SNOMED

A foreign key to the predefined concept identifier in the vocabulary reflecting the condition that was associated with the observation. Note that this is not a direct reference to a specific condition record in the condition table, but rather a condition concept in the vocabulary. Related Condition

observation_source_value No string(50)

The observation code as it appears in the source data. This code is mapped to a standard concept in the vocabulary and the original code is, stored here for reference. Result Type (Coded)

FP7-287800 SALUS


unit_source_value No string(50)

The source code for the unit as it appears in the source data. This code is mapped to a standard unit concept in the vocabulary and the original code is, stored here for reference. Unit

5.1.7 Observation Period

The Observation Period table is designed capture the time intervals in which data are being recorded

for the Person. An Observation Period is the span of time when a Person is expected to have the

potential of Drug and Condition information recorded. For claims data, observation periods are

equivalent to enrolment periods to a plan.

Analytical methods use Observation Period records to distinguish periods with no observed records

from periods where data are systematically not captured, such as a person not having insurance

coverage.



Table:Observation_period Patient

observation_period_id Yes integer

A system-generated unique identifier for each observation period. -


A foreign key identifier to the person for whom the observation period is defined. The demographic details of that person are stored in the person table. ID

observation_period_start_date Yes date

The start date of the observation period for which data are available from the data source.

Patient registration date

observation_period_end_date Yes date

The end date of the observation period for which data are available from the data source.

Patient de-registration date

FP7-287800 SALUS


5.1.8 Death

The Death table is designed to capture the time when a Person is deceased and causes of death.



Table:Death Death


A foreign key identifier to the deceased person. The demographic details of that person are stored in the person table. Patient.ID

death_date Yes date

The date the person deceased. If the precise date including day or month is not known or not allowed, December is used as the default month, and the last day of the month the default day. Date of Death

death_type_concept_id Yes integer OMOP

A foreign key referring to the predefined concept identifier in the vocabulary reflecting how the death was represented in the source data.

Automatically set as : 38003569 EHR record patient status "Deceased"

cause_of_death_concept_id No integer

SNOMED

A foreign key referring to a standard concept identifier in the vocabulary for conditions.

Cause of Death (derived)

If the coause of death is not available as SNOMED Codes, it needs to be mapped to SNOMED Codes in OMOP CDM

FP7-287800 SALUS


cause_of_death_source_value No

string(50)

The source code for the cause of death as it appears in the source data. This code is mapped to a standard concept in the vocabulary and the original code is, stored here for reference. Cause of Death

5.1.9 Location

The Location table represents a generic way to capture physical location or address information. Each

address or Location must be only present once in the table. Locations are used to define the addresses

for Persons, Care Sites and Organizations. Locations do not contain names; to construct a full address

that can be used on the Postal Service, the address information from the Location needs to be

combined with information from the Care Site or Organization (the Person table does not contain

name information).

5.1.10 Provider

The Provider table contains a list of uniquely identified health care providers (physicians).


Table:Provider Provider

provider_id Yes integer

A system-generated unique identifier for each provider. -

npi No string(20)

The National Provider Identifier (NPI) of the provider. Provider ID

dea No string(20)

The Drug Enforcement Administration (DEA) number of the provider. Provider ID

FP7-287800 SALUS


specialty_concept_id No integer CDC

A foreign key to a standard provider's specialty concept identifier in the vocabulary.

Provider Type (derived)

If the provider type is not available as CDC Codes, it needs to be mapped to CDC Codes in OMOP CDM


A foreign key to the main care site where the provider is practicing. Organistion

provider_source_value Yes string(50)

The identifier used for the provider in the source data, stored here for reference. Provider ID

specialty_source_value No string(50)

The source code for the provider specialty as it appears in the source data, stored here for reference. Provider Type

5.1.11 Organisation

The Organization table contains a list of uniquely identified health care organizations (hospitals,

clinics, practices, etc.).



Table:Organisation Organisation

organization_id Yes integer

A system-generated unique identifier for each organization. Here, an organization is defined as a collection of one or more care sites that share a single EHR database. -

FP7-287800 SALUS


place_of_service_concept_id No integer CMS

A foreign key that refers to a place of service concept identifier in the vocabulary.

Organisation Type (derived)

If the organisation type is not available as CMS Codes, it needs to be mapped to CMS Codes in OMOP CDM


A foreign key to the geographic location of the administrative offices of the organization in the location table, where the detailed address information is stored. address

organization_source_value Yes

string(50)

The identifier for the organization in the source data, stored here for reference. Organisation id

place_of_service_source_value No

string(50)

The source code for the place of service as it appears in the source data, stored here for reference.

Organisation Type

5.1.12 Care Site

The Care Site table contains a list of uniquely identified points of care, or an individual clinical

location within an organization. Each care site belongs to one organization. There might be more than

one Care Site in a Location (address).



Table:Care Site Organisation

care_site_id yes integer

A system-generated unique identifier for each care site. A care site is the place where the provider delivered the healthcare to the person. -


A foreign key to the geographic location in the location table, where the detailed address information is stored. address

FP7-287800 SALUS


organization_id No integer

A foreign key to the organization in the organization table, where the detailed information is stored. Organisation id

place_of_service_concept_id No integer CMS

A foreign key to the predefined concept identifier in the vocabulary reflecting the place of service.

Organisation Type (derived)

If the organisation type is not available as CMS Codes, it needs to be mapped to CMS Codes in OMOP CDM

care_site_source_value No

string(50)

The identifier for the care site as it appears in the source data, stored here for reference. -

place_of_service_source_value No

string(50)

The source code for the place of service as it appears in the source data, stored here for reference.

Organisation Type

FP7-287800 SALUS


6 ICH E2B(R2) SPECIFICATION BASED CONTENT

MODEL TEMPLATES

SALUS ICSR reporting tool supports semi-automatic reporting of ADE to regulatory authorities

(scenario 1) using the ICH E2B(R2) Electronic Transmission of Individual Case Safety Reports

Message Specification. ICH E2B(R2) is a standard used by the WHO Collaborating Centre for

International Drug Monitoring, whose database (named VigiBase) stores spontaneous reports in E2B

XML format. The European Medicines Agency (EMA) in Europe and Food and Drug Administration

(FDA) in USA also support the submissions of E2B forms for the reporting of ADE and propose Web

based Electronic submission systems. Although E2B specification is not widely used in Europe, it will

probably tend to become the standard international ICSR specification in the future, and for current

uses it is sufficiently detailed to cover most of the national ADE reporting forms information models.

However, some data elements are sometimes not covered by the E2B data model, but are specific to

local pharmacovigilance policies, for example: the description of the ethnic origin of the patient, by

the Italian Medicines Agency (AIFA) standard form used to report ADE in Italy is not present in

E2B(R2) data elements. To manage such data elements, it was not possible to extend the E2B data

model, which is a standard XML. Two solutions were then used: either using the comments fields

available in E2B to record the additional data (e.g. <reportercomment>); or to exclude this data from

the generated XML file.

The general organization of E2B(R2) sections is presented in Figure 2.

FP7-287800 SALUS


Figure 2 - Relational View of E2B Data Elements

6.1 E2B(R2) sections and Mapping to Common Data Elements16 The following subsections describe mappings between E2B data elements and SALUS CDEs. These

mappings are also available as a spread sheet in Appendix 1. The general objective of this mapping is

to enable the ICSR prepopulation process by ensuring that patient data needed by (i) the E2B(R2)

standard form or (ii) national adverse event reporting forms (AIFA Italian form in SALUS case) can

be extracted automatically from the patient EHR DWH.

It has to be noted that only E2B data elements needing to be prepopulated from EHR have been

mapped with CDEs. Indeed:

(1) The value of some E2B data elements can only be set manually by the GP because the related

information is not available in the patient EHR or can’t be extracted in an automated manner.

(2) The value of some E2B data elements is the same for all E2B reports:

Message Type (M.1.1) = “ichicsr”

Message Format Version (M.1.2) = “2.1”

Type of report (A.1.4) = “1” [for "Spontaneous"]

16 The description of the content of the E2B sections provided in this chapter comes from the ICH guideline

E2B (R2), Electronic transmission of individual case safety reports - Message specification (ICH ICSR DTD

Version 2.1), Final Version 2.3, Document Revision Feb. 1, 2001.

FP7-287800 SALUS


… (3) The value of some E2B data elements can be calculated on the basis of the value of other E2B data

elements:

The format used for dates (102 = Format CCYYMMDD; 610 = Format CCYYMM; 602 =

Format CCYY) can be automatically deduced from the date value entered.

The value of "Age at time of onset of reaction/event" (B.1.2.2a) can be calculated based on

the "Date of birth" (B.1.2.1b) and the "Date of start of reaction/event" (B.2.i.4b).

The “Duration of reaction/event” (B.2.i.6a) can potentially be calculated on the basis of “Start

date” (B.2.i.4b) and “End date” (B.2.i.5b).

… (4) The value of some E2B data elements can be set manually by the user for all subsequent ICSR

forms.

E2B data describing the Primary source (A.2.1): the GP reporting the ADE

E2B data describing the Sender (A.3.1): Name and address of the hospital of the GP or Name

of person in the company or agency who is responsible for the authorization of report

dissemination.

E2B data describing the Receiver (A.3.2), for example UMC.

E2B data describing which version of MedDRA is used.

…

6.1.1 Patient characteristics. Demographics (B.1.1 to B.1.6) The identification of the patient may be prohibited by certain national confidentiality laws or

directives. The information should be provided when it is in conformance with the confidentiality

requirements. Because it is often difficult to obtain all the information, any one of several data

elements is considered sufficient to define an identifiable patient (e.g., initials, age, sex).

Field Req. Type Stand. Descrip. Corresponding CDE Rq

E2B section: B.1.1 to B.1.6 Patient name or initials

Only one of those items is mandatory

10AN Patient.GivenName. Patient.FamilyName

Hospital record number

20AN Patient.ID

Date of birth CCYYMMDD

CCYYMMDD Patient.DateOfBirth

Weight (kg) 6N Result.Value Weight in E2B must be specified in kg, Vital signs.Unit must thus be used to see what unit is used in EHR and proceed to necessary conversion

Height (cm) 3N Result.Value Same remark for Height and cm

Sex 1N ISO 5218 1=Male; 2=Female

Patient.Gender

Last menstrual period date

8N

Pregnancy.LastMenstrualPerio

dDate

Ethnic origin (AIFA)

FREE TEXT

Patient.Ethnicity

FP7-287800 SALUS


6.1.2 Relevant medical history and concurrent conditions (B1.7) Medical judgment should be exercised in completing this section. Information pertinent to

understanding the case is desired such as diseases, conditions such as pregnancy, surgical procedures,

psychological trauma, etc.

The mappings presented in the following tables refer to both SALUS CDE “conditions” sections

available: (1) “Condition (Past Medical History)” and (2) “Condition (Active

Problems/Symptoms)”.


E2B section: B.1.7 Relevant medical episode (disease/ surgical procedure /etc.)

No 250AN MedDRA Id Condition.ProblemCode Need the conversion from the controlled vocabulary used to encode the observation (i.e. SNOMED-CT) to MedDRA code

Start Date No 8N CCYYMMDD or CCYYMM or CCYY

Condition.TimeInterval

End Date No 8N CCYYMMDD or CCYYMM or CCYY

Condition.TimeInterval

Comments No 100AN Condition.Comments

Since E2B B1.7 section covers all potentially relevant categories of medical episodes (not only

diseases), the E2B B1.7 data elements listed in the previous table can also be mapped to the SALUS

CDE items of the (3) “Procedures” and of the (4) “Allergies/Intolerance” sections.


E2B section: B.1.7 Relevant medical episode (disease/ surgical procedure /etc.)

No 250AN MedDRA Id Procedures. Type Need the conversion from the controlled vocabulary used to encode the procedure (i.e. SNOMED-CT) to MedDRA code


Procedure.TimeInterval


Procedure.TimeInterval

Comments No 100AN Procedures.Comment


E2B section: B.1.7

FP7-287800 SALUS


Relevant medical episode (disease/ surgical procedure /etc.)

No 250AN MedDRA Id Condition.ProblemCode Need the conversion from the controlled vocabulary used to encode the problem (i.e. SNOMED-CT) to MedDRA code


AdverseEvent.TimeInterval



Comments No 100AN AdverseEvent.Comment

6.1.3 Relevant past drug history (B1.8) This E2B section concerns drugs previously taken, but not those taken concomitantly or drugs which

may have potentially been involved in the current reaction(s)/event(s). Information concerning

concomitant and other suspect drugs should be included in section B4. The information provided here

can also include previous experience with similar drugs.

As for the previous B1.7 section, medical judgment should be exercised in completing B1.8 section.

When completing the item concerning the name of the drug it is important to use the words provided

by the primary source. Trade name, generic name or class of drug can be used. The term "none"

should be used when appropriate (e.g. when there is no previous exposure to the drug or vaccine, or

no previous reaction following exposure).


E2B section: B.1.8 Name of Drug as Reported

No 100AN Medication.MedicationInformation


Medication.TimeInterval


Medication.TimeInterval

Indication No 250AN MedDRA Id Medication.Indication.Condition

Reaction No 250AN MedDRA Id Medication.Reaction.AdverseEvent Need the conversion from the controlled vocabulary used to encode the reaction (i.e. SNOMED-CT) to MedDRA code

6.1.4 Reaction(s)/event(s) (B.2) E2B section used to describe one or several reaction/event that the patient manifests.

Field Req Type Stand. Descrip. Corresponding CDE Rq

FP7-287800 SALUS


E2B section: B.2 Reaction/event as reported by primary source


200AN The original reporter's words and/or short phrases used to describe the reaction/event.

AdverseEvent.Comment Only partial match because the CDE will not necessarily record the description of the reaction using original reporters’ word

Reaction/event in MedDRA (LLT)

250AN MedDRA Id

Condition.ProblemCode Need the conversion from the controlled vocabulary used to encode the reaction(i.e. SNOMED-CT) to MedDRA code

Reaction/event in MedDRA (PT)

250AN MedDRA Id

Condition.ProblemCode Need the conversion from the controlled vocabulary used to encode the reaction (i.e. SNOMED-CT) to MedDRA code

Date of start of reaction/event

No 12N CCYYMMDDHHMM or CCYYMMDD or CCYYMM or CCYY


Date of end of reaction/event

No 12N CCYYMMDDHHMM or CCYYMMDD or CCYYMM or CCYY


Outcome of reaction/event at the time of last observation

No 1N 1=recovered/resolved; 2=recovering/resolving; 3=not recovered/not resolved; 4=recovered/resolved with sequelae; 5=fatal; 6=unknown

AdverseEvent.Status Need the conversion from the value set used in EHR (e.g. Snomed-CT for CDA) and the value set used in E2B.

The same remark as described in section 6.1.3for Allergies/Intolerance.Adverse Event Type SALUS CDE item applies for the situation of E2B B.2 data elements.

6.1.5 Results of tests and procedures relevant to the investigation of the patient (B.3) This section should capture the tests and procedures performed to diagnose or confirm the

reaction/event, including those tests done to investigate (exclude) a non-drug cause (e.g. serologic

tests for infectious hepatitis in suspected drug-induced hepatitis). Both positive and negative results

should be reported. While structured information is preferable, provisions have been made to transmit

the information as free text.


E2B section: B.3 Date No 8N CCYYMMD

D or CCYYMM or CCYY

Lab Results.Result Date

Test No 100AN Result.Type

Result No 50AN Result.Value.CD

Unit No 35AN Result.Value.PQ

Normal low range No 50AN Result.ReferenceRange Normal high range No 50AN Result.ReferenceRange

FP7-287800 SALUS


Description (free text) No 2000AN Result.Comment

6.1.6 Drug(s) information (B.4) This section covers both suspect drugs and concomitant medications including biologicals. In

addition, the section can be used to identify drugs thought to have an interaction. For each drug, the

characterization of the drug role (B.4.k.1) is that indicated by the primary reporter (i.e. the original

source of the information).

Field Rq. Type Stand. Descrip. Corresponding CDE Rq

E2B section: B.4 Proprietary medicinal product name


70AN Medication.MedicationInformation

Active Drug substance names

100AN Medication.MedicationInformation

dose (number) No 8N Medication.Dose dose (unit) No 3N See E2B value sets Medication.Dose number of units in the interval

No 3N Medication.Frequency

Pharmaceutical form (Dosage form)

No 50AN

Medication.ProductForm

Route of administration

No 3N See E2B value sets Medication.Route

Indication for use in the case

No 250AN MedDRA Id Medication.Indication.Condition

Need the conversion from the controlled vocabulary used to encode the indication (i.e. SNOMED-CT) to MedDRA code

Date of start of drug

No 8N CCYYMMDD Medication.TimeInterval

Date of last administration

No 8N CCYYMMDD Medication.TimeInterval

Duration of drug administration

No 5N

Medication.Duration

FP7-287800 SALUS


7 SALUS 13606 ARCHETYPE LIBRARY

ERS has developed a library of 13606 artefacts that matched the required data sets by SALUS pilot

applications as described in Section 3.1.

The CEN/ISO 13606 EHR Communication standard is designed to define EHR-Extracts to transport

data between two or more EHR systems. The standard consists of 5 parts:

13606-1: Reference Model that deals with the structure of any document, versioning, digital

signature.

13606-2: Archetype Reference Model that allows the construction of archetypes. Archetypes

are artefacts that define what can be documented about a topic according to healthcare

providers on one hand. On the other hand it is a computer processable format. The Archetype

Description Language (v1.4) is used.

13606-3: Term list. Supporting value sets

13606-4: Privacy. The Patient mandate that allows the construction of an expression as part of

the Reference Model/Archetypes that define who has access to what data.

13606-5: A minimal specification needed of the exchange of EHR-extracts.

Because the CEN/ISO 13606 standard allows many degrees of freedom to define archetypes a need

was felt to design and rely on a limited set of semantic patterns with which archetypes are

constructed. As a response to this need, ERS has developed the Semantic Interoperability Artefact

Modelling Method (SIAMM) that is published by the EN13606 Association (www.en13606.org).

SIAMM is also used in the SemanticHealthNet project and part of the Information Architecture

Reference Model of Health Services Executives Ireland. An epSOS Patient Summary based on

CEN/ISO 13606 and SIAMM is developed for HSE Ireland (Public Healthcare of Ireland).

SIAMM17 was created because:

there were too many degrees of freedom to model archetypes,

there were too many differing definitions of core concepts we need when we model

archetypes,

there was an ad-hoc way to deal with processes in healthcare provision,

there were no formal rich bindings to coding systems and ontologies,

there was no harmonisation with CEN/ISO System of Concepts for Continuity of Care

(ContSys) and CEN/ISO Health Information Services Architecture (HISA).

The main purposes of SIAMM are:

o Create standardised generic semantic patterns that can be specialised to create any archetype

that support the expression of the: What, When, Where, Why, Who and How in a fixed

standardised way.

17 Back ground information about SIAMM and ContSys will be made available in an Appendix 3

http://www.en13606.org/

FP7-287800 SALUS


o Harmonise with ContSys

o Harmonise with HISA

o Harmonise with coding systems

o Harmonise with value sets, terminology lists

o Harmonise with (health) ontologies

o Harmonise with libraries/registries of archetypes

Some requirements used in the process of developing SIAMM:

Simple basic Reference Model

Each artefact must define, as much as possible, all semantics inside the artefact

Full list of meta-data about each file

Full list of meta-data about the content of the file, the model

Common set of shared concepts how to model (patient system, clinical process, etc.)

Ability to express: quantitative data, semi-quantitative data, and qualitative data (negation)

Ability to deal with semantic ordinals (in order to define semi-quantitative (severity,

classifications)

Ability to deal with certainty and state models for all things documented

Uniform way to model the location in the patient system, organ systems, including anatomy

and laterality)

Uniform way to deal with localisation in time in absolute and relative ways

Uniform way to deal with localisation in space in absolute and relative ways

Uniform way to deal with who are involved (participation) in what roles

Uniform way to deal with the how, the method. Each entry specialisation will have its own

methods

Uniform way to deal with the why, the causality, the clinical thinking in semantic links

Uniform way to deal with defined protocols, clinical pathways, other workflow

Uniform way to deal with bindings to coding systems, ontologies, and express rules plus

calculations. Combining the expression in an extensional and intentional way as much as

possible

Uniform way to express the function of the artefact (used for storage, query, presentation)

Uniform way to specialise in a standardised way the generic RM classes and provide them

with standardised names and functionality(such as for the Entry class:Observation,

Evaluation, Instruction, Action)

FP7-287800 SALUS


Uniform way to define the intersections with the CEN/ISO System of Concepts for

Continuity of Care and the CEN/ISO Health Information Services Architecture.

Uniform way to deal with references inside artefacts, between artefacts, between data that is

instantiated, and between supporting services (coding systems, lab batteries, demographic

servers, protocols, clinical pathways, clinical decision support, etc.) by means of pointers to

these services or including the results of the services)

Uniform way to deal with artefacts that are used inside systems and that are used in exchange

formats (where all pointers need to be resolved)

In parallel CEN/tc261 and EN13606 Association are in the process to align and find the intersections

between the 13606 and CEN/ISO13940 System of Concepts for Continuity of Care18. (ContSys).

ContSys is a terminological standard that defines at the terminological level all concepts related to

healthcare, processes, actors, and documentation there off.

General Purpose Information Components EN18422 is a CEN/tc251 standard representing the data

requirements as used in 15 years of Edifact Message production in Europe.

The present SALUS 13606 Archetype Library is based on 13606, 13940, 14822 and SIAMM.

7.1 EN13606 Archetype Library

The library is developed in phases:

· Generic Pattern Master. This is a collection of artefact fragments (patterns) that are used to

construct on generic ENTRY class artefact. · This generic ENTY artefact is used to construct ContSys aligned artefacts that model

processes in healthcare. · With the CEN EN14822 General Purpose Information Components as bases specific

Complex Cluster Models are produced to model for example the detailed data around

medicinal products and prescription, etc. · Finally the SALUS Composition Template is produced using the ContSys aligned ENTRY

specialisations and the Complex Cluster Models. This library is also available as a package as an appendix of this deliverable (Appendix 4).

7.1.1 EN13606 Artefacts Introduction Archetypes are constraints on a Reference Model. 13606 Artefacts are constraints placed on the

13606-1 Reference Model. The static, stable, Reference Model is a set of classes that define the

structure of any document and allows the archiving of these documents. An Archetype Object Model

allows the construction of Documents and Clinical Statements defined as constraints on the Reference

Model defined as UML model. Any data point defined by an Archetype can be stored and queried.

The supported document structure is:

a. EHR-Extract: b. Composition, c. Section, d. Entry, e. Cluster, f. Elements, g. Folder.

18 http://www.datadictionary.nhs.uk/contsys/web_site_content/navigation/main_menu.asp

http://www.datadictionary.nhs.uk/contsys/web_site_content/navigation/main_menu.asp

FP7-287800 SALUS


Figure: EN 13606 EHR-Extract Reference Model

FP7-287800 SALUS


Each part of the document structure serves a well defined purpose as is reflected by the attributes of

that class. On top of the static Reference Model, the Archetypes allow a very flexible expression of

healthcare needs.

Each Composition is built using one or more nested Sections as chapters with a heading. Each

Composition or Section can be filled with ENTRIES. Compositions allow to mimic screens or reports.

ENTRIES are clinical statements that fully describe a data point in its full context. ENTRIES can be

structured using the CLUSTER construct. ENTRIES and CLUSTERS are populated by ELEMENTS

that hold the data points plus its associated Data Type.

In spite of the EN13606 specification too many degrees of freedom exist to define archetypes.

SIAMM defines one pattern for the construction of archetypes thereby decreasing the degrees of

freedom considerably.

The 13606 archetypes are produced following a SIAM method. This Semantic Interoperability

Artefact Modeling Method (SIAMM) is described in Appendix 3. SIAMM secures that all ENTRY

artefacts are defined using one generic pattern that describes the What, Where, When, Why, Who and

How.

7.1.2 Source Generic Artefacts/SIAMM

The basic SIAMM pattern that can be used to create all kinds of archetypes but must be used for

Clinical Statements (ENTRY archetypes) consists of the following parts (see the figure above):

• WHAT: consisting of the ‘NamedObject’ and ‘ResultValues’ CLUSTERS

• Context: consisting of the WHERE (Localisation in Patent System, Time and Space), WHY

(Reasons why it is documented), WHO (who and what is Participating in what role, etc.), HOW

(ContextHow with the environmental factors that influence the interpretation of the Clinical

Statement). In addition the Meta-Data about the artefacts, its uses and has relation to the 13606 Reference Model

and ContSys. The next table describes several possible attributes of this pattern:

FP7-287800 SALUS


MetaDataArtefact

ELEMENT name Description Setting used in SALUS

Template

ArtefactUse Codes for the use of the artefact

o Persistence

o Querying

o InputExchange

o OutputExchange

o Presentation

Indicates whether the template is

constrained for: Input, Output or

Querying

ProcessContext Codes for the process context the

artefact is used in

o Diagnostic

o Therapeutic

o Administrative

o Management

o ReUse

Indicates whether the template is

constrained for: Clinical

documentation (either Diagnostic or

Therapeutic) in order to make the

data query-able.In reports the data

points are labelled as Administrative

and are NOT query-able.

ProcessPattern Codes for one of the five SIAMM

patterns for an ENTRY class

o Order

o Execute

o Assess

o ResultCollection

(summary)

o Inference

Indicates that the data is the result of

a ResultCollection process.

TargetReferenceModel Provide the name + version of the

Reference Model

(e.g. En13606:2008 or

SIAMM:2013, etc)

Indicates that the source Reference

Model is 13606

TargetReferenceModelClass Specify what class of the RM is

used as starting point:

o EHR-Extract

o Folder

o Composition

o Section

o Entry

o Cluster

o Element

TargetReferenceModelClassType Codes for the binding with one

ContSys concept

Indicates the ContSys concept that

describes this artefact the best.

The detailed meaning can be found

in the WHAT:NamedObject branch

of the ENTRY archetype (Name and

NameType)

FP7-287800 SALUS


MetaDataArtefact

ELEMENT name Description Setting used in SALUS

Template

TargetReferenceModelClassType Codes for the kind of artefact:

o Observation

o Evaluation

o Instruction

o Action

Indicates that the SALUS template

in its ENTRIES are the result of an

Observation.

Finally in several places it is possible to indicate: Certainty, Status and the Presence or Absence).

In several places Objects play a role and data about these Living and Non-living objects needs to be

documented. Demographics play a role. SIAMM relies on the CEN/ISO standard EN22220

Identification of the Subject of Care to model the demographics.

Specific topics need specific detailed Complex Cluster Models in pre-defined places in order to be

able to define topics like: medicinal products, medical devices, lab tests, questionnaires, scales, etc.

The SIAMM pattern is constructed using two Modeling Styles:

Attribute Modeling style for specialisations. Procedure Modeling style.

Attribute Modeling style

The generic SIAMM pattern is constructed such that when archetypes are specialised only data fields

of ELEMENT classes are changed to reflect a more detailed concept.

The Attribute Modeling style is a consequence of the fact that each ENTRY Archetype will be the

same structure using the same generic names for the nodes. Only data fields in the ELEMENT class

are used to indicate the meaning.

The modeling style that is used by many others until now is the Class modeling style. In this style the

names of the classes in the archetype are constrained to reflect more detailed concepts. (e.g. Finding -

> Palpation - > Palpation of the Liver - Palpation of the Liver of an Infant, etc.)

Procedure Modeling style

Archetypes are used aligned with the CEN/ISO standard ContSys. Each ENTRY archetype models

either the Ordering, Execution, Assessment or ResultCollection of a procedure.

FP7-287800 SALUS


In the SALUS Template two basic CONTSYS archetypes are used: HealthActivity, HealthCondition.

7.1.3 Archetype Libraries used in SALUS Template ContSys

With SIAMM basis archetypes are created (mostly ENTRY-type Clinical Statements). The alignment

with CEN/ISO 1394019 System of Concepts for Continuity of Care results in Clinical Statements that

model that what needs to be documented as the result of processes. In principle processes are Ordered,

Executed, Assessed and the Results are collected after termination of the process.

ContSys defines two basic classes of documentation:

Health Issue Health Activity Each of these can be specialised further in great detail.

GPICS

General Purpose Information Components (GPICS) (CEN 1482220) describe the data requirements

during 15 years of European Message standard definitions.

Depending on the specialization, associated Complex Cluster Models are used inside the artefact to

deal with the details. In particular in the WHAT.Results branches and HOW.Method branches of the

SIAMM pattern these Complex Cluster Models are used. These Complex Cluster Models model

things like: specimens, medicinal products, environmental factors during the physical exams, etc.

In SALUS notably the medicinal products parts are derived from the GPICS standard.

7.1.4 SALUS Specialised Generic Artefacts and SALUS COMPOSITION Template

The SALUS data set is translated into a Template describing how the data will be exchanged in the

SALUS project using 13606 archetypes.

The SALUS COMPOSITION Template describing the SALUS data requirements is considered to be

the output of a procedure that queries the data base. The execution of this ReportProducing procedure

could have been modeled using a specific SIAMM ENTRY archetype, because not every detail needs

to be documented in an EHR. This ReportProducing archetype generates output. It is called the

ResultCollection after a successful termination of this process. The data as queried or entered during

data capture is transformed into the SALUS COMPOSITION Template in a separate process step.

The data that is exchanged in the SALUS COMPOSITION Template will contain no new data about

the patient system, but collects a subset of re-used data for reporting or other re-use purposes. Each

Clinical Statement will reflect this fact in the branch MetaDataArtefact.In case this SALUS

COMPOSITION Template is used to accept data that can be labelled as new the settings in the

MetaDataArtefact branch must be updated to reflect that the data is query-able.

The SALUS Composition Template is based on the second release of SIAMM. This template defines

the full SALUS specification. Using the Link-EHR editor various human and machine readable

exports were produced: (FreeMind Map, Excel, HTML, ADL1.4, Schematron, XML Data

Instantiation). This new template is available as Appendix 4 of this deliverable.

The FreeMind MindMap below is generated from the SALUS COMPOSITION Template:

SALUSPatientReportTemplate. It shows only the first 3 -4 layers. The full Mind Map is available in

appendix 4.

19 http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=58102 20 http://www.nen.nl/NEN-Shop/Norm/CENTS-1482242005-en.htm

http://www.nen.nl/NEN-Shop/Norm/CENTS-1482242005-en.htm

FP7-287800 SALUS


The next table presents the binding of the SALUS Artefact names with the ContSys definitions and its

specializations, the associated Complex Cluster Model and Comments.

Artefact name ContSysSpecialisation

path

Complex Cluster

Model

Comments

SalusCodes - - Ad hoc ENTRY to

collect the codes and

coding systems used

SalusAllergiesIntollerances HealthIssue/HealthCondition/O

bservedCondition/Allergy_Into

llerance

Salus/Allergy_Intolea

nce/CCM

Ad-hoc Salus complex

Cluster Model

SalusFamilyHistory HealthIssue/HealthCondition/O

bservedCondition/FamilyHisto

ry

Salus/FamilyHistory/C

CM


Cluster Model

SalusHcConditionsActive HealthIssue/HealthCondition/H

ealthProblem/HealthProblemA

ctive

Salus/ProblemActive/

CMM


Cluster Model

SalusHcConditionsPassive HealthIssue/HealthCondition/H

ealthProblem/HealthProblemPa

ssive

Salus/ProblemPassive/

CMM


Cluster Model

SalusLabResults HealthIssue/HealthCondition/O

bservedCondition/LabTest

Salus/LabClusterMode

l


Cluster Model

SalusMedications HealthcareActivity/Healthcare

ActivityElement/HealthcareTre

atment/MedicinalProduct

Medication/CMM Derived from EN13606

Library based on GPICS

SalusPregnancy HealthIssue/HealthCondition/O

bservedCondition/Pregnancy

- -

FP7-287800 SALUS


Artefact name ContSysSpecialisation

path

Complex Cluster

Model

Comments

SalusProcedures HealthcareActivity/Healthcare

ActivityElement/HealthcareTre

atment/

Salus/Procedure/CMM Ad-hoc Salus complex

Cluster Model

SalusSocialHistory HealthIssue/HealthCondition/O

bservedCondition/SocialHistor

y

Salus/SocialHistoryC

MM


Cluster Model

SalusVitalSigns HealthIssue/HealthCondition/O

bservedCondition/

- A selected set of findings

will be allowed (e.g.

Systolic/Diastolic blood

pressure, etc.

SalusEncounters HealthRelatedPeriod/Healthcar

eActivityPeriod/ContactPeriod

- -

SalusHcProvider HcActor.HcProvider - -

SalusPatient HcActor.SubjectOfCare - -

SalusRegistration/Deregistrat

ion

- - -

FP7-287800 SALUS


8 CONTENT MODULES to be used in ROCHE Scenario

Within the scope of SALUS project, ROCHE has defined a pilot application scenario demonstrating

the usage of EHRs as secondary use data sources for drug safety studies. In particular ROCHE has

defined an example study definition to collect a data set “to estimate incidence rates of Congestive

Heart Failure (CHF) in diabetic patients with a recent acute coronary syndrome (ACS) event and to

estimate incidence rates of CHF in patients on different diabetic medications”.

Roche is conducting clinical trials in both acute coronary syndrome (ACS) patients and in ACS

patients with diabetes. Whilst the trials are blind, it is important to compare the observed overall

incidence rate of an important adverse event like CHF in the trials with that in similar background

populations. Such a comparison helps to provide a context to the observed incidence and enables us to

identify any potential safety concerns earlier on (e.g. if the observed incidence in the trial is greater

than the background).

In SALUS we would like to enable a semi-automatic approach to collect data sets from EHR Sources

given the eligibility criteria and data collection set definition. The envisioned flow is as follows:

Safety analyst defines the data collection set and eligibility criteria from the local data

elements maintained in the pharmaceutical company which are defined in reference to

CDISC Data set definitions like SDTM variables. In other words, SDTM variables are used

to annotate the meaning of data elements in data set definitions.

SALUS Services takes this machine processable data set definition and query the EHR

Sources, retrieve the medical summaries of the eligible patients, and de-identify them.

By making use of the annotations in "data collection set" definition (possibly SDTM

variables), SALUS Services process the medical summaries automatically, and extract the

relevant information from these medical summaries, and construct the data set collections for

eligible patients. The data set collection is converted to a model (which can be spreadsheets,

SAS files, to be decided by safety analyst) by SALUS Services, and sent back to safety

analyst.

Safety analyst imports these data set collections to the local system and runs the analysis

methods implemented either in “R” or as SAS Methods.

Based on this initial workflow definition, we have discussed and identified the following standards to

be used in defining the content models for this scenario.

Metadata standards:

- CDISC SDTM and Roche extension SDTM

Data terminology/coding standards:

- SDTM and Roche SDTM Submission Values

- MedDRA: PREFERRED_TERM_CODE and SYSTEM_ORGAN_CLASS_CODE

- NCI codes, mapped to MedDRA codes

Data communication standard:

- CDISC define.xml; based on the XML schema of ODM (http://www.cdisc.org/define-

xml)

- Note: OMOP (Observational Medical Outcomes Partnership) could be used in the

future: common data model for observational pharmacovigilance, http://omop.org/;

to be developed from end 2013-2016 under FDA umbrella

Output formats: xls, csv, SAS

In the following sub sections first brief information about these selected standards will be provided,

then the definition of the data collection set through the selected metadata and data terminology

standards will be presented.

http://www.cdisc.org/define-xml

http://www.cdisc.org/define-xml

http://omop.org/

FP7-287800 SALUS


8.1 CDISC Study Data Tabulation Model (SDTM) and Define.xml

The Clinical Data Interchange Standards Consortium (CDISC)21 is a non-profit organization whose

standards bear the same name. CDISC standards are actively being used by the clinical research

community especially for the set-up and execution of clinical trials.

The Study Data Tabulation Model (SDTM)22 defines a standard structure for human clinical trial data

tabulations that are to be submitted as part of a product application to a regulatory authority so that the

regulatory authority can execute their review tools on them. It is widely accepted as the submission

standard for clinical trials.

SDTM is built to record the observations collected about subjects who participated in the clinical

study. Each observation can be described by a series of variables. The observations are stored in a flat

file, termed as a “data set” which is a table with one or more rows and columns. Each row of the

dataset represents a single observation and each column represents one of the variables. A collection

of observations on a particular topic is considered a domain. CDISC provides data set models for the

identified domains (such as Demographics, Medical History, Adverse Events) listing the allowed

variables in these data sets, presenting the allowed terms for these variables by referencing controlled

terminologies, notes on proper usage, and examples. For example, “Subject 101 had mild nausea

starting on Study Day 6” is an observation that belongs to the “Adverse Events” domain in a clinical

trial. Similarly, “Animal 525 weighed 250 grams on Study Day 6” would represent an observation

belonging to the “Body Weights” domain in an animal toxicity study. Each observation can be

described by a series of named variables which normally corresponds to a column in a dataset. For

example, in the observation “Subject 101 had mild nausea starting on Study Day 6”, the “Topic

variable” value is the term for the adverse event, “nausea”. The “Identifier variable” is the subject

identifier, “101”. The “Timing variable” is the start date, which captures the information, “starting on

Study Day 6”, while a “Variable Qualifier” is the severity, the value for which is “mild”. Additional

“Timing and Qualifier variables” could be included to provide the necessary detail to adequately

describe an observation.

Each dataset or table is accompanied by metadata definitions that provide information about the

variables used in the dataset. The metadata are given in a data definition document named ``Define"

that is submitted along with the data to regulatory authorities.

A sponsor should only submit domain datasets that were actually collected (or directly derived from

the collected data) for a given study. In line with this requirement, when creating submissions, a

sponsor may drop certain variables from the dataset model, and the corresponding descriptions from

the “Define” data definition document, but new variables must not be added, and existing variables

should not be renamed or modified for novel usage.

Previously ``Data Definition Document" was provided in pdf format known as “define.pdf”.

However, to increase the level of automation and improve the efficiency of the Regulatory Review

process by making this file machine processable, its XML version is specified.

CDISC “Define.xml” standard23, also termed as “Case Report Tabulations Data Definitions”, provides

the list of the datasets together with a detailed description of their contents for submission to a

regulatory authority. It is based on an extension to the CDISC Operational Data Model (ODM).

21 http://www.cdisc.org/

22 http://www.cdisc.org/sdtm

23 http://www.cdisc.org/define-xml

FP7-287800 SALUS


8.2 Definition of Data Collection set through SDTM variables and Terminology

System codes The Data requirements of ROCHE scenario have been first identified in D8.1.1. After CDSISC

SDTM variables have been selected by ROCHE to annotate the data elements, we have worked on

representing these data collection set data items in terms of CDISC SDTM variables and together with

the MedDRA and/or NCI codes. As the source data will be coded with ICD10-GM and ICD9-CM,

ROCHE has also annotated the data elements with these code systems when possible to guide

terminology reasoning process.

The list of data items in the data collection set had been identified as follows:

Patient id (Pseudonym)

Sex

Date of birth (or year of birth)

Date of ACS event

Date of ACS +30 days (Start date)

History of type 2 diabetes (T2D) before start date (Y/N)

Date of the first T2D diagnosis date ever

Average HbA1C over the 12 months before start date (will be missing for

most non diabetic pts)

Average systolic BP over 12 months before start date

Average diastolic BP over 12 months before start date

History of hypertension before start date (Y/N)

Last BMI before start date

Last weight before start date

Ever smoked before start date(Y/N)

Smoked within the last 3 months of start date(Y/N)

Taken Sulfonylurea anytime within 3 months before start date (Y/N)

Taken metformin anytime within 3 months before start date (Y/N)

Taken insulin anytime within 3 months before start date (Y/N)

Taken Thiazolidinediones (Glitazones) anytime within 3 months before start

date (Y/N)

Taken other oral anti-diabetic drugs within 3 months before start date (Y/N)

Had a CHF before start date (Y/N)

FP7-287800 SALUS


Had a CHF after start date (Y/N)

Date of CHF after start date

Patient died any time after start date (Y/N)

Date of Death

The representation of these data items in terms of SDTM variables and the selected terminology

system codes are depicted in the following table.

For some of the data items, like “Patient id”, or “Sex”, the annotation with SDTM variables are

straight forward, as there is a single corresponding SDTM variable. When necessary the possible

values are indicated in the “SDTM Submission Value” column. When necessary, the ROCHE

Submission Value is indicated when an extension to SDTM Submission Value Set is required (e.g.

TOBACCO CONSUMPTION).

For some other data items, like “Date of Acute Coronary Syndrome (ACS) event”, annotation with a

number of SDTM variables is needed:

First the ACS event in the patient’s medical history should be indicated through the

“MH.MHPTCD” code with a selected MedDRA or NCI code. The body system code should be indicated through the MH.MHBDSYCD SDTM variable

and the selected MedDRA code.

Finally the “Start date” data item should be annotated with MH.MHSTDTC SDTM variable.

For such data items, a number of rows have been reserved for a single “Original Data Element”,

indicating composition of a number of “Singular Data Elements”.

The Post Marketing Safety Study tool that is currently being developed will enable such annotation of

data items in the data collection set with SDTM variables. Then the tool will identify the mappings of

these data element definitions to SALUS Common Data Elements maintained in the SALUS CDE

Repository (SALUS Semantic MDR) (see SALUS Deliverable 4.2.1 for a complete list of CDEs). In

the SALUS Semantic MDR, the mappings of these abstract CDEs to SALUS Source content models,

such as SALUS Common Information Ontology, are available (see SALUS Deliverable 4.2.2 for

these mappings), hence the tool will be seamlessly able to access the source data retrieved from EHRs

although the data collection set is coded with CDISC SDTM variables.

FP7-287800 SALUS


Original Data Element

Singular Data Element Name

SDTM Name

SDTM Code List Code

SDTM Submission Value

Roche Submission Value

MedDRA PTC

MedDRA SOCC

NCI Code

ICD10-GM

ICD9-CM

Patient id Patient id DM.USUBJID

Sex Sex DM.SEX C66731 F C16576

M C20197

UN C45908

U C17998

Date of birth Date of birth DM.BRTHDTC

Date of Acute Coronary Syndrome (ACS) event ACS event

MH.MHPTCD

10051592 C53652

MH.MHBDSYCD 10007541

Start date of ACS event

MH.MHSTDTC

Date of Acute Myocardial Infarction

Acute Myocardial Infarction

MH.MHPTCD

10000891 C35204 I21.- 410


Start date of Acute Myocardial Infarction

MH.MHSTDTC

Date of Unstable Angina

Unstable Angina Pectoris

MH.MHPTCD

10002388 C66911 I20.0 411.1


Start date of Unstable Angina Pectoris

MH.MHSTDTC

History of type 2 diabetes (T2D) before start of ACS (Y/N) T2D

MH.MHPTCD

10067585 C26747 E11.- 250.00


FP7-287800 SALUS


Start date of T2D

MH.MHSTDTC

Date of the first T2D diagnosis ever

[='T2D' + 'Start date of T2D']

Average HbA1C over the 12 months before start of ACS

Test name: HbA1C (glycated hemoglobin)

LB.LBTEST C67154

Hemoglobin A1C C64849

LB.LBTESTCD C65047 HbA1C

Test value LB.LBORRES

Test unit LB.LBORRESU

mmol/mol

Test time indicator

LB.LBDTC

Average systolic blood pressure (BP) over 12 months before start of ACS

Systolic BP measurement

VS.VSTEST C67153

Systolic Blood Pressure C25298

VS.VSTESTCD C66741 SYSBP

Systolic BP value

VS.VSORRES

Systolic BP unit

VS.VSORRESU C66770 mmHg C49670

Systolic BP time indicator

VS.VSDTC

Average diastolic BP over 12 months before start of ACS

Diastolic BP measurement

VS.VSTEST C67153

Diastolic Blood Pressure C25299

VS.VSTESTCD C66741 DIABP

Diastolic BP value

VS.VSORRES

Diastolic BP unit

VS.VSORRESU C66770 mmHg C49670

Diastolic BP time indicator

VS.VSDTC

FP7-287800 SALUS


History of hypertension before start of ACS (Y/N)

Hypertension

MH.MHPTCD

10020772


Start date of hypertension

MH.MHSTDTC

Last Body Mass Index (BMI) before start of ACS

BMI measurement name

VS.VSTEST C67153

Body Mass Index C16358

BMI measurement code

VS.VSTESTCD C66741 BMI

BMI value VS.VSORRES

BMI unit VS.VSORRESU C66770 kg/m2 C49671

BMI time indicator

VS.VSDTC

Last weight before start of ACS

Weight measurement name

VS.VSTEST C67153 Weight C25208

Weight measurement code

VS.VSTESTCD C66741 WEIGHT

Weight value

VS.VSORRES

Weight unit VS.VSORRESU C66770 kg C28252

Weight time indicator

VS.VSDTC

Last lenght before start of ACS

Length measurement name

VS.VSTEST C67153 Height C25347

Length measurement code

VS.VSTESTCD C66741 HEIGHT

Length value VS.VSORRES

Length unit VS.VSORRESU C66770 cm C49668

Length time indicator

VS.VSDTC

FP7-287800 SALUS


Ever smoked (Y/N) Smoking

SU.SUCAT L00040

TOBACCO CONSUMPTION

Smoked within the last 3 months (Y/N) Smoking

SU.SUCAT L00040

TOBACCO CONSUMPTION

Smoking time indicator

SU.SUENDTC

Taken sulfonylurea anytime within 3 months before start of ACS (Y/N)

Sulfonylurea therapy

CM.CMDECOD C97936

Therapy time indicator

CM.CMENDTC

Taken metformin anytime within 3 months before start of ACS (Y/N)

Metformin therapy

CM.CMDECOD C61612


CM.CMENDTC

Taken insulin anytime within 3 months before start of ACS (Y/N)

Insulin therapy

CM.CMDECOD C581


CM.CMENDTC

FP7-287800 SALUS


Taken Thiazolidinediones anytime within 3 months before start of ACS (Y/N)

Thiazolidinedione therapy

CM.CMDECOD C98241


CM.CMENDTC

Taken other oral anti-diabetic drugs within 3 months before start of ACS (Y/N)

Other anti-diabetic drug therapy

CM.CMCLAS C29711

Route of drug Administration

CM.CMROUTE C66729 ORAL C38288


CM.CMENDTC

Congestive Heart Failure (CHF) before start of ACS (Y/N)

Congestive Heart Failure

MH.MHPTCD

10007559 C3080 I50.01 428


Congestive Heart Failure time indicator

MH.MHSTDTC

CHF after start of ACS (Y/N) = previous

Date of CHF after start of ACS = previous

Died any time after start of ACS (Y/N)

Date of death

DM.DTHDTC

Date of Death = previous

FP7-287800 SALUS


FP7-287800 SALUS


9 ORBIS CONTENT ENTITY MODELS

This section provides an overview of Agfa HealthCare’s ORBIS system content entity models

expressed using the proprietary ORBIS Content Model Ontology.

9.1 Diagnosis Diagnosis information in ORBIS is stored in a number of relation tables and the ICD-10-GM coding

system is used to specify the diagnosis. Figure 1 shows the ORBIS Diagnosis Content Entity Model,

represented with the ORBIS Content Model Ontology.

falldiagnosen

falldiagnosen:FallDiagnosen

falldiagnosen:diagnoseid

falldiagnosen:fallid

falldiagnosen:lokalisation

fall

Fall:Fall

fall:persnr

diagnosen

diagnosen:Diagnosen

diagnosen:diagkurz

diagnosen:codesgbv

diagnosen:diagbez

diagnosen:diagtypid

falldiagarten

falldiagarten:FallDiagArten

falldiagarten:feststdatum

falldiagarten:fallDiagnosenid

falldiagarten:verdacht

diagnosetyp

diagnosetyp:Diagnosetyp

diagnosetyp:hl7kurz

Figure 1 ORBIS Content Entity Model for Diagnosis

The ORBIS Content Model Ontology is generated based on the database schema of the ORBIS

database. The database tables are converted to classes in the ORBIS Content Model Ontology, the

columns in tables are converted to properties. The following shows an extract of the ORBIS

Falldiagnosen Content Model Ontology:

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

schema/FallDiagnosen#>.

falldiagnosen:FallDiagnosen a rdfs:Class;

rdfs:comment "OS_KERN.FALL_DIAGNOSEN".

falldiagnosen:diagnoseid a rdf:Property;

rdfs:label "DIAGNOSEID";

rdfs:comment "OS_KERN.FALL_DIAGNOSEN.DIAGNOSEID";

rdfs:domain falldiagnosen:FallDiagnosen;

rdfs:range diagnosen:Diagnosen.

falldiagnosen:fallid a rdf:Property;

rdfs:label "FALLID";

rdfs:comment "OS_KERN.FALL_DIAGNOSEN.FALLID";

rdfs:domain falldiagnosen:FallDiagnosen;

rdfs:range fall:Fall.

falldiagnosen:lokalisation a rdf:Property;

FP7-287800 SALUS


rdfs:label "LOKALISATION";

rdfs:comment "OS_KERN.FALL_DIAGNOSEN.LOKALISATION";

rdfs:domain falldiagnosen:FallDiagnosen.

The falldiagnosen:FallDiagnosen class indicates this ontology is generated from the FallDiagnosen

table. Diagnoseid, fallid, and lokalisation are columns in this table and thus corresponding properties

are generated. Diagnoseid and fallid are both Foreign Keys so that the range of these two properties

are classes, which represent the foreign table. The range of lokalisation is not specified, which is

equivalent to plain literal.

In Figure 1 the ontology class 'Fall' stands for medical case, which can be further linked to a 'Patient'

class (with its property fall:persnr). Diagnosen stores the standard ICD-10-GM coding, where

diagnosen:codesgbv represents the ICD-10-GM diagnosis code, and diagnosen:diagbez represents the

diagnosis name. As the ICD-10-GM coding distinguishes different versions for each year, such

version information is stored in Diagnosetyp. In ORBIS, diagnosis is assigned to each medical case

and the Falldiagnosen table (ontology) records such assignments. Additional information of a

diagnosis, e.g. diagnosis date, is kept in Falldiagarten.

The ORBIS Diagnosis Content Entity Model is thus derived as:

?fda falldiagarten:fallDiagnosenid ?fd.

?fda falldiagarten:feststdatum ?diagDate.

?fda falldiagarten:verdacht ?verdacht.

?fd a falldiagnosen:FallDiagnosen.

?fd falldiagnosen:fallid ?fall.

?fd falldiagnosen:diagnoseid ?primaryDiag.

?fd falldiagnosen:lokalisation ?lokalisation.

?fall fall:persnr ?patient.

?primaryDiag diagnosen:codesgbv ?diagCode.

?primaryDiag diagnosen:diagkurz ?diagkurz.

?primaryDiag diagnosen:diagbez ?diagName.

?primaryDiag diagnosen:diagtypid ?diagtyp.

?diagtyp diagnosetyp:hl7kurz ?diagnosisType.

A sample ORBIS Diagnosis Content Entity, returned by the ORBIS SPARQL Endpoint after

executing the Diagnosis SPARQL Query mentioned in Error! Reference source not found.:

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

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

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

<https://agfa.com/orbis/SALUS/resource/FallDiagnosen/564800001#this>

<http://www.agfa.com/w3c/orbis/orbis-schema/FallDiagnosen#fallid>

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


<http://www.agfa.com/w3c/orbis/orbis-schema/FallDiagnosen#diagnoseid>

<https://agfa.com/orbis/SALUS/resource/Diagnosen/726450001#this> .


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

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

FP7-287800 SALUS


<https://agfa.com/orbis/SALUS/resource/FallDiagArten/564800001#this>

<http://www.agfa.com/w3c/orbis/orbis-schema/FallDiagArten#fallDiagnosenid>

<https://agfa.com/orbis/SALUS/resource/FallDiagnosen/564800001#this> .

<https://agfa.com/orbis/SALUS/resource/FallDiagArten/564800001#this>

<http://www.agfa.com/w3c/orbis/orbis-schema/FallDiagArten#feststdatum>

"2012-08-30T00:00:00+01:00"^^<http://www.w3.org/2001/XMLSchema#dateTime> .

<https://agfa.com/orbis/SALUS/resource/Diagnosen/726450001#this>

<http://www.agfa.com/w3c/orbis/orbis-schema/Diagnosen#diagkurz> "I21" .


<http://www.agfa.com/w3c/orbis/orbis-schema/Diagnosen#diagbez> "Akuter

Myokardinfarkt" .


<http://www.agfa.com/w3c/orbis/orbis-schema/Diagnosen#codesgbv> "I21.-" .


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

<https://agfa.com/orbis/SALUS/resource/Diagnosetyp/29#this> .

<https://agfa.com/orbis/SALUS/resource/Diagnosetyp/29#this>

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

"icd10gm2012" .

9.2 Medication In ORBIS the medication information is stored in customized ORBIS forms. In practice at UKD the

medication information for inpatients are stored on paper and not in ORBIS. For the other patient

types the medication information is stored in 20 different medication forms for different clinics.

Among those different medication forms, the 'Rezept neu' form and the

'Medikamentenliste_PO_ABDA9636' form are the mostly widely used. These two forms are

accounting for more than 90% of the medication form instances. The 'Rezept neu' form is equivalent

to prescription, while the 'Medikamentenliste_PO_ABDA9636' form is embedded in the admission or

discharge letters. These two medication forms are formalized in the SALUS project.

FP7-287800 SALUS


9.2.1 Prescription Form – Rezept neu

cwmedpackung

cwmedpackung:CwMedpackung

cwmedpackung:bezeichnung

cwmedpackung:pzn

cwmedpackung:medpraeparatid

cwmedpraepglied

cwmedpraepglied:CwMedpraepglied

cwmedpraepglied:medgliederungid

cwmedpraepglied:medpraeparatid

cwmedgliederung

cwmedgliederung:CwMedgliederung

cwmedgliederung:bezeichnung

cwmedgliederung:code

listfield

listfield:Listfield

listfield:hasName

listfield:hasFeldtext

listfield:hasListName

listfield:belongsTo

form

form:Form

form:fall

form:hasName

form:meddate

form:medtime

fall

fall:Fall

fall:persnr

ATCcode

ATCname

Figure 2 ORBIS Content Entity Model for Medication Form – Rezept neu

Figure 2 shows the ORBIS Content Entity Model for formalizing the 'Rezept neu' form. In the 'Rezept

neu' form, there is a list named "ListeMedikamente", where a list of drugs can be prescribed. An entry

of this list may have multiple fields, and the field "PZN" contains the PZN of a drug. While most of

the ORBIS Content Model Ontologies formalized the Relational Database (RDB) tables in ORBIS,

the form ontology and listfield ontology are created to formalize the Generic Data Model (GDM) of

forms and list fields in ORBIS, so that they can also be queried by SPARQL query. The

form:hasName property refers to the name of a form, in this case, it is assigned as "Rezept neu" to

indicate the 'Rezept neu' form is the form to be queried. The form:fall property points to the 'Fall'

class, which is further connected to the 'Patient' class. The form:meddate and form:medtime properties

records the date and time a form is created. The listfield:hasName property keeps the name of a list

field while the listfield:hasListName property records the name of the list. The listfield:belongsTo

property indicates the form that a listfield belongs to. The listfield:hasFeldtext stores the contents of a

list field, after specifying the form:hasName as "Rezept neu", the listfield:hasListname as

"ListeMedikamente", and the listfield:hasName as "PZN", the data stored in listfield:hasFeldtext is

exactly the PZN of a prescribed drug.

The cwmedpackung, cwmedpraepglied and cwmedgliederung ontologies are generated from the

relational tables in ORBIS where drug information is stored, e.g. cwmedpackung is about drug

package, and cwmedgliederung is about ATC coding. In the 'Rezept neu' form, the PZN is recorded

in the form and is used to link to the aforementioned tables to retrieve the ATC code of the prescribed

drug. The 'PZN' stands for 'Pharma Zentralnummer' (Pharmaceutical Central Number), each drug

package has one PZN number.

The ORBIS Content Entity Model of the 'Rezept neu' form:

?cwmedpackung cwmedpackung:pzn ?hasPZN.

?cwmedpackung cwmedpackung:bezeichnung ?medPackname.

?cwmedpackung cwmedpackung:medpraeparatid ?medpraeparatid.

?cwmedpraepglied cwmedpraepglied:medpraeparatid ?medpraeparatid.

?cwmedpraepglied cwmedpraepglied:medgliederungid ?cwmedgliederung.

FP7-287800 SALUS


?cwmedgliederung cwmedgliederung:code ?ATCcode.

?cwmedgliederung cwmedgliederung:bezeichnung ?ATCname.

?pzn listfield:hasFeldtext ?hasPZN.

?pzn listfield:hasName "PZN".

?pzn listfield:hasListName "ListeMedikamente".

?pzn listfield:belongsTo ?form.

?form form:hasName "Rezept neu".

?form form:fall ?fall.

?form form:meddate ?formdate.

?form form:medtime ?formtime.


A sample ORBIS Content Entity Model of the 'Rezept neu' form, returned by the ORBIS SPARQL

Endpoint after executing the SPARQL Query mentioned in Error! Reference source not found.:

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

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

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

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

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

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


<http://www.agfa.com/w3c/orbis/orbis-schema/Form#meddate> "2012-07-

23+01:00"^^<http://www.w3.org/2001/XMLSchema#date> .


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

"12:12:12"^^<http://www.w3.org/2001/XMLSchema#time> .

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

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

"ListeMedikamente" .


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


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

"3552295" .


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

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


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

<https://agfa.com/orbis/SALUS/resource/CwMedgliederung/11135801#this>

<http://www.agfa.com/w3c/orbis/orbis-schema/CwMedgliederung#code> "C08CA05"

.

<https://agfa.com/orbis/SALUS/resource/CwMedgliederung/11135801#this>

<http://www.agfa.com/w3c/orbis/orbis-schema/CwMedgliederung#bezeichnung>

"Nifedipin" .

FP7-287800 SALUS


<https://agfa.com/orbis/SALUS/resource/CwMedpraepglied/11276901#this>

<http://www.agfa.com/w3c/orbis/orbis-schema/CwMedpraepglied#medpraeparatid>

<https://agfa.com/orbis/SALUS/resource/CwMedpraeparat/11492601#this> .

<https://agfa.com/orbis/SALUS/resource/CwMedpraepglied/11276901#this>

<http://www.agfa.com/w3c/orbis/orbis-

schema/CwMedpraepglied#medgliederungid>

<https://agfa.com/orbis/SALUS/resource/CwMedgliederung/11135801#this> .

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

<http://www.agfa.com/w3c/orbis/orbis-schema/CwMedpackung#bezeichnung>

"Nifedipin-ratio Tropfen 100 ml N3" .


<http://www.agfa.com/w3c/orbis/orbis-schema/CwMedpackung#pzn> "3552295" .


<http://www.agfa.com/w3c/orbis/orbis-schema/CwMedpackung#medpraeparatid>

<https://agfa.com/orbis/SALUS/resource/CwMedpraeparat/11492601#this> .

9.2.2 Medikament Form – Medikamentenliste_PO_ABDA9636

Figure 3 ORBIS Content Entity Model for Medication Form – Medikamentenliste_PO_ABDA9636

The ORBIS ontologies used in formalizing the 'Medikamentenliste_PO_ABDA9636' form is quite

similar with what used in formalizing the 'Rezept neu' form. Except that in the 'Rezept neu' form, the

PZN of the prescribed drug is recorded and is used to link to the cwmedpackung (drug package),

while in the 'Medikamentenliste_PO_ABDA9636' form, only the drug name is recorded, which is

then linked to the cwmedpraeparat (drug) table in order to retrieve the ATC code.

The Content Entity Model of the 'Medikamentenliste_PO_ABDA9636' form:

?cwmedpraepglied cwmedpraepglied:medpraeparatid ?cwmedpraeparat.

?cwmedpraepglied cwmedpraepglied:medgliederungid ?cwmedgliederung.

?cwmedpraeparat cwmedpraeparat:bezeichnung ?hasMedikament.

?cwmedgliederung cwmedgliederung:code ?ATCcode.

?cwmedgliederung cwmedgliederung:bezeichnung ?ATCname.

FP7-287800 SALUS


?medikament listfield:hasFeldtext ?hasMedikament.

?medikament listfield:hasName "T_Medikament".

?medikament listfield:hasListName "L_Medikamente".

?medikament listfield:belongsTo ?form.

?form form:hasName "Medikamentenliste_PO_ABDA9636".

?form form:fall ?fall.

?form form:meddate ?formdate.

?form form:medtime ?formtime.


FP7-287800 SALUS


LIST OF APPENDICES:

Among the following appendices, only #4 has been updated in the 2nd release of this deliverable.

1. Mappings between HL7 CDA Content Modules, OMOP CDM, E2B(R2) Model and SALUS

Common Data Elements (D4.1.1-Appendix1-Mappings-between-HL7CDA-OMOP-E2B-

CommonDataElements.xlsx)

2. A sample HL7 CDA Document complying to entry level templates defined (D4.1.1-Appendix2-

SALUS-sample-full-CDA-instance.xml)

3. Definition of SALUS EN13606 artefacts based on SIAMM and ContSys (D4.1.1-Appendix3-

DefinitionofSALUS13606ArtefactsbasedonSIAMM.pdf)

4. SALUS Archetype Library (D4.1.2-Appendix4-SALUS13606Artefacts.zip)