INDHOLD
Brugerne tilgår Organdonor servicen indirekte via Sundhed.dk, patientjournalsystemer, lægepraksissystemer osv.
Herudover foretager Dokumentdelingsservicen (DDS) opslag via FSK. Opslaget via FSK returnerer alene information om, hvorvidt der findes data for en person eller ej (og derfor skal anvender systemer efterfølgende kalde direkte for at få faktiske data).
Support ansvarlig: Trifork
NSP: Organdonorregister-service (ODR)
Det er kun borgeren som kan opdatere og har ved registrering mulighed for at tage stilling til donation af forskellige typer af organer heriblandt hjerte, lever, nyrer, hornhinder, tyndtarm osv.
Dette gøres via Sundhed.dk
Borgerer, der ønsker at tilgå servicen, skal gøre det igennem Sundhed.dk, som står for borgervendt funktionalitet. Sundhed.dk kan foretage IDWS-kald til servicen igennen DGWS / IDWS Proxyen. Proxyen vil verificere at der er tale om et korrekt IDWS-kald.
Support ansvarlig: Trifork
NSP: Organdonorregister-service (ODR)
WSDL:
- DGWS: https://wsdl.nspop.dk/odr/wsdl/dgws
- IDWS: https://wsdl.nspop.dk/odr/wsdl/idws
Selve registerservicen håndterer funktionalitet og databaseadgang og en separat DGWS/IDWS Proxyservice håndterer kald til systemet.
Der understøttes adgang gennem DGWS eller IDWS forudsat at adgangen sker via en DGWS/IDWS Proxy, som er en separat service der afkobler alt DGWS- og IDWS-specifikt.
Brugerne tilgår servicen indirekte via Sundhed.dk, patientjournalsystemer, lægepraksissystemer osv.
Herudover foretager Dokumentdelingsservicen (DDS) opslag via FSK. Opslaget via FSK returnerer alene information om, hvorvidt der findes data for en person eller ej.
Borgerer, der ønsker at tilgå servicen, skal gøre det igennem http://sundhed.dk/
Såfremt Proxyen kan verificere at der er tale om et korrekt DGWS- eller IDWS-kald, vil kaldet blive viderestillet til servicen. Servicen vil tillade kaldet hvis:
Der er tale om et DGWS-kald foretaget af en autoriseret sundhedsprofessionel.
Der er tale om et IDWS-kald, foretaget af samme person, som der slås data op for.
Alle opslag og ændringer af oplysninger i registret registreres i MinLog med undtagelse af borgerens egen tilgang og ændring af data.
Operationerne i servicen kan alle kaldes med IDWS-kald (f.eks. fra sundhed.dk), mens de to sidste (Get/Has) også kan kaldes med DGWS-kald (kun forespørgelse):
++ CreateOrganDonorRegistration -- Opret en organdonorregistrering for en specifik borger (-/IDWS)
++ UpdateOrganDonorRegistration -- Opdatér en borgers organdonorregistrering (-/IDWS)
++ DeleteOrganDonorRegistration -- Slet en borgers organdonorregistrering (-/IDWS)
++ GetOrganDonorRegistration -- Hent en organdonorregistrering for en specifik borger (DGWS/IDWS)
++ HasOrganDonorRegistration -- Hent om en specifik borger har en organdonorregistrering (DGWS/IDWS)
Cpr-subscriber er en fælles intern applikation hvis formål er at håndtere al kommunikation til stamdata (cpr-registry)
ODR Slettejob
---------------
ODR-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 ODR-servicen at lave opslag i stamdata til brug i dette slettejob
Register properties:
Borgeren har ved registrering mulighed for at tage stilling til donation af forskellige typer af organer heriblandt hjerte, lever, nyrer, hornhinder, tyndtarm osv.
Da det kun er borgeren selv der har adgang til at oprette og ændre i vedkommendes organdonorregistrering, kan datamodellen for servicen realiseres relativt simpelt, idet at det ikke er nødvendigt at lagre information omkring hvem der har oprettet / opdateret data.
Alle registreringer indeholder oplysninger om en gyldighedsperiode, som angiver hvorvidt registreringen stadig betragtes som gyldig eller ej.
Der kan kun eksistere én gyldig registrering for hver enkelt borger, og ønsker borgeren at tilføje en ny registrering skal vedkommende slette den gyldige først.
Når borgeren opdaterer sin registrering med en eller flere ændringer, afsluttes gyldigheden for den nuværende registrering og der oprettet en ny række. Dermed bliver data ikke slettet, men får blot afsluttet en gyldighed.
Ved sletning afsluttet gyldighedsperioden blot.
ODR-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)
OrganDonor bliver anvendt til at lagre information om en borgers organdonorregistrering.
Objektet indeholder følgende information:
----------------------------------------------
PersonIdentifier -- identificerer borgeren (CPR nummer)
ValidFrom - ValidTo -- definerer gyldighedsperioden.
PermissionType -- kan antage 4 værdier, som repræsenterer følgende:
Fuld tilladelse -- Borgerens fuld tilladelse til, at vedkommendes organer kan anvendes til transplantation efter død.
Begrænset tilladelse -- Tabellens boolske værdier til at udtrykke, hvad der gives begrænset tilladelse til.
Ved ikke -- Borger har endnu ikke taget stilling og dermed overlades beslutning som organdonor til de nærmeste pårørende.
Forbud -- Borgeren modsætter at vedkommendes organer anvendes til transplantation efter død.
Boolske værdier, benyttes ved PermissionType = "Begrænset tilladelse":
Heart
Kidneys
Lungs
Corneas
Liver
SmallIntestine
Pancreas
Skin
RelativeAcceptanceRequired -- anvendes ved fuld -og begrænset tilladelse. Har borgeren angivet denne, forudsætter valget som organdonor pårørendes accept.
Properties er anvendt til at lagre information omkring hvornår et Organdonorregister slettejob sidst er blevet eksekveret.
-- -----------------------------------------------------
-- Table `organDonor`.`OrganDonor`
-- -----------------------------------------------------
CREATE TABLE IF NOT EXISTS `organDonor`.`OrganDonor` (
`OrganDonorPID` INT(11) NOT NULL AUTO_INCREMENT,
`PersonIdentifier` VARCHAR(30) NOT NULL,
`ModifiedDateTime` DATETIME NOT NULL,
`ValidFrom` DATETIME NOT NULL,
`ValidTo` DATETIME NOT NULL,
`PermissionType` VARCHAR(10) NULL,
`Heart` BIT NULL,
`Kidneys` BIT NULL,
`Lungs` BIT NULL,
`Corneas` BIT NULL,
`Liver` BIT NULL,
`SmallIntestine` BIT NULL,
`Pancreas` BIT NULL,
`Skin` BIT NULL,
`RelativeAcceptanceRequired` BIT NULL,
`Version` INT(11) NOT NULL,
PRIMARY KEY (`OrganDonorPID`),
INDEX `idx_validTo` (`ValidTo` ASC))
ENGINE = InnoDB
COLLATE 'utf8_bin';
Database "follow-up" (Backend)
CREATE TABLE BRS2_TreatmentRelationFollowup (
serialNumber bigint NOT NULL, -- Auto increment is set in alter table (due to hsqldb and mysql syntax)
nextCheck datetime NOT NULL,
queryableCvr char(8) NOT NULL, -- cvr nummer der kan hente alarmer paa baggrund af denne followup
externalReferenceId varchar(50) NOT NULL,
uid varchar(36) NOT NULL,
doctorOrganisation varchar(7) NULL,
hospitalOrganisation varchar(7) NULL,
ean varchar(20) NULL,
patientCpr char(10) NOT NULL,
healthProfessionalCpr char(10) NOT NULL,
relationLookupStart DATETIME NOT NULL,
relationLookupEnd DATETIME NOT NULL,
timeLimit DATETIME NOT NULL,
acceptableRelations varchar(20) NOT NULL, -- separated by comma
followupRelations varchar(20),
authorisationIdentifier varchar(20) NOT NULL,
serviceProviderName varchar(50) NOT NULL,
serviceProviderVersion varchar(30) NOT NULL,
serviceProviderVendor varchar(50) NOT NULL,
created DATETIME NOT NULL,
PRIMARY KEY (serialNumber)
);
ALTER TABLE BRS2_TreatmentRelationFollowup MODIFY COLUMN serialNumber bigint NOT NULL auto_increment;
CREATE INDEX NextCheckIndex on BRS2_TreatmentRelationFollowup(nextCheck);
CREATE INDEX uidIndex on BRS2_TreatmentRelationFollowup(uid);
-- -----------------------------------------------------
-- Table `organDonor`.`Properties`
-- -----------------------------------------------------
CREATE TABLE IF NOT EXISTS `organDonor`.`Properties` (
`PropertiesPID` INT NOT NULL AUTO_INCREMENT COMMENT 'Primær nøgle',
`PropertyKey` VARCHAR(50) NOT NULL COMMENT 'Nøgle',
`PropertyValue` VARCHAR(50) NULL COMMENT 'Værdi',
PRIMARY KEY (`PropertiesPID`))
ENGINE = InnoDB
COLLATE 'utf8_bin';