Versions Compared

Key

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

...

Sundhedsprofessionelle (uden sundhedsfaglig autorisation): Kan få adgang til borgerens forløbsplaner via lokal trustmodel, hvor parterne giver relevante medarbejdere adgang til at tilgå borgeres forløbsplaner via Sundhedsjournalen på sundhed.dk, eller via eget fagsystem - afhængigt af lokal implementering

Overordnet oversigt

Teknisk oversigt

Indhold i Forløbsplaner

Først og fremmest skal man kende til det indholdsformat der benyttes til aftaledokumenter. Formatet er XML og indholdet er specificeret som en dansk profil af CDA. Den danske profil for CDA Appointment (APD-DK 2.0.1) er forankret hos MedCom der står for den danske profilering. Se under MedCom APD-DK hvor både beskrivelse af standarden samt forskellige aftale eksempler opbevares, bemærk der findes eksempler til alle versioner af APD-DK, eksempler til APD-DK 2.0.1 findes i version 2.0 folderen.
Update 20/10-2020: Der er udgivet en Errata, hvori der er enkelte præciseringer samt rettelser af fejl i forhold til APD-DK 2.0.1, Errata'en kan kan hentes på MedCom's hjemmeside, og er gældende sammen med APD-DK 2.0.1 profilen.

...

Systemer der tilsluttes Aftaleoversigten, skal godkendes af MedCom ud fra en certificering. Testprotokollerne for certificering til Aftaleoversigten, hvor version 1.1 er gældende for afsendelse og version 1.0 er gældende for modtagelse, kan findes på MedCom's hjemmeside under: Testprotokoller for modtagelse og afsendelse af Aftaler.
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

Krav IDKravAfvigelse
Afsendelse krav 4.7Redegør for hvordan erstatnings CPR håndteres

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

Afsendelse krav 4.24Aftaler som uploades skal, hvis de er del af et repetitionsmønster, uploades et år frem i tiden

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.

Afsendelse krav 4.27Opret en ny aftale med angivelse af forløbs-label og forløbs-id

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.

Modtagelse krav 4.2

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

Kode

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.

<id
 
extension="31af7e14-891c-48f0-a414-fd432289bf7d"
 root="1.2.208.184"
 assigningAuthorityName="MedCom"/>

Patienten aftalen omhandler

...recordTarget.patientRole

Patientens Navn og CPR nr.


<patientRole classCode="PAT">

<id extension="2512489996" root="1.2.208.176.1.2" assigningAuthorityName="CPR"/>

<patient classCode="PSN" determinerCode="INSTANCE">

<name>

<given>Nancy</given>

<given>Ann</given>

<family>Berggren</family>

</name>

<administrativeGenderCode code="F" codeSystem="2.16.840.1.113883.5.1"/>

<birthTime value="19481225000000+0000"/>

</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"

<code code="REFB" codeSystem="2.16.840.1.113883.5.90" codeSystemName="ParticipationType (HL7) Code System" displayName="ParticipationReferredBy"/>

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">

<time value="20190816100000+0100"/>

<assignedAuthor classCode="ASSIGNED">

<id extension="378631000016009" root="1.2.208.176.1.1" assigningAuthorityName="SOR"/>

<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>

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">

<assignedCustodian classCode="ASSIGNED">

<representedCustodianOrganization classCode="ORG" determinerCode="INSTANCE">

<id extension="378631000016009" root="1.2.208.176.1.1" assigningAuthorityName="SOR"/>

</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

<documentationOf typeCode="DOC">

<serviceEvent classCode="MPROT" moodCode="EVN">

<templateId root="1.2.208.184.200.1.11" extension="2019-09-10"/>

<effectiveTime>

<low value="20191231090000+0100"/>

<high value="20191231120000+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"

Slut dato og tidspunkt for aftalen

<documentationOf typeCode="DOC">

<serviceEvent classCode="MPROT" moodCode="EVN">

<templateId root="1.2.208.184.200.1.11" extension="2019-09-10"/>

<effectiveTime>

<low value="20191231090000+0100"/>

<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"

Hvis tidspunkterne i aftalen er vejledende vil

<precondition>

<templateId root="1.2.208.184.14.11.5" extension="2019-09-10" />

<criterion>

<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)

<documentationOf>

<serviceEvent>

<templateId root="1.2.208.184.200.1.10" extension="2019-09-10"/>

<!--This id @extension equals the identification and version of the CDA profile-->

<id root="1.2.208.184.100.3" extension="apd-v2.0" assigningAuthorityName="MedCom"/>

</serviceEvent>

</documentationOf>

Aftaletypen

<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

<precondition>

<templateId root="1.2.208.184.14.11.4" extension="2019-09-10" />

<criterion>

<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">

<assignedEntity classCode="ASSIGNED">

<id extension="378631000016009" root="1.2.208.176.1.1" assigningAuthorityName="SOR"/>

<addr use="WP">

<streetAddressLine>Vestergade 5</streetAddressLine>

<postalCode>3000</postalCode>

<city>Odense</city>

</addr>

<telecom value="tel:66113333-3" use="WP"/>

<representedOrganization classCode="ORG" determinerCode="INSTANCE">

<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:

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

For virtuelle aftaler, se nedenfor



Lokation #1

<participant typeCode="LOC">

<participantRole classCode="SDLOC">

<templateId root="1.2.208.184.14.11.3" extension="2019-09-10" />

<id extension="240901000016000" root="1.2.208.176.1.1" assigningAuthorityName="SOR"/>

<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">

<participantRole classCode="SDLOC">

<templateId root="1.2.208.184.14.11.3" extension="2019-09-10" />

<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">

<participantRole classCode="SDLOC">

<templateId root="1.2.208.184.14.11.3" extension="2019-09-10" />

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

<playingEntity classCode="PLC">

<name>Borgers Hjemmeadresse</name>

</playingEntity>

</participantRole>

</participant>

Årsag til aftalen

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

Årsagen til at der er indkaldt til aftalen

<entryRelationship typeCode="RSON">

<observation classCode="OBS" moodCode="EVN">

<code code="NI" displayName="Hjemmehjælp"/>

</observation>

</entryRelationship>

Tekniske forudsætninger

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

...

Følgende roller anvendes i forbindelse med Et samlet patientoverblik.

Rollenavn

Rettighed

Notation som indsættes i SOSI IdKort ved udstedelse

nspSundAssistR2

Giver ret til at læse til Forløbsplaner

urn:dk:healthcare:national-federation-role:code:41002:value:SundAssistR2

 

En sundhedsperson kan ikke have tilknyttet flere roller på samme tid - dette skal administreres via den lokale identifikations- og rettighedsstyring, eller via SEB

...