singapore healthcare’s journey towards interoperability ......introduction mohh plan & key...

Singapore Healthcare’s Journey towards Interoperability, Sharing and Reuse

Tony Lam*, Senior ConsultantWong Ming Fai*, Senior ConsultantSari McKinnon, Principal

Enterprise ArchitectureInformation Systems Division, MOHH

11th July, 2010

*Also staff of Infocomm Development Authority of Singapore

This material contains information that is confidential to MOH Holdings Pte Ltd (MOHH) and should not be circulated beyond MOHH without permission. 2M O H H o l d i n g s P t e L t d

The Crooked Bridge


Outline

� Introduction

� MOHH Plan & Key Initiatives

� Architecture Initiatives Highlight

� Service Catalogue

� Interoperability & Integration Architecture

� National Health Service Bus Reference Architecture

� Enterprise Architecture Repository

� Conclusion


Singapore: Small Country but Big City

� 4.99 million people on 710.3 sq km (7,025/km2)

� 125% of Los Angeles’ population in half its area

� Ethnically diverse:� Chinese: 75 per cent

� Malays: 14 per cent

� Indians: 9 per cent

� 35,000+ healthcare workers

� 11,580 hospital beds

� 429,744 hospital admissions (2007)

� Public sector out-patient visits (2007)� Specialist Outpatient Clinics 3,687,910

� A&E 752,122

� Polyclinics 3,797,953


Primary Care Long-Term CareAcute &Intermediate Care

Fragmented IT Landscape

Restructured Hospital

Rehab & Support Services

Community Hospital

Polyclinics

General Practitioners

Screening & Preventation

Nursing Home

Home Care

Palliative Care

Public sectorPrivate sector

People sector


“One Singaporean, One Health Record”

Interoperability, Sharing and Re-use are key to: 1.Achieve this vision2.Maximise Return on Investment

Interoperability, Sharing and Re-use are key to: 1.Achieve this vision2.Maximise Return on Investment


Electronic Records - EMR vs. EHR

EMRSpecific to an facility (institution, private office); the equivalent of its paper predecessor and includes everything that is recorded by that organization about a given patient. It has “depth” but lacks “breadth”.

EHRSpecific to an individual; captures a key subset of health

information from multiple point of service systems. It is available electronically to authorized healthcare providers and the individual anywhere, anytime in support of high quality care. This record is designed to facilitate the sharing of data across the continuum of care, across healthcare delivery organizations and across geographies.


Outline

� Introduction

� MOHH Plan and Key Initiatives



� Interoperability Architecture



� Conclusion


Singapore iN2015 Goal for Healthcare and Biomedical Sciences

About MOHH


National Electronic Health Record (NEHR)

Hea

lthca

re In

nova

tions

ILTC (Residential) ILTC (Community)

Wellness & Prevention

Primary Care Acute Care

Communications, Education and Change Management Patient Care Provider Caregiver Industry Agencies

Data Standards Enterprise Architecture

Privacy & Security Medical Informatics

GP IT Enablement

Prog*

Primary Care Prog *

Healthcare Informatics Summit 2010 *

Comm Hospital Integration Care

(CHIC) *

ILTC Prog & Mental Health Prog *

Nat’l Standards Prog*

Medical Product & Service Catalogue

Healthcare Authentication &

Access Mgmt Framework

Healthcare IT Summit & Medical Informatics

CourseTelecare

Prog *

Joint Healthcare

CFC *

NEHR Prog

Personal Health Records

Agency for Integrated Care (AIC)

Regional Health

Services (RHS)

NEHR EA

CIC EA

Nat’l Data DictionaryNat’l Drug Dictionary

Nat’l Privacy Framework

EHR Clinical Taskforces

Interop Arch, Services

Catalogue

NHSB Ref Arch, EA repository


Intermediate and Long Term Care

(Residential)

Intermediate and Long Term Care

(Community)






Our Plan



Hea

lthca

re In

nova

tions

ILTC (Residential) ILTC (Community)



Communications, Education and Change Management Patient Care Provider Caregiver Industry Agencies



GP IT Enablement

Prog*

Primary Care Prog *

Healthcare Informatics Summit 2010 *

Comm Hospital Integration Care

(CHIC) *

ILTC Prog & Mental Health Prog *

Nat’l Standards Prog*

Medical Product & Service Catalogue

Healthcare Authentication &

Access Mgmt Framework

Healthcare IT Summit & Medical Informatics

CourseTelecare

Prog *

Joint Healthcare

CFC *

NEHR Prog

Personal Health Records


Regional Health

Services (RHS)

NEHR EA

CIC EA

Nat’l Data DictionaryNat’l Drug Dictionary

Nat’l Privacy Framework

EHR Clinical Taskforces

Service Catalogue,

IIA, ESB Ref Arch, EA Repo

Our Plan


Outline

� Introduction

� MOHH Plan






� Conclusion


Two Key Dimensions


Two Key Dimensions

Service CatalogueInteroperability Architecture

National Health Service BusReference Architecture

Enterprise Architecture Repository


Outline

� Introduction

� MOHH Plan






� Conclusion


Service Catalogue

� Background:� Early 2010, two-month effort

� Objectives:� Provide a baseline of NEHR services� Take a step towards SOA-based NEHR architecture

� Deliverables:� Approach for identifying services

� Template for documenting identified services

� Roadmap for realising services during NEHR implementation


Organisation

� 5 Domains: EHR, Identify and Access Mgmt, Terminology, National Health Identification Service, Integration

x 461x 461

x 82x 82

x 24x 24

x 5x 5


A Peek into the Service Catalogue

Domain

Functional Area

Service Name

Service Name Description

Service Operation

Service Operation Description

Service Input

Service Output

EHR1. Summary

Care Record

Patient

Manages the

services to

register

patients.

AddPatient

Registers a

new patient

with the EHR

based on

inputs from

the source

systems

Patient

Particulars;

e.g. Last

Name, First

Name, etc

Success

or failure

indicator

EHR1. Summary

Care RecordDeletePatient

De Registers

the patient

from the EHR

based on the

source

systems

PID

Success

or failure

indicator


Current Business Requirements

COTS Functions/Features

Industry Practices

Service Modeling Phase 0

SERVICE IDENTIFICATION

Service Catalogue v1.0

Service Modeling Phase 1

SERVICE IDENTIFICATION, SPECIFICATION,

REALIZATION

Finalized NEHR Use Cases

Current System Interfaces

Non-Functional Requirements

NEHR Implementation PhaseFirst Iteration

Others…

Existing Catalogue documents

Service Catalogue Construction Approach

� Develop first-cut based on available information� Plan to revise after NEHR vendor selection and

finalisation of use cases and requirements

Service Catalogue v2.0


Next Steps

� Review and update catalogue (leveraging on EA Repository)

� Get other applications to re-use NEHR services

� Stronger tie-up with Interoperability Architecture


Outline

� Introduction




� Interoperability and Integration Architecture



� Conclusion


Key Questions Answered:

� Interoperability Specifications– How can EHR information be understood

in a consistent manner?� Integration Services

– What capabilities does the EHR need to provide to support interoperability and integration?

� Security� Administration

– How does interoperability impact administration and operations of EHR and EMR systems?

� Infrastructure

Interoperability Specifications

Infrastructure

Adm

inis

trat

ion S

ecurity

Integration Services

Interoperability and Integration Architecture


Information Exchange Requirements


Linkage to Standards

S/N

Name Purpose Integration Standards

Semantic Standards

5 Doc –Request EMRX

Request source system for a specific document.

Leverages on EMRX’s GetDoc functionality.

Web Service EMRX XML


Linkage to Service Catalogue

Domain Functional Area Service Name Service Operation Service Operation Description

EHR1. Summary Care

RecordMedication

UpdatePatientMedic

ation

Update

medication(s) on

the patient

medication list.


Outline

� Introduction







� Conclusion


National Health Service Bus Reference Architecture

� Background

� Most systems integrations (EMR, Labs, Rad … etc) in large healthcare settings are using traditional MLLP via integration engine

� minimal Enterprise Service Bus (ESB) investments to-date.

� However, ESB is being considered in a number of upcoming large scale healthcare IT initiatives. For example, National Electronic Health Records (NEHR), National Health Identify Services (NHIS),Clinical and EMR Operation System (CLEO) and other hospital cluster wide projects.

Opportunity for early alignment !!!



� Process

� One month exercise

� Over 10 internal/external stakeholders engaged for interviews, major stakeholders participated in working group

� Deliverables and Outcome

� A Reference Architecture for ESB landscape

� Key directions identified for moving towards the reference architecture


NationalHealthcare

ESB

NHG Apps

Cluster Apps

AIC Apps

NEHR

AIC

MOH Apps

MOHH

EHR-IX (Cluster) Internal

Other NHG/SHS Cluster (1..n)

EHR-IX (NHG) Internal EHR-IX (NHG)

EHR-IX (AIC) Internal EHR-IX (AIC)

EHR-IX (MOHH) Internal EHR-IX (MOHH)

Medinet

HPB Apps

EHR-IX (Cluster)

NHIS

CLEOS

CHIC

NHG

SHS Apps

EHR-IX (SHS) Internal

SHS

EHR-IX (SHS)

SCM

Reference Architecture

Characteristics1. Federated Model. No one single ESB

for everybody. Multiple ESB instances in the whole landscape

2. Each hospital cluster will have own physical instance of ESB, with dedicated ESB partition for external integration.

3. Planned initiatives that required ESB capability (e.g. National EHR)

Key Considerations:-Org/structures, governance, operation

performance, effort/cost

1

2

2

33

3

3

3

2

2

2


Key Direction #1 – Shared ESB for MOHH driven initiatives

NEHR & NHIS

ESB

CLEOS

ESB

CHIC

ESB

AIC

ESB

NHG

ESB

SHS

ESB

Isolated Infrastructure

NEHR, NHISCLEOS, CHIC

AIC

ESB

NHG

ESB

NHG

ESB

Shared Infrastructure

Isolated1. Investment in more sets of ESB platforms and

implementation.2. Investment in more physical network

connections and data centre operations.

Shared1. Investment in less sets of ESB platforms and

implementation.2. Investment in less physical network

connections and data centre operations.

Hospital cluster(s)

MOHH driven initiatives

SHS


Key Direction #2 – National EHR to extend the Info exchange platform to support other MOHH initiatives

NationalHealthcare

ESB

NHG Apps

Cluster Apps

AIC Apps

NEHR

AIC

MOH Apps

MOHH






Medinet

HPB Apps

EHR-IX (Cluster)

NHIS

CLEOS

CHIC

NHG

SHS Apps


SHS

EHR-IX (SHS)

SCM

Considerations: Scale and project timeline dependency, and infrastructure requirements


Key Direction #3 – Leverage on same products/technologies for other ESBs

NationalHealthcare

ESB

NHG Apps

Cluster Apps

AIC Apps

NEHR

AIC

MOH Apps

MOHH






Medinet

HPB Apps

EHR-IX (Cluster)

NHIS

CLEOS

CHIC

NHG

SHS Apps


SHS

EHR-IX (SHS)

SCM

Considerations• Ease of Integration, establishing

of logical SOA registry for all cross-org services to facilitate reuse

Service Registry

NEHR (Int & Ext)NHIS (Int & Ext)

CLEOS (Int & Ext)CHIC (Int & Ext)

MOHH

NHG Apps(Int & Ext)

NHG

SHS Apps(Int & Ext)

SHS

AIC Apps (Int & Ext)

AIC

MOH & HPB Apps(Ext)

Medinet

EHR-IX Registry

NEHR (Int & Ext)NHIS (Int & Ext)

CLEOS (Int & Ext)CHIC (Int & Ext)

MOHH

NHG Apps(Int & Ext)

NHG

SHS Apps(Int & Ext)

SHS

AIC Apps (Int & Ext)

AIC

MOH & HPB Apps(Ext)

Medinet

EHR-IX Registry


Outline

� Introduction




� Interoperability and Integration Architecture



� Conclusion


Enterprise Architecture (EA) Repository

Background

• Our IT initiatives involve a lot of integration -> need intensive planning

• For planning purpose, we gather & generates vast amount of architecture artefacts in different formats, stored in different locations and captured from different perspective.

• Lack consistent way to maintain/update. Artefacts collected become obsolete overtime

• Difficult to cross-harmonise and reuse.

.

1.0 Support & Educate Patient

1.1 Educate

1.2 Enable Self Management

2.0 Deliver Health Services

2.1 Schedule / Register 2.2 Assess Patient 2.3 Deliver Care 2.4 Transfer of Care

3.0 Plan & Manage the Health System

3.1 Manage Logistics

3.2 Manage Finances

3.3 Manage Legal & Commercial

3.4 Manage HR 3.5 Manage IT

4.0 Manage Population Health

4.1 Design Programme 4.2 Execute Programme 4.3 Evaluate Programme

1.2.1 Access Screening Data in PHR

2.5 Manage Patient Flow

4.3.1 Extract EHR Data for Programme Evaluat ion

4.1 Define & Manage Performance Targets

4.1.1 Extract EHR Data for Clinical Audit

3.7 Manage Quality

3.8 Manage Policy

1.3 Access Care

3.1.1 Manage Facil ity Information

3.4.1 Manage Clinic ian Information

2.1.1 Enable EHR Access

2.1.2 Manage Patient Demographics

2.1.3 Capture Care Team Details

2.2 .1 Rev iew Summary Record

2.2 .3 Rev iew Invest igation Details

2.2 .4 Rev iew Procedure Detai ls

2.2 .5 Rev iew Referral Details

2.2 .6 Rev iew Care Plans

2.2 .2 Rev iew Event Details

2.2 .7 Rev iew Notifications

2.3.1 Create / Manage Care Plans

2.3.2 Reconc ile Medications

2.3.3 Reconc ile Problem List

2.3.4 Update Allergy / ADR

2.4.1 Create / Manage Referral

2.4.2 Create Event Summary

2.4.3 Create Discharge Summary

3.5.1 Manage EHR Operations

Level One business capability

Level Two business capability

EHR-related functionality

Legend

Not direc tly impacted by EHR


1.1 Educate






3.2 Manage Finances










3.7 Manage Quality

3.8 Manage Policy

1.3 Access Care
























Legend


Data Source Dat

a T

ype

Pat

ient

Dem

ogra

phic

s

Eve

nt

AM

D

Car

e T

eam

Scr

eeni

ng

Ref

erra

l Rec

ord

Inpa

tien

t Dis

ch S

um (

str)

Com

Hos

p D

isch

Sum

(st

r)

Pol

yclin

ic E

vt S

um (

str

)

ED

Evt

Sum

(st

r)

Pvt

GP

Evt

Su

m (

str)

Ref

erra

l Doc

umen

t

Alle

rgie

s

Imm

uni

satio

n

Med

icat

ion

Ord

ers

His

tory

Med

icat

ions

Dis

pens

ed H

isto

ry

Med

icat

ions

Cur

rent

Med

icat

ions

Rec

onci

led

Pro

blem

/Dia

gnos

is H

isto

ry

Pro

blem

/Dia

gnos

es R

econ

cile

d

Lab

Ord

ers

Lab

Rep

orts

Rad

Rep

ort

Rad

Ord

ers

Rad

Imag

e

Pro

cedu

re R

epor

t

Tra

nsfe

r of

Car

e c

omp

in d

ocs

NHG R1 R1 - - - - R1 - - R1 - - - - R1 R1 - - R1 - - R1 R1 - - R1 -SHS R1 R1 - - - - R1 - - R1 - - - - R1 R1 - - R1 - - R1 R1 - - R1 -GP EMR R1 - - - - - - - - - - - - - - - - - - - - - - - - - -Com. Hosp EMR R1 R1 - - - - - R1 - - - - - - R1 R1 R1 R1 R1 R1 - - - - - - -AIC - - - - - - - - - - - - - - - - - - - - - - - - - - -DOT - - - - - - - - - - - - - - - - - - - - - - - - - - -CMIS - - - - - - - - - - - - R1 - - - - - - - - - - - - - -NIR - - - - - - - - - - - - - R1 - - - - - - - - - - - - -Mindef - - - - - - - - - - - - - R1 - - - - - - - R1 - - - - -MOH AMD - - R1 - - - - - - - - - - - - - - - - - - - - - - - -


Need for EA Repository


1.1 Educate






3.2 Manage Finances










3.7 Manage Quality

3.8 Manage Policy

1.3 Access Care
























Legend



1.1 Educate






3.2 Manage Finances










3.7 Manage Quality

3.8 Manage Policy

1.3 Access Care
























Legend


Data Source Dat

a T

ype

Pat

ient

Dem

ogra

phic

s

Eve

nt

AM

D

Car

e T

eam

Scr

eeni

ng

Ref

erra

l Rec

ord

Inpa

tien

t Dis

ch S

um (

str)

Com

Hos

p D

isch

Sum

(st

r)

Pol

yclin

ic E

vt S

um (

str

)

ED

Evt

Sum

(st

r)

Pvt

GP

Evt

Su

m (

str)

Ref

erra

l Doc

umen

t

Alle

rgie

s

Imm

uni

satio

n

Med

icat

ion

Ord

ers

His

tory

Med

icat

ions

Dis

pens

ed H

isto

ry

Med

icat

ions

Cur

rent

Med

icat

ions

Rec

onci

led

Pro

blem

/Dia

gnos

is H

isto

ry

Pro

blem

/Dia

gnos

es R

econ

cile

d

Lab

Ord

ers

Lab

Rep

orts

Rad

Rep

ort

Rad

Ord

ers

Rad

Imag

e

Pro

cedu

re R

epor

t

Tra

nsfe

r of

Car

e c

omp

in d

ocs

NHG R1 R1 - - - - R1 - - R1 - - - - R1 R1 - - R1 - - R1 R1 - - R1 -SHS R1 R1 - - - - R1 - - R1 - - - - R1 R1 - - R1 - - R1 R1 - - R1 -GP EMR R1 - - - - - - - - - - - - - - - - - - - - - - - - - -Com. Hosp EMR R1 R1 - - - - - R1 - - - - - - R1 R1 R1 R1 R1 R1 - - - - - - -AIC - - - - - - - - - - - - - - - - - - - - - - - - - - -DOT - - - - - - - - - - - - - - - - - - - - - - - - - - -CMIS - - - - - - - - - - - - R1 - - - - - - - - - - - - - -NIR - - - - - - - - - - - - - R1 - - - - - - - - - - - - -Mindef - - - - - - - - - - - - - R1 - - - - - - - R1 - - - - -MOH AMD - - R1 - - - - - - - - - - - - - - - - - - - - - - - -

Distilled In

fo

A repository is required to

•capture & manage the gist of the

architecture information in a

structured manner

•as a single source of info (though

may not be the truth) to facilitate

ongoing analysis and planning

Key Challenge:

• How to maintain, align, exploit and reuse these architecture information for ongoing planning purpose?


Example of pain points

•We need clarity and visibility for the “operating” environment•It is just too complex (e.g. over 150 applications, 300 known interfaces

in clinical area alone for just one hospital cluster). Nobody has a full

picture.

•We want to mitigate ambiguity and standardise vocabularye.g. is it “prescribed medications” or “ordered medications” ?

•We want to facilitate Architecture Information Reuse and

Sharinge.g. I would like to know roughly which systems process this type of

data and who are the project managers that I should talk to for more

info. I do not want to start from zero !!!

It is a little bit like Knowledge Management !!!


Data Architecture Technology ArchitectureBusiness Architecture Application Architecture

Architecture Principles, Vision & Requirements

How it is used

Other References

Architecture Principles

D

Architecture Requirements RepositoryRequirements | Constraints | Assumptions | Gaps

D Architecture VisionBusiness strategy | Business Principles Objectives & Drivers | Stakeholders | Technology Strategy

D

Deliverable's PARCI

DProcesses

DArchitecture Decision Log

D Staff Contact list

DToolkits

DSpecifications?

DArchitecture Position Statement

D

IT Master Plan(current and to-be view )supported Business Domains/Organizations (Business Support) - which IT systems provides which Capabilities to which Organizations.

A

Program PlanPlanned programs with view of affected Architecture, dependencies and program overlap

A

OrganizationA

CapabilityA

Process*(Attachment)

A

ApplicationA

ApplicationReleases

AServices

A

Information FlowA

Business Object (LIM)

A

Business Data (Physical)

A

ComponentsA

Standard Components

A

Standard Platform

A

GlossaryA

ComponentModule

A

Typically unstructured info, (e.g. docs) generated for purpose like

general communications, consumption by mgmt

DTypically structured Info that

is crucial for architecture

planning – managed by the EA repository

A


Service Catalogue in the EA Repository

Service Catalogue

Data in the service

Applications providing the service


Interoperability Architecture the in EA Repository

Interfaces view for a application

Interfaces view for a application


Inner Governance (Internal Operation & Control)

EA Repository –Supporting Architecture Assurance & Governance

EA –Project Engagement

(Interaction Points)

EA Repository

Architecture Office

Implementation Projects

(NEHR, CLEO, NHIS)

PrincipalEnterprise Architect

PrincipalEnterprise Architect

ArchitectureChange

Management

ArchitectureChange

Management

Architects (Enterprise & Domain)

Architects (Enterprise & Domain)

Guidance

Business Capability

Business Capability

Technology Roadmap

Technology Roadmap

Application Status

Application Status

Stage 3 (Delivery)Stage 3 (Delivery)

InceptionInception

ElaborationElaboration

RealizationRealization

Senior ManagementSenior Management

SimplifiedInteraction

New projects to tap on for initial planning

Senior Management Stewardship

1

6

3

4

1. EA team member assigned as project architect support a particular project,

2. Identify architecture gaps & opportunities as a natural part of the project execution. E.g.:• Shared infra (e.g. ESB) need• Reuse existing services

3. Architecture office review gaps and opportunities..

4. The review will serve as input for on-going architecture development/ refresh. E.g.:• Change in technical standards direction

5. Architecture decision that has cross project/ program impact (e.g. NEHR to extend its ESB to cover others’ need) will escalate to senior management for support and endorsement.

6. Project architecture info will be refreshed into the EA repository

7. Subsequently, new implementation projects can make use of artifacts in the EA repository (e.g. Current state of applications, IT roadmap etc) for initial planning => avoid starting from zero.

2

5

7

Information Flow

Information Flow

Others architecture

artefacts

Others architecture

artefacts


Outline

� Introduction




� Interoperability & Integration Architecture



� Conclusion


Conclusion

Service CatalogueInteroperability Architecture


Enterprise Architecture Repository


Conclusion

Singapore is embarking on multiple large-scale, and multi-years initiatives across its healthcare settings, taking an SOA-based approach to facilitate interoperability, sharing and reuse.

As of now, key learning points are:

� Pragmatic – “how does it help for investment, project planning and implementation?”

� “Just-enough” & “just-in-time” effort to show progress and value

� Continuously to re-visit, re-validate and re-align the architecture to ensure the relevancy

Key Challenges are:

Diversity of current systems/solution capability, on-going parallel inter-dependent projects and forever changing landscape


Conclusion

If this whole journey is a soccer match, then we are at the end of the pre-match planning.

The real match is about to start …..

Thank You

MOH Holdingswww.mohh.com.sg

singapore healthcare’s journey towards interoperability ......introduction mohh plan & key...

Documents