Kısa cevap: Bir sağlık uygulamasındaki güvenlik, dört soruyu sırayla yanıtlar. Bu kim? Kimlik: OpenID Connect aracılığıyla doğrulanmış bir kullanıcı (hasta, klinisyen, sistem) ve klinisyenler için ulusal mesleki kimlik; doğrulama seviyesi parola gücünden daha önemlidir. Ne yapabilirler? Yetkilendirme: SMART on FHIR sözdiziminde kapsamları olan OAuth 2.0 (2.1'e geçiyor) belirteçleri, bir amaç ve süre için hastanın rızasından türetilir ve veri katmanında uygulanır. Ne yaptılar? Hesap verebilirlik: hastanın okuyabileceği bir erişim günlüğü ve kuruluş için bir FHIR AuditEvent izi. Veriler dinlenme, aktarım ve yedeklemelerde güvende mi? Koruma: şifreleme, anahtar yönetimi, ayırma, test edilmiş geri yüklemeler. Bunların etrafında: ISO 27001 ve 27799, NIS2 ve HIPAA'nın Güvenlik Kuralı'nın temelini oluşturanlar ve sağlık verilerine özgü tehditler (içeriden göz atma, yanlış dosyalam, fidye yazılımı).
Harita
Bir sağlık uygulamasındaki güvenlik ve kimlik yedi katmandan oluşur: OpenID Connect ve ulusal veya profesyonel kimlikler aracılığıyla kimlik, OAuth 2.0 ve SMART on FHIR kapsamları aracılığıyla yetkilendirme, her iznin kaynağı olarak rıza, erişim günlükleri ve FHIR AuditEvent aracılığıyla hesap verebilirlik, şifreleme ve yedeklemeler aracılığıyla koruma, ISO 27001, ISO 27799, NIS2 ve HIPAA temelinde bir başlangıç noktası ve hasta tarafından başlatılan paylaşım.
| Katman | Standart veya uygulama | Size ne sağlar | Sayfa |
|---|---|---|---|
| Kimlik | OpenID Connect; ulusal kimlikler (eIDAS, NHS login, GesundheitsID); mesleki kimlikler (eHBA, CPS, UZI) | Bir güvence seviyesine sahip doğrulanmış bir özne | SMART Uygulama Başlatma açıklandı |
| Yetkilendirme | OAuth 2.0 ve 2.1 (PKCE zorunlu, örtülü veya parola verme yok); SMART on FHIR kapsamları (patient/Observation.rs); asimetrik istemci kimlik doğrulamalı arka uç hizmetleri | Bir kullanıcıya, bir hasta bağlamına ve bir kapsama bağlı belirteçler | SMART Uygulama Başlatma açıklandı, SMART on FHIR arka ucu |
| Rıza | FHIR Rıza; amaç ve zamana bağlı izinler; geri alma; gerekçe ve uyarı ile "kırılma camı" | Her yetkilendirmenin kaynağı olarak hasta | Hasta rıza platformu, Klinik erişim istekleri |
| Hesap verebilirlik | Hastanın görebildiği kayıt başına erişim günlükleri; FHIR AuditEvent; kurcalamaya dayanıklı depolama; saklama | Kim neyi, ne zaman, neden gördü | Tıbbi kaydıma kim baktı? |
| Koruma | TLS 1.2+, yönetilen anahtarlarla dinlenme durumunda şifreleme, tanımlayıcılar için alan düzeyinde şifreleme, ayrılmış ortamlar, test edilmiş geri yüklemeli yedeklemeler | Gizlilik ve kullanılabilirlik | ISO 27001 vs ISO 27799 |
| Temel | ISO 27001 ISMS, 27799 sağlık kontrolleri, NIS2 önlemleri, HIPAA Güvenlik Kuralı, ulusal şemalar (HDS, DSPT, C5) | Hastaneler, denetçiler ve düzenleyiciler ne bekler | Hastaneler ve satıcılar için NIS2, HIPAA vs GDPR |
| Paylaşım | SMART Sağlık Bağlantıları ve Kartları; doğrulanabilir kimlik bilgileri | Hasta tarafından başlatılan bağlantı veya QR ile paylaşım, geri alınabilir | SMART Sağlık Bağlantıları açıklandı |
Kimlik: parolalar yerine güvence
Bir sağlık uygulamasında kimlik, parola gücü yerine güvenceye dayanır: NIST IAL, eIDAS substantial ve high veya NHS login P9 gibi kimlik güvence seviyeleri, bir kişinin kayıt sırasında ne kadar güçlü doğrulandığını açıklarken, çok faktörlü kimlik doğrulama ve geçiş anahtarları her oturum açmayı açıklar. Klinikler, ayrıldıklarında iptal edilen profesyonel kimliklerle tanımlanır.
Tam bir kaydı gösteren bir hasta uygulaması, o hasta ile konuştuğunu bilmelidir. Kimlik güvence seviyeleri (NIST'in IAL'si, eIDAS'ın önemli ve yüksek seviyesi, NHS login P9) kimliğin kayıt sırasında ne kadar güçlü doğrulandığını açıklar; kimlik doğrulama gücü (çok faktörlü, geçiş anahtarları) her oturumu açıklar. Hastaneler ve ulusal sistemler giderek artan bir şekilde, kendi kendine beyan edilen kayıtlardan ziyade tanınmış şemalardan doğrulanmış kimlikler gerektiriyor ve AB Dijital Kimlik Cüzdanı kabul edilebilir bir araç haline gelecek. Klinisyenler için mesleki kimlik (ve birinin ayrıldığında geri alınması), bir klinisyen olarak kimin hareket edebileceğinin kayıt sistemi haline gelir.
Yetkilendirme: rıza kapsam haline gelir
Hasta kontrollü bir kayıtta yetkilendirme, hastanın rızasını, örneğin bir kliniğin 90 gün boyunca laboratuvar sonuçlarını ve durumlarını okumasına izin vermek gibi, OAuth kapsamlarına ve belirteçteki hasta bağlamına, SMART on FHIR sözdiziminde patient/Observation.rs gibi, her istekte veri katmanında zorlanır ve hasta geri çektiğinde iptal edilir. Break-the-glass ayrı, denetlenmiş bir yoldur.
Hasta kontrollü bir kayıtta, hastanın rızası politikadır: bu klinik laboratuvar sonuçlarımı ve durumlarımı 90 gün boyunca okuyabilir. Sistem, bunu klinisyenin sisteminin aldığı belirteçteki OAuth kapsamlarına ve bağlama (hangi hasta, hangi kaynaklar, hangi işlemler) çevirir, her istekte veri katmanında uygular ve hasta geri çektiğinde geri alır. SMART on FHIR'ın kapsam sözdizimi (patient/Observation.rs, patient/Condition.rs), bunun için ortak dildir; daha ince kontrol için SMART v2'de ayrıntılı kapsamlar (kategoriye veya koda göre) mevcuttur. Kırılma camı (rıza olmadan acil erişim), zorunlu gerekçe ve hastaya uyarı ile ayrı, denetlenmiş bir yoldur, asla varsayılan değildir. Hasta rıza platformuna bakın.
Hesap verebilirlik: hastanın okuduğu günlük
Bir sağlık uygulamasında hesap verebilirlik, bir kayda yapılan her erişimin, kim tarafından, ne zaman, ne ve hangi rıza ile yapıldığının, hastanın uygulamasında okuyabileceği yalnızca eklenen bir günlükte ve FHIR AuditEvent'teki bir organizasyonel denetim izinde kaydedilmesi anlamına gelir. ISO 27799 bunu zorunlu kabul eder ve görünür bir günlük, kurum içi göz atma için en güçlü caydırıcıdır.
Bir kayda yapılan her erişim, kim tarafından, ne zaman, ne, hangi rıza altında, hastanın uygulamasında okuyabileceği yalnızca eklemeli bir günlükte ve güvenlik ekipleri için kurumsal bir denetim izinde (FHIR AuditEvent) kaydedilir. ISO 27799 bunu sağlık bilgileri için zorunlu kabul eder; GDPR'ın şeffaflık ilkesi ve EHDS'nin hasta hakları aynı yöne işaret eder; içeriden göz atmanın en büyük gerçek dünya caydırıcısı görünür bir günlüktür. Tıbbi kaydıma kim baktı? bölümüne bakın.
Koruma: mühendislik temeli
Sağlık verilerini korumak için mühendislik temeli, her yerde TLS, yönetilen, döndürülen anahtarlarla depolama sırasında şifreleme, doğrudan tanımlayıcılar için ayrı şifreleme veya belirteçleştirme, üretim dışı ayrılmış ortamlarda sentetik veriler, yöneticiler için çok faktörlü kimlik doğrulama ile en az ayrıcalık erişimi, sır ve güvenlik açığı yönetimi, fidye yazılımlarına karşı geri yükleme ile test edilmiş şifreli yedeklemeler ve GDPR ve NIS2 saatleri içinde olay müdahalesi.
Her yerde TLS, modern şifreler ve uygun olduğunda uygulamalarda sertifika sabitleme; yönetilen bir anahtar hizmetinde anahtarlarla dinlenme durumunda şifreleme ve anahtar rotasyonu; doğrudan tanımlayıcılar için ayrı şifreleme veya belirteçleştirme; üretim ortamının geliştirme ortamından ayrılması, üretim dışı sentetik verilerle; personel için en az ayrıcalık erişimi, paylaşılan hesap yok, tüm idari erişim için çok faktörlü kimlik doğrulama; sır yönetimi; açıklama ile bağımlılık ve güvenlik açığı yönetimi; şifrelenmiş yedeklemeler, geri yükleme ile test edilmiş ve hastaneleri ve laboratuvarları tekrar tekrar vuran fidye yazılımlarına (2017'de WannaCry, 2020'de Düsseldorf hastanesi, 2024'te Change Healthcare ve Synnovis) karşı korunmuş. 72 saatlik GDPR ve 24 saatlik NIS2 saatlerini tek bir çalıştırma defterinde içeren olay müdahalesi.
Sağlık verilerine özgü tehditler
Sağlık verilerine özgü tehditler, tanıdıkların kayıtlarının kurum içi göz atılması, hastalar arasında yanlış dosyalanma, çok uzun süre verilen aşırı geniş paylaşımlar, sağlık verilerini işleyen uygulamaların içindeki reklam SDK'ları, AI özelliklerine belge kaynaklı enjeksiyon ve anahtarların, formatların ve erişim kurallarının personel ve satıcılardan daha uzun süre dayanması gereken on yıllar boyunca uzun saklama süreleri.
- Tanıdıkların veya tanınmış kişilerin kayıtlarının içeriden gözden geçirilmesi: ilişki tabanlı erişim ve görünür günlükler.
- Hastalar arasında yanlış dosyalam: yalnızca erişim kontrolü değil, kimlik uzlaştırması ve köken bilgisi.
- Aşırı geniş paylaşım: bir yıl boyunca "her şey" izni verilmiş bir klinik; makul varsayılanlarla kapsamlar ve süreler.
- Reklam SDK'larına sahip uygulamalar: sağlık verilerini işleyen hiçbir şeyde üçüncü taraf izleyici yok.
- Yapay zeka özelliklerine belge kaynaklı enjeksiyon: içerik veridir, asla talimat değildir (Tıbbi kayıtlarda RAG).
- Uzun saklama: kayıtlar on yıllarca yaşar; anahtarlar, formatlar ve erişim kuralları personel ve satıcıların ömrünü aşmalıdır.
Anpheros'ta
Anpheros, güvenlik haritasını uygulamalar için PKCE ile OAuth 2.0 ve arka uçlar için asimetrik istemci kimlik doğrulaması, her kliniğin erişim kaynağı olarak amaç ve süre başına rıza, kişinin uygulamasında kayıt başına erişim günlüğü, depolama ve aktarım sırasında şifreleme, AB barındırma, reklam SDK'sı olmaması ve ISO 27001 ve 27799'a göre bir ISMS ile kendine uygular.
Anpheros bu haritayı kendine uygular: uygulamalar için PKCE ve arka uçlar için asimetrik istemci kimlik doğrulaması ile OAuth 2.0; her kliniğin erişim kaynağı olarak amaç ve süre başına rıza, geri alma ve sessiz kırılma camı yok; kişinin uygulamasında kayıt başına erişim günlüğü; dinlenme ve aktarım sırasında şifreleme, AB barındırma, reklam SDK'sı yok; 27799 sağlık kontrolleri ile ISO 27001'e göre bir ISMS. Geliştirici sitesi kimlik doğrulama, rıza ve güvenlik belgelerini sunar.
İlgili sayfalar
- SMART Uygulama Başlatma açıklandı
- Hasta rıza platformu
- Tıbbi kaydıma kim baktı?
- SMART Sağlık Bağlantıları açıklandı
- ISO 27001 vs ISO 27799
- Hastaneler ve sağlık teknolojisi satıcıları için NIS2
- Platform güvenliği (geliştirici sitesi)
- Kimlik doğrulama (geliştirici sitesi)
Kaynaklar
- HL7 SMART Uygulama Başlatma
- IETF: OAuth 2.1 (taslak)
- OpenID Connect Core 1.0
- HL7 FHIR R4: AuditEvent
- HL7 FHIR R4: Consent
- NIST SP 800-63-4: Dijital Kimlik Kılavuzları
- ISO 27799:2016
- ENISA: Hastanelerde siber güvenlik için tedarik kılavuzları
Sık sorulan sorular
OAuth 2.1, 2.0'dan farklı mı?
OAuth 2.1, 2.0'ı güvenlik en iyi uygulamalarıyla birleştirir: tüm istemciler için PKCE zorunludur, örtülü ve parola verme işlemleri kaldırılmıştır, yönlendirme URI'leri tam olarak eşleşmelidir ve genel istemciler için yenileme belirteçleri bağlı veya döndürülmelidir. SMART on FHIR v2 zaten bunların çoğunu gerektiriyor.
Kırılma camı nedir?
Bir klinisyenin gerekçe belirttiği, hastanın ön rızası olmadan bir kayda acil erişim. Nadir olmalı, kaydedilmeli, gözden geçirilmeli ve hastaya bildirilmelidir; asla varsayılan erişim yolu değildir.
Hastalar neden erişim günlüğünü görmeli?
Çünkü uygunsuz erişime karşı en güçlü caydırıcı ve kontrolün en net ifadesidir: kişi hangi kliniğin neyi ne zaman okuduğunu görür ve geri alabilir. ISO 27799 ve EHDS aynı yöne işaret eder.
Ayrı bir denetim sistemine ihtiyacım var mı?
Uygulamanın değiştiremeyeceği, ilkeye göre saklanan ve bunlardan türetilen hastaya dönük bir görünümü olan yalnızca eklemeli bir denetim izine (FHIR AuditEvent veya eşdeğeri) ihtiyacınız vardır. Ayrı bir sistem mi yoksa platform içindeki korumalı bir depolama mı olduğu bir uygulama seçimidir.
Sandbox'ta ücretsiz deneyin
İlk FHIR çağrınız 5 dakikada. Hasta izniyle yerleşik HL7 FHIR R4 API: sandbox'ta deneyin, ardından kendi uygulamanızı veya klinik sisteminizi bağlayın.
Ücretsiz · 30 sentetik hasta · kart gerekmez
Anpheros, hasta kontrolünde olan ve herhangi bir klinik ile paylaşılabilecek, AB merkezli bir HL7 FHIR R4 platformu üzerinde tıbbi kayıtlar oluşturur. Bu rehberler, sağlığınızı anlamanıza ve düzenlemenize yardımcı olur; doktorunuzun yerini tutmaz.
Anpheros Hakkında →