design and implementation of clinical databases using openehr

Tutorial - Design and Implementation of Clinical Databases with openEHR

Pablo Pazos Gutiérrez, Koray Atalag, Luis Marco-Ruiz, Erik Sundvall, Sérgio Miranda

Freire

Foundations• Modern Clinical Databases need to ...

– handle many types of information,– lost of different data structures,– be flexible and generic,– consistent, standardized, future-proof (evolution)

• CDBs are difficult to design!– design is 10% about storing data, 90% about querying, retieve and

using data• To achieve a good design we need to have:

– deep knowledge of clinical record structures– apply good practices, standards and support generic requirements– knowledge about different technologies / solutions

Agenda• Clinical Information Requirements• Clinical Information Organization• Database Technologies & Features• openEHR

– goals, information model, knowledge model, data store & query, versioning & audit

• openEHR Data Storage Techniques– Relational + ORM– Hybrid

• Data Querying

Clinical Information Requirements

Storing & Accessing Data

Minimal Information Set (ISO 18308)• Related to storage: from the user point of view

– Patient history– Physical examination– Psychological, social, environmental, family and self care information– Allergies and other therapeutic precautions– Preventative and wellness measures such as vaccinations and lifestyle

interventions– Diagnostic tests and therapeutic interventions such as medications and

procedures– Clinical observations, interpretations, decisions and clinical reasoning– Requests/Orders for further investigations, treatments or discharge– Problems, diagnoses, issues, conditions, preferences and expectations– Healthcare plans, health and functional status, and health summaries– Disclosures and consents– Suppliers, model and manufacturer of devices (e.g. implants or prostheses)

• Internally we want more generic information elements– especially on our database designs

Several ways of accessing clinical data

• Related to clinical data querying for clinical usage (patient level):– Chronological (e.g. to sort medical consultations)– Problem-Oriented (access data by condition or disease)

• Health records are associated to a health problem• Each problem evolves until it is solved/inactivated if it is not chronic

– By medical specialty (e.g. cardiology)– By department, sector, unit or service (e.g. emergency, ICU, ...)– Episode

• One or many contacts / visits on different dates• May include hospitalizations• Associated with a health problem (e.g. asthma attack)

– Access to individual documents or data points• e.g. all the blood pressure measures for a patient

• There is also Public Health and Epidemiology (population level)– we had a tutorial about that yesterday: “Enabling Clinical Data

Reuse with openEHR Data Warehouse Environments”

Infrastructure Requirements• Related to user experience and quality

– Be aware of the CAP theorem!• Scalability (grow maintaining service

level)• High availability (% operational time)• Transactionality (all or nothing)

– Performance (run forest, run!)– Concurrency (we all want that resource)– Audit (what, when, who, where, why, ...)– Encryption (data at rest)– Version management (history of

changes)– ...

• We want all!– We might need to use different

technologies

• Data Querying

Clinical Information Organization

Clinical records & information are highly hierarchicalpaper based or electronic

Clinical Information Organization

Clinical records & information are highly hierarchical

• Data Querying

DBs for different kinds of usage• operative / transactional databases (OLTP)

– read/write oriented– support business processes, small historical data

• querying databases– read oriented– read-only data, might be in memory

• document database– audit, versioning, electronic signature (authenticity, incorruptibility)

• analysis database– read oriented– might need ETL– data linking + data mining + statistical analysis + prediction

techniques (trends)• datawarehouse database

– ETL from many data sources– batch calculations of indicators over loads of historical data

Databases and Data StructuresDBMS Relational XML JSON Key/Value Graph

MySQL native partial in development

can be modeled

Postgres native complete complete hstore extension

hstore extension

Oracle native complete complete NoSQL edition NoSQL edition

SQLServer native complete in development

can be modeled

eXistDB no native output map map

MongoDB no no native JSON JSON

CouchDB / Couchbase no no native JSON JSON

Neo4j can be modeled

can be modeled

can be modeled native

Riak no no store and get native no

Which to choose?

relational, documental, key/value, graph, object, ...,

and which brand?

Considermany use cases can be met efficiently

by relational databases, but each project is different,

and there is no one-fits-all solution

We are not worried about performance just yet, we’ll focus onhow to design Clinical Databases with openEHR first!

First approach• The choice depends on the context

– use cases, estimated # of operations / # of records, organizational knowledge, ...

• For the operative / transactional DB lets go with a relational database:– MySQL, Postgres, Oracle, SQLServer, …– NOT a recommendation: just focusing on one option to understand

some common clinical database design concepts applicable on other technologies.

First approach• Loads of reads? Complex queries and JOINs? Low performance?

– try relational for writes + documental for reads• Needs ETL: relational => doc (JSON,XML)

– you can denormalize the relational DB, and/or – use documental capabilities of some RDBs (e.g. Postgres supports

XML & JSON)– made good use of indexes– analyze query plans (Posrgres / MySQL EXPLAIN query)

• Most systems wont have problems with any of these options– there is always a way to optimize things!

Also, we have transformations between models

• When we need to– migrate to another technology (e.g. from RDBs to Doc)– integrate different technologies (hybrid solution)

We can: XML (canonical xform) JSON

<data xsi:type="COMPOSITION" archetype_node_id="openEHR-EHR-COMPOSITION.signos.v1"> <name> <value>Signos vitales</value> </name> <archetype_details> <archetype_id> <value>openEHR-EHR-COMPOSITION.signos.v1</value> </archetype_id> <template_id> <value>Signos-Vitales</value> </template_id> <rm_version>1.0.2</rm_version> </archetype_details> <language> <terminology_id> <value>ISO_639-1</value> </terminology_id> <code_string>es</code_string> </language> <territory> <terminology_id> <value>ISO_3166-1</value> </terminology_id> <code_string>UY</code_string> </territory> <category> ... </category> ...</data>

{ "data": { "@xsi:type": "COMPOSITION", "@archetype_node_id": "openEHR-EHR-COMPOSITION.signos.v1", "name": { "value": "Signos vitales" }, "archetype_details": { "archetype_id": { "value": "openEHR-EHR-COMPOSITION.signos.v1" }, "template_id": { "value": "Signos-Vitales" }, "rm_version": "1.0.2" }, "language": { "terminology_id": { "value": "ISO_639-1" } }, "territory": { "terminology_id": { "value": "ISO_3166-1" } }, "category": { ... } }}

openEHR XML JSON equivalent

Non-RDB-based approaches?• XML: BaseX, Sedna, eXist, ...• JSON: Couchbase, CouchDB, MongoDB, ...• Often suitable if your client side GUI primarily wants XML or JSON

documents/chunks (avoids conversion needs) …or if you go all-in-javascript on server+client?

• Auto-translating AQL to hierarchy-friendly query languages (e.g. Xquery, N1QL, Sparql, SQL++?) is often straightforward. – Consider using a parser generator.

• XML databases fast for transactional (clinical?), but often slow for population-wide (epidemiology?) queries.

• Solutions such as Couchbase can be very fast for both, after specific indexing is done (example on next slide).

• Very little is published regarding graph/network databases (Neo4J etc) and object databases for openEHR usage. Please test and publish!

Scaling? Size & Performance tests, 4.2M patients

Please note: •All DBs work fine/fast for ”clinical” patient-specific queries, the graph shows population-queries•the RDB, here used as source and reference, is an epidemiology-optimised non-openEHR-based reference that we try to match in end-user speed (not size). The XML/JSON based DB-examples have the flexibility of openEHR to add new archetypes etc. without manually reworking the DB schema etc, the RDMBs reference example does not have that flexibility.

21Source: Yet unpublished results, working title: Comparing the Performance of NoSQL Approaches for Storing and Retrieving Archetype-Based Electronic Health Record Data. Authors: Sergio M Freire, Douglas Teodoro, Fang Wei-Kleiner, Erik Sundvall, Daniel Karlsson, Patrick LambrixMore about the test data and some of the setup is already published in http://www.ep.liu.se/ecp/070/009/ecp1270009.pdf

Type Databases

Size in GB

sus42k sus420k sus4200k

RDBMySQL

reference0.09 0.43 3.6

XML files 1.38 13.8 137.9

JSON files 0.83 8.3 82.9

XML DB

BaseX 1.2 11.9 -

eXist 3.3 - -

Berkeley 3.8 - -

JSON DB Couchbase 0.21 2.1 21

• Data Querying

• Open Standard to create really flexible, future-proof (maintainable in the long term at large scale with low cost), interoperable EHRs.– Defines an Infostructure!

• Created, maintained, tested, validated and implemented by an international community of professionals.

• The community provides Modeling Tools and Open Source Reference Implementations in many technologies (Java, Eiffel, .Net, Ruby, Python).

• Key elements:– technological independence– multi-level models, clean and complete

• information, clinical concepts, terminology bindings, querying, services, ...– formal methodology for knowledge management– open & free access to specifications

• a-la W3C / IETF (enabled the implementation of the Internet and the Web)• Please join us!

– openEHR Foundation:• http://openehr.org/community/mailinglists

– openEHR en español:• http://openehr.org.es

Information ModelOur Clincal DB Design will be based on this!

Information Model

Clinical records & information are highly hierarchical

Record Entries

Different types of entries a clinical document can haveClinical records are highly hierarchical!

Data Types (simplified)

Demographic Model

Specifying Clinical Records:Key Points for Clinical Database Design for

openEHR data

Archetypes & ADL• Represent clinical concepts by constraints over a generic

Information Model– defined in Archetype Definition Language– globally valid, multi-language

• Important elements for DB design and implementation!– multi-axial identifier

• openEHR-EHR-OBSERVATION.blood_pressure.v1– node identifier

• atNNNN– node path (e.g. path to systolic BP)

• /data[at0001]/events[at0006]/data[at0003]/items[at0004]/value• archetype id + path

– unique semantic identifier– will use them in our databases!

• Need archetypes, no problem: http://ckm.openehr.org/

Operational Templates (OPT)• "Big archetypes"

– Combine archetypes to represent clinical documents– Allows to add more constraints– Defined in XML

• Use for specific contexts– one language– locally valid (organization, federation, national)

• Used by EHR/EMR software directly– for validating data– for generating UIs– for indexing data– for querying– …

Operational Templates (OPT) <template_id> <value>Consulta Médica</value> </template_id> <definition> <rm_type_name>COMPOSITION</rm_type_name> ... <node_id>at0000</node_id> <attributes xsi:type="C_SINGLE_ATTRIBUTE"> <rm_attribute_name>category</rm_attribute_name> ... <children xsi:type="C_COMPLEX_OBJECT"> <rm_type_name>DV_CODED_TEXT</rm_type_name> ... <attributes xsi:type="C_SINGLE_ATTRIBUTE"> <rm_attribute_name>defining_code</rm_attribute_name> ... <children xsi:type="C_CODE_PHRASE"> <rm_type_name>CODE_PHRASE</rm_type_name> ... <terminology_id> <value>openehr</value> </terminology_id> <code_list>433</code_list> -- category = event </children> </attributes> </children> </attributes> ...

openEHR IM class

openEHR IM attribute

Information & Metadata

• Link between Archetypes and the Information Model– Will use those fields in our persistence model– Are important for queries!

References to Archetypes

and Templates(semantic content

definitions)

• Data Querying

Clinical Data Storage Design

openEHR Data Storage Design• openEHR doesn't define how to store data

– The IM is not a Persistence Model– The Persistence Model will depend on requirements and

technologies• Our work is to adapt the IM to our persistence needs• We can simplify, adapt or use part of it (openEHR is very

flexible)– openEHR doesn't care about how we store data but does care

about:• structural and semantic consistency (defined by archetypes & OPTs)• processable / accessable / queryable data

• Tips:– archetype id, path, template id, node id are important for

querying– references can be simplified (OBJECT_REF) (FKs in Relational)– structured data can be simplified (ej. DV_CODED_TEXT)– …

Object-Relational Mapping (ORM)• OO system (openEHR IM) & Relational DB => ORM

– OO: class, attribute, attr. type, relationship, inheritance– Relational: table, column, column type, reference

• Key elements:1. identity representation2. data type mapping3. association mapping (different cardinalities 1..1, 1..N, N..N)4. inheritance mapping

Identity in Object-Oriented Model• Objects have an identity to:

– differentiate between objects of the same class– reference those objects

• In the relational model we have Primary Keys• Solution:

– add an "id" column in each table– of type "int" or "long" and use it as PK– FKs reference only PKs "id"

• represents relationships in the OO model

Data Type MappingMySQL Postgres SQLServer Oracle

Date datedatetime

datetimestamp

datedatetime2

datedatetime

String varchartext

varchartext

varcharnvarchar

varchar2nvarchar2clob

Boolean bit boolean bit char(1) CHEK IN ('1','0')

Integer integer numeric int number

... ... ... ... ...

Each type we use in the OO model, should be mapped to a type in the DBMS we chose.

Mapping Classes Tables

Mapping Relationships

Mapping InheritanceTIP: on table per class, is

better to use the same value for "id" for the columns of the same

instances distributed in different tables.

Database Schema Examples

Some databases we have designed for openEHR data, but with different purposes

EHRServer

+ generic data storage+ focused on querying+ doesn’t map the whole IM+ training purposes (for now)

+ operational DB+ for an EMR system+ pretty normalized

Hybrid approach

• Considerations– Use only if it makes sense!

• for example if it improves querying performance / scalability– Modern Relational DBMS compete with some NoSQL features:

• support documents• scale through clusters• some allow in-memory tables or views

• Data Querying

Data Querying

AQL and path-based queries

Archetype Query Language• AQL is like SQL for EHRs• Archetype ID is "like" a table (type of info we want)

– openEHR-EHR-OBSERVATION.blood_pressure.v1• Data points identified by paths, "like" "columns (defined by each

archetype)– Systolic BP: /data[at0001]/events[at0006]/data[at0003]/items[at0004]/value

SELECT obs/data[at0001]/events[at0006]/data[at0003]/items[at0004]/value/magnitude, obs/data[at0001]/events[at0006]/data[at0003]/items[at0005]/value/magnitudeFROM EHR [ehr_id/value=$ehrUid] CONTAINS COMPOSITION [openEHR-EHR-COMPOSITION.encounter.v1] CONTAINS OBSERVATION obs [openEHR-EHR-OBSERVATION.blood_pressure.v1]WHERE obs/data[at0001]/events[at0006]/data[at0003]/items[at0004]/value/magnitude >= 140 OR obs/data[at0001]/events[at0006]/data[at0003]/items[at0005]/value/magnitude >= 90

Get high BP data

https://openehr.atlassian.net/wiki/display/spec/Archetype+Query+Language+Description

AQL - Query samples

Marco-Ruiz L, Moner D, Maldonado JA, Kolstrup N, Bellika JG,Archetype-based data warehouse environment to enable the reuse of electronic health record data, International Journal of Medical Informatics (2015), http://dx.doi.org/10.1016/j.ijmedinf.2015.05.016

SELECT o/data/events/data/items[at0078.13]/value AS WhiteCellCount FROM EHR e

CONTAINS COMPOSITION c [openEHR-EHR-COMPOSITION.encounter.v1]

CONTAINS OBSERVATION o [openEHR-EHR- OBSERVATION.lab_test_full_blood_count.v1] WHERE o/data/events/data/items[at0078.13]/value > 11000000000AND o/data/events/data/items[at0078.13]/value < 17000000000 TIME WINDOW P1Y/2014-02-12

AQL - Query samples

SELECT o/data/events/data/items[at0078.13]/value AS WhiteCellCount

FROM EHR e

CONTAINS COMPOSITION c [openEHR-EHR-COMPOSITION.encounter.v1]

CONTAINS OBSERVATION o [openEHR-EHR- OBSERVATION.lab_test_full_blood_count.v1]

o/data/events/data/items[at0078.13]/value > 11000000000AND o/data/events/data/items[at0078.13]/value <

17000000000 TIME WINDOW P1Y/2014-02-12

Infectious diseases tests monitoring at University

Hospital of North Norway AQL in action

AQL in actionInfectious diseases monitoring at

UNN:• Laboratory tests are extracted from

the LIS in a canonical XML format• Canonical extracts are transformed

into openEHR compliant extracts• Extracts are loaded into an

openEHR data warehouse (Think!EHR)

SELECT count(o1/data[at0001]/events[at0002]/data[at0003]/items[at0022]) -- count (patientId)FROM EHR e CONTAINS COMPOSITION c CONTAINS (OBSERVATION o1[openEHR-EHR-OBSERVATION.micro_lab_test.v1])WHERE ( o1/data[at0001]/events[at0002]/data[at0003]/items[at0010]/items[at0043]/items[at0036]/value = 'Kikhoste' AND o1/data[at0001]/events[at0002]/data[at0003]/items[at0010]/items[at0043]/items[at0037]/value='Positiv') ANDo1/data[at0001]/events[at0002]/data[at0003]/items[at0024]/value >= '2013-01-04' ANDo1/data[at0001]/events[at0002]/data[at0003]/items[at0024]/value < '2013-01-05'

AQL 1: + Count positive tests of Pertussis for the day specified in the parameter

AQL in action

SELECTcount(o1/data[at0001]/events[at0002]/data[at0003]/items[at0022]/value)FROM EHR e CONTAINS COMPOSITION c CONTAINS ( OBSERVATION o1[openEHR-EHR-OBSERVATION.micro_lab_test.v1] AND OBSERVATION o2[openEHR-EHR-OBSERVATION.micro_lab_test.v1] )WHERE ( o1/data[at0001]/events[at0002]/data[at0003]/items[at0010]/items[at0043]/items[at0036]/value = 'Salmonella' AND o1/data[at0001]/events[at0002]/data[at0003]/items[at0010]/items[at0043]/items[at0037]/value = 'Positiv') ANDo1/data[at0001]/events[at0002]/data[at0003]/items[at0020]/value = '1917' ANDo1/data[at0001]/events[at0002]/data[at0003]/items[at0024]/value >= '2013-01-01' ANDo1/data[at0001]/events[at0002]/data[at0003]/items[at0024]/value < '2013-01-15'

AQL 2: + Count patient ID + Salmonella cases in the specified municipality (same as patient just confirmed) + In the first 2 weeks of January

AQL in action

EHRServer Queries

Path-based queries in actionhttps://cabolabs-ehrserver.rhcloud.com/ehr-0.3/query/list

EHRServer Query Builder

Path-based queries in action

{ "uid": "9c5da334-4b81-4d60-92e2-aa96a722b4ac", "name": "Documents with high BP", "format": "xml", "type": "composition", "criteriaLogic": "OR", "criteria": [ { "archetypeId": "openEHR-EHR-OBSERVATION.blood_pressure.v1", "path": "/data[at0001]/events[at0006]/data[at0003]/items[at0004]/value", "conditions": { "magnitude": { "gt": [ 140 ] }, "units": { "eq": "mm[Hg]" } } }, { "archetypeId": "openEHR-EHR-OBSERVATION.blood_pressure.v1", "path": "/data[at0001]/events[at0006]/data[at0003]/items[at0005]/value", "conditions": { "magnitude": { "gt": [ 90 ] }, "units": { "eq": "mm[Hg]" } } } ]}

Path-based: + Get clinical documents (compositions) + With high BP

JSON expression of EHRServer

queries

Path-based queries in actionResults: + in XML (or JSON if specified on the query or as a parameter) + just the index, no data, get a document using the index or change the query to get the data

<list> <compositionIndex id="8"> <archetypeId>openEHR-EHR-COMPOSITION.signos.v1</archetypeId> <category>event</category> <dataIndexed>true</dataIndexed> <ehrId>11111111-1111-1111-1111-111111111111</ehrId> <startTime>2015-08-14 03:06:44.0 EDT</startTime> <subjectId>11111111-1111-1111-1111-111111111111</subjectId> <templateId>Signos</templateId> <uid>e152b2c2-7dbe-44b6-9ec6-2cd698561140</uid> </compositionIndex> <compositionIndex id="9"> <archetypeId>openEHR-EHR-COMPOSITION.signos.v1</archetypeId> <category>event</category> <dataIndexed>true</dataIndexed> <ehrId>11111111-1111-1111-1111-111111111111</ehrId> <startTime>2015-08-14 03:07:06.0 EDT</startTime> <subjectId>11111111-1111-1111-1111-111111111111</subjectId> <templateId>Signos</templateId> <uid>f0a8d192-0f68-4501-8373-f954a47a7385</uid> </compositionIndex> ... </list>

Path-based queries in action

{ "uid": "70764d85-4e4b-4548-8f71-3a294f35e704", "name": "Vital Signs", "format": "json", "type": "datavalue", "group": "path", "projections": [ { "archetypeId": "openEHR-EHR-OBSERVATION.blood_pressure.v1", "path": "/data[at0001]/events[at0006]/data[at0003]/items[at0004]/value" }, { "archetypeId": "openEHR-EHR-OBSERVATION.blood_pressure.v1", "path": "/data[at0001]/events[at0006]/data[at0003]/items[at0005]/value" }, { "archetypeId": "openEHR-EHR-OBSERVATION.body_temperature.v1", "path": "/data[at0002]/events[at0003]/data[at0001]/items[at0004]/value" }, { "archetypeId": "openEHR-EHR-OBSERVATION.body_weight.v1", "path": "/data[at0002]/events[at0003]/data[at0001]/items[at0004]/value" }, { "archetypeId": "openEHR-EHR-OBSERVATION.pulse.v1", "path": "/data[at0002]/events[at0003]/data[at0001]/items[at0004]/value" }, { "archetypeId": "openEHR-EHR-OBSERVATION.respiration.v1", "path": "/data[at0001]/events[at0002]/data[at0003]/items[at0004]/value" } ] }

Path-based: + Get clinical data for all vital signs measures + Result in JSON format, grouped by path (type of data)

JSON expression of EHRServer

queries

GastrOS – Endoscopy Databasehttp://gastros.codeplex.com

• Open Source openEHR implementation of a commercial DB for academic research (2011)

• Based on Minimal Standard Terminology for Digestive Endoscopy (MST 2)

• Works with openEHR RM directly– C# openEHR.NET (Open Source)– Uses 3 Templates (EGD, Colonopscopy, ERCP)

• Used RDMBS (MS Access and SQLite)• Uses ORM (Nhibernate) to store XML Compositions

EndoscopicObservation / Procedure

Heading

Attribute

MST Findings for Duodenum

MST Hierarchy

MST Structure

Content Model Coverage

SDE ParserOPT

ReferenceModel

Skeleton Instance(ENTRY types, CLUSTERS)

GUI Form: Widgets+Leaf nodes(ELEMENT)

SDE GUI Generator

AOM Representation

A Standards-based Approach to Development of Clinical Registries -

NZ Gestational Diabetes Registry Pilot

Dr. Koray Atalag MD, PhD, FACHI (National Institute for Health Innovation)

Aleksandar Zivaljevic, PhD candidate (Univ. Of Auckland)Dr. Carl Eagleton MBChB, FRACP (Counties Manukau District Health Board)

Karen Pickering (Diabetes Projects Trust)

GDM Registry Database• Used OceanEHR Framework

– Academic license from Ocean Informatics– Simplifies persistence and querying plus more!– Supports openEHR Demographic IM– Supports AQL

• Extended MultiPrac App (Source provided on academic license)– MVC Application (VS 2010 w/ SQL Server)– Handles user management, basic admin etc.– Supports reference sets, provider/organisation etc.

The Dataset

Automatic technical conversion – C# Class

Make your own or reuse existing openEHR persistence?

• Open reusable openEHR persistence & query APIs have been suggested and are now being formally specified – Join the REST discussion, openEHR wiki + mailinglists

https://openehr.atlassian.net/wiki/display/spec/openEHR+REST+APIs – Implementations of openEHR SOAP interfaces exist.

• A SOAP API could be formally specified if there is enough interest– Other API options?

• New reusable implementations are welcome! • Before implementing your own persistence, consider:

– Is your main interest storage or clinical application?– Would AQL be helpful in some of your use-cases?– In what way will it need to scale?

Conclusion• openEHR doesn’t specify how to store openEHR clinical data

– not bound to any technology or modeling technique• Remember to model data with references to metadata

– archetype id, template id, path, node id• Use operational templates in software, not archetypes directly

– archetypes are too generic, too many options, not so good for software• Choosing a technology is on you

– there is no one-fits-all solution– you might need to mix technologies (hybrid solution)

• Modify the openEHR Information Model– to create your storage model using the chosen technology

• Design generic query mechanisms based on archetype ids and paths– go for AQL support if you need it, allows to share queries between openEHR

Clinical Data Storages• Designing and querying Clinical Databases is hard!

– now you have some pointers on where to start

Muito Obrigado!Perguntas?

pablo.pazos@cabolabs.com @ppazosgithub.com/ppazos

koray @atalagk

erik .sundvall@liu.se@ErikSundvallgithub.com/ErikSundvallhttp://www.imt.liu.se/~erisu/sergio@lampada.uerj.br

luis.marco.ruiz@telemed.no

design and implementation of clinical databases using openehr

Healthcare

tesis sueca-openehr

dr heather leslie md, clinical modelling lead, ocean...

developing openehr ehrs - core functionalities

interoperability: managing clinical · pdf filemanaging...

ehr architecture architecture overvie · openehr...

using full ad clinical trials databases for simulating and...

clinical research databases

medinfo 2010 openehr clinical modelling worshop

openehr medinfo2015 brazil sponsor session

introduction to openehr clinical knowledge manager

introduction to openehr archetypes and templates

introduction to openehr clinical workshop mie2016

scimp openehr ckm workshop 2015

ehr architecture architecture overview - openehr · openehr...

representing clinical information using snomed clinical...

what is openehr? - code4health · what is openehr? an open...

openehr specification projectrelease 1.0 - road...

localisation of openehr in japan

enabling clinical data reuse with openehr data warehouse...

aleksandar zivaljevic - annotation of clinical datasets...