D4.1.2 SALUS Content models for the Functional Interoperability … · 2017-04-17 · SALUS D4.1.2...
Transcript of 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 Page 2 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-FP7-287800 • D4.1.2 • Version 1.4, dated January 28, 2014 Page 3 of 90
SALUS Consortium Contacts:
Beneficiary Name Phone Fax E-Mail
SRDC Gokce Banu Laleci
Erturkmen
+90-312-2101763 +90(312)2101837 [email protected]
EUROREC Georges De Moor +32-9-2101161 +32-9-3313350 [email protected]
UMC Niklas Norén +4618656060 +46 18 65 60 80 [email protected]
OFFIS Wilfried Thoben
+49-441-9722131
+49-441-9722111
AGFA Dirk Colaert +32-3-4448408 +32 3 444 8401 [email protected]
ERS Gerard Freriks +31 620347088 +31 847371789 [email protected]
LISPA Davide Rovera +3902393311 +39 02 39331207 [email protected]
INSERM Marie-Christine Jaulent +33142346983 +33153109201 marie-
TUD Peter Schwarz +49 351 458 2715 +49 351 458 7319 Peter.Schwarz@uniklinikum-
dresden.de
ROCHE Jamie Robinson +41-61-687 9433 +41 61 68 88412 [email protected]
FP7-287800 SALUS
SALUS-FP7-287800 • D4.1.2 • Version 1.4, dated January 28, 2014 Page 4 of 90
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
SALUS-FP7-287800 • D4.1.2 • Version 1.4, dated January 28, 2014 Page 5 of 90
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
SALUS-FP7-287800 • D4.1.2 • Version 1.4, dated January 28, 2014 Page 6 of 90
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
SALUS-FP7-287800 • D4.1.2 • Version 1.4, dated January 28, 2014 Page 7 of 90
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
SALUS-FP7-287800 • D4.1.2 • Version 1.4, dated January 28, 2014 Page 8 of 90
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
SALUS-FP7-287800 • D4.1.2 • Version 1.4, dated January 28, 2014 Page 9 of 90
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
SALUS-FP7-287800 • D4.1.2 • Version 1.4, dated January 28, 2014 Page 10 of 90
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
SALUS-FP7-287800 • D4.1.2 • Version 1.4, dated January 28, 2014 Page 11 of 90
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)
x (Year of Birth is Adequate)
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
SALUS-FP7-287800 • D4.1.2 • Version 1.4, dated January 28, 2014 Page 12 of 90
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 Encounter 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)
Related Encounter x (o)
Procedure Provider x (o)
FP7-287800 SALUS
SALUS-FP7-287800 • D4.1.2 • Version 1.4, dated January 28, 2014 Page 13 of 90
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)
Related Encounter 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 Encounter x (o)
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
SALUS-FP7-287800 • D4.1.2 • Version 1.4, dated January 28, 2014 Page 14 of 90
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
SALUS-FP7-287800 • D4.1.2 • Version 1.4, dated January 28, 2014 Page 15 of 90
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
SALUS-FP7-287800 • D4.1.2 • Version 1.4, dated January 28, 2014 Page 16 of 90
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
SALUS-FP7-287800 • D4.1.2 • Version 1.4, dated January 28, 2014 Page 17 of 90
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
Common Data Element Name Cardinality Data Type
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
SALUS-FP7-287800 • D4.1.2 • Version 1.4, dated January 28, 2014 Page 18 of 90
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']
Location in CDA Document in the specified sections
Common Data Element Name Cardinality Data Type
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
8http://wiki.ihe.net/index.php?title=1.3.6.1.4.1.19376.1.5.3.1.4.5
FP7-287800 SALUS
SALUS-FP7-287800 • D4.1.2 • Version 1.4, dated January 28, 2014 Page 19 of 90
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
SALUS-FP7-287800 • D4.1.2 • Version 1.4, dated January 28, 2014 Page 20 of 90
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']
Location in CDA Document in the specified sections
Common Data Element Name Cardinality Data Type
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
8. 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’10) to record information about the related condition
of the patient.
9. MAY contain zero or one [0..1] entryRelationship such that it
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
SALUS-FP7-287800 • D4.1.2 • Version 1.4, dated January 28, 2014 Page 21 of 90
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']/
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.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
11http://wiki.ihe.net/index.php?title=1.3.6.1.4.1.19376.1.5.3.1.4.14
FP7-287800 SALUS
SALUS-FP7-287800 • D4.1.2 • Version 1.4, dated January 28, 2014 Page 22 of 90
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
a. This code SHOULD contain zero or one [0..1] originalText
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.
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] @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.
12http://wiki.ihe.net/index.php?title=1.3.6.1.4.1.19376.1.5.3.1.4.1
FP7-287800 SALUS
SALUS-FP7-287800 • D4.1.2 • Version 1.4, dated January 28, 2014 Page 23 of 90
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' ]
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.7' ] Medication
cda:code
0..1 CD
cda:statusCode - 1..1 CS
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
SALUS-FP7-287800 • D4.1.2 • Version 1.4, dated January 28, 2014 Page 24 of 90
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
a. This code SHOULD contain zero or one [0..1] originalText
b. This code MAY contain zero or more [0..*] translation
11. MAY contain zero or more [0..*] 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’ ) to record information about the related indication.
12. 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] 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
a. SHALL contain exactly one [1..1] @typeCode="REFR"
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"
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] performer
14. 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] @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')
15. MAY contain zero or one [0..1] entryRelationship such that it
FP7-287800 SALUS
SALUS-FP7-287800 • D4.1.2 • Version 1.4, dated January 28, 2014 Page 25 of 90
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')
16. 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] 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']/
Location in CDA Document in the specified sections
Common Data Element Name Cardinality Data Type
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
SALUS-FP7-287800 • D4.1.2 • Version 1.4, dated January 28, 2014 Page 26 of 90
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
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’13) to record information about the related condition
of the patient.
4.1.7 Family History Possible Sections: Coded Family History Section
//cda:section[cda:templateId/@root='1.3.6.1.4.1.19376.1.5.3.1.3.15']/
Location in CDA Document in the specified
sections
Common Data Element Name Cardinality Data Type
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
13http://wiki.ihe.net/index.php?title=1.3.6.1.4.1.19376.1.5.3.1.4.5
FP7-287800 SALUS
SALUS-FP7-287800 • D4.1.2 • Version 1.4, dated January 28, 2014 Page 27 of 90
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:section[cda:templateId/@root='1.3.6.1.4.1.19376.1.5.3.1.3.16']/
Location in CDA Document in the specified sections
Common Data Element Name Cardinality Data Type
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
SALUS-FP7-287800 • D4.1.2 • Version 1.4, dated January 28, 2014 Page 28 of 90
cda:code Social history type 1..1 CD
cda:statusCode - 1..1 CS
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
Location in CDA Document in the specified
sections
Common Data Element Name Cardinality Data Type
/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
SALUS-FP7-287800 • D4.1.2 • Version 1.4, dated January 28, 2014 Page 29 of 90
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
SALUS-FP7-287800 • D4.1.2 • Version 1.4, dated January 28, 2014 Page 30 of 90
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']/
Location in CDA Document in the specified
sections
Common Data Element Name Cardinality Data Type
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
SALUS-FP7-287800 • D4.1.2 • Version 1.4, dated January 28, 2014 Page 31 of 90
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
SALUS-FP7-287800 • D4.1.2 • Version 1.4, dated January 28, 2014 Page 32 of 90
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:statusCode - 1..1 CS
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
SALUS-FP7-287800 • D4.1.2 • Version 1.4, dated January 28, 2014 Page 33 of 90
iv. SHALL contain exactly one [1..1] manufacturedMaterial
1. This manufacturedMaterial SHALL contain exactly one [1..1] code
a. This code SHOULD contain zero or one [0..1] originalText
b. This code MAY contain zero or more [0..*] translation
8. MAY contain zero or one [1..1] entryRelationship such that it
a. SHALL contain exactly one [1..1] @typeCode="REFR"
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"
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] performer
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] 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
10. MAY contain zero or one [0..1] entryRelationship such that it
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
SALUS-FP7-287800 • D4.1.2 • Version 1.4, dated January 28, 2014 Page 34 of 90
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
FP7-287800 SALUS
SALUS-FP7-287800 • D4.1.2 • Version 1.4, dated January 28, 2014 Page 35 of 90
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
SALUS-FP7-287800 • D4.1.2 • Version 1.4, dated January 28, 2014 Page 36 of 90
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
SALUS-FP7-287800 • D4.1.2 • Version 1.4, dated January 28, 2014 Page 37 of 90
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
SALUS-FP7-287800 • D4.1.2 • Version 1.4, dated January 28, 2014 Page 38 of 90
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
SALUS-FP7-287800 • D4.1.2 • Version 1.4, dated January 28, 2014 Page 39 of 90
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
SALUS-FP7-287800 • D4.1.2 • Version 1.4, dated January 28, 2014 Page 40 of 90
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.
Field Required Type Standard Description Corresponding Common Data Item Notes
Table: Condition_Occurance
Condition/ Allergies and Intolerances
condition_occurrence_id yes integer
A system-generated unique identifier for each condition occurrence event. -
person_id yes integer
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
SALUS-FP7-287800 • D4.1.2 • Version 1.4, dated January 28, 2014 Page 41 of 90
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
visit_occurrence_id No integer
A foreign key to the visit in the visit table during which the condition was determined (diagnosed).
Condition.related encounter
FP7-287800 SALUS
SALUS-FP7-287800 • D4.1.2 • Version 1.4, dated January 28, 2014 Page 42 of 90
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.
Field Required Type Standard Description Corresponding Common Data Item Notes
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. -
person_id yes integer
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
SALUS-FP7-287800 • D4.1.2 • Version 1.4, dated January 28, 2014 Page 43 of 90
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?
care_site_id No integer
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
Corresponding Common Data Item Notes
Table: Procedure_Occurance Procedure
procedure_occurrence_id yes integer
A system-generated unique identifier for each procedure occurrence. -
person_id yes integer
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
SALUS-FP7-287800 • D4.1.2 • Version 1.4, dated January 28, 2014 Page 44 of 90
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
SALUS-FP7-287800 • D4.1.2 • Version 1.4, dated January 28, 2014 Page 45 of 90
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
SALUS-FP7-287800 • D4.1.2 • Version 1.4, dated January 28, 2014 Page 46 of 90
Field Required Type Standard Description
Corresponding Common Data Item Notes
Table:Observation Result
observation_id yes integer
A system-generated unique identifier for each observation. -
person_id yes integer
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
SALUS-FP7-287800 • D4.1.2 • Version 1.4, dated January 28, 2014 Page 47 of 90
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
SALUS-FP7-287800 • D4.1.2 • Version 1.4, dated January 28, 2014 Page 48 of 90
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
SALUS-FP7-287800 • D4.1.2 • Version 1.4, dated January 28, 2014 Page 49 of 90
associated_provider_id no integer
A foreign key to the provider in the provider table who was responsible for making the observation. Result Provider
visit_occurrence_id No integer
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
SALUS-FP7-287800 • D4.1.2 • Version 1.4, dated January 28, 2014 Page 50 of 90
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.
Field Required Type Standard Description
Corresponding Common Data Item Notes
Table:Observation_period Patient
observation_period_id Yes integer
A system-generated unique identifier for each observation period. -
person_id Yes integer
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
SALUS-FP7-287800 • D4.1.2 • Version 1.4, dated January 28, 2014 Page 51 of 90
5.1.8 Death
The Death table is designed to capture the time when a Person is deceased and causes of death.
Field Required Type Standard Description
Corresponding Common Data Item Notes
Table:Death Death
person_id Yes integer
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
SALUS-FP7-287800 • D4.1.2 • Version 1.4, dated January 28, 2014 Page 52 of 90
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).
Field Required Type Standard Description Corresponding Common Data Item Notes
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
SALUS-FP7-287800 • D4.1.2 • Version 1.4, dated January 28, 2014 Page 53 of 90
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
care_site_id No integer
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.).
Field Required Type Standard Description
Corresponding Common Data Item Notes
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
SALUS-FP7-287800 • D4.1.2 • Version 1.4, dated January 28, 2014 Page 54 of 90
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
location_id No integer
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).
Field Required Type Standard Description
Corresponding Common Data Item Notes
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. -
location_id No integer
A foreign key to the geographic location in the location table, where the detailed address information is stored. address
FP7-287800 SALUS
SALUS-FP7-287800 • D4.1.2 • Version 1.4, dated January 28, 2014 Page 55 of 90
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
SALUS-FP7-287800 • D4.1.2 • Version 1.4, dated January 28, 2014 Page 56 of 90
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
SALUS-FP7-287800 • D4.1.2 • Version 1.4, dated January 28, 2014 Page 57 of 90
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
SALUS-FP7-287800 • D4.1.2 • Version 1.4, dated January 28, 2014 Page 58 of 90
… (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
SALUS-FP7-287800 • D4.1.2 • Version 1.4, dated January 28, 2014 Page 59 of 90
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)”.
Field Req. Type Stand. Descrip. Corresponding CDE Rq
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.
Field Req. Type Stand. Descrip. Corresponding CDE Rq
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
Start Date No 8N CCYYMMDD or CCYYMM or CCYY
Procedure.TimeInterval
End Date No 8N CCYYMMDD or CCYYMM or CCYY
Procedure.TimeInterval
Comments No 100AN Procedures.Comment
Field Req. Type Stand. Descrip. Corresponding CDE Rq
E2B section: B.1.7
FP7-287800 SALUS
SALUS-FP7-287800 • D4.1.2 • Version 1.4, dated January 28, 2014 Page 60 of 90
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
Start Date No 8N CCYYMMDD or CCYYMM or CCYY
AdverseEvent.TimeInterval
End Date No 8N CCYYMMDD or CCYYMM or CCYY
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).
Field Req. Type Stand. Descrip. Corresponding CDE Rq
E2B section: B.1.8 Name of Drug as Reported
No 100AN Medication.MedicationInformation
Start Date No 8N CCYYMMDD or CCYYMM or CCYY
Medication.TimeInterval
End Date No 8N CCYYMMDD or CCYYMM or CCYY
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
SALUS-FP7-287800 • D4.1.2 • Version 1.4, dated January 28, 2014 Page 61 of 90
E2B section: B.2 Reaction/event as reported by primary source
Only one of those items is mandatory
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
AdverseEvent.TimeInterval
Date of end of reaction/event
No 12N CCYYMMDDHHMM or CCYYMMDD or CCYYMM or CCYY
AdverseEvent.TimeInterval
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.
Field Req. Type Stand. Descrip. Corresponding CDE Rq
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
SALUS-FP7-287800 • D4.1.2 • Version 1.4, dated January 28, 2014 Page 62 of 90
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
Only one of those items is mandatory
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
SALUS-FP7-287800 • D4.1.2 • Version 1.4, dated January 28, 2014 Page 63 of 90
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
FP7-287800 SALUS
SALUS-FP7-287800 • D4.1.2 • Version 1.4, dated January 28, 2014 Page 64 of 90
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
SALUS-FP7-287800 • D4.1.2 • Version 1.4, dated January 28, 2014 Page 65 of 90
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
FP7-287800 SALUS
SALUS-FP7-287800 • D4.1.2 • Version 1.4, dated January 28, 2014 Page 66 of 90
Figure: EN 13606 EHR-Extract Reference Model
FP7-287800 SALUS
SALUS-FP7-287800 • D4.1.2 • Version 1.4, dated January 28, 2014 Page 67 of 90
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
SALUS-FP7-287800 • D4.1.2 • Version 1.4, dated January 28, 2014 Page 68 of 90
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
SALUS-FP7-287800 • D4.1.2 • Version 1.4, dated January 28, 2014 Page 69 of 90
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
SALUS-FP7-287800 • D4.1.2 • Version 1.4, dated January 28, 2014 Page 70 of 90
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
FP7-287800 SALUS
SALUS-FP7-287800 • D4.1.2 • Version 1.4, dated January 28, 2014 Page 71 of 90
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
Ad-hoc Salus complex
Cluster Model
SalusHcConditionsActive HealthIssue/HealthCondition/H
ealthProblem/HealthProblemA
ctive
Salus/ProblemActive/
CMM
Ad-hoc Salus complex
Cluster Model
SalusHcConditionsPassive HealthIssue/HealthCondition/H
ealthProblem/HealthProblemPa
ssive
Salus/ProblemPassive/
CMM
Ad-hoc Salus complex
Cluster Model
SalusLabResults HealthIssue/HealthCondition/O
bservedCondition/LabTest
Salus/LabClusterMode
l
Ad-hoc Salus complex
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
SALUS-FP7-287800 • D4.1.2 • Version 1.4, dated January 28, 2014 Page 72 of 90
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
Ad-hoc Salus complex
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
SALUS-FP7-287800 • D4.1.2 • Version 1.4, dated January 28, 2014 Page 73 of 90
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.
FP7-287800 SALUS
SALUS-FP7-287800 • D4.1.2 • Version 1.4, dated January 28, 2014 Page 74 of 90
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
SALUS-FP7-287800 • D4.1.2 • Version 1.4, dated January 28, 2014 Page 75 of 90
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
SALUS-FP7-287800 • D4.1.2 • Version 1.4, dated January 28, 2014 Page 76 of 90
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
SALUS-FP7-287800 • D4.1.2 • Version 1.4, dated January 28, 2014 Page 77 of 90
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
MH.MHBDSYCD 10007541
Start date of Acute Myocardial Infarction
MH.MHSTDTC
Date of Unstable Angina
Unstable Angina Pectoris
MH.MHPTCD
10002388 C66911 I20.0 411.1
MH.MHBDSYCD 10007541
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
MH.MHBDSYCD 10027433
FP7-287800 SALUS
SALUS-FP7-287800 • D4.1.2 • Version 1.4, dated January 28, 2014 Page 78 of 90
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
SALUS-FP7-287800 • D4.1.2 • Version 1.4, dated January 28, 2014 Page 79 of 90
History of hypertension before start of ACS (Y/N)
Hypertension
MH.MHPTCD
10020772
MH.MHBDSYCD 10047065
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
SALUS-FP7-287800 • D4.1.2 • Version 1.4, dated January 28, 2014 Page 80 of 90
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
Therapy time indicator
CM.CMENDTC
Taken insulin anytime within 3 months before start of ACS (Y/N)
Insulin therapy
CM.CMDECOD C581
Therapy time indicator
CM.CMENDTC
FP7-287800 SALUS
SALUS-FP7-287800 • D4.1.2 • Version 1.4, dated January 28, 2014 Page 81 of 90
Taken Thiazolidinediones anytime within 3 months before start of ACS (Y/N)
Thiazolidinedione therapy
CM.CMDECOD C98241
Therapy time indicator
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
Therapy time indicator
CM.CMENDTC
Congestive Heart Failure (CHF) before start of ACS (Y/N)
Congestive Heart Failure
MH.MHPTCD
10007559 C3080 I50.01 428
MH.MHBDSYCD 10007541
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
SALUS-FP7-287800 • D4.1.2 • Version 1.4, dated January 28, 2014 Page 82 of 90
FP7-287800 SALUS
SALUS-FP7-287800 • D4.1.2 • Version 1.2, dated January 17, 2014 Page 83 of 90
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
SALUS-FP7-287800 • D4.1.2 • Version 1.2, dated January 17, 2014 Page 84 of 90
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> .
<https://agfa.com/orbis/SALUS/resource/FallDiagnosen/564800001#this>
<http://www.agfa.com/w3c/orbis/orbis-schema/FallDiagnosen#diagnoseid>
<https://agfa.com/orbis/SALUS/resource/Diagnosen/726450001#this> .
<https://agfa.com/orbis/SALUS/resource/FallDiagnosen/564800001#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
SALUS-FP7-287800 • D4.1.2 • Version 1.2, dated January 17, 2014 Page 85 of 90
<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" .
<https://agfa.com/orbis/SALUS/resource/Diagnosen/726450001#this>
<http://www.agfa.com/w3c/orbis/orbis-schema/Diagnosen#diagbez> "Akuter
Myokardinfarkt" .
<https://agfa.com/orbis/SALUS/resource/Diagnosen/726450001#this>
<http://www.agfa.com/w3c/orbis/orbis-schema/Diagnosen#codesgbv> "I21.-" .
<https://agfa.com/orbis/SALUS/resource/Diagnosen/726450001#this>
<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
SALUS-FP7-287800 • D4.1.2 • Version 1.2, dated January 17, 2014 Page 86 of 90
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
SALUS-FP7-287800 • D4.1.2 • Version 1.2, dated January 17, 2014 Page 87 of 90
?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.
?fall fall:persnr ?patient.
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> .
<https://agfa.com/orbis/SALUS/resource/Form/39450101#this>
<http://www.agfa.com/w3c/orbis/orbis-schema/Form#meddate> "2012-07-
23+01:00"^^<http://www.w3.org/2001/XMLSchema#date> .
<https://agfa.com/orbis/SALUS/resource/Form/39450101#this>
<http://www.agfa.com/w3c/orbis/orbis-schema/Form#medtime>
"12:12:12"^^<http://www.w3.org/2001/XMLSchema#time> .
<https://agfa.com/orbis/SALUS/resource/Listfield/39450101+69930+14578+1#thi
s> <http://www.agfa.com/w3c/orbis/orbis-schema/Listfield#hasListName>
"ListeMedikamente" .
<https://agfa.com/orbis/SALUS/resource/Listfield/39450101+69930+14578+1#thi
s> <http://www.agfa.com/w3c/orbis/orbis-schema/Listfield#hasName> "PZN" .
<https://agfa.com/orbis/SALUS/resource/Listfield/39450101+69930+14578+1#thi
s> <http://www.agfa.com/w3c/orbis/orbis-schema/Listfield#hasFeldtext>
"3552295" .
<https://agfa.com/orbis/SALUS/resource/Listfield/39450101+69930+14578+1#thi
s> <http://www.agfa.com/w3c/orbis/orbis-schema/Listfield#belongsTo>
<https://agfa.com/orbis/SALUS/resource/Form/39450101#this> .
<https://agfa.com/orbis/SALUS/resource/Form/39450101#this>
<http://www.agfa.com/w3c/orbis/orbis-schema/Form#hasName> "Rezept neu" .
<https://agfa.com/orbis/SALUS/resource/CwMedgliederung/11135801#this>
<http://www.agfa.com/w3c/orbis/orbis-schema/CwMedgliederung#code> "C08CA05"
.
<https://agfa.com/orbis/SALUS/resource/CwMedgliederung/11135801#this>
<http://www.agfa.com/w3c/orbis/orbis-schema/CwMedgliederung#bezeichnung>
"Nifedipin" .
FP7-287800 SALUS
SALUS-FP7-287800 • D4.1.2 • Version 1.2, dated January 17, 2014 Page 88 of 90
<https://agfa.com/orbis/SALUS/resource/CwMedpraepglied/11276901#this>
<http://www.agfa.com/w3c/orbis/orbis-schema/CwMedpraepglied#medpraeparatid>
<https://agfa.com/orbis/SALUS/resource/CwMedpraeparat/11492601#this> .
<https://agfa.com/orbis/SALUS/resource/CwMedpraepglied/11276901#this>
<http://www.agfa.com/w3c/orbis/orbis-
schema/CwMedpraepglied#medgliederungid>
<https://agfa.com/orbis/SALUS/resource/CwMedgliederung/11135801#this> .
<https://agfa.com/orbis/SALUS/resource/CwMedpackung/11309601#this>
<http://www.agfa.com/w3c/orbis/orbis-schema/CwMedpackung#bezeichnung>
"Nifedipin-ratio Tropfen 100 ml N3" .
<https://agfa.com/orbis/SALUS/resource/CwMedpackung/11309601#this>
<http://www.agfa.com/w3c/orbis/orbis-schema/CwMedpackung#pzn> "3552295" .
<https://agfa.com/orbis/SALUS/resource/CwMedpackung/11309601#this>
<http://www.agfa.com/w3c/orbis/orbis-schema/CwMedpackung#medpraeparatid>
<https://agfa.com/orbis/SALUS/resource/CwMedpraeparat/11492601#this> .
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
SALUS-FP7-287800 • D4.1.2 • Version 1.2, dated January 17, 2014 Page 89 of 90
?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.
?fall fall:persnr ?patient.
FP7-287800 SALUS
SALUS-FP7-287800 • D4.1.2 • Version 1.2, dated January 17, 2014 Page 90 of 90
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)