Analyse anfordern v1.0
Endpoint Version 1.1
letzte Änderung: 28.10.2025
Request
Analyseanforderungen werden im JSON Format via http POST über eine REST API an unser Laborsystem übermittelt. Hierzu benötigen Sie eine eindeutige API-Kennung, die Sie im Rahmen des Onboardings von uns erhalten.
Der POST Endpoint für die Analyseanforderung lautet:
https://partner:VvSoIe1UEPRpKAm8nPDrDBkEqX1J0uT9@labordatenbank.com/labclinic/imports/import/131/0/https
Solange die Probe noch nicht im Labor angekommen und verarbeitet ist, kann über den gleichen Endpoint der Datensatz zu einer Probe beliebig aktualisiert werden
Der Endpoint erwartet ein JSON im folgenden Format (Beispiel):
{
"customer_secret": "uAx6UyHHP1kU2YUcUQXCGZueNoiyZm3iJD1JIQ3okAOKKR61e0xZqL1uKjXK",
"barcode": "YOURBARCODE123",
"ordered_templates": [157],
"ordered_parameters": [FERR, VITD25],
"patient_data": {
"firstname": "Bea",
"lastname": "Beispiel",
"birthdate": "1971-04-12",
"gender": "f",
"email": "bea.beispiel@example.com"
},
"sample_data": {
"sample_taken": "2025-08-22 00:13:00",
"sampletype": "capillary blood"
},
"email_results": false,
"allow_update": true
}
customer_secret (string)
Ihre individuelle API-Kennung
Zwingend benötigt: ja
barcode (string)
Ihre individuelle API-Kennung
Zwingend benötigt: ja
ordered_templates (integer array)
Eine oder mehrere IDs der angeforderten Untersuchungspakete
Zwingend benötigt: nein
Hinweis: kombinierbar mit „ordered_parameters“. Verfügbare Analysen und IDs abzufragen über Endpoint „Verfügbare Analysen“.
ordered_parameters (string array)
Eine oder mehrere Kürzel der angeforderten Parameter
Zwingend benötigt: nein
Hinweis: kombinierbar mit „ordered_templates“. Verfügbare Analysen und IDs abzufragen über Endpoint „Verfügbare Analysen“.
patient_data (object)
Stammdaten des Patienten
Zwingend benötigt: ja
patient_data.firstname (string)
Vorname des Patienten
Zwingend benötigt: nein
Hinweis: wenn nicht angegeben im Bericht leer
patient_data.lastname (string)
Nachname des Patienten
Zwingend benötigt: nein
Hinweis: wenn nicht angegeben im Bericht leer
patient_data.birthdate (date „yyyy-mm-dd“)
Geburtsdatum des Patienten
Zwingend benötigt: ja
patient_data.gender („m“ / „f“)
Biologisches Geschlecht des Patienten
Zwingend benötigt: ja
patient_data.height (int)
Körpergröße des Patienten in cm
Zwingend benötigt: nein
patient_data.weight (decimal)
Körpergewicht des Patienten in kg
Zwingend benötigt: nein
patient_data.street (string)
Straße & Hausnummer des Patienten
Zwingend benötigt: nein
patient_data.zipcode (string)
Postleitzahl des Patienten
Zwingend benötigt: nein
patient_data.place (string)
Wohnort des Patienten
Zwingend benötigt: nein
patient_data.country (string)
Ländercode des Wohnsitzes des Patienten (ISO-Standard, z. B. „DE“)
Zwingend benötigt: nein
patient_data.email (string)
Email Adresse des Patienten
Zwingend erforderlich: nein
patient_data.phone (string)
Telefonnummer des Patienten
Zwingend erforderlich: nein
sample_data (object)
Stammdaten der Probe
Zwingend benötigt: ja
sample_data.sample_taken (date „yyyy-mm-dd hh:mm:ss“)
Zeitpunkt der Probenentnahme
Zwingend benötigt: ja
sample_data.sample_type („capillary blood“ / „whole blood“)
Probentyp (unterscheidet zwischen Venösem Blut und Kapillarblut)
Zwingend benötigt: ja
email_results (boolean)
Entscheidet darüber, ob von labClinic aus eine Email zum Abrufen des Ergebnisses an den Patienten gesendet wird.
Zwingend benötigt: nein
Hinweis: Wenn nicht gesetzt als „false“ gewertet. Funktioniert nur, wenn patient_data.email existiert.
allow_update (boolean)
Entscheidet darüber, ob vorhandener Datensatz aktualisiert wird oder bei bestehendem Datensatz import zurückgewiesen wird.
Zwingend benötigt: nein
Hinweis: Wenn nicht gesetzt als „true“ gewertet. Schnittstelle gibt fehler zurück wenn „false“ gesetzt und Datensatz zu Barcode bereits besteht.
Response
Leider sind wir aufgrund bestehender Limitationen unseres Laborinformationssystems in der Gestaltung unserer Responses verhältnismäßig eingeschränkt und haben nur sehr begrenzten Einfluss auf Format und den Inhalt der Endpoint Responses. Entsprechend können wir leider auch keine eigenen Fehlermeldungen definieren, die Aufschluss über den genauen Grund für die Ablehnung eines Requests zurückgeben. Lediglich bei erfolgreichen Requests können wir hier begrenzten Einfluss und können mitteilen, ob es sich um eine Aktualisierung oder einen neuen Auftrag handelt.
Wir arbeiten bereits an einer Lösung für eine spätere Iteration dieses Endpoints und bitten das etwas krude Antwortformat bis dahin zu entschuldigen.
Die Folgenden Antwortmuster sind derzeit Implementiert:
Neue Probe erfolgreich registriert
{
"msg": "Hinweis: Kein Auftrag zu Barcode gefunden. Auftrag wird angelegt.1 Auftrag aktualisiert",
"import_id": "93845",
"status_code": 200,
"imported_data": [
{
"md5": "25826686e36dcda2d437d9bab781167b",
"save_response": [
{
"order_id": 3346,
"msg": "TEST46391
customer_id geändert von 177 auf 177
Import erfolgreich 1 gespeichert"
}
]
}
]
}
Probe erfolgreich aktualisiert
{
"msg": "Hinweis: Auftrag zu Barcode gefunden. Auftrag wird aktualisiert.1 Auftrag aktualisiert",
"import_id": "93846",
"status_code": 200,
"imported_data": [
{
"md5": "b57f54e0527bc68908e52b575ed21818",
"save_response": [
{
"order_id": 3346,
"msg": "TEST46391
customer_id geändert von 177 auf 177
Auftrag eingegangen geändert von 2025-06-05 00:47:32 auf 2025-06-05 00:48:59
Geburtsdatum geändert von 2025-06-05 00:00:00 auf 1994-06-05 00:00:00
Import erfolgreich geändert von 1 auf 1"
}
]
}
]
}
Import Fehlgeschlagen
{
"error": "JSON Fehler: JSON Fehler: Syntaxfehler, ungültiges JSON",
"msg": "JSON Fehler: JSON Fehler: Syntaxfehler, ungültiges JSON",
"import_id": "93848",
"status_code": 400
}