Overblik

Dette dokument beskriver designet af Stamkortregister-servicen.

Ændringslog

Version

Dato

Ændring

Ansvarlig

1.0.0

2018-08-31

Initialt dokument

Trifork

1.0.112019-08-16Fjernet note om SCES. Tilføjet note om MinLog SessionId.Trifork
1.0.122021-01-18Opdateret 'Design'-figurKvalitetsIT
1.0.132021-04-13Opdateret med NAS-integrationKvalitetsIT
1.0.142021-04-29Opdateret 'Design'-figurKvalitetsIT

Terminologi



HL7 CDA

Standard til udveksling af oplysninger indenfor sundhedsvæsenet.

Forkortelser

Forkortelse

Betydning

SKR

Stamkortregistret

FSKDet Fælles Stamkort
DDSDokumentdelingsservicen
DCCViderestillingsservicen

Arkitektur

Stamkortregister-servicen er en webservice, der anvendes som datakilde for Det Fælles Stamkort. Anvendere skal hente oplysningerne igennem Det Fælles Stamkort.


<iframe src="https://archi.nspop.dk/NSP/570928ca/views/b5e29947-a12a-45ae-80e5-2edccfd8589b.html" name="test" height="780" width="800">You need a Frames Capable browser to view this content.</iframe>   

* Hver kasse i ovenstående diagram har en kort forklaring, som kommer frem i et nyt browservindue, når der klikkes på kassen.


Brugerne tilgår 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. Servicen vil validere, at kaldet er foretaget korrekt.

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. Der kræves som udgangspunkt anvendelse af OCES sikkerhedsniveau 4, hvor der skal medsendes et ID-kort, som er signeret med medarbejdercertifikat (MOCES). Servicen vil verificere at kaldet er korrekt signeret, og at signeringen ikke er udløbet. Det pågældende brugercertifikat skal være hvidlistet i SKR og have den nødvendige funktion - ret til at få adgang til en specifik SKR-servicemetode.

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, som vil verificere at der er tale om et korrekt IDWS-kald.

Servicen vil tillade kaldet hvis:

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

CPR-subscriber

Cpr-subscriber er en fælles intern applikation hvis formål er at håndtere al kommunikation til stamdata (cpr-registry). SKR-servicen inkluderer et slettejob der skal sørge for at slette en borgers registrering 1 år efter personen er afgået ved døden.

Oplysningen om døde personer stammer fra stamdata. Cpr-subscriber gør det muligt for SKR-servicen at lave opslag i stamdata til brug i dette slettejob.

MinLog

Alle opslag og ændringer af Stamkort registreres i MinLog2. Med undtagelse af system bruger og borgerens egen læsning af data. 

Ved manglende adgang til MinLog-servicen vil servicekaldet fejle.

NAS

Alle ændringer (oprettelser, opdateringer og sletning) af Stamkort afstedkommer adviseringer til NAS.

Ved manglende adgang til NAS-servicen vil servicekaldet fejle.

Beskedformat

Der anvendes følgende topic (som kan konfigureres): http://sundhedsdatastyrelsen.dk/PersonalDataCard/2020/11/01:DataCardUpdated.

Indholdet i notifikationen bestpår af et DataCardUpdated xml objekt, med følgende attributter:

<?xml version="1.0" encoding="UTF-8"?>
	<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
			   targetNamespace="http://sundhedsdatastyrelsen.dk/skr/2021/06/02"
			   xmlns:ns="http://sundhedsdatastyrelsen.dk/skr/2021/06/02">

		<xs:element name="DataCardUpdated">
			<xs:complexType>
				<xs:sequence>
					<xs:element name="date" type="ns:element"/>
					<xs:element name="id" type="ns:element"/>
					<xs:element name="messageId" type="ns:element"/>
					<xs:element name="type" type="ns:element"/>
					<xs:element name="version" type="ns:element"/>
				</xs:sequence>
			</xs:complexType>
		</xs:element>

		<xs:complexType name="element">
			<xs:attribute name="value" type="xs:string" use="required"/>
		</xs:complexType>
	</xs:schema>

Eksempel på notifikation:

<ns3:Notify xmlns:ns2="http://www.w3.org/2005/08/addressing" xmlns:ns3="http://docs.oasis-open.org/wsn/b-2"
            xmlns:ns6="http://nsi.dk/advis/v10" xmlns:ns8="http://sundhedsdatastyrelsen.dk/skr/2021/06/02">
    <ns3:NotificationMessage>
        <ns3:Topic Dialect="http://docs.oasis-open.org/wsn/t-1/TopicExpression/Simple">TESTNAS-TOPIC1</ns3:Topic>
        <ns3:Message>
            <ns6:NotifyContent id="0501792275" idType="http://nsi.dk/advis/v10/CPR">
                <ns8:DataCardUpdated>
                    <date value="2022-11-01"/>
                    <id value="0501792275"/>
                    <messageId value="AAABhDKrCSD8xJkQXp07iFNPU0k="/>
                    <type value="http://sundhedsdatastyrelsen.dk/MessageDefinition/PDC-notification"/>
                    <version value="1"/>
                </ns8:DataCardUpdated>
            </ns6:NotifyContent>
        </ns3:Message>
    </ns3:NotificationMessage>
</ns3:Notify>

PersonInformation

PersonInformation anvendes på 3 områder i SKR:

  1. Gennem kald til PersonInformation Service foretages validering af CPR nummer. CPR valideringen kan køre i følgende tre modes:
  2. Gennem kald til PersonInformation Service tjekkes anvenderens relation til CPR numret, skulle anvender og patient ikke være den samme. Anvender kan have en af 2 relationer
  3. CPR oprydningsjobbet benytter PersonInformation servicen til at tjekke om tal strenge i tekstfelter er rigtige CPR numre, som skal fjernes.

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.


<iframe src="https://archi.nspop.dk/NSP/570928ca/views/bb995f9c-1f1e-4bbb-a379-79a2dc0709fc.html" name="test" height="410" width="800">You need a Frames Capable browser to view this content.</iframe>   

* Hver kasse i ovenstående diagram har en kort forklaring, som kommer frem i et nyt browservindue, når der klikkes på kassen.


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