Indledning

Denne vejledning beskriver de tekniske forretningsregler i forhold til at implementere deling af kommunale tilstande og indsatser i et lokalt fagsystem eller en patient/borgerportal. Vejledningen er tiltænkt forretningsarkitekter, systemarkitekter samt systemleverandører.

Anden dokumentation

For generel introduktion til den nationale delingsinfrastruktur, se vejledningen ’Kom godt i gang med dokumentdeling’ til deling af dokumenter via Dokumentdelingsservice på NSP lavet af MedCom.

For detaljeret teknisk dokumentation omkring dokumentdeling via NSP, se beskrivelsen på Dokumentdeling på NSP (DROS, DDS, NXRG, OpenXDS)

Aktører

Figuren giver et overblik over de aktører som er i spil i relation til deling af kommunale tilstande og indsatser.

Borgere (Patienter): Borgere har læseadgang til egne kommunale tilstande og indsatser via sundhed.dk

Pårørende (andre borgere): Pårørende har læseadgang til borgerens kommunale tilstande og indsatser via sundhed.dk, hvis borgeren har tildelt den pårørende en læsefuldmagt via den fælles-offentlige fuldmagtsservice på borger.dk

Sundhedspersoner (med sundhedsfaglig autorisation): Sundhedspersoner har adgang til borgeres kommunale tilstande og indsatser via Sundhedsjournalen på sundhed.dk, eller via eget fagsystem - afhængigt af lokal implementering

Sundhedsprofessionelle (uden sundhedsfaglig autorisation): Kan få adgang til borgerens kommunale tilstande og indsatser via lokal trustmodel, hvor parterne giver relevante medarbejdere adgang til at tilgå borgeres kommunale tilstande og indsatser via Sundhedsjournalen på sundhed.dk, eller via eget fagsystem - afhængigt af lokal implementering

Teknisk oversigt

Indhold i kommunale tilstande og indsatser

Først og fremmest skal man kende til det indholdsformat der benyttes til kommunale tilstande og indsatser. Formatet er JSON og indholdet er specificeret som en dansk profil af FHIR.

FHIR-dokumentet i JSON format bliver pakket ind i XDS protokollen, så det er XDS protokollen som anvendes i forhold til at fremsøge og hente som FHIR-dokumentet.

Tekniske forudsætninger

Se Administrative forudsætninger for at få adgang til NSP'en.

Kommunale tilstande og indsatser udstilles via services på NSP'en, disse skal tilgås gennem en afkoblingskomponent "DCC'en". DCC'en viderestiller kald til underliggende services, så der er ikke en WSDL for DCC'en. Se DCC Dokumentation for adgang til services gennem DCC'en.

Det er et krav at dokumentdelingsservicen skal tilgås gennem afkoblingskomponenten

NSP services kan tilgås enten via Den Gode Webservice (DGWS) eller via OIO-IDWS (Udelukkende borger adgang). 
Den Gode WebService (DGWS) benytter XMLDSIG til at signere SAML assertions ud fra X.509 certifikater/nøgler - for adgang tilKommunale tilstande og indsatser skal sundhedspersoner have et STS-underskrevet SOSI-ID kort på niveau 4 (medarbejder), hvilket også er beskrevet under administrative forudsætninger, således at borgeren har mulighed for at lave en frabedelse så kommunale tilstande og indsatser ikke kan deles med specifikke sundhedspersoner, samt at patienten har mulighed for at se hvem der har haft adgang til patientens Kommunale tilstande og indsatser via MinLog.
For mere information om den gode webservice, se: https://www.medcom.dk/standarder/webservice-standarder/den-gode-webservice

Sundhedsdatastyrelsen har beskrevet hvordan et SOSI-ID kort kan skabes og anvendes under STS Dokumentationen

De servicesnitflader der udstilles til Kommunale tilstande og indsatser er alle baseret på SOAP kald der understøtter DGWS.
Indholdsdelen af den enkelte servicekald (SOAP body) er den del der er specificeret af IHE XDS snitfladerne, dvs. for eksempel ITI-18 og ITI-43, se nærmere beskrivelse under: Dokumentdeling på NSP (DROS, DDS, NXRG/SDS Patientindex, OpenXDS)

De detaljerede beskrivelser af snitfladerne findes i IHE IT Infrastructure Technical Framework dokumenterne volume 1, 2a, 2b, 2x og 3.

Beskrivelserne i de officielle dokumenter fra IHE er relativt komplicerede, og det kan være svært at opnå et godt overblik over hvordan specifikke kald sættes sammen. Der findes en række generelle og praktiske eksempler og programmer på IPF Open eHealth Integration Platform siderne. Se for eksempel:

Søgning på Kommunale tilstande og indsatser

For at søge efter en borgers Kommunale tilstande og indsatser, skal der laves en ITI-18 forespørgsel via NSP'ens dokumentdelingsservice.

WSDL til DDS Registry findes her: https://wsdl.nspop.dk/ddsregistry?wsdl

Når der søges påKommunale tilstande og indsatser, kan der søges på de værdier, der er angivet som XDS-metadata. Kommunale tilstande og indsatser benytter metadata profil version 0.96, der kan hentes på https://svn.medcom.dk/svn/releases/Standarder/IHE/DK_profil_metadata/

Borgerens CPR-nummer (PatientId) samt dokumentets statuskode (Status) er påkrævede felter, som skal inkluderes i alle søgninger.

ForKommunale tilstande og indsatser, er der desuden følgende forretningsmæssige XDS-metdata, som skal anvendes i søgninger:

  • Typecode: TODO - den mangler at blive defineret

Desuden anbefales det at forespørge både efter specifikt format samt statiske og dynamiske (on-demand) dokumentkilder, angives denne værdi ikke, returneres kun data fra statiske dokumentkilder.

  • Type
    • urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1 (for statiske dokumentkilder)
    • urn:uuid:34268e47-fdf5-41a6-ba33-82133c465248 (for dynamiske "on-demand" dokumentkilder)

  • FormatCode: TODO - den mangler at blive defineret

Værdierne (klassifikationerne) som anvendes i XDS-metadata er defineret i et regneark hos MedCom, se: DK-IHE_Metadata-Common_Code_systems-Value_sets.xlsx

For henholdsvis AND og OR søgninger gælder det at angives der flere søgeværdier i samme <slot> så tæller det som en OR søgning for disse værdier. Hvor der mellem de forskellige <slot> tæller som en AND søgning.

De detaljerede tekniske informationer om ITI-18 og angivelse af søgeparametre, kan ses i IHE ITI dokumentation volume 2

Eksempel på en ITI-18 forespørgsel efter Kommunale tilstande og indsatser:

ITI-18 AdhocQueryRequest 
<ns3:AdhocQueryRequest xmlns:ns3="urn:oasis:names:tc:ebxml-regrep:xsd:query:3.0" xmlns="urn:oasis:names:tc:ebxml-regrep:xsd:rim:3.0" xmlns:ns2="urn:oasis:names:tc:ebxml-regrep:xsd:rs:3.0" xmlns:ns4="urn:ihe:iti:xds-b:2007" xmlns:ns5="urn:oasis:names:tc:ebxml-regrep:xsd:lcm:3.0">
			<ns3:ResponseOption returnComposedObjects="true" returnType="LeafClass"/>
			<AdhocQuery id="urn:uuid:14d4debf-8f97-4251-9a74-a90016b0af0d">
				<Slot name="$XDSDocumentEntryTypeCode">
					<ValueList>
						<Value> TODO - indsæt typecode </Value>
					</ValueList>
				</Slot>
				<Slot name="$XDSDocumentEntryFormatCode">
					<ValueList>
						<Value> TODO. - indsæt formatcode </Value>
					</ValueList>
				</Slot>
				<Slot name="$XDSDocumentEntryPatientId">
					<ValueList>
						<Value>'2512489996^^^&1.2.208.176.1.2&ISO'</Value>
					</ValueList>
				</Slot>
				<Slot name="$XDSDocumentEntryType">
					<ValueList>
						<Value>('urn:uuid:34268e47-fdf5-41a6-ba33-82133c465248')</Value>
						<Value>('urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1')</Value>
					</ValueList>
				</Slot>
				<Slot name="$XDSDocumentEntryStatus">
					<ValueList>
						<Value>('urn:oasis:names:tc:ebxml-regrep:StatusType:Approved')</Value>
					</ValueList>
				</Slot>
			</AdhocQuery>
</ns3:AdhocQueryRequest>


Retur-svaret indeholder referencerne til dokumenterne indeholdende Kommunale tilstande og indsatser, der skal benyttes efterfølgende til at udtrække de konkrete dokumenter

ITI-18 AdhocQueryResponse 
TODO - Svar indsættes når XDS metadata er defineret

Hentning af Kommunale tilstande og indsatser

Bemærk for at henteKommunale tilstande og indsatser 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 et konkret dokument med Kommunale tilstande og indsatser:

  1. HomeCommunityId - der beskriver det domæne dokumentet befinder sig i.

    Værdien hentes ud fra ...ExtrinsicObject/@home

  2. RepositoryUniqueId - der bekriver den kilde under domænet der opbevarer dokumentet
    Værdien hentes ud fra ...ExtrinsicObject/Slot[@name=’repositoryUniqueId’]/Value List/Value
  3. DocumentUniqueId - der identificerer selve dokumentet
    Værdien hentes ud fra ...ExtrinsicObject/ExternalIdentifier[@identificationScheme=’urn:uuid:2e82c1f6-a085-4c72-9da3-8640a32e42ab]/@value

Ud fra disse værdier skal der laves en ITI-43 forespørgsel via NSP'ens dokumentdelingsservice.

Som beskrevet ovenfor benyttes de tre værdier: HomeCommunityId, RepositoryUniqueId og DocumentUniqueId til at hente dokumenterne.

WSDL til DDS Repository findes her: https://wsdl.nspop.dk/ddsrepository?wsdl

ITI-43 RetrieveDocumentSetRequest 
        <RetrieveDocumentSetRequest xmlns="urn:ihe:iti:xds-b:2007">
            <DocumentRequest>
                <HomeCommunityId>urn:oid:1.2.208.176.43210.8.20.11</HomeCommunityId>
                <RepositoryUniqueId> TODO - indsættes når repository er konfigureret (afhængig af XDS metadata) </RepositoryUniqueId>
                <DocumentUniqueId>1.2.208.184^e23d1b0d-f4cc-4b3e-9973-b2a499aa15ba</DocumentUniqueId>
            </DocumentRequest>
        </RetrieveDocumentSetRequest>


Det svar der returneres er patientens Kommunale tilstande og indsatser, indeholdende de dataelementer der er beskrevet i KL's FHIR implementeringsguide for Gateway

Bemærk at selve body delen af dokumentet til Kommunale tilstande og indsatser skal hentes ud som en mime attachement, eller også er det indlejret som et base64-kodet tekststreng

ITI-43 RetrieveDocumentSetResponse 
		<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>application/fhir+json</mimeType>
				<Document> TODO - indsæt base64 FHIR eksempel </Document>
			</DocumentResponse>
		</RetrieveDocumentSetResponse>

Oprettelse af Kommunale tilstande og indsatser

Oprettelse af Kommunale tilstande og indsatser foregår via dokumentregistreringsservicen (DROS), detaljeret dokumentation er beskrevet under: Dokumentregistreringsservice

Dokumentregistreringsservicen (DROS) skal tilgås gennem en afkoblingskomponent "DCC'en". DCC'en viderestiller kald til underliggende services, så der er ikke en WSDL for DCC'en. Se DCC Dokumentation for adgang til services gennem DCC'en.

Det er et krav at Dokumentregistreringsservicen (DROS) skal tilgås gennem afkoblingskomponenten


Kommunen opretter via DROS dokumenter med borgerens kommunale tilstande og indsatser, hvorefter de bliver udstillet via Dokumentdelingsservicen

TODO - Indsæt ITI-41 request via DROS, når XDS metadata er etableret

Ændring af Kommunale tilstande og indsatser

Kommunerne ændrer ikke dokumenter med borgerens kommunale tilstande og indsatser, der oprettes delta-dokumenter efterhånden som ændringer sker. Hvorefter de udstilles via Dokumentdelingsservice, der er klienternes ansvar at sammensætte data jvf. TODO - henvis til beskrivelse

Sletning af Kommunale tilstande og indsatser

Det er Sundheddatastyrelsens ansvar at slette delte dokumenter med kommunale tilstande og indsatser efter: TODO - indsæt ordlyd fra ændring af bekendtgørelse

Sikkerhed, roller og rettigheder

For adgang tilKommunale tilstande og indsatser 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

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.

Følgende roller anvendes i forbindelse med kommunale tilstande og indsatser.

Rollenavn

Rettighed

Notation som indsættes i SOSI IdKort ved udstedelse

nspSundAssistR2

Giver ret til at læse til Kommunale tilstande og indsatser

Giver også adgang til at læse andre dokumenter, der deles via dokumentdelingsinfrastrukturen jvf. Sundhedslovens §42a stk. 4

(Se overordnet dokumentation for nationale roller her: SEB - Sundhedsvæsenets Elektroniske Brugerstyring - Sundhedsdatastyrelsen Services (nsi.dk))

urn:dk:healthcare:national-federation-role:code:41002:value:SundAssistR2

 

En sundhedsfaglig uden sundhedsfaglig autorisation kan ikke have tilknyttet flere roller på samme tid - dette skal administreres via den lokale identifikations- og rettighedsstyring, eller via SEB

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 tilkommunale tilstande og indsatser.

For yderligere information, se Administrative forudsætninger for tilslutning under brugerstyring/trust

Håndtering af frabedelse og fuldmagt

Frabedelse af deling af sundhedsdata 
Borgeren kan have frabedt sig deling af at data, herunder Kommunale tilstande og indsatser, med andre parter i sundhedssektoren, i det tilfælde vil fejlkoden "Consent Filter Applied” blive returneret (se nedenstående xml eksempel for ITI-18 Dokumenter med frabedelse). Det betyder at borgeren enten har frabedt sig deling af data til den specifikke sundhedsperson, for data i et givet tidsrum, for data fra bestemte organisationer, eller i en kombination af disse. Klienten skal håndtere at der er angivet en frabedelse, og give sundhedspersonen mulighed for at få adgang til Kommunale tilstande og indsatser under specielle vilkår, TODO henvis til beskrivelse af forretningsregel for frabedelse

For adgang til data, hvor der er frabedt deling, kan klienten angive at der ønskes adgang til data uanset at der er frabedt deling for det. Det kan være på baggrund af enten et specifikt samtykke fra borgeren, eller at der nødvendigvis skal foretages et værdispring, eller at og så sende forespørgslen igen med “ConsentOverride” flaget sat til “True”. Der laves logning i dokumentdelingsinfrastrukturen der angiver at en frabedelse er tilsidesat. Klienten skal samtidig angive årsagen (Eksempelvis: eksplicit samtykke fra patienten for at få adgang til data) til at frabedelsen er tilsidesat i eget journalsystem, da der kan forventes at være opfølgning på tilsidesatte frabedelser.

Yderligere information omkring frabedelse af deling af sundhedsdata og forespørgsler via dokumentdeling kan ses i Brugervejledning til forespørgsler via DDS. Eksempel på ITI-18 fejlsvar for dokumenter der er lavet frabedelse på:  

ITI-18 Dokumenter med frabedelse 
<rs:RegistryError codeContext="urn:dk:nsi:Consent Filter Applied" errorCode="XDSRegistryError" severity="urn:oasis:names:tc:ebxml-regrep:ErrorSeverityType:Error"/>

Fuldmagt

Borgerportaler kan give 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 borgerportalen selv håndterer kontrol af fuldmagter.

Information angående angivelse af fuldmagter via dokumentdelingsservicen, kan ses i HSUID header dokumentation.

Ændringslog


0.22025-06-17Indsat link til KL's FHIR implementeringsgruideSDS
0.12025-05-13Udkast til teknisk implementeringsvejledning, mangler XDS-metadataSDS


  • No labels