Der kan forekomme ændringer i den tekniske implementeringsvejledning, da løsningen er ved at blive etableret. |
Denne vejledning beskriver de tekniske forretningsregler i forhold til at implementere visning af journalnotater fra praktiserende læger i et lokalt fagsystem eller en borgerportal. Vejledningen er tiltænkt forretningsarkitekter, systemarkitekter samt systemleverandører, således at disse kan vurdere hvordan visning af journalnotater kan implementeres i systemerne.
Det er vigtigt at forretningsreglerne og indhold forvisning af journalnotater læses i forbindelse med en kommende implementering. Den tekniske implementeringsvejledning kan ikke stå alene. |
På nationalt plan er der udarbejdet en indholdsprofil ud fra HL7's Fast Healthcare Interoperability Resources (FHIR) dokumenter, som beskriver udvekslingsformatet for journalnotater. Indholdsprofilen er forankret hos MedCom.
FHIR-dokumenterne for journalnotater forvaltes af Primærsektorens Leverandør Service Platform (PLSP), men udstilles via den nationale delingsinfrastruktur, således at borgerens journalnotater fra praktiserende læge kan fremfindes af sundhedsvæsenets aktører.
Aktører kan ligeledes, via deres fagsystemer anvende de standardiserede IHE XDS-snitflader til at hente borgernes journalnotater.
Den nationale delingsinfrastruktur udstilles gennem dokumentdeling- og dokumentregistreringsservices via standardiserede IHE XDS-snitflader. Disse er tilpasset den nationale sikkerhedsinfrastruktur, som bl.a. omhandler autorisation, samtykkekontrol, auditlogning etc.
Udveksling af journalnotater foregår via den nationale delingsinfrastruktur. Denne understøtter referencearkitekturen for deling af dokumenter og billeder.
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)
Figuren giver et overblik over de aktører som er i spil i relation til deling af journalnotater.
Den praktiserende læge: Lægen og /eller klinikpersonale udarbejder journalnotatet via klinikkens fagsystem. Journalnotatet deles med patientjournaldatabasen som er forvaltet af PLSP.
Borgere (Patienter): Borgere har læseadgang til egne journalnotater via sundhed.dk
Pårørende: Pårørende har læseadgang til borgerens journalnotater via sundhed.dk, hvis borgeren har tildelt den pårørende en læsefuldmagt via den fælles-offentlige fuldmagtsservice på borger.dk
Sundhedspersoner: Sundhedspersoner har adgang til borgeres journalnotater via Sundhedsjournalen på sundhed.dk, eller via eget fagsystem - afhængigt af lokal implementering
Sundhedsprofessionelle (uden sundhedsfaglig autorisation): Kan få adgang til borgerens journalnotater via lokal trustmodel, hvor parterne giver relevante medarbejdere adgang til at tilgå borgeres journalnotater via Sundhedsjournalen på sundhed.dk eller via eget fagsystem - afhængigt af lokal implementering
Først og fremmest skal man kende til det indholdsformat, der benyttes til journalnotater. Formatet er JSON og indholdet er specificeret som en dansk profil af FHIR.
Den danske FHIR-profil for journalnotater er forankret hos MedCom. Se under TODO: Indsæt link til MedCom's FHIR profil hvor både beskrivelse af standarden samt forskellige eksempler opbevares.
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 FHIR-dokumentet.
Tekniske forudsætninger
Se Tilslutning for at få adgang til NSP'en.
Journalnotater 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 til journalnotater skal sundhedspersoner have et STS-underskrevet SOSI-ID-kort på niveau 4 (medarbejder). Dette er også beskrevet under administrative forudsætninger. Borgeren har mulighed for at frabede sig deling af data, så journalnotater ikke kan deles med sundhedspersoner, samt at patienten har mulighed for at se hvem der har haft adgang til patientens journalnotater 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 deling af journalnotater er alle baseret på SOAP kald der understøtter DGWS.
Indholdsdelen af det 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:
For at søge efter en borgers journalnotater, 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å journalnotater, kan der søges på de værdier, der er angivet som XDS-metadata. Journalnotater benytter metadata profil version 1.0.x, der kan hentes på https://svn.medcom.dk/svn/releases/Standarder/IHE/DK_profil_metadata/.
Borgerens CPR-nummer (PatientId) samt journaldokumentets (Status) er påkrævede felter, som skal inkluderes i alle søgninger.
For journalnotater er der desuden følgende forretningsmæssige XDS-metdata, som skal anvendes i søgninger:
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.
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 det 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 journalnotater:
<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>('866144008^^2.16.840.1.113883.6.96')</Value>
</ValueList>
</Slot>
<Slot name="$XDSDocumentEntryFormatCode">
<ValueList>
<Value>('urn:ad:dk:medcom:ecn-v1.0:full^^1.2.208.184.100.10')</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 journalnotat dokumenterne. Der skal benyttes følgende til at udtrække de konkrete journalnotater:
TODO: Indsæt når infrastrukturen er etableret |
Bemærk: For at hente journalnotater 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 konkrete journalnotater:
Værdien hentes ud fra ...ExtrinsicObject/@home
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
<RetrieveDocumentSetRequest xmlns="urn:ihe:iti:xds-b:2007">
<DocumentRequest>
<HomeCommunityId>urn:oid:1.2.208.176.43210.8.20.11</HomeCommunityId>
<RepositoryUniqueId>1.2.208.176.43210.8.20.11</RepositoryUniqueId>
<DocumentUniqueId>1.2.208.184^e23d1b0d-f4cc-4b3e-9973-b2a499aa15ba</DocumentUniqueId>
</DocumentRequest>
</RetrieveDocumentSetRequest> |
Det svar der returneres, er patientens journalnotater, indeholdende de dataelementer der er beskrevet i MedComs standard. Se: https://medcomdk.github.io/dk-medcom-conditionlist/
Bemærk: Selve bodydelen af journalnotatet skal hentes ud som en mime attachement alternativt er det indlejret som et base64-kodet tekststreng.
<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>ewogICJyZXNvdXJjZVR5cGUiIDogIkJ1bmRsZSIsCiAgImlkIiA6ICJiOTkxZGNiNy02ZjJhLTRlNTYtOTZmOS02YjRiMjNjYjk0NzIiLAogICJtZXRhIiA6IHsKICAgICJwcm9maWxlIiA6IFsiaHR0cDovL21lZGNvbWZoaXIuZGsvaWcvY29uZGl0aW9ubGlzdC9TdHJ1Y3R1cmVEZWZpbml0aW9uL21lZGNvbS1jb25kaXRpb25saXN0LWJ1bmRsZSJdCiAgfSwKICAiaWRlbnRpZmllciIgOiB7CiAgICAic3lzdGVtIiA6ICJ1cm46aWV0ZjpyZmM6Mzk4NiIsCiAgICAidmFsdWUiIDogInVybjp1dWlkOjg1Y2NhNGE0LTMwZjItNDIzNi04MDdiLTc0ZDgzODJlM2RmYSIKICB9LAogICJ0eXBlIiA6ICJkb2N1bWVudCIsCiAgInRpbWVzdGFtcCIgOiAiMjAyNC0wNy0xMFQxMjo1MDowMCswMTowMCIsCiAgImVudHJ5IiA6IFt7CiAgICAiZnVsbFVybCIgOiAiaHR0cDovL21lZGNvbWZoaXIuZGsvaWcvY29uZGl0aW9ubGlzdC9Db21wb3NpdGlvbi9hMGU3ODNiNy0wMjdmLTQ1YzctYTQ4Ny0wNTg1Mzg3NmIxZDciLAogICAgInJlc291cmNlIiA6IHsKICAgICAgInJlc291cmNlVHlwZSIgOiAiQ29tcG9zaXRpb24iLAogICAgICAiaWQiIDogImEwZTc4M2I3LTAyN2YtNDVjNy1hNDg3LTA1ODUzODc2YjFkNyIsCiAgICAgICJtZXRhIiA6IHsKICAgICAgICAicHJvZmlsZSIgOiBbImh0dHA6Ly9tZWRjb21maGlyLmRrL2lnL2NvbmRpdGlvbmxpc3QvU3RydWN0dXJlRGVmaW5pdGlvbi9tZWRjb20tY29uZGl0aW9ubGlzdC1jb21wb3NpdGlvbiJdCiAgICAgIH0sCiAgICAgICJsYW5ndWFnZSIgOiAiZGEiLAogICAgICAidGV4dCIgOiB7CiAgICAgICAgInN0YXR1cyIgOiAiZ2VuZXJhdGVkIiwKICAgICAgICAiZGl2IiA6ICI8ZGl2IHhtbG5zPVwiaHR0cDovL3d3dy53My5vcmcvMTk5OS94aHRtbFwiIHhtbDpsYW5nPVwiZGFcIiBsYW5nPVwiZGFcIj48YSBuYW1lPVwiQ29tcG9zaXRpb25fYTBlNzgzYjctMDI3Zi00NWM3LWE0ODctMDU4NTM4NzZiMWQ3XCI+IDwvYT48cCBjbGFzcz1cInJlcy1oZWFkZXItaWRcIj48Yj5HZW5lcmF0ZWQgTmFycmF0aXZlOiBDb21wb3NpdGlvbiBhMGU3ODNiNy0wMjdmLTQ1YzctYTQ4Ny0wNTg1Mzg3NmIxZDc8L2I+PC9wPjxhIG5hbWU9XCJhMGU3ODNiNy0wMjdmLTQ1YzctYTQ4Ny0wNTg1Mzg3NmIxZDdcIj4gPC9hPjxhIG5hbWU9XCJoY2EwZTc4M2I3LTAyN2YtNDVjNy1hNDg3LTA1ODUzODc2YjFkN1wiPiA8L2E+PGEgbmFtZT1cImEwZTc4M2I3LTAyN2YtNDVjNy1hNDg3LTA1ODUzODc2YjFkNy1lbi1VU1wiPiA8L2E+PGRpdiBzdHlsZT1cImRpc3BsYXk6IGlubGluZS1ibG9jazsgYmFja2dyb3VuZC1jb2xvcjogI2Q5ZTBlNzsgcGFkZGluZzogNnB4OyBtYXJnaW46IDRweDsgYm9yZGVyOiAxcHggc29saWQgIzhkYTFiNDsgYm9yZGVyLXJhZGl1czogNXB4OyBsaW5lLWhlaWdodDogNjAlXCI+PHAgc3R5bGU9XCJtYXJnaW4tYm90dG9tOiAwcHhcIj5MYW5ndWFnZTogZGE8L3A+PHAgc3R5bGU9XCJtYXJnaW4tYm90dG9tOiAwcHhcIj5Qcm9maWxlOiA8YSBocmVmPVwiU3RydWN0dXJlRGVmaW5pdGlvbi1tZWRjb20tY29uZGl0aW9ubGlzdC1jb21wb3NpdGlvbi5odG1sXCI+TWVkQ29tQ29uZGl0aW9uTGlzdENvbXBvc2l0aW9uPC9hPjwvcD48L2Rpdj48cD48Yj5zdGF0dXM8L2I+OiBGaW5hbDwvcD48cD48Yj50eXBlPC9iPjogPHNwYW4gdGl0bGU9XCJDb2Rlczp7aHR0cDovL2xvaW5jLm9yZyAxMTQ1MC00fVwiPlByb2JsZW0gbGlzdCAtIFJlcG9ydGVkPC9zcGFuPjwvcD48cD48Yj5kYXRlPC9iPjogMjAyNC0wNy0xMCAxMjo1MDowMCswMTAwPC9wPjxwPjxiPmF1dGhvcjwvYj46IDxhIGhyZWY9XCJPcmdhbml6YXRpb24tMTg5NWM0NjktMjEyYi00NWY0LTg2NjYtYzVjN2MxNDEzMzgwLmh0bWxcIj5Pcmdhbml6YXRpb24gTWVkQ29tIFRlc3RjZW50ZXI8L2E+PC9wPjxwPjxiPnRpdGxlPC9iPjogRGlhZ25vc2VvdmVyc2lndCBmb3IgMjUwOTQ3OTk4OTwvcD48cD48Yj5jb25maWRlbnRpYWxpdHk8L2I+OiBub3JtYWw8L3A+PC9kaXY+IgogICAgICB9LAogICAgICAic3RhdHVzIiA6ICJmaW5hbCIsCiAgICAgICJ0eXBlIiA6IHsKICAgICAgICAiY29kaW5nIiA6IFt7CiAgICAgICAgICAic3lzdGVtIiA6ICJodHRwOi8vbG9pbmMub3JnIiwKICAgICAgICAgICJjb2RlIiA6ICIxMTQ1MC00IiwKICAgICAgICAgICJkaXNwbGF5IiA6ICJQcm9ibGVtIGxpc3QgLSBSZXBvcnRlZCIKICAgICAgICB9XQogICAgICB9LAogICAgICAic3ViamVjdCIgOiB7CiAgICAgICAgInJlZmVyZW5jZSIgOiAiUGF0aWVudC9kNjVjZDhkYi00NTIwLTQyNjQtODdiZS1hNWZkMDFmYjk3NjIiCiAgICAgIH0sCiAgICAgICJkYXRlIiA6ICIyMDI0LTA3LTEwVDEyOjUwOjAwKzAxOjAwIiwKICAgICAgImF1dGhvciIgOiBbewogICAgICAgICJyZWZlcmVuY2UiIDogIk9yZ2FuaXphdGlvbi8xODk1YzQ2OS0yMTJiLTQ1ZjQtODY2Ni1jNWM3YzE0MTMzODAiCiAgICAgIH1dLAogICAgICAidGl0bGUiIDogIkRpYWdub3Nlb3ZlcnNpZ3QgZm9yIDI1MDk0Nzk5ODkiLAogICAgICAiY29uZmlkZW50aWFsaXR5IiA6ICJOIiwKICAgICAgInNlY3Rpb24iIDogW3sKICAgICAgICAidGV4dCIgOiB7CiAgICAgICAgICAic3RhdHVzIiA6ICJnZW5lcmF0ZWQiLAogICAgICAgICAgImRpdiIgOiAiPGRpdiB4bWxucz1cImh0dHA6Ly93d3cudzMub3JnLzE5OTkveGh0bWxcIj48cCBjbGFzcz1cInJlcy1oZWFkZXItaWRcIj48Yj5HZW5lcmF0ZWQgTmFycmF0aXZlOiBDb25kaXRpb24gMTdlM2IwYzAtMDQ5Ny00OWUxLTljZjEtNGUxZWVhOGZjNzlkPC9iPjwvcD48YSBuYW1lPVwiMTdlM2IwYzAtMDQ5Ny00OWUxLTljZjEtNGUxZWVhOGZjNzlkXCI+PC9hPjxhIG5hbWU9XCJoYzE3ZTNiMGMwLTA0OTctNDllMS05Y2YxLTRlMWVlYThmYzc5ZFwiPiA8L2E+PGEgbmFtZT1cIjE3ZTNiMGMwLTA0OTctNDllMS05Y2YxLTRlMWVlYThmYzc5ZC1lbi1VU1wiPjwvYT48cD48Yj5jYXRlZ29yeTwvYj46IDxzcGFuIHRpdGxlPVwiQ29kZXM6e2h0dHA6Ly90ZXJtaW5vbG9neS5obDcub3JnL0NvZGVTeXN0ZW0vY29uZGl0aW9uLWNhdGVnb3J5IHByb2JsZW0tbGlzdC1pdGVtfVwiPlByb2JsZW0gTGlzdCBJdGVtPC9zcGFuPiwgPHNwYW4gdGl0bGU9XCJDb2Rlczp7aHR0cDovL3Nub21lZC5pbmZvL3NjdCAxNTI0MDAwN31cIj5DdXJyZW50PC9zcGFuPjwvcD48cD48Yj5jb2RlPC9iPjogPHNwYW4gdGl0bGU9XCJDb2Rlczp7dXJuOm9pZDoxLjIuMjA4LjE3Ni4yLjQuMTIgREYzMjl9LCB7dXJuOm9pZDoxLjIuMjA4LjE3Ni4yLjMxIFA3Nn1cIj5EZXByZXNzaW9uPC9zcGFuPjwvcD48cD48Yj5zdWJqZWN0PC9iPjogPGEgaHJlZj1cIlBhdGllbnQtZDY1Y2Q4ZGItNDUyMC00MjY0LTg3YmUtYTVmZDAxZmI5NzYyLmh0bWxcIj5OaWVscyBUZXN0IFZlbmRlbGJvZSAob2ZmaWNpYWwpIE1hbGUsIERvQjogMTk3NC0wMS0zMCAoIHVybjpvaWQ6MS4yLjIwOC4xNzYuMS4yIzMwMDE3NDk5OTUpPC9hPjwvcD48cD48Yj5yZWNvcmRlZERhdGU8L2I+OiAyMDI0LTAxLTE2PC9wPjwvZGl2PiIKICAgICAgICB9LAogICAgICAgICJlbnRyeSIgOiBbewogICAgICAgICAgInJlZmVyZW5jZSIgOiAiQ29uZGl0aW9uLzE3ZTNiMGMwLTA0OTctNDllMS05Y2YxLTRlMWVlYThmYzc5ZCIKICAgICAgICB9XQogICAgICB9XQogICAgfQogIH0sCiAgewogICAgImZ1bGxVcmwiIDogImh0dHA6Ly9tZWRjb21maGlyLmRrL2lnL2NvbmRpdGlvbmxpc3QvUGF0aWVudC9kNjVjZDhkYi00NTIwLTQyNjQtODdiZS1hNWZkMDFmYjk3NjIiLAogICAgInJlc291cmNlIiA6IHsKICAgICAgInJlc291cmNlVHlwZSIgOiAiUGF0aWVudCIsCiAgICAgICJpZCIgOiAiZDY1Y2Q4ZGItNDUyMC00MjY0LTg3YmUtYTVmZDAxZmI5NzYyIiwKICAgICAgIm1ldGEiIDogewogICAgICAgICJwcm9maWxlIiA6IFsiaHR0cDovL21lZGNvbWZoaXIuZGsvaWcvZG9jdW1lbnQvU3RydWN0dXJlRGVmaW5pdGlvbi9tZWRjb20tZG9jdW1lbnQtcGF0aWVudCJdCiAgICAgIH0sCiAgICAgICJ0ZXh0IiA6IHsKICAgICAgICAic3RhdHVzIiA6ICJnZW5lcmF0ZWQiLAogICAgICAgICJkaXYiIDogIjxkaXYgeG1sbnM9XCJodHRwOi8vd3d3LnczLm9yZy8xOTk5L3hodG1sXCI+PGEgbmFtZT1cIlBhdGllbnRfZDY1Y2Q4ZGItNDUyMC00MjY0LTg3YmUtYTVmZDAxZmI5NzYyXCI+IDwvYT48cCBjbGFzcz1cInJlcy1oZWFkZXItaWRcIj48Yj5HZW5lcmF0ZWQgTmFycmF0aXZlOiBQYXRpZW50IGQ2NWNkOGRiLTQ1MjAtNDI2NC04N2JlLWE1ZmQwMWZiOTc2MjwvYj48L3A+PGEgbmFtZT1cImQ2NWNkOGRiLTQ1MjAtNDI2NC04N2JlLWE1ZmQwMWZiOTc2MlwiPiA8L2E+PGEgbmFtZT1cImhjZDY1Y2Q4ZGItNDUyMC00MjY0LTg3YmUtYTVmZDAxZmI5NzYyXCI+IDwvYT48YSBuYW1lPVwiZDY1Y2Q4ZGItNDUyMC00MjY0LTg3YmUtYTVmZDAxZmI5NzYyLWVuLVVTXCI+IDwvYT48cCBzdHlsZT1cImJvcmRlcjogMXB4ICM2NjFhZmYgc29saWQ7IGJhY2tncm91bmQtY29sb3I6ICNlNmU2ZmY7IHBhZGRpbmc6IDEwcHg7XCI+TmllbHMgVGVzdCBWZW5kZWxib2UgKG9mZmljaWFsKSBNYWxlLCBEb0I6IDE5NzQtMDEtMzAgKCB1cm46b2lkOjEuMi4yMDguMTc2LjEuMiMzMDAxNzQ5OTk1KTwvcD48aHIvPjwvZGl2PiIKICAgICAgfSwKICAgICAgImlkZW50aWZpZXIiIDogW3sKICAgICAgICAic3lzdGVtIiA6ICJ1cm46b2lkOjEuMi4yMDguMTc2LjEuMiIsCiAgICAgICAgInZhbHVlIiA6ICIzMDAxNzQ5OTk1IgogICAgICB9XSwKICAgICAgIm5hbWUiIDogW3sKICAgICAgICAidXNlIiA6ICJvZmZpY2lhbCIsCiAgICAgICAgImZhbWlseSIgOiAiVmVuZGVsYm9lIiwKICAgICAgICAiZ2l2ZW4iIDogWyJOaWVscyIsCiAgICAgICAgIlRlc3QiXQogICAgICB9XSwKICAgICAgImdlbmRlciIgOiAibWFsZSIsCiAgICAgICJiaXJ0aERhdGUiIDogIjE5NzQtMDEtMzAiCiAgICB9CiAgfSwKICB7CiAgICAiZnVsbFVybCIgOiAiaHR0cDovL21lZGNvbWZoaXIuZGsvaWcvY29uZGl0aW9ubGlzdC9Pcmdhbml6YXRpb24vMTg5NWM0NjktMjEyYi00NWY0LTg2NjYtYzVjN2MxNDEzMzgwIiwKICAgICJyZXNvdXJjZSIgOiB7CiAgICAgICJyZXNvdXJjZVR5cGUiIDogIk9yZ2FuaXphdGlvbiIsCiAgICAgICJpZCIgOiAiMTg5NWM0NjktMjEyYi00NWY0LTg2NjYtYzVjN2MxNDEzMzgwIiwKICAgICAgIm1ldGEiIDogewogICAgICAgICJwcm9maWxlIiA6IFsiaHR0cDovL21lZGNvbWZoaXIuZGsvaWcvY29uZGl0aW9ubGlzdC9TdHJ1Y3R1cmVEZWZpbml0aW9uL21lZGNvbS1jb25kaXRpb25saXN0LW9yZ2FuaXphdGlvbiJdCiAgICAgIH0sCiAgICAgICJ0ZXh0IiA6IHsKICAgICAgICAic3RhdHVzIiA6ICJnZW5lcmF0ZWQiLAogICAgICAgICJkaXYiIDogIjxkaXYgeG1sbnM9XCJodHRwOi8vd3d3LnczLm9yZy8xOTk5L3hodG1sXCI+PGEgbmFtZT1cIk9yZ2FuaXphdGlvbl8xODk1YzQ2OS0yMTJiLTQ1ZjQtODY2Ni1jNWM3YzE0MTMzODBcIj4gPC9hPjxwIGNsYXNzPVwicmVzLWhlYWRlci1pZFwiPjxiPkdlbmVyYXRlZCBOYXJyYXRpdmU6IE9yZ2FuaXphdGlvbiAxODk1YzQ2OS0yMTJiLTQ1ZjQtODY2Ni1jNWM3YzE0MTMzODA8L2I+PC9wPjxhIG5hbWU9XCIxODk1YzQ2OS0yMTJiLTQ1ZjQtODY2Ni1jNWM3YzE0MTMzODBcIj4gPC9hPjxhIG5hbWU9XCJoYzE4OTVjNDY5LTIxMmItNDVmNC04NjY2LWM1YzdjMTQxMzM4MFwiPiA8L2E+PGEgbmFtZT1cIjE4OTVjNDY5LTIxMmItNDVmNC04NjY2LWM1YzdjMTQxMzM4MC1lbi1VU1wiPiA8L2E+PHA+PGI+aWRlbnRpZmllcjwvYj46IDxjb2RlPnVybjpvaWQ6MS4yLjIwOC4xNzYuMS4xPC9jb2RlPi8zMjUzODEwMDAwMTYwMDg8L3A+PHA+PGI+bmFtZTwvYj46IE1lZENvbSBUZXN0Y2VudGVyPC9wPjwvZGl2PiIKICAgICAgfSwKICAgICAgImlkZW50aWZpZXIiIDogW3sKICAgICAgICAic3lzdGVtIiA6ICJ1cm46b2lkOjEuMi4yMDguMTc2LjEuMSIsCiAgICAgICAgInZhbHVlIiA6ICIzMjUzODEwMDAwMTYwMDgiCiAgICAgIH1dLAogICAgICAibmFtZSIgOiAiTWVkQ29tIFRlc3RjZW50ZXIiCiAgICB9CiAgfSwKICB7CiAgICAiZnVsbFVybCIgOiAiaHR0cDovL21lZGNvbWZoaXIuZGsvaWcvY29uZGl0aW9ubGlzdC9Db25kaXRpb24vMTdlM2IwYzAtMDQ5Ny00OWUxLTljZjEtNGUxZWVhOGZjNzlkIiwKICAgICJyZXNvdXJjZSIgOiB7CiAgICAgICJyZXNvdXJjZVR5cGUiIDogIkNvbmRpdGlvbiIsCiAgICAgICJpZCIgOiAiMTdlM2IwYzAtMDQ5Ny00OWUxLTljZjEtNGUxZWVhOGZjNzlkIiwKICAgICAgIm1ldGEiIDogewogICAgICAgICJwcm9maWxlIiA6IFsiaHR0cDovL21lZGNvbWZoaXIuZGsvaWcvY29uZGl0aW9ubGlzdC9TdHJ1Y3R1cmVEZWZpbml0aW9uL21lZGNvbS1jb25kaXRpb25saXN0LWNvbmRpdGlvbiJdCiAgICAgIH0sCiAgICAgICJ0ZXh0IiA6IHsKICAgICAgICAic3RhdHVzIiA6ICJnZW5lcmF0ZWQiLAogICAgICAgICJkaXYiIDogIjxkaXYgeG1sbnM9XCJodHRwOi8vd3d3LnczLm9yZy8xOTk5L3hodG1sXCI+PGEgbmFtZT1cIkNvbmRpdGlvbl8xN2UzYjBjMC0wNDk3LTQ5ZTEtOWNmMS00ZTFlZWE4ZmM3OWRcIj4gPC9hPjxwIGNsYXNzPVwicmVzLWhlYWRlci1pZFwiPjxiPkdlbmVyYXRlZCBOYXJyYXRpdmU6IENvbmRpdGlvbiAxN2UzYjBjMC0wNDk3LTQ5ZTEtOWNmMS00ZTFlZWE4ZmM3OWQ8L2I+PC9wPjxhIG5hbWU9XCIxN2UzYjBjMC0wNDk3LTQ5ZTEtOWNmMS00ZTFlZWE4ZmM3OWRcIj4gPC9hPjxhIG5hbWU9XCJoYzE3ZTNiMGMwLTA0OTctNDllMS05Y2YxLTRlMWVlYThmYzc5ZFwiPiA8L2E+PGEgbmFtZT1cIjE3ZTNiMGMwLTA0OTctNDllMS05Y2YxLTRlMWVlYThmYzc5ZC1lbi1VU1wiPiA8L2E+PHA+PGI+Y2F0ZWdvcnk8L2I+OiA8c3BhbiB0aXRsZT1cIkNvZGVzOntodHRwOi8vdGVybWlub2xvZ3kuaGw3Lm9yZy9Db2RlU3lzdGVtL2NvbmRpdGlvbi1jYXRlZ29yeSBwcm9ibGVtLWxpc3QtaXRlbX1cIj5Qcm9ibGVtIExpc3QgSXRlbTwvc3Bhbj4sIDxzcGFuIHRpdGxlPVwiQ29kZXM6e2h0dHA6Ly9zbm9tZWQuaW5mby9zY3QgMTUyNDAwMDd9XCI+Q3VycmVudDwvc3Bhbj48L3A+PHA+PGI+Y29kZTwvYj46IDxzcGFuIHRpdGxlPVwiQ29kZXM6e3VybjpvaWQ6MS4yLjIwOC4xNzYuMi40LjEyIERGMzI5fSwge3VybjpvaWQ6MS4yLjIwOC4xNzYuMi4zMSBQNzZ9XCI+RGVwcmVzc2lvbjwvc3Bhbj48L3A+PHA+PGI+c3ViamVjdDwvYj46IDxhIGhyZWY9XCJQYXRpZW50LWQ2NWNkOGRiLTQ1MjAtNDI2NC04N2JlLWE1ZmQwMWZiOTc2Mi5odG1sXCI+TmllbHMgVGVzdCBWZW5kZWxib2UgKG9mZmljaWFsKSBNYWxlLCBEb0I6IDE5NzQtMDEtMzAgKCB1cm46b2lkOjEuMi4yMDguMTc2LjEuMiMzMDAxNzQ5OTk1KTwvYT48L3A+PHA+PGI+cmVjb3JkZWREYXRlPC9iPjogMjAyNC0wMS0xNjwvcD48L2Rpdj4iCiAgICAgIH0sCiAgICAgICJjYXRlZ29yeSIgOiBbewogICAgICAgICJjb2RpbmciIDogW3sKICAgICAgICAgICJzeXN0ZW0iIDogImh0dHA6Ly90ZXJtaW5vbG9neS5obDcub3JnL0NvZGVTeXN0ZW0vY29uZGl0aW9uLWNhdGVnb3J5IiwKICAgICAgICAgICJjb2RlIiA6ICJwcm9ibGVtLWxpc3QtaXRlbSIKICAgICAgICB9XQogICAgICB9LAogICAgICB7CiAgICAgICAgImNvZGluZyIgOiBbewogICAgICAgICAgInN5c3RlbSIgOiAiaHR0cDovL3Nub21lZC5pbmZvL3NjdCIsCiAgICAgICAgICAiY29kZSIgOiAiMTUyNDAwMDciCiAgICAgICAgfV0KICAgICAgfV0sCiAgICAgICJjb2RlIiA6IHsKICAgICAgICAiY29kaW5nIiA6IFt7CiAgICAgICAgICAic3lzdGVtIiA6ICJ1cm46b2lkOjEuMi4yMDguMTc2LjIuNC4xMiIsCiAgICAgICAgICAiY29kZSIgOiAiREYzMjkiCiAgICAgICAgfSwKICAgICAgICB7CiAgICAgICAgICAic3lzdGVtIiA6ICJ1cm46b2lkOjEuMi4yMDguMTc2LjIuMzEiLAogICAgICAgICAgImNvZGUiIDogIlA3NiIKICAgICAgICB9XSwKICAgICAgICAidGV4dCIgOiAiRGVwcmVzc2lvbiIKICAgICAgfSwKICAgICAgInN1YmplY3QiIDogewogICAgICAgICJyZWZlcmVuY2UiIDogIlBhdGllbnQvZDY1Y2Q4ZGItNDUyMC00MjY0LTg3YmUtYTVmZDAxZmI5NzYyIgogICAgICB9LAogICAgICAicmVjb3JkZWREYXRlIiA6ICIyMDI0LTAxLTE2IgogICAgfQogIH1dCn0=</Document> </DocumentResponse> </RetrieveDocumentSetResponse> |
Det er patientens praktiserende læge som opretter borgerens journalnotater, hvorefter de udstilles via PLSP Indeks.
Det er ikke muligt for andre parter, end de praktiserende læger, at oprette journalnotater. |
Det er praktiserende læge som redigerer borgerens journalnotater, hvorefter den udstilles via PLSP Indeks. PLSP Indeks udstiller journalnotater som en dynamisk (on-demand) dokumentkilde. Det betyder at det altid er dee sidste opdaterede journalnotater som hentes.
Det er ikke muligt for andre parter, end de praktiserende læger, at ændre journalnotater. |
Det er praktiserende læge som sletter borgerens journalnotater, hvorefter den ikke længere udstilles via PLSP Indeks
Det er ikke muligt for andre parter, end de praktiserende læger, at slette en borgers journalnotater. |
For adgang til journalnotater 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 journalnotater.
Rollenavn | Rettighed | Notation som indsættes i SOSI IdKort ved udstedelse |
nspSundAssistR2 | Giver ret til at læse journalnotater 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 til journalnotater.
Se Tilslutning under brugerstyring/trust for yderligere information.
Borgeren kan have frabedt sig deling af at data, herunderjournalnotater, 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 journalnotater under specielle vilkår, se forretningsregel #6 under: Forretningsregler for journalnotater
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å:
<rs:RegistryError codeContext="urn:dk:nsi:Consent Filter Applied" errorCode="XDSRegistryError" severity="urn:oasis:names:tc:ebxml-regrep:ErrorSeverityType:Error"/> |
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. 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.
| Version | Dato | Ændret | Ændret af |
|---|---|---|---|
| 0.1 | 2026-04-216 | Første udgave (midlertidig, da løsningen endnu ikke er etableret | SDS |