datasharingframework · schwzr · Mar 8, 2026 · Mar 8, 2026 · Mar 8, 2026 · Mar 8, 2026
diff --git a/.github/workflows/pull_request.yml b/.github/workflows/pull_request.yml
@@ -3,7 +3,7 @@ name: docs
 on:
   # trigger build on every PR phase
   pull_request:
-    types: [opened, reopened, review_requested]
+    types: [opened, synchronize, reopened, review_requested]
   # trigger deployment manually
   workflow_dispatch:
 

diff --git a/docs/package-lock.json b/docs/package-lock.json
diff --git a/docs/src/community/consultation-hours.md b/docs/src/community/consultation-hours.md
@@ -7,7 +7,7 @@ icon: guide
 
 Mondays, 14:00–14:50
 
-Location: https://dsf.dev/sprechstunde
+Location: /sprechstunde
 :::
 
 Click [here](https://lecture.senfcall.de/sim-ock-1vk-l8o) to join the consultation hour.

diff --git a/docs/src/community/contribute/README.md b/docs/src/community/contribute/README.md
@@ -12,13 +12,13 @@ We are thrilled that you consider contributing to our projects. Your contributio
     * **MII Zulip**: If you are part of the German Medical Informatics Initiative, [join the MII Zulip community](https://mii.zulipchat.com/#narrow/stream/392426-Data-Sharing-Framework-.28DSF.29) to assist others, share your knowledge, and learn from fellow contributors.
     * **GitHub Discussions**: Engage with our community in [GitHub Discussions](https://github.com/datasharingframework/dsf/discussions) by answering questions, providing feedback, and sharing your insights.
 2. **Testing releases**:
-    * **Stay ahead**: Help us testing the latest releases. Your feedback on functionality, bugs, and user experience is invaluable.
+    * **Stay ahead**: Help us test the latest releases. Your feedback on functionality, bugs, and user experience is invaluable.
     * **Report findings**: Share your testing results to help us refine and enhance our releases.
 3. **Reviewing changes**:
     * **Peer review**: Contribute by reviewing pull requests. Your insights can help ensure the quality and integrity of code changes.
     * **Constructive feedback**: Offer constructive feedback and suggestions to help improve and refine proposed changes.
 4. **Documentation changes**:
-    * **Improve documentation**: Help us improving and updating our documentation. Clear and accurate documentation is crucial for user understanding and success. Please checkout our [Getting started guide for documentation contributions](./documentation) to DSF.
+    * **Improve documentation**: Help us improve and update our documentation. Clear and accurate documentation is crucial for user understanding and success. Please checkout our [Getting started guide for documentation contributions](./documentation) to DSF.
     * **Suggest improvements**: If you notice gaps or areas for enhancement in our documentation, we welcome [your suggestions and contributions](https://github.com/datasharingframework/datasharingframework.github.io).
 5. **Contributing bug reports**:
     * **Report bugs**: If you find a bug, please report it via [an issue on GitHub](https://github.com/datasharingframework/dsf/issues). Detailed bug reports are incredibly helpful.
@@ -27,7 +27,7 @@ We are thrilled that you consider contributing to our projects. Your contributio
     * **Suggest features**: You have an idea for a new feature? We'd love to hear it! Open an issue to describe your proposed feature and its potential benefits according to our feature request template.
     * **Collaborate on implementation**: If you're able to, contribute to the development of your proposed feature or bug fix. Collaboration can lead to more innovative and effective solutions. Please checkout our [Getting started guide for code contributions](./code) to DSF.
 7. **Contributing process plugins**:
-    * **Develop process plugins for the DSF**: If you have ideas for a process plugin, we encourage you to develop and contribute them. Our [Getting started guide for process plugin development](https://dsf.dev/stable/develop/) will be a useful reference.
+    * **Develop process plugins for the DSF**: If you have ideas for a process plugin, we encourage you to develop and contribute them. Our [Getting started guide for process plugin development](/process-development/) will be a useful reference.
     * **Share your work**: Your plugins could be a valuable addition to the ecosystem and benefit other users.
 
 Before you start contributing, we recommend reading our getting started guidelines for detailed information on our processes and standards. This ensures a smooth and productive experience for everyone involved.

diff --git a/docs/src/community/events/tutorials/2023-05-30-MIE2023.md b/docs/src/community/events/tutorials/2023-05-30-MIE2023.md
@@ -40,5 +40,5 @@ You need a laptop with a web browser for the hands-on portion of the tutorial.
 - … gain knowledge on various distributed processes specific to bio-medical research.
 - … understand the unique challenges and considerations from the German MII resulting in the design and architecture of the DSF.
 - … be introduced to the key concepts of the DSF and the various contexts in which it can be applied. 
-- … learn how to evaluate if the DSF is appropriate for their particular project or application your planning. 
+- … learn how to evaluate if the DSF is appropriate for their particular project or application you're planning. 
 - … understand the difficulties that can occur when implementing distributed processes, as well as strategies for addressing them.
diff --git a/docs/src/community/team.md b/docs/src/community/team.md
@@ -48,11 +48,11 @@ The [LIFE Institute](https://www.uniklinikum-leipzig.de/einrichtungen/life/) of
 
 ![BMFTR Logo =228x158](/photos/learnmore/funding/bmftr.png) 
 
- The DSF Community connects the DSF competencies of the entire [Medical Informatics Initiative (MII)](https://www.medizininformatik-initiative.de/de/start) so that new use cases, in particular from Module 3 or the [Network University Medicine (NUM)](https://www.netzwerk-universitaetsmedizin.de/), are better supported in creating the respective DSF plugins. In the context of Module 2b, the DSF Community contributes to the further development of the common digital infrastructure of the MII together with the [FDPG+](https://forschen-fuer-gesundheit.de/) and [TRANSIT](https://www.gesundheitsforschung-bmbf.de/de/transit-medizininformatik-struktur-data-management-unit-16148.php) projects. [BMBF](https://www.gesundheitsforschung-bmbf.de/de/dsf-medizininformatik-struktur-data-sharing-framework-community-16133.php)
+ The DSF Community connects the DSF competencies of the entire [Medical Informatics Initiative (MII)](https://www.medizininformatik-initiative.de/de/start) so that new use cases, in particular from Module 3 or the [Network University Medicine (NUM)](https://www.netzwerk-universitaetsmedizin.de/), are better supported in creating the respective DSF plugins. In the context of Module 2b, the DSF Community contributes to the further development of the common digital infrastructure of the MII together with the [FDPG+](https://forschen-fuer-gesundheit.de/) and [TRANSIT](https://www.gesundheitsforschung-bmbf.de/de/transit-medizininformatik-struktur-data-management-unit-16148.php) projects. [BMBF](https://www.gesundheitsforschung-bmftr.de/de/dsf-medizininformatik-struktur-data-sharing-framework-community-16133.php)
 
  Heilbronn University (HHN) focuses on the connecting of DSF related topics and competencies in the MII with the community management. The quality assurance of new DSF plugins and further development of the application and core components aim at a scalable, stable and secure operation of the DSF (Funding code: 01ZZ2307A).
 
- Heidelberg University is focusing on the further development of the DSF core components as well as the rollout of the DSF plugins, in particular also from the perspective of a data integration center in consultation with the FDGP+ and TRANSIT projects (Funding code: 01ZZ2307B).
+ Heidelberg University is focusing on the further development of the DSF core components as well as the rollout of the DSF plugins, in particular also from the perspective of a data integration center in consultation with the FDPG+ and TRANSIT projects (Funding code: 01ZZ2307B).
 
  The University of Leipzig will further develop and adapt the DSF plugin for the Research Data Portal for Health FDPG according to specifications resulting from the FDPG+ project and enable Data Integration Centers (DIC) to operate the FDPG plugin (Funding code: 01ZZ2307C).
 

diff --git a/docs/src/explore/concepts/allow-list.md b/docs/src/explore/concepts/allow-list.md
@@ -7,9 +7,9 @@ icon: share
 The main objective is to allow only authorized organizations to do what "we" allow them to do (e.g. query data).
 First, we need a list of organizations that we trust. Secondly, we need a way to ensure that the other party is a member of the parent organization. Thirdly, a list of actions we want to allow the organization to perform is needed. An organization can have different roles in different use cases. 
 
-The Allow List consists of Organization-, Endpoint- and OrganisationAffiliation- resources. With these resources the allow list defines communication partners and and parent organizations like research consortia and groups as well as the roles of each organization. Each DSF FHIR server stores their own allow list. To make sure that processes can be executed, parties must allow access via their allow list.
+The Allow List consists of Organization-, Endpoint- and OrganisationAffiliation- resources. With these resources the allow list defines communication partners and parent organizations like research consortia and groups as well as the roles of each organization. Each DSF FHIR server stores their own allow list. To make sure that processes can be executed, parties must allow access via their allow list.
 
-## Allow List Managment
+## Allow List Management
 [Here](/operations/latest/allowList-mgm.md) you can read all the information if you want to create or update an Allow List.
 
 If you have the need for allowlist management feel free to contact us via <a href="mailto:dsf-gecko@hs-heilbronn.de"> E-Mail (dsf-gecko@hs-heilbronn.de)</a> and we will take care of your request as soon as possible.
diff --git a/docs/src/explore/concepts/basics.md b/docs/src/explore/concepts/basics.md
@@ -2,7 +2,7 @@
 title: Basics and Standards
 icon: study
 ---
-Here you can find some basic information about interoperability and the standards were using within the DSF before we go into details about the architecture. Here we only describe how the standards (FHIR and BPMN) are used within the DSF. If you want to gain a deeper knowledge of the standards, we recommend visiting these websites: [HL7 FHIR](https://www.hl7.org/fhir/) and [BPMN](https://www.bpmn.org/) 
+Here you can find some basic information about interoperability and the standards we're using within the DSF before we go into details about the architecture. Here we only describe how the standards (FHIR and BPMN) are used within the DSF. If you want to gain a deeper knowledge of the standards, we recommend visiting these websites: [HL7 FHIR](https://www.hl7.org/fhir/) and [BPMN](https://www.bpmn.org/) 
 
 ## Interoperability 
 Interoperability is the ability of different systems to work together as seamlessly as possible. We can divide interoperability into four levels. 

diff --git a/docs/src/explore/concepts/introduction.md b/docs/src/explore/concepts/introduction.md
@@ -6,13 +6,13 @@ The [German Federal Ministry of Research, Technology and Space](https://www.bmft
 
 ![MII =300x150](/photos/learnmore/funding/mii.png)
 
-The **Data Sharing Framework (DSF)** was developed within the HiGHmed consortium of the Medical Informatics Initiative and is now funded as an independent project by the German Federal Ministry of Research, Technology and Space within the Medical Informatics structure as *[DSF Community](https://www.gesundheitsforschung-bmbf.de/de/dsf-medizininformatik-struktur-data-sharing-framework-community-16133.php)*. 
+The **Data Sharing Framework (DSF)** was developed within the HiGHmed consortium of the Medical Informatics Initiative and is now funded as an independent project by the German Federal Ministry of Research, Technology and Space within the Medical Informatics structure as *[DSF Community](https://www.gesundheitsforschung-bmftr.de/de/dsf-medizininformatik-struktur-data-sharing-framework-community-16133.php)*. 
 
 The DSF is a concept for a secure middleware to distribute data sharing processes, aiming to extract, merge, pseudonymize and provide data stored in multiple distributed DICs. A researcher can use the DSF for example to submit feasibility queries to several DICs and thus has the opportunity to obtain sufficient data from different locations for his or her research. By using international standards such as FHIR and BPMN 2.0, the problem of heterogeneous data models, primary systems, architectures and federated legislation between DICs can be solved. The aim is to enable secure and syntactically-, semantically- and process-interoperable data exchange across organisational boundaries.
 
 ![DSF concept](/photos/info/introduction/dsf-concept.png)
 
-The DSF is a secure communication infrastructure, that (1) scales with communication relationships, (2) orchestrates processes and instances, (3) separates execution logic from program code, (4) enables automated and user-centeric process steps (5) and can be used for heterogeny structures.
+The DSF is a secure communication infrastructure, that (1) scales with communication relationships, (2) orchestrates processes and instances, (3) separates execution logic from program code, (4) enables automated and user-centric process steps (5) and can be used for heterogeneous structures.
 
 ![Federated data exchange between distributed DICs (CRP=Central Research Portal, DMU=Data Management Unit) =500x320](/photos/info/introduction/dic-structure.png)
 

diff --git a/docs/src/explore/concepts/network-setup.md b/docs/src/explore/concepts/network-setup.md
@@ -2,26 +2,26 @@
 title: Network Setup and General Architecture
 icon: customize
 ---
-The Data Sharing Framework consists of two components: A FHIR Endpoint Server used to except Task resources and provide resources for download by other organizations and a Business Process Engine Server run internal and not accessible by other organization to execute and coordinate processes.
+The Data Sharing Framework consists of two components: A FHIR Endpoint Server used to accept Task resources and provide resources for download by other organizations and a Business Process Engine Server run internal and not accessible by other organization to execute and coordinate processes.
 
-![Network Setup Diagramm](/photos/guideline/generalInformation/highmed_dsf_network_setup.svg)
+![Network Setup Diagram](/photos/guideline/generalInformation/highmed_dsf_network_setup.svg)
 
-- FHIR Reverse Proxy: The FHIR Reverse Proxy is used to terminate incoming https connections to the FHIR App Server. The Reverse Proxy needs to be accessible on port 443 from the internet. Incoming https connection will be delegate as http on a docker internal network to the FHIR App Server.
+- FHIR Reverse Proxy: The FHIR Reverse Proxy is used to terminate incoming https connections to the FHIR App Server. The Reverse Proxy needs to be accessible on port 443 from the internet. Incoming https connection will be delegated as http on a docker internal network to the FHIR App Server.
 - FHIR App Server: The FHIR App Server is used as a FHIR Endpoint for incoming Task resources and providing resources for download by other organizations. In order to validate incoming FHIR resources the server will communicate with FHIR Servers at other organizations. Access to resources and authorization for creating or updating resources is granted based on the content of the resource and/or based on the client (identified by its client certificate) being part of an allow list. JDBC connections to the FHIR DB Server
 - FHIR DB Server: PostgreSQL database for the FHIR App Server.
-- BPE App Server: The BPE App Server is executing BPMN 2.0 business processes with the included business process engine. Automatic BPMN service tasks are used for example to check resource, access the PDP- and MPI-servers as well as the MDAT repository. The calculation of record linkage bit vectors (Record Bloom Filters) is also performed using an automatic service task. As of version 0.3.0 the BPE server does not provide any webservices for modifying an server resources.
+- BPE App Server: The BPE App Server is executing BPMN 2.0 business processes with the included business process engine. Automatic BPMN service tasks are used for example to check resource, access the PDP- and MPI-servers as well as the MDAT repository. The calculation of record linkage bit vectors (Record Bloom Filters) is also performed using an automatic service task. The BPE server does not provide any webservices for modifying server resources.
 - BPE DB Server: PostgreSQL database for the BPE App Server.
 - PDP: IHE Policy Decision Point for deciding on patient consent.
 - MDAT Repo: Repository (e.g. openEHR) for storing medical data (MDAT).
-- MPI: IHE Master Patient Index for storing identifying patient date (IDAT) e.g. first name, last name, date of birth.
+- MPI: IHE Master Patient Index for storing identifying patient data (IDAT) e.g. first name, last name, date of birth.
 - Cohort Browser: Example for a system to trigger patient cohort size estimations across multiple organizations.
 
-More information on Client- and Server-Certificates are available on the dedicated wiki page: [Authentication: Client/Server Certificates](Authentication)
+More information on Client- and Server-Certificates can be found in the [Security](security) section.
 
 ## Additional Reverse Proxy in external DMZ
 In some organizations an additional reverse proxy in an external DMZ is needed. This can be accomplished by using for example nginx or haproxy as a TCP-Proxy. Example configurations routing traffic using SNI can be found below. Configuring an additional reverse proxy to terminate the incoming TLS connection early is not recommended.
 
-![Network Setup Diagramm](/photos/guideline/generalInformation/highmed_dsf_network_setup_ext_dmz.svg)
+![Network Setup Diagram](/photos/guideline/generalInformation/highmed_dsf_network_setup_ext_dmz.svg)
 <!--
 **nginx**
 ```

diff --git a/docs/src/explore/concepts/security.md b/docs/src/explore/concepts/security.md
@@ -2,7 +2,7 @@
 title: Security by Design
 icon: safe
 ---
-## Basics Security
+## Security Basics
 The open-source Data Sharing Framework is EU-GDPR compliant and meets the highest security standards by design. DSF FHIR servers only accept certain FHIR resources from internal systems/administrators (e.g. tasks, binary resources...). In addition, the communication partners are defined via Allow Lists. This means that an organisation can only communicate with organisations that are included in the allow list of approved organisations of the participating organisations. More information about allow lists can be found in the [next chapter](allow-list).
 For transport encryption, the TLS protocol is used. Secure Web Socket (WSS) connections provide security for the connection between the DSF FHIR server (DMZ) and the BPE (internal network). In addition, the DSF is being actively developed and there is an excellent community, both of which guarantee fast security patches.
 
@@ -11,7 +11,7 @@ For transport encryption, the TLS protocol is used. Secure Web Socket (WSS) conn
 ![Certificates](/photos/info/security/certificates-dark.svg#dark)
 
 ## Authentication 
-Authentication of organizations within the DSF is handled by the use of X.509 client and server certificates. The DSF supports a configurable whitelist of  certificate authorities. All participating organizations are entered in a distributed and synchronized allow-list of valid organizations and certificates.
+Authentication of organizations within the DSF is handled by the use of X.509 client and server certificates. The DSF supports a configurable allow list of certificate authorities. All participating organizations are entered in a distributed and synchronized allow-list of valid organizations and certificates.
 
 A webserver certificate is needed to run the FHIR endpoint and a 802.1X client certificate is used to authenticate against other organizations endpoints and as a server certificate for the business process engine.