Ontwikkelaars die voor het eerst een klant in de gezondheidszorg bedienen, stellen zich HIPAA vaak voor als een enorme code-audit. Meestal is dat niet het geval. De Security Rule is een set van administratieve, fysieke en technische beveiligingsmaatregelen. Het grootste deel van een HIPAA-programma bestaat uit risicoanalyses, beleid, personeel en contracten met leveranciers. Alleen een klein deel wordt bepaald door wat je code doet, en als je weet welk deel dat is, wordt het hele proces minder mysterieus.
Deze pagina gaat over dat deel dat met code te maken heeft. Het is geen bepaling of je een gedekte entiteit bent, geen BAA (Business Associate Agreement) en geen belofte dat heygrc of ISMS Copilot ePHI afhandelt.
De beveiligingsmaatregelen die code raken
De technische beveiligingsmaatregelen staan in 45 CFR 164.312. De maatregelen die daadwerkelijk veranderen in een pull request zijn unieke gebruikersidentificatie (164.312(a)(2)(i)), noodtoegang (164.312(a)(2)(ii)), automatische afmelding (164.312(a)(2)(iii)), versleuteling en ontsleuteling (164.312(a)(2)(iv)), auditcontroles (164.312(b)), integriteit (164.312(c)(1)), authenticatie van persoon of entiteit (164.312(d)) en beveiliging van verzending (164.312(e)(1)). Automatische afmelding en versleuteling/ontsleuteling zijn aanpasbare specificaties: implementeer ze waar redelijk en passend, of documenteer waarom niet en gebruik een equivalente maatregel. Als je kunt redeneren over wie toegang heeft tot ePHI, of activiteiten worden geregistreerd, of gegevens versleuteld zijn in rust en tijdens verzending, en of een wijziging de oproeper nog steeds authenticeert, dan redeneer je over het grootste deel van de codegerichte aspecten van de Security Rule.
Veel van wat in de engineering als HIPAA-achtig aanvoelt, bevindt zich buiten de diff: toegangsonderzoeken, training van medewerkers, een risicoanalyse en een ondertekende BAA wanneer de regels voor business associates van toepassing zijn (die laatste is een verplicht contract, niet alleen bewijs dat een proces is uitgevoerd). De code zelf heeft vooral betrekking op 164.312.
De wijzigingen die bevindingen worden
Een pull request die een volledige aanvraagbody met patiëntgegevens logt, kan ePHI opslaan in een omgeving waar meer mensen toegang toe hebben dan het systeem van record. Een wijziging die versleuteling van een gegevensopslag verwijdert, of die alle toegang routeert via een gedeeld serviceaccount, is hetzelfde type probleem: de beveiligingsmaatregel is na de merge zwakker dan ervoor. Als dit in de PR wordt opgemerkt, heeft de auteur nog de context om het op te lossen. Als het wordt ontdekt tijdens een beveiligingsreview van een klant of een onderzoek, is het een herstelactie met een papieren spoor.
Die asymmetrie is het argument om de 164.312-aspecten bij de diff te controleren in plaats van ze te ontdekken nadat een klant om bewijs heeft gevraagd.
Waar heygrc past, en de eerlijkheidsgrens
heygrc is gebouwd om die patronen te herkennen wanneer HIPAA een van de geselecteerde frameworks is, en om de beveiligingsmaatregel bij de clausule te citeren. Het bepaalt niet of je een gedekte entiteit of een business associate bent, schrijft geen risicoanalyse, tekent geen BAA of slaat ePHI op. Noch heygrc noch ISMS Copilot is een HIPAA business associate voor de klantgegevens in dit product. Gebruik het als reviewer van de wijziging, niet als compliance-programma.