Page History
...
Hentning af Forløbsplaner
| Info |
|---|
Bemærk for at hente en forløbsplan på baggrund af en søgning, skal NSP's Service Deklaration: "Særlige begrænsninger ift. anvendelse af Dokumentdelingsservicen (DDS)" følges. Se: Dokumentdelingsservice (DDS) Opsummeret står der følgende: Der må højst være 10 minutter mellem disse kald (ITI-18 og ITI-43), begge kald skal udføres af samme bruger, og begge kald skal have samme (men unikke) ‘flowID’ |
Der er tre værdier fra retursvaret på ITI-18 forespørgslen som skal benyttes for at hente indholdet af en konkret forløbsplan:
...
| Code Block | ||||||
|---|---|---|---|---|---|---|
|
Oprettelse af Forløbsplaner
Ændring af Forløbsplaner
Sletning af Forløbsplaner
Der er ikke udstillet funktionalitet til at slette aftaler for fagsystemerne.
Aftaler bliver automatisk slettet 2 år efter udførelsestidspunktet, hvilket er fastsat lovgivningsmæssigt.
Fagsystemer skal istedet ændre aftalen, og give den status "deprecated". Det kan gøres ved at benytte ITI-57 UpdateDocumentSet, hvorved AvailabilityStatus stættes til "deprecated" istedet for "approved"
...
<RetrieveDocumentSetResponse xmlns="urn:ihe:iti:xds-b:2007" xmlns:ns2="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" xmlns:ns3="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:ns4="http://www.w3.org/2000/09/xmldsig#" xmlns:ns5="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" xmlns:ns6="http://www.medcom.dk/dgws/2006/04/dgws-1.0.xsd" xmlns:ns7="http://www.nsi.dk/hsuid/2016/08/hsuid-1.1.xsd" xmlns:ns8="urn:oasis:names:tc:ebxml-regrep:xsd:rim:3.0" xmlns:ns9="urn:oasis:names:tc:ebxml-regrep:xsd:rs:3.0" xmlns:ns10="urn:oasis:names:tc:ebxml-regrep:xsd:cms:3.0" xmlns:ns11="urn:oasis:names:tc:ebxml-regrep:xsd:query:3.0" xmlns:ns12="urn:oasis:names:tc:ebxml-regrep:xsd:lcm:3.0">
<ns9:RegistryResponse status="urn:oasis:names:tc:ebxml-regrep:ResponseStatusType:Success"/>
<DocumentResponse>
<RepositoryUniqueId>1.2.208.176.43210.8.20.11</RepositoryUniqueId>
<DocumentUniqueId>1.2.208.184^e23d1b0d-f4cc-4b3e-9973-b2a499aa15ba</DocumentUniqueId>
<mimeType>text/xml</mimeType>
<Document>
<xop:Include xmlns:xop="http://www.w3.org/2004/08/xop/include" href="cid:37b3a03a-70c8-45ea-9be5-bbaec58de49a-128338@urn%3Aihe%3Aiti%3Axds-b%3A2007"/>
</Document>
</DocumentResponse>
</RetrieveDocumentSetResponse> |
Oprettelse af Forløbsplaner
Det er praktiserende læge som opretter borgerens forløbsplan, hvorefter den udstilles via PLSP Indeks.
| Info |
|---|
Det er ikke muligt for andre parter, end de praktiserende læger, at oprette forløbsplaner. |
Ændring af Forløbsplaner
Det er praktiserende læge som opretter borgerens forløbsplan, hvorefter den udstilles via PLSP Indeks.
PLSP Indeks udstiller forløbsplaner som en dynamisk (on-demand) dokumentkilde, det betyder at det altid er den sidste opdaterede forløbsplan som hentes
| Info |
|---|
Det er ikke muligt for andre parter, end de praktiserende læger, at ændre forløbsplaner. |
Sletning af Forløbsplaner
Det er praktiserende læge som sletter borgerens forløbsplan, hvorefter den ikke længere udstilles via PLSP Indeks.
| Info |
|---|
Det er ikke muligt for andre parter, end de praktiserende læger, at slette en borgers forløbsplaner. |
Sikkerhed, roller og rettigheder
For adgang til Aftaleoversigten Forløbsplaner skal der for sundhedspersoner eksistere et gyldigt SOSI-ID kort som er signeret af NSP'ens Secure Token Service, dokumentationen for SOSI-ID kort og STS ligger under: Anvenderguide til STS
Sundhedspersoner, med en sundhedsfaglig autorisation har adgang til AftaleoversigtenForløbsplaner. Sundhedspersoner Sundhedsfaglige uden sundhedsfaglig autorisation skal have tilknyttet en rettighed før disse kan få adgang. Lokale organisationer kan enten tilknytte disse rettigheder via Sundhedsstyrelsens Elektroniske Brugerstyring (SEB), eller give rettigheden via den lokale identifikations- og rettighedsstyring.
...
Rollenavn | Rettighed | Notation som indsættes i SOSI IdKort ved udstedelse |
nspSundAssistR2 | Giver ret til at læse til Stamkort, Aftaler og Forløbsplaner | urn:dk:healthcare:national-federation-role:code:41002:value:SundAssistR2
|
En sundhedsperson sundhedsfaglige uden sundhedsfaglig autorisation kan ikke have tilknyttet flere roller på samme tid - dette skal administreres via den lokale identifikations- og rettighedsstyring, eller via SEBpå samme tid - dette skal administreres via den lokale identifikations- og rettighedsstyring, eller via SEB
| Info |
|---|
Ansvaret for at tildele rettigheder til sundhedsfaglige uden sundhedsfaglig autorisation ligger hos de enkelte parter. Parterne skal ligeledes via deres eget rolle/rettighedssystem kunne styre om en sundhedsfaglige uden sundhedsfaglig autorisation skal have adgang til både Stamkort, Aftaler og Forløbsplaner. For yderligere information, se Administrative forudsætninger |
Bemærk: Bemærk: SEB-dokumentationen samt vejledningen ved oprettelse af en rolle er ved at blive tilrettet, så rettigheden for nspSundAsisstR2 afspejler ovenstående.
Håndtering af Spærring og Fuldmagt
Spærring
PatientenBoergeren kan have spærret for deling af at data fra Aftaleoversigten må deles , herunder forløbsplaner, med andre parter i sundhedssektoren, i det tilfælde vil fejlkoden "Consent Filter Applied” blive returneret (se nedenstående xml eksempel for ITI-18 spærrede dokumenter). Det betyder at borgeren enten har spærret for deling af Aftaler data til den specifikke sundhedsperson, for Aftaler data i et givet tidsrum, for Aftaler data fra bestemte organisationer, eller i en kombination af disse. Klienten skal håndtere at der er angivet en spærring, og give sundhedspersonen mulighed for at få adgang til den fulde Aftaleoversigt forløbsplaner under specielle vilkår., se forretningsregel #6 under: Indhold og forretningsregler Forløbsplaner
For adgang til spærrede Aftaler data kan klienten enten angive at der ønskes foretaget et værdispring , eller angive at der ligger et explicit samtykke til at se data, og så sende forespørgslen igen med “ConsentOverride” flaget sat til “True”. Der laves logning i dokumentdelingsinfrastrukturen der angiver at en spærring er tilsidesat. Klienten skal samtidig angive årsagen (Eksempelvis: eksplicit samtykke fra patienten for at få adgang til data) til at spærringen er tilsidesat i eget journalsystem, da der kan forventes at være opfølgning på tilsidesatte spærringer.
...
| Code Block | ||||||
|---|---|---|---|---|---|---|
| ||||||
<rs:RegistryError codeContext="urn:dk:nsi:Consent Filter Applied" errorCode="XDSRegistryError" severity="urn:oasis:names:tc:ebxml-regrep:ErrorSeverityType:Error"/> |
Fuldmagt
Patientportaler Borgerportaler kan give patienternes borgernes pårørende adgang via den Fælles Offentlige Fuldmagtsservice, hvortil der er tilknyttet en brugergrænseflade på Borger.dk.
Bevis for fuldmagter er understøttet i OIO-IDWS identitytokens signeret af STS'en, dog understøtter dokumentdelingsservicen ikke OIO-IDWS - så fuldmagter er i stedet etableret via en trust-løsning hvor patientportalen borgerportalen selv håndterer kontrol af fuldmagter.
...