This specification conforms to FHIR®© R4

Return

Sundhedsfaglige retningslinjer for anvendelse | Clinical guidelines for application

Indholdsfortegnelse | Table of Contents

• 1 Introduktion / Introduction
• 2 Formål / Purpose
• 3 Illustration af Korrespondancemeddelelsen / Illustration of CareCommunication
• 4 Krav og anbefalinger til Korrespondancemeddelelsen / Requirements and Recommendations for CareCommunication
  • 4.1 Kategori og emne / Category and Topic
  • 4.2 Meddelelsessegment / Message Segment
    • 4.2.1 Meddelelsestekst / Message Text
      • 4.2.1.1 Kopierede eller vedhæftede journalnotater / Copied or Attached Medical Notes
    • 4.2.2 Signatur / Signature
  • 4.3 Prioritet, krav om afgrænset brug / Priority, Requirements for Limited Use
  • 4.4 Vedhæftede filer / Attached Files
  • 4.5 Historisk overblik i brugergrænsefladen / Historical Overview in the User Interface
    • 4.5.1 Håndtering af historiske data ved SOR-koder / Handling of historical data with SOR-codes
  • 4.6 Forsendelsesmuligheder / Sending Options
    • 4.6.1 Besvarelse / Replying
    • 4.6.2 Videresendelse / Forwarding
• 5 Opsummering af krav og anbefalinger til afsender- og modtagersystemer / Summary of Requirements and Recommendations for Sending and Receiving Systems
• 6 Use Cases
• 7 Ibrugtagning i SOR/SOR-EDI / Implementation in SOR/SOR-EDI

1 Introduktion | Introduction

Dette er den tekstuelle del af dokumentationen til MedComs FHIR-standard for Korrespondancemeddelelse (på engelsk CareCommunication). Den tekstuelle del indeholder information om formål, baggrund, en illustration af indholdet i korrespondancemeddelelsen, krav og anbefalinger samt ibrugtagning ift. SOR-EDI. Målgruppen for denne tekst er it-systemleverandører og implementeringsansvarlige, som skal it-understøtte afsendelse og modtagelse af Korrespondancemeddelelsen.

Krav og anbefalinger til indhold, herunder funktionaliteter, er udarbejdet i samarbejde med en national arbejdsgruppe med repræsentanter fra regioner, kommuner og praktiserende læger. Derudover har indholdet på denne side været sendt i høring ved relevante MedCom-grupper samt været bredt tilgængeligt for kommentering via publicering på MedComs hjemmeside. De tekniske specifikationer for Korrespondancemeddelelsen findes via forsiden for MedComs samlede dokumentation for Korrespondancemeddelelsen, MedCom anvender onlineværktøjet GitHub til visning. Klik her for at læse de tekniske specifikationer for Korrespondancemeddelelsen.

Note: I tilfælde af uoverensstemmelser i beskrivelsen af de sundhedsfaglige retningslinjer for anvendelse på dansk og engelsk er det den danske beskrivelse af de sundhedsfaglige retningslinjer for anvendelse, der er gældende.

The intended audience of this text is IT system vendors and implementation managers responsible for supporting the sending and receiving of CareCommunication. Requirements and recommendations for the content of CareCommunication, including functionality, have been developed in collaboration with anational working group consisting of representatives from regions, municipalities, and general practitioners. Additionally, the content on this page has been reviewed by relevant MedCom groups and has been publicly available for comments via publication on MedCom’s website. The technical specifications for CareCommunication can be accessed through the main page of MedCom’s documentation site for CareCommunication. MedCom uses the online tool GitHub for displaying these specifications.Click here to read the technical specifications for CareCommunication.

>Note: Should any discrepancies arise between the Danish and English versions of the clinical guidelines, the Danish version shall be considered authoritative.

2 Formål | Purpose

Formålet med Korrespondancemeddelelsen er at understøtte den digitale kommunikation mellem sundhedsvæsenets parter, herunder bl.a. også psykiatri- og socialområdet, hvor initiativ til ny version af Korrespondancemeddelelsen er forankret. Korrespondancemeddelelsen anvendes til sikker digital kommunikation af personhenførbare oplysninger og anvendes typisk til ad hoc kommunikation. Korrespondancemeddelelsen skal dog kun bruges på de områder, hvor der i forvejen ikke findes tilgængelige strukturerede MedCom standarder. Korrespondancemeddelelsen skal ikke anvendes ved sager af akut karakter. Formålet med Korrespondancemeddelelsen er bl.a. at:

• Give mulighed for at vedhæfte og udveksle digitale filer.
• Understøtte automatisk fordeling ved modtagelse via brug af fælles nationale kategorier (=overordnede overskrifter).
• Respektere regionale samarbejdsaftaler med kommuner og praksislæger ved at bevare muligheden for at angive aftalte emneord (=supplerende overskrifter).
• Tydeliggøre afsenderen af Korrespondancemeddelelsen med påkrævet signatur.
• Anvende teknisk indhold, således at der i brugergrænsefladen arbejdes med en tydelig kommunikationshistorik og aktivitet (fx om en meddelelse er ny, besvaret eller videresendt).

3 Illustration af Korrespondancemeddelelsen | Illustration of CareCommunication

Figur 1 er en illustration af indholdet i Korrespondancemeddelelsen. Illustrationen er et eksempel og indeholder ikke alle datafelter, som er i standarden og afspejler ikke det enkelte systems brugergrænseflade. Figure 1is an illustration of the content of a CareCommunication. The illustration is an example and does not include all data fields defined in the standard, nor does it reflect the user interface of any specific system.

4 Krav og anbefalinger til Korrespondancemeddelelsen | Requirements and Recommendations for CareCommunication

Korrespondancemeddelelsen skal indeholde information om:

• Borger/patient som henvendelsen vedrører
• Afsender
• Modtager
• Kategori (fortæller på et overordnet niveau, hvad indholdet i Korrespondancemeddelelsen drejer sig om)
• Meddelelsessegment (indeholdende meddelelsestekst og signatur)
• Signatur skal indeholde dato og tidspunkt, forfatters navn, stillingsbetegnelse og relevant telefonnummer
• Tekniske data om meddelelsen (herunder bl.a. ID’er og referencer til forudgående meddelelser. Klik her for at se den tekniske dokumentation for yderligere information.)

Korrespondancemeddelelsen kan (=frivilligt) indeholde:

• Specifik afsender, hvis relevant (fx specifik udskrivningskoordinator eller læge på sygehus)
• Specifik modtager, hvis relevant (fx specifik sagsbehandler eller socialrådgiver i kommunen)
• Emne (supplerer den valgte kategori med et emneord, som fortæller i detaljer, hvad indholdet i Korrespondancemeddelelsen drejer sig om. Liste med emner er ofte defineret via regionale sundhedsaftaler)
• Vedhæftede filer (knyttes til et meddelelsessegment)
• Prioritet (Obs. Kan kun påsættes ved valg af den nationale kategori ”Vedr. henvisning”)

4.1 Kategori og emne | Category and Topic

Afsender vælger en kategori fra en nationalt fastlagt liste bestående af aftalte kategorier. Kategorilisten muliggør, at modtager automatisk kan fordele indkomne korrespondancemeddelelser, fx til det relevante kommunale område. Det er et krav, at kategorien vises for brugeren, men muligheden for automatisk fordeling ved modtagelse efter de nationale kategorier i Korrespondancemeddelelsen er ikke en del af MedComs test og certificering. Klik her for at læse de aftalte nationale kategorier.

Der er oprettet en kategori ”Andet” i de tilfælde, hvor de øvrige kategorier på listen ikke vurderes tilstrækkeligt dækkende for indholdet i Korrespondancemeddelelsen. Ved valg af kategorien ”Andet” er det et krav, at afsender medsender et emne. MedCom anbefaler, at afsender så vidt muligt undlader at anvende kategorien ”Andet”, undtagen i de tilfælde hvor det er absolut nødvendigt.

I emnefeltet har brugeren mulighed for at supplere den valgte kategori med et emne. Emnefeltet udfyldes enten med de regionalt aftalte emneord, defineret i de regionale samarbejdsaftaler, eller som selvskreven fritekst. Det er valgt at bibeholde emnefeltet netop for at kunne understøtte de eksisterende samarbejdsaftaler med de regionalt aftalte emneord. Der er ikke krav til, eller forventning om, at systemerne automatisk kan fordele efter emneord.

For at understøtte brugeren mest muligt anbefales følgende:

• Regionalt aftalte emneord mappes til de nationalt aftalte kategorier, hvor de pågældende emneord relateres til de relevante kategorier.
• I de brugssituationer, hvor der er regionalt aftalte emneord:
  • Brugeren præsenteres for de regionalt aftalte emneord, som de kender, og ved valg af emneord, påsætter systemet automatisk den pågældende relevante kategori (som er valgt ved forudgående mapning mellem kategori og emneord). Brugeren slipper derved for at skulle tage stilling til kategori.
  • Kategorien skal altid være synlig, både for afsender og modtager – også ved regionalt aftalte emneord. Kategorien kan dog, for at understøtte brugeren, gøres mindre synlig i brugergrænsefladen, fx ved at ’fade ud’, hvis der er regionalt aftalte emneord.
• I de brugssituationer, hvor der ikke er regionalt aftalte emneord:
  • Brugeren vælger kategori og har herefter mulighed for at supplere med selvskrevet emneord som fritekst i emnefeltet.

MedCom stiller en terminologiserver til rådighed, som bl.a. udstiller de nationale kategorier og tilladte filtyper, som kan vedhæftes Korrespondancemeddelelsen. Governance, omfattende regler og retningslinjer, herunder bl.a. adgang, opdatering og vedligeholdelse, for såvel terminologiserveren som listen over de nationalt aftalte kategorier, håndteres og fastlægges i MedCom-regi. Governance for terminologier og serveren findes via forsiden for Governance for MedCom FHIR Messaging. Klik her for at læse Governance for MedCom FHIR Messaging.

4.2 Meddelelsessegment | Message Segment

Et meddelelsessegment består af Korrespondancemeddelelsens meddelelsestekst og afsenders signatur. I de tilfælde, hvor der vedhæftes en fil til Korrespondancemeddelelsen, vil vedhæftningen knyttes til et nyt meddelelsessegment. Der er en identifier på hvert meddelelsessegment, som også skal medsendes og modtages af systemerne. I den forbindelse er der krav om, at meddelelsessegmenter indeholdt meddelelsestekst, altid skal medsendes i kommunikationen, fx ved besvarelse.

A message segment comprises the message text in the CareCommunication together with the sender’s signature. When a file is attached to the CareCommunication, the attachment will be linked to a new message segment. Each message segment carries its own identifier, which must be included when sending and receiving messages. Message segments containing message text must always be included in the communication, for example, when a reply is sent.

4.2.1 Meddelelsestekst | Message Text

Meddelelsestekst-feltet er et fritekstfelt, hvori afsender skriver sin tekst. Det er obligatorisk for afsender at skrive fritekst i meddelelsens tekstfelt.
Det er et krav til afsendersystemet, at understøtte muligheden for linjeskift i meddelelsens fritekstfelt. Det er et krav til modtagersystemet, at understøtte og vise linjeskift i meddelelsens fritekstfelt. Læs mere i Governance for CareCommunication.

The message text is a free-text field where the sender writes their text. The sender must enter free text in this field. The sender system must support the insertion of line breaks in the free text. The recipient system must preserve and display line breaks in the free text. Read more in Governance for CareCommunication.

4.2.1.1 Kopierede eller vedhæftede journalnotater | Copied or Attached Medical Notes

Hvis afsender kopierer og indsætter kortere journalnotater i meddelelsesteksten, anbefaler MedCom, at navn på forfatter, samt tidspunkt for oprettelse, af journalnotatet påskrives og medsendes i meddelelsens tekstfelt. Hvis afsender ønsker at medsende længere journalnotater, f.eks. mere end 1.000 tegn (svarende til en halv side), anbefaler MedCom, at disse medsendes som vedhæftede filer.[Se afsnit 4.4 Vedhæftede filer].

If the sender copies and pastes brief medical notes into the message free-text field, MedCom recommends including the author’s name and the creation timestamp of the medical note in the message free-text field. When the sender wishes to include longer medical notes e.g., more than 1,000 characters (approximately half a page), MedCom recommends attaching them as files. [See section 4.4 Attached files].

4.2.2 Signatur | Signature

Signaturen skal altid udfyldes, medsendes af afsender og vises af modtager. Formålet med signaturen er at tydeliggøre, hvem forfatteren af den afsendte Korrespondancemeddelelse er. Derfor er det et krav, at signatur udfyldes med bl.a. dato og tidspunkt, forfatterens navn, stillingsbetegnelse og relevant telefonnummer. Det anbefales at anvende de stillingsbetegnelser, som slutbrugeren er vant til at anvende i fagsystemet. Hvis systemet ikke har indlagt stillingsbetegnelser, skal afsenderen tilføje en jobtitel som fritekst eller benytte MedComs liste over stillingsbetegnelser, som er sammensat af udtræk fra autorisationsregistret og Sundhedsvæsenets Klassifikationssystem (SKS). Klik her for at læse listen over stillingsbetegnelser.
MedCom anbefaler, at telefonnummer udfyldes med relevant telefonnummer, såsom telefonnummeret på afdelingen, afsnittet eller enheden, som afsenderen er tilknyttet, eller fx et relevant vagttelefonnummer. Signaturen består af struktureret data og er ikke en del af tekststrengen, som kendt fra (X)DIS91. Signatur bør så vidt muligt autoudfyldes af systemet. I tilfælde af elementer, som ikke kan autoudfyldes af systemet, skal disse kunne tilføjes manuelt af brugeren, fx relevant telefonnummer.

The signature must always be filled out and sent as well as displayed by the recipient. The purpose of the signature is to clearly indicate the author of the CareCommunication. Therefore, the signature must include date and time, the author’s name, job title and relevant phone number. MedCom recommends using job titles that end-users are accustomed to in the clinical system. If the system does not have predefined job titles, the user must add a self-written job title or choose from MedCom’s list of job titles based on data from the Danish authorization register and Healthcare Classification System (DA: Sundhedsvæsenets Klassifikationssystem (SKS)). Click here to see the list of job titles.
MedCom also recommends entering a relevant phone number, such as the phone number of the department, unit, or a relevant on-call number. The signature consists of structured data and is not part of the text string as known from (X)DIS91. The system should auto-fill the signature as much as possible. Any elements that cannot be auto-filled by the system must be manually filled out by the user, such as the relevant phone number.

4.3 Prioritet, krav om afgrænset brug | Priority, Requirements for Limited Use

Det bliver muligt at markere en Korrespondancemeddelelse med prioritet, men med afgrænset brug i praksis. Alle systemer testes for, at de kan modtage og vise prioritet. I forhold til anvendelse og afsendelse af prioritet, testes alle systemer for, at prioritet kun er synlig og mulig at bruge ved valg af den nationale kategori ”Vedr. henvisning”. Kravet fremgår af use case og tilhørende testprotokol. Dette er besluttet på baggrund af, at behovet for at anvende prioritet er rejst i regi af et nationalt projekt om forbedring af henvisninger, herunder revision af henvisningsflowet. Anvendelsen af prioritet skal tilpasses løbende ift. udvikling i overenskomster og på baggrund af nationale krav fra Sundhedsministeriet, Sundhedsstyrelsen og Sundhedsdatastyrelsen.

It will be possible to mark a CareCommunication with priority, but with restricted use in practice. All systems are tested to ensure that they can receive and display priority. When applying and sending priority, every system will be tested to ensure that priority is only visible and selectable when the national category ‘Regarding referral’ is chosen. This requirement is specified in the use cases and corresponding test protocol. This decision is based on the need to use priority, which has emerged as part of a national project aimed at improving referrals, including revising the referral workflow. The use of priority must be continuously adapted to developments in agreements and to national requirements from the Ministry of Health, the Danish Health Authority, and the Danish Health Data Authority.

4.4 Vedhæftede filer | Attached Files

Det er muligt at vedhæfte filer, som indlejres i Korrespondancemeddelelsen. Når der er vedhæftet en fil til en Korrespondancemeddelelse, er det et krav, at det tydeligt vises i brugergrænsefladen. En vedhæftet fil kan både være en fil med en filtype, fx pdf, eller et link. De tilladte filtyper, som kan vedhæftes Korrespondancemeddelelsen, ses beskrevet i Implementation Guide for terminologi samt udstilles på terminologiserveren.
Klik her for at finde de tilladte filtyper, som kan vedhæftes i Korrespondancemeddelelsen.
Det er besluttet, at der ikke må medsendes video i en Korrespondancemeddelelse grundet størrelsen. Det anbefales, at videoer deles via en forventet kommende national delingsservice. Der vil ikke være begrænsning på, hvor mange vedhæftede filer der kan medsendes i en Korrespondancemeddelelse, men i stedet begrænses størrelsen på hele meddelelsen, dvs. inklusiv vedhæftede filer og VANS-kuverten. Den maksimale størrelse på hele meddelelsen, inklusive vedhæftede filer og VANS-kuverten, som sendes over VANS, er 100 MB. Alle vedhæftede filer tildeles en unik identifier
Afsender, som vælger at afsende, besvare eller videresende en Korrespondancemeddelelse, er ansvarlig for meddelelsens indhold, herunder vedhæftede filer. Forfatter på den vedhæftede fil er den fagperson, som oprindeligt har udarbejdet filen, og derfor er ansvarlig for det faglige indhold. MedCom anbefaler, at navn, samt tidspunkt for oprettelse, af den vedhæftede fil påskrives og medsendes. Systemfunktionalitet, der understøtter automatisk påsat navn på forfatter, samt tidspunkt for oprettelse, er optionel, og hvis denne funktionalitet ikke findes, anbefales det, at systemet understøtter, at afsender manuelt kan påskrive disse informationer enten i den vedhæftede fil, eller som struktureret information i meddelelsessegmentet med den vedhæftede fil. Når man, som afsender, vælger at medsende en fil, er man også ansvarlig for, at filens indhold er relevant for det aktuelle behandlingsforløb. Som en del af test og certificering tjekker MedCom, at identifier på vedhæftede filer indlæses og gemmes. Dette med henblik på at systemet ved modtagelse af en besvarelse kan genfinde og vise tidligere vedhæftede filer for brugeren. Krav til understøttelse af arbejdsgange samt brugervenlighed skal varetages lokalt i et samarbejde mellem kunde og it-leverandør.

4.5 Historisk overblik i brugergrænsefladen | Historical Overview in the User Interface

Systemerne skal benytte sig af muligheden for at give det bedst mulige overblik over en meddelelsesaktivitet (fx om meddelelsen er en ny modtaget meddelelse, en besvarelse eller en videresendelse) samt synliggøre kommunikationshistorikken i brugergrænsefladen.

Som en del af Korrespondancemeddelelsen medsendes en kommunikations-identifier samt referencer mellem meddelelsessegmenter og de tekniske elementer i provenance. Disse tekniske referencer medsendes med henblik på at kunne håndtere og koble meddelelser i en meddelelsestråd på samme måde på tværs af afsender og modtager, og således understøtte, at korrespondancemeddelelser dels placeres i rette tråd (via kommunikations-identifieren) og dels placeres i korrekt rækkefølge (via referencer mellem provenance og meddelelsessegment).

Kommunikations-identifieren oprettes og indsættes af afsendersystemet ved oprettelse af en meddelelse. Der er én kommunikations-identifier per meddelelsestråd. Formålet med kommunikations-identifieren er at koble de sammenhørende korrespondancemeddelelser i én meddelelsestråd, således at meddelelserne vises i samme tråd, både hos afsender og modtager.
Reference mellem provenance og meddelelsessegment skal både indgå i forhold til den aktuelle meddelelse, som sendes, men også i forhold til eventuelle forudgående meddelelser. Formålet med referencerne er at koble rækkefølgen af korrespondancemeddelelser, og at systemerne således ved, hvilke meddelelsessegmenter der er blevet tilføjet i en meddelelse.

MedCom har udarbejdet regler for håndtering og kobling af meddelelsestråde via kommunikations-identifier samt referencer mellem provenance og meddelelsessegmenter. Reglerne beskriver håndtering og kobling af de mulige kommunikationsflows, herunder besvarelser og videresendelser samt håndtering af parallelle meddelelser (grundet samtidighed).Klik her for at læse reglerne for håndtering af de mulige kommunikationsflows. Reglerne indgår også i testprotokollerne med henblik på at sikre ensartet implementering og anvendelse

I MedComPatientCore er det tilladt, at en person har flere identifiers – fx to erstatnings-CPR-numre eller et almindeligt CPR-nummer sammen med et erstatnings-CPR. Derfor anbefaler MedCom, at kommunikationsidentifieren også anvendes til at holde tråden i kommunikationen, hvis der tilføjes et CPR-nummer, som ikke i forvejen er kendt. Dette vil bevare historikken i en kommunikationstråd med samme kommunikationsidentifier, selvom der sker ændringer i en borgers CPR-numre.

In MedComPatientCore, a person may have multiple identifiers—for example, two replacement CPR numbers or a regular CPR number together with a replacement CPR. Therefore, MedCom recommends also using the communication identifier to maintain the message thread if a CPR number is added that is not already known. This will preserve the history within a communication thread that shares the same communication identifier, even if a citizen’s CPR numbers change.

4.5.1 Håndtering af historiske data ved SOR-koder | Handling of historical data with SOR-codes

En given SOR-kode kan, over tid, have forskellige data knyttet til sig (fx navn og lokationsnummer). Når en meddelelse sendes, skal de oplysninger, der er knyttet til den pågældende SOR-kode, fastholdes og forblive uændrede. Det betyder, at data ikke må opdateres til de aktuelle oplysninger i SOR, da det ville ændre den oprindelige kontekst for meddelelsen. I praksis vil et skift af både SOR-kode og lokationsnummer medføre, at der startes en ny meddelelsestråd. I det scenarie, hvor det kun er SOR-koden, som ændres, vil en ny meddelelsestråd ligeledes blive oprettet.

A given SOR-code may, over time, have different data associated with it (e.g., name and EAN/GLN-number). When a message is sent, the information linked to the specific SOR-code must be preserved and remain unchanged. This means that historical data must not be updated to reflect the current information in SOR, as that would change the message’s original context. In practice, a change of both the SOR-code and the EAN/GLN-number will result in the initiation of a new message thread. In cases where it is only the SOR-code that changes, a new message thread will be created.

4.6 Forsendelsesmuligheder | Sending Options

Afsender skal kunne sende en ny Korrespondancemeddelelse samt besvare en Korrespondancemeddelelse. Afsender bør (funktionaliteten er ikke påkrævet) kunne videresende en modtaget Korrespondancemeddelelse. MedCom anbefaler, at systemet understøtter funktionaliteten videresendelse. Det er et krav, at alle modtagersystemer skal kunne modtage og vise, om meddelelsen er en ny, besvaret eller videresendt Korrespondancemeddelelse. Både ved besvarelse og videresendelse af en Korrespondancemeddelelse indsættes den samme kategori og det samme emne automatisk af systemet. Brugeren skal kunne vælge at ændre det til en anden kategori og et andet emne. Referencer til det/de forudgående, eller videresendte, meddelelsessegment(er) skal indgå.

Afsenderen bør kunne tilføje en specifik afsender eller modtager til meddelelsen. Funktionalitet til at understøtte dette, er optionel. Tilføjelse af en specifik afsender kan benyttes i tilfælde, hvor afsenderen af meddelelsen sender informationer til modtager på vegne af en anden med behandlingsrelation til patienten og dermed ønsker at angive den/det specifikke person/team. En specifik afsender kan eksempelvis være et plejeteam, en hjemmeplejegruppe i kommunen eller en praktiserende læge. Specifik afsender er ikke en del af signaturen, da signaturen refererer til afsenderen af meddelelsen, og derfor bør afsenderoplysninger og specifik afsender ikke pr. automatik være ens. Det er et krav, at alle modtagersystemer skal kunne modtage og vise specifik afsender og specifik modtager, hvis dette er udfyldt og medsendt i meddelelsen. Hvis en korrespondancemeddelelse modtages med en specifik afsender, skal systemet automatisk sætte denne som specifik modtager ved besvarelse. MedCom anbefaler, at brugeren kan fjerne den specifikke modtager, hvis det ikke er relevant at videreføre. Det er ikke et krav, at der kan tilføjes en ny specifik modtager.

4.6.1 Besvarelse | Replying

Det er et krav at kunne afsende en besvarelse til:

• en ny modtaget Korrespondancemeddelelse
• den senest modtagne besvarelse i en kommunikationstråd
• en videresendt Korrespondancemeddelelse

Afsender bør (funktionaliteten er ikke påkrævet) kunne besvare egen senest afsendte Korrespondancemeddelelse i en meddelelsestråd. Denne mulighed vil støtte slutbrugeren i at fortsætte kommunikationen i samme tråd uden at skulle vente på svar fra modtageren, da det ikke er tilladt at besvare en tidligere modtaget Korrespondancemeddelelse i en meddelelsestråd. Således vil funktionaliteten med besvarelse af egen senest afsendte Korrespondancemeddelelse gøre det muligt for afsenderen at fortsætte meddelelsestråden. Det er ikke tilladt, og må ikke være muligt, at besvare en tidligere modtaget Korrespondancemeddelelse.

Det er et krav at kunne modtage og vise førnævnte besvarelsesscenarier inklusive forudgående meddelelser, herunder meddelelsessegmenter og nye vedhæftede filer. Hvis der modtages en CareCommunication med specifik afsender, er det et krav, at systemet indsætter den specifikke afsender som specifik modtager af besvarelsen, jf. afsnit 4.6.

Ved besvarelse indsættes afsender af den modtagne Korrespondancemeddelelse automatisk som modtager af besvarelsen (med SOR-kode og EAN-nummer). Afsender udfylder det nye meddelelsestekst-felt med selvskrevet tekst. Derudover påsættes også signatur, i samme meddelelsessegment, på afsender af besvarelsen. En besvarelse af en Korrespondancemeddelelse består således altid af minimum to meddelelsessegmenter, dvs. det tidligere modtaget meddelelsessegment og det nye, som afsender udfylder og medsender i besvarelsen. Hvis der er vedhæftet nye filer til besvarelsen, knyttes disse til meddelelsessegmentet. Hvis afsender har vedhæftet filer i den oprindelige Korrespondancemeddelelse, skal de vedhæftede filer fra afsender ikke medsendes igen ved besvarelse. I stedet tjekker MedCom, som en del af test og certificering, at systemerne indlæser og gemmer identifieren på de vedhæftede filer. Dette er med henblik på at systemet ved modtagelse af en besvarelse kan genfinde og vise tidligere vedhæftede filer for brugeren. De ovenstående hændelserne for besvarelse af en Korrespondancemeddelelse er visualiseret i et aktivitetsdiagram iFigur 2. Det er også muligt at besvare en tidligere modtaget EDIFACT, OIOXML eller FHIR MedCom-meddelelse med Korrespondancemeddelelsen. Ved besvarelse af en tidligere modtaget EDIFACT, OIOXML eller FHIR MedCom-meddelelse anvendes den medsendte identifier fra den modtagne meddelelse og medsendes i Korrespondancemeddelelsen. Således er det muligt, via identifier, at koble en relevant tråd af meddelelser sammen. Det kan eksempelvis ske ved, at man besvarer en modtaget henvisning med en Korrespondancemeddelelse, hvor forløbs-identifieren anvendes og medsendes i besvarelsen. Teknisk betyder det, at der ved besvarelse indsættes et nyt meddelelsessegment, bestående af et nyt meddelelsestekst-felt og signatur.

Parallelle besvarelser | Parallel Replies
I de få tilfælde hvor samme Korrespondancemeddelelse besvares på samme tid af afsender og modtager, vil både afsender- og modtagersystemet modtage såkaldte parallelle korrespondancemeddelelser. Det er et krav, at begge systemer indlæser meddelelserne i den tilhørende meddelelsestråd, selvom det ikke er den seneste meddelelse i tråden. Begge parallelt afsendte meddelelser skal således placeres i samme meddelelsestråd med samme kommunikations identifier. Det er et krav, at brugeren skal kunne fortsætte kommunikationen i meddelelsestråden enten ved besvarelse eller modtagelse af en ny meddelelse, selvom der optræder parallelle korrespondancemeddelelser. Det er vigtigt at synliggøre, hvilke oplysninger slutbrugeren har været bekendt med på afsendelsestidspunktet, når parallelle meddelelser placeres i samme tråd. Derfor er det et krav, at systemerne inkluderer en synlig reference mellem korrespondancemeddelelserne i tråden, således at brugerne tydeligt kan se, hvad de pågældende korrespondancemeddelelser er et svar på samt synliggøre sammenhængen mellem de øvrige korrespondancemeddelelser i meddelelsestråden. Det er op til leverandøren at sikre en visning, der understøtter brugeren bedst muligt.

Regler for håndtering af parallelle meddelelser, og visning i brugergrænsefladen, er beskrevet i governance for den nye Korrespondancemeddelelse. Klik her for at læse reglerne for håndtering af de mulige kommunikationsflows.

In rare cases where the same CareCommunication is replied to simultaneously by both the sender and the recipient, both the sender’s and the recipient’s systems will receive what are known as parallel CareCommunications. It is a requirement that both systems load the messages into the corresponding message thread, even if it is not the latest message in the thread. Both parallel messages must be placed in the same message thread with the same communication identifier. It is a requirement that users can continue communication in the message thread, either by replying or receiving a new message, even when parallel CareCommunications occur. It is important to make clear which information the end user was aware of at the time of sending, when parallel messages are placed in the same thread. Therefore, it is a requirement that systems include a visible reference between CareCommunication in the thread, so users can clearly see what each message is a response to and understand the context of the other messages in the thread. The vendor is responsible for ensuring that the display supports the user in the best possible way. Users must be able to continue communication in the message thread, even if parallel CareCommunication appear. The rules for handling parallel messages and their display in the user interface are described in the governance of the new CareCommunication.Click here for the governance rules on handling communication flows.

4.6.2. Videresendelse | Forwarding

Afsender bør kunne videresende en Korrespondancemeddelelse (funktionaliteten er ikke påkrævet). Det er op til afsender, hvornår det vurderes relevant at videresende en modtaget Korrespondancemeddelelse, såfremt systemet stiller denne mulighed til rådighed, som anbefalet af MedCom.

Alle systemer skal kunne modtage en videresendelse. Modtager skal kun kunne besvare den videresendte meddelelse, dvs. at modtageren ikke kan besvare en eller flere af de forudgående meddelelsessegmenter inkluderet i den modtagne videresendelse. Afsender er ansvarlig for videresendelsen og relevansen ift. det aktuelle behandlingsforløb. Hvis systemet har funktionalitet, som kan videresende Korrespondancemeddelelse, skal afsender kunne videresende hele meddelelsestråden, som kan bestå af en eller flere meddelelser og vedhæftede filer. Funktionaliteten til at kunne udvælge hvilke dele af meddelelsestråden, man som afsender ønsker at videresende, er ikke påkrævet i systemerne men optionel. Hvis systemet ikke understøtter, at afsender ved videresendelse kan udvælge hvilke dele af meddelelsestråden og vedhæftede filer, der skal medsendes - og afsender ved, at der er dele i meddelelsestråden, som modtageren ikke må modtage/se - skal afsender sende en ny Korrespondancemeddelelse i stedet for at videresende hele meddelelsestråden. Det anbefales, at afsender påskriver navn på den oprindelige forfatter af meddelelsen, som videresendes, i den nyoprettede Korrespondancemeddelelse.

MedCom anbefaler, at afsender beskriver årsagen til videresendelsen i meddelelsesteksten. Ved videresendelse vælger afsender, hvem modtageren er. Teknisk betyder det, at der ved videresendelse indsættes et nyt meddelelsessegment, bestående af et nyt meddelelsestekst-felt og signatur. Afsender udfylder det nye meddelelsestekst-felt med selvskrevet tekst, hvori det også anbefales at angive årsagen til videresendelsen. Derudover påsættes også signatur, i samme meddelelsessegment, på afsender af videresendelsen. En videresendelse består således altid af minimum to meddelelsessegmenter – det tidligere modtagne meddelelsessegment og det nye, som afsender udfylder og medsender ved videresendelsen. Hvis der er vedhæftet filer til videresendelsen, knyttes disse til et nyt meddelelsessegment. De ovenstående hændelser for videresendelse af en Korrespondancemeddelelse er visualiseret i et aktivitetsdiagram iFigur 3 og er beskrevet i governance for den nye Korrespondancemeddelelse. Hvis en bruger har videresendt en meddelelse, skal brugeren kunne fortsætte kommunikationen i den originale meddelelsestråd.

5 Opsummering af krav og anbefalinger til afsender- og modtagersystemer | Summary of Requirements and Recommendations for Sending and Receiving Systems

I tabel 1 opsummeres krav og anbefalinger til afsender- og modtagersystemer på baggrund af den tekstuelle del af dokumentationen. For tekniske detaljer henvises til de tekniske specifikationer, som findes via forsiden for Korrespondancemeddelelse i GitHub.
Klik her for at læse de tekniske specifikationer for Korrespondancemeddelelsen på GitHub.

table 1 summarizes the requirements and recommendations for sender and receiver systems based on the textual documentation above. For technical details, please refer to the
technical specifications available on the CareCommunication GitHub page..

6 Use Cases

Til brug for den tekniske implementering af Korrespondancemeddelelsen findes use case beskrivelser, som demonstrerer indhold og funktionalitet i Korrespondancemeddelelsen, herunder krav og anbefalinger til afsender- og modtagersystemer. Klik her for at finde use cases.

For the technical implementation of the CareCommunication, use case descriptions are provided to illustrate the content and functionality of the CareCommunication, including requirements and recommendations for sender and receiver systems. Click here to find Use Cases.

7 Ibrugtagning i SOR/SOR-EDI | Implementation in SOR/SOR-EDI

Inden ibrugtagning skal meddelelsestypen for Korrespondancemeddelelse ajourføres i SOR-EDI for den enkelte aktør, så der er valide data om, hvem der har implementeret og anvender Korrespondancemeddelelsen, og derved hvem der kan afsende og modtage Korrespondancemeddelelsen.

Before implementation, the message type for CareCommunication must be updated in SOR-EDI for each actor to ensure valid data regarding who has implemented and is using the CareCommunication, and thereby who can send and receive the CareCommunication.

About

Support or contact

Version of this documentation