Download - Interoperability Capability Guidelines
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