Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 35 Next »

Description of the list of eHealth infrastructure environments used for test and production. The description includes the intended users of this environment, the access to the environments and the integration to external systems in each of these environments. The intended audience is primary third-party providers to get a basic understanding of the use of these environments.

List of eHealth environments

The environment for KL Gateway is described here: KL Gateway environments

Actors in the eHealth Environments

A breakdown of the different actors and their roles within the eHealth environments:

Development Team

  • Infrastructure Development Teams: Responsible for developing the platform and eHealth services.

  • Telemedicine Solution Provider: Engaged in the development of Telemedicine Solutions.

Test Users: Users used for testing Telemedicine Solutions and the eHealth Infrastructure. Test users can be used by:

  • Telemedicine Solution Providers: Tests the Telemedicine Solution integration to the eHealth infrastructure primarily in the External Test Environment (EXTTEST).

  • Customers: Tests the eHealth infrastructure primarily in the External Test Environment (EXTTEST).

  • Infrastructure Provider: Tests the eHealth infrastructure primarily in the Internal Test Environment (INTTEST).

End Users: Individuals who currently use or intend to use Telemedicine Solutions for their healthcare needs.

Operation Teams

  • Infrastructure Operations: In charge of operating the eHealth infrastructure, specifically deploying to PRODUCTION.

  • Telemedicine Solution Provider: Responsible for operating the Telemedicine Solution and deploying Telemedicine Solutions to PRODUCTION.

The diagram below visually depicts the various actors end-users, solution developers, and operations, utilizing and accessing the eHealth infrastructure environments.

environment-actors.png

Accessing the environments

The end user and test user login to the eHealth Infrastructure involves the following external systems:

  1. Nemlogin: Used for the federated login of Citizens.

  2. SEB: Utilized for federated login purposes by Employees in regions and municipalities.

  3. KOMBIT STS: Employed for federated login by Employees in municipalities.

The process for logging in follows a specific flow, which is detailed across the following pages: 

eHealth environments connection to SEB, NemLogin and KOMBIT access management (Danish: adgangsstyring)

The following provides an overview of how eHealth environments are connected to both testing and production systems concerning the login process, highlighting the connections between these environments and the respective systems utilized for authentication purposes.

eHealth Environment Type

eHealth Environment

NemLogin Environment

KOMBIT

Adgangsstyring

SEB

Internal test environment

INTTEST

test

test-nemlog-in.dk

External test

adgangsstyring.eksterntest-stoettesystemerne.dk

t-seb

http://t-seb.dkseb.dk

External test environment

EXTTEST

test

test-nemlog-in.dk

External test

adgangsstyring.eksterntest-stoettesystemerne.dk

t-seb

http://t-seb.dkseb.dk

Vendor environment

DEVENVCGI

test

test-nemlog-in.dk

External test

adgangsstyring.eksterntest-stoettesystemerne.dk

t-seb

http://t-seb.dkseb.dk

Education environment

TEST002

test

test-nemlog-in.dk

External test

adgangsstyring.eksterntest-stoettesystemerne.dk

t-seb

http://t-seb.dkseb.dk

Pre-production environment

PREPROD

test

test-nemlog-in.dk

External test

adgangsstyring.eksterntest-stoettesystemerne.dk

t-seb

http://t-seb.dkseb.dk

Production environment

PROD

prod

login.nemlog-in.dk

Prod

adgangsstyring.stoettesystemerne.dk

Prod

http://seb.dkseb.dk

eHealth Environments connection to FK Organisation

The mapping provided below serves as a guiding reference for eHealth environments connection to the FK Organisation service.

eHealth Environment Type

eHealth Environment

KOMBIT Environment

FK Organisation

Internal test environment

INTTEST

external test

External test environment

EXTTEST

external test

Vendor environment

DEVENVCGI

external test

Education environment

TEST002

external test

Pre-production environment

PREPROD

external test

Production environment

PROD

prod

eHealth Environments connection to NSP Environments

The mapping provided below serves as a guiding reference for determining the suitable types of environments for use in conjunction with different NSP (National Service ) environments.

NSP and KIH Test Environments

NSP has several test environments. These are described here:

From https://www.nspop.dk/pages/viewpage.action?pageId=4839407 cNSP is used for municipalities and dNSP for regions. This reference is used in the following

Environment

Regions Endpoint

Municipalities Endpoint

DROS Paths

DDS Paths

DRS Path

KIH Endpoint

TEST1

https://test1.ekstern-test.nspop.dk:8443/

https://test1-cnsp.ekstern-test.nspop.dk:8443/

/dros/iti41/dros/iti57

/ddsregistry
/ddsregistry/metadataupdate
/ddsrepository

/drs/proxy

Not available in test 1

TEST2

https://test2.ekstern-test.nspop.dk:8443/

https://test2-cnsp.ekstern-test.nspop.dk:8443/

/dros/iti41/dros/iti57

/ddsregistry
/ddsregistry/metadataupdate
/ddsrepository

/drs/proxy

http://kih.test.xdsrepositoryb.medcom.dk:8020/axis2/services/xdsrepositoryb

PRODTEST

https://prodtest.ekstern-test.nspop.dk:8443/

https://prodtest-cnsp.ekstern-test.nspop.dk:8443/

/dros/iti41/dros/iti57

/ddsregistry
/ddsregistry/metadataupdate
/ddsrepository

/drs/proxy

http://kihrepository-test.npi.nsi.dsdn.dk:8020/axis2/services/xdsrepository

UDD

https://dnsp-prodtest.nsp.dsdn.dk:8443/

https://prodtest-cnsp.ekstern-test.nspop.dk:8443/

/dros/iti41/dros/iti57

/ddsregistry
/ddsregistry/metadataupdate
/ddsrepository

/drs/proxy

http://kihrepository-udd.npi.nsi.dsdn.dk:8020/axis2/services/xdsrepositoryb

Connections from eHealth Environments

The mapping is intended as a reference to assist in understanding which types of environments correspond or align best with the respective NSP environment.

eHealth Environment

INTTEST

DEVENVCGI

EXTTEST

TEST002

PREPROD

PROD

Environment Type / External System (down)

Internal test environment

Vendor development environment

External test environment

Education environment

Pre-production environment

Production environment

Appointment Repository
(ITI-41)

Municipality
DROS
TEST1

Regional
DRS
TEST1

Regional
DRS
TEST2

Regional
DRS
TEST1

Regional
DRS
PRODTEST

Municipality
DRS
PROD

Document Sharing Service (Da: Dokumentdelingsservice, DDS)

(ITI-18, ITI-43)

Municipality
DDS
TEST1

Municipality
DDS
TEST1

Municipality
DDS
TEST2

Municipality
DDS
TEST1

Municipality
DDS
PRODTEST

Municipality
DDS
PROD

Metadata Update
(ITI-57)

Municipality
DROS
TEST1

Municipality
DDS
TEST1

Municipality
DDS
TEST2

Municipality
DDS
TEST1

Municipality
DDS
PRODTEST

Municipality
DDS
PROD

KIH Repository (ITI-41)

KIH
TEST

KIH
TEST

KIH
TEST

KIH
TEST

KIH
TEST

Not configured

Note, the following differences:

  1. INTTEST uses DROS for ITI-41 and ITI-57, but not for ITI-18/ITI-43 (warning).

  2. PREPROD used KIH TEST2, and not KIH PRODTEST. (warning)

  3. DEVENVCGI, EXTTEST, TEST002, PREPROD, uses Regional DRS, not Municipality DRS (warning)

  4. INTTEST, DEVENVCGI and TEST002 uses TEST1, and not TEST2 (warning)

Component and Data Lifecycle in Environments

The diagram below provides a visual overview of the lifecycle of components and data within the eHealth infrastructure environments. It outlines the progression of components as they are promoted through different environments and depicts the mechanisms for exporting and importing data across these environments.

Key Observations:

  • Component Promotion: The diagram illustrates the progression of components through various environments, showcasing how they are promoted across different stages within the eHealth infrastructure.

  • Data Export/Import Process: It demonstrates the flow of data, highlighting the export and import procedures between different environments. Packages (such as questionnaires, activity definitions, and plan definitions) follow a distinct flow. These packages can be developed or created in the EXTTEST environment, exported from there, and subsequently imported into the PRODUCTION environment, and vice versa.

This unique flow for Packages signifies their flexibility in being developed or initiated in one environment and seamlessly transferred to another, facilitating their movement between testing and production environments.

environments-lifecycle.png
  • No labels