HSSP 1

X Paradigm layered architecture

Starting Point

S. Lotti

HL7 Italia Chair

Enterprise Architect atInvitalia – Government Agency forInward Investment Promotion and Enterprise Development

Draft 02

27/06/2012

HSSP 2

Objective of Layered Architecture (from wiki)

Initial ideas are: Map artefacts into the SAIF framework as was done in Practical Guide

Part II with an eye to separating platform independent elements from platform specific ones.

A decision tree through the stack will be graphed. The output of task #1 may or may not be appropriate as a starting point. Particular paths of choices through the stack may represent particular existing artifact choices (example: IHE XDS profile). Again the purpose is to find the common elements vs. differences and provide raw material for generating a deployment that enables disparate systems to interoperate.

27/06/2012

SAIF - Interoperability Specification Matrix

27/06/2012 HSSP 3

X Paradigm specs in SAIF ISM

HSSP 4

Implementable perspective

HSSP WS* and semantic signifiers specs

Implementable perspective IHE Profiles

Implementable perspective

HSSP RESTful and semantic signifiers specs

Implementable perspective FIHR (?)

27/06/2012

Common part (Platform indipendent)

Platform Specific part

?

Conformance assertion analysis

?

Mixed implementation environments are also theoretically possible

SAIF – ISM and Xparadigm Artifacts

Enterprise dimension

Information dimension

Computational dimension

Engineering

dimension

Technical dimension

Conceptual perspective

- Use case (narrative)

- Business Vocabulary (SBVR DOM in UML derived from existing spec, DAMs)

- BPMN2 Collaboration (from use cases)- Capabilities (from SFMs and other spec)

N.A. Technology requirements

- EHR-S function - EHR-S conformance criteria(as SBVR Rules ?)- Other specific SBVR rules

- EHR-S conformance criteria(as SBVR Rules ?)- Other specific SBVR rules

Logical perspective

Conformance stantement

(SBVR rules)(TBD)

- Logical models of semantic signifiers, (RMIMs, UML Models)- MDMI models

BPMN choreographyService Architecture and contracts (SoaML from STMs PIM)Resulting Service Inventory (task, entity, utility, etc.)

N.A. Technology (and security) model

Implementable perspective

Conformance stantement

(SBVR rules)(TBD)

- Message spec,- Implementation Guide

- OMG STM PSM (WS* / REST)- IHE profiles- FIHR (?)

N.A. Selected Technology an Security standards (e.g. soap 1.2, ws- security etc.)

HSSP 527/06/2012

Logical progession (partial)

HSSP

Bottom upWith existingspecs27/06/2012

e.g. Service architecture design

HSSP 7

- Use case (narrative)

- Business Vocabulary (SBVR)

- BPMN2 Collaboration

- BPMN2 Choreograpy

- Layered Service Inventory

- Service Architecture (SoaML from STMs PIM)

Process Services

Entity services

Utility services27/06/2012

HSSP 8

- Business Vocabulary (SBVR)

The Vocabulary will be designed with SBVR (with a simple UML profile)

SBVR will be used for role/actor modeling and also for conceptual information modeling

27/06/2012

HSSP 9

- Business Vocabulary (SBVR)

- BPMN2 Collaboration

The processes will be derived from narrative use cases and vocabulary (participants)

Narrative Use Case

27/06/2012

27/06/2012 HSSP 10

- BPMN2 Collaboration

- Service Architecture

From BPMN collaborations will be identified the operations and mapped on the service architecture and contracts (from SFMs/STMs PIM)

Contract

Service architecture

- Service Contracts

Retro-modeling from existing standard specs is necessary

&

23/08/2010 HSSP 11

- BPMN2 Collaboration

- BPMN2 Choreograpy

From BPMN collaborations will be defined the choreography or the orchestration(s) (if possible or useful)

Resulting Service Inventory

27/06/2012 HSSP

Layered Service InventoryParadigm X

RLUS

CDSS

IXS CTS2

HCSPDIR

HSSP Services(logical dimension PIM)

OMG Standards

IHE Profile

Implementabledimension (PSMs)

Inform

…

use