Page History

Versions Compared

Key

This line was added.
This line was removed.
Formatting was changed.

...

Den praktiserende læge: Lægen udarbejder forløbsplanen, for henholdsvis KOL, diabetes og hjertelidelser i samerbejde samarbejde med patienten borgeren via eget fagsystem.
Forløbsplanen opbevares i forløbsplandatabasen som er forvaltet af PLSP.

...

Først og fremmest skal man kende til det indholdsformat der benyttes til forløbsdokumenterforløbsplansdokumenter. Formatet er XML og indholdet er specificeret som en dansk profil af CDA. Den danske profil for CDA Careplan (CPD-DK 2v2.0.0) er forankret hos MedCom der står for den danske profilering. Se under MedCom CPD-DK hvor både beskrivelse af standarden samt forskellige aftale eksempler opbevares, bemærk der findes eksempler til alle versioner af CPD-DK, eksempler til CPD-DK 2v2.0.o 0 findes i Eksempel folderen.

...

Indholdet i CDA headeren er fælles for alle danske CDA dokumenter, og er ligeledes forankret hos MedCom, se under MedCom CDA Header v. 1.4. I forbindelse med forløbbsplaner er der tilføjet en forløbslabel til CDA Headeren, som ikke er inkluderet i CDA Header v. 1,4 standarden - dette er beskrevet i CPD-DK v2.0.0 under afsnit 2.1.5.3

Systemer der tilsluttes Forløbsplaner, skal bl.a. godkendes af MedCom ud fra en certificering. Testprotokollerne for certificering til Forløbsplaner,, kan findes på MedCom's hjemmeside under: Testprotokoller for modtagelse og afsendelse af careplaner.Der er enkelte afvigelser i test-protokollerne for afsendelse og modtagelse af Aftaler, der ikke er defineret under forretningsreglerne. Følgende tabel viser disse afvigelser

...

Der er ingen forretningsregel der definerer at erstatnings CPR skal kunne benyttes.

Der er ikke noget krav til systemet at de skal anvende erstatnings CPR numre til afsendelse af Aftaler

...

Forretningsregel #3 definerer: at repetitionsmønsteret er gentaget 6 måneder frem, afhængigt af om repetitionerne stadig foregår.

Systemet der skal tilsluttes Aftaleoversigten, skal kunne håndtere et repetitionsmønster på 6 måneder som forretningsregel #3 angiver.

...

Oprettelse af Aftale med forløbslabel og forløbs-id, er ikke et krav i forhold til forretningsreglerne for Aftaleoversigten. CDA-Profilen (APD-DK 2.0.1) er en profil der giver fagsystemer som har behov for at dele forløbslabel og forløbs-id mulighed for det

Der er ikke noget krav til systemet at kan oprette Aftaler med forløbslabel og forløbs-id på skrivende tidspunkt.

...

Vis aftale-indhold (aftale med region) fra testeksempel 1.5, hvor følgende er beskrevet:

Vis aftale forløbs-label og alle forløbs-id som er angivet i testeksemplet.

Vis at det kun er muligt at se forløbs-label i detaljeret visning (hvis dette er muligt).

Vis at det hverken er muligt at se forløbs-id i simpel eller evt. detaljeret visning.

Forløbs-id skal som minimum vises i det hentede CDA dokument

...

Visning af Aftaler med forløbslabel og forløbs-id, er ikke et krav i forhold til forretningsreglerne for Aftaleoversigten. Fagsystemerne skal dog kunne håndtere modtagelse af Aftaler, hvori forløbslabel og forløbs-id er inkluderet.

Der er ikke noget krav til systemet at kan vise Aftaler med forløbslabel og forløbs-id på skrivende tidspunkt.

Yderligere information om om hvordan CDA dokumenter er opbygget kan findes hos IHE, under: IHE - Hvad er HL7 CDA?

Aftaler i APD-DK 2.0.1 indeholder information, som defineret i nedenstående tabel

...

Beskrivelse

...

Eksempel

...

ID for aftalen

ClinicalDocument.id

...

Den unikke identifikation for aftalen
Bemærk: dette er ikke det samme som dokument-id'et der returneres ved at svar på en søgning. dokument-id'et vil ændres hvis en aftale opdateres, det vil Id for aftalen ikke.

...

...

Patienten aftalen omhandler

...recordTarget.patientRole

Patientens Navn og CPR nr.

...

<patientRole classCode="PAT">

<name>

<given>Nancy</given>

<family>Berggren</family>

</name>

</patient>

</patientRole>

...

Ansvarlig for aftalen

ClinicalDocument.author

Den organisation og person der er ansvarlig for aftalen

Der kan tilføjes et ekstra "author" element, efter den aftale ansvarlige, dette vil være rekvirenten for aftalen hvis en sådan er tilgængelig.
Efter "id" men før "addr" skal der tilføjes følgende "code"

Bemærk at "code" er ændret på baggrund af tastefejl, til "REFB" - dette kan ses i Errata_APD-DK-v2.0.1_20_10_2020

...

<author typeCode="AUT" contextControlCode="OP">

<addr use="WP">
<streetAddressLine>Sundhedsenhedsforvaltningen</streetAddressLine>
<streetAddressLine>Ørbækvej 100</streetAddressLine>
<postalCode>5220</postalCode>
<city>Odense SØ</city>
</addr>

<assignedPerson classCode="PSN" determinerCode="INSTANCE"><name>
<given>Jens</given>
<family>Jensen</family>
</name>
</assignedPerson>

</assignedAuthor>

</author>

Yderligere information om om hvordan CDA dokumenter er opbygget kan findes hos IHE, under: IHE - Hvad er HL7 CDA?

Tekniske forudsætninger

Se Administrative forudsætninger for at få adgang til NSP'en.

Forløbsplaner

...

Forvalter for CDA dokumentet, hvori aftalen indgår

ClinicalDocument.custodian

...

Forvalteren er den myndighed der sørger for opbevaring og udlevering af CDA dokumentet ved relevante forespørgsler. Forvalteren er ligeledes ansvalig for at CDA dokumentet behandles på lovlig og forsvarlig vis, når det er i forvalterens varetægt.

Forvalteren er ikke ansvarlig for det sundhedsspecifikke indhold i CDA dokumentet.

...

<custodian typeCode="CST">

</representedCustodianOrganization>

</assignedCustodian>

</custodian>

...

Start dato og tidspunkt for aftalen

documentationOf.serviceEvent.
effectiveTime.low

templateId
root="11.2.208.184.200.1.11"
extension="2019-09-10"

...

Start dato og tidspunkt for aftalen

...

<low value="20191231090000+0100"/>

</effectiveTime>

</serviceEvent>

</documentationOf>

...

Slut dato og tidspunkt for aftalen

documentationOf.serviceEvent.
effectiveTime.high

templateId
root="11.2.208.184.200.1.11"
extension="2019-09-10"

...

<high value="20191231120000+0100"/>

</effectiveTime>

</serviceEvent>

</documentationOf>

...

Indikation om tidspunkterne i aftalen er vejledende

<body>.encounter.preCondition

templateId
root="1.2.208.184.14.11.5"
extension="2019-09-10"

code
code="GuidedIntervalType"
codeSystem="1.2.208.184.100.1"

...

<code code="GuidedIntervalType" codeSystem="1.2.208.184.100.1"

codeSystemName="MedCom Message Codes"/>

<text>Tidspunktet er vejledende</text>

</criterion>

</precondition>

...

Status for aftalen

<body>.encounter.statusCode

code="active"

...

Status for aftalen

Bemærk: Status skal altid have værdien "active"

...

<statusCode code="active" />

...

Version for aftalen standarden

documentationOf.serviceEvent.id

templateId
root="1.2.208.184.200.1.10"
extension="2019-09-10"

...

Feltet indeholder hvilken version af aftalestandarden dokumentet er baseret på.

Bemærk: Feltet er først indført fra version 2.0, og vil derfor ikke findes i de tidligere versioner af aftalestandarden (1.0 og 1.1)

...

</serviceEvent>

</documentationOf>

...

<body>.encounter.code

...

Aftalen kan være af typerne: Regional, Kommunal, Praksis - dette kommer sig til udtryk ud fra følgende værdier

Kommunal: MunicipalityAppointment

Regional: RegionalAppointment

Praksis: PractitionerAppointment

...

<code

code="MunicipalityAppointment" codeSystem="1.2.208.184.100.1"

codeSystemName="MedCom Message Codes">

</code>

...

Repetitionsmønster for aftalen

<body>.encounter.preCondition

templateId
root="1.2.208.184.14.11.4"
extension="2019-09-10"

code
code="RepeatingAppointmentType"
codeSystem="1.2.208.184.100.1"

...

Viser om aftalen er en del af et repeterende aftalemønster

...

<code code="RepeatingAppointmentType" codeSystem="1.2.208.184.100.1"

codeSystemName="MedCom Message Codes"/>

<value xsi:type="II" root="1.2.208.184" extension="06b2b3bb-dac5-446f-aa19-ed5c46d8b0b7"

assigningAuthorityName="MedCom" />

</criterion>

</precondition>

...

Udførende for aftalen

<body>.encounter.performer

...

Den udførende organisation i forhold til aftalen

Bemærk: Den udførende organisation, er ofte også den ansvarlige organisation for aftalen.

...

<performer typeCode="PRF">

<streetAddressLine>Vestergade 5</streetAddressLine>

<city>Odense</city>

</addr>

<name>Hjemmehjælp, afdeling City, Odense Kommune</name>

</representedOrganization>

</assignedEntity>

</performer>

Lokation for aftalen

encounter.participant

Den lokation hvor aftalen udføres,
Lokationen kan være en af tre forskellige typer:

Lokationen er baseret på Sundhedsvæsnets Organisationsregister (SOR), og defineret som besøgsadresse i SOR.
typeCode="LOC"
Lokationen er baseret på en adresse udenfor SOR, f.eks den lokale idrætshal, eller den offentlige svømmehal.
typeCode="DST"
Lokationen er patientens hjemadresse.
typeCode="SBJ"

For virtuelle aftaler, se nedenfor

Lokation #1

<participant typeCode="LOC">

...

<addr use=”WP”>
<streetAddressLine>OUH Radiologisk Afdeling (Odense)</streetAddressLine>
<streetAddressLine>Sdr Boulevard 29</streetAddressLine>
<city>Odense</city>
<postalCode>5000</postalCode>
</addr>

<playingEntity classCode="PLC">
<name>Radiologisk Afdeling</name>
</playingEntity>

</participantRole>

</participant>

Lokation #2

<participant typeCode="DST">

<addr use=”WP”>
<streetAddressLine>Radiologisk Afdeling</streetAddressLine>
<streetAddressLine>Kløvervænget 47</streetAddressLine>
<city>Odense</city>
<postalCode>5000</postalCode>
</addr>

<playingEntity classCode="PLC">
<name>Radiologisk Afdeling, indgang A</name>
</playingEntity>

</participantRole>

</participant>

Lokation #3

<participant typeCode="SBJ">

<addr use=”WP”>
<streetAddressLine>Skovvejen 12, Landet</streetAddressLine>
<city>Svendborg</city>
<postalCode>5700</postalCode>
</addr>

<name>Borgers Hjemmeadresse</name>

</playingEntity>

</participantRole>

</participant>

...

Årsag til aftalen

<body>.encounter.entryRelationship.
observation.code.displayName

...

<entryRelationship typeCode="RSON">

</observation>

</entryRelationship>

Tekniske forudsætninger

Se Administrative forudsætninger for at få adgang til NSP'en.

Aftaleoversigten udstilles via services på NSP'en, disse skal tilgås gennem en afkoblingskomponent "DCC'en" DCC'en viderestiller kald til underliggende services, så der er ikke en WSDL for DCC'en. Se DCC Dokumentation for adgang til services gennem DCC'en.adgang til services gennem DCC'en.

Info
Det er et krav at dokumentdelingsservicen skal tilgås gennem afkoblingskomponenten

NSP services kan tilgås enten via Den Gode Webservice (DGWS) eller via OIO-IDWS (Udelukkende borger adgang).
Den Gode WebService (DGWS) benytter XMLDSIG til at signere SAML assertions ud fra X.509 certifikater/nøgler - for adgang til Aftaleoversigten Forløbsplaner skal sundhedspersoner have et gyldigt NemSTS-underskrevet SOSI-ID Medarbejdercertifikat (MOCESkort på niveau 4 (medarbejder), hvilket også er beskrevet under administrative forudsætninger, således at patienten har således at borgeren har mulighed fat lave en spærring for at aftaler forløbsplaner kan deles med specifikke sundhedspersoner, samt at patienten at patienten har mulighed for at se hvem der har haft adgang til patientens Aftaleoversigt via Min-logMinlog.
For mere information om den gode webservice, se: https://www.medcom.dk/standarder/webservice-standarder/den-gode-webserviceTil at understøtte SAML har Sundhedsdatastyrelsen udviklet biblioteker til Java og .NET (SEAL biblioteket) Dette bør benyttes så vidt det er muligt, se

STS DokumentationSundhedsdatastyrelsen har beskrevet hvordan et SOSI-ID kort kan skabes og anvendes under STS Dokumentationen

De servicesnitflader der udstilles til Aftaleoversigten Forløbsplaner er alle baseret på SOAP kald der opfylder understøtter DGWS.
Der arbejdes på at indføre en model baseret på IDWS kompatibel med XUA, som anvendes af de standard produkter der implementerer IHE XDS.Indholdsdelen af den enkelte servicekald (SOAP body) er den del der er specificeret af IHE XDS snitfladerne, dvs. for eksempel ITI-18 og ITI-43., se nærmere beskrivelse under: Dokumentdeling på NSP (DROS, DDS, NXRG, OpenXDS)

De detaljerede beskrivelser af snitfladerne findes i IHE IT Infrastructure Technical Framework dokumenterne volume 1, 2a, 2b, 2x og 3.

...

Content

Space Tools

Versions Compared

Old Version 6

New Version 7

Key

Tekniske forudsætninger

Tekniske forudsætninger