Ohne Vorkenntnisse lesbar
Der coderis-Vermittler bringt Bestellung und Fahrdienst zusammen – über eine verabredete, gemeinsame Sprache: Alle Beteiligten – Klinik, Vermittler und Fahrdienst – meinen damit garantiert dieselbe Fahrt. Diese Seite erklärt ohne Fachjargon, wie aus einer Bestellung eine Fahrt wird, wie die Plattform den passenden Betreiber findet und wer wann welche Daten zu sehen bekommt.
Die Idee in einem Bild
Eine Fahrt zu bestellen heißt heute meistens: telefonieren, bis jemand Ja sagt. Die Schnittstelle dreht das um – die Anfrage geht einmal raus und erreicht alle, die sie tatsächlich fahren können.
Ohne Schnittstelle
Mit Schnittstelle
Der Vermittler disponiert dabei nicht. Er sorgt dafür, dass die richtige Anfrage bei den richtigen Betreibern landet – welches Fahrzeug am Ende fährt, entscheidet der Betreiber in seiner eigenen Disposition.
Die fünf Bausteine
Die gesamte Schnittstelle besteht aus fünf Themen. Wer eine Software anbindet, braucht selten alle fünf – ein Bestellsystem kommt meist mit den ersten drei aus, eine Fahrdienst-Disposition mit den letzten beiden. Der allgemeine Personentransport durchläuft dieselben Themen als eigene Auftragsfamilie mit eigenen, zur Fahrtfamilie passenden Feldern.
Damit alle Beteiligten dasselbe meinen, kommen die verbindlichen Auswahllisten von der Plattform – etwa der Katalog der Infektionsangaben. Kein Abtippen, keine hausgemachten Kürzel.
Hin- und Rückfahrt gehören zu einer Bestellung, sind aber getrennt disponierbar. Zeiten und Kostenträgerangaben lassen sich nachziehen, stornieren geht, solange die Fahrt nicht abgeschlossen ist.
„Ginge morgen 9 Uhr überhaupt?“ – eine kurze Momentaufnahme über alle geeigneten Betreiber, ohne dass eine Bestellung entsteht. Es wird nichts reserviert; die Verfügbarkeit wird bei der echten Bestellung erneut geprüft.
Die Betreiberseite: offene Angebote abrufen, annehmen oder ablehnen – und beim Ablehnen gleich sagen, wann es stattdessen ginge. Erst der Gewinner sieht die vollständigen Fahrtdaten.
Der Betreiber meldet, was passiert – Fahrzeug unterwegs, angekommen, Fahrt beendet. Die Plattform reicht das signiert an den Besteller weiter, ohne dass jemand nachfragen muss.
Eine Fahrt von vorn bis hinten
Ein Pflegeheim braucht für Herrn M. eine Fahrt zur Dialyse: sitzend, im eigenen Rollstuhl, zulasten der Krankenkasse. So läuft das durch die Plattform – darunter jeweils der Name, unter dem die Meldung technisch ankommt.
Das Heim erfasst Abhol- und Zielort, Zeitfenster, Bedarf und Kostenträger. Die Plattform prüft die Angaben sofort auf Vollständigkeit und Plausibilität – unvollständige Bestellungen fallen hier auf, nicht erst am Bordstein.
booking.requested
Jetzt greifen die Vermittlungsregeln und der Fähigkeiten-Abgleich (siehe unten). Ergebnis ist eine geordnete Kandidatenliste – wer gefragt wird, in welcher Reihenfolge, und mit welcher Entscheidungsfrist.
booking.dispatching
In der Disposition der Fahrdienste erscheint die Anfrage – ohne Personendaten, mit einer festen Frist. Wer nicht kann, lehnt ab und schlägt bei Bedarf andere Zeiten vor.
proposal.offered
Die erste gültige Zusage gewinnt. Alle anderen offenen Angebote für diese Fahrt erlöschen im selben Moment – niemand disponiert versehentlich gegen einen bereits vergebenen Auftrag. Erst jetzt bekommt der Gewinner die vollständigen Fahrtdaten.
booking.confirmed · proposal.withdrawn
Der Betreiber ordnet in seiner eigenen Disposition ein Fahrzeug zu und meldet das zurück. Welches Fahrzeug das ist, entscheidet ausschließlich er.
booking.assigned
Losgefahren, vor Ort, Fahrt begonnen, Fahrt beendet – jede Station meldet sich beim Besteller. Verschiebt sich die Ankunft, kommt eine aktualisierte Zeit hinterher, statt dass jemand anruft.
vehicle.enroute · vehicle.arrived · trip.started ·
trip.completed
Auch die unangenehmen Fälle haben einen definierten Weg: Wenn alle Betreiber zum
Wunschtermin ablehnen, aber Alternativen vorschlagen, bekommt der Besteller diese
gebündelt zur Auswahl (booking.time_alternatives_available). Findet sich
niemand, sagt die Plattform das ausdrücklich und mit Grund
(booking.not_served) – etwa „kein geeigneter Betreiber“, „alle abgelehnt“
oder „Frist abgelaufen“. Ein stiller Nicht-Zustand, in dem eine Bestellung einfach liegen
bleibt, existiert nicht.
Der Dispatcher
Das ist das Herzstück – und bewusst keine Blackbox. Die Auswahl läuft in zwei Etappen: Erst legen die Regeln fest, wer überhaupt gefragt wird und in welcher Reihenfolge. Dann prüft die Plattform Betreiber für Betreiber, wer die Fahrt tatsächlich leisten kann.
Eine Region wird über Regeln abgebildet, die der Reihe nach abgearbeitet werden. Jede Regel
beschreibt, worauf sie zutrifft – etwa Abhol- oder Zielpostleitzahl (auch als Bereich,
40* für ganz Düsseldorf), Transportklasse, Beförderungsart, bestimmte Bedarfe,
ein bestimmter Besteller, Wochentage oder Uhrzeiten. Und sie beschreibt, was dann passieren
soll: welche Betreiber gefragt werden, in welcher Reihenfolge, mit welcher Frist.
So lassen sich gewachsene Absprachen abbilden, statt sie wegzustandardisieren: „Dialysefahrten am Wochenende zuerst an den örtlichen Fahrdienst, danach an den Rest“ ist eine Regel, keine Sonderentwicklung.
Jeder Betreiber hinterlegt, was er kann – als Fahrzeugprofile mit Transportklassen, Beförderungsarten, abgedeckten Bedarfen, Kostenträgern und Einsatzgebieten. Bevor ein Angebot überhaupt entsteht, hält die Plattform die Fahrt gegen diese Profile. Sechs Fragen, und bei jeder kann jemand ausscheiden:
Ohne aktive Anbindung gibt es niemanden, der das Angebot entgegennehmen könnte.
Ein qualifizierter Krankentransport (QUALIFIED_KTW) verlangt ein Profil, das
genau das führt. Eine einfache Krankenfahrt
(UNQUALIFIED_KRANKENFAHRT) ist etwas anderes – einen stillen Fallback in die
jeweils andere Klasse gibt es nicht.
Gefordert ist Taxi, Mietwagen oder KTW. Wer „Taxi oder Mietwagen“
(TAXI_OR_HIRE_CAR) anbietet, deckt damit auch die konkrete Taxi- oder
Mietwagenanfrage ab. Für KTW gilt das nicht: Den kann nur, wer ihn
ausdrücklich führt.
Liegend, Tragestuhl, eigener Rollstuhl, Begleitperson, Einstiegshilfe – jeder Bedarf ist ein eigenes Muss-Kriterium.
Wichtig: Ein einzelnes Fahrzeugprofil muss alle Bedarfe gleichzeitig abdecken. Zwei Profile, die sich die Anforderungen aufteilen, zählen nicht – es fährt schließlich auch nur ein Fahrzeug.
Der Betreiber muss den Kostenträger der Fahrt bedienen – gesetzliche Kasse, privat, Selbstzahler oder sonstiger Träger. Rechnet er direkt mit dem Kostenträger ab, kommt mehr dazu: das passende Institutionskennzeichen, das regionale Abrechnungsprofil in genau der geforderten Fassung und der vereinbarte Weg, auf dem die Versichertendaten zustande kommen.
Die Abholung – und je nach Regel auch das Ziel – muss in einem hinterlegten Postleitzahlgebiet des Betreibers liegen.
Wer alle sechs Fragen besteht, wird Kandidat. Alle anderen scheiden mit einer festgehaltenen Begründung aus – und genau das macht den Unterschied zu einer Blackbox: Zu jeder Fahrt lässt sich nachlesen, welche Regel gegriffen hat, wer Kandidat war und woran es bei den übrigen gescheitert ist.
Für den allgemeinen Personentransport gilt derselbe Mechanismus mit einem eigenen Fragenkatalog gleicher Härte: Statt Transportklasse und Kostenträger zählen dort Taxi-/Mietwagen-Profil, Sitz- und Rollstuhlplätze, Kindersitze, Gepäck, Servicebedarfe und der Zahlweg – und auch dort muss ein einzelner Betreiber alles gleichzeitig abdecken.
Datenschutz im Ablauf
Für die Frage „kann ich das fahren?“ braucht niemand den Namen des Patienten. Deshalb ist die Ausschreibung datensparsam – die Personendaten folgen erst dem Zuschlag.
Vor dem Zuschlag sieht jeder gefragte Betreiber
Erst der Gewinner bekommt zusätzlich
Wer nicht gewinnt, behält nichts als die Information, dass die Anfrage erledigt ist.
Wenn der Wunschtermin nicht geht
Ein „geht nicht“ ist selten die ganze Wahrheit – meistens heißt es „nicht um 9, aber um 11“. Genau dafür gibt es den strukturierten Gegenvorschlag.
Betriebssicherheit
Das sind die unspektakulären Eigenschaften, die man erst vermisst, wenn sie fehlen – hier ohne Fachjargon.
Jede Bestellung trägt ein eindeutiges Kennzeichen. Wird sie nach einem Verbindungsabbruch erneut gesendet, erkennt die Plattform sie wieder und legt keine zweite Fahrt an – der Klassiker, aus dem sonst zwei Fahrzeuge vor derselben Tür stehen.
Wer eine Fahrt ändert, sagt dabei, auf welchen Stand er sich bezieht. Hat inzwischen jemand anderes etwas geändert, wird die Änderung abgelehnt statt still überschrieben.
Jede Statusmeldung an ein Bestellsystem ist signiert und mit Zeitstempel versehen. Das empfangende System kann prüfen, dass die Meldung echt ist und nicht nachträglich verändert oder erneut eingespielt wurde.
Jeder Vorgang trägt dieselbe Kennung vom Bestellsystem über die Plattform bis in die Disposition. Wenn etwas hakt, muss niemand raten, welche Fahrt gemeint war.
Angebundene Systeme dürfen unbekannte Zusatzangaben in Antworten schlicht ignorieren. Neue Felder kommen also, ohne dass eine bestehende Anbindung dadurch stehen bleibt – Pflichtangaben in eine Richtung werden dagegen nie stillschweigend verschärft. Wer heute anbindet, muss nicht bei jedem Release nachziehen.
Nächster Schritt
Technische Details, Felder und die vollständige Referenz finden Sie im Schnittstellen-Bereich.
