INDHOLD

Beskrivelse

Dokumentdelingsservicen fungerer som et adgangspunkt til dokumentdeling baseret på profiler under Cross-Enterprise Document Sharing (XDS) som defineret af sammenslutningen Integrating the Healthcare Enterprise (IHE). XDS er baseret på, at dokumentkilder i et index registrerer metadata om dokumenter, de kan stille til rådighed.En dokumentanvender kan foretage opslag på indexet og ud fra returnerede metadata, foretage indhentning af dokumenter til efterfølgende visning og/eller udtræk af informationer.
Dokument Registrering Servicen (DRS) håndterer oprettelsen af nye aftale-dokumenter i det centrale XDS repository.

Support ansvarlig: Kvalitets IT 

NSP: Dokumentdelingsservice (DDS)Formålet med Dokumentdelingsservicen er at tilvejebringe adgang til data om patienten fra forskellige datakilder via et indeks. Anvendersystemer (f.eks. Sundhedsjournalen) kan i indekset søge efter informationer om data på en given patient (metadata) og præsentere en oversigt over disse for sundhedsfaglige brugere og borgere. Såfremt en sundhedsfaglig bruger eller borger ønsker at få adgang til de bagvedliggende detaljerede patientdata, skal indekset levere tilstrækkelig information om, hvor og hvordan dette kan hentes. Hvis det system, der er kilde til data har etableret en standardiseret snitflade til at hente disse patientdata, vil den sundhedsfaglige bruger kunne hente disse, ligesom borgeren umiddelbart vil kunne hente data via sundhed.dk

Der foretages:
- Sikkerheds verifikation gennem STS servicen
- Whitelist kontrol gennem DDS documentsources.whitelist_config
- Samtykke verifikation gennem Consent verification servicen
- MinLog registreringer af al access
- Behandlingsrelation kontrol mellem borger og sundhedsfagling gennem BRS servicen
- Fra on-demand dokumentkilden Fælles Stamkort servicen (FSK) hentes data fra en række registre i NSP regi
- Der foretages indhenting af dokumenter fra andre kilder via proxies:
+ aftaleoversigt (AO) fra Bookplan
+ Antikoagulation (AK) hentes i Laboratoriedatabanken
+ Laboratoriesvar (SXA) fra Laboratoriedatabanken

Forretningsanvendelse

^^Tilbage til toppen^^

Relaterede registre og services

• B02 Autorisations registret
• E08 Behandlingsrelationsservice (BRS)
• B26 SOR-FMK
• D00 Cross-Enterprise Document Sharing (XDS)
• D03 Aftaleoversigt adaptere (DDS-AO)
• D04 AntiKoagulering adaptere (DDS-AK)
• D05 Laboratoriesvar eksponering adaptere (DDS-SXA)
• D06 FSK Registry adapter (DDS-FSK)
• E01 Min Spærring (Samtykke)
• E03 Minlog
• E05 STS (Security Token Service)
• F01 Fælles Stamkort (FSK)

Applikationsbeskrivelse

^^Tilbage til toppen^^

DDS dokumentdeling kalder følgende services og skal være godkendt på whiteliste til at kalde disse services.
- Sikkerheds verifikation gennem STS servicen
- Min Spærring, Samtykkeverifikation: Samtykkeverifikationsservicen kaldes for at filtrere de dokumenter fra, som sundhedspersonen ikke har samtykke til at se. Listen af dokumenter fremsøges i DDS-document registry, samt i externe registries (via adaptere som AK, SXA, AO, FSK). Filtreringen er baseret på de positive/negative samtykker borgeren har oprettet.
- Behandlingsrelation (BRS): BRS giver mulighed for at forespørge om en given sundhedsperson har en behandlingsrelation til en given borger. Aktivering af kald er konfigurerbart via properties-filen for DDS Registry.
- MinLogRegistration: En sundhedspersons adgang eller forsøg på adgang til borgers oplysninger, registreres i MinLogRegistration-servicen.

Desuden benyttes følgende tabeller:
- DDS-documentregistry: konfiguration af hvilke dokument-indeks som har Metadata for de registrede udstillede dokumenter. Bruges af DDS Registry
- DDS-documentsources: Mapning mellem angivet OID i udtræk til aktuelt service endpoint for XDS dokument kilde. Bruges af DDS Repository
- DDS-documentsources.whitelist_config: Alle CVR-numre i databasen, der skal gælde for DDS Registry, skal have ’service key’ sat til ’dk.nsi.ddsregistry’ og for DDS Repository ’dk.nsi.ddsrepository’
- autorisation: Anvender stamdata-tabellen autreg, der indeholder CPR-nummer og autorisationsnummer for sundhedspersoner med gyldige og gældende dansk autorisation opført i Sundhedsstyrelsens autorisationsregister.
- sor: Mapning mellem SOR-koder og SHAK-koder/ydernumre, som anvendes til opslag i forbindelse med samtykkeverifikationer.

- Udover indhenting af dokumenter fra det centrale aftale XDS foretages indhentning også fra andre kilder via adaptere:
+ Aftaleoversigt (AO) fra Bookplan (region Midt og Nord)
+ Antikoagulation (AK) hentes i Laboratoriedatabanken
+ Laboratoriesvar (SXA) fra Laboratoriedatabanken
+ Fra on-demand dokumentkilden Fælles Stamkort servicen (FSK) hentes data fra en række registre i NSP regi (Her er "repository adapteren" selve FSK-servicen, som kun kan kaldes af DDS Repository)

Dokumentdelingsservicens snitflader anvender Den Gode Webservice (DGWS) eller IDWS til autentificering og autorisering, dvs. der anvendes OCES II certifikater. Hvorvidt anvender, der benytter DGWS snitfladen, skal benytte Virksomhedscertifikat (VOCES), Funktionscertifikat (FOCES) eller Medarbejdercertifikat (MOCES) vil indgå i den anvenderaftale, der aftales mellem anvender og Sundhedsdatastyrelsen. I tillæg til DGWS eller IDWS skal der ved opslag på metadata og indhentning af dokumenter vedlægges yderligere beskrivelser af konteksten. Dette sker via HSUID headeren. Informationer fra DGWS og kontekstbeskrivelsen benytter Dokumentdelingsservicen til at foretage kontroller, herunder kontrol af patientens samtykker.

En dokumentanvender kan foretage opslag på Dokumentdelingsservicen ved at benytte søgeparametre herunder patient-id. Ved opslaget returneres 0, 1 eller flere dokumentmetadata om dokumenter vedrørende patienten afhængig af, hvad dokumentkilder har registreret af dokumenter. Disse dokumentmetadata kan dokumentanvender efterfølgende benytte til at indhente et eller flere af dokumenterne fra Dokumentdelingsservicen.
En dokumentkilde kan registrere metadata i et index tilknyttet Dokumentdelingsservicen. Ved at have tilkoblet dokumentkildens snitflade til indhentning af dokumenter, kan en dokumentkilde tilbyde sine dokumenter til anvendere af Dokumentdelingsservicen.

Service Deklaration: Særlige begrænsninger ift. anvendelse af Dokumentdelingsservicen (DDS)
---------------------------------------------------------------------------------------------------
Forud for rekvirering af dokumenter gennem DDS’ens repository-service ReceiveDocumentSet (ITI-43) forpligter anvender sig til at gennemføre et kald til DDS’ens registry-service RegistryStoredQuery (ITI-18). I kaldet mod DDS’ens repositoryservice må der udelukkende anvendes informationer (herunder dokument-id’er) fra svaret fra DDS’ens registryservice, idet registryservicen har foretaget de nødvendige filtreringer i forhold til patientens frabedelser og samtykker. Der må højst være 10 minutter mellem disse kald, begge kald skal udføres af samme bruger, og begge kald skal have samme (men unikke) ‘flowID’

Der findes to endpoints med kald formelt specificeret i tilhørende WDSL:
+ http://[host]:[port]/ddsregistry https://wsdl.nspop.dk/ddsregistry?wsdl
+ http://[host]:[port]/ddsrepository https://wsdl.nspop.dk/ddsrepository?wsdl

DDS Repository operationer (de faktiske dokumenter):
---------------------------------------------------------
ITI-43 RetrieveDocumentSet: autorisation, samtykke kontrol og indhentning af faktiske dokument(er) fra dokumentkilde(r)
(ITI-41 Provide and Register Document Set: udstilles fra Dokument Registrerings servicen (DRS))

DDS Registry operationer: (dokument metadata relateret CPR-nr):
---------------------------------------------------------------------
ITI-18 RegistryStoredQuery: operation til fremsøgning af metadata i registry.
ITI-42 RegisterDocumentSetB: Registrering af statiske dokumenter
ITI-57 UpdateDocumentSet: Benyttes til opdatering af registrerede metadata (f.eks til skift af status på et dokument (som APPROVED -> DEPRECATED) )
ITI-61 RegisterOnDemandDocumentEntry: Registrering af on-demand-dokumenter

Ved kald af webservice-operationen Reqistry Stored Query (ITI-18) på DDS Registry gennemføres følgende:
----------------------------------------------------------------------------------------------------------------
- Logning i Min-log-servicen
- fremsøgning af metadata gennem IHE Repository, der med produktet Healthshare er en implementation af netop IHE registry ("Opentext XDS Registry"), samt de tilknyttede adaptere til andre dokument-indexes
- Igangsættelse af check af behandlingsrelation mellem borger og sundhedsfaglig
- Filtrering af det returnerede svar ved verifikation af at borgerens registrerede samtykker ikke forhindrer at metadata vises
- Mulighed for forceret fremsøgning (værdispring), som tilsidesætter check af samtykke

Ved kald af webservice-operationen Retrieve Document Set (ITI-43) på DDS Repository gennemføres følgende:
--------------------------------------------------------------------------------------------------------------------
- Autentificering og autorisation af anvendersystemet
- Audit-logning af brugers (forsøg på) udtræk af dokumenter om patient
- Autorisation af bruger
- Logning i værdisprings-log, hvis bruger er sundhedsperson og foretager værdispring
- Logning i Min-log-servicen, hvis bruger er sundhedsperson
- Kontrol af samtykke mod sundhedsperson, hvis bruger er sundhedsperson og værdispring ikke er foretaget. Er der samtykke(r) mod sundhedspersonen returneres svar med notits herom.
- Bestemmelse af dokumentkildes webservice-endpoint
- Indhentning af dokument(er) fra dokumentkilde: det centrale OpenXDS Repository, eller gennem de tilknyttede adaptere til andre dokument-kilder
- Kontrol af data-specifikke samtykker, hvis bruger er sundhedsperson og værdispring ikke er foretaget.
- Denne kontrol er betinget af, at dokumentkilden kontrollerer data-specifikke samtykker. Derved foretages evt. frafiltrering af dokumenter/dokument-dele med tilhørende notits herom i svaret
- Igangsættelse af check af behandlingsrelation mellem borger og sundhedsperson, hvis bruger er sundhedsperson.

Ved kald af webservice-operationen RegisterDocumentSetB (ITI-42 statistiske dokumenter) og RegisterOnDemandDocumentEntry (ITI-61 on-Demand dokumenter) på DDS Registry gennemføres følgende:
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
- Requested viderestilles til IHE register-instansen IHE Registry (Opentext XDS Registry)
- Er registrering i IHE Repository succesfuld foretages audit-logning af hvilket system, der har registreret metadata om en borger (dette foretages for alle de borgere, der indgår metadata om).

Datastruktur, Intern register: Dokumentdeling (DDS)

^^Tilbage til toppen^^

Register properties:

En dokumentkilde kan registrere metadata i et index tilknyttet Dokumentdelingsservicen.
Ved at have tilkoblet dokumentkildens snitflade til indhentning af dokumenter, kan en dokumentkilde tilbyde sine dokumenter til anvendere af Dokumentdelingsservicen.
Database: documentsources

Entitetsbeskrivelser

documentregistry

^^Tilbage til toppen^^

I documentregistry er der konfiguration af hvilke dokument-indeks som har Metadata for de registrede udstillede dokumenter. Anvendes af DDS servicen (DDS Registry)

Objektet rummer følgende information:
-------------------------------------------
`documentregistryid` -- Entydig document ID
`documentregistryserviceurl` -- Adressen for indeksets webservice-endpoint givet som URI.
`documentregistryfriendlyname` -- Et relativt brugervenligt navn for indekset, der indgår i fejlbeskeden, når indekset ikke svarer rettidigt eller ikke kan tilgås.
`documentregistryservicenamespace` -- Namespace anvendt af indeksets webservice-endpoint. Standard-værdien er urn:ihe:iti:xds-b:2007.
`documentregistrylocal` -- Hvorvidt indekset er lokalt eller ej. Dokumentdelingsservicen skal have præcis et lokalt indeks, der benyttes ved registrering af dokumenter. Værdien 1 anfører lokalt indeks, 0 ellers.
`documentregistrytimeoutvalue` -- Timeout givet i millisekunder anvendt ved Dokumentdelingsservicens opslag mod indekset, dvs. timeout for kald af indeksets webservice
`documentregistryactive` -- Hvorvidt indekset anvendes eller ej. Værdien 1 anfører, at indekset anvendes, 0 ellers.
`documentregistryservicename` -- Navnet på service-gruppen for indeksets webservice. Standard-værdien er DocumentRegistry_Service.
`documentregistryfailurethreshold` -- Grænseværdi for hvor mange kald til indekset der må fejle før monitoreringssnitfladen melder fejl.
`documentregistrysoapversion` -- Hvorvidt der skal anvendes headere af type HSUID, DGWS (Security og Medcom) og Medcom fra DGWS.
`documentregistryititransaction` -- Beskrivelse af hvilken ITI transaction, der kan anvendes på dokumentindekset. Understøtter en dokumentindeks flere ITI transactions skal der laves en indgang per ITI transaction. Lovlige værdier, hvoraf der skal anføres en enkelt:
-- ITI-18 Benyttes til opslag på metadata via Registry Stored Query ITI-18 transaktionen.
-- ITI-42 Benyttes til registrering af metadata for dokument(er) med fast (Stable) indhold via Register Document Set-b ITI-42 transaktionen.
-- ITI-57 Benyttes til opdatering af registrerede metadata via Update Document Set ITI-57 transaktionen. (f.eks til skift af status på et dokument (APPROVED -> DEPRECATED). )
-- ITI-61 Benyttes til registrering af metadata for dokument(er) med dynamisk (On-demand) indhold via Register On-Demand Document Entry ITI-61 transaktionen.

Extract fra produktion juni-2019:

documentsource

^^Tilbage til toppen^^

webservice-endpoint for kildesystemer
Mapning mellem angivet OID i udtræk til aktuelt service endpoint for XDS dokument kilde. Anvendes af DDS servicen (DDS Repository).

Kombinationen af oid og type skal være unik

Objektet rummer følgende information:
-------------------------------------------
oid -- OID værdien som for den pågældende XDS dokument kilde, som kan være at typen ’repository_unique_id’ eller ’home_community_id’
type -- Angiver hvilken typen af OID der er angivet, og den skal have én af følgende værdier: [‘repository_unique_id’|’home_community_id’]
service_endpoint -- Angiver URL til XDS dokument kilde, web-endpoint for dokumentkilden
soap_version -- Hvorvidt der skal anvendes headere af type HSUID, DGWS (Security og Medcom) og Medcom fra DGWS. Mulige værdier med angivelse af om benytter HSUID eller DGWS udgående):
-- 1.1 (HSUID)
-- 1.2 (HSUID)
-- 1.1_NO_HSUID (none)
-- 1.2_NO_HSUID (none)
-- 1.2_DGWS (HSUID, DGWS)
-- 1.2_DGWS_NO_HSUID (DGWS)
-- 1.2_DGWS_NO_ADDR (HSUID, DGWS) -- benyttes når WS-Addressing ikke ønskes anvendt
-- 1.2_MEDCOM_NO_HSUID ((DGWS) - kun medcom-header)
timeout -- Angiver hvor lang tid DDS forsøger at hente dokumenter fra eksterne kilder inden forsøget opgives. Tiden angives i millisekunder
failurethreshold -- Grænseværdi for hvor mange kald der må fejle før monitoreringssnitfladen melder fejl.

Extract fra produktion juni-2019:
-----------------------------------

Whitelist config (DDS)

^^Tilbage til toppen^^

Objektet indeholder de CVR som er whitelisted til brug på test/prod for DDS servicen

Objektet indeholder informationen:
---------------------------------------
service_key
-- DDS Registry: 'dk.nsi.ddsregistry'
-- DDS Repository: ’dk.nsi.ddsrepository’
-- Min Spærring (Samtykke verifikation): 'dk.nsi.consent.verification'
-- Min Spærring (Samtykke administration): 'dk.nsi.consent.administration'
service_type --
cvr -- CVR nummer
comment -- Her anføres NSP Jira nummer som relaterer den enkelte whitelisting

Tabelbeskrivelser

Tabel: documentregistry

^^Tilbage til toppen^^

-- -----------------------------------------------------
-- Table `documentsources`.`documentregistry`
-- -----------------------------------------------------
CREATE TABLE IF NOT EXISTS `documentsources`.`documentregistry` (
`documentregistryid` INT(10) NOT NULL AUTO_INCREMENT,
`documentregistryserviceurl` VARCHAR(256) NOT NULL,
`documentregistryfriendlyname` VARCHAR(120) NOT NULL,
`documentregistryservicenamespace` VARCHAR(256) NOT NULL,
`documentregistrylocal` BOOLEAN NOT NULL DEFAULT false,
`documentregistrytimeoutvalue` INT NOT NULL DEFAULT 100,
`documentregistryactive` BOOLEAN NOT NULL DEFAULT true,
`documentregistryservicename` VARCHAR(120) NOT NULL,
`documentregistryfailurethreshold` INT NOT NULL DEFAULT 5 ,
`documentregistrysoapversion` VARCHAR(45) NOT NULL DEFAULT '1.2',
`documentregistryititransaction` VARCHAR(45) NOT NULL,
PRIMARY KEY (documentregistryid),
CONSTRAINT `unique_constraint_documentregistry` UNIQUE (`documentregistryfriendlyname`, `documentregistryactive`)
)
ENGINE = InnoDB
DEFAULT CHARACTER SET = utf8;

Tabel: documentsource

^^Tilbage til toppen^^

-- -----------------------------------------------------
-- Table `documentsources`.`documentsource`
-- -----------------------------------------------------
CREATE TABLE IF NOT EXISTS `documentsources`.`documentsource` (
`oid` VARCHAR(120) NOT NULL ,
`type` VARCHAR(120) NOT NULL ,
`service_endpoint` VARCHAR(120) NOT NULL ,
`soap_version` VARCHAR(45) NOT NULL DEFAULT '1.2' ,
`timeout` INT NOT NULL DEFAULT 300000 ,
`failurethreshold` INT NOT NULL DEFAULT 5,
PRIMARY KEY (oid, type))
ENGINE = InnoDB
DEFAULT CHARACTER SET = utf8;

Tabel: whitelist_config (DDS)

^^Tilbage til toppen^^

CREATE TABLE whitelist_config (
service_key VARCHAR(50) NOT NULL,
service_type VARCHAR(20) NOT NULL,
cvr CHAR(8) NOT NULL,
comment VARCHAR(100) NULL,
PRIMARY KEY (service_key, service_type, cvr)
); -- ENGINE=InnoDB COLLATE=utf8_bin;

Teknologibeskrivelse

^^Tilbage til toppen^^

Refereres fra

^^Tilbage til toppen^^

• Page: 2.1 NSP Forretningsarkitektur overordnet
• Page: 2.2 NSP Forretningsarkitektur områder
• Page: D00 Cross-Enterprise Document Sharing (XDS)
• Page: D02 Dokument Registrering service (DRS)
• Page: D03 Aftaleoversigt adaptere (DDS-AO)
• Page: D05 Laboratoriesvar eksponering adaptere (DDS-SXA)
• Page: D06 FSK Registry adapter (DDS-FSK)
• Page: E01 Min Spærring (Samtykke)
• Page: F01 Fælles Stamkort (FSK)