Overblik

Dette dokument beskriver designet af Stamkortregister-servicen..

Det forudsættes at læseren er bekendt med grundfunktionaliteten i servicen, beskrevet i dokumentet Stamkortregister-service (SKR).

Ændringslog

Terminologi

Forkortelser

Arkitektur

Systemet består af to services. Stamkortregister-servicen håndterer funktionalitet og databaseadgang, og en separat DGWS/IDWS Proxyservice håndterer DGWS- og IDWS-specifik sikkerhed i forbindelse med udefrakommende kald til systemet.

Som illustreret på figuren herunder tilgår brugerne servicen indirekte via Sundhed.dk, patientjournalsystemer, lægepraksissystemer osv. Herudover kan stamkort hentes via Dokumentdelingsservicen (DDS), som anvender FSK som On-Demand datakilde. FSK henter data fra en række datakilder, herunder Stamkortregistret.

Standarder

Dataudveksling er basereret på HL7 CDA.

Data fra selve stamkortet udstilles i CDA-dokumentets body (structuredBody) mens metadata udstilles i CDA-dokumentets header. Metadata er hovedsageligt information om hvilken borger stamkortet vedrører og hvem der har opdateret stamkortet.

Da HL7 CDA er tiltænkt kliniske dokumenter og ikke stamkortoplysninger om borgere, er stamkortet repræsenteret som CDA-udvidelser, så vidt muligt opbygget af dataelementer fra CDA. 

Oprettelse, ændring og sletning af stamkort-data sker via separate opdateringsoperationer til hver del af stamkortet, eksempelvis midlertidig adresse eller sprog. Disse opdateringsoperationer modtager ikke et komplet stamkort-dokument men kun de relevante data som ændres. Her benyttes de samme CDA-strukturer, som ved læsning af stamkortet.

Forretningslogikken i Stamkortregister-servicen er afkoblet fra udvekslingsformatet, dvs. HL7 CDA.

Se Guide til Anvendere for flere detaljer.

Sikkerhed

Kald til Stamkortregister-servicen kan foretages som enten DGWS- (Den Gode Webservice) eller IDWS- (Identity Based Web Services) kald. Som beskrevet i afsnittet Arkitektur ovenfor, foretages kald til SKR igennem en DGWS/IDWS proxy, der har det primære formål at validere, at der er foretaget et korrekt DGWS- eller IDWS-kald.

Sundhedsprofessionelle, der vil tilgå Stamkortregister-servicen fra deres EPJ- eller EOJ-system, kan foretage DGWS-kald igennem den centrale NSP afkoblingskomponent (DCC), som viderestiller kaldet til Stamkortregistret igennem DGWS/IDWS Proxyen. Der kræves som udgangspunkt anvendelse af OCES sikkerhedsniveau 4, hvor der skal medsendes et ID-kort, som er signeret med medarbejdercertifikat (MOCES). Proxyen vil verificere at kaldet er korrekt signeret, og at signeringen ikke er udløbet.

Borgere, der vil tilgå Stamkortregister-servicen, skal gøre dette igennem Sundhed.dk, som står for borgervendt funktionalitet. Sundhed.dk kan foretage et IDWS-kald til Stamkortregistret igennem DGWS/IDWS Proxyen. Proxyen vil verificere at der er tale om et korrekt IDWS-kald.

Såfremt Proxyen kan verificere at der er tale om et korrekt DGWS- eller IDWS-kald, vil kaldet blive viderestillet til Stamkortregister-servicen. Servicen vil tillade kaldet hvis:

• Der er tale om et DGWS-kald foretaget af en autoriseret sundhedsprofessionel (og som der ikke er givet negativt samtykke til af den borger, hvis data slås op).
  
• Der er tale om et IDWS-kald, foretaget af samme person, som der slås data op for (eller en person, der har fuldmagt til at foretage opslaget)

De tilfælde, der er angivet i parentes ovenfor, kræver at der er etableret integration til hhv. samtykke- og fuldmagt-services. Denne funktionalitet er pt. ikke understøttet.

Der henvises til hhv. Den Gode Webservice og OIO Identity-based Web Services v1.0.1a for yderligere information.

Integrationer

Alle opslag og ændringer af Stamkort registreres i MinLog.

Ved manglende adgang til MinLog-servicen vil servicekaldet fejle.

Design

Datamodel

Service og database er opbygget således at det vil være nemt at udvide stamkortet med yderligere informationer senere.

Den logiske datamodel er illustreret på figuren herunder.

Det centrale dataelement er en stamkortopdatering (tabel: PersonalDataCard), som der kan eksistere et antal af for hver borger/CPR-nummer.

Til hver stamkortopdatering hører en eller flere ændringer af de oplysninger, som indgår i stamkortet, eksempelvis borgerens pårørende. Hver af disse oplysninger har en gyldighedsperiode, der angiver hvorvidt informationen er gældende eller ej. Data slettes således ikke, men får blot afsluttet sin gyldighed. 

En række af disse stamkortopdateringer kan være gyldige på samme tidspunkt, eksempelvis hvis der er registreret flere pårørende ad flere omgange.

Hver stamkortopdatering har tilknyttet en aktør (tabel: ServiceActor) som er den person, der lavede den pågældende ændring af stamkortet. Denne aktør kan være borgeren selv, en sundhedsprofessionel eller en person der har fuldmagt til at opdatere stamkortet.

Det detaljerede schema for databasen er vist på figuren herunder.

Image Added

Specifikke designbeslutninger

Vedr. DGWS/IDWS Proxy'en, er der foretaget følgende beslutninger:

• IDWS implementationen stammer fra FMK, og bygger på udgaver af oiosaml_java og oiosaml-trust, som er videreudviklet i forhold til de oprindelige, officielle udgaver af disse libraries. De 2 jar-filer er endnu ikke tilgængelige som artifacts i nspop's Nexus repository, men levereres med som libs i nspop's Subversion sammen med den øvige DGWS/IDWS Proxy og SKR kildekode. Kildekoden til disse libraries findes i nspop's SVN repository.
  
  
• Proxy'en anvender Seal, som ved initialisering normalt registrerer til STR-Transform algoritme i forbindelse med xmlsec-biblioteket. oiosaml registrerer ligeledes denne algoritme, hvilket giver en konflikt. Dette er løst ved at sætte en System-property "sosi:do.not.register.STRTransform", som får Seal til at undlade at registrere algoritmen. Dette har ikke negative effekter i Seal, da Proxy'en kun anvender Seal til parsning af DGWS messages. Det betyder dog, at andre services, som afvikles på samme Wildfly instans, potentiet kan bliver berørt af dette, hvilket normalt ikke er acceptabelt i henhold til NSP's regler for services.