Wiki - Chris Seyboth

Der Zeitstempel ist zwei Aussagen

15 Min. Lesezeit

Konzept: Ein Zeitstempel behauptet zweierlei

Eine Zeitangabe in einer HL7-v2-Nachricht sieht aus wie eine einzelne Information. Sie ist zwei voneinander unabhängige Aussagen:

AussageWo sie stecktFehlerbild
Welcher Augenblick?im Wert — Ziffernfolge plus Offsetder bezeichnete Augenblick ist ein anderer als der gemeinte
Welches Ereignis?im Feld, in dem der Wert stehtder Augenblick stimmt, beschreibt aber ein anderes Ereignis

Beide können unabhängig voneinander falsch sein, und keine der beiden ist validierbar: Jede syntaktisch korrekte Ziffernfolge im richtigen Feld passiert Parser, Schema und Konformitätsprofil.

Ein Zeitstempel ist keine Zahl. Er ist eine Behauptung über einen Augenblick — und eine zweite darüber, was in diesem Augenblick geschehen sein soll.

Drei Begriffe, die auseinandergehalten werden müssen

BegriffWas es istBeispiel
Augenblick (Instant)ein Punkt auf der physikalischen Zeitachse. Hat keine Uhrzeit.„als der Patient durch die Tür kam”
Zoneeine Funktion vom Datum, die einen Offset liefertEurope/Berlin(18.08.) = +02:00, Europe/Berlin(12.01.) = +01:00
DarstellungAugenblick + Zone → Ziffernfolge„23:30”

Ein Zeitstempel in einer Nachricht ist eine Darstellung. Um daraus einen Augenblick zu machen, braucht man den Offset. Genau dafür ist er da: Der Offset sagt, welchen Nullpunkt die Ziffern haben.

Die beiden Rechenrichtungen — hier sitzt die Vorzeichenfalle:

Sender:     Augenblick = Ziffern − Offset
Empfänger:  Ziffern    = Augenblick + Offset(Zielzone, Datum)

+0200 heißt „zwei Stunden vor UTC”. Wer vorne liegt, muss abziehen, um auf UTC zu kommen. Daraus die Kurzform für jede Fehlersuche:

angezeigte Ziffern = gesendete Ziffern + (Offset_Ziel − Offset_gesendet)

Ein zu kleiner Offset im Sender verschiebt die Anzeige beim Empfänger nach hinten, und zwar um die Differenz der Offsets. Ein zu großer verschiebt sie nach vorn. Die Minuten wandern dabei nicht mit — außer bei Offsets, die keine vollen Stunden sind (+0530, +0545, −0330). Eine Prüfroutine, die „nur die Stunde vergleicht”, ist bei mitteleuropäischen Häusern jahrelang unauffällig und fällt beim ersten internationalen Datensatz um.

Die erste Aussage: der Wert

Der Datentyp DTM hat das Format

YYYY[MM[DD[HH[MM[SS[.S[S[S[S]]]]]]]]][+/-ZZZZ]

Die Genauigkeit steckt in der Anzahl der Ziffern. Es gibt kein separates Feld dafür — die Länge ist die Angabe.

Ziffern (ohne Offset)Genauigkeit
4Jahr
6Monat
8Tag
10Stunde
12Minute
14Sekunde
16Zehntelsekunde
19Zehntausendstelsekunde

Daraus eine Regel, die beim Import regelmäßig verletzt wird: 20260818 und 20260818000000 sind verschiedene Aussagen. Das erste sagt „an diesem Tag, Uhrzeit unbekannt”, das zweite sagt „um Mitternacht”. Ein Cast auf ein Datenbankfeld mit fester Genauigkeit erfindet stillschweigend die zweite Aussage. Wer darauf eine Frist rechnet, rechnet ab Mitternacht.

Der Offset ist optional:

„The time zone (+/-ZZZZ) is represented as +/-HHMM offset from Coordinated Universal Time (UTC).” „If the time zone is not included, the time zone defaults to that of the local time zone of the sender.” „The HL7 Standard strongly recommends that all systems routinely send the time zone offset but does not require it.”

Drei Folgerungen:

  1. Ein Offset ist kein Zeitzonenname. +0200 sagt „zwei Stunden vor UTC”, nicht „Europe/Berlin”. Aus dem Offset allein lässt sich nicht rekonstruieren, welcher Zone der Sender folgt — nur, wie weit er in diesem Augenblick von UTC entfernt war.
  2. Fehlt der Offset, gilt eine Angabe, die in der Nachricht nicht vorkommt — die lokale Zeitzone des Senders. Der Empfänger muss sie aus einer Quelle außerhalb der Nachricht kennen.
  3. Eine Nachricht ohne Offset ist konform. Wer sie zurückweist, verletzt den Standard; wer sie annimmt, rät. Zwischen beiden Möglichkeiten steht nichts als eine Vereinbarung — dieselbe Lage wie bei Z-Segmenten.

Typangabe je Version

In HL7 v2.5.1 tragen die Zeitfelder den Typ TS mit den Komponenten TS.1 Time (Typ DTM) und TS.2 Degree of Precision. In den refaktorierten Fassungen ist TS entfallen; die Felder tragen direkt DTM. An der Offsetregel ändert das nichts.

Der Default-Vertrag auf Nachrichtenebene

Zur Definition von MSH-7 gehört ein Satz, der leicht überlesen wird:

„This field contains the date/time that the sending system created the message. If the time zone is specified, it will be used throughout the message as the default time zone.”

Damit ist die Auflösung hierarchisch:

Offset am Feld   >   Offset in MSH-7   >   „lokale Zeitzone des Senders"
   (explizit)         (Nachrichten-Default)      (steht nirgends)

Zwei praktische Konsequenzen, und die zweite entscheidet regelmäßig Tickets:

  • Ein Zeitstempel mit eigenem Offset ist von MSH-7 vollständig unabhängig. MSH-7 zu reparieren ändert an ihm nichts — auch dann nicht, wenn ein Empfänger MSH-7 auswertet. Ein Default greift nur, wo nichts anderes steht.
  • MSH-7 ohne Offset ist ein latenter Defekt: Solange jeder fachliche Zeitstempel seinen eigenen Offset trägt, wirkt er nicht. Er wird in dem Augenblick wirksam, in dem irgendein ausgewertetes Feld ohne Offset ankommt — ohne dass jemand etwas geändert hätte.

Für die Fehlersuche folgt daraus eine Reihenfolge: Erst prüfen, ob das symptomtragende Feld einen eigenen Offset hat. Wenn ja, ist MSH-7 als Ursache erledigt — unabhängig davon, wie das Zielsystem gebaut ist. Diese Begründung folgt aus dem Standard und hält auch dann, wenn sich die Implementierung ändert.

Die zweite Aussage: welches Ereignis?

Eine ADT-Nachricht trägt bis zu vier Zeitpunkte, und sie meinen Verschiedenes.

FeldBedeutungUhr
MSH-7„the date/time that the sending system created the message”Kommunikationsstack
EVN-2 Recorded Date/Timewann das Ereignis erfasst wurde. „Most systems will default to the system date/time when the transaction was entered, but they should also permit an override.”Arbeitsplatz im Sendesystem
EVN-6 Event Occurred„This field contains the date/time that the event actually occurred.”fachliche Uhr
PV1-44 Admit Date/TimeAufnahmezeitpunkt des Aufenthaltsfachliche Uhr
  • MSH-7 ist nie ein fachlicher Zeitpunkt. Eine Zeitleiste, die aus MSH-7 gespeist wird, zeigt an, wann eine Nachricht erzeugt wurde. Bei Nachbuchungen ist das nachts um drei.
  • EVN-2 ist der Erfassungs-, nicht der Ereigniszeitpunkt. Der Nachtrag einer Aufnahme von gestern trägt hier korrekt das Datum von heute.
  • EVN-6 beantwortet die fachliche Frage — und ist optional.
  • Bei Storno-Events dreht sich die Bedeutung: „On a cancellation event, this field should contain the date/time that the event being cancelled occurred.” EVN-6 einer Storno-Nachricht trägt also den Zeitpunkt der stornierten Bewegung. Zusammen mit dem Ausgangsort in PV1-3 (siehe 08-Storno ist kein Rollback) ergibt das zwei schwache Indizien auf die gemeinte Bewegung — und keinen Bewegungsbezeichner.

Frage fürs Schnittstellenkonzept, die in fast keinem steht: Aus welchem Feld nimmt das Zielsystem den Zeitpunkt, den es anzeigt — und was tut es, wenn dieses Feld fehlt?

Zwei unabhängige Konfigurationen im Sender

Der häufigste Kurzschluss in der Diagnose ist, von der Systemzeit auf den Offset zu schließen. Es sind zwei getrennte Dinge:

steuerttypischer Zustand
Zeitzone von OS / Anwendungwelche Ortszeit angezeigt und gespeichert wirdmeist korrekt, wird ständig von Menschen kontrolliert
Schnittstellen-Serialisierungwelcher Offset in die Nachricht geschrieben wirdselten kontrolliert, oft ein fester Konfigurationswert

Ein System kann perfekt auf Europe/Berlin stehen — Anzeige stimmt, Uhr stimmt, Umstellung funktioniert — und trotzdem im Schnittstellenadapter einen festen Offset-String führen. Das ist der Normalfall des Fehlerbilds, nicht die Ausnahme.

Praxisfolge: Die Frage „läuft Ihre Systemzeit korrekt?” klärt den Fall nicht. Sie wird wahrheitsgemäß mit „ja” beantwortet, und der Fehler bleibt.

Warum Offsetfehler saisonal sind

Ein Sendesystem kann den Offset auf zwei Arten erzeugen:

  • aus der Zeitzone, zum Ereigniszeitpunkt ausgewertet, oder
  • aus einer Konfiguration, in der ein fester Wert steht.

Beide liefern in einem halben Jahr dasselbe Ergebnis. Sie divergieren zwischen dem letzten Sonntag im März und dem letzten Sonntag im Oktober.

  • Ein Offsetfehler, der bei einem Winter-Go-Live nicht auffällt, ist nicht abwesend, sondern schlafend. Er wacht Ende März auf, ohne dass jemand etwas deployt hat. Bei Zeitproblemen ist seit wann? deshalb die erste Frage, und „seit dem Wochenende Ende März” ist bereits eine vollständige Diagnose.
  • Wer nur im Sommer testet, findet den umgekehrten Fehler nie. Ein fest auf +0200 konfigurierter Sender ist von April bis Oktober unauffällig.
  • Die Umstellungsnächte sind ein eigener Fall. Im Herbst existiert eine lokale Stunde zweimal: Ohne Offset ist ein Zeitstempel aus dieser Stunde objektiv mehrdeutig — zwei verschiedene Augenblicke schreiben dieselbe Ziffernfolge. Im Frühjahr fehlt eine Stunde ganz. Das ist der einzige Fall, in dem ein fehlender Offset nicht nur geraten, sondern prinzipiell unauflösbar ist.

Die Bauweise hinterlässt keine Spur

Der entscheidende diagnostische Befund, und er ist unbequem:

Zwei Sender — einer mit Zonenableitung, einer mit festem Wert — erzeugen in der Jahreshälfte, in der beide übereinstimmen, byte-identische Nachrichten.

Aus einer einzelnen Nachricht ist die Bauweise nicht ableitbar, nicht messbar, nicht prüfbar. Ein Vergleich zweier Fälle aus verschiedenen Jahreszeiten ist deshalb kein Zufallsfund, sondern das einzige Verfahren, das die beiden Bauweisen aus den Daten unterscheidet — und selbst das zeigt nur, dass etwas nicht stimmt, nicht warum.

Daraus folgt, was eine Frage an die Kunden-IT klären muss: nicht die Wirkung (die rechnet man aus), sondern die Bauweise (die weiß nur der Sender).

Warum keine Validierung das findet

PrüfebeneFindet einen falschen Offset?
Parser / Syntaxnein
Schema / Datentypnein — +0100 ist eine gültige Offsetform
Konformitätsprofilnein — es gibt keinen Wertevorrat für „richtiger Offset”
Fachliche Plausibilisierungnur, wenn die Verschiebung eine Grenze überschreitet

Ein falscher Offset erzeugt einen Zeitpunkt innerhalb jedes zulässigen Bereichs. Genau deshalb ist dieser Defekt so langlebig.

Ein Zeitfehler wird nicht dadurch sichtbar, dass er groß ist, sondern dadurch, dass er etwas kreuzt. Eine Stunde um 23:30 ist auffälliger als drei Stunden am Mittag.

Prüfbarkeit ist keine Eigenschaft der Ebene. Ein fehlerhafter Wert ist manchmal gegen eine Liste prüfbar (ein Code außerhalb eines vereinbarten Vorrats, siehe 12-Das Z-Kürzel ist kein Namensraum) und manchmal gegen gar nichts. Beim Offset gibt es keine Liste: Jeder Wert von −1200 bis +1400 ist gültig, und welcher der richtige ist, ergibt sich erst aus Ort und Datum — der Ort steht in der Nachricht nirgends. Dieselbe Sprosse der Leiter, gegensätzliche Prüfbarkeit.

Der Wächter, der fast funktioniert

Naheliegend ist ein Plausibilitätscheck „ein Ereigniszeitpunkt darf nicht nach dem Empfangszeitpunkt liegen”. Er fängt den Fall tatsächlich, solange die Nachricht zeitnah zum Ereignis kommt: Ein zu kleiner Offset schiebt den Instant zuverlässig in die Zukunft. Zwei blinde Flecken bleiben: die Gegenrichtung (ein zu großer Offset erzeugt einen Zeitpunkt in der Vergangenheit — nie ein Alarm) und Nachbuchungen (dort liegt der Instant ohnehin weit zurück). Und prinzipiell: Ein Systemzeitvergleich prüft Plausibilität, nie Konformität. Er sagt „dieser Zeitpunkt kann nicht stimmen”, nie „der Offset ist falsch”.

Beispielnachrichten (synthetisch)

Sommerfall — der Sender schreibt einen festen Offset +0100, obwohl lokal +0200 gilt:

MSH|^~\&|SENDER|HAUS|EMPFAENGER|HAUS|20260818233512||ADT^A01^ADT_A01|1001|P|2.5.1
EVN|A01|20260818233512+0100|||OP0815^Muster^Anke||
PID|1||100045^^^NS-A^MR||Muster^Erika^^^^^L||19700102|F
PV1|1|I|ST2^Z12^01|E||||||FA1|||||||||EIN-2026-004711^^^NS-A^VN|||||||||||||||||||||||||20260818233000+0100

Rechnung: 23:30+0100 → 22:30 UTC. Gemeint war 23:30+0200 → 21:30 UTC. Ein Empfänger, der intern UTC speichert und lokal darstellt, zeigt 00:30 am Folgetag an — die Verschiebung kreuzt eine Datumsgrenze und wird dadurch überhaupt erst gemeldet.

Winterfall aus derselben Konfiguration — unauffällig, weil +0100 im Winter zutrifft:

PV1|1|I|ST2^Z12^03|E||||||FA1|||||||||EIN-2026-000188^^^NS-A^VN|||||||||||||||||||||||||20260112142000+0100

14:20 + (1 − 1) = 14:20. Derselbe Sender, dieselbe Strecke, kein Befund. Die Klammer wird null, nicht der Fehler.

Portalbezug

Zielsysteme, die Ereignisse chronologisch darstellen — Patientenportale, Aktenansichten, Terminübersichten — sind für diese Fehlerklasse besonders empfindlich, weil sie Zeitpunkte nicht nur speichern, sondern anzeigen, sortieren und Fristen darauf rechnen. Vier Entwurfsregeln:

  1. Intern in UTC speichern, den empfangenen Offset zusätzlich aufbewahren. Wird er beim Import verworfen, ist die Bauweise des Senders später nicht mehr aus den Daten belegbar — dieselbe Bewegung wie beim Verwerfen der Assigning Authority (siehe 14-Der Identifier ist ein Paar).
  2. Die Genauigkeit des Eingangswerts mitführen. Wer aus einer tagesgenauen Angabe intern Mitternacht macht, kann später nicht mehr unterscheiden, ob „00:00” behauptet oder erfunden war.
  3. Fristen und Sortierungen auf dem Instant rechnen, nicht auf der Ortszeit-Zeichenkette. Andernfalls springen sie in den Umstellungsnächten.
  4. Die Normalisierung auf UTC ist die richtige Architektur. Sie erzeugt den Fehler nicht, sie macht ihn sichtbar. Ein System, das Ziffern nur durchreicht, hat dieses Symptom nicht — dafür kann es Ereignisse aus mehreren Quellen nicht zuverlässig ordnen und in der Herbstnacht gar nichts mehr entscheiden.

Einordnung

BefundKategorieWarum
Zeitstempel mit Offset, aber falschem Offset5 — ungewollte Aussagebeide Seiten konform, die Aussage vollständig und korrekt verstanden; der Empfänger hat nichts geraten
Zeitstempel ohne Offset, ohne Default in MSH-7, ohne Festlegung im Konzept3 — Empfänger rätdie Angabe fehlt in der Nachricht, jemand muss eine Zone wählen
Zeitpunkt aus dem falschen Feld gelesen4 — Mapping-Fehlerdie richtige Angabe ist da und wird falsch zugeordnet

Abgrenzung 4 gegen 5 — die Linie, an der es am häufigsten kippt:

NachrichtErgebnis beim EmpfängerMangel sitzt
4richtigfalschin der Übersetzung
5falschkorrekt abgeleitetim Inhalt der Aussage

Operativer Test: Kann man den Fall heilen, ohne den Sender anzufassen? Ja → 4. Nein → 5.

Kein Ausschlussgrund für 4 ist dagegen „es wird abgebildet, was vereinbart wurde” — sonst wäre jede Mapping-Strecke mit dokumentiertem Mapping automatisch keine. Der Ausschluss muss an der Abbildung ansetzen: Übersetzen beide Seiten gleich und richtig, kann es keine 4 sein.

Eine Nachricht trägt nicht eine Fehlerkategorie, sondern pro Aussage eine. Ein wirksamer Defekt der einen Klasse und ein latenter Defekt einer anderen können nebeneinander stehen — etwa ein falscher Offset im fachlichen Feld (5) und ein fehlender Default in MSH-7 (latente 3). Praxisfolge: Wer nach „dem Fehler” sucht, findet den auffälligsten. Das ist der häufigste Weg, an einer Störung vorbeizuermitteln — und der auffälligste Befund ist regelmäßig der, den ein Prüfblick zuerst trifft, nicht der, der wirkt.

Wer entscheidet? Bei dieser Fehlerklasse lautet die Antwort niemand. Ein Offset ist die Anweisung, wie der Wert auf UTC zu beziehen ist; ein Empfänger, der ihn anwendet, liest, er entscheidet nicht. Das ist der Unterschied zu Fällen, in denen ein Zielsystem eine Lücke füllt. Die Frage „wer entscheidet?” ist eine Frage, keine Formel — sie darf auch mit „niemand” beantwortet werden, und dann liegt der Defekt beim Sender.

Kahn-Rahmen: Ein falscher Offset ist im Quellbestand in keiner Kategorie messbar — die Quelle ist in sich richtig, und der Offset ist dort kein gespeichertes Attribut, sondern entsteht erst beim Serialisieren. Im Zielbestand ist Temporal Plausibility die zuständige Kategorie, aber sie löst nur aus, wenn eine Ordnung verletzt wird. Auf die Frage, wie groß die Abweichung sein müsste: nicht groß, sondern günstig gelegen. Dieselbe Stunde ist um 23:30 detektierbar und um 12:00 nicht. Das ist ein Anwendungsfall der Rahmengrenze — siehe Kahn-Framework: Kahn misst Bestände, nicht Strecken. Übrig bleibt der Abgleich Quelle↔Ziel, und der ist ein Verfahren, keine Kategorie.

FHIR erbt den Fehler

in FHIR
falscher Offsetunverändert, Validator grün
fehlender Offsetbeseitigt
Nachweisbarkeitschlechter, wenn der Server normalisiert
Feld-/Ereignisverwechslungbreiter
  • Was FHIR schließt: instant — „The time SHALL specified at least to the second and SHALL include a time zone”, ausdrücklich „for system times, not human times”. dateTime — „If hours and minutes are specified, a time zone SHALL be populated.” Ein Zeitstempel mit Uhrzeit ohne Zone ist nicht wohlgeformt. Die Klasse „Empfänger muss die Senderzone raten” verschwindet.
  • Was FHIR nicht schließt: "2026-08-18T23:30:00+01:00" ist ein valides dateTime. FHIR erzwingt die Anwesenheit der Zeitzone, nicht ihre Richtigkeit.
  • Die zweite Aussage wird breiter: Bundle.timestamp (Sender-Stack) · Provenance.recorded (Erfassung) · Encounter.period.start (fachlich) · meta.lastUpdated — letzteres wird vom Server gesetzt, sieht deshalb immer plausibel aus und ist nie als falsch widerlegbar. Es beantwortet nur eine andere Frage als die, die man ihm stellt.

Zwei Beobachtungen aus der Praxis, nicht aus der Spezifikation

(1) Der Server normalisiert den Beweis weg. Viele Server speichern intern UTC und liefern beim GET …22:30:00Z zurück, obwohl +01:00 geschickt wurde. Derselbe Augenblick — aber die Information, welchen Offset der Sender behauptet hat, ist weg, und damit die einzige Spur auf seine Bauweise. (2) Die Suche wird falsch, ohne leer zu sein. Datums-Suchparameter vergleichen Zeitpunkte. Ein um eine Stunde verschobener Instant rutscht an Tagesgrenzen in den falschen Tag; der Client bekommt eine syntaktisch einwandfreie Trefferliste mit einem Fall zu viel und einem zu wenig. Ein Mensch, der eine Zeitleiste ansieht, stutzt — eine Trefferliste prüft niemand gegen. Beides vor einer Zusage am konkreten Server nachmessen.

Transfer

Zeitbasierte Auswertungen — Verweildauer, Zeit bis zur Intervention, Nacht- oder Wochenendaufnahme, Fristeinhaltung — hängen sämtlich an dieser einen Ziffer im Offset. Ein Offsetfehler erzeugt keinen einzigen ungültigen Wert und landet unbeanstandet in jedem Auswertungsbestand. Ein Modell, das darauf trainiert wird, lernt die Konfiguration eines Sendesystems und hält sie für einen Sachverhalt.

Zwei ohne Interpretationsspielraum zählbare Kennzahlen:

  • Anteil der Zeitstempel ohne Offset, je Sender und je Feld;
  • Anteil der Fälle, in denen der Zielbestand einen anderen Ortszeit-Wert trägt als die Quelle.

Beide stehen in keinem Konformitätsbericht.

Fragen an die Kunden-IT

  1. Woher nimmt Ihr System den Offset, den es in die Zeitfelder der Nachricht schreibt — leitet es ihn zum Ereigniszeitpunkt aus der Zeitzone ab, oder steht er als fester Wert in der Schnittstellenkonfiguration? (Die Frage nach der Systemzeit klärt das nicht.)
  2. Senden Sie in allen Zeitfeldern einen Offset, oder nur in einigen?
  3. Trägt MSH-7 einen Offset? Falls nein: Welche Zeitzone sollen wir für Felder ohne Offset annehmen, und ist das im Schnittstellenkonzept festgehalten?
  4. Welches Feld trägt bei Ihnen den fachlichen Ereigniszeitpunkt — EVN-6, ein feldspezifisches Datum, oder wird EVN-2 dafür mitbenutzt?
  5. Wie verhält sich Ihr System in den beiden Umstellungsnächten, insbesondere bei Ereignissen in der doppelt vorkommenden Stunde?
  6. In welcher Genauigkeit senden Sie Zeitangaben, und gibt es Felder, in denen die Genauigkeit fallabhängig schwankt?

Zur Verzweigung der ersten Frage: Antwort „aus der Zone abgeleitet” ist durch einen einzigen Sommerfall mit falschem Offset widerlegt — dann gemeinsam in die Adapter-Konfiguration schauen statt zu diskutieren. Antwort „fester Wert” bestätigt die Ursache; die Reparatur ist die Umstellung auf Zonenableitung plus Nacherfassung aller seit der Frühjahrsumstellung übertragenen Zeitpunkte. Antwort „wissen wir nicht” → Hersteller einbinden, bis dahin Sommer- und Winterfälle desselben Senders gegenüberstellen.

Wer einen falschen festen Wert durch einen richtigen festen Wert ersetzt, repariert den Zeitpunkt, nicht die Regel. Der Irrelevanz-Test für jede vorgeschlagene Reparatur lautet hier: Ist danach gleichgültig, welcher Monat läuft?

Lektüre & Belege

Verwandt: 12-Das Z-Kürzel ist kein Namensraum · 14-Der Identifier ist ein Paar · 08-Storno ist kein Rollback · 10-A08 vs. A31 — das Event benennt die Ebene · Die sechs Fehlerkategorien · Kahn-Framework

Graphansicht

Backlinks