Page History
...
Ideen med aftaledeling er et danne et overblik over en patients samlede aftaler i sundhedsvæsnet. Dette betyder især noget for patienter der er i et komplekst forløb, der, på samme tid, spænder over flere kliniske specialer, og hvor patienten er i kontakt med for eksempel egen læge, kommunen og flere hospitalsafdelinger.
| Multiexcerpt | ||
|---|---|---|
| ||
Dokument Registrering Service (DRS) håndterer oprettelsen af nye aftaler. |
| Multiexcerpt | ||
|---|---|---|
| ||
Servicen tager imod registreringer til det nationale aftalerepository. Efterfølgende sørger det centrale XDS repository for at meta-data afleveres til det nationale registry, så aftalerne kan fremsøges vha. Dokumentdelingsservicen (DDS) |
Support ansvarlig: Kvalitets IT
NSP: Dokument Registreringservice (DRS) - Leverancebeskrivelse
DRS implementerer DGWS og kan tilgås med gyldig SOSI Idkort (MOCES/VOCES/FOCES)
Der foretages:
- Sikkerheds verifikation gennem STS servicen
- Autentificering af anvendersystemet ved Whitelist kontrol gennem DDS documentsources.whitelist_config
- Aflevering af dokument(er) til bagvedliggende Aftalerepository (Opentext XDS OpenXDS Repository service)
Forretningsanvendelse
| Multiexcerpt | ||
|---|---|---|
| ||
|
Relaterede registre og services
| Multiexcerpt | ||
|---|---|---|
| ||
Applikationsbeskrivelse
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) til autentificering og autorisering, dvs. der anvendes OCES II certifikater. Hvorvidt anvender skal benytte Virksomhedscertifikat (VOCES), Funktionscertifikat (FOCES) eller Medarbejdercertifikat (MOCES) vil indgå i den anvenderaftalen, der aftales mellem anvender og Sundhedsdatastyrelsen. I tillæg til DGWS skal der ved opslag på metadata og indhentning af dokumenter vedlægges yderligere beskrivelser af konteksten. 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 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
...
Dokument Registrering servicen (DRS) gør det muligt for dokumentkilder at registrere aftaledokumenter i henhold til IHE XDS profilens (XDS.b) transaktion ITI-41 ProvideAndRegisterDocumentSet.
Der etableres en web service, som giver mulighed for at aflevere aftaledokumenter ind i det fælles centrale NSP OpenXDS Repository og Opentext XDS Registry. DRS benyttes som proxy for en eller flere dokumentkilder.
Aflevering af dokumenter gennemføres med operationen Provide and Register Document Set (ITI-41), der er IHE XDS.b’s operation til aflevering af dokumenter til et IHE repository.
Ved kald af webservice-operationen Provide and Register Document Set på DRS gennemføres følgende:
- Sikkerheds verifikation gennem STS servicen
- Autentificering af anvendersystemet ved Whitelist kontrol gennem DDS documentsources.whitelist_config
- Aflevering af dokument(er) til bagvedliggende Aftalerepository (OpenXDS Repository service)
Dokumentregistrering servicen overholder Den Gode Web Service 1.0.1, kræver anvendersystem autentificeret af STS’en på NSP, kræver anvendersystem autoriseret, hvilket kontrolleres vha. whiteliste, returnerer SOAPFault ved autentifikations- og autorisationsfejl samt ved visse systemfejl.
Den generelle servicestruktur er at servicen implementeres som en webservice, der implementerer det webinterface, der er genereret fra DRS WSDL [ITI-41++ SOAP 1.1 WSDL]. Webservicen er en tynd skal, der for sin eneste weboperation blot kalder den faktiske implementation på Aftalerepository.
Inden kald af DRS skal anvendersystemet: Trække et SOSI ID Kort fra NSP'ens STS.
Url: <serverurl>/drs
WSDL: https://wsdl.nspop.dk/drs/wsdl/drs.wsdl
Følgende operationer:
------------------------
ITI-41 Provide and Register Document Set (Resulterer i et implicit kald til XDS Registry servicen for at få registreret metadata via ITI-42 Register Document)
Datastruktur
Der er ingen informationsmodel for DRS.
Herunder vises den benytted whitelist tabel fra D01 DDS.
Entitetsbeskrivelser
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 Opentext XDS 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 Repository (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)
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
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
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)
...
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
-- -----------------------------------------------------
-- 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
...
Tabel: whitelist_config (DDS)
...