| ANF-CON-001 |
IHE IUA - Abschnitt 34.1.1.3 Resource Server |
MUSS |
| ANF-CON-002 |
IHE IUA - Abschnitt 3.103.2.1 Resource Server |
SOLL |
| ANF-CON-003 |
IHE IUA - Abschnitt 3.71.4.1.2.2 Authorization Code grant type |
SOLL |
| ANF-CON-004 |
IHE IUA - Abschnitt 3.71.4.1.2.2 Authorization Code grant type |
MUSS |
| ANF-CON-005 |
ISiK-Ressourcen-Server - Verarbeitung von Autorisierungen |
MUSS |
| ANF-CON-006 |
FHIR-Ressourcen-Server - Mindestunterstützung Compartment Definition |
MUSS |
| ANF-CON-007 |
FHIR-Ressourcen-Server - Bestätigung von Scopes |
MUSS |
| ANF-CON-008 |
Autorisierungsserver - Client-Id Vergabe |
MUSS |
| ANF-CON-009 |
EHR-Client-Start durch externen Kontextaufruf |
MUSS |
| ANF-CON-010 |
SMART App Launch - EHR Launch Parameter |
MUSS |
| ANF-CON-011 |
Autorisierungsendpunkte per HTTPS erreichbar |
MUSS |
| ANF-CON-012 |
Standalone Launch - URL des FHIR-Endpunkts |
MUSS |
| ANF-CON-013 |
Abfrage des .well-known/smart-configuration Dokuments |
MUSS |
| ANF-CON-014 |
OAuth 2.0 Endpunkte im CapabilityStatement |
MUSS |
| ANF-CON-015 |
Scopes for requesting identity data |
MUSS |
| ANF-CON-016 |
Konfiguration der erlaubten Scopes pro Client |
MUSS |
| ANF-CON-017 |
Confidential Clients - Authentifizierung am Token-Endpunkt |
MUSS |
| ANF-CON-018 |
SMART App Launch - Obtain access token |
MUSS |
| ANF-CON-019 |
Unterstützung verpflichtender SMART App Launch Details |
MUSS |
| ANF-CON-020 |
Verarbeitung des Access Tokens - Validierungsschritte |
MUSS |
| ANF-CON-021 |
Begrenzte Gültigkeitsdauer des Access Tokens (RFC6819) |
SOLL |
| ANF-CON-022 |
Unterstützung von Refresh Tokens |
SOLL |
| ANF-CON-023 |
SMART App Launch - Refresh access token |
MUSS |
| ANF-CON-024 |
OAuth 2.0 Token Revocation (RFC7009) |
MUSS |
| ANF-CON-025 |
Sicherstellung der sofortigen Token-Invalidierung |
MUSS |
| ANF-CON-026 |
ISiK-Ressourcen-Server - Unterstützung von Scopes |
MUSS |
| ANF-CON-027 |
.well-known-Dokument über unterstützte Scopes |
MUSS |
| ANF-CON-028 |
ISiK-Funktionalitäten durch Reverse Proxy/API Gateway |
KANN |
| ANF-CON-029 |
Verarbeitung von Autorisierungsinformationen |
MUSS |
| ANF-CON-030 |
Keine Zugriffstoken ohne Kontextangabe akzeptieren |
DÜRFEN NICHT |
| ANF-CON-031 |
Unterstützung der Kontexte “patient” und “encounter” |
MUSS |
| ANF-CON-032 |
Durchsetzung von Autorisierungen gemäß Compartment Patient |
MUSS |
| ANF-CON-033 |
Berechtigungen auf Ressourcentypen in der SMART Datei und Capabilities |
MUSS |
| ANF-CON-034 |
Kategorien von SMART-on-FHIR-Berechtigungen auf Ressourcen |
MUSS |
| ANF-CON-035 |
Autorisierungen ohne Compartment-Definition auf “user”- oder “system”-Level Scope |
SOLL |
| ANF-CON-036 |
Verpflichtende Umsetzung der ISiK-Connect-Vorgaben |
MUSS |
| ANF-CON-037 |
Berechtigungen im Scope in der Reihenfolge ‘cruds’ angeben |
SOLL |
| ANF-CON-038 |
Wildcard-Scopes |
MUSS |
| ANF-CON-039 |
Unterstützung von Suchparametern |
MUSS |
| ANF-CON-040 |
exp-Parameter für Backend Service Tokens |
DARF NICHT |
| ANF-CON-041 |
Validierung JWT Client Assertion |
MUSS |
| ANF-CON-042 |
Patient- / User-level Backend Service |
KÖNNEN/SOLL |
| ANF-CON-043 |
Zurückweisung Scopes Backend Service |
MUSS |
| ANF-CON-044 |
Scope-Parameter Backend Service |
MUSS |
| ANF-CON-045 |
Launch Scopes Access Token Response |
MUSS |
| ANF-CON-046 |
authorization_endpoint |
MUSS |
| ANF-CON-047 |
grant_types_supported |
MUSS |
| ANF-CON-048 |
refresh_token |
MUSS |
| ANF-CON-049 |
code_challenge_methods_supported |
MUSS/DARF NICHT |
| ANF-CON-050 |
scopes_supported |
MUSS |
| ANF-CON-051 |
capabilitites: permission-v2 |
MUSS |
| ANF-CON-052 |
KEINE eigenen CompartmentDefinitionen |
DÜRFEN NICHT |