{"id":9380,"date":"2026-10-07T14:52:00","date_gmt":"2026-10-07T14:52:00","guid":{"rendered":"https:\/\/medicalvalues.de\/?p=9380"},"modified":"2026-10-07T14:54:40","modified_gmt":"2026-10-07T14:54:40","slug":"ki-im-labor-build-buy-oder-partner","status":"publish","type":"post","link":"https:\/\/medicalvalues.de\/de\/ki-im-labor-build-buy-oder-partner\/","title":{"rendered":"KI im Labor: Build, Buy oder Partner"},"content":{"rendered":"\t\t
\n\t\t\t\t
\n\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

KI in der Labormedizin wird in Laboren bereits auf sehr unterschiedliche Weise umgesetzt. Fragt man in einer Runde von Laborleitungen und IT-Verantwortlichen, wie sie KI heute einsetzen, fallen die Antworten erstaunlich unterschiedlich aus. Die einen haben in der Labor-IT eigene Skripte, Regelwerke und Auswertungen aufgebaut. Andere haben ein KI-Modul ihres LIS-Herstellers, einen Office-Copilot oder eine Transkriptionsl\u00f6sung eingekauft. Wieder andere entwickeln gemeinsam mit einem Partner. Und eine vierte Gruppe sagt offen: noch gar nicht \u2013 oder nur inoffiziell.<\/p>

Diese vierte Antwort ist die aufschlussreichste. Denn \u201enoch gar nicht“ bedeutet in den seltensten F\u00e4llen, dass im Haus keine KI genutzt wird. Es bedeutet meist, dass niemand entschieden hat, wie sie genutzt werden soll. Genau darum geht es in diesem Beitrag: um die Frage, die jedes Labor fr\u00fcher oder sp\u00e4ter beantworten muss \u2013 Build, Buy oder Partner?<\/p>

Viel KI, wenig Wirkung<\/h3><\/div>

Die Ausgangslage ist branchen\u00fcbergreifend ern\u00fcchternd. Laut einer MIT-Studie<\/span> (\u201eThe GenAI Divide\u201c, 2025) zeigen rund 95 Prozent der GenAI-Pilotprojekte in Unternehmen keine messbaren Auswirkungen auf die Ergebnisse. Im Januar 2026 hob Gartner seine Prognose f\u00fcr eingestellte GenAI-Projekte deutlich an: Mindestens die H\u00e4lfte wird nach dem Proof-of-Concept eingestellt.<\/p>

Aufschlussreich sind die Ursachen, die Gartner daf\u00fcr nennt: fehlender Business Value, Daten, die nicht bereit sind, untersch\u00e4tzte Gesamtkosten, Responsible AI als Nachgedanke und schwaches Change Management. Keine dieser Ursachen ist ein Technologieproblem. Alle sind Fragen der Umsetzung \u2013 und damit genau die Fragen, die hinter der Entscheidung zwischen Build, Buy und Partner stehen.<\/p>

Drei Wege \u2013 und keiner ist per se der richtige<\/h3><\/div>

Build <\/strong>bedeutet Eigenentwicklung \u2013 durch die Labor-IT, ein universit\u00e4res Institut oder beauftragte Entwickler. Die St\u00e4rken liegen auf der Hand: maximale Passung, Datenhoheit, Know-how im eigenen Haus. Die Risiken werden dagegen oft untersch\u00e4tzt: Talente und Betrieb m\u00fcssen dauerhaft gesichert werden, aus einzelnen Projekten werden schnell Skriptsammlungen ohne Lebenszyklus \u2013 und wer Software mit diagnostischer Zweckbestimmung selbst entwickelt, wird regulatorisch zum Hersteller.<\/p>

Buy<\/strong> bedeutet, ein fertiges Produkt oder eine SaaS-L\u00f6sung einzukaufen. Das verspricht eine schnelle Time-to-Value, planbare Kosten und einen Anbieter, der Zertifizierung und Weiterentwicklung tr\u00e4gt. Der Preis daf\u00fcr sind begrenzte Anpassbarkeit, m\u00f6gliche Abh\u00e4ngigkeiten \u00fcber propriet\u00e4re Formate und Schnittstellengeb\u00fchren sowie offene Fragen zu Datenabfluss und Verarbeitungsort.<\/p>

Partner<\/strong> bedeutet gemeinsame Entwicklung auf einer bestehenden Plattform \u2013 etwa als Co-Innovation, als gemanagtes Open-Source-Projekt oder als Pilot mit klarer Zielvereinbarung. Hier trifft das Dom\u00e4nenwissen des Labors auf die Technologie und regulatorische Erfahrung des Partners. Wichtig ist: Partnerschaft ist kein Euphemismus f\u00fcr Einkauf. Der Unterschied liegt in geteilter Verantwortung, einer gemeinsamen Roadmap und echter Risikoteilung. Daf\u00fcr braucht es klare Governance \u2013 und eine Exit-Strategie.<\/p>

In der Praxis sind die meisten erfolgreichen Umsetzungen Mischformen. Die eigentliche Frage lautet daher nicht \u201eWelcher Weg?“, sondern \u201eWelcher Weg f\u00fcr welchen Teil?“<\/p>

Die Leitfrage: Commodity oder Differenzierung?<\/h3><\/div>

Ein hilfreiches mentales Modell ordnet jeden Anwendungsfall entlang zweier Achsen: Wie stark differenziert die F\u00e4higkeit das eigene Labor \u2013 und wie nahe liegt sie an der medizinischen Entscheidung und damit an MDR <\/span>\/ IVDR<\/span> und dem AI Act?<\/p>

  • Geringe Differenzierung, geringe Kritikalit\u00e4t:<\/strong> Transkription, Telefon-KI, \u00dcbersetzung, Office-Copilot. Austauschbar und schnell verf\u00fcgbar \u2013 hier lohnt der Einkauf von Standardl\u00f6sungen.<\/p><\/li>

  • Hohe Differenzierung, geringe Kritikalit\u00e4t: <\/strong>Einsender- und Portfoliosteuerung, eigene Regeln, Dashboards, Analytics. Hier lohnt es sich, selbst zu gestalten \u2013 idealerweise auf den Schnittstellen einer stabilen Plattform, mit Tests und Dokumentation.<\/p><\/li>

  • Geringe Differenzierung, hohe Kritikalit\u00e4t: <\/strong>zertifizierte Entscheidungsunterst\u00fctzung, Validierungshilfen, Befundtexte als Medizinprodukt. Hier tr\u00e4gt idealerweise der Anbieter die Zertifizierung, das Labor konfiguriert lokal.<\/p><\/li>

  • Hohe Differenzierung, hohe Kritikalit\u00e4t<\/strong>: Hier k\u00f6nnen Labore am meisten gewinnen \u2013 und am meisten verlieren. Eine gemeinsame Innovation mit einem Partner, der die regulatorische Last tr\u00e4gt, ist in der Regel der realistischste Weg. Eine eigenst\u00e4ndige Entwicklung erfordert spezielle Fachkenntnisse in den Bereichen Qualit\u00e4tsmanagement<\/span> und MDR.<\/span><\/p><\/li><\/ul>

    Oder zugespitzt: Wer Commodity selbst baut, investiert in das Falsche. Wer Differenzierung nur einkauft, gibt sie aus der Hand.<\/p>

    Ein zweites Modell stammt von McKinsey und unterscheidet Taker<\/em>, Shaper<\/em> und Maker<\/em>. Taker nutzen KI-Produkte, wie sie sind. Maker trainieren und betreiben eigene Modelle \u2013 mit maximaler Differenzierung, aber auch maximaler Verantwortung, Infrastruktur und Validierungsaufwand. Dazwischen liegen die Shaper: Sie bringen ihre eigene Fachlogik \u2013 SOPs, Regelwerke, Referenzbereiche, Einsenderlogik, eigene Wissensbest\u00e4nde \u2013 in eine bestehende Plattform ein, ohne ein eigenes Modell zu trainieren. F\u00fcr die meisten Labore ist das der Sweet Spot: Taker bei Commodity, Shaper bei der eigenen Fachlogik, Maker nur mit Forschungsauftrag und eigenem Regulatorik-Setup. Dazu passt ein aktueller Trend: Unternehmen kaufen wieder h\u00e4ufiger fertige Anwendungen, nutzen aber parallel mehrere Modelle. Modelle werden austauschbar \u2013 die Fachlogik nicht.<\/p>

    Kern kaufen, Commodity teilen, Differenzierung bauen<\/h3><\/div>

    \u00dcbersetzt in eine Architektur ergibt sich ein Schalenmodell mit drei Ebenen:<\/p>

    1. Ein stabiler Kern<\/strong> \u2013 ob erworben oder gemeinsam mit einem Partner betrieben: Kernlaborprozesse, zertifizierte Entscheidungshilfen und ein harmonisiertes Datenmodell auf der Grundlage von Standards wie LOINC<\/span> und FHIR<\/span>. Mit direktem Zugriff auf die eigenen Daten und ohne Geb\u00fchren f\u00fcr die Nutzung der Schnittstellen.<\/p><\/li>

    2. Eine geteilte Schicht <\/strong>f\u00fcr alles, was nicht differenziert \u2013 Ger\u00e4tetreiber, Middleware, Parser, Mappings. Diese Komponenten gemeinsam als Open Source zu entwickeln, schafft Transparenz statt Blackbox und verhindert Lock-in. Betreiben kann man sie selbst \u2013 oder als Service einkaufen.<\/p><\/li>

    3. Flexible Erweiterungen<\/strong> f\u00fcr die eigene Differenzierung \u2013 Regelwerke, Workflows, Dashboards \u00fcber offene APIs. Entscheidend ist, dass sie als echte Software entstehen: mit Lebenszyklus, Tests und Dokumentation, egal ob Labor, Partner oder Anbieter sie umsetzen.<\/p><\/li><\/ol>

      Ebenso wichtig ist ein flie\u00dfender \u00dcbergang zwischen Konfiguration und Code. Viele Labore stecken heute zwischen klassischer LIS-Parametrierung und einer inoffiziellen Ebene aus Excel-Makros und Skripten fest. Was fehlt, ist die Ebene dazwischen: Individualisierung durch Power-User und Medizininformatik \u2013 Regelwerke, Reflextestungen, Workflows \u2013, abgesichert durch Simulation und automatisierte Tests, bevor eine \u00c4nderung produktiv geht.<\/p>

      Bauen wird billiger \u2013 Verantwortung nicht<\/h3><\/div>

      KI ver\u00e4ndert die Rechnung auch auf der Build-Seite. Mit KI-gest\u00fctzter Programmierung, oft als \u201eVibe Coding“ bezeichnet, werden kleine, spezielle Use Cases pl\u00f6tzlich baubar. Eigenentwicklung wird damit verlockender. Doch die Kosten verschwinden nicht, sie verschieben sich: von der Entwicklung in Betrieb, Wartung und Verantwortung. Ein Workaround ohne Tests und Dokumentation bleibt ein Risiko \u2013 auch wenn er heute in Minuten generiert ist.<\/p>

      Nachhaltige Erweiterungen brauchen deshalb f\u00fcnf Fundamente: saubere APIs und Erweiterungspunkte, stabile Kernprozesse, klare Governance und Ownership, Dokumentation als Voraussetzung f\u00fcr Wartbarkeit und Auditierbarkeit \u2013 und eine gute Prozessanalyse, die echte Differenzierung von unn\u00f6tiger Komplexit\u00e4t unterscheidet. Der vielleicht wertvollste Einsatz von KI in der Entwicklung ist ohnehin ein anderer: als Denkpartner f\u00fcr Prozessvarianten, gemeinsam mit den Menschen, die die Arbeit kennen.<\/p>

      Hinzu kommen die gesetzlichen Vorschriften. Wer intern Software mit diagnostischem Verwendungszweck entwickelt, \u00fcbernimmt die Pflichten eines Herstellers: ein Qualit\u00e4tsmanagementsystem<\/span>, technische Dokumentation, klinische Bewertung und Vigilanz. Die Ausnahmeregelung f\u00fcr die Eigenentwicklung im Rahmen der MDR<\/span> unterliegt strengen Auflagen und ist kein Freifahrtschein. Die K\u00e4ufer bleiben Betreiber \u2013 mit eigenen Verpflichtungen hinsichtlich Verwendungszweck, Schulung, Datenschutz-Folgenabsch\u00e4tzung und NIS2-Risikomanagement<\/span>. Eine Partnerschaft erfordert eine klare Verantwortungsmatrix: Wer zertifiziert, wer validiert vor Ort, wer berichtet, wer haftet? Das KI-Gesetz r\u00e4umt eine Frist ein, jedoch nicht auf unbestimmte Zeit: Transparenzpflichten gelten bereits, und die Verpflichtungen f\u00fcr KI in Medizinprodukten mit hohem Risiko treten \u2013 nach derzeitigem Stand \u2013 ab August 2028 in Kraft.<\/p>

      Security und Privacy: Shadow AI ist die teuerste Option<\/h3><\/div>

      Zur\u00fcck zur vierten Antwort vom Anfang. Laut MIT<\/span> nutzen Mitarbeiter in mehr als 90 Prozent der Unternehmen private KI-Tools f\u00fcr ihre Arbeit \u2013 w\u00e4hrend nur etwa 40 Prozent \u00fcber offizielle Lizenzen verf\u00fcgen. Der \u201eCost of a Data Breach Report 2025\u201c von IBM beziffert die zus\u00e4tzlichen Kosten einer Datenpanne im Zusammenhang mit \u201eShadow-KI\u201c auf etwa USD<\/span><\/span> <\/span>670.000 USD; 63 Prozent der Unternehmen verf\u00fcgen noch nicht \u00fcber eine KI-Governance-Richtlinie.<\/p>

      Im Labor bedeutet das: Befundtexte, Arztbriefe oder Patientendaten landen in Consumer-Tools, wenn es kein freigegebenes Angebot gibt. Ein fr\u00fcher, sicherer Einkauf oder eine Partnerschaft ist deshalb oft die wirksamste Governance-Ma\u00dfnahme. Security und Privacy sind Auswahlkriterium Nummer eins \u2013 nicht Bremse.<\/p>

      Die Risiken selbst gelten f\u00fcr alle drei Wege: Prompt Injection \u00fcber eingelesene Dokumente und Befunde, Patientendaten in Prompts und Logs, die Nutzung eigener Daten zum Training fremder Modelle, Datenabfluss an Anbieter au\u00dferhalb der EU, Abh\u00e4ngigkeiten durch propriet\u00e4re Formate, unklare Verantwortlichkeiten und Blackbox-Ergebnisse, die weder \u00c4rzt:innen noch Auditoren nachvollziehen k\u00f6nnen. Der Unterschied liegt darin, wer die Kontrolle nachweist: bei Build das Labor selbst, bei Buy der Anbieter \u2013 \u00fcber Vertr\u00e4ge, Zertifikate und Auditrechte \u2013, bei Partner die gemeinsam vereinbarte Verantwortungsmatrix.<\/p>

      Auch beim Betriebsmodell lautet die Frage nicht \u201eCloud ja oder nein“, sondern: Welche Daten d\u00fcrfen wohin? On-Premise bietet volle Kontrolle, verlangt aber GPU-Infrastruktur und Betriebs-Know-how. Reine Cloud-L\u00f6sungen sind schnell, erfordern aber einen genauen Blick auf Verarbeitungsort, Subprozessoren und die Kostenentwicklung \u00fcber f\u00fcnf Jahre. F\u00fcr viele H\u00e4user ist ein hybrider Ansatz der pragmatische Weg: Kernlogik und Patientendaten bleiben im Haus, nur anonymisierte Textaufgaben gehen an ein Sprachmodell in Deutschland oder der EU.<\/p>

      Was andere zeigen<\/h3><\/div>

      Ein Blick \u00fcber das Labor hinaus macht die Muster sichtbar. Klarna ersetzte 2024 gro\u00dfe Teile seines Kundenservice durch KI \u2013 und kehrte 2025 zu einem hybriden Modell zur\u00fcck, weil Kosten, so der CEO, ein zu dominanter Bewertungsfaktor gewesen seien. Die Lehre: Erfolgsmetrik ist Qualit\u00e4t, nicht nur Kosten und Geschwindigkeit. IBM Watson Health wurde nach Milliardeninvestitionen verkauft \u2013 unter anderem, weil Daten- und Workflow-Passung fehlten. Dom\u00e4nenwissen l\u00e4sst sich nicht einfach zukaufen.<\/p>

      Im Gesundheitswesen zeigt sich, dass Build und Partner kein Widerspruch sind. Die Mayo Clinic entwickelt gemeinsam mit Microsoft ein eigenes Modell aus de-identifizierten Daten \u2013 und beh\u00e4lt das Eigentum daran. Am Universit\u00e4tsklinikum Freiburg waren \u00fcber 93 Prozent der mit einem nicht-kommerziellen Sprachmodell erstellten Arztbriefe mit minimalen Anpassungen nutzbar: Differenzierung durch lokale Anpassung eines offenen Modells, ganz ohne eigenes Modelltraining. Und gro\u00dfe universit\u00e4re KI-Institute berichten offen, dass viel geforscht werde, aber zu wenig in der Versorgung ankomme \u2013 der Transfer scheitert oft an Regulatorik und Betrieb.<\/p>

      Auch Laborprojekte lassen Muster erkennen. Als eine weit verbreitete Integrations-Engine im Jahr 2025 von Open Source auf ein propriet\u00e4res Lizenzmodell umgestellt wurde, standen viele Labore pl\u00f6tzlich vor einer strategischen Entscheidung \u2013 und erlebten, wie schnell Abh\u00e4ngigkeiten teuer werden k\u00f6nnen. Offene, laborspezifische Middleware stellt hier eine Art vierten Weg dar: Die Ausstiegsm\u00f6glichkeit bleibt erhalten, w\u00e4hrend Betriebsleistungen weiterhin eingekauft werden k\u00f6nnen. Das Gleiche gilt f\u00fcr die LIS-Modernisierung: Anstelle eines riskanten \u201eBig Bang\u201c lassen sich Module f\u00fcr die Auftragserfassung, Validierung oder Analytik \u00fcber FHIR <\/span>und LOINC<\/span> an den bestehenden Kern anschlie\u00dfen. Und Vertragsmodelle, die Zahlungen an gemeinsam definierte Ziele kn\u00fcpfen, machen aus einem Lieferanten einen Partner \u2013 denn beide Seiten arbeiten auf messbare Ergebnisse hin.<\/p>

      Was scheitert \u2013 und was tr\u00e4gt<\/h3><\/div>

      Verdichtet man diese Erfahrungen, zeichnen sich klare Muster ab. Es scheitern Proofs of Concept ohne Betriebs- und Finanzierungskonzept, Kosten oder Geschwindigkeit als einzige Erfolgsmetrik, Skriptsammlungen ohne Ownership, Lock-in durch propriet\u00e4re Middleware und Schnittstellengeb\u00fchren sowie Blackbox-Ergebnisse, denen niemand vertraut. Und es scheitert KI, die vor der Datenbasis kommt: Wer nicht beantworten kann, welche Daten vorhanden sind, woher sie stammen und was sie bedeuten, wird auch mit dem besten Modell wenig erreichen \u2013 ein Thema, das wir im Beitrag zur intelligenten Metadaten-Verwaltung ausf\u00fchrlicher beleuchtet haben.<\/p>

      Was hingegen funktioniert: klein anfangen, mit klaren Vorteilen und messbaren Zielen. Die Wahl der richtigen Ebene \u2013 Standardkomponenten kaufen, die Dom\u00e4nenlogik gestalten, den Kern stabil halten. Die Zust\u00e4ndigkeit f\u00fcr jede Erweiterung festlegen. Offene Standards wie FHIR<\/span>, LOINC <\/span>und SNOMED<\/span> CT sowie Datenportabilit\u00e4t vom ersten Tag an. Den Menschen im Prozess einbeziehen. Und eine Ausstiegsstrategie vertraglich verankern \u2013 die beste Absicherung gegen eine Bindung an einen Anbieter.<\/p>

      Zehn Fragen vor der Entscheidung<\/h3><\/div>

      1. Auf welcher Ebene ist der Anwendungsfall angesiedelt<\/strong> \u2013 auf der Ebene des Werkzeugs, des Prozesses oder des Medizinprodukts?<\/p><\/li>

      2. Ist die F\u00e4higkeit f\u00fcr uns Commodity oder Differenzierung?<\/strong><\/p><\/li>

      3. Wer tr\u00e4gt die regulatorische Verantwortung<\/strong> \u2013 der Hersteller oder der Betreiber?<\/p><\/li>

      4. Welche Datenkategorie verarbeiten wir <\/strong>\u2013 und wo darf diese verarbeitet werden?<\/p><\/li>

      5. Sind unsere Daten strukturiert und beschrieben<\/strong> \u2013 mit LOINC, FHIR <\/span>und Metadaten<\/span>?<\/p><\/li>

      6. Wie hoch sind die Gesamtkosten \u00fcber einen Zeitraum von f\u00fcnf Jahren<\/strong> \u2013 Betrieb, Wertmarken, Personal, Zertifizierung?<\/p><\/li>

      7. Wer ist f\u00fcr den Lebenszyklus,<\/strong> die Tests, die Dokumentation und die Aktualisierungen der Erweiterung verantwortlich?<\/p><\/li>

      8. Woran messen wir Erfolg \u2013 an<\/strong> Qualit\u00e4t, Zeit, Kosten oder Akzeptanz?<\/p><\/li>

      9. Wie kommen wir da wieder heraus <\/strong>\u2013 Datenportabilit\u00e4t, offene Schnittstellen, Open Source?<\/p><\/li>

      10. Was passiert, wenn wir nichts tun?<\/strong><\/p><\/li><\/ol>

        Je mehr Antworten in Richtung \u201ehohe Differenzierung, hohe Kritikalit\u00e4t, begrenzte eigene Kapazit\u00e4t“ zeigen, desto eher lohnt sich der Partner-Weg.<\/p>

        Fazit<\/h3><\/div>

        Build, Buy oder Partner ist keine Entweder-oder-Entscheidung. Die Ebene bestimmt die Antwort: Werkzeuge kauft man, Prozesse gestaltet man \u2013 allein oder mit einem Partner \u2013, und bei Medizinprodukten kauft man zertifiziert ein oder entwickelt gemeinsam mit jemandem, der die regulatorische Verantwortung tragen kann. Security und Privacy sind dabei kein Hindernis, sondern das wichtigste Auswahlkriterium. Und schneller bauen hei\u00dft nicht besser bauen: Auch im Zeitalter KI-gest\u00fctzter Entwicklung brauchen Erweiterungen Schnittstellen, Ownership, Tests und Dokumentation.<\/p>

        Die teuerste Option ist am Ende nicht die falsche Entscheidung zwischen Build, Buy und Partner \u2013 sondern gar keine Entscheidung. Wir freuen uns \u00fcber den Austausch mit allen, die diese Fragen gerade f\u00fcr ihr Labor oder ihre Klinik bewegen \u2013 \u00fcber gelungene Ans\u00e4tze ebenso wie \u00fcber Projekte, aus denen man lernen konnte.<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t","protected":false},"excerpt":{"rendered":"

        K\u00fcnstliche Intelligenz ist im Labor angekommen \u2013 zumindest in den Pilotprojekten. Ob sie auch im Routinebetrieb Wirkung entfaltet, entscheidet sich weniger an der Technologie als an einer klassischen Managementfrage: selbst entwickeln, einkaufen oder gemeinsam mit einem Partner umsetzen? <\/p>\n","protected":false},"author":17,"featured_media":9389,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[63,62],"tags":[111,96,39,37,95],"class_list":["post-9380","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-order-entry-de","category-technologie-und-innovation","tag-artificial-intelligence","tag-it-de","tag-labor","tag-lis-de","tag-software-de"],"acf":[],"_links":{"self":[{"href":"https:\/\/medicalvalues.de\/de\/wp-json\/wp\/v2\/posts\/9380","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/medicalvalues.de\/de\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/medicalvalues.de\/de\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/medicalvalues.de\/de\/wp-json\/wp\/v2\/users\/17"}],"replies":[{"embeddable":true,"href":"https:\/\/medicalvalues.de\/de\/wp-json\/wp\/v2\/comments?post=9380"}],"version-history":[{"count":8,"href":"https:\/\/medicalvalues.de\/de\/wp-json\/wp\/v2\/posts\/9380\/revisions"}],"predecessor-version":[{"id":9406,"href":"https:\/\/medicalvalues.de\/de\/wp-json\/wp\/v2\/posts\/9380\/revisions\/9406"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/medicalvalues.de\/de\/wp-json\/wp\/v2\/media\/9389"}],"wp:attachment":[{"href":"https:\/\/medicalvalues.de\/de\/wp-json\/wp\/v2\/media?parent=9380"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/medicalvalues.de\/de\/wp-json\/wp\/v2\/categories?post=9380"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/medicalvalues.de\/de\/wp-json\/wp\/v2\/tags?post=9380"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}