Interoperability Capability Guidelines

Key points from the Australian eHealth Interoperability Framework

HL7 ARB Presentation Zoran Milosevic, NEHTA, July 2012

Positioning interoperabilityIntegration

practice

Standards - conformance

Interoperability practice

Open world

Bespoke solutions

Technical focus

Closed world

Common Architecture Practices

Multiple time pointsSingle time point

Close coupling Loose coupling

Rationalization FlexibilityEnterprise Architecture

Practices

Viewpoints Principles

Traceability PatternsMethod

Maturity

Governance

Federation

Integration points 1, 2, 3 …

Interoperability timeline

Architecture vs. Interoperability

• Interoperability at its most challenging is process of alignment of multiple architectures over time in the midst of multiple governance contexts

• Sound architecture is a precondition for sound interoperability

• Interoperability is to architecture as acceleration is to speed– Interoperability supports architecture in transit

Problem : Interoperability Capability

• Establish guidelines and best practices for – Measuring interoperability levels– Continuous improving of interoperability capability

• Targets– eHealth specification and systems– Organisations developing/participating in eHealth

solutions

Solution approach

• Leverage CMMI Framework• Use existing structuring approach – Tailor it for the purpose of interoperability– Use existing concepts and add new ones as

required– Ensure compliance

• Essentially a new CMMI constellation– In addition to Development, Service and

Acquisition constellations

CMMI – Continuous representation*

* See http://www.sei.cmu.edu/library/abstracts/reports/10tr033.cfm

CMMI – Staged representation

Categorising capability: approaches

Capability Levels Maturity Levels

CMMI Continuous CMMI Staged

Existing approaches

eHealth System(artifacts)

Organisation(processes)

Organisation(processes)

CL3

CL2

CL1

Organisation specific Predefined sets

ML1

ML2

ML5

ML3

ML4

Specific Goals

Process Area 2

L 1

L 2

L 3

L 4

(Walker and LCIM)

Specific Goals

Process Area 1

Concept relationship

Capability Level

Maturity Level

Specific GoalsArtefact (Work Product)

Equivalent staging

Process Areas

Attributeshas

qualify as1, …*

1, …*

Interoperability Goals

To be defined and agreed

Generic Goals

Characterised by

CL0 - IncompleteCL1 - PerformedCL2 - Managed

GG1:

CL3 - DefinedGG2:GG3:

Principles

determine

Practices realiseproduced by

identify

Approach

• Process areas are needed – group related specific interoperability goals

• Principles useful in identifying key process areas– Governance – Policy compliance– Service orientation– Conformity Assurance– Common Semantics– Technical interoeprability

Multiplicity

• Governance contexts• Service types• Technology options• Points in time

• Necessary vs sufficient conditions – Architecture vs interoperability

GovernanceProcess Area Specific Goals Specific Practices Work Products

Policy Compliance

SG1: Establish governance and management

SP1: Establish organisational policiesSP2: Implement processesSP3: Measure process effectiveness

WP1: Managed polices and processes

SG2: Govern change

SP4: Systematic approach to change

WP2: Effective adoption of change

SP5: Manage change within defined timeframes

Policy ComplianceProcess Area Specific Goals Specific Practices Work Products

Policy Compliance

SG1: Compliant to eHealth legislation and regulations

SP1: Review relevant regulations/legislationsSP2: Identify applicable policies

Demonstrated compliance in all systems(access control, authentication, federation support)

Collaboration and stakeholders

Process Area Specific Goals Specific Practices Work Products

Collaboration and stakeholders

SG1: Stakeholder engagement

Engagement and consultation in deriving eHealth specifications

Consensus in eHealth specifications (standards)

SG2: Universal participation

Participation and contribution to eHealth specifications

Interoperable eHealth systems

Service Orientation

Process Area Specific Goals Specific Practices Work Products

Service Orientation

SG1: Service Interface

Design by contract Service interface specification

SG2: Service Discoverability

Implement service catalogue

Service repository

SG3: Service Composition

Service orchestration

Process model

SG4: Service co-existence

Multiple service versions or options

Service registry

Conformity Assurance

Process Area Specific Goals Specific Practices Work Products

Conformity Assurance

SG1: Requirements management

Begin any project with clear requirements

Requirements documented (use cases, narrative, scenarios)

SG2: Verification and Validation

TBD TBD

SG3: Declaration of conformance

TBD TBD

SG4: Graduated conformance levels

Bronze, Silver, Gold status

TBD

Common Semantics

Process Area Specific Goals Specific Practices

Work Products

Common Semantics

SG1: Information semantics

Logical TBD

SG2: Service semantics

TBD

SG3: Process semantics

TBD TBD

SG4: Policy semantics

TBD TBD

SG5: Alternative semantic options

TBD TBD

Technical InteroperabilityProcess Area Specific Goals Specific Practices Work

Products

Technical interoperability

SG1: Machine transportable data

TBD TBD

SG2: Basic electronic data interchange

TBD

SG3: Electronic information exchange

TBD TBD

SG4: Semantic interoperability

TBD TBD

SG5: Business process integration

Next steps

• Agree Interoperability Process Areas– vs Architecture Process

• For each area agree on – Specific goals– Practices– Work products