Page tree
Skip to end of metadata
Go to start of metadata

Goal of the current document


The goal of the current page is to present the eHDSI Service Catalogue, the eHDSI Delivery process (Artefacts releases) and Overall Deployment Plans, in order to:


  • Provide awareness to eHDSI governance bodies, as well as work as a tool to monitor the progress of eHDSI deployment
  • Communicate eHDSI Solution Provider plans and commitment towards artefacts delivery
  • Manage eHDSI Deploying Countries expectations on artefacts releases
  • Communicate and guide eHDSI Deploying Countries intentions regarding NCPeH deployment plans
  • Identify the operational activities (to be performed centrally) necessary to support Service Operation.


The current document contains three main sections:
  1. eHDSI Service Catalogue: list of services provided in eHDSI Core Services Platform, their category, type and description.
  2. eHDSI Service Delivery Plan:
    1. High-level Release Lifecycle of eHDSI Services and Artefacts
    2. eHDSI Detailed Release Lifecycle (2020 Planning)
      1. Design and Development: The planned releases for the eHDSI Artefacts to be used by the eHDSI NCPeHs while deploying and running routine operations. 
      2. Operations Management: The main Service Operation related activities.
  3. eHDSI Overall Deployment Plans: eHDSI Generic Services (a.k.a. NCPeH or National services) deployment.
    1. Overall NCPeH Deployment Approach

    2. eHDSI NCPeH Services Deployment Plan

Table of Contents

Note

Please check the previous versions of the document and the changes performed in the currently released version in the Document Control Information section at the end of this page.

Definitions


eHDSI Core Services: digital services or artefacts provided centrally by eHDSI Solution Provider to enable the Generic Services (countries NCPeH) deployment and operation.

eHDSI Solution Provider: role performed by DG SANT A4 Unit.

eHDSI Service Catalogue: the list of services included in eHDSI Core Services.

eHDSI Service Delivery: plan (content and time) committed by eHDSI Solution Provider to release digital services updates.

eHDSI Overall Deployment: set of time plans describing the releases, preparatory activities (e.g. test, audit), procedural steps, go live milestones and waves for eHDSI Deploying Countries.

eHDSI Deploying Country: National entity responsible for the deployment of the NCPeH.

eHDSI Service/Artefacts Usage Policy: used to classify the required or optional use of services  and artefacts:

  • Normative: absolute requirement that must be followed.
  • Non-normative: suggestions or recommendations, guidelines.

eHDSI Service Catalogue


The current section describes the 12 eHDSI services, their purpose and classification.

The eHDSI services were classified in two categories, in order to better differentiate between the analysis/ documentation services and those which imply IT/ software development services, as follows:

  • eHDSI Service Categories:
    1. Analysis/ Documentation services: Requirements, Specifications, Frameworks, Guidelines
    2. IT/ Software Development services: NCPeH Reference Implementation (OpenNCP), eHDSI Central/Core Services (Configuration, Central Terminology).
REQUIREMENTSSPECIFICATIONSFRAMEWORKSGUIDELINES
  • Adopted by NCPeHs
  • Normative (mandatory) for NCPeHs
  • Applicable to specific Wave/s
  • Adopted by NCPeHs
  • Normative (mandatory) for NCPeHs
  • Applicable to specific Wave/s
  • Adopted by NCPeHs
  • Normative (mandatory) for NCPeHs
  • Immediate applicability for all Waves
  • Could be further detailed into procedures
  • Recommended (optional) for NCPeHs
  • Do not require adoption

eHDSI Service Types are used to classify the nature of each  service, as follows:

  • Requirements: business needs and solution conditions and capabilities;
  • Specifications: architectural and logical design instructions;
  • Frameworks: policies, methodologies and procedures;
  • Guidelines: best practices and recommendations;
  • IT Service: provided as Software as a Service;
  • Reference implementation: software to be used by eHDSI Generic Services.
  • Collaborative: online tools, mainly for collaboration purposes;
  • Communication: online content, mainly for communication purposes.
#

SERVICE

ARTEFACT

PURPOSE

CATEGORY

TYPE

USAGE POLICY

DESCRIPTION

1

REQUIREMENTS

eHDSI Requirements Catalogue

Provide business and solution requirements, elicited from Regulation, Directives, Implementing acts, policies and guidelines,

Analysis/ Documentation

Requirements

Normative

In order to be able to accurately point and trace back requirements from specifications, implementation, test and audit, there is the need for having the following instruments in place:

  • eHDSI Requirements Management approach
  • eHDSI Requirements Catalogue

More information at: eHDSI Requirements

2

Interoperability SPECIFICATIONS

eHDSI Interoperability Specifications documents

Provide specifications  that enable the building of eHDSI Core and Generic services

Analysis/

Documentation

Specifications

Normative

Fundamental design information that map requirements into clear indications on what is to be built.

More information at: eHDSI Interoperability Specifications

3

TEST services

  • eHDSI Test Framework
  • eHDSI Test Tools

Enable Generic Services conformance testing

Analysis/

Documentation

Framework

Normative

In order to start and continue routine operations, an NCPeH must demonstrate its conformance with interoperability specification.

The eHDSI Test Framework describes policies, methodologies and procedures for an NCPeH demonstrate the necessary conformance.

More information at: eHDSI Test Framework and Tools

4

AUDIT services

  • eHDSI Audit Framework
  • eHDSI Readiness Criteria Checklist

Enable Generic Services Requirements fulfilment assessment

Analysis/ 

Documentation

Framework

Normative

In order to start and continue routine operations, an NCPeH must demonstrate the fulfilment of all requirements established in eHDSI.

The eHDSI Audit Framework describes policies, methodologies and procedures for an NCPeH demonstrate the fulfilment of eHDSI Requirements.

More information at:  eHDSI Audit Framework and tools

5

MONITORING services

  • eHDSI Monitoring Framework
  • eHDSI Monitoring Dashboard

Gather evidence about core and generic services performance

Analysis/ Documentation

Framework

Normative

Performance monitoring is crucial to understand effective usage of the services and detect defects. In order to achieve performance monitoring it is needed to have in place mechanisms able to collect and report specific performance data. These services (that may come as Specifications, Software or Services) should ease the burden of MS on reporting tasks.

More information at: eHDSI Monitoring Framework

6

OPERATIONS services

  • Central Service Desk
  • eHDSI Operations Framework

Establish the eHDSI Services Operation policies and procedures

Analysis/

Documentation

Framework

Normative

  • Describe the eHDSI Solution Provider service provision principles and procedures.
  • Provide guidance to the persons appointed to manage the NCPeH.
  • Support countries in gaining knowledge on eHDSI Operations principles.
  • Address and Resolve NCPeHs issues by gathering and tracking the End Users requests for assistance or support.

More information at: eHDSI Operations Framework

7

CONFIGURATION services

  • Service Metadata Publisher and Service Metadata Locator (SMP/SML), implemented under the eDelivery Building Blocks

Enable NCPeH Technical Gateways automated configuration management

IT/ Software Development services

IT Service

Normative

In order to set up and keep functional the NCPeH TG node network, there is the need for Dynamic Service Location and Capability Lookup services that allow the NCPeH to discover each other and establish trusted communication.

More information at: eHDSI Central Configuration Services

8

TERMINOLOGY services

  • Central Terminology Services (CTS) - Server and Portal

Enable MVC distribution and support MTC management

IT/ Software Development services

IT Service

Normative

In order to achieve semantic interoperability there is the need for a common vocabulary (Master ValueSet Catalogue – English by default) to describe the clinical data. The MVC should be presented to the End-Users in the MS desired language and code systems. For that, MS should be able to translate, map and transcode (creating the Master Translation/Transcoding Catalogue MTC) according to their national policies.

More information at: Central Terminology Services [training environment]

9

NCPeH TECHNICAL GATEWAY Reference Implementation  (a.k.a. OpenNCP)

  • OpenNCP

Ease MS effort by providing a jointly build NCPeH TG implementation

IT/ Software Development services

Reference Implementation

Non-Normative

The NCPeH technical gateway is one of the core nodes in the Service Network. Since each MS need to deploy an NCPeH based on the same specifications, it was agreed between EC and MS that a reference implementation should be jointly developed, so that knowledge shared and effort distributed among the participating MS.

More information at:  eHDSI Technical/OpenNCP Community

10

COMMUNICATION services

Multi-stakeholder dissemination

IT/ Software Development services

Web Page

Non-Normative

Web site publicly available to any stakeholder to promote eHDSI official dissemination content (e.g. new, discover, how it works, services, communities).

More information at:  eHDSI Communication Services

11

COLLABORATION services

CEF Digital Platform:

  • Confluence spaces (e.g., eHDSI Operations, Semantic Community, Technical Community, MS Expert Community)
  • JIRA projects (e.g., eHDSI Operations, Semantic, Technical)

Webex: eHDSI Operations, Semantic, Technical virtual meeting rooms

Streamline stakeholders interaction and joint work

IT/ Software Development services

Platform

Non-Normative

In order to boost collaborative work, the toolkit provide, at least, the following tools:

  • Knowledge Sharing through the use of wiki pages (e.g. documentation, meeting minutes, discussions, files management) and a powerful search engine to assist find content.
  • Work Orchestration by providing mechanisms to describe, assign and monitor work tasks to be performed.Teleconferencing facilitating the organisation of remote meetings by providing audio, video and screen sharing.

More information at:  eHDSI Collaboration Services

12

GUIDELINES services

eHDSI Guidelines

Provide implementation guidance or best practices examples

Analysis/

Documentation

Guidelines

Non-Normative

eHDSI Guidelines are intended to provide deploying countries with a minimum set of common rules or directions, but are not normative, i.e. eHDSI deploying countries may choose to implement their own product or follow their own rules or protocols.

A non-exhaustive list of eHDSI Guidelines comprises:

  • eHDSI Glossary
  • CDA Display Tool Guidelines
  • Detailed Guidance for communicating and representing exceptional situations (the "known absence" and "no information" situations)
  • Guidelines for the creation of the Master Translation/Transcoding Catalogue (MTC)

More information at:  eHDSI Guidelines services


eHDSI Service Delivery - Artefacts Releases


eHDSI High-level Release Lifecycle


According to the eHDSI Solution Provider mission and commitment, the eHDSI core services release should occur in a timely manner, promoting sustainability and favoring the adoption by the eHDSI deploying countries (countries participating in eHDSI). With that vision in mind, the eHDSI Delivery Plan was designed to describe when the eHDSI services are planned to be released and expected to be used in routine operation.

The release cycle foresees a 12 (twelve) month time window between release and entering operation, in order to favour the needed artefact maturation and localisation by eHDSI deploying countries (NCPeHs).

  • Artefacts are made available usually by Quarter 2 (each year) as Release Candidate.
  • Artefacts are matured through an open feedback cycle, with the participation of all the interested stakeholders, usually during Quarter 2 (each year).
  • Operation Ready artefacts are made available usually by the end of Quarter 2 (each year), in order to be used in PREPARATORY, TEST and AUDIT activities towards Go Live (usually 12 months from July to June next year).
  • The months of the year mentioned in the above descriptions should be considered as default time line. Deviations to it may be admissible after endorsement by eHOMB and eHMSEG.

After the OPERATION READY release (usually by Quarter 2 each year), the following procedures must be rigorously followed, for sake of quality and readiness of NCPeH service deployment:

  • The artefacts shall only receive fixes (e.g. solve any deadlock specification, fix software related bugs).
  • Improvements and new features should be placed into the artefacts backlog for the following wave.

Artefacts COME INTO FORCE and APPLICABILITY

Operation Ready Artefacts come into force after the eHMSEG adoption (usually June-July), however they are applicable from 1 July of the following year. From that time, all eHDSI Countries (in operation or entering operation) MUST CONFORM with them. If needed, Conformance and Functional test activities will be set up (i.e. Upgrade-PPT), to ensure the countries fulfill new requirements or specifications.

An exception from this rule are the eHDSI Frameworks, which are applicable immediately after eHMSEG adoption.

Depending on their category, the eHDSI Services and Artefacts evolve in several cycles (stages), as described in the below diagram. 

  • Analysis/ Documentation services: These services consists of Requirements, Specifications and Frameworks.
    • The flow of releasing this type of artefacts is: Release Candidate (artefacts open for NCPeHs/ stakeholders review) - Operation Ready Release (improved artefacts with review remarks integrated, ready for eHMSEG adoption and routine operation) - Artefacts come into force (once the artefacts were adopted by eHMSEG) - Artefacts applicability (1 year after eHMSEG adoption or immediately, in case of Frameworks).
    • Changes that impact an eHDSI normative artefact (e.g., Specifications) are managed using the eHDSI specific Change Management procedure.
  • IT/ Software Development services: They mainly include the eHDSI Central Services (OpenNCP reference implementation, Configuration and Terminology Services, eHDSI Validators - used for performing the Conformance tests).
    • The flow of releasing this type of artefacts is: Release Candidate (version of the artefacts ready to be integrated/ deployed by NCPeHs for testing purposes) - Stable Release (improved version of the artefacts ready to be integrated/ deployed by NCPeHs for testing purposes) - Operation Ready Release (version of the artefacts ready to be used in routine operations).
    • The Stable Release of the OpenNCP Reference implementation (NCPeH Technical Gateway) must be released at least one month in advance of the start of the eHDSI Test events, as a freezed version. After the eHDSI Test events, only emergency changes must be performed (unplanned changes, such as security issues or blocking issues affecting the routine operations).

    • In routine operations (Production environment), all countries must use the same major release of OpenNCP Reference implementation. That way we ensure that the connectivity and functionality between NCPeHs is not affected, the reason being is that all MS are on the same major version of the Open NCP Reference implementation. At technical level, compatibility is ensured between the ‘’minor versions’’ (1.0, 1.1…), but not between the ‘’major versions’’ (1.0, 2.0…).

    • The eHDSI Validators (used for testing purposes) must be ready at least two weeks in advance of the start of the eHDSI Test events.
  • Operations services: They consists of NCPeHs continuous improvement process (Testing activities) used to improve and evolve the eHDSI artefacts. There are two main types of test events performed between NCPeHs (Acceptance and Production environment testing). More details on all eHDSI Test activities are available in the eHDSI Test Framework.

High-level Release Lifecycle of eHDSI  Services and Artefacts


eHDSI Detailed Release Lifecycle (2020 Planning)


The following table describes:

  • Design and Development: The planned releases for the eHDSI Artefacts to be used by the eHDSI NCPeHs while deploying and running routine operations. These artefacts are prepared by the eHDSI Solution Provider team with the contributions of the eHDSI Communities and partners with commitments with the eHDSI. The artefact release is the culmination of a 12-month lifecycle that brings together maintenance, change and innovation efforts.
  • Operations Management: The main Service Operation related activities. They differ from the delivery activities described in the previous chapter since they are not related with Development of Artefacts but focused on making possible start Routine Operations, as well as, establish business continuity and continuous improvement. The Operations Management activities are performed by eHDSI Central Services (eHDSI Owner and eHDSI Solution Provider).
MONTH

JANUARY

FEBRUARY

MARCH

APRIL

MAY

JUNE

JULY

AUGUST

SEPTEMBER

OCTOBER

NOVEMBER

DECEMBER

MILESTONE

 

 

 


 

ANALYSIS/ DOCUMENTATION

(Requirements, Specifications, Frameworks, Guidelines)

WAVE 3 CDA IG - STABLE RELEASE

WAVE 4 RELEASE CANDIDATE ARTEFACTS 
(by 30/04)
NCPeHs REVIEW of 
WAVE 4 Release Candidate Artefacts
WAVE 4 OPERATION READY RELEASE
(ready for eHMSEG adoption on 05/06)



Submission of Change Proposals for next Release
(by 30/09)

WAVE 4 eHDSI (CDA) Validators - STABLE RELEASE

(by 02/10)


WAVE 3 eHDSI (CDA) Validators - STABLE RELEASE

WAVE 3 CDA IG - OPERATION READY RELEASE (hot fix)

(by 15/04)

NCPeHs UPGRADE to WAVE 3 Operation Ready Artefacts

(on 07/09)



Assessment of Change Proposals for next Release

IT/ SOFTWARE DEVELOPMENT

(OpenNCP, SMP/SML, CTS)

WAVE 3 OpenNCP (and CDA Display Tool) - STABLE RELEASE
(for Formal Test event)



WAVE 3 OpenNCP (and CDA Display Tool) - OPERATION READY RELEASE (hot fix)

(by 29/05)


WAVE 4 OpenNCP (and CDA Display Tool)
RELEASE CANDIDATE
(planned for 01/07)

WAVE 4 OpenNCP (and CDA Display Tool) - STABLE RELEASE
(by 18/09)


CTS 2.0 RELEASE CANDIDATE

(tbc)




WAVE 4 eHDSI (CDA) Validators - STABLE RELEASE

(by 29/05)






WAVE 3 OpenNCP SUPPORTWAVE 3 OpenNCP MAINTENANCE RELEASE + SUPPORT
WAVE 2 OpenNCP MAINTENANCE RELEASE + SUPPORT
CTS1.0 MAINTENANCE + SUPPORT

OPERATIONS
(Main activities and Events)

NCPeHs Testing of WAVE 3 OpenNCP Stable ReleaseWAVE 3 FORMAL TEST EVENT
(17/02 - 27/03)

FORMAL TEST REPORTS


NCPeHs Testing of WAVE 4 OpenNCP Release Candidate

eHDSI BOOTCAMPWAVE 4 PREPARATORY TEST EVENT
(19/10 - 20/11)
PREPARATORY TEST REPORTS
(by 15/12)
Verification of Open Findings and Production environment testing
WAVE 3 and WAVE 4 Pre-assessment/ Consultancy Visits
WAVE 3 AUDITS

Overall NCPeH Deployment Approach


The rationale behind the eHDSI Overall Deployment plan is the country service deployment intentions combined with the eHDSI Solution Provider delivery capacity and the lessons learnt from Wave 1 (2018) arrangements to GoLive.

The original plan foreseen that eHDSI Deploying countries would GoLive (start routine operations) in a Once a year approach (all Countries of a specific wave at the same moment in time) and that was supposed to happen in February each year.

During 2018, for different reasons (e.g. new requirements, audit implementation, countries reduced readiness) the approach needed to be revised.

Based on the lessons learnt, the GoLive approach changed from a Once a year to FirstReady-FirstGoLive. Meaning that, as soon as a country demonstrates its readiness to start routine operations, the country should apply for it and a decision (authorization to GoLive) will be provided as soon as possible by the responsible governance body (eHealth Network). The NCPeHs Go-live process follows the eHDSI Go-live procedures adopted by eHealth Network.

FirstReady-FirstGoLive approach in practice results in a period between June and December where eHDSI Deploying countries can obtain authorization to GoLive with first services or new services.


eHDSI NCPeH Services Deployment Plan


The below table is updated for the NCPeHs which are already in routine operations. For the rest of the NCPeHs, the date is indicative, subject to be updated in the next release of the eHDSI Service Catalogue, Delivery and Overall Deployment Plans.

  • Each NCPeHs is presented on the second column, in the order of starting (or planning to start) routine operations with their first eHDSI service: Patient Summary (PS) or ePrescription (eP), as Country of affiliation (PS A or eP A) or as Country of Treatment (PS B or eP B).
  • Each NCPeHs is presented in correspondence with their first go-live partner NCPeH (on the second row).

Years2019 - 2020202120222023
#

NCPeH/ First  Go-live Partner NCPeH

Finland

Estonia

Czech Republic

Luxembourg

Malta

Croatia


Portugal

Cyprus

Greece

SwedenIrelandFrance

Poland

SpainHungaryBelgiumNetherlands

Italy

Slovenia

Lithuania

GermanyAustria
1

FINLAND


eP A

eP B

 





















2

ESTONIA

eP B

eP A



 




PS APS B












3

CZECH REPUBLIC

 



PS A

PS B



eP A

eP B












4

LUXEMBOURG


 

PS B


PS A

eP A













5

PORTUGAL




 

PS B 

PS A

 

eP A
eP B

















6

CROATIA

eP B

eP A

 

PS B

PS A

 
















7

MALTA




PS A 

 



PS B
















8

CYPRUS









PS A

PS BeP AeP B











9

GREECE








PS A


PS BeP AeP B











10

SWEDEN








eP AeP B












11IRELAND






PS AeP A












12FRANCE






PS B





PS A






13POLAND






eP AeP B












14SPAIN






PS APS B




eP AeP B





15HUNGARY














PS APS BeP AeP B


16BELGIUM













PS B





PS A
17NETHERLANDS













PS B






18ITALY













PS APS BeP A
eP B


19SLOVENIA













PS APS BeP AeP B



20LITHUANIA













eP AeP B





21GERMANY













PS APS B





22

AUSTRIA















PS A

PS B

eP A

eP B




Annex 1 - Context Information


Solution Provider perspective

In order to fulfil its main function, the Solution Provider:

  • (…) is accountable for the delivery of the CEF Building Block, including the design and implementation of solutions in the form of Specifications, Software and Services. [1]

  • (…)To build the eHealth DSI specific software and services; advise and assist Member States on setting up the generic services, and ensure that they are linked to the core services (technical and semantic interoperability). eHealth DSI Solution Provider is responsible for the provision of core services. (…)[2]

The eHDSI Solution Provider WORK SCOPE (Service blueprint) is the following ecosystem:

eHDSI Service Catalogue (Solution Provider perspective)

---

[1] CEF Governance

[2] eHN - Governance model for the eHDSI, Adopted by consensus by the eHN, Brussels, 23 November 2015


Users perspective

From the User point of view, the relation between the services is important but above all the concerning questions relate to:

  • What should/can be used to achieve a certain purpose?

  • What services are available for each stage of deployment (just started, preparations, implementation or operation)?

  • Who can I ask for assistance or support to solve an issue or to escalate a situation I cannot solve in an isolated way?

The following table and figure attempt to depict this perspective following closely the CEF nomenclature.

[1]SERVICE TYPE 

DESCRIPTION[2]

CORE

deliver the basic outcomes and objectives of the CEF DSI.

i.e. the definition, maintenance and sponsorship of European standards, guidelines  and technical specifications.

ENABLING

deliver the core services and the outcomes/objectives that these core services support.

i.e.  technical and organizational services to enable the implementation of the Standards and Technical Specifications as defined by the core services.

  • e.g. Software (development, maintenance and evolution of highly modular and reusable pieces of software);
  • e.g. Operations Services (services to support the day-to-day operation of the core services):

ENHANCING

added on top of the core services to create additional value for the users and promote the uptake.

  • e.g. On-Boarding services (to create awareness on the DSI services amongst potential users and help these potential users to evaluate the added value they can receive through its use);
  • e.g. Community Management Services (governance structures to capture user needs and monitor user experience in order to maintain and enhance the value offered to new and existing users through the DSI Services):

 

eHDSI Service Catalogue (Users' perspective)

---

[1] Source: CEF Service Offering link

[2] Adaptation from CEF Service Offering focusing on the DSI services and not so much on the generic CEF BB


Document Control Information


Note

This Confluence page deprecates the Word version of the eHDSI Service Catalogue, Delivery and Overall Deployment Plans document. Word and PDF versions of the document will be provided as export of the content from this Confluence page.

The previous versions of the eHDSI Service Catalogue, Delivery and Overall Deployment Plans document can be found in the below History table.

VERSIONDATEDOCUMENT AND SUMMARY OF CHANGESSTATUS/ APPLICABLE TO WAVE
4.1.0

 

Wave 4 Operation Ready

  • Integrated the review remarks from eHDSI Owner, additional details given to the eHDSI High-level Release Lifecycle diagram.
  • Integrated the rules for releasing the OpenNCP and eHDSI Validators before the eHDSI Test events (as proposed by eHDSI OpenNCP Technical Work Group and agreed by eHMSEG).
All Waves
4.0.0

 

Wave 4 Release Candidate to be reviewed by eHDSI stakeholders.

Summary of changes (highlighted in blue):

  1. Renamed the ''Assumption'' section into ''Definitions''.
  2. Introduced and described the ''Service Category''.
  3. Differentiated between the Services description and the Artefacts description.
  4. Integrated the Central Service Desk into the Operations services.
  5. Moved the following sections into Annexes:
    1. 2.2. Solution Provider perspective - Annex 1
    2. 2.3. Users perspective - Annex 1
  6. Introduced/updated the following sections:
    1. eHDSI Service Delivery - Artefacts Releases
    2. eHDSI High-level Release Lifecycle
    3. eHDSI Detailed Release Lifecycle (2020)
  7. Removed the ''Glossary'' section, as all the terms were already integrated into the eHDSI Glossary.
  8. Removed the following sections and figures as outdated, and replaced them with updated sections/diagrams:  
    1. 3.2. Artefact Releases (Design and Development) - Table of activities
    2. 4. OPERATIONS MANAGEMENT - Table of activities

    3. Figure 3 – eHealth DSI Release Plan
    4. Figure 4 – eHDSI Artefacts COME INTO FORCE and APPLICABILITY
    5. Figure 5 - Wave Deployment plan
All Waves
3.0.0

Not released
2.9

 

Wave 3
2.8

 

eHDSI_ServiceCatalogue-ServiceDelivery-OveralDeployment-Plan_V2.8_20180621.pdfWave 2
2.4

 

Wave 1
1.2

 

eHDSI_Ps-eP_ServiceBlueprint_V1.2_20161007.pdfn/a
  • No labels

1 Comment

  1. FI eP-B is now live with EE eP-A since 1.6.2020. This should be updated in the table.