aktin / aktin/dwh-admin

Configurable Hash Persistence from HL7 CDA Patient Data in AKTIN DWH

Offen
#38 1 Kommentar 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen
enhancement
Vorherrschende Sprache
TypeScript
Sterne
0
Forks
0
Ø Merge
7 T. 3 Std.
Gemergte PRs (30 T.)
2

Beschreibung

**User Story**
As an AKTIN DWH user, I want to generate and store a secure hash from specific patient information in the HL7 CDA message that is currently not persisted in the database. This will allow pseudonymized tracking of patient cases while ensuring data privacy. The hashing functionality should be configurable, allowing hospitals to enable or disable it and to define a shared secret for hash generation. Furthermore, I want to configure multiple hash pseudonyms for different studies.

For example, in the TRANSPARENT project, I want to track patients across healthcare environments. The Gesundheitsdatennutzungsgesetz (GDNG) allows me to do this as long as a hash-based pseudonym is generated within the respective healthcare environment. Therefore, we need to generate a secure hash at the source (within the AKTIN DWH) to enable cross-institutional identification based on specific projects. This requires the ability to configure a shared secret for each study, ensuring that the pseudonyms remain consistent within a study while remaining unlinkable outside of their intended context.

**Current Situation**
The HL7 CDA message contains a recordTarget section, which includes patient identifiers, name, gender, birth date, and address information. However, this section is not currently persisted in the AKTIN DWH database.

Example HL7 CDA snippet:

>
>
>
>
>
>
>
> Dachauer Straße 112
> 80636
> München
>
>
>
>
> Timo
> Kicker
>
>
>
>
>
>
>
>
> Currently, none of this information is persisted in the AKTIN DWH, but a hash should be generated from selected patient attributes and stored in the database.

**Requirements**
Hash Generation from Patient Data:
- The system should compute a hash upon import or update of HL7 CDA messages.
- The hash should be based on configurable patient attributes, such as:
- Given name (given)
- Family name (family)
- Health insurance number (id extension with a specific root)
- Birthdate (birthTime)

Configurable Feature Activation:
- The hashing functionality must be optional and configurable in the aktin.properties configuration file.
- If disabled, no hash should be generated or stored.

Shared Secret for Hashing:
- The hash generation must support a configurable shared secret to ensure deterministic but secure pseudonymization.
- A separate shared secret must be configurable for each study, allowing cross-institutional tracking within a defined research context while keeping hashes unlinkable across projects.
- The shared secret should be defined in the aktin.properties configuration file and should support periodic rotation.Multiple
- Study-Specific Hashes:
- The system must support the generation of multiple hash pseudonyms for different studies.
- Each study can have a separate hash based on different configurations.
- The study hash should be persisted in the database along with metadata defining its scope (i.e., which study it belongs to).

Persistence in AKTIN DWH:
- The computed hash(es) should be stored in the AKTIN DWH database as separate fields.
- Each study-specific hash should be linked to the relevant patient dataset for later retrieval.
- Pseudonyms will be stored in Consent Manager Tables and can be accessed via Consent Manager User Interface in AKTIN DWH

Security Considerations
- The shared secret should be stored securely and should not be hardcoded in the application source code.
- The hashing algorithm should be cryptographically secure (e.g., HMAC-SHA256 with the shared secret).
- The generated hashes should be irreversible to protect patient privacy.

**Benefits**
Enables GDNG-compliant pseudonymized tracking of patients across institutions while preserving data protection principles.
Allows different hospitals to decide whether they want to use patient hashing.
Provides flexibility for multiple studies, ensuring that each study receives a distinct but consistent pseudonym.
Supports secure and configurable hashing with a shared secret per study, ensuring that pseudonyms are only linkable within their intended research context.

Beitragsleitfaden

Für dieses Repository ist kein Beitragsleitfaden indexiert

Bewertung

Dieses Issue wurde noch nicht bewertet.

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.