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

Please consider this page as "work in progress", for discussion, before being introduced to eHOMB for decision.

The following image illustrates the proposed change proposal process for the update of Open NCP Technical specifications.

Proposed change proposal process

Scope of the change proposal process: Update of OpenNCP technical specifications.

Description of the process:

  1. The requester of the change fills the Change proposal template with the details of the change and submit the change proposal
    1. Anyone can send a CP to eDSI Solution Provider. This is typically done by directly updating the repository if you have access; otherwise send it an email to the functional mailbox (
  2. Unrealistic (e.g. "use dropbox") or CPs not in scope of eHealth DSI (e.g. bugs) can be blocked by the DSI Solution Provider

  3. The new CPs are considered by the eHDSI solution provider (EC) who analizes the CP and consults the OpenNCP Community
    1. If the proposed change concerns a software bug for instance, it will follow the usual process for software bugs (Jira)
    2. If CP is accepted it is given a CP #, assigned an editor, renamed to CP-eHealthDSI-xxx-00.doc and placed in Assigned. If CP is rejected it is moved to Rejected and submitter is informed of explanation for rejection. Likely reasons for rejection are: duplicate, merged, withdrawn or not enough information to understand the request. Rejected CPs can be resubmitted with more information for reconsideration

  4. eHDSI SP works with editor to draft the CP. Versions are kept in Assigned directory and numbered -00, -01, -02, etc. When CP is ready, latest version of CP is moved to Completed diretory and old versions are moved to old_versions
  5. DSI Solution Provider:

    1. makes directly decision in case of minor impact to eHealth DSI and the decision will be given for information to eHOMB. eHOMB can take the decision into discussion if necessary

    2. DSI Solution Provider declines CP and the decision will be given for information to eHOMB. eHOMB can take the decision into discussion if necessary.

    3. If CP has major impact DSI Solution Provider will make a proposal to eHOMB who will make the decision. Operational Management Board can consult Member State Expert Group according to the Governance Model. Any member of the eHOMB can also raise the decision to eHealth Network.

  6. Once approved by eHOMB or eHealth Network the specification becomes official eHealth DSI specification

Change proposal template

  • No labels


  1. The template is focused only on implementation. In fact, it is mentioned "Components or Configuration items to be changed".  What about specifications? 

    Having a mixed CP process for both software and specification is a bit tricky, and different from EXPAND and IHE. Enterprise Architectures like TOGAF usually refers them to ABB and SBB respectively. The reason is that they may need to have different paths towards sustainability, e.g., an ABB may need to have the change proposal as above, while a change in an SBB is more suited by means of other software tools like, e.g., gatekeeper, or JIRA.

  2. I agree about the principle that Solution Building Block and Architectural Building blocks may require different approaches, less about the conclusions (smile)

    A word based CP may be useful for amending word based specifications (and mainly when we deal with editorial changes) , less useful when we need to discuss wider aspect (I've for example in mind changes that can derive from the Openmed project) or when we need to deal with computable specs or other assets (e.g. terminologies) that however impact on the deployment.

    In that case we absolutely need more agile, effective and trackable solutions (closer to the software management world) rather than the word based CP (see for example the for the time being what is informally used for the ART DECOR based epSOS CDA specifcations issues

    Another important aspect to be considered is if we want to track the real maintenance lifecycle or only the phase where decisions have been already substantially taken and the formal approval part is managed. In the first case we need to carefully select the set of tools (not necessarly only one) in order to faciliate the collection of inputs, enable the tracking of each item, enable the collboration among the different actors involved and to avoid to burden people with unuseful documentation. On the contrary more tight appraoch have to be considered for the final approval phase.


    1. Giorgio, 

      I substantially agree on what you said. I always assumed a word-based CP to amend specifications. To change software, epics, stories, are more suitable. 

  3. Does any change in the code (bugs, improvements and new features) will be covered by this process?

    Lets think that a change proposal is not a functional issue, it is not a new functionality to be more clear. Lets say that we have the following example as a change request: "Configuration Manager update in order to use hibernate 4.x instead of Hibernate 3.x" Is this covered by this process? 

    What about also the proposal made for maven project refactoring? Is this also a change and will be covered by this process?