Seiteninhalt:
Normativ
Die Vorgaben von ISiK-Connect betreffen aktuell ausschließlich Systeme in der Rolle eines ISiK-Ressourcenservers. Diese Systeme MÜSSEN die auf dieser Seite beschriebenen Autorisierungsinformationen bei jedem Zugriffsversuch auf FHIR-Ressourcen verarbeiten können (ANF-CON-029).
Bestätigungsrelevante Systeme in der Rolle eines ISiK-Ressourcenservers DÜRFEN im “patient”-Level Scope (s.u.) KEINE Zugriffstoken (Access Token) akzeptieren, in denen kein Kontext als Bezugspunkt für die gewährten Zugriffsrechte angegeben ist bzw. per Introspection ermittelt werden kann (ANF-CON-030).
Es MÜSSEN mindestens die Kontexte “patient” und “encounter” unterstützt werden (ANF-CON-031).
Beispiele:
"patient": "87a339d0-8cae-418e-89c7-8651e6aab3c6"
"encounter": "dd345a12-ed67-e451-3422-9813d3a400bc"
ISiK-Ressourcenservers MÜSSEN bei der Durchsetzungen von Autorisierungen die Festlegungen zum Compartment Patient unterstützen (ANF-CON-032). Sie KÖNNEN weitere der von HL7 definierten CompartmentDefinitionen unterstützen.
ISiK-Ressourcen-Server DÜRFEN KEINE eigenen CompartmentDefinitionen definieren, da eine Definition von Compartments alleinig durch HL7 erfolgen darf (ANF-CON-052).
Die Unterstützung eines Compartments umfasst, dass die Festlegungen in der CompartmentDefinition die Gruppierung von über Scopes angegebenen Berechtigungen zu der als Kontext angegebenen Ressource bestimmen. Im “patient”-Level Scope (s.u.) bestimmt das Patient Compartment die maximal zulässigen Berechtigungen eines Zugriffs auf die den angegebenen Kontext darstellende Ressource.
Beispiel: Der gegebene Kontext ist der Patient “123”. Die über einen Scope angegebene Autorisierung ist ‘patient/Observation.r’. Der ISiK-Ressourcen-Server darf nur Anfragen ausführen, die lesend auf Observation-Ressourcen zugreifen, die über ‘Observation.subject’ oder ‘Observation.performer’ dem Patienten “123” zugeordnet sind.
Berechtigungen auf Ressourcentypen MÜSSEN sowohl in der SMART Capabilities Datei als auch in den gegenüber dem ISiK-Ressourcen-Server bestätigten Scopes in der folgenden Syntax kodiert werden (ANF-CON-033):
(patient | user | system) \/ (_Ressourcetyp_ | \*) \. c?r?u?d?s? (\? (_param_\=_value_) (\& _param_\=_value_)* )?
SMART-on-FHIR-Berechtigungen auf Ressourcen lassen sich in drei Kategorien einteilen, die alle durch ISiK-konforme Ressourcen-Server unterstützt werden MÜSSEN (ANF-CON-034):
Autorisierungen in einem SMART on FHIR Launch Kontext, für den keine Compartment-Definition existiert (z. B. ‘launch/location’), SOLLEN in einem “user”- oder “system”-Level Scope erfolgen (z. B. ‘user/Location.rs’) (ANF-CON-035).
Es MÜSSEN alle in weiteren ISiK-Modulen profilierten Ressourcentypen unterstützt werden. Sofern in ISiK ein Ressourcentyp als zulässig definiert wird, MÜSSEN alle in FHIR definierten lesenden und modifizierenden Operationen unterstützt werden (ANF-CON-036):
| Berechtigung | FHIR-Operation auf System-Ebene | FHIR-Operation auf Typ-Ebene | FHIR-Operation auf Instanz-Ebene |
|---|---|---|---|
| c | create | ||
| r | read, vread, history | ||
| u | update, patch | ||
| d | delete | ||
| s | search, history | search, history |
Berechtigungen werden im Scope in der dargestellten Reihenfolge (‘cruds’) angegeben (vgl. https://hl7.org/fhir/smart-app-launch/STU2.2/scopes-and-launch-context.html#clinical-scope-syntax). Bei einer falschen Reihenfolge SOLL der ISiK-Ressourcen-Server einen Zugriffsfehler auslösen (ANF-CON-037).
Die Möglichkeit von Wildcard-Scopes MUSS unterstützt werden (ANF-CON-038).
Alle in ISiK für den Ressourcetyp unterstützten Suchparameter inkl. Modifier und Kombinationsmöglichkeiten MÜSSEN als Teil eines Scopes unterstützt werden (ANF-CON-039).
Die folgende Beispiele geben gültige Scopes wieder:
patient/Patient.rspatient/Observation.crudspatient/Observation.rs?category=http://terminology.hl7.org/CodeSystem/observation-category|laboratory