HL7
4
0

Scheduling (SIU)

Hoofdstuk 10 van de HL7 standaard beschrijft berichten die dienen om informatie over gebeurtenissen door te geven, die samenhangen met het plannen van afspraken in de context van de gezondheidszorg.

De standaard bevat specificaties voor drie berichtcategorieën, te weten:

Request transactions

Dit betreft verzoeken voor het plannen van afspraken en de reacties daarop door het verwerkende systeem (dit proces is vergelijkbaar met de ordercommunicatie in de hoofdstukken 4 en 7). De verzoekende applicatie wordt in dit verband aangeduid als de placer en de verwerkende applicatie wordt aangeduid als de filler.

Query transactions

Dit betreft berichten voor het actief opvragen van planningsinformatie door een opvragend systeem. De opgevraagde informatie wordt retour verzonden door het verwerkende systeem (de filler).

Unsollicited transactions (notifications)

Dit betreft berichten voor het passief ontvangen van planningsinformatie door een geïnteresseerd systeem. De informatie wordt (ongevraagd) verzonden door het verwerkende systeem (de filler).

Deze berichtspecificaties en implementatierichtlijnen dienen om planningsinformatie te kunnen uitwisselen tussen applicaties. Deze communicatie heeft betrekking op drie belangrijke concepten: agenda’s (schedules), afspraken (appointments) en hulpbronnen (resources). Deze concepten worden kort toegelicht

Schedules

Agenda’s bestaan uit een verzameling roosters voor één of meer schaarse hulpbronnen of diensten. De agendaroosters bestaan daarbij uit een verzameling vrije, gevulde of geblokkeerde afspraakposities (slots).

Eén van de betreffende hulpbronnen is altijd primair (het meest bepalend voor de beschikbaarheid). Deze wordt ook wel aangeduid als de agendahouder. Van de secundaire hulpbronnen wordt vaak impliciet aangenomen dat ze beschikbaar zijn bij een afspraak, zoals een spreekkamer voor een consult of de operateur, anesthesist en omlooppersoneel bij een operatie. Ze kunnen echter ook expliciet gereserveerd worden.

Voorbeelden van agenda’s voor bepaalde hulpbronnen of diensten:

  • De spreekuren voor een medisch specialist (de specialist is dan de primaire hulpbron).
  • De sessieroosters voor een operatiekamer (de OK ruimte is dan de primaire hulpbron).
  • De planning voor de hartfunctieonderzoeken (hartfunctie is dan de primaire hulpbron).

Een hulpbron kan overigens ook primair zijn voor meerdere agenda´s (b.v. specialist met aparte agenda’s voor verschillende locaties). De indeling in agenda´s is dus in zekere zin arbitrair en wordt bepaald door de wijze waarop toewijzing van hulpbronnen is geregeld binnen een afsprakensysteem (filler application).

Services and resources

Hulpbronnen zijn personen, locaties, goederen of diensten waarvoor afspraken gepland worden. De Amerikaanse tekst legt een 1-op-1 relatie tussen een agenda (schedule) en een hulpbron (resource), terwijl we er in de Nederlandse richtlijnen (zoals hierboven reeds geschetst) van uit gaan dat:

  • een agenda kan horen bij een verzameling hulpbronnen (waarvan er één agendahouder is);
  • een hulpbron gepland kan worden in meerdere agenda’s (b.v. een specialist op twee locaties).

Appointments

Afspraken zijn een registratie van de reservering van één of meer posities in een bepaalde agenda. Hierbij worden de gegevens vastgelegd die relevant zijn voor de voorbereiding of uitvoering van de afspraak. Het kan hierbij gaan om consulten, onderzoeken, verrichtingen of zelfs operaties.

Parent and child appointments

Meervoudige afspraken (parent appointments) bestaan uit een aantal deelafspraken (child appointments). Voorbeelden zijn de volgende situaties:

  • Een repeterende afspraak, bv. voor een serie behandelingen volgens een vast patroon.
  • Een gecombineerde afspraak, bv. voor een consult en een onderzoek op dezelfde dag.
  • Een groepsafspraak, waarbij meerdere patiënten tegelijk aan een sessie deelnemen.

Er zijn meerdere manieren om de deelafspraken binnen een meervoudige afspraak te identificeren. Als de placer of de filler afzonderlijke ID’s toekennen aan de deelafspraken, dan kunnen deze ID’s gebruikt worden in transacties. Anders kan het ID van de overkoepelende (meervoudige) afspraak worden gebruikt, waarbij het zogenaamde occurence number wordt gebruikt om de deelafspraken aan te duiden.

In deze versie van de Nederlandse implementatierichtlijnen wordt er nog van uitgegaan dat alleen sprake is van enkelvoudige afspraken. Aspecten in relatie tot parent en child appointments wordt later uitgewerkt.

Application roles

Bij het gebruik van de berichten worden vier rollen onderscheiden die applicaties kunnen hebben. In veel gevallen kan dezelfde applicatie, afhankelijk van de transactie, meerdere rollen hebben.

The filler application role

De verwerkende rol hoort bij een applicatie waarbinnen één of meer agenda’s worden beheerd. De applicatie wordt dan wel de eigenaar van de betreffende agenda’s genoemd (en dus van de bijbehorende dataset).

Binnen de filler zelf kunnen afspraken worden ingevoerd of gewijzigd, waarna deze worden gerapporteerd aan geïnteresseerde systemen. Ook kunnen geïnteresseerde systemen informatie vanuit de agenda’s opvragen bij de filler. Tenslotte verwerkt en beantwoordt de filler aanvragen voor het plannen van afspraken.

Theoretisch kunnen twee verschillende applicaties als filler optreden voor dezelfde agenda (als ze de agenda onderling exact synchroon houden), maar meestal wordt er zelfs dan één als eigenaar gezien.

The placer application role

De verzoekende rol hoort bij een applicatie van waaruit afspraken gepland kunnen worden, maar die zelf geen controle heeft over de betreffende agenda’s. Er wordt dan een aanvraag naar de bijbehorende filler gestuurd om de afspraak in te plannen. Deze rol wordt in de Nederlandse richtlijnen nog niet uitgewerkt.

The querying application role

De opvragende rol hoort bij een applicatie die gegevens wil opvragen over agenda’s en de afspraken daarin. Hierbij worden geen wijzigingen aangebracht of verzocht in de betreffende agenda’s, maar wordt alleen een query gedaan bij de bijbehorende filler.

Overigens komen de rollen van placer en querying application vaak samen voor. De placer vraagt dan eerst een overzicht van de beschikbare afspraakposities voor bepaalde criteria aan de filler, waarna het een aanvraag plaatst voor het boeken van een afspraak op één van deze posities (wat dan waarschijnlijk lukt).

The auxiliary application role

De geïnteresseerde rol hoort bij een applicatie die gegevens wil ontvangen over de afspraken in agenda’s. Dit gebeurt door de updates te verwerken die automatisch door de betreffende fillers worden gestuurd.

Overigens komen de rollen van placer en auxiliary application vaak samen voor. De placer houdt dan een kopie bij van bepaalde agenda’s en houdt deze synchroon door alle updates te verwerken. Bij het plaatsen van een aanvraag is dan vooraf reeds bekend welke afspraakposities nog vrij zijn. In feite kan de placer in zo’n geval fungeren als een (schaduw) filler en wordt vaak niet eens meer request gedaan aan de eigenaar.

Trigger events, statuses, reasons and types

Trigger events

De trigger events (gebeurtenissen die aanleiding geven tot interactie tussen applicaties) zijn opgedeeld aan de hand van de rol van het verzendende systeem. Sectie 10.3 voor placer applications, 10.4 voor filler applications en 10.5 voor querying applications (auxiliary applications genereren zelf geen trigger events).

Statuses

De status van een (al dan niet geplande) afspraak geeft aan in welk stadium deze op dat moment verkeert. Juist als een afspraak van status verandert, zal meestal een trigger event plaatsvinden. De status van een afspraak wordt (vrijwel) altijd bepaald door de filler application en deze genereert dan deze trigger events.

De mogelijke statussen voor een geplande afspraak zijn bijvoorbeeld:

  • Pending en Waitlist
    Deze worden het meest gebruikt bij aanvraag en afhandeling van appointment requests. Afspraken kunnen nog niet zijn bevestigd, maar wel geboekt (Pending), of tijdelijk op een wachtlijst worden geplaatst (Waitlist), bijvoorbeeld omdat een bepaalde resource tijdelijk niet beschikbaar is.
  • Booked
    Dit is de normale status van een geplande afspraak
  • Arrived
    De patiënt is gearriveerd voor de betreffende afspraak maar het afgesproken contact is nog niet begonnen. Dit is van toepassing bij ‘patient tracking’, waarbij een patiënt met deze status normaal gesproken in de wachtkamer is. Deze status komt niet voor in de internationale tekst.
  • Started
    De betreffende afspraak is gestart. Deze is van toepassing bij ´patient tracking´ (spreekkamerbeheer) en bij het toepassen van samengestelde afspraken.
  • Dc
    De betreffende afspraak of serie afspraken is afgebroken nadat deze is begonnen
  • Overbook en Blocked
    Dit zijn kenmerken van de positie in het rooster (slot) en niet van de afspraak zelf. Deze statussen zijn op dit moment dus nog niet aan de orde, maar worden meegenomen zodra in de Nederlandse implementatiegids aandacht wordt besteed aan queries en synchronisatie van agendaroosters.
  • Cancelled en Deleted
    De betreffende afspraak is geannuleerd (‘Cancelled’) voordat deze is begonnen. De betreffende afspraak is verwijderd (‘Deleted’) omdat deze foutief is ingevoerd.
  • Complete en Noshow
    Na afloop van de afspraak is de status completed (als deze heeft plaatsgevonden) of no-show (als de patiënt niet is komen opdagen). Deze laatste komt niet als status voor in de internationale tekst, ook al is er wel reeds een trigger event gedefinieerd voor deze situatie

Reasons

Er wordt in dit hoofdstuk onderscheid gemaakt tussen twee soorten ‘redenen’. De appointment reason geeft aan waarom de afspraak is gemaakt (en de bijbehorende activiteit zal plaatsvinden). Dit is een statisch kenmerk van de geregistreerde afspraak. De event reason geeft aan waarom een bepaald trigger event plaatsvindt. Dit is geen kenmerk van de afspraak, maar van de interactie tussen applicaties.

Types

Er is een subtiel onderscheid tussen de appointment reason en de appointment type. Deze laatste dient om het soort afspraak vast te leggen, maar in de Amerikaanse specificaties is het onderscheid vrij vaag. In de Nederlandse situatie is dan ook besloten om beide begrippen zelf te interpreteren, waarbij de appointment reason wordt gebruikt voor afspraakcodes (bv. herhaalconsult, CT scan etc.) en de appointment type voor een indicatie van de wijze waarop de afspraak is gepland (normaal, spoed, etc.).

Appointments, orders and referrals

Het is belangrijk om een onderscheid te maken tussen afspraak(verzoeken) en orders. Een order begint met een aanvraag voor het verlenen van een bepaalde dienst of het uitvoeren van een bepaald onderzoek. Dit is een procedurele interactie tussen twee eenheden binnen een organisatie. Als voor het uitvoeren van de order een afspraak gemaakt moet worden, dan kan na plaatsing van de order een afspraakverzoek plaatsvinden.

De berichten uit dit hoofdstuk zijn dus geen vervanging voor de berichten uit de hoofdstukken 4 en 7, maar dienen slechts om de interactie met betrekking tot het plannen van afspraken mogelijk te maken. Een order kan al dan niet gevolgd worden door een afspraak en een afspraak kan al dan niet horen bij een order, maar de twee moeten niet met elkaar verward worden.

In de Scheduling berichten kan de relatie van een afspraak met een eventuele bijbehorende order worden aangeduid, door de ID van deze order in het desbetreffende veld te plaatsen (zie de segmentbeschrijvingen).

Overigens is het onderwerp referrals (verwijzingen) nog nauwelijks belicht in de Amerikaanse standaard. In deze implementatiegids wordt hierop verder niet ingegaan. Belangrijk is wel om te benadrukken dat een afspraak niet hetzelfde is als de verwijzing die er aanleiding toe was (zie commentaar over orders hierboven).

Filler application messages and trigger events

Deze categorie berichten wordt gebruikt voor het doen van afspraakverzoeken door een ‘placer’ aan een ‘filler’. De placer kan daarbij elk systeem zijn dat een afspraak wil boeken maar niet zelf de controle heeft over de betreffende agenda. De filler is het afspraaksysteem dat de betreffende agenda beheerd en het verzoek in behandeling neemt. De placer stuurt afspraakverzoeken met behulp van het SRM bericht en de filler reageert hier vervolgens als volgt op:

  • Als de enhanced acknowledgement mode gebruikt wordt, dan wordt een ACK bericht verstuurd om aan te geven dat het afspraakverzoek correct is ontvangen. Dit zegt niets over het boeken van de afspraak.
  • Na verwerking van het afspraakverzoek op applicatieniveau wordt een SRR bericht verstuurd als reactie. Hiermee wordt aangegeven of de afspraak geboekt kon worden, inclusief eventuele bijzonderheden.
    [Let op: in hoofdstuk 10 van de standaard wordt ten onrechte gesproken over een SRM bericht als reactie!]

Het SRR bericht wordt verstuurd als de original acknowledgement mode wordt gebruikt of als in de enhanced acknowledgement mode is aangegeven dat een application acknowledgement gebruikt moet worden. Een SRM bericht zonder SRR bericht als reactie wordt echter niet aanbevolen, omdat de placer dan niets weet over het resultaat van het afspraakverzoek. Zie hoofdstuk 2 voor meer informatie over de acknowledgement modes in HL7.

De verschillende application acknowledgement codes worden voor afspraakverzoeken als volgt geïnterpreteerd:

  • Een application accept (AA) betekent dat het verzoek is verwerkt en ingewilligd door de filler.
  • Een application error (AE) betekent dat het verzoek is verwerkt en afgewezen door de filler.
  • Een application reject (AR) betekent dat het verzoek niet kon worden verwerkt door de filler.

Het SRR bericht zal in het geval van een application accept meer informatie bevatten over het verwerkte verzoek.

Alle trigger events voor afspraakverzoeken en de reacties daarop gebruiken onderstaande berichtopbouw:

Let op! Bovenstaande berichtstructuur wijkt enigszins af van de specificatie in de internationale HL7 standaard. Binnen Nederland zijn de volgende beperkingen aangebracht (overigens binnen de grenzen van de officiële syntax):

  • Het blok met PID, PV1 en PV2 is verplicht (althans PID is verplicht) en mag niet herhalend zijn.
    Gevolg: er kan alleen sprake zijn van patiëntgerelateerde afspraken voor een enkele patiënt.
  • Het ZDB-segment is toegevoegd achter het PV2-segment zoals dat ook in andere berichten gebruik is. Dit maakt het in de toekomst mogelijk om groepsafspraken te maken waarbij de DBC van een patient in de PID groep staat. Momenteel is er nog geen implementatie van bekend van groepsafspraken.
    Let op: er zijn eerdere concept implementatierichtlijnen gemaakt, maar niet officieel gepubliceerd waarin het ZDB-segment achter ARQ (SRM) en SCH (SRR) gestaan heeft. Deze wijziging is daarmee niet compatibel
  • Het blok met het AIG segment is verwijderd. Dit segment werkt eerder verwarrend bij implementaties.
  • Er worden geen APR segmenten (in het SRM bericht) en NTE segmenten (in beide berichten) toegestaan binnen de blokken met de AIS, AIL en AIP segmenten. Planningsvoorkeuren en opmerkingen moeten dus voor de gehele afspraak gelden en worden niet per hulpbron afzonderlijk aangeduid.
  • Een voorbeeld van toepassing van het NTE segment bij de afspraak is de vraagstelling/afspraakreden. In dat geval wordt in NTE-4 Comment type de waarde GR (general reason) gezet. Voor algemene opmerkingen bij de afspraak wordt in NTE-4 Comment type de waarde RE (remark) gezet.

Let op! Het ZDB segment in het SRR bericht (één per geplande afspraak) kan afwijken van de informatie in het afspraakverzoek als b.v. om administratieve redenen een nieuw DBC traject geopend moet (of zal moeten?) worden voor de geplande afspraak. Dit is afhankelijk van de vraag of DBC trajecten al worden geopend op basis van de afspraak of pas op het moment dat het bijbehorende contact heeft plaatsgevonden.

SRM – request new appointment booking (event S01)

Een verzoekend systeem (placer) gebruikt dit trigger event om aan een verwerkend afspraaksysteem (filler) een verzoek te doen voor het boeken van een nieuwe afspraak. Als het verzoek kon worden ingewilligd, verstuurt de filler een bevestiging, waarin optioneel nadere details van de geboekte afspraak zijn opgenomen.

SRM – Request appointment rescheduling (event S02)

Een aanvragend systeem (placer) gebruikt dit trigger event om aan een afspraaksysteem (filler) een verzoek te doen voor het verplaatsen van een bestaande afspraak. In het ARQ-segment worden de nieuwe (gewenste) afspraakdatum/tijd en –duur doorgegeven, alsmede de bestaande placer en filler appointment ID’s. Indien het verzoek kon worden ingewilligd, retourneert de filler een bevestiging, waarin optioneel een SCH-segment en gerelateerde detailsegmenten zijn opgenomen, met de nieuwe informatie voor de verzette afspraak.

Deze transactie moet niet worden gebruikt om een afspraak te verzetten die reeds is begonnen maar niet is geëindigd. In dat soort gevallen, en alleen als dit logisch is om te doen, moet de afspraak afgebroken worden en moet er een verzoek voor een nieuwe afspraak worden verstuurd. Om dezelfde reden moet deze transactie ook niet worden gebruikt om een meervoudige afspraak (parent appointment) te verzetten, waarin één of meerdere deelafspraken reeds zijn begonnen of zijn geweest. Ook in dit geval moet de meervoudige afspraak worden afgebroken en moet er een verzoek voor een nieuwe afspraak worden verstuurd. Deze procedure voorkomt de ambiguïteit tussen applicaties die kan optreden als wordt getracht een lopende afspraak te wijzigen.

SRM – request appointment modification (event S03)

Dit bericht bevat een aanvraag voor de wijziging van een bestaande afspraak voor een afsprakensysteem (filler). Dit trigger event wordt gebruikt om de wijziging van informatie voor een bestaande afspraak te wijzigen, buiten de noodzaak om de afspraak opnieuw in te plannen, te annuleren, af te breken/te verwijderen, of om diensten en/of hulpbronnen te verwijderen van de afspraak. Dit trigger event moet alleen worden gebruikt voor afspraken die nog niet zijn geweest, of voor meervoudige afspraken (parent appointments) waarvan de deelafspraken nog niet zijn voltooid. Indien het verzoek kon worden ingewilligd, retourneert de filler een bevestiging, waarin optioneel een SCH-segment en gerelateerde detailsegmenten zijn opgenomen, met de nieuwe informatie voor de gewijzigde afspraak.

SRM – request appointment cancellation (event S04)

Het trigger event Request appointment cancellation wordt door de aanvragende applicatie (placer) gestuurd naar het afsprakensysteem (filler) om annulering van een bestaande afspraak te vragen. Dit event wordt gebruikt om een geplande afspraak te annuleren. Als bijvoorbeeld een patiënt die is ingepland voor een onderzoek zijn/haar afspraak annuleert, wordt een verzoek om annulering gestuurd. Indien het verzoek kon worden ingewilligd, retourneert de filler een bevestiging, waarin optioneel een SCH-segment en gerelateerde detailsegmenten zijn opgenomen, met de informatie voor de geannuleerde afspraak.

Dit trigger event kan worden gebruikt om een meervoudige afspraak (parent appointment) te annuleren, waarin geen van de deelafspraken van deze afspraak is begonnen of voltooid. Alle bestaande deelafspraken op de filler en placer applicaties moet worden beschouwd als geannuleerd. Als één of meerdere deelafspraken reeds zijn begonnen, dan moet dit trigger event niet worden gebruikt. In plaats daarvan moet het S05 (Request appointment discontinuation) event worden gebruikt.

SRM – request appointment discontinuation (event S05)

Het trigger event Request Appointment Discontinuation wordt door de aanvragende applicatie (placer) naar het afsprakensysteem om te vragen of een afspraak die al bezig is kan worden gestopt, of dat de resterende voorkomens van een meervoudige afspraak niet doorgaan zoals gepland. Als geen van de deelafspraken van een meervoudige afspraak nog heeft plaatsgevonden, dan moet in plaats hiervan een Cancel event worden gestuurd. Indien succesvol, wordt een bevestigingsbericht teruggestuurd, optioneel met een SCH-segment en gerelateerde detailsegmenten die de gestopte afspraak omschrijven.

SRM – request appointment deletion (event S06)

Het trigger event Request Appointment Deletion wordt gestuurd door de aanvragende applicatie naar het afsprakensysteem om te vragen of een afspraak die foutief is ingevoerd kan worden verwijderd van het systeem. Een delete-trigger mag alleen worden gebruikt wanneer een afspraak foutief is aangevraagd en moet worden verwijderd uit de agenda zodat het statistische verwerking niet beïnvloedt. Een delete-trigger verschilt van een cancel-trigger in dat een delete dient om een fout te verwijderen, terwijl een cancel voorkomt dat een geldig verzoek ten uitvoer wordt gebracht. Dit trigger event mag niet worden gebruikt voor een afspraak die al is begonnen, of al voltooid is. Ook mag het niet worden gebruikt voor meervoudige afspraken als één of meerdere van de deelafspraken al is begonnen of voltooid. Indien succesvol, wordt een bevestigingsbericht teruggestuurd, optioneel met een SCH-segment en gerelateerde detailsegmenten die de verwijderde afspraak omschrijven

De delete-trigger moet na zorgvuldige overweging worden geïmplementeerd, omdat het typisch verschillende uitwerking en bijeffecten kan hebben in verschillende applicaties. In sommige applicaties, kan een delete event niet ongedaan gemaakt worden. Dat betekent dat als een delete event onterecht is verstuurd, het herstel moeilijk of onmogelijk is. In andere applicaties, zal een delete transactie niet resulteren in de fysieke verwijdering van het record/de records, maar een status zetten of een markering. In deze gevallen zullen de identificaties van het afspraaksysteem en/of aanvragende system (de nummers of codes die de geplande afspraak of het verzoek uniek identificeren voor het afspraaksysteem of het aanvragende systeem) waarschijnlijk niet hergebruikt kunnen worden. Aangezien deze applicaties verwijderde afspraken bijhouden, zal het hergebruik van een identificatie waarschijnlijk leiden tot een conflict in de verwerking van transacties door de applicatie.

SRM – request addition of service/resource on appointment (event S07)

SRM – request modification of service/resource on appointment (event S08)

SRM – request cancellation of service/resource on appointment (event S09)

SRM – request discontinuation of service/resource on appointment (event S10)

SRM – request deletion of service/resource on appointment (event S11)

Filler application messages and trigger events unsollicited

Deze categorie berichten is uitgekozen voor de eerste Nederlandse implementatierichtlijnen. Het is bekend dat er al diverse implementaties zijn, waarbij voor zover bekend sprake is van twee soorten toepassingen:

  • Een afsprakensysteem houdt geïnteresseerde systemen op de hoogte, door van alle mutaties in de betreffende agenda’s een automatisch mutatiebericht (‘unsolicited update’) te versturen. Voorbeelden van geïnteresseerde systemen bij deze toepassingsvorm kunnen b.v. zijn:
    • Een EPD systeem, dat de patiëntafspraken wil kunnen tonen als onderdeel van diens informatie.
    • Een archief beheer systeem, dat de geregistreerde afspraken omzet in aanvragen voor dossiers.
    • Een zogenaamd patient tracking systeem, dat route- en uitloopinformatie levert aan patiënten.
  • Twee afsprakensystemen houden hun agenda’s onderling synchroon. Deze toepassing is iets minder conventioneel, maar kan bijvoorbeeld worden toegepast in het volgende scenario: Een ziekenhuis heeft zowel een centraal afsprakensysteem, waarin alle poliklinische afspraken worden bijgehouden, als een radiologie informatie systeem, waarin de afspraken voor de röntgenafdeling staan. Nu bestaat er een behoefte om vanuit het centrale systeem combinatieafspraken te kunnen plannen voor patiënten die zowel bij b.v. orthopedie als bij radiologie langs moeten komen. Dit kan worden bereikt door een request/response koppeling te implementeren, maar dit vereist een erg complexe interactie tussen beide afspraakmodules.Daarom wordt vaak gekozen voor een oplossing waarbij een kopie van de röntgenagenda’s wordt bijgehouden binnen het centrale afsprakensysteem. Elke keer als een mutatie plaatsvindt in deze agenda’s, kan er dan een HL7 bericht naar het andere systeem worden verstuurd (dus vanuit radiologie systeem naar centraal afsprakensysteem en andersom). Als dit consequent gebeurt, dan kan binnen het centrale afsprakensysteem met de röntgenagenda’s worden gewerkt alsof ze bij het systeem zelf horen. Met andere woorden, er kunnen direct combinatieafspraken gemaakt worden.Randvoorwaarde voor bovenstaande werkwijze is wel dat niet alleen de afspraakmutaties, maar ook alle mutaties aan de roosters voor de betreffende agenda’s worden doorgegeven. Deze roosterwijzigingen (waar ook blokkeringen van afspraakposities of dagdelen onder vallen) vinden alleen plaats in het origineel dat beheerd wordt door de röntgenafdeling, maar moeten direct verwerkt worden in de synchrone kopie, om te voorkomen dat een afspraak wordt gemaakt op een geblokkeerde plaats. Deze roostersynchronisatie vindt meestal plaats door middel van een handmatige procedure.

Alle interacties in deze categorie bestaan uit een SIU-bericht dat door een afspraaksysteem (‘filler application’) wordt verzonden. Het geïnteresseerde systeem (of ander afsprakensysteem) antwoordt met een ACK bericht.

Alle trigger events voor unsolicited updates vanuit afsprakensystemen gebruiken onderstaande berichtopbouw:

Let op! Bovenstaande berichtstructuur wijkt enigszins af van de specificatie in de internationale HL7 standaard. Binnen Nederland zijn de volgende beperkingen aangebracht (overigens binnen de grenzen van de officiële syntax):

  • Het blok met PID, PD1, PV1 en PV2 is verplicht (althans PID is verplicht) en mag niet herhalend zijn. Gevolg: er kan alleen sprake zijn van patiëntgerelateerde afspraken voor een enkele patiënt.
  • Het ZDB-segment is toegevoegd achter het PV2-segment zoals dat ook in andere berichten gebruik is. Dit maakt het in de toekomst mogelijk om groepsafspraken te maken waarbij de DBC van een patient in de PID groep staat. Momenteel is er nog geen implementatie van bekend van groepsafspraken.
    Let op: er zijn eerdere concept implementatierichtlijnen gemaakt, maar niet officieel gepubliceerd waarin het ZDB-segment achter ARQ (SRM) en SCH (SRR) gestaan heeft. Deze wijziging is daarmee niet compatibel
  • Het blok met het AIG segment is verwijderd. Dit segment werkt eerder verwarrend bij implementaties.
  • Daarnaast is het ZDB segment (specifiek voor Nederland) toegevoegd. Dit segment is beschreven in HL7 Versie 2.4 bijlage 1-NL.
  • Een voorbeeld van toepassing van het NTE segment bij de afspraak is de vraagstelling/afspraakreden. In dat geval wordt in NTE-4 Comment type de waarde GR (general reason) gezet. Voor algemene opmerkingen bij de afspraak wordt in NTE-4 Comment type de waarde RE (remark) gezet.

SIU/ACK – notification of new appointment booking (event S12)

Dit bericht wordt verzonden als een nieuwe afspraak is geboekt.

SIU/ACK – notification of appointment rescheduling (event S13)

Dit bericht wordt verzonden als een bestaande afspraak is verplaatst.

Deze trigger wordt in de Nederlandse situatie gebruikt om door te geven dat een afspraak is verzet m.b.t. datum en/of tijd, maar ook om aan te geven dat de agenda waarin de afspraak is geboekt is gewijzigd. Indien de afspraak wordt verzet naar een andere agenda, betekent dit ook een wijziging van het SCH-5 Schedule ID.

SIU/ACK – notification of appointment modification (event S14)

Dit bericht wordt verzonden als een bestaande afspraak is gewijzigd.

Deze trigger wordt gebruikt voor alle wijzigingen in de afspraakgegevens die niet als een ‘rescheduling’ worden beschouwd (zie hierboven).

Tevens kan deze trigger worden gebruikt als een afspraak wordt geparkeerd om opnieuw gepland te worden, bijvoorbeeld als gevolg van roosterwijzigingen. In afwachting van een nieuwe afspraakdatum/-tijd wordt bij de afspraak tijdelijk SCH-25 ‘Filler status code’ op status ‘WAITLIST’ gezet. De oude afspraakdatum/-tijd blijft staan in SCH-11 ‘Appointment timing quantity’. Op een later moment zal dit worden gevolgd door een S13 bericht met de nieuwe afspraakdatum/-tijd.

De afzonderlijke trigger events voor wijzigingen in de ‘resources’ die bij de afspraak betrokken (zullen) zijn, worden op dit moment nog niet gebruikt in Nederland. Als dit op een later moment nodig mocht zijn, dan volgen hiervoor aanvullende richtlijnen in deze gids.

SIU/ACK – notification of appointment cancellation (event S15)

Dit bericht wordt verzonden als een bestaande afspraak is geannuleerd.

In de Nederlandse situatie wordt geen expliciet onderscheid gemaakt tussen een ‘cancel’ (afspraak gaat niet door) en een ‘delete’ (afspraak was een invoerfout). Alle situaties waarbij een eerder geboekte afspraak wordt geannuleerd, worden met deze trigger event afgehandeld. De reden hiervoor is dat ontvangende systemen meestal toch geen onderscheid maken (afgezien van het registreren van de annuleringsreden).

SIU/ACK – notification of appointment discontinuation (event S16)

SIU/ACK – notification of appointment deletion (event S17)

SIU/ACK – notification of addition of service/resource on appointment (event S18)

SIU/ACK – notification of modification of service/resource on appointment (event S19)

SIU/ACK – notification of cancellaton of service/resource on appointment (event S20)

SIU/ACK – notification of discontinuation of service/resource on appointment (event S21)

SIU/ACK – notification of deletion of service/resource on appointment (event S22)

SIU/ACK – notification of blocked schedule time slot(s) (event S23)

SIU/ACK – notification of opened (unblocked) schedule time slot(s) (event S24)

SIU/ACK – notification that patient did not show up for scheduled appointment (event S26)

Dit bericht wordt verzonden als een patiënt niet is verschenen voor diens afspraak.

In tegenstelling tot de eerdere trigger events is dit niet zozeer een afspraakmutatie, maar een gevolg van de administratieve afhandeling van de betreffende agenda. De registratie van het niet verschijnen van patiënten vindt meestal plaats als onderdeel van de zogenaamde spreekuurafhandeling, waarbij ook de financieel-administratieve consequenties van afspraken die wel zijn doorgegaan worden vastgelegd.

In zekere zin is dit bericht complementair op de toepassing van ADT bericht voor het doorgeven van uitgevoerde poliklinische consulten of andere patiëntcontacten die (al dan niet naar aanleiding van een afspraak) hebben plaatsgevonden. Deze ADT berichten geven dan het omzetten van de afspraak in een feitelijk consult aan, terwijl event S26 juist wordt gebruikt om aan te geven dat dit consult niet heeft plaatsgevonden.

Soortgelijke Berichten

Geef een reactie

Het e-mailadres wordt niet gepubliceerd. Vereiste velden zijn gemarkeerd met *

Fill out this field
Fill out this field
Geef een geldig e-mailadres op.
Je moet de voorwaarden accepteren voordat je het bericht kunt verzenden.

Meest Bekeken Berichten

Menu