Common Information Model of SALUS

In the scope of SALUS Project Clinical Information Model (CIM), the ACA team of AGFA developed a set of advanced model of reusable clinical entities; under the acronym of CIMv2, and released as N3 file.

The CIMv2 was built based on 2 starting points:

  1. SALUS project Clinical Information Model (CIMv1)
  2. HL7 Clinical Document Architecture (CDA);

but there was additional influence from other existing clinical models in health community.

Like its predecessor (CIMv1), the CIMv2 represented in an ontological format, enables to rely on unique correspondences to link together the standard EHR data models integrated and interoperable with ICH E2B standard. The CIM Ontology thus acts as a common denominator for the existing standards used in clinical care as well as for proprietary models. Ensuring interoperability with proprietary models is important because EHR data remain based on such models in many healthcare facilities, despite the on growing dissemination of standard-based clinical documentation.



History and Background

In order to ensure the possibility of prepopulating ICH E2B(R2) compliant Adverse Event reporting forms with patient data from EHR systems using different data models, we have aligned standardized EHR data models to ICH E2B(R2) by converging the overlapping entities of both models to a harmonized data model specific to SALUS: the CIM.

The CIM Ontology is built through a systematic approach by (i) examining the content models, (ii) extracting and harmonizing Common Data Elements (CDEs) from these, (iii) representing the related terminology systems as ontologies within the SALUS Semantic Resource Set, and (iv) linking them with the CDEs in an ontological framework. We have focused on the requirements of a set of selected pilot applications by identifying and formally representing CDEs as an RDF model. In this process, we have analyzed and taken into account the content models from other standards and initiatives as well, to provide a common mediator that can interoperate with well-established state of the art. These include HL7/ASTM CCD and IHE PCC templates, HITSP C32/C83 components, Consolidated CDA templates, ICH E2B(R2) and ISO/CEN EN 13606 archetypes. We have also analyzed the Common Data Model (CDM) of the Observational Medical Outcomes Partnership (OMOP), which is used as a target model in three of our pilot applications to carry out statistical analysis on top of the EHR data extracted.

The main CDEs resulting from this selection process are the so-called entities, below listed. After identifying the required CDEs we have modeled them in RDF using existing ontologies and terminologies such as or SNOMED CT. This strategy has been chosen to avoid creating from scratch entities that are already defined by existing resources and to favor the re-use of our entity models in the healthcare and EHR communities.

In CIMv1 all the elements appeared in our proprietary SALUS CIM namespace. To make the re-usable for healthcare community, we replaced all the proprietary SALUS CIM namespace elements with elements from non-propriety namespaces (namely third-party ontologies). Therefore the ACA team of AGFA, partner in Salus Project, developed the Second Release of Clinical Information Model (CIMv2) of SALUS project, and released as N3 file.

What are reusable ontologies?

  • The used approach:
    • We’ve chosen multiple ontologies to express the entity patterns.
    • Salus CIM as starting point with additionally extra descriptions from HL7 CDA/CCD sources.
  • What are the entities?
    • Entity models: what info is needed to describe an entity (abstract)
    • Entity patterns: a pattern for representing an entity (concrete)
    • Entity: instances which is exchanged between parties.
  • SALUS CIM represents the pivot ontology used for semantic mediation, and is the core of Semantic Interoperability Layer. As a part of Semantic Interoperability Layer, mapping rules are defined to translate EHR data from local EHR models to SALUS CIM.
Data location Ontology
Application Application Ontology
Domain Entity Domain (Reusable) Ontology (CIMv2)
Source DDO

Benefits of using the 3rd parties’ ontologies

  • Guaranty for interoperability
    • Scalability
    • Reusability
  • Outreach to the healthcare community
  • Developing with the healthcare community
  • Align with worldwide ongoing Semantic Web Technologies
  • Exploitation of the project (thereafter)

 How reusable ontologies are built? 4 steps

  1. First: Design a clinical model (based on medical/clinical knowledge, existing clinical models in health care community, etc)
  2. Second: Choose the required classes (mainly from SNOMED CT, US National Institute of Health (NIH) bio-ontologies: NCIT, MeSH, EVS and known medical terminology and classifications: ICD, LOINC and ATC)
  3. Third: Build a clinically meaning entity model (gathering predicates and concept classes)
  4. Lastly: Test and validate the entities through existing data sources (Orbis-TUD)

Here is the order of priority in the choice of 3rd-party ontologies sources:



What are clinical entities?

In total we identified 19 clinical entities. Those entities have been unified in the Patient Summary file (named salusPatientSummary file, released as N3 file):

  1. Addresses
  2. Organization
  3. Membership
  4. Healthcare provider
  5. Patient insurance and guarantor
  6. Data reporter
  7. Patient (demographics)
  8. Patient family history
  9. Patient social history
  10. Laboratory results
  11. Vital signs
  12. Medical condition: diagnosis
  13. Medical condition: adverse events
  14. Pregnancy
  15. Medical procedure
  16. Encounter : visit
  17. Encounter : stay
  18. Medication
  19. Immunotherapy


@prefix clisko: <>.
@prefix common: <>.
@prefix con: <>.
@prefix dcterms: <> .
@prefix event: <>.
@prefix foaf: <>.
@prefix gr: <> .
@prefix healthcare: <>.
@prefix org: <> .
@prefix owl: <> .
@prefix prov: <>.
@prefix rdf: <> .
@prefix rdfs: <>.
@prefix schema: <>.
@prefix skos: <>.
@prefix vcard: <>.
@prefix xsd: <>.

The namespaces ’healthcare:’ ’event:’ and ‘common:’ will be replaced by ‘schema:’ once the migration of their predicates/concepts to ‘’ is done.

Design choice, use and perspective of CIMv2

  • The CIMv2 clinical designs are Process oriented, not State oriented

The main debate in health IT community about the clinical entity patterns design is about this choice.

The best is to provide both but in this release, the choice was to use a process oriented approach to mimic the clinical workflow in health care environment.

                        healthcare:hasProcedure _:diagnosisProcedure.
                        a <>; #Diagnosis Procedure. This is a filtering medical code
                        a <>; #Replace this by a specific source code URI
                        a schema:MedicalProcedure;
                        schema:startDate   “2000-12-22T10:00:00″^^xsd:dateTime;
                        healthcare:indication <>;    
                        healthcare:medicalCase <>;
                        common:hasProvider <>;
                        prov:generated _:medicalCondition.
                        healthcare:drug _:drugOrMedicament;
##18. MEDICATION (Medication/therapy procedure)
                        healthcare:hasProcedure _:prescribingProcedure. 
                        a <>;  #Prescription procedure. This is a filtering medical code
                        healthcare:medicalCase <>;
                        healthcare:indication _:medicalCondition;                 
schema:startDate “2000-08-22T10:00:00″^^xsd:dateTime;
                        foaf:maker  <>;
                        schema:location <>;
                        healthcare:medicalCase [a <>]; #Patient encounter procedure      prov:generated _:clinicalDocumentOrReport; #Written prescription = medication order          
healthcare:drugPreparation _:drugPreparation.                                                        
                        a <>; #Type of drug preparation
                        a <>; # Use specific instance URI code if possible
                        healthcare:dispensation  _:drugDispensation;
                        healthcare:drug _:drugOrMedicament;

However,  in Electronic Health Records (EHRs) some data is often missing. Therefore, we agreed to release in near future an advanced model of this CIMv2 optimized to be used with state oriented design.

This advanced model (the ‘Clinical Research Entities patterns: Advanced Model – CREAM’) will introduce the 2 design structures in the same entity, as follows:

                        healthcare:hasProcedure _:diagnosisProcedure;
                        healthcare:hasDiagnosis _:diagnosis.
                        a _:medicalCondition;
                        a <>; #This is a filtering code
                        a <>; #This is to be replace by a specific URI code from the source
                        prov:wasGeneratedBy _:diagnosisProcedure.
                        a _:medicalProcedure;
                        a <>; #Diagnosis procedure. This is a filtering code                            
                        a <>; #This is to be replace by a specific URI code from the source
                        prov:generated _:diagnosis.
                        a <>; #Medical Procedure. This is a filtering code
                        a schema:MedicalProcedure;
                        healthcare:medicalCase <>;
                        a <>; # Replace by the souce code URI.
                        common:status “Incomplete”;                                       
                        healthcare:hasSite _:bodySiteOrRegion;
                        healthcare:indication _:medicalCondition;                                                                 
                        schema:howPerformed “Partial removal of ureteral stent under general anasthesia”;         
                        schema:startDate  “2000-12-22T10:00:00″^^xsd:dateTime;
                        schema:endDate “2012-12-22T10:00:00″^^xsd:dateTime;
                        common:hasProvider <>;
                        schema:location                  <>;
                        schema:description “Free text details of the procedure”;
                        prov:generated _:clinicalDocumentOrReport.
                        a <>; #Type of drug preparation
                        a <>; # Use specific instance URI code if possible
                        healthcare:dispensation  _:drugDispensation;
                        healthcare:drug _:drugOrMedicament;

Though, this optimized release will be done once all partners agreed on it.

  • in CIMv2, concepts are defined to help specific SPARQL Queries

In CIMv2, all concepts are defined with known terminology concepts classes (SNOMED CT, LOIC, NCIT, MeSH, etc) as filtering codes, so it’s easy to make specific SPARQL queries.


                        a _:medicalCondition;
                        a <>; #This is a filtering code
                        a <>; #This is to be replace by a specific URI code from the source
                        prov:wasGeneratedBy _:diagnosisProcedure.

Currently, we divided data into three layers and each layer has its corresponding ontology. We do not control the local and application layer, but control the domain entity layer where we use domain (reusable) ontology to allow interoperability between different data sources. Now, it appears in order to allow the interoperability of terminology, we might also need to have domain terminology. In addition to DDO-DO conversion rules, we would also have DDO-DO terminology mapping, which may also expressed as rules.  We now consider SNOMED, LOINC and ATC as domain terminology.

It is impossible to have a full implementation covering all the codes in limited time, however; we would practice the ICD10GM to SNOMED terminology mapping on the SALUS Mockup/sample data, where a limited set of diagnosis is used.

Data location Ontology                 Terminology
Application Application Ontology MedDRA, etc.
Domain Entity Domain (Reusable) Ontology (CIMv2) SNOMED, LOINC, ATC
Source DDO ICD10GM, ICD9CM, local lab code, etc.