Page History

*Dokumentationen af NSP services og komponenter på NSPOP omfatter udelukkende NSP produktionsmiljøet og ikke NSP’s øvrige miljøer. Det er muligt at få information og indblik i tilstanden på et af de øvrige miljøer via de gængse kommunikationsveje.

Indledning

Dette dokument handler om omhandler servicearkitekturen, der ligger bag deling af aftaler via NSP . Det giver og giver et overblik arkitekturoverblik over, hvorledes de forskellige forretningsservices på NSP skal anvendes interagerer i forbindelse med deling af aftaler.

Dokumentet dokumenterer ikke de De enkelte services dokumenteres ikke i forhold til f.eks. snitflader, men der vil henvise til relevant dokumentation.

Dokumentet starter med et overblik over aftaler: Hvad er en aftale? Hvordan er aftaler modelleret?

Dernæst gives et overblik over aftaledeling: Hvilke NSP services udgør tilsammen infratrukturen til understøttelse af deling af aftaler.

Tilsidst i dokumentet gennemgås relevante user stories i forbindelse med deling af aftaler:

...

findes henvisninger til dokumentation, hvor dette er relevant.

For beskrivelser af forretningsregler,  tekniske implementeringsvejledninger og standarder, der gælder for deling af aftaler, henvises til dokumentationen Et samlet patientoverblik > Aftaleoversigt

...

Ordliste

Dokumenthenvisninger

...

https://bitbucket.org/4s/cda-validator

https://cda.medcom.dk (online version)

Arkitekturoverblik for aftaler

Grundlæggende faciliterer arkitekturen to overordnede metoder for aftaledeling:

• Oprettelse, udlæsning, opdatering og sletning (CRUD) af aftaledokumenter via den nationale XDS infratruktur.
• Udlæsning af aftaler fra Bookplan i hhv. Region Nordjylland og Region Midtjylland.

Oprettelse, udlæsning, opdatering og sletning (CRUD) af aftaledokumenter via den nationale XDS infratruktur

På NSP stilles den nationale XDS infrastruktur til rådighed for anvenderne til deling af aftaler:

• Oprettelse af nye aftaler sker fra anvendersystemerne vha. Dokument Registrerings- og Opdateringsservice (DROS). DROS lagrer den oprettede aftale i det bagvedliggende nationale XDS Repository (anvendelse af servicen ITI-41 Provide and Register Document Set). I forbindelse med oprettelsen sørger det nationale XDS Repository for at få indexeret dokumentet og dets metadata i det nationale XDS Registry (anvendelse af servicen ITI-42 Register Document Set). Tidligere har også DRS været anvendt til dette formål, men den udgår.
• DROS skal også anvendes, når en aftale oprettes som en opdatering til en eksisterende aftale (anvendelse af servicen ITI-41 Provide and Register Document Set).
• Skal en aftale slettes (deprecate) eller dets metadata opdateres anvendes ligeledes DROS (ITI-57: Update Document Set)
• Udsøging af aftaler sker via Dokumentdelingsservicen (DDS Registry), der videredelegerer forespørgslen til det nationale XDS Registry (anvendelse af servicen ITI-18 Registry Stored Query).
• Hentning af aftaler sker via Dokumentdelingsservicen (DDS Repository), der henter det efterspurgte aftaledokument ud fra det nationale XDS Repository (anvendelse af servicen ITI-43 Retrieve Document Set).
• Det er via DROS muligt at oprette on-demand dokumenter (ITI-61 Register On-Demand Document Entry) samt registrere nye stable dokumenter (ITI-42 Register Document Set)men dette anvendes ikke for nuværende for aftaler. 

For en detaljeret gennemgang af de enkelte usecases henvises til dokumentet Et samlet patientoverblik > Aftaledeling > Teknisk implementeringsvejledning Aftaleoversigt.

Derudover henvises der til anvenderguides af disse NSP services:

DROS - Guide til anvendere

DDS - Guide til anvendere

De udstillede services (ITI-18, ITI-41, ITI-43 og ITI-57 samt ITI-61 og ITI-42) er alle standardservices beskrevet i standarderne for XDS. Dog er disse services (undtagen ITI-42noDgws) forsynet med servicesikkerhed efter de gældende standarder for NSP services. Dette betyder, at alle de udstillede services skal kaldes med Den Gode Webservice (DGWS).

Udlæsning af aftaler fra Bookplan i hhv Region Nord og Region Midt

Udover de aftaler, der deles via den nationale XDS infrastruktur, er der lavet adaptorer for integration til Bookplan i Region Nordjylland og Region Midtjylland. Disse adaptorer giver mulighed for læseadgang for aftaler registreret i Bookplan i disse to regioner.

Som det fremgår af ovenstående diagram, delegeres en søgning, der kommer ind via DDS Registry både til det nationale XDS Registry og til to adaptere: AO XDS Registry Adapter RN og AO XDS Registry Adapter RM. Disse services er ansvarlige for at delegere søgninger videre til de to Bookplan instanser i Region Nord hhv. Region Midt.

I forbindelse med en søgning mod Bookplan genererer AO XDS Registry Adapter de relevante aftaledokumenter og tilhørende metadata. De genererede aftaledokumenter lægges i en cache, hvor de er klar til afhentning.

De konkrete "Bookplan-aftaler" kan efter en søgning hentes ved hjælp af DDS Repository på samme måde som de aftaledokumenter, der deles via den nationale XDS infrastruktur. DDS Repository delegerer afhentningen af "Bookplan-aftaler" videre til AO XDS Repository Adapter RN hhv AO XDS Repository Adapter RM.

Til forskel fra aftaler, som deles via den nationale XDS infrastruktur, er der for "Bookplan-aftaler" tale om en ren læseadgang.

For en mere detaljeret gennemgang af AO XDS Adapters henvises til AO XDS Adapter - Guide til Anvendere

Dokumentdelingsservices ansvarsområder

DDS Registry og DDS Repository fungerer således som proxy'er for de bagvedliggende registries og repositories.

DDS Registry og DDS Repository samler svar fra de bagvedliggende komponenter i ét og tilbagesender det til anvenderen. For anvenderne af DDS Registry og DDS Repository er det derfor gennemsigtighed i forhold til, hvilke dokumenter der ligger i den nationale XDS infrastruktur, og hvilke der hentes via integrationssnitfladerne mod Bookplan.

Udover at videredelegere forespørgsler til bagvedliggende komponenter og samle svar, gør DDS følgende:

• Foretager auditlogning.
• Filtrerer svar i henhold til en borgers registreringer i MinSpærring.
• Foretager kald til MinLog.
• Bestiller opfølgninger i Behandlingsrelationsservicen (BRS).

For en mere detaljeret gennemgang af Dokumentdelingsservicen henvises til DDS - Guide til anvendere

Overblik over aftaler

Hvad er en aftale?

I konteksten af deling af aftaler, defineres en aftale som følger:

...

En aftale skal i det følgende forstås som et tidspunkt og et sted,

hvor en borger og en sundhedsprofessionel ressource (hospital, læge, kommune)

mødes i terapeutisk/behandlingsøjemed (se ABP1.1)

I deling af aftaler via NSP arbejdes der med en fælles datamodel for aftaler. Denne fælles datamodel bygger på HL7v3 (baseret på HL7's Reference Information Model - RIM) samt profilering af denne datamodel i implementationsguides for XML dokumenter (CDA Release 2) for specifikke anvendelser.

Hvordan modelleres aftaler?

Overordnet set består et CDA (Clinical Document Architecture) dokument af følgende elementer:

• En header med metadata om dokumentet: Denne header indeholder information, der går igen henover alle typer af kliniske dokumenter f.eks. hvilken patient drejer dokumentet sig om, hvilken organisation er ansvarlig (ejer) af dokumentet mm.
  
• En body med selve det kliniske indhold: En struktur til bestemte formål
  

Medcom har lavet danske profileringer både af CDA headeren (se MEDCOM-CDAHEADER) og af aftaledokumentformatet (MEDCOM-APD).

...

Således modelleres aftaler som individuelle aftaledokumenter.

Det er op til anvenderne af deling af aftaler at parse og forstå de hentede aftaledokumenter. Medcom har til dette formål udviklet en builder/parser til f.eks. aftaledokumenter (se 4S-BUILDER) samt en validator (se 4S-VALIDATOR), som også er tilgængelig online.

Aftaleformatet er udkommet i flere revisioner, hvoraf den seneste er 2.0.

Repeterende aftaler

Der har været diskussioner om, hvorledes repeterende aftaler skal repræsenteres indenfor konceptet deling af aftaler. Medcoms version 2.0 af APD (se MEDCOM-APD-V2) behandler specifikt problemet vedr. repeterende aftaler, hvor de tidligere versioner lod dette være op til anvenderne.

En repeterende aftale er en aftale, hvor en borger og en sundhedsprofessionel mødes i terapeutisk/behandlingsøjemed flere gange med en defineret frekvens f.eks. et hjemmebesøg hver mandag. I forhold til aftaledefinitionen ovenfor, kan en repeterende aftale opfattes som en mængde af flere enkeltaftaler.

Version 2.0 af APD beskriver, hvorledes de enkelte delaftaler i en repeterende aftale skal modelleres som individuelle APD CDA dokumenter. Aftaledokumenter som er en del af en repeterende aftale har en angivelse af dette som en del af CDA body:

• Repetationskode: For at en aftale kan opfattes som en del af en repeterende aftale, skal APD dokumentet have repetationskoden 'RepeatingDocumentType'.
• Sammenkædning med andre enkeltaftaler: Der kan angives et UUID på de enkelte aftaledokumenter. UUID'en identificerer den repeterende aftale og er en måde at lave den konkrete sammenkædning på.

Vejledende tidspunkter

Udover at beskrive modelleringen af repeterende aftaler indeholder version 2.0 af APD en beskrivelse af, hvordan det kan modelleres, at tidspunkterne i aftalen er vejledende f.eks. i forbindelse med hjemmebesøg.

Eksempel på aftaledokument

På Medcoms SVN findes en række eksempler på CDA dokumenter.

Dette er et eksempel på en repeterende aftale (APD version 2.0): http://svn.medcom.dk/svn/drafts/Standarder/HL7/Appointment/Eksempler/DK-APD_Example_apd-2-0.xml

Overblik over aftaledeling

Ligesom modellering af aftaler bygger på danske profileringer af internationale standarder under HL7, er snitfladerne i deling af aftaler også baseret på HL7 standarder.

Snitflader

Aftaledelingarkitektur

I det følgende gives et arkitekturoverblik over, hvilke forretningsservices på NSP, der er i spil i forbindelse med deling af aftaler.

User stories i forbindelse med aftaledeling

Det er vigtigt at holde sig for øje, at et CDA dokument er uforanderligt.