{"id":18985612,"url":"https://github.com/gematik/tiger-integration-ncp","last_synced_at":"2026-06-23T15:32:01.528Z","repository":{"id":204837347,"uuid":"693195709","full_name":"gematik/tiger-integration-ncp","owner":"gematik","description":"This project provides test case implementations for testing the German NCPeH (National Contact Point for eHealth). It focuses on validating end-to-end functionality and interoperability within the national product chain. All test scenarios are written in Gherkin and described in German.","archived":false,"fork":false,"pushed_at":"2026-05-20T11:35:17.000Z","size":1539,"stargazers_count":1,"open_issues_count":0,"forks_count":1,"subscribers_count":5,"default_branch":"main","last_synced_at":"2026-05-20T15:53:25.897Z","etag":null,"topics":["testing-tools","testsuites"],"latest_commit_sha":null,"homepage":"","language":"Java","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"apache-2.0","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/gematik.png","metadata":{"files":{"readme":".github/README.md","changelog":null,"contributing":null,"funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":"SECURITY.md","support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null,"zenodo":null,"notice":null,"maintainers":null,"copyright":null,"agents":null,"dco":null,"cla":null}},"created_at":"2023-09-18T14:37:06.000Z","updated_at":"2026-05-20T12:52:42.000Z","dependencies_parsed_at":"2023-11-09T11:57:00.349Z","dependency_job_id":"4bea3032-ee62-49d8-91d7-e4a87cb7e950","html_url":"https://github.com/gematik/tiger-integration-ncp","commit_stats":null,"previous_names":["gematik/tiger-integration-ncp"],"tags_count":4,"template":false,"template_full_name":null,"purl":"pkg:github/gematik/tiger-integration-ncp","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/gematik%2Ftiger-integration-ncp","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/gematik%2Ftiger-integration-ncp/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/gematik%2Ftiger-integration-ncp/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/gematik%2Ftiger-integration-ncp/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/gematik","download_url":"https://codeload.github.com/gematik/tiger-integration-ncp/tar.gz/refs/heads/main","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/gematik%2Ftiger-integration-ncp/sbom","scorecard":null,"host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":286080680,"owners_count":34696735,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2026-05-26T15:22:16.424Z","status":"online","status_checked_at":"2026-06-23T02:00:07.161Z","response_time":65,"last_error":null,"robots_txt_status":"success","robots_txt_updated_at":"2025-07-24T06:49:26.215Z","robots_txt_url":"https://github.com/robots.txt","online":true,"can_crawl_api":true,"host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["testing-tools","testsuites"],"created_at":"2024-11-08T16:27:25.674Z","updated_at":"2026-06-23T15:32:01.522Z","avatar_url":"https://github.com/gematik.png","language":"Java","funding_links":[],"categories":[],"sub_categories":[],"readme":"\u003ca href=\"https://www.gematik.de\"\u003e\u003cimg align=\"right\" width=\"250\" height=\"47\" src=\"../Gematik_Logo_Flag_With_Background.png\" alt=\"Gematik Logo\"/\u003e\u003c/a\u003e\u003cbr/\u003e\n\n# Tiger-Integration-NCP\n\n\u003cdetails\u003e\n \u003csummary\u003eTable of Contents\u003c/summary\u003e\n \u003col\u003e\n \u003cli\u003e\u003ca href=\"#about-the-project\"\u003eAbout the Project\u003c/a\u003e\u003c/li\u003e\n \u003cli\u003e\u003ca href=\"#release-notes\"\u003eRelease Notes\u003c/a\u003e\u003c/li\u003e\n \u003cli\u003e\n \u003ca href=\"#getting-started\"\u003eGetting Started\u003c/a\u003e\n \u003cul\u003e\n \u003cli\u003e\u003ca href=\"#prerequisites\"\u003ePrerequisites\u003c/a\u003e\u003c/li\u003e\n \u003cli\u003e\u003ca href=\"#running-the-tests\"\u003eRunning the Tests\u003c/a\u003e\u003c/li\u003e\n \u003cli\u003e\u003ca href=\"#troubleshooting\"\u003eTroubleshooting\u003c/a\u003e\u003c/li\u003e\n \u003c/ul\u003e\n \u003c/li\u003e\n \u003cli\u003e\n \u003ca href=\"#test-environment\"\u003eTest Environment\u003c/a\u003e\n \u003cul\u003e\n \u003cli\u003e\n \u003ca href=\"#test-components\"\u003eTest Components\u003c/a\u003e\n \u003c/li\u003e\n \u003cli\u003e\n \u003ca href=\"#environment-variables\"\u003eEnvironment Variables\u003c/a\u003e\n \u003c/li\u003e\n \u003cli\u003e\n \u003ca href=\"#configuration-files\"\u003eConfiguration Files\u003c/a\u003e\n \u003cul\u003e\n \u003cli\u003e\u003ca href=\"#overview\"\u003eOverview\u003c/a\u003e\u003c/li\u003e\n \u003cli\u003e\u003ca href=\"#adjusting-infrastructureyaml\"\u003eAdjusting \u003ccode\u003einfrastructure.yaml\u003c/code\u003e\u003c/a\u003e\u003c/li\u003e\n \u003c/ul\u003e\n \u003c/li\u003e\n \u003cli\u003e\n \u003ca href=\"#test-data\"\u003eTest Data\u003c/a\u003e\n \u003cul\u003e\n \u003cli\u003e\u003ca href=\"#data-about-the-test-insurant\"\u003eData about the Test Insurant\u003c/a\u003e\u003c/li\u003e\n \u003cli\u003e\u003ca href=\"#data-about-the-german-test-practitioner\"\u003eData about the German Test Practitioner\u003c/a\u003e\u003c/li\u003e\n \u003cli\u003e\u003ca href=\"#data-about-the-european-test-practitioner\"\u003eData about the European Test Practitioner\u003c/a\u003e\u003c/li\u003e\n \u003cli\u003e\u003ca href=\"#providing-test-data\"\u003eProviding Test Data\u003c/a\u003e\u003c/li\u003e\n \u003c/ul\u003e\n \u003c/li\u003e\n \u003c/ul\u003e\n \u003c/li\u003e\n \u003cli\u003e\n \u003ca href=\"#use-case-eprescriptionedispensation-country-a-epeda\"\u003eUse Case: ePrescription/eDispensation Country A (ePeDA)\u003c/a\u003e\n \u003cul\u003e\n \u003cli\u003e\u003ca href=\"#epeda-scenario-overview\"\u003eePeDA Scenario Overview\u003c/a\u003e\u003c/li\u003e\n \u003cli\u003e\u003ca href=\"#epeda-specific-test-data\"\u003eePeDA-Specific Test Data\u003c/a\u003e\u003c/li\u003e\n \u003c/ul\u003e\n \u003c/li\u003e\n \u003cli\u003e\n \u003ca href=\"#use-case-patient-summary-country-a-psa\"\u003eUse Case: Patient Summary Country A (PSA)\u003c/a\u003e\n \u003cul\u003e\n \u003cli\u003e\u003ca href=\"#psa-scenario-overview\"\u003ePSA Scenario Overview\u003c/a\u003e\u003c/li\u003e\n \u003cli\u003e\u003ca href=\"#psa-specific-test-data\"\u003ePSA-Specific Test Data\u003c/a\u003e\u003c/li\u003e\n \u003c/ul\u003e\n \u003c/li\u003e\n \u003cli\u003e\u003ca href=\"#license\"\u003eLicense\u003c/a\u003e\u003c/li\u003e\n \u003cli\u003e\u003ca href=\"#additional-notes-and-disclaimer-from-gematik-gmbh\"\u003eAdditional Notes and Disclaimer from gematik GmbH\u003c/a\u003e\u003c/li\u003e\n \u003cli\u003e\u003ca href=\"#contact\"\u003eContact\u003c/a\u003e\u003c/li\u003e\n \u003cli\u003e\n \u003ca href=\"#appendix\"\u003eAppendix\u003c/a\u003e\n \u003cul\u003e\n \u003cli\u003e\u003ca href=\"#links--references\"\u003eLinks / References\u003c/a\u003e\u003c/li\u003e\n \u003cli\u003e\u003ca href=\"#glossary\"\u003eGlossary\u003c/a\u003e\u003c/li\u003e\n \u003c/ul\u003e\n \u003c/li\u003e\n \u003c/ol\u003e\n\u003c/details\u003e\n\n## About the Project\n\nThis project provides test scenarios for the German National Contact Point for eHealth (NCPeH),\ndesigned to verify correct operation and compliance with the\n[gemSpec_NCPeH_FD_V2.0.1](https://gemspec.gematik.de/docs/gemSpec/gemSpec_NCPeH_FD/gemSpec_NCPeH_FD_V2.0.1/)\nspecification. \nThe test scenarios cover two eHDSI use cases:\n\n- **ePrescription/eDispensation Country A (ePeDA)** — enabling a German patient to fill\n e-prescriptions at a pharmacy in another EU member state.\n- **Patient Summary Country A (PSA)** — searching for and retrieving the patient summary from the\n electronic health record (_elektronische Patientenakte_, ePA) of a German patient receiving\n treatment in another EU member state.\n\nEach use case is tested for end-to-end functionality, interoperability with the national Telematics\nInfrastructure (TI), and performance reporting to the TI monitoring\nsystem (_Betriebsdatenerfassung_, BDE).\n\nThese tests serve as acceptance tests during the NCPeH approval process conducted by gematik GmbH.\nThey are published to help developers and testers working on the NCPeH with quality assurance ahead\nof that process. All scenarios are written in German using Gherkin syntax.\n\n\u003e [!NOTE]\n\u003e The following aspects are **not** covered by the test scenarios:\n\u003e * Transformation and transcoding rules — i.e. conformance of the resulting CDA or FHIR documents\n to eHDSI requirements and correctness of the contained medical data\n\u003e * Detailed testing of the NCPeH's eHDSI interface, since tests are run within the national test\n environment and do not involve actual cross-border data transfer. A simulation is used to mimic\n the NCPeH in the country of treatment.\n\n## Release Notes\n\nSee [ReleaseNotes.md](../ReleaseNotes.md) for all information regarding the latest releases.\n\n## Getting Started\n\nThis section provides instructions on how to get started with the project, including setting up the\ndevelopment environment and running the test suite.\n\n### Prerequisites\n\n* Git\n* Java JDK 21\n* Maven 3.8.0 or later\n* Docker \u0026 Docker Compose\n\nTo run end-to-end tests using real TI services, you also need:\n\n* A way of connecting to the TI (see\n [gematik.de/telematikinfrastruktur/ti-zugang](https://www.gematik.de/telematikinfrastruktur/ti-zugang)\n for details)\n* Test identity for the German insurant (to authenticate to the insurant's personal client)\n\n### Running the Tests\n\nTo execute the test suite (in local mode, i.e. without long-running tests and using mocks for\nexternal components):\n\n```bash\nmvn clean verify\n```\n\nTo capture Maven output in a log file:\n\n```bash\nmvn clean verify | tee reports/maven-$(date +%Y%m%d-%H%M%S).log\n```\n\n### Troubleshooting\n\nIf you encounter a `java.nio.charset.UnmappableCharacterException`, set the `MAVEN_OPTS`\nenvironment variable:\n\n```bash\nexport MAVEN_OPTS=-Dfile.encoding=UTF-8\n```\n\nYou can add this to your `.bashrc` or `.bash_profile` to make it persistent.\n\n## Test Environment\n\nThis test suite relies on the [Tiger Test Framework](https://github.com/gematik/app-Tiger) to manage\nand run the Cucumber-based scenarios. Tiger ensures all required components are properly\nstarted, configured, and available during test execution. It also captures and records the\ncommunication exchanged between the participating components, enabling detailed analysis of test\nruns.\nFor general setup, configuration options, and advanced usage of the framework, refer to the\nofficial [Tiger User Manual](https://gematik.github.io/app-Tiger/Tiger-User-Manual).\n\n### Test Components\n\nDepending on the use case being tested, certain\nexternal test components, which are involved in the end-to-end workflow, need to be integrated into\nthe test environment. For example, the e-prescription/e-dispensation use case requires that an\ninsurant authorizes the country of treatment for health data access via their personal client. This\nproject includes mocks which mimic the required components to allow for a\npurely local test run in the default configuration. \nThe end-to-end tests, which interact with services located in the TI, use the implementations listed\nbelow. They need to be activated via their individual configurations files which are maintained in\nthe `tiger` directory of this repository. Test components can be provided as executable JAR\napplications, Docker images which are started automatically at test launch, or as pre-running\nservices.\n\n\u003e [!NOTE]\n\u003e With the current configuration, end-to-end tests involving TI-services are only possible when run\n\u003e on gematik infrastructure. The following sections are meant to provide an overview of the required\n\u003e components and their configuration. If you are interested in running the tests on your own\n\u003e infrastructure, please contact the project maintainers to discuss the necessary adjustments.\n\n#### Common (All Use Cases)\n\n| Component | Description | Implementation |\n|---------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|\n| NCPeH Country B Simulator | Simulates a practitioner in another EU country interacting with a German patient's health data. Used for patient identification, document discovery, and document retrieval across all use cases. | Until the fully-functional simulator is available, the `ncpeh-simulation-mock` implementation included in the [ncpeh-simulation-api](https://github.com/gematik/NCPeH-Simulation-API) project is used to run the scenarios. |\n\n#### Use Case: ePeDA\n\n| Component | Description | Implementation |\n|-----------------------------------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-------------------------------------------------------------------------------------|\n| E-Prescription Personal Client Simulator | Simulates an insurant's client application, enabling automated selection and authorization of e-prescriptions for cross-border dispensation, and providing the access code needed by the EU pharmacist. | [ref-erp-fdv-testdriver](https://github.com/gematik/ref-erp-fdv-testdriver) |\n| Health Professional E-Prescription Client Simulator | Simulates a German practitioner's client software for issuing e-prescriptions. | `primsys-rest` in [erp-e2e-testsuite](https://github.com/gematik/erp-e2e-testsuite) |\n\n#### Use Case: PSA\n\n| Component | Purpose | Implementation |\n|------------------------------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------|-----------------------------------------------------------------------------------------------|\n| ePA Personal Client Simulator | Simulates an insurant's ePA client application, enabling the authorization of EU practitioners for patient summary access and providing the required access code. | [api-ePA-Testtreiber](https://github.com/gematik/api-ePA-Testtreiber/tree/epa3.1/src/openapi) |\n| Health Professional ePA Client Simulator | Simulates a German practitioner's software for storing the patient summary in the patient's ePA account. | [epa-ps-sim](https://github.com/gematik/epa-ps-sim) |\n| ePA VAU Proxy | Responsible for establishing an encrypted connection to ePA backends. Used by the HP ePA Client Simulator. | [epa-deployment](https://github.com/gematik/epa-deployment) |\n\n### Environment Variables\n\nThe following environment variables must be set when running the tests with the implementations\nlisted above:\n\n#### Common (All Use Cases)\n\n| Variable | Description |\n|--------------------------------|----------------------------------------------------------------------------------|\n| `TIGER_DOCKER_HOST` (optional) | Remote Docker daemon URL (if Docker is not available locally)* |\n| `PROXY_HOST` (optional) | Corporate proxy host for components that require outbound internet connectivity. |\n| `PROXY_PORT` (optional) | Corporate proxy port for components that require outbound internet connectivity. |\n\n*For details on configuring Tiger to set up a Docker node, see the\n[Tiger User Manual](https://gematik.github.io/app-Tiger/Tiger-User-Manual.html#docker-container-node).\n\n#### Use Case: ePeDA\n\n| Variable | Description |\n|-------------------|---------------------------------------------------------------------------------|\n| `ERPIONE_API_KEY` | API key for PrimSys REST (health professional e-prescription client simulator). |\n| `ERP_FDV_API_KEY` | API key for the e-prescription personal client simulator. |\n\n#### Use Case: PSA\n\n| Variable | Description |\n|--------------------------|-----------------------------|\n| `PS_SIM_KONN17_USERNAME` | Username for KSP connector. |\n| `PS_SIM_KONN17_PASSWORD` | Password for KSP connector. |\n\n### Configuration Files\n\n#### Overview\n\nConfiguration is entirely file-based. The key files are:\n\n| File | Location | Purpose |\n|-----------------------------------------------------|--------------|------------------------------------------------------------------------------------------------------------------------|\n| [pom.xml](../pom.xml) | Project root | Maven build configuration including maven profiles specifying which scenarios to run and which components to activate. |\n| [tiger.yaml](../tiger.yaml) | Project root | Main Tiger configuration: enables the Workflow UI and integrates additional config files. |\n| [dwh.yaml](../tiger/erpFdv.yaml) | `tiger/` | Configuration for the data warehouse API of the *BDE* performance data reporting system (\"dwh\" component) |\n| [erpFdv.yaml](../tiger/erpFdv.yaml) | `tiger/` | E-Prescription personal client configuration (\"Erp-FdV\" component). |\n| [fdv.yaml](../tiger/fdv.yaml) | `tiger/` | EHR personal client configuration (\"ePA FdV\" component). |\n| [infrastructure.yaml](../tiger/infrastructure.yaml) | `tiger/` | Hostnames and base paths for each test component. |\n| [ncpeh.yaml](../tiger/ncpeh.yaml) | `tiger/` | NCPeH Simulation component configuration. |\n| [primsys-rest.yaml](../tiger/primsys-rest.yaml) | `tiger/` | Health professional e-prescription client configuration (\"PrimSys REST\" component). |\n| [psSim.yaml](../tiger/psSim.yaml) | `tiger/` | Health professional EHR client configuration (\"ePA PS-Sim\" component). |\n| [testdata.yaml](../tiger/testdata.yaml) | `tiger/` | Test data (patients, practitioners, profiles, ePKA templates, reporting settings). |\n\n\u003e [!CAUTION]\n\u003e Configurations are loaded into a Java object of type `de.gematik.test.ncp.ExternalServerConfig`.\n\u003e Changing the structure or naming of test components in `infrastructure.yaml` will likely break\n\u003e the test suite.\n\nEach test component is configured in a similar way via its respective YAML file:\n\n* The `active` property controls whether the component should be activated at test launch. The test\n suite will fall back to mocks for any component that is not active.\n* Jar files of `externalJar`-type test components will be copied into the folder\n `target/externalJars`.\n\nFor further information please consult\nthe [Tiger User Manual](https://gematik.github.io/app-Tiger/Tiger-User-Manual.html).\n\n#### Adjusting `infrastructure.yaml`\n\nChanges to this file should rarely be necessary. If they are:\n\n- Each test component has its own section.\n- `hostname` — defines how Tiger and the test suite code refer to the component.\n- `basePath` — the path at which the component's endpoints are exposed (application-specific;\n adjust only if switching implementations).\n\n### Test Data\n\nPart of the test data is generated dynamically at runtime; certain templates must be prepared in\nadvance as static data. This section describes the common data structures shared across use cases.\n\n#### Data about the Test Insurant\n\n##### Identity Data\n\nEach test insurant is identified by a valid KVNR referring to a test identity in the TI. To manage\nePA / e-prescription access for both German and EU practitioners, the insurant's personal client\nmust be configured with an *AUT certificate* with a private key.\n\n##### Personal Data\n\nThe following **required** personal-data attributes are configured in\n[testdata.yaml](../tiger/testdata.yaml), section `patients`:\n\n| Attribute | Description |\n|-------------------|--------------------------------------------------|\n| `kvnr` | Unique insurant identifier |\n| `name.titles` | *(optional)* Titles such as \"Dr.\", \"Prof.\", etc. |\n| `name.givenNames` | First names |\n| `name.lastNames` | Last names |\n| `birthDate` | Date of birth (`yyyy-mm-dd`) |\n\nThis data is used to verify NCPeH output during patient identification and document retrieval and to\ngenerate ePKA documents in the PSA use case.\n\n##### Non-Correlation of Identity and Personal Data\n\nThe name and birthdate of a test insurant do **not** need to match the identity data in the\ninsurant's certificates. The NCPeH does not process any personal data from the insurant certificates\nassigned to a given KVNR. You can therefore associate any available KVNR with the pre-configured\npersonal data. Note that, for the PSA use case, an active ePA account must be prepared and available\nfor this KVNR. (see [testdata.yaml](../tiger/testdata.yaml), section\n`recordsystems`)\n\n##### Dynamic Data\n\nAccess codes are generated when access rights are granted via the insurant's personal client.\n\nWhen the LE-DE writes the ePKA document into the insurant's ePA account, both the document and its\nmetadata are generated on the fly.\n\n#### Data about the German Test Practitioner\n\nThe German practitioner's identity data (SMC-B) is used to store documents in the test insurant's\nePA account. Any valid Test-SMC-B may be used with a connector, either as a physical card or a\nvirtual card image. Automated test execution uses a card image with a card terminal simulation\nconnected to a *KSP* connector.\n\nThe practitioner's personal data is not relevant for these tests.\n\nConfiguration is in [testdata.yaml](../tiger/testdata.yaml), section `practitioners.de`:\n\n| Attribute | Description |\n|--------------|-------------------------------------|\n| `titles` | Titles such as \"Dr.\", \"Prof.\", etc. |\n| `givenNames` | First names |\n| `lastNames` | Last names |\n\n#### Data about the European Test Practitioner\n\nThe EU practitioner's identity, personal data, and associated country must be configured on the\nNCPeH country B simulator and are referenced by a profile name (see\n[ncpeh-simulation-api](https://github.com/gematik/NCPeH-Simulation-API)).\n\nConfiguration is in [testdata.yaml](../tiger/testdata.yaml), section `practitioners.eu`:\n\n| Attribute | Description |\n|---------------|--------------------------------------------------------------------------------------------------------------------|\n| `name` | A human-readable name for test-step readability (e.g., \"Dr. John Doe\"). |\n| `profileName` | The name of the configuration profile referencing both a TRC and an IDA profile in the NCPeH country B simulation. |\n\nThe `profileName` must match a profile in the `profiles` section\nof [testdata.yaml](../tiger/testdata.yaml). A profile references TRC and IDA profiles via the\nmandatory attributes `trcProfileName` and `idaProfileName`. Referenced profiles must be configured\nin the NCPeH simulation [ncpeh-simulation-api](https://github.com/gematik/NCPeH-Simulation-API).\n\n\u003e [!NOTE]\n\u003e Configuration profiles and their contents must be coordinated with the NCPeH-B simulation\n\u003e provider (DVKA).\n\n#### Providing Test Data\n\nAll test data is configured in [testdata.yaml](../tiger/testdata.yaml). The file contains these\nsections:\n\n| Section | Description |\n|-----------------------------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|\n| `epka.templates` | Object containing the classpath locations of ePKA template files as attributes. |\n| `patients` | Personal data and KVNRs of test insurants, see [Personal Data](#personal-data). |\n| `practitioners` | `eu` and `de` sub-sections for EU and German practitioner data. |\n| `recordsystems` | Provider names of ePA Aktensystem backends with a list of KVNRs for existing ePA accounts. Each KVNR listed here must uniquely identify a patient in the `patients` section! |\n| `profiles.`\\\u003c_profileName_\\\u003e | Configuration profiles for the communication with the NCPeH country B simulation. `profileName` must match a name from `practitioners.eu.profileName`. |\n| `profiles.`\\\u003c_profileName_\\\u003e`.trcProfileName` | Profile to be used by the NCPeH country B simulation to generate a TRC assertion. |\n| `profiles.`\\\u003c_profileName_\\\u003e`.idaProfileName` | Profile to be used by the NCPeH country B simulation to generate an IDA assertion. |\n| `config.names.titles` | List of allowed titles in the name of the test insurant. |\n| `config.names.prefixes` | List of allowed prefixes in the name of the test insurant. |\n| `reporting.fileName` | Name of the file to write performance reporting data to. |\n| `reporting.acceptableDelta` | Specifies the tolerated deviation, in milliseconds, between the scenario starting time recorded by the DWH service and that recorded by the testsuite. Reported performance metrics are only considered valid if their starting times fall within this acceptable delta. |\n\n---\n\n## Use Case: ePrescription/eDispensation Country A (ePeDA)\n\nThe ePeDA use case enables a German patient to fill e-prescriptions at a pharmacy in another EU\nmember state (eHDSI scenario \"ePrescription/eDispensation Country A\"). The patient uses\na personal client application to select e-prescriptions for cross-border use, authorize the EU\ncountry, and receive an access code. The EU pharmacist then uses the patient's KVNR and access code\nto identify the patient, list redeemable prescriptions, retrieve selected prescriptions, and\ndispense the medication.\n\n### ePeDA Scenario Overview\n\nSeven feature files cover this use case:\n\n| Feature File | Use Case | Description |\n|----------------------------------------------------------------------------------------------------------------------|-------------------------------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|\n| [200_epedaPatientIdentification.feature](../src/test/resources/features/ePeD/200_epedaPatientIdentification.feature) | NCPeH.UC_9 — Identify the insurant for ePeD-A | Tests patient identification by the EU pharmacist using KVNR and access code. |\n| [210_epedaFindDocuments.feature](../src/test/resources/features/ePeD/210_epedaFindDocuments.feature) | NCPeH.UC_10 — List redeemable e-prescriptions | Tests listing of e-prescriptions available for cross-border dispensation. |\n| [220_epedaRetrieveDocuments.feature](../src/test/resources/features/ePeD/220_epedaRetrieveDocuments.feature) | NCPeH.UC_11 — Retrieve selected e-prescriptions | Tests retrieval of selected e-prescriptions by the EU pharmacist. |\n| [230_epedaDispensePrescription.feature](../src/test/resources/features/ePeD/230_epedaDispensePrescription.feature) | NCPeH.UC_12 — Dispense medication | Tests medication dispensation to the insurant in the country of treatment. |\n| [240_epedaErpInteroperability.feature](../src/test/resources/features/ePeD/240_epedaErpInteroperability.feature) | E-Rezept interoperability | Tests interoperability between the NCPeH and the E-Rezept Fachdienst, including authorization handling. |\n| [250_epedaNcpInteroperability.feature](../src/test/resources/features/ePeD/250_epedaNcpInteroperability.feature) | NCPeH interoperability | Tests security-related interoperability aspects: KVNR/access-code validation, LE-EU permission and role codes, assertion consistency, country-code verification, and service access restrictions. |\n| [290_epedaPerfReporting.feature](../src/test/resources/features/ePeD/290_epedaPerfReporting.feature) | Performance reporting | Validates performance metrics for UC_9–UC_12 reported to the BDE, including operation counts, duration plausibility, and status reporting. |\n\n### ePeDA-Specific Test Data\n\nIn addition to the common test data described [above](#test-data), ePeDA scenarios require:\n\n- **E-prescriptions** issued by a German practitioner, which the insurant must **actively mark as\n available** for cross-border dispensation.\n- An **access code** generated when the insurant authorizes the EU country via the\n e-prescription personal client.\n- **NCPeH authorization** for the EU member state to access the insurant's e-prescriptions. Must be\n granted via the e-prescription personal client.\n\n---\n\n## Use Case: Patient Summary Country A (PSA)\n\nThe PSA use case covers searching for and retrieving the patient summary from a German patient's\nePA, as defined in\n[gemSpec_NCPeH_FD_V2.0.1](https://gemspec.gematik.de/docs/gemSpec/gemSpec_NCPeH_FD/gemSpec_NCPeH_FD_V2.0.1/).\nIt leverages the ePA to enable a practitioner in another EU member state to access the patient's\nePKA (elektronische Patientenkurzakte).\n\n### PSA Scenario Overview\n\nSix feature files cover this use case:\n\n| Feature File | Use Case | Description |\n|-----------------------------------------------------------------------------------------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------|--------------------------------------------------------------------------------------------------------------------------------------------|\n| [100_psaPatientIdentification.feature](../src/test/resources/features/PSA/100_psaPatientIdentification.feature) | [NCPeH.UC_1](https://gemspec.gematik.de/docs/gemSpec/gemSpec_NCPeH_FD/gemSpec_NCPeH_FD_V2.0.1/#5.1.1) — Identify the insurant in the country of treatment | Tests patient identification; covers fault scenarios caused by unavailable or invalid ePKA documents. |\n| [110_psaFindDocuments.feature](../src/test/resources/features/PSA/110_psaFindDocuments.feature) | [NCPeH.UC_2](https://gemspec.gematik.de/docs/gemSpec/gemSpec_NCPeH_FD/gemSpec_NCPeH_FD_V2.0.1/#5.1.2) — List ePKA MIO metadata | Tests document metadata discovery; covers fault scenarios (no content checks). |\n| [120_psaRetrieveDocumentCDA3.feature](../src/test/resources/features/PSA/120_psaRetrieveDocumentCDA3.feature) | [NCPeH.UC_3](https://gemspec.gematik.de/docs/gemSpec/gemSpec_NCPeH_FD/gemSpec_NCPeH_FD_V2.0.1/#5.1.3) — Retrieve the ePKA MIO (CDA Level 3) | Tests structured XML document retrieval; covers fault scenarios. |\n| [130_psaRetrieveDocumentCDA1.feature](../src/test/resources/features/PSA/130_psaRetrieveDocumentCDA1.feature) | [NCPeH.UC_4](https://gemspec.gematik.de/docs/gemSpec/gemSpec_NCPeH_FD/gemSpec_NCPeH_FD_V2.0.1/#5.1.4) — Retrieve the ePKA MIO as PDF/A (CDA Level 1) | Tests PDF retrieval and combined retrieval of both CDA levels. Fault scenarios are covered by the CDA Level 3 feature. |\n| [140_psaEpaInteroperability.feature](../src/test/resources/features/PSA/140_psaEpaInteroperability.feature) | Interoperability | Tests NCPeH–ePA interoperability: missing/unfound accounts, account states, multiple backends, access permissions, and session management. |\n| [190_psaPerfReporting.feature](../src/test/resources/features/PSA/190_psaPerfReporting.feature) | Performance reporting | Validates performance metrics reported to the BDE for successful and failed use cases, and verifies product information. |\n\n### PSA-Specific Test Data\n\nIn addition to the common test data described [above](#test-data), PSA scenarios require:\n\n- At least one insurant with an active account on **every** ePA backend variant (currently IBM and\n Rise)\n- An **ePKA test document** stored in the ePA account containing the insurant's identity and\n personal data, the German practitioner's identity, and an ePKA template.\n- **Metadata** about the ePKA document for response validation.\n- The **ePA access code** generated when granting cross-border access via the ePA personal client.\n\nNote: Instead of using a personal client to grant access to the insurant's ePA account,\nauthorization of the German health professional can optionally happen ad-hoc by inserting the\npatient's eGK into a card terminal. This process can be simulated using a KSP connector with a\ncard terminal simulation and an *eGK image* which contains the AUT certificate of the test insurant.\n\n---\n\n## License\n\nCopyright 2022-2026 gematik GmbH\n\nApache License, Version 2.0\n\nSee the [LICENSE](../LICENSE) for the specific language governing permissions and limitations under\nthe License\n\n## Additional Notes and Disclaimer from gematik GmbH\n\n1. Copyright notice: Each published work result is accompanied by an explicit statement of the\n license conditions for use. These are regularly typical conditions in connection with open source\n or free software. Programs described/provided/linked here are free software, unless otherwise\n stated.\n2. Permission notice: Permission is hereby granted, free of charge, to any person obtaining a copy\n of this software and associated documentation files (the \"Software\"), to deal in the Software\n without restriction, including without limitation the rights to use, copy, modify, merge,\n publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to\n whom the Software is furnished to do so, subject to the following conditions:\n 1. The copyright notice (Item 1) and the permission notice (Item 2) shall be included in all\n copies or substantial portions of the Software.\n 2. The software is provided \"as is\" without warranty of any kind, either express or implied,\n including, but not limited to, the warranties of fitness for a particular purpose,\n merchantability, and/or non-infringement. The authors or copyright holders shall not be\n liable in any manner whatsoever for any damages or other claims arising from, out of or in\n connection with the software or the use or other dealings with the software, whether in an\n action of contract, tort, or otherwise.\n 3. The software is the result of research and development activities, therefore not necessarily\n quality assured and without the character of a liable product. For this reason, gematik does\n not provide any support or other user assistance (unless otherwise stated in individual cases\n and without justification of a legal obligation). Furthermore, there is no claim to further\n development and adaptation of the results to a more current state of the art.\n3. Gematik may remove published results temporarily or permanently from the place of publication at\n any time without prior notice or justification.\n4. Please note: Parts of this code may have been generated using AI-supported technology. Please\n take this into account, especially when troubleshooting, for security analyses and possible\n adjustments.\n\n## Contact\n\nFor questions, issues, or other inquiries regarding this project, please reach out via the\n[gematik service portal](https://service.gematik.de/servicedesk/customer/portal/34).\n\n## Appendix\n\n### Links / References\n\n- [Tiger User Manual](https://gematik.github.io/app-Tiger/Tiger-User-Manual.html)\n- [NCPeH Simulation API](https://github.com/gematik/NCPeH-Simulation-API)\n- [gematik NCPeH Specification](https://gemspec.gematik.de/docs/gemSpec/gemSpec_NCPeH_FD/latest/index.html)\n- [gematik Service Portal for NCPeH](https://service.gematik.de/servicedesk/customer/portal/34)\n- [ePA FdV Test Driver OpenAPI Description](https://github.com/gematik/api-ePA-Testtreiber/tree/epa3.1/src/openapi)\n- [E-Rezept FDV Test Driver](https://github.com/gematik/ref-erp-fdv-testdriver)\n- [E-Rezept E2E Test Suite](https://github.com/gematik/erp-e2e-testsuite)\n\n### Glossary\n\n| Term | Full Name | Description |\n|--------|----------------------------------------|-----------------------------------------------------------------------------------|\n| BDE | Betriebsdatenerfassung | TI monitoring system for performance data reporting. |\n| eHDSI | eHealth Digital Service Infrastructure | EU-wide infrastructure for cross-border eHealth data exchange. |\n| ePA | elektronische Patientenakte | Centrally stored electronic health record for German insurants (see ePA AS). |\n| ePA AS | ePA Aktensystem | Electronic health record system (EHR) in Germany. |\n| ePeDA | ePrescription/eDispensation Country A | eHDSI use case for cross-border e-prescription dispensation. |\n| ePKA | elektronische Patientenkurzakte | Digital patient health summary; equivalent to the eHDSI patient summary. |\n| FdV | Frontend des Versicherten | Application for insurants to access health records and manage access permissions. |\n| KSP | Konnektor Service Platform | gematik service providing _Konnektor_ devices and simulated cards for testing. |\n| KVNR | Krankenversichertennummer | Unique insurant identifier in Germany. First 10 characters match `[A-Z][0-9]{9}`. |\n| LE-DE | Leistungserbringer Deutschland | German healthcare professional. |\n| LE-EU | Leistungserbringer EU | European healthcare professional. |\n| PSA | Patient Summary Country A | eHDSI use case for cross-border patient summary access. |\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fgematik%2Ftiger-integration-ncp","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fgematik%2Ftiger-integration-ncp","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fgematik%2Ftiger-integration-ncp/lists"}