Interoperability and Standards

Dr Christopher Seebregts • Senior Manager, Biomedical Informatics Research, Medical Research Council

• Honorary Associate Professor, School of Computer Science, University of KwaZulu-Natal

• Executive Director, Jembi Health Systems

• SOUTH AFRICA

CJ Seebregts; 8 Sep 2011

Contents

1. Interoperability

1. Interoperability and Integration

2. Interoperability, Systems and Architecture

3. Case Study: Improving MCH Interoperability in Rwanda

2. Standards

1. Teminologies, Vocabularies and Standards

2. Examples of Standards (ICD, SnoMED, HL7)

3. Open Standards

2

CJ Seebregts; 8 Sep 2011

Definition

• The Healthcare Information and Management Systems Society (HIMSS) distinguishes between integration and interoperability:

• Integration is the arrangement of an organization’s information systems in way that allows them to communicate efficiently and effectively & brings together related parts into a single system.

• Interoperability is the ability of health information systems to work together within and across organizational boundaries in order to advance the effective delivery of healthcare for individuals and communities”.

3

Interoperability levels in open systems

SOCIAL WORLD - beliefs, expectations, commitments, contracts, law, culture, ...

PRAGMATICS - intentions, communication, conversations, negotiations, ...

SEMANTICS - meanings, propositions, validity, truth, signification, denotations, …

SYNTACTICS - formal structure, language, logic, data, records, deduction, software, file, ...

Ouksel, A.M. & Sheth, A. (1999), 'Semantic interoperability in global

information systems', SIGMOD Rec. 28(1), 5--12.

Interoperable Systems Architecture

5

Open standards slide courtesy of Dr Deshen Moodley, Health Enterprise Architecture Laboratory, School of Computer Science, UKZN

• An agreed way of doing things

• Includes data syntax and semantics, system architecture, communication protocols

• Standards that are developed by a community driven, participatory and even consensus approach

• Freely accessible, aims for maximum adoption, balances generality and pragmatic use

• Aim to have at least one open source reference implementation but does not preclude proprietary implementations

6

INTEROPERABILITY CSE STUDY:

Improving Interoperability for Maternal and

Child Health in Rwanda

slide courtesy of Derek Ritz, ecGroup

7

Goals

• Increase the number of pregnant women accessing

ante-natal care services

• Increase the number of HIV-positive pregnant

women accessing PMTCT services

• Improve progress in implementing MDGs 4, 5 and 6

8

Detailed Clinical Workflow slide courtesy of Derek Ritz, ecGroup

VCT clinic

Village

ANC clinic

Participants

9

Relevant Point of Care Applications

10

Technology components

TS

HIAL

LRS

CR

PR

SHR

VCT Clinic

Mosa’s Village

Community Clinic

HL7

HL7

SMS Core Architectural Services:

• Client Registry and Patient Identification (CR)

• Provider and Facility Registry (PR)

• Terminology Standards and Service (TS)

• Shared Health Record (SHR)

• Logical Record Service (LRS

• Health Information Access Layer) 11

Canada Health InfoWay EHR Architecture

12

Standards

Contents

• Classification of Standards

• Examples of Standards

• International Classification of Diseases (ICD)

• SNoMED

• HL7v2

• HL7v3

• Clinical Document Architecture (CDA)

• SDMX-HD

14

Classification of Standards

Can classify standards in four dimensions

• Organization

• Process

• Information

• Technology

• http://www.hiwiki.org

15

Classification of Standards

16

International Classification of Diseases (ICD)

17

Structure of SNoMED CT

• Some basic principles behind its design are listed below in order to provide a foundation for understanding the SNOMED CT structure.

• SNOMED is based on “concepts.” Each concept represents a unit of thought

or meaning and is labeled with a unique identifier (computer readable).

• The phrases in human language used to describe the concept are called “descriptions” (or synonyms). Each concept has one or more descriptions linked to it.

• Each concept is interrelated to other SNOMED concepts that have logical connections to it. Relationships are used to provide a computer readable definition of the concepts. These definitions greatly enhance the value of the data collected, allowing it to be searched, retrieved, reused or analyzed in a variety of ways.

18

SNoMED-ICD

19

Health Level Seven (HL7)

V2 Message Structure A simple HL7v2 partial message example is shown below; a 182 mg/dl Glucose value was

observed for Eve Everywoman:

PID|||555-44-4444||EVERYWOMAN^EVE^E^^^^L|JONES|19620320|F||||||||||AC555444444||

OBX|1|NM|1554-5^GLUCOSE:POST 12H CFST:MCNC:PT:SER/PLAS:QN||182|mg/dl|70-105|H|||F

Core characteristics of HL7v2 include:

• The core elements of reusability in the standard are a) data types and b) segments and to a certain degree c) segment groups (e.g. “OBR {OBX-” or “PID *PD1+ ,*NK1+-”).The syntax used is an EDI syntax – the industry standard at the time of creation of HL7v2 in 1987.

• It supports the exchange of EDI-style “messaging”.

• The standard was created in order to mainly support the administrative, logistical and financial processes within hospitals. It has the capacity to support the exchange of medical data of relatively low complexity (e.g. lab result, textual radiology report).

20

HL7 ctd

v3 Core Characteristics • The core elements of reusability in the standard are a) data types and b) Common Message

Element Types (CMETs). • CMETs are the HL7v3 equivalent of a segment or segment group; example CMETs are Patient (which includes next of kin),

Provider and Coverage (i.e. insurance).

• The syntax used is XML – the industry standard at the time of creation of HL7 version 3 in 1995. This, by its very nature, leads to more human readable, but also more bloated messages.

• Everything is a model – Model Driven Engineering (MDE) methods are used to derive XML Schema; the models van also be used for class/code generation.

• It supports the exchange of EDI-style “messaging”, services as well as an e-Document approach (Clinical Document Architecture, CDA).

• The standard was created in order to support all healthcare workflows, including (but not limited to) the exchange of data between organizations. It has the capacity to support the exchange of medical data of high complexity (e.g. for decision support, EHRs, clinical research).

• When one exchanges data between organizations there is less in terms of shared context. The lower the shared context, the more context one has to include in the data which is exchanged. As such HL7 version 3 is richer in content than HL7 version 2.

21

Reference Information Model (RIM)

22

HL7v3 Message Structure (1)

<recordTarget>

<patientClinical>

<id root="2.16.840.1.113883.19.1122.5" extension="444-22-2222"

assigningAuthorityName="GHH Lab Patient IDs"/>

<statusCode code="active"/>

<patientPerson>

<name use="L">

<given>Eve</given>

<given>E</given>

<family>Everywoman</family>

</name>

<asOtherIDs>

<id extension="AC555444444" assigningAuthorityName="SSN"

root="2.16.840.1.113883.4.1"/>

</asOtherIDs>

</patientPerson>

</patientClinical>

</recordTarget>

23

HL7v3 Message Structure (2)

Part 2: Observation

<observationEvent>

<id root="2.16.840.1.113883.19.1122.4" extension="1045813"

assigningAuthorityName="GHH LAB Filler Orders"/>

<code code="1554-5" codeSystemName="LN" codeSystem="2.16.840.1.113883.6.1"

displayName="GLUCOSE^POST 12H CFST:MCNC:PT:SER/PLAS:QN"/>

<statusCode code="completed"/>

<effectiveTime value="200202150730"/>

<value xsi:type="PQ" value="182" unit="mg/dL"/>

<interpretationCode code="H"/>

<referenceRange>

<interpretationRange>

<value xsi:type="IVL_PQ">

<low value="70" unit="mg/dL"/>

<high value="105" unit="mg/dL"/>

</value>

<interpretationCode code="N"/>

</interpretationRange>

</referenceRange>

</observationEvent>

24

Clinical Document Architecture (CDA)

• The HL7 Clinical Document Architecture (CDA) is a document markup standard that specifies the structure and semantics of "clinical documents" for the purpose of exchange. A clinical document contains observations and services and has the following characteristics:

• Persistence – A clinical document continues to exist in an unaltered state, for a time period defined by local and regulatory requirements 1.

• Stewardship – A clinical document is maintained by an organization entrusted with its care.

• Potential for authentication - A clinical document is an assemblage of information that is intended to be legally authenticated.

• Context - A clinical document establishes the default context for its contents.

• Wholeness - Authentication of a clinical document applies to the whole and does not apply to portions of the document without the full context of the document.

• Human readability – A clinical document is human readable.

A CDA document is a defined and complete information object that can include text, images, sounds, and other multimedia content.

25

CDA Document Structure

26

Open standards slide courtesy of Dr Deshen Moodley, Health Enterprise Architecture Laboratory, School of Computer Science, UKZN

• An agreed way of doing things

• Includes data syntax and semantics, system architecture, communication protocols

• Standards that are developed by a community driven, participatory and even consensus approach

• Freely accessible, aims for maximum adoption, balances generality and pragmatic use

• Aim to have at least one open source reference implementation but does not preclude proprietary implementations

27

SDMX-HD

28

SDMX-HD

• SDMX-HD is a Statistical Data and Metadata Exchange (SDMX)-based data exchange format intended to serve the needs of the Monitoring and Evaluation community in the health domain (HD). It has been developed by the WHO and partners to facilitate the exchange of indicator definitions and data in aggregate data systems. Ryan Crichton of Jembi Health Systems developed an Integration Module in OpenMRS which allows OpenMRS to export aggregate data in the SDMX-HD format. It makes use of the Reporting Module for OpenMRS and allows the mapping of Indicator and Dimensions created in the reporting module to be mapped to Indicators and Dimensions in a SDMX-HD Data Set Definition. This allows the user to create any custom repots in OpenMRS and map those to a SDMX-HD Dataset definition. Once this is done they can export data in a standardised format using the SDMX-HD Integration Module.

• Jembi worked closely with, Bob Jolliffe, a Developer of DHIS 2.0 (District Health Information System). DHIS stored aggregate data and allow repoting of that aggregate data at a District level. SDMX-HD support was built into DHIS that allows user to generate a SDMX-HD dataset definition for the DHIS dataset definitions and to import SDMX-HD data file. This means that DHIS and OpenMRS can now interoperate using a standardised format due to the support build into each of the systems.

• This is a big step toward interoperability between open source applications using standardised formats and it is hoped that the software build here can be widely used to demosatrate the importance of using standard and building interoperable systems.

29

Collaborators and Contributors

• MRC

• UKZN

• Jembi Health Systems

• Meraka Institute, CSIR

• Ministry of Health, Mozambique

• Ministry of Health, Rwanda

• MOASIS, Mozambique

• Pivot Access, Rwanda

• UNICEF, Rwanda

• OpenMRS Foundation, USA

• Regenstrief Institute, USA

• InSTEDD, USA

• ecGroup Inc, Ontario, Canada

• Mohawk College, Ontario, Canada

• eZ-Vida, Brazil

• PATH, USA

• Canada Health InfoWay, Canada

• Partners in Health, USA

• Millennium Villages Project, USA

• University of Washington, USA

30