--- { "title": "Einkaufsführer für Healthcare MDM 2026", "description": "Wie Sie Healthcare-MDM- und Enterprise-MPI-Plattformen bewerten: Identitätsauflösung, Matching-Qualität, Anpassungsfähigkeit, Integration, Leistungsnachweis und Gesamtkosten.", "date": "2026-10-15", "author": "Health Samurai Team", "reading-time": "30 min read", "tags": ["System Design", "Integrations", "FHIR Standard"], "utm-campaign": "guide", "utm-content": "mdm-buyers-guide-2026" } --- > For the complete documentation index, see [llms.txt](https://www.health-samurai.io/llms.txt). > Use it to discover all available pages before guessing URLs. --- Dieser Leitfaden erläutert, wie Sie eine Healthcare-Master-Data-Management-(MDM-)- oder Enterprise-Master-Patient-Index-(MPI-)Plattform bewerten: welche Identitätsentscheidungen sie unterstützen muss, wie Sie die Matching-Qualität anhand Ihrer eigenen Daten testen und wie Sie Anpassungsfähigkeit, Integration und Langzeitkosten vergleichen.

Den vollständigen Leitfaden als PDF herunterladen

Das vollständige Bewertungsframework mit dem Anbieter-Scorecard und dem Proof-of-Capability-Plan – zum Offline-Lesen oder zur Weitergabe an Ihr Team.

PDF herunterladen
## Zusammenfassung für Entscheidungsträger Gesundheitsorganisationen verfügen selten über einen einzigen autoritativen Datensatz für jeden Patienten, Leistungserbringer, jede Organisation oder jeden Standort. Dieselbe Entität wird unabhängig voneinander in EHR-Systemen, Laborsystemen, Abrechnungsplattformen, Registern, Portalen, übernommenen Unternehmen und Analyseumgebungen angelegt. Identifikatoren unterscheiden sich je nach Quelle. Namen, Adressen und Zugehörigkeiten ändern sich. Felder können unvollständig, veraltet oder schlicht falsch sein. Das Ergebnis ist ein Datensatzbestand, der erst dann sicher genutzt werden kann, wenn die Organisation bestimmen kann, welche Datensätze sich auf dieselbe reale Entität beziehen. Master Data Management, kurz MDM, stellt die Technologie und betrieblichen Kontrollmechanismen bereit, die zur Auflösung dieser Identitäten und zur Pflege vertrauenswürdiger Stammdaten in Healthcare-Systemen verwendet werden. Es umfasst den gesamten Entscheidungslebenszyklus: die Erkennung möglicher Duplikate, die Entscheidung, ob Datensätze dieselbe Entität darstellen, die Anwendung der korrekten Auflösungsmaßnahme, die Sicherung der Herkunft, die Korrektur von Fehlern und die Veröffentlichung des Ergebnisses an andere Systeme. Ein Master Patient Index, kurz MPI, ist der auf die Patientenidentität ausgerichtete Teil des Healthcare-MDM. Ein Enterprise-MPI führt diese Arbeit über mehrere Systeme, Einrichtungen oder Organisationen hinweg durch. Healthcare-MDM kann dieselben Grundlagen auf Leistungserbringer, Organisationen, Standorte, Mitglieder, verbundene Personen und die Beziehungen zwischen ihnen anwenden. Die Qualität der Identitätsdaten wirkt sich auf weit mehr aus als nur auf die Anzahl der Duplikate. Ein nicht erkannter Treffer kann eine klinische Vorgeschichte fragmentieren und relevante Informationen verbergen. Eine falsche Übereinstimmung kann Daten verschiedener Personen zusammenführen. Doppelte Leistungserbringer- und Organisationsdatensätze können Zuordnungen, Verzeichnisse, Überweisungen, Netzwerkberichte und Abrechnungen verfälschen. Analysesysteme laufen häufig weiter, wenn Identitäten falsch sind; sie liefern plausibel wirkende Ergebnisse auf der Grundlage überhöhter Populationen, fragmentierter Zeitverläufe und inkonsistenter Beziehungen. Die geeignete Lösung hängt vom Betriebsmodell der Organisation ab. Ein Gesundheitssystem kann Datensätze innerhalb eines zentral verwalteten EHR zusammenführen. Ein Gesundheitsinformationsnetzwerk kann jeden Quelldatensatz des Teilnehmers beibehalten und Verknüpfungen zwischen ihnen pflegen. Eine Healthcare-Plattform kann für jeden Kunden unterschiedliche Matching-Modelle, Prüfprozesse und Schnittstellen benötigen. Überlebensregeln (Survivorship Rules), Governance-Grenzen, Automatisierungsschwellenwerte, Integrationen und Korrekturverfahren können alle variieren. Diese Variabilität verändert die Art und Weise, wie ein Produkt bewertet werden sollte. Eine allgemeine Funktionsliste zeigt nicht, ob die Plattform die erforderliche Identitätsrichtlinie umsetzen kann. Ein veröffentlichter Genauigkeitsprozentsatz zeigt nicht, wie das Produkt mit den Daten des Käufers umgehen wird. Eine ansprechende Überprüfungsmaske zeigt nicht, ob Workflow, Belege, Berechtigungen und Korrekturmaßnahmen für den Produktionsbetrieb geeignet sind. ### Fünf Fragen, die jede Bewertung beantworten muss - **Kann die Plattform zuverlässige Identitätsentscheidungen treffen und erklären?** Die Matching-Qualität muss anhand repräsentativer Daten gemessen werden, und Prüfer müssen die Belege hinter jedem Ergebnis einsehen können. - **Kann sie die erforderliche Auflösungsrichtlinie anwenden?** Das Produkt muss möglicherweise Zusammenführungs-, Verknüpfungs-, Gesamtansichts-, Überlebens-, Nicht-Duplikat-, Trennungs- und Entknüpfungsverhalten unterstützen, das sich je nach Entität, Quelle, Mandant oder Konfidenzniveau unterscheidet. - **Kann es sich an die Organisation anpassen?** Workflows, Schnittstellen, Analysen, Mappings und Entscheidungsgrenzen erfordern häufig eine Anpassung und ändern sich nach der Inbetriebnahme weiter. - **Kann es in die Healthcare-Architektur integriert werden?** Identitätsentscheidungen müssen über FHIR-APIs, Ereignisse, Batch-Feeds, EHR-Integrationen, Analyseplattformen und Governance-Grenzen hinweg übertragen werden, ohne die Herkunftsinformationen zu verlieren. - **Kann es im großen Maßstab zuverlässig betrieben werden?** Leistung, Support, Implementierungsaufwand, Routineänderungen und kommerzielle Konditionen bestimmen die tatsächlichen Gesamtbetriebskosten. Dieser Leitfaden erläutert die Überlegungen hinter diesen Fragen, überführt sie in Produktanforderungen und bietet eine präzise Methode zum Vergleich von Anbietern. Health Samurai veröffentlicht diesen Leitfaden und entwickelt MDMbox. Diese Beziehung wird offen benannt. Die Bewertungsmethode sollte auf MDMbox mit denselben käufereigenen Daten, Workflows und Abnahmekriterien angewendet werden, die für jedes andere Produkt verwendet werden. ## Teil I: Die wesentlichen MDM-Entscheidungen verstehen ### 1. Identitätsauflösung im Gesundheitswesen Matching beantwortet eine Frage: Wie wahrscheinlich ist es, dass zwei Datensätze dieselbe reale Entität darstellen? Die Auflösung (Resolution) beantwortet eine andere Frage: Was soll geschehen, nachdem diese Beziehung identifiziert wurde? Ein Käufer muss beides verstehen, bevor er Anforderungen definiert. #### Zusammenführung (Merge) Eine Zusammenführung konsolidiert doppelte Datensätze zu einem verbleibenden Datensatz. Der Vorgang kann Feldwerte kopieren oder neu berechnen, Referenzen aus verwandten Ressourcen umleiten, die Quelle archivieren oder löschen und nachgelagerte Systeme benachrichtigen. Eine Zusammenführung ist am besten geeignet, wenn eine Autorität die Datensätze kontrolliert und den verbleibenden Zustand definieren kann. Der schwierige Teil ist die Richtlinie. Eine Gesundheitsorganisation muss entscheiden, welche Identifikatoren aktiv bleiben, welche demografischen Werte überleben, was mit widersprüchlichen klinischen oder administrativen Informationen geschieht und welche zugehörigen Ressourcen automatisch verschoben werden dürfen. FHIR R5 definiert eine Patienten-Merge-Operation, aber die Spezifikation überlässt viele Implementierungsentscheidungen dem Server, da legitime Richtlinien voneinander abweichen. Eine produktive Zusammenführung muss auch reversibel sein. Eine fehlerhafte Zusammenführung kann entdeckt werden, nachdem neue Begegnungen, Ergebnisse, Abrechnungen oder andere Ressourcen dem überlebenden Datensatz zugeordnet wurden. Die Plattform benötigt ausreichend Verlaufsdaten, um die ursprüngliche Änderung zu identifizieren, spätere Aktivitäten zu unterscheiden und eine sichere Trennung durchzuführen oder Konflikte zur Überprüfung weiterzuleiten. #### Verknüpfung (Link) Eine Verknüpfung hält fest, dass zwei oder mehr Datensätze zur selben Entität gehören, während die ursprünglichen Datensätze getrennt bleiben. Referenzen bleiben an ihren Quelldatensätzen verankert, und jede Quelle kann ihre eigenen Daten weiterhin verwalten. Eine Verknüpfung ist häufig sicherer über EHR-Systeme, Organisationen, juristische Personen, Mandanten oder Datenaustauschpartner hinweg, die keine gemeinsame Zusammenführungsbefugnis haben. Verknüpfungen sollten explizit, abfragbar, prüfbar und reversibel sein. Ein System, das einen Identitätscluster erstellen, aber keinen einzelnen Datensatz daraus entfernen kann, hat das Korrekturproblem lediglich in eine andere Datenstruktur verlagert. #### Gesamtansicht (Golden View) Eine Gesamtansicht präsentiert eine verwaltete Darstellung der Entität, während die beitragenden Quelldatensätze erhalten bleiben. Sie kann als kanonischer Datensatz gespeichert oder dynamisch aus verknüpften Datensätzen zusammengestellt werden. Die Organisation muss die Herkunft jedes ausgewählten Werts definieren und entscheiden, ob die Gesamtansicht für Analysen, operative Workflows, die nachgelagerte Veröffentlichung oder alle drei Zwecke verwendet wird. #### Nicht-Duplikat-Entscheidungen Ähnliche Datensätze gehören nicht immer zur selben Person oder Organisation. Zwillinge, Verwandte, Leistungserbringer mit häufigen Namen, gemeinsame Kontaktdaten im Haushalt und wiederverwendete Einrichtungsadressen erzeugen legitime Beinahe-Übereinstimmungen. Sobald ein Prüfer bestätigt, dass ein Paar verschiedene Entitäten darstellt, sollte die Plattform diese Entscheidung festhalten und verhindern, dass dasselbe Paar wiederholt als ungelöster Kandidat auftaucht. #### Manuelle und automatische Auflösung Die Automatisierung sollte die Kosten jedes Fehlers widerspiegeln. Ein Paar mit hoher Konfidenz kann automatisch zusammengeführt oder verknüpft werden. Ein mehrdeutiges Paar erfordert möglicherweise einen Datenpfleger (Data Steward). Ein schwaches Paar erfordert möglicherweise keine Maßnahme. Die Grenzen hängen von der Population, den verfügbaren Daten und den Folgen einer Fehlmaßnahme ab. Die Feinabstimmungsarbeit für ein großes Diagnostiklabornetzwerk verdeutlicht diesen Punkt. Falsche Zusammenführungen bargen ein besonders hohes Datenschutzrisiko, da sie Labordaten an die falsche Person weitergeben konnten. Das anfängliche Betriebsmodell bevorzugte daher die manuelle Überprüfung gegenüber einer aggressiven automatischen Zusammenführung. Gemeinsame Adressen, Einrichtungsadressen und umfangreiche Kontaktdaten erforderten zudem, dass das Modell vermied, wiederholte schwache Signale als unabhängige Belege zu behandeln. | **Maßnahme** | **Datensatzverhalten** | **Geeignet wenn** | **Erforderliche Absicherung** | |---|---|---|---| | Merge | Ein Datensatz überlebt, verwandte Daten können neu zugeordnet werden | Eine Autorität kontrolliert die Datensätze und die Überlebensregel | Vorschau, atomare Ausführung, Herkunftssicherung und Trennmöglichkeit | | Link | Quelldatensätze bleiben aktiv, eine Identitätsbeziehung wird gepflegt | Datensätze überschreiten System-, Mandanten- oder Governance-Grenzen | Explizite Clusterzugehörigkeit, Belege und Entknüpfungsmöglichkeit | | Golden View | Eine kanonische Ansicht wird aus erhaltenen Quellen erstellt | Konsumenten benötigen eine verwaltete Darstellung ohne destruktive Konsolidierung | Herkunft auf Feldebene und Aktualisierungsregeln | | Getrennt halten | Ähnliche Datensätze bleiben unterschiedlich | Belege sind unzureichend oder das Paar ist als verschieden bestätigt | Persistierte Nicht-Duplikat-Entscheidung | #### Hierarchische Identität Unternehmensnetzwerke benötigen häufig mehr als eine Auflösungsmaßnahme. Datensätze können innerhalb eines Mandanten, der sie besitzt, zusammengeführt werden, während die mandantenspezifischen Stammdatensätze netzwerkübergreifend verknüpft werden. Dies bewahrt die lokale Autorität und schafft dennoch eine unternehmensweite Identitätssicht. Dasselbe Muster kann Gesundheitsinformationsaustausch, klinisch integrierte Netzwerke, Akquisitionen und Healthcare-Plattformen mit kundspezifischer Governance bedienen. ![Hierarchische Identität: Datensätze werden innerhalb jedes Mandanten zusammengeführt, Mandanten-Stammdatensätze werden netzwerkübergreifend verknüpft](hierarchical-identity.svg) *Abbildung 1. Ein hierarchisches Betriebsmodell nach dem Prinzip „Merge within / Link across"* Die korrekte Topologie ist eine Geschäfts- und Governance-Entscheidung. Ein Produkt sollte sie unterstützen, ohne alle Datensätze in eine einzige globale Zusammenführungsrichtlinie zu zwingen. ### 2. Matching-Ansätze Die Healthcare-Identitätsabgleichung wird üblicherweise mit deterministischen Regeln, probabilistischen Modellen, externen Referenzdaten oder einer Kombination dieser Ansätze implementiert. Der Käufer muss die Mathematik nicht beherrschen, sollte aber verstehen, was jeder Ansatz voraussetzt und wo er versagt. | **Ansatz** | **Geeignet für** | **Wesentliche Einschränkungen** | |---|---|---| | Deterministisch oder regelbasiert | Exakte Identifikatoren, einfache Populationen, explizite Einschränkungen und hochsichere Regeln | Wird spröde, wenn Ausnahmen zunehmen, und reagiert sehr empfindlich auf fehlende oder inkonsistente Daten | | Probabilistisch | Unvollständige, verrauschte, widersprüchliche oder aus mehreren Quellen stammende Healthcare-Daten | Erfordert Kalibrierung, repräsentative Daten und Expertüberprüfung von Fehlern und Schwellenwerten | | Referenziell | Anreicherung lokaler Belege durch einen anbietergepflegten externen Identitätsdatensatz | Abdeckung, Herkunft, Datenschutz, zulässige Nutzung, Kosten, Latenz und Abhängigkeit vom Referenz-Asset | | Hybrid | Kombination strenger Einschränkungen, probabilistischer Belege und optionaler Anreicherung nach Anwendungsfall | Erfordert klare Vorrangregeln und transparente Belege, damit das Ergebnis steuerbar bleibt | #### Deterministisches Matching Deterministisches Matching wendet explizite Regeln an, wie z. B. die exakte Übereinstimmung bei einem vertrauenswürdigen Identifikator oder die Übereinstimmung bei einer definierten Kombination aus Name und Geburtsdatum. In diesem Leitfaden werden deterministisches und regelbasiertes Matching als eine Kategorie behandelt. Die Begriffe sind nicht in jeder Implementierung vollständig synonym, aber ihre Trennung verbessert die Kaufentscheidung nicht. Regeln sind leicht verständlich, wenn Daten stabil und die Fallanzahl gering ist. Sie werden schwer zu warten, wenn die Organisation Quellen, Populationen, Namensformate, Transliterationen, historische Werte oder widersprüchliche Identifikatoren hinzufügt. Ein wachsender Regelsatz kann auch den Kompromiss zwischen nicht erkannten Duplikaten und falschen Übereinstimmungen verbergen. #### Probabilistisches Matching Probabilistisches Matching bewertet die kombinierten Belege in einem Datensatzpaar. Die Übereinstimmung bei einem seltenen, zuverlässigen Identifikator kann mehr Belege liefern als die Übereinstimmung bei einem häufigen Nachnamen. Ein fehlender Wert kann neutral bleiben, anstatt wie eine Nichtübereinstimmung zu wirken. Ein vertauschtes Datum oder ein falsch geschriebener Name kann teilweise Belege liefern, anstatt eine exakte Regel zu verletzen. Für komplexe Healthcare-Umgebungen ist eine probabilistische Methode wie Fellegi–Sunter in der Regel der stärkste Standardansatz. Sie verarbeitet unvollkommene Daten, erzeugt einen Wert, der mehrere Entscheidungszonen unterstützen kann, und ermöglicht es der Organisation, Präzision und Trefferquote (Recall) bei verschiedenen Schwellenwerten zu messen. Die Feinabstimmungsarbeit von Health Samurai zeigt auch, warum das Modell weiterhin einer lokalen Kalibrierung bedarf. Gemeinsame Adressen, Platzhalterwerte, Familienkontaktdaten und quellenspezifische Fehler verändern, wie stark jedem Signal vertraut werden sollte. Die Bezeichnung des Algorithmus allein beweist wenig. Der Käufer sollte sich auf die resultierende Qualität, die für jede Entscheidung verfügbaren Belege und den Aufwand konzentrieren, das Modell anzupassen, wenn sich die Daten ändern. #### Referenzielles Matching Referenzielle Dienste vergleichen Kundendatensätze mit einem externen Identitätsgraphen oder einem demografischen Datensatz, der aus kommerziellen, öffentlichen oder anderen Quellen zusammengestellt wurde. Dies kann zusätzliche Belege liefern, wenn lokale Datensätze spärlich oder veraltet sind. Es kann auch wesentliche Einschränkungen mit sich bringen. Der Käufer sollte ermitteln, woher die Referenzdaten stammen, welche Populationen und geografischen Regionen sie abdecken, wie häufig sie aktualisiert werden, welche Belege zurückgegeben werden, ob eingereichte Datensätze gespeichert werden und ob die beabsichtigte Nutzung im Rahmen der geltenden Verträge und Gesetze zulässig ist. In den Vereinigten Staaten hängt die Genehmigung für einen Business Associate zur Durchführung eines Patienten-Matching-Dienstes vom maßgeblichen Vertrag und den zulässigen Nutzungen geschützter Gesundheitsinformationen ab. Andere Rechtssysteme können unterschiedliche Anforderungen stellen. Eine rechtliche und datenschutzrechtliche Prüfung sollte daher die spezifische Datenquelle und den Workflow abdecken, anstatt davon auszugehen, dass der Zugang zu einer Referenzdatenbank eine rechtmäßige Nutzung begründet. Referenzielles Matching kann auch Kosten pro Anfrage, Netzwerklatenz, Abdeckungsverzerrungen und langfristige Abhängigkeit vom Asset des Anbieters mit sich bringen. Diese Kompromisse können für einige Populationen gerechtfertigt sein. Sie sollten nicht automatisch als überlegen gegenüber einem gut kalibrierten Modell angesehen werden, das mit den eigenen Belegen der Organisation arbeitet. #### Hybrides Matching Ein hybrides Design kann probabilistische Bewertung mit deterministischen Schutzmaßnahmen und, wo gerechtfertigt, referenzieller Anreicherung kombinieren. Beispielsweise kann ein Modell probabilistische Belege für die Kandidatenbewertung verwenden, während eine strenge Regel eine automatische Zusammenführung verhindert, wenn zwei vertrauenswürdige Identifikatoren in Konflikt stehen. Die wichtige Anforderung ist, dass das Produkt erklären kann, welche Belege und welche Richtlinie zur endgültigen Entscheidung geführt haben. ### 3. Erklärbarkeit und Entscheidungsbelege Ein erklärbares System zeigt mehr als einen Gesamtwert. Ein Prüfer sollte in der Lage sein, die Quellwerte, Übereinstimmungen und Abweichungen auf Feldebene, die Stärke jedes Beitrags, den anwendbaren Schwellenwert und die für die Entscheidung verwendete Modell- oder Regelversion einzusehen. Diese Belege dienen mehreren Nutzern: - Ein Datenpfleger muss entscheiden, ob die Datensätze zusammengehören und welche Maßnahme sicher ist. - Ein Modellverantwortlicher muss falsch positive Ergebnisse, nicht erkannte Übereinstimmungen und unerwartete Muster verstehen. - Ein Prüfer muss rekonstruieren, welche Konfiguration und welche Benutzeraktion das Ergebnis erzeugt haben. - Ein Integrationsteam muss erklären, warum ein nachgelagertes Zusammenführungs-, Verknüpfungs- oder Unterdrückungsereignis stattgefunden hat. Erklärbarkeit muss Änderungen standhalten. Wenn das Modell nächsten Monat aktualisiert wird, sollte die Organisation weiterhin in der Lage sein, eine heute getroffene Entscheidung zu reproduzieren oder zu interpretieren. Das erfordert versionierte Konfigurationen, gespeicherte Quellwerte, strukturierte Auditdaten und eine Verknüpfung zwischen dem Matching-Beleg und der Auflösungsmaßnahme. Die Schnittstelle ist ebenso wichtig wie das zugrunde liegende Modell. Belege auf Feldebene, die nur in einer internen Datenbank vorhanden sind, sind für einen Datenpfleger nicht nützlich. Ein Produkt sollte sie über eine geeignete Überprüfungsschnittstelle oder API zugänglich machen, damit die Organisation sie in ihren eigenen Workflow einbetten kann. Dieselbe Anforderung gilt für automatisierte Entscheidungen. Eine hochkonfidente Maßnahme sollte die Belege, die Modellversion, den Schwellenwert, den Initiator, die betroffenen Ressourcen und das Ergebnis festhalten. Automatisierung ohne einen rekonstruierbaren Entscheidungsdatensatz schafft operationelle und Prüfungsrisiken. ## Teil II: Das erforderliche Betriebsmodell definieren ### 4. Das Ziel-MDM-Betriebsmodell definieren Die Organisation kann ihre Anforderungen definieren, sobald sie die verfügbaren Identitätsmaßnahmen und Matching-Ansätze versteht. Das Ziel-Betriebsmodell sollte kurz genug sein, um in einem Anbieter-Workshop verwendet zu werden, und spezifisch genug, um zu verhindern, dass jeder Anbieter ein anderes Problem demonstriert. | **Entscheidung** | **Was zu definieren ist** | **Beispielergebnis** | |---|---|---| | Umfang | Entitäten, Beziehungen, Quellen, Populationen und erste Implementierungsphase | Patient und Leistungserbringer in Phase eins, Organisation und Standort in Phase zwei | | Identität | Was als dieselbe Entität gilt und welchen Belegen vertraut wird | Lokale MRN ist nur innerhalb der zuweisenden Organisation eindeutig | | Auflösung | Wo zusammengeführt, verknüpft, eine Gesamtansicht erstellt oder Datensätze getrennt gehalten werden | Zusammenführung innerhalb eines Krankenhauses, Verknüpfung über Netzwerkteilnehmer hinweg | | Survivorship | Welche Werte überleben und wie Konflikte behandelt werden | Verifizierte Identifikatoren haben Vorrang vor nicht verifizierten Feeds; historische Werte bleiben nachvollziehbar | | Automatisierung | Welche Entscheidungen automatisch getroffen werden und welche eine Überprüfung erfordern | Automatische Verknüpfung oberhalb des genehmigten Schwellenwerts; Zusammenführung erfordert Genehmigung des Datenpflegers | | Governance | Eigentümerschaft, Berechtigungen, Audit, Aufbewahrung und Mandantengrenzen | Mandanten-Datenpfleger verwalten lokale Zusammenführungen; Enterprise-Nutzer verwalten nur Verknüpfungen | | Betrieb | Integrationen, Schnittstellen, Analysen, Volumina, Latenz und Support | Echtzeit-Registrierungsabgleich plus nächtliche Massenabstimmung und ausgehende Ereignisse | #### Umfang und Identität Beginnen Sie mit den Entitäten, die ein reales operationelles oder analytisches Risiko darstellen. Die Patientenidentität ist möglicherweise der erste Anwendungsfall, aber Leistungserbringer-, Organisations- und Standortdaten bestimmen häufig Zuordnungen, Überweisungsrouting, Netzwerkberichte und Abrechnungen. Jede Entität kann eigene Felder, Modelle, Schwellenwerte und Datenpflegeprozesse erfordern. Definieren Sie Identität im Kontext jeder Quelle. Derselbe Identifikatorwert kann innerhalb einer zuweisenden Organisation zuverlässig und ohne sein System in einer anderen bedeutungslos sein. Der aktuelle Name oder die aktuelle Adresse eines Leistungserbringers kann weniger nützlich sein als eine stabile NPI, dennoch kann das NPI-Register selbst doppelte Leistungserbringerdatensätze enthalten. Die Anforderung sollte beschreiben, welchen Belegen vertraut wird, und nicht lediglich verfügbare Felder auflisten. #### Auflösung und Survivorship Geben Sie für jeden Anwendungsfall die erforderliche Maßnahme und Autorität an. Definieren Sie, ob das System zusammenführen, verknüpfen, eine Gesamtansicht erstellen oder eine Nicht-Duplikat-Entscheidung bewahren soll. Definieren Sie dann Survivorship auf Feldebene: Quellpriorität, Aktualität, Verifizierungsstatus, Vollständigkeit, Gültigkeitsdaten und Behandlung widersprüchlicher Werte. Verwandte Ressourcen gehören in dieselbe Entscheidung. Eine Patientenzusammenführung kann Encounters, Observations, Claims, Tasks, Abonnements, zwischengespeicherte Identifikatoren und nachgelagerte Berechnungen betreffen. Eine Leistungserbringerzusammenführung muss möglicherweise die PractitionerRole-Historie und zeitpunktbezogene Zugehörigkeit erhalten. Das Betriebsmodell sollte angeben, welche verwandten Daten automatisch verschoben werden und welche einen separaten Workflow erfordern. #### Automatisierung und Datenpflege Definieren Sie das akzeptable Risiko und die erwartete Arbeitsbelastung. Wie kostspielig ist eine falsche Zusammenführung im Vergleich zu einem nicht erkannten Duplikat? Wie viele Fälle können pro Woche überprüft werden? Wer ist für eine Entscheidung verantwortlich? Kann die Überprüfung in einer dedizierten Schnittstelle stattfinden, oder muss sie in die Registrierung, das Health Information Management, den Leistungserbreibetrieb oder eine Kundenanwendung eingebettet werden? Die Antworten bestimmen Schwellenwerte, Warteschlangen, Berechtigungen, Belege und Schnittstellenanforderungen. Sie bestimmen auch, ob ein Produkt, das auf eine feste Datenpfleger-Maske angewiesen ist, zur Organisation passt. #### Governance und Integration Geben Sie die Grenzen an, die Identitätsentscheidungen respektieren müssen. Mandanten, Einrichtungen, juristische Personen, Quellsysteme und Datenaustauschpartner können unterschiedliche Modelle und unterschiedliche zulässige Maßnahmen erfordern. Definieren Sie, welche Nutzer Belege einsehen, Änderungen genehmigen, Modelle konfigurieren, Workflows anpassen und Entscheidungen rückgängig machen dürfen. Listen Sie die Systeme auf, die Identitätsentscheidungen erstellen, verbrauchen oder darauf reagieren. Schließen Sie Echtzeit- und Batch-Pfade, erforderliche Formate, nachgelagerte Ereignisbehandlung, Abstimmung und Fehlerbehebung ein. Ein MDM, das eine korrekte Entscheidung erzeugt, diese aber nicht in verbundenen Systemen weitergeben oder korrigieren kann, löst das vollständige Problem nicht. Das Ergebnis sollte ein präziser Satz von Richtlinien, Produktionsszenarien und Abnahmebedingungen sein. Detaillierte RFP-Fragen können später abgeleitet werden. Das Betriebsmodell ist die stabile Referenz, an der jedes Produkt bewertet wird. ### 5. Das Betriebsmodell in Produktanforderungen überführen #### Flexibles Identitäts- und Auflösungsmodell Das Produkt muss die erforderlichen Healthcare-Entitäten und -Beziehungen unterstützen, ohne jede neue Domäne als separate Implementierung zu behandeln. Käufer sollten mindestens prüfen, ob Anwendungsfälle für Patient, Leistungserbringer, Organisation, Standort, Mitglied und verbundene Person dieselbe Identitätsgrundlage nutzen können, während separate Modelle und Richtlinien beibehalten werden. Die Auflösung muss auf Maßnahmenebene konfigurierbar sein. Der Käufer benötigt möglicherweise Zusammenführung für eine Domäne, Verknüpfung für eine andere und eine hybride Hierarchie für eine dritte. Survivorship, Referenzbehandlung, Quelldisposition, Audit und nachgelagerte Auswirkungen sollten der Richtlinie der Organisation folgen. Forschungs- und Produktionserfahrung aus MPI-Implementierungen zeigt, dass diese Entscheidungen zwischen Organisationen erheblich variieren; ein einziger fest kodierter Zusammenführungsalgorithmus kann sie nicht alle abbilden. Korrekturen sind eine Produktfähigkeit, kein Support-Verfahren. Verlangen Sie Vorschau, atomare Ausführung wo angemessen, Trennmöglichkeit, Entknüpfung, Herkunftssicherung und persistierte Nicht-Duplikat-Entscheidungen. Fragen Sie, was passiert, wenn sich Daten nach der ursprünglichen Maßnahme ändern und ob eine Rücknahme spätere legitime Aktivitäten bewahren kann. #### Anpassbare Workflows, Schnittstellen und Analysen Healthcare-MDM-Workflows sind selten identisch. Eine Organisation kann mögliche Übereinstimmungen in einem zentralen HIM-Team überprüfen. Eine andere kann Leistungserbringer-Identitätskonflikte an den Netzwerkbetrieb weiterleiten. Ein Plattformunternehmen kann Überprüfungsmaßnahmen innerhalb seiner eigenen kundengerichteten Anwendung einbetten. Einige Implementierungen automatisieren die meisten Entscheidungen; andere erfordern eine Genehmigung für jede Zusammenführung. Das Produkt sollte daher die zugrunde liegenden Maßnahmen und Belege über APIs bereitstellen sowie nützliche Verwaltungsschnittstellen anbieten. Käufer sollten zwischen drei Ebenen unterscheiden: - Eine integrierte Schnittstelle, die für den Standard-Workflow funktioniert. - Eine konfigurierbare Schnittstelle, die Felder, Belege, Maßnahmen, Rollen und Warteschlangenverhalten ändern kann. - Ein einbettbares API- oder Komponentenmodell, das es der Organisation ermöglicht, eine workflowspezifische Erfahrung zu gestalten. Dashboards müssen ebenfalls zum Betriebsmodell passen. Nützliche Kennzahlen umfassen ausstehende und abgeschlossene Überprüfungen, Warteschlangenalter, Entscheidungsertrag, Duplikatprävalenz, automatische Auflösungsrate, Latenz, Durchsatz, Fehler, Modellversionen und Auditaktivität. Wenn das Produkt die erforderliche Ansicht nicht bietet, sollte der Käufer strukturierte Betriebsdaten in eine externe Analyseplattform exportieren können. Schnittstellen- und Dashboard-Anforderungen werden sich nach der Inbetriebnahme ändern. Die Bewertung sollte daher die Kosten und Vorlaufzeiten für deren Änderung einschließen, nicht nur die Qualität der anfänglichen Maske. #### Architektur und Integration FHIR-Unterstützung sollte als Datenverhalten getestet und nicht als Label akzeptiert werden. Stellen Sie fest, ob FHIR-Ressourcen das primäre Identitätsmodell sind oder ob die Plattform in ein proprietäres Schema übersetzt. Erstellen Sie eine profilierte Ressource mit mehreren Identifikatoren und Erweiterungen, führen Sie einen Abgleich durch, führen Sie eine Auflösungsmaßnahme aus und rufen Sie die Quelle, das Ergebnis, die Herkunft und die Auditdaten ab. Der Test zeigt, was den vollständigen Durchlauf übersteht. Integrationsanforderungen sollten FHIR-APIs, Batch-Aufnahme, Ereignisse, Webhooks oder Abonnements, Mappings, Behandlung verwandter Ressourcen, nachgelagerte Abstimmung und Fehlerbehebung abdecken. Viele Healthcare-Umgebungen erfordern auch HL7v2, C-CDA, Flat Files, SFTP oder benutzerdefinierte Feeds. Klären Sie, ob das MDM-Produkt diese Formate direkt unterstützt oder ob eine separate Integrationsschicht Teil der vorgeschlagenen Architektur ist. Mappings und ausgehende Schemas ändern sich. Ein nachhaltiges Design hält sie versioniert, testbar und deploybar, ohne das MDM neu aufzubauen. Der Käufer sollte wissen, welche Änderungen sein eigenes Team vornehmen kann und welche das Engineering des Anbieters erfordern. #### Enterprise-Eignung Enterprise-Eignung umfasst mehr als die Anzahl der Datensätze. Die Plattform muss den erwarteten Mix aus Online-Abgleich, Massenabstimmung, kontinuierlicher Verarbeitung, Gleichzeitigkeit und verrauschten Daten unterstützen. Leistungsnachweise sollten den Datensatz, das Kandidatenvolumen, das Modell, die Infrastruktur, die Worker-Konfiguration, Zeitgrenzen und die Softwareversion dokumentieren. Governance-Anforderungen umfassen Mandantenisolierung, mandantenspezifische Richtlinien, mandantenübergreifende Identität wo zulässig, rollenbasierte Zugriffskontrolle, strukturiertes Audit, Authentifizierung, Verschlüsselung, Aufbewahrung, Backup, Wiederherstellung und Datenresidenz. Deployment-Verantwortlichkeiten müssen explizit sein: Software, Datenbank, Infrastruktur, Upgrades, Monitoring, Verfügbarkeit und Notfallwiederherstellung können verschiedenen Parteien obliegen. Die Organisation sollte auch in der Lage sein, Identitätsbeziehungen, Konfigurationen, Entscheidungen und Audithistorie zu exportieren. Exit gehört zur Enterprise-Eignung, da der Identitätsgraph zu grundlegender Infrastruktur wird, sobald nachgelagerte Systeme davon abhängig sind. ## Teil III: Anbietereignung bewerten ### 6. Produkteignung und Anpassungsfähigkeit klassifizieren Ein Anbieter kann eine Anforderung auf verschiedene, wesentlich unterschiedliche Weisen mit „Ja" beantworten. Die Fähigkeit kann im Standardprodukt verfügbar sein, als Konfiguration bereitgestellt werden, durch benutzerdefinierte Entwicklung erreichbar sein, von einer anderen Komponente abhängen, für ein zukünftiges Release geplant sein oder nicht unterstützt werden. All diese Antworten als gleichwertig zu behandeln, verbirgt Kosten und Lieferrisiken. | **Status** | **Bedeutung** | **Anzufordernde Belege** | |---|---|---| | Nativ | Im unterstützten Produkt ohne projektspezifische Entwicklung verfügbar | Dokumentation und Live-Demo | | Konfigurierbar | Durch unterstützte Einstellungen, Modelle, Regeln oder Vorlagen implementiert | Käufergeführte Konfigurationsänderung und wiederholbarer Deployment-Pfad | | Anpassbar | Erfordert Code, eine benutzerdefinierte UI, eine Integration oder eine projektspezifische Erweiterung | Umfang, Eigentümer, Schätzung, Upgrade-Modell, Tests und Support-Konditionen | | Externe Komponente | Abhängig von einem anderen Produkt oder Dienst in der vorgeschlagenen Architektur | Komponentenverantwortung, Datenfluss, Lizenz, SLA und Fehlerverhalten | | Roadmap | Geplant, aber in der bewerteten Version nicht verfügbar | Datierte vertragliche Zusage, wenn die Fähigkeit wesentlich ist | | Nicht unterstützt | Kann nicht innerhalb akzeptabler Einschränkungen geliefert werden | Als Lücke erfassen, anstatt es in ein wenig vertrauenswürdiges Versprechen umzuwandeln | #### Bestimmte Anforderungen können einen Anbieter ausschließen Gesundheitsorganisationen stellen während der Bewertung häufig fest, dass eine Kernanforderung außerhalb des Betriebsmodells eines Produkts liegt. Ein Anbieter unterstützt möglicherweise Zusammenführung, aber keine Verknüpfung. Er erlaubt möglicherweise eine globale Survivorship-Richtlinie, aber keine mandantenspezifischen Richtlinien. Seine Überprüfungs-UI zeigt möglicherweise die falschen Belege oder Maßnahmen. Seine Integrationsschicht veröffentlicht möglicherweise einen zusammengeführten Identifikator, aber keine reversible Beziehung oder ein Korrekturelement. Diese Lücken sind keine sekundären Details. Wenn die Richtlinie der Organisation lokale Zusammenführung und mandantenübergreifende Verknüpfung erfordert, kann ein Produkt, das nur einen einzigen globalen Golden Record erstellt, nicht durch Scoring-Gewichte behoben werden. Wenn Datenpfleger in einer bestehenden Registrierungsanwendung arbeiten müssen, kann eine anbieterspezifische Warteschlange operativ unbrauchbar sein, auch wenn die Matching-Engine stark ist. Identifizieren Sie diese Einschränkungen vor dem gewichteten Scorecard. Ein Anbieter, der eine erforderliche Governance-, Sicherheits-, Deployment- oder Workflow-Bedingung nicht erfüllt, sollte sich nicht durch das Sammeln von Punkten für nicht verwandte Funktionen erholen. #### Die Änderungsfähigkeit testen Die anfängliche Implementierung ist nur eine Version des Betriebsmodells. Quellen ändern ihre Dateistrukturen. Neue Populationen kommen hinzu. Ein Unternehmen fügt einen Mandanten hinzu. Überprüfungsverantwortlichkeiten wechseln zwischen Teams. Eine neue Regulierung ändert Aufbewahrung oder Zugang. Nutzer stellen fest, dass das erste Dashboard oder die erste Maske die tatsächlich durchgeführte Arbeit nicht unterstützt. Die Bewertung sollte daher eine kontrollierte Änderung nach der Basisdemonstration einschließen. Bitten Sie den Anbieter, eine wesentliche Anforderung zu ändern, zum Beispiel: - einen Abgleichs- oder Überprüfungsschwellenwert für eine Population ändern, ohne eine andere zu beeinflussen; - eine quellenspezifische Survivorship-Bedingung hinzufügen; - einen Zusammenführungsfluss an einer Governance-Grenze in einen Verknüpfungsfluss ändern; - einen weiteren Beleg und eine neue Korrekturmaßnahme in der Überprüfungsschnittstelle bereitstellen; - ein eingehendes Mapping oder eine ausgehende Ereignis-Nutzlast ändern; - eine Dashboard-Kennzahl oder einen Export hinzufügen, den der Betrieb benötigt. Erfassen Sie, wer die Änderung durchführt, wie lange sie dauert, ob ein Release erforderlich ist, wie sie getestet wird und wie sie von der Entwicklung in die Produktion gelangt. Diese Übung zeigt den praktischen Unterschied zwischen einer konfigurierbaren Plattform und einer Professional-Services-Abhängigkeit. #### Workflow und UI separat bewerten Eine gute Schnittstelle demonstriert den aktuellen Workflow. Sie beweist nicht, dass der Workflow geändert werden kann. Stellen Sie fest, ob die UI fest, konfigurierbar oder austauschbar ist; ob jede UI-Maßnahme auch über eine API verfügbar ist; und ob der Käufer unterschiedliche Erfahrungen für Datenpfleger, Administratoren, Analysten und Anwendungsnutzer erstellen kann. Dasselbe gilt für die Betriebsanalysen. Ein Dashboard sollte die Fragen beantworten, die die Organisation zur Verwaltung von Qualität und Arbeitsbelastung benötigt. Wenn das integrierte Dashboard das nicht kann, werden strukturierte Exporte und dokumentierte Datenmodelle unerlässlich. Screenshots sind schwache Belege; der Anbieter sollte die erforderliche Ansicht konfigurieren oder zeigen, wie der Käufer sie erstellen würde. ### 7. Einen Proof of Capability durchführen Eine geskriptete Demonstration zeigt den vom Anbieter gewählten Pfad. Ein Proof of Capability testet den vom Käufer benötigten Pfad. Er sollte repräsentative Daten, vereinbarte Szenarien und Abnahmebedingungen verwenden, die vor Bekanntgabe der Ergebnisse definiert wurden. #### Repräsentative Daten Die Stichprobe sollte bestätigte Übereinstimmungen und Nicht-Übereinstimmungen aus jeder wichtigen Quelle und Population enthalten. Schließen Sie die Fälle ein, die reale Fehler verursachen: - fehlende und veraltete demografische Daten; - vertauschte Daten und Ziffern; - Aliase, Namensänderungen, Transliteration und umgeordnete Namen; - gemeinsame Telefonnummern, Haushaltsadressen, Einrichtungsadressen und häufige Leistungserbringernamen; - Platzhalter- oder Standardwerte; - widersprüchliche vertrauenswürdige Identifikatoren; - mehrere Identifikatorsysteme; - Zwillinge, Verwandte und Datensätze, die zuvor von Datenpflegern aufgelöst wurden; - jeden Mandanten, Quellentyp, jede geografische Region oder Population, die möglicherweise ein anderes Verhalten erfordern. Verwenden Sie einen beschrifteten Validierungssatz, der nicht vollständig während der Feinabstimmung verbraucht wird. Wenn der Anbieter das Modell gegen jedes Bewertungspaar konfiguriert, misst die abschließende Kennzahl die Anpassung an die Testdatei und nicht die Leistung bei unbekannten Produktionsdaten. #### Qualität und Arbeitsbelastung messen Eine Gesamtgenauigkeitszahl kann von einfachen Nicht-Übereinstimmungen dominiert werden. Fordern Sie ausreichend Informationen, um die Fehlertypen und die operative Belastung zu unterscheiden. | **Kennzahl** | **Unterstützte Entscheidung** | |---|---| | Präzision | Wie viele als Übereinstimmungen klassifizierte Datensätze tatsächlich Übereinstimmungen sind | | Trefferquote (Recall) | Wie viele bekannte Duplikate der Prozess findet | | Falsche Übereinstimmungen | Risiko, verschiedene Personen oder Entitäten zu verbinden | | Nicht erkannte Übereinstimmungen | Verbleibende Fragmentierung nach dem Abgleich | | Überprüfungsvolumen | Anzahl der Fälle, die die gewählten Schwellenwerte an Datenpfleger senden | | Überprüfungsertrag | Anteil der überprüften Kandidaten, die als Übereinstimmungen bestätigt werden | | Latenz | Eignung für Echtzeit-Registrierung oder API-Workflows | | Durchsatz | Zeit und Infrastruktur, die für Massen- oder kontinuierliche Verarbeitung erforderlich sind | Berichten Sie die Ergebnisse nach sinnvollen Segmenten, nicht nur aggregiert. Ein Modell kann insgesamt gut abschneiden, während es bei einer Quelle, einer Minderheitspopulation, einem Mandanten oder einem Datenqualitätsmuster versagt. Die gewählten Schwellenwerte sollten auch die relativen Kosten von falschen Übereinstimmungen, nicht erkannten Übereinstimmungen und manueller Überprüfung widerspiegeln. #### Erforderliche Szenarien Der Proof sollte sechs miteinander verbundene Szenarien abdecken: 1. **Eine Entscheidung erklären.** Gleichen Sie repräsentative Datensätze ab und zeigen Sie die Quellwerte, Belege auf Feldebene, den Wert, den Schwellenwert, die Modellversion und die Klassifizierung. 2. **Die Auflösungsrichtlinie anwenden.** Führen Sie das erforderliche Zusammenführungs-, Verknüpfungs-, Gesamtansichts-, Survivorship- und Nicht-Duplikat-Verhalten aus, anstatt das Standardbeispiel des Anbieters. 3. **Den menschlichen Workflow ausführen.** Leiten Sie einen mehrdeutigen Fall an den vorgesehenen Nutzer weiter, stellen Sie die erforderlichen Belege und Maßnahmen bereit, schließen Sie die Entscheidung ab und prüfen Sie den Auditdatensatz. 4. **Die Integration testen.** Verarbeiten Sie einen echten eingehenden Pfad und ein ausgehendes Entscheidungs- oder Korrekturelement, einschließlich Mappings und Fehlerbehandlung. 5. **Einen Fehler korrigieren.** Trennen Sie eine abgeschlossene Zusammenführung oder Verknüpfung, bewahren Sie die Herkunft und zeigen Sie, wie verwandte Ressourcen und nachgelagerte Systeme behandelt werden. 6. **Eine Anforderung ändern.** Ändern Sie ein Modell-, Workflow-, Schnittstellen-, Mapping- oder Dashboard-Anforderung und wiederholen Sie den betroffenen Test. Testen Sie die Leistung separat mit einem produktionsähnlichen Volumen und Datenprofil. Fordern Sie eine Benchmark-Aussage, die den Datensatz, die Duplikatprävalenz, das Modell, Indizes oder die Kandidatenstrategie, die Infrastruktur, die Gleichzeitigkeit, Worker, enthaltene Verarbeitungsstufen, die Softwareversion und die Messgrenzen benennt. #### Belege sichern Erfassen Sie für jede Anforderung, ob das Ergebnis aus dem Standardprodukt, der unterstützten Konfiguration, der benutzerdefinierten Entwicklung, einer externen Komponente oder einer Roadmap-Zusage stammt. Speichern Sie die Konfiguration, Ergebnisexporte, Screenshots wo nützlich, Benchmark-Bedingungen und die Abnahmeentscheidung. Der endgültige Vertrag sollte wesentliche Schlussfolgerungen aus dem Proof widerspiegeln. Ein erfolgreicher Prototyp garantiert nicht, dass dieselbe Anpassung durch Upgrades unterstützt, in der Lizenz enthalten oder durch ein SLA abgedeckt wird. ## Teil IV: Die kommerzielle Realität vergleichen ### 8. Kosten, Abhängigkeit und Wachstum Der Lizenzpreis ist nur eine Komponente der Healthcare-MDM-Kosten. Der nützliche Vergleich ist ein Drei-Jahres-Szenario, das auf dem Ziel-Betriebsmodell und dem erwarteten Wachstum basiert. **Drei-Jahres-Kosten umfassen** Softwarelizenzen, Implementierung, Datenprofilerstellung, Modellkonfiguration, Integration, Mappings, benutzerdefinierte Workflows und Schnittstellen, Infrastruktur, Umgebungen, Datenpflege-Personalkosten, Support, Upgrades, Änderungsanfragen, Datenwachstum und Exit. Fragen Sie, was jede Komponente des Preises verändert: - Datensätze, Entitäten, API-Aufrufe, Abgleichstransaktionen oder Batch-Jobs; - Quellsysteme, Nachrichtentypen, Mappings und Konnektoren; - Domänen, Abgleichsmodelle, Mandanten, Einrichtungen oder juristische Personen; - Produktions- und Nicht-Produktionsumgebungen; - Datenpfleger-, Administrator- oder API-Nutzer; - Speicher, Aufbewahrung, Auditvolumen, Verfügbarkeit und Support-Tier; - benutzerdefinierte Entwicklung, Optimierung und zukünftige Migration. Anbieterabhängigkeit ist ein separater Kostentreiber. Eine niedrige Lizenz kann teuer werden, wenn jede Schwellenwertänderung, jedes Mapping-Update, jede Workflow-Anpassung oder jede UI-Modifikation ein bezahltes Service-Engagement erfordert. Schätzen Sie die Anzahl der pro Jahr erwarteten Routineänderungen und kalkulieren Sie sie dann mit dem tatsächlichen Liefermodell des Anbieters in Zeit und Geld. Pauschallizenzen können die Softwarekomponente vorhersehbarer machen, wenn Datenvolumen und Akzeptanz wachsen. Sie beseitigen keine Implementierungs-, Infrastruktur-, Integrations-, Feinabstimmungs- oder Betriebskosten. Das Angebot sollte diese Kosten trennen, damit der Käufer sehen kann, welche Ausgaben mit der Nutzung und welche mit der Komplexität skalieren. Der Exit sollte vor dem Kauf kalkuliert werden. Bestätigen Sie, dass die Organisation Quellbeziehungen, Cluster, Gesamtansichten, Abgleichskonfigurationen, Nicht-Duplikat-Entscheidungen, Zusammenführungs- und Verknüpfungshistorie, Auditdatensätze und die Daten abrufen kann, die zur Rekonstruktion des nachgelagerten Identitätszustands benötigt werden. ### 9. Häufige Einkaufsfallen #### Die höchste Genauigkeitsangabe auswählen Anbieter können unterschiedliche Datensätze, Definitionen, Schwellenwerte und Nenner verwenden. Vergleichen Sie Präzision, Trefferquote, falsche Maßnahmen und Überprüfungsaufwand anhand derselben repräsentativen Stichprobe. #### Matching als das gesamte Produkt behandeln Ein starker Wert reicht nicht aus. Auflösung, Survivorship, Korrektur, Datenpflege, Integration, Audit und Weitergabe bestimmen, ob die Entscheidung sicher genutzt werden kann. #### Nur einfache Duplikate testen Einfache Beispiele verbergen das relevante Verhalten. Schließen Sie gemeinsame Adressen, widersprüchliche Identifikatoren, fehlende Daten, Transliteration, häufige Namen und bekannte Produktionsfehler ein. #### FHIR-Unterstützung mit FHIR-nativem Verhalten gleichsetzen Ein FHIR-Endpunkt kann in ein proprietäres Schema übersetzen. Testen Sie Profile, Erweiterungen, zuweisende Systeme, Historie, Beziehungen, Herkunft und Export durch einen vollständigen Durchlauf. #### Ein festes Betriebsmodell akzeptieren Ein Produkt kann ausgezeichnete Standardwerte haben und dennoch für die Zusammenführungsrichtlinie, die Governance-Grenze, den Überprüfungsprozess oder die UI der Organisation falsch sein. Demonstrieren Sie den Workflow des Käufers und eine zukünftige Änderung. #### Datenpflegekosten unterschätzen Eine Konfiguration, die die Trefferquote maximiert, kann die Überprüfungswarteschlange überfluten. Schätzen Sie wöchentliches Volumen, Überprüfungsertrag, Warteschlangenalter und Datenpfleger-Stunden bei den vorgeschlagenen Schwellenwerten. #### Einen Prototyp mit dem Produkt verwechseln Identifizieren Sie benutzerdefinierten Code, externe Komponenten, Roadmap-Elemente, nicht unterstützte Erweiterungen und Upgrade-Verantwortlichkeiten. Fordern Sie kommerzielle Konditionen und Support-Bedingungen für alles Wesentliche. #### Korrekturen und Exit ignorieren Zusammenführungs-, Verknüpfungs- und Gesamtansichtsentscheidungen werden zu Abhängigkeiten für andere Systeme. Testen Sie Rücknahme und Export, bevor diese Abhängigkeiten bestehen. ### 10. Entscheidungs-Scorecard Setzen Sie Gewichtungen fest, bevor Anbieter Ergebnisse präsentieren. Bewerten Sie jedes Kriterium von null bis fünf, multiplizieren Sie es mit seiner Gewichtung und dividieren Sie durch fünf. Verwenden Sie eine Ausschlussbedingung für jede Anforderung, bei der kein Kompromiss möglich ist. | **Kriterium** | **Gewichtung** | **Mindestbelege** | |---|---|---| | Matching-Qualität und Erklärbarkeit | 20 | Ergebnisse mit Käuferdaten und Belege auf Feldebene