Ingenieure, die ihren ersten Kunden im Gesundheitswesen gewinnen, stellen sich HIPAA oft als riesige Code-Prüfung vor. Das ist meistens nicht der Fall. Die Security Rule ist eine Reihe von administrativen, physischen und technischen Schutzmaßnahmen. Der Großteil eines HIPAA-Programms besteht aus Risikoanalysen, Richtlinien, Schulungen der Mitarbeiter und Verträgen mit Dienstleistern. Nur ein Teil wird durch das bestimmt, was dein Code tut, und wenn man diesen Teil kennt, wird das Ganze weniger mysteriös.
Diese Seite behandelt genau diesen codebezogenen Teil. Sie ist keine Bestimmung, ob du eine abgedeckte Einheit bist, kein BAA und auch keine Zusicherung, dass heygrc oder ISMS Copilot ePHI verarbeiten.
Die Schutzmaßnahmen, die den Code betreffen
Die technischen Schutzmaßnahmen sind in 45 CFR 164.312 festgelegt. Diejenigen, die tatsächlich in einem Pull Request geändert werden, sind: eindeutige Benutzeridentifikation (164.312(a)(2)(i)), Notfallzugriff (164.312(a)(2)(ii)), automatische Abmeldung (164.312(a)(2)(iii)), Verschlüsselung und Entschlüsselung (164.312(a)(2)(iv)), Audit-Kontrollen (164.312(b)), Integrität (164.312(c)(1)), Authentifizierung von Personen oder Einheiten (164.312(d)) und Übertragungssicherheit (164.312(e)(1)). Automatische Abmeldung sowie Verschlüsselung/Entschlüsselung sind anpassbare Spezifikationen: Implementiere sie, wo es sinnvoll und angemessen ist, oder dokumentiere, warum nicht, und verwende eine gleichwertige Maßnahme. Wenn du nachvollziehen kannst, wer auf ePHI zugreifen kann, ob Aktivitäten aufgezeichnet werden, ob sie im Ruhezustand und während der Übertragung verschlüsselt sind und ob eine Änderung den Anrufer weiterhin authentifiziert, dann denkst du über den Großteil der codebezogenen Aspekte der Security Rule nach.
Vieles, was sich im Engineering wie HIPAA anfühlt, liegt außerhalb des Diffs: Zugriffsprüfungen, Schulungen der Mitarbeiter, eine Risikoanalyse und ein unterzeichneter BAA, wenn die Regeln für Geschäftspartner gelten (letzteres ist ein erforderlicher Vertrag, nicht nur ein Beweis, dass ein Prozess durchgeführt wurde). Der Code selbst bezieht sich hauptsächlich auf 164.312.
Die Änderungen, die zu Befunden werden
Ein Pull Request, der den vollständigen Anforderungsbody mit Patientendaten protokolliert, kann ePHI in einem Speicher ablegen, auf den mehr Personen Zugriff haben als auf das System of Record. Eine Änderung, die die Verschlüsselung eines Datenspeichers entfernt oder alle Zugriffe über ein gemeinsames Dienstkonto leitet, gehört in dieselbe Problemkategorie: Der Schutz ist nach dem Merge schwächer als vorher. Wird dies im PR erkannt, hat der Autor noch den Kontext, um es zu beheben. Wird es in einer Kunden-Sicherheitsprüfung oder einer Untersuchung festgestellt, ist es eine Nachbesserung mit Papierkram.
Diese Asymmetrie ist das Argument dafür, die 164.312-Oberfläche im Diff zu prüfen, anstatt sie erst nach einer Kundenanfrage zu entdecken.
Wo heygrc ins Spiel kommt und die Ehrlichkeitsgrenze
heygrc ist so konzipiert, dass es diese Muster erkennt, wenn HIPAA eines der von dir ausgewählten Frameworks ist, und die Schutzmaßnahme bei der Klausel zitiert. Es bestimmt nicht, ob du eine abgedeckte Einheit oder ein Geschäftspartner bist, schreibt keine Risikoanalyse, unterzeichnet keinen BAA oder speichert ePHI. Weder heygrc noch ISMS Copilot ist ein HIPAA-Geschäftspartner für deine Kundendaten in diesem Produkt. Nutze es als Prüfer der Änderung, nicht als Compliance-Programm.