DE102007026799A1 - Systeme und Verfahren zur Verfeinerung der Identifikation von Kandidaten für klinische Studien - Google Patents

Systeme und Verfahren zur Verfeinerung der Identifikation von Kandidaten für klinische Studien Download PDF

Info

Publication number
DE102007026799A1
DE102007026799A1 DE102007026799A DE102007026799A DE102007026799A1 DE 102007026799 A1 DE102007026799 A1 DE 102007026799A1 DE 102007026799 A DE102007026799 A DE 102007026799A DE 102007026799 A DE102007026799 A DE 102007026799A DE 102007026799 A1 DE102007026799 A1 DE 102007026799A1
Authority
DE
Germany
Prior art keywords
conditions
data
patient
pool
user
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
DE102007026799A
Other languages
English (en)
Inventor
Philip D. Chicago Setimi
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
General Electric Co
Original Assignee
General Electric Co
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by General Electric Co filed Critical General Electric Co
Publication of DE102007026799A1 publication Critical patent/DE102007026799A1/de
Withdrawn legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/10—Office automation; Time management
    • G—PHYSICS
    • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H10/00—ICT specially adapted for the handling or processing of patient-related medical or healthcare data
    • G16H10/20—ICT specially adapted for the handling or processing of patient-related medical or healthcare data for electronic clinical trials or questionnaires
    • G—PHYSICS
    • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H10/00—ICT specially adapted for the handling or processing of patient-related medical or healthcare data
    • G16H10/60—ICT specially adapted for the handling or processing of patient-related medical or healthcare data for patient-specific data, e.g. for electronic patient records
    • G—PHYSICS
    • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H50/00—ICT specially adapted for medical diagnosis, medical simulation or medical data mining; ICT specially adapted for detecting, monitoring or modelling epidemics or pandemics
    • G16H50/70—ICT specially adapted for medical diagnosis, medical simulation or medical data mining; ICT specially adapted for detecting, monitoring or modelling epidemics or pandemics for mining of medical data, e.g. analysing previous cases of other patients

Abstract

Bestimmte Ausführungsformen der vorliegenden Erfindung ergeben Systeme und Verfahren zur Verfeinerung der Identifikation von Kandidaten für klinische Studien. In einer Ausführungsform kann das Verfahren (1100) einen Empfang (1110) mehrerer klinischer Bedingungen an einer Benutzerschnittstelle umfassen. Die Bedingungen können generell mit kodierten Begriffen in elektronischen medizinischen Patientenakten verknüpft sein. Das Verfahren kann ferner einen Empfang (1120) von Parametern zur genauen Anpassung einer Durchsuchung von elektronischen medizinischen Daten nach klinischen Bedingungen umfassen. Zum Beispiel können die Parameter die Bedingungen gewichten und eine Rangklassifizierung der Bedingungen, eine Bestimmung, ob die Bedingungen für den Pool obligatorisch sind, und eine Bestimmung einer prozentualen Abweichung für numerische Bereiche enthalten. Das Verfahren kann ferner eine Ausführung (1130) einer Optimierungsfunktion zur Erzeugung eines Pools gemäß den spezifizierten Bedingungen und Parametern umfassen. Das Verfahren kann ferner eine Anzeige (1140) des Pools in einer Reihenfolge umfassen, die von den am besten geeigneten Ergebnissen zu den am wenigsten geeigneten Ergebnissen verreicht.

Description

  • HINTERGRUND DER ERFINDUNG
  • Die vorliegende Erfindung betrifft allgemein eine Durchsuchung und Analyse von elektronischen medizinischen Aufzeichnungsdaten. Insbesondere bezieht sich die vorliegende Erfindung auf die Verfeinerung der Identifikation von Kandidaten für klinische Studien auf der Grundlage von elektronischen medizinischen Aufzeichnungsdaten.
  • Viele Aspekte in der Gesundheitsindustrie nehmen zunehmend einen elektronischen Charakter an. In Krankenhäusern werden typischerweise Computersysteme eingesetzt, um die verschiedenen Abteilungen innerhalb eines Krankenhauses zu leiten, und Daten über jeden Patienten werden von verschiedenen Computersystemen gesammelt. Beispielsweise kann ein Patient in ein Krankenhaus eingewiesen werden, damit bei ihm ein transthorakales Echo (TTE) durchgeführt wird. Informationen über den Patienten (z.B. demographische und Versicherungsinformationen) könnten durch das Krankenhausinformationssystem (HIS, Hospital Information System) erfasst und in einer Patientenakte bzw. einem Patientendatensatz gespeichert werden. Diese Informationen könnten dann beispielsweise an das System der Kardiologischen Abteilung weitergegeben werden (das allgemein als kardiovaskuläres Informationssystem oder CVIS (Cardio Vascular Information System) bekannt ist). Typischerweise ist das CVIS ein Produkt einer Firma, während das HIS das Produkt einer anderen Firma ist. Folglich können sich die Datenbanken dieser bei den unterscheiden. Ferner können Informationssysteme die Daten bei unterschiedlichen Auflösungsniveaus aufnehmen/speichern und versenden. Sobald die Patienteninformation von dem CVIS empfangen wurde, kann der Patient für eine TTE im Echolabor eingeplant werden. Als nächstes wird die TTE durch einen Sonographierenden durchgeführt. Bilder und Messungen werden erfasst und an den CVIS-Server geschickt. Der ablesende Arzt (z.B. ein Echokardiographiespezialist) setzt sich an eine Prüfstation und führt die TTE-Untersuchung des Patienten durch. Der echokardiographierende Arzt beginnt dann damit, sich die Bilder und Messwerte anzusehen und stellt einen vollständigen medizinischen Bericht über die Untersuchung zusammen. Wenn der echokardiographierende Arzt den medizinischen Bericht fertig gestellt hat, wird der Bericht an den CVIS-Server gesandt, wo er gespeichert und anhand der Patientenidentifikationsdaten dem Patienten zugeordnet wird. Dieser fertig gestellte medizinische Bericht ist ein Beispiel für die Art von Bericht, der an ein Datenlager (Datenrepositorium) für eine öffentliche Datensuche bzw. -auswertung gesendet werden kann. Ebenso können Angaben zu medikamentösen Behandlungen, wie eine Dokumentation und/oder Verschreibung, sowie Laborergebnisse und/oder Vitalzeichen elektronisch generiert und in einem Datenspeicher bzw. -repositorium gespeichert werden.
  • Heute sind die Hersteller von medizinischen Geräten und Pharmaunternehmen mit einer stetig wachsenden Herausforderung konfrontiert, was die Sammlung von klinischen Daten in Bezug auf die Verwendung ihrer Produkte im reellen Leben anbelangt. Durch die Umstellung auf Datenverarbeitung bei den medizinischen Patientenberichten wird es leichter, lebensechte Anwendungsdaten zu erhalten. Ferner sind die Daten zur Gewinnung von größeren Mengen nützlicher Informa tionen leichter zu kombinieren und zu analysieren (z.B. aufzufinden oder auszuwerten).
  • Mit der Weiterentwicklung der medizinischen Technologie schreitet auch die klinische Analyse in ihrer Entwicklung fort. Wachsende Datenmengen werden elektronisch generiert und archiviert. Mit dem Aufkommen von klinischen Informationssystemen kann eine Patientengeschichte per Knopfdruck verfügbar sein. Während die Zugänglichkeit der Informationen von Vorteil ist, ist Zeit in einem klinischen Umfeld ein knappes Gut. Um die Entwicklung der medizinischen Technologie voll auszunutzen zu können, wäre es sehr wünschenswert, wenn die klinischen Informationen geordnet und standardisiert wären.
  • Auch wenn die klinischen oder mit Bildern im Zusammenhang stehenden Informationen geordnet sind, werden Daten von gängigen Systemen oft in einem Format geordnet, das von den Entwicklern festgelegt wurde und für einen oder mehrere Mediziner eines Fachgebiets nicht verwendungsfähig sind. Zusätzlich können Informationen in einem Format gespeichert sein, welches sich nicht für die Datenauffindung und -verwendung in anderen Kontexten eignet. Daher besteht die Notwendigkeit, die Daten und Befehle auf eine Weise zu strukturieren, die leichter zu verstehen und anzuwenden ist.
  • Es sind Datenlagerhaltungsverfahren verwendet worden, um Patienteninformationen, die aus medizinischen Kostenrechnungen und elektronischen medizinischen Aufzeichnungen EMA (EMR, Electronic Medical Records) hergeleitet werden, zu sammeln, zu säubern, aufzubereiten, bereitzustellen, zu melden und zu analysieren. Patientendaten können aus zahlreichen EMA-Datenbanken extrahiert werden, die sich an Standorten von Patientenpflegeversorgern PBV (PCP, Patient Care Provider) an geographisch weit auseinander liegenden Orten befinden, und dann an ein zentral liegendes Datenlager übertragen und darin gespeichert werden. Das zentrale Datenlager kann eine Informationsquelle für bevölkerungsbasierte Profilberichte zu Arztproduktivität, Vorsorge, Krankheits-Handhabungs-Statistiken und Erforschung klinischer Resultate dienen. Patientendaten sind empfindlich und vertraulich, und daher müssen spezifische identifizierende Informationen entfernt werden, bevor sie von einem PBV-Standort an ein zentrales Datenlager übertragen werden. Diese Entfernung von Identifikationsdaten muss gemäß den "Vorschriften des bundesstaatlichen „Health Insurance Portability and Accountability Act" (HIPAA) erfolgen. Sämtliche Daten, die sich in einer öffentlichen Datenbank befinden, dürfen nicht die Identität der individuellen Patienten preisgeben, deren medizinische Informationen in der Datenbank enthalten sind. Augrund dieser Anforderung muss jede in einem medizinischen Bericht oder einer medizinischen Akte enthaltene Information, welche sich auf ein bestimmtes Individuum zurückführen lässt, aus dem Bericht oder der Akte entfernt werden, bevor die Daten zu einer Datenlagereinrichtung für öffentliche Datensuche bzw. -auswertung hinzugefügt werden.
  • Patientendaten können auf vielfältige Art und Weise für den medizinischen Fortschritt sowie für die Diagnose und Behandlung von Patienten nützlich sein. Um zum Beispiel die Wirkung eines bestimmten Medikamentes oder einer bestimmten Behandlung bei einem Patienten richtig einschätzen zu können, ist es hilfreich, alle medizinischen Berichte zu diesem speziellen Patienten zu analysieren. Die Entfernung von Daten, die dazu benutzt werden können, einen individu ellen Patienten nachzuverfolgen, kann es unmöglich machen, alle medizinischen Berichte, die zu einem bestimmten Patienten gehören, zusammenzufassen und zu analysieren. Zusätzlich ist eines der Ziele der Bevölkerungsanalyse, innerhalb der Bevölkerung eine Risikogruppe zusammenzufassen, die aus Individuen besteht, die Kandidaten für einen klinischen Eingriff sein können. Deidentifizierte Daten sind für die Patientenbehandlungsversorger nicht sehr hilfreich, da diese die Identität ihrer eigenen Patienten kennen müssen, um sie behandeln zu können. Für Benutzer des Systems könnte die Möglichkeit notwendig sein, die Patienten für Nachfolgeuntersuchungen erneut zu identifizieren. Portalbenutzer könnten darauf angewiesen sein, die Patienten in einem Prozess zu reidentifizieren, welcher das Portalsystem nicht einschließt, d.h. der Prozess der Reidentifikation findet auf dem lokalen Benutzersystem statt.
  • Medizinischer Fortschritt vollzieht sich unter anderem durch die Verwaltung von klinischen Studien. Bei der jetzigen Identifizierung von Teilnehmern klinischer Studien werden typischerweise Massenmedien eingesetzt, um den Bedarf an Patienten publik zu machen, welche einer Liste von klinischen Bedingungen entsprechen, die den Kandidaten für eine klinische Studie möglicherweise qualifiziert. Dieser manuelle, auf Massenmedien beruhende Auswahlprozess ist aufgrund der Kosten für die Verwendung der Massenmedien und der für die Ausarbeitung einer Meldung, die Ausstrahlung der Meldung und das Warten auf Reaktionen benötigten Zeit langwierig und teuer. Daher wären Systeme und Verfahren zur schnelleren Identifizierung potentieller Teilnehmer einer klinischen Studie sehr erwünscht. Auch wären Systeme und Verfahren zur präziseren und kostengünstigeren Identifizie rung von potentiellen Teilnehmern einer klinischen Studie wünschenswert.
  • Zurzeit entwerfen Forscher Protokolle für klinische Studien, indem sie die neusten Statistiken über Krankheitsinzidenz sowie veröffentlichte Literatur zu ähnlichen Studien verwenden, um klinische Bedingungen oder Parameter bestmöglich zu definieren, die einen potentiellen Untersuchungspool von signifikanter Größe und Qualität ergeben.
  • Die Erstellung eines solchen Protokolls beruht auf der Methode von „Versuch und Irrtum". Die Verwendung von Protokollentwurfsverfahren auf der Grundlage von Versuch und Irrtum umfasst einen hohen Aufwand, wenn für ein bestimmtes Protokoll die Anwerbung von Teilnehmern begonnen hat und z.B. aufgrund einer insignifikanten Anzahl von potentiellen Teilnehmern an einer Studie eine Veränderung des Protokolls erforderlich wird. Häufig erfordern Veränderungen des Protokolls, dass alle zuvor als qualifiziert beurteilten Patienten auf der Grundlage der aktuellsten Studienparameter neu geprüft werden müssen. Daher wären Systeme und Verfahren für eine verbesserte Anpassung von klinischen Studienprotokollen und Überprüfung von potentiellen Kandidaten für klinische Studien sehr wünschenswert.
  • Bei den zurzeit verwendeten Verfahren werden in einer frühen Phase einer Studie Forscher zur Teilnahme an der klinischen Studie rekrutiert, indem eine Vielzahl von Methoden verwendet wird, wozu auch Massenmedien, Datenbanken und Mund-zu-Mund-Propaganda gehören. Das Ziel der Rekrutierungsbemühungen ist es, Forscher mit einem klinischen Hintergrund und Forschungserfahrung zu identifizieren, welche die Studienkriterien erfüllen sowie auch einen Patientenbestand bedienen, der groß und fokussiert genug ist, als dass er Patienten umfasst, deren klinischer Hintergrund die Studienkriterien erfüllt. Oft rufen Sponsoren von klinischen Studien klinische Studienforscher an, um sowohl das Interesse als auch die Anzahl von Patienten, die die Studienkriterien erfüllen, einschätzen zu lassen. Bei dieser Selbstauskunfts-Methode wird die Anzahl der potentiellen Studienkandidaten regelmäßig überschätzt, da diese Einschätzungen aus der Erinnerung des Forschers und nicht aus einer tatsächlichen medizinischen Patientenakte stammen. Durch die Überschätzung des Patientenpools könnte es sein, dass die Studie ihre Ziele verfehlt, keine statistische Signifikanz erreicht, hohe Kosten verursacht, um dringend neue Teilnehmer zu finden, lange Verzögerungen mit sich bringt und/oder eine vollständige Veränderung des Studienprotokolls und damit auch eine erneute Rekrutierung von Teilnehmern erfordert.
  • Daher besteht ein Bedarf an Systemen und Verfahren zur verbesserten Definition einer klinischen Studie und Patientenauswahl. Es besteht der Bedarf an Systemen und Verfahren zur verbesserten Konfiguration von klinischen Versuchen in Übereinstimmung mit der HIPAA.
  • KURZBESCHREIBUNG DER ERFINDUNG
  • Bestimmte Ausführungsformen der vorliegenden Erfindung können ein Verfahren zur Durchsuchung kodierter elektronischer medizinischer Daten umfassen. Das Verfahren kann den Empfang mehrerer Bedingungen an einer Benutzerschnittstelle umfassen. Das Verfahren kann ferner einen Empfang mehrerer Parameter für den genauen Zuschnitt einer Durchsuchung der kodierten elektronischen medizinischen Daten umfassen. Die Parameter können verwendet werden, um den Bedingungen eine Gewichtung zu verleihen. Das Verfahren kann eine Durchsuchung der kodierten elektronischen medizinischen Daten zur Erzeugung eines Kandidatenpools gemäß den gewichteten Bedingungen umfassen. Das Verfahren kann auch ein Anzeigen der in dem Pool enthaltenen Kandidaten in einer Reihenfolge von den optimalsten Ergebnissen zu den am wenigsten optimalen Ergebnissen beinhalten. Die Bedingungen können kodierten Bedingungen oder Ausdrücken der kodierten elektronischen medizinischen Daten entsprechen. Zu den Parametern kann eine Rangordnung der Bedingungen in einer Rangliste, eine Festlegung bestimmter Bedingungen als obligatorisch und eine Bestimmung einer Abweichung für numerische Bereiche gehören. Die Bedingungen und Parameter können auf der Grundlage eines zuvor bestimmten Studientyps festgelegt werden. Zu den Parametern kann eine Bestimmung einer Abweichung für geographische Bereiche gehören. Ein Benutzer kann eine Untergruppe der Poolkandidaten auswählen, um Kontaktinformationen oder medizinische Patientenakten zu erhalten.
  • Bestimmte Ausführungsformen der vorliegenden Erfindung können ein System zur Identifizierung eines Pools von potentiellen Kandidaten für eine Studie enthalten. Das System kann eine Benutzerschnittstelle umfassen, die eine Eingabe von Bedingungen und Parametern ermöglicht. Die Parameter können dazu verwendet werden, den Bedingungen eine Gewichtung zuzuordnen. Die Benutzerschnittstelle kann es auch unterstützen, einen oder mehrere aus dem Pool der potentiellen Kandidaten zur Teilnahme an der Studie einzuladen. Die Benutzerschnittstelle kann auch eine Eingabe für eine vorbestimmte Studienart umfassen. Das System kann auch eine Datenspeichervorrichtung zur Speicherung von kodierten elektronischen medizinischen Daten enthalten. Der Datenspeicher kann eine Datenbank von vorgegebenen Studientypen ent halten. Jeder vorgegebene Studientyp in der Datenbank kann mit einem Satz von Bedingungen und Parametern in Verbindung gebracht werden. Das System kann auch eine Computereinheit zur Ausführung von Computersoftware umfassen, die der Durchsuchung der kodierten elektronischen medizinischen Daten entsprechend den gewichteten Bedingungen und der Erzeugung einen Kandidatenpools dient. Das System kann auch eine Anzeige- bzw. Displayeinheit umfassen, die dazu dient, den Kandidatenpool in einer Reihenfolge von den optimalsten Resultaten zu den am wenigsten optimalen Resultaten anzuzeigen.
  • Bestimmte Ausführungsformen der vorliegenden Erfindung können ein computerlesbares Medium mit einem Satz von Anweisungen oder Befehlen zur Ausführung auf einem Computer enthalten. Die Befehle können eine Eingaberoutine zum Empfang mehrerer Bedingungen umfassen. Die Befehle können ferner eine Rankingroutine zum Ordnen einer Vielzahl von Bedingungen in Form einer Rangliste umfassen. Die Befehle können ferner eine Identifizierungsroutine umfassen, die der Bestimmung dient, ob eine bestimmte Bedingung obligatorisch ist. Die Befehle können auch eine Zuordnungsroutine umfassen, die dazu dient, numerischen Bereichen optional eine Abweichung zuzuordnen. Die Befehle können auch eine Suchroutine umfassen, um kodierte elektronische medizinische Daten zu durchsuchen, um einen Kandidatenpool gemäß den Bedingungen, dem Rang der Bedingungen, der Bestimmung als obligatorisch und, wenn vorhanden, einer Abweichung für numerische Bereiche zu erzeugen. Die Befehle können auch eine Anzeigeroutine zum Anzeigen des Kandidatenpools in der Reihenfolge von den optimalsten Ergebnissen zu den am wenigsten optimalen Ergebnissen anzuzeigen. Die Befehle können auch eine Auswahlroutine zum Auswählen einer Untergrup pe aus dem Kandidatenpool umfassen, um weitere Informationen zu dieser Untergruppe zu erhalten.
  • KURZBESCHREIBUNG VERSCHIEDENER ANSICHTEN DER ZEICHNUNGEN
  • 1 zeigt ein beispielhaftes System zur Sicherung der Patientenidentität gemäß einer Ausführungsform der vorliegenden Erfindung.
  • 2 zeigt ein Blockdiagramm einer beispielhaften Datenlagerarchitektur gemäß einer Ausführungsform der vorliegenden Erfindung.
  • 3 veranschaulicht einen beispielhaften Prozess zur Deidentifizierung von Patientendaten zum Zwecke der Speicherung in einer Datenlagervorrichtung, der gemäß einer Ausführungsform der vorliegenden Erfindung angewendet wird.
  • 4 zeigt ein Blockdiagramm eines beispielhaften Prozesses zur Reidentifizierung eines Patienten aus deidentifizierten Patientendaten gemäß einer Ausführungsform der vorliegenden Erfindung.
  • 5 veranschaulicht ein System zur Deidentifikation und Reidentifikation von Patientendaten gemäß einer Ausführungsform der vorliegenden Erfindung.
  • 6 veranschaulicht ein Flussdiagramm für ein Verfahren zur Generierung eines Kadidatenpools aus elektronischen medizinischen Akten gemäß einer Ausführungsform der vorliegenden Erfindung.
  • 7 veranschaulicht ein Durchsuchungssystem 700 für elektronische medizinische Akten, das gemäß einer Ausführungsform der vorliegenden Erfindung verwendet wird.
  • 8 veranschaulicht ein Beispiel von vier Bedingungen, die ein Benutzer eingeben kann, um einen Kandidatenpool zu erzeugen.
  • 9 veranschaulicht eine Ausführungsform der Erfindung, bei der es die Benutzerschnittstelle dem Endnutzer ermöglicht, den für die Erzeugung des Pools verwendeten Bedingungen eine Gewichtung zuzuordnen.
  • 10 veranschaulicht einen Benutzerschnittstellenbildschirm, wobei die Benutzerschnittstelle die Erlebnisse des Pools anzeigt, der gemäß den in dem Beispiel nach 9 dargestellten Parametern erzeugt wurde.
  • 11 veranschaulicht ein Flussdiagramm für ein Verfahren zur Generierung eines Pools von potentiellen Teilnehmern für eine klinische Studie gemäß einer Ausführungsform der vorliegenden Erfindung.
  • 12 veranschaulicht ein Flussdiagramm für ein Verfahren zur Generierung eines Pools von potentiellen Teilnehmern einer klinischen Studie gemäß einer Ausführungsform der vorliegenden Erfindung.
  • Die vorstehende Kurzbeschreibung und die nachfolgende detaillierte Beschreibung bestimmter Ausführungsformen der vorliegenden Erfindung können besser nachvollzogen werden, wenn sie im Zusammenhang mit den angehängten Zeichnungen gelesen werden. Zum Zwecke der Veranschaulichung der Erfindung sind bestimmte Ausführungsformen in den Zeichnungen gezeigt. Es soll jedoch verständlich sein, dass die vorliegende Erfindung nicht auf die in den beigefügten Zeichnungen veranschaulichten Anordnungen und Mittel beschränkt ist.
  • DETAILLIERTE BESCHREIBUNG DER ERFINDUNG
  • Bestimmte Ausführungsformen ergeben elektronische medizinische Aufzeichnungsdaten, die unter anderem zur Identifizierung von Teilnehmern für eine oder mehrere klinische Studien durchsucht werden können. In dem hier verwendeten Sinne kann eine „klinische Studie" eine oder mehrere klinische Forschungs- oder Untersuchungsstudien an menschlichen Patienten (in einer beliebigen Phase), Registerstudien, Studien zur Überwachung bestimmter Populationen (ältere Menschen, Kinder oder andere) und/oder sonstige auf einer klinischen Grundlage beruhenden Studien umfassen. In vielen klinischen Studien ist der Schutz der Patientenidentität gemäß der HIPAA-Definition ein wichtiges Anliegen. Das heißt, dass Informationen über den Patienten zur Nutzung in klinischen Studien und anderen Anwendungen in einer Form zugänglich gemacht werden sollte, bei der die genaue Identität eines Patienten denjenigen verborgen bleibt, die nicht durch die HIPAA autorisiert sind.
  • Bestimmte Ausführungsformen ergeben einen sicheren Prozess zur Versendung deidentifizierter Patienteninforma tionen von einem Ort eines ambulanten Patientenbehandlungsversorgers (PBV) zu einem Datenlagersystem, in dem die Patientendaten analysiert und mit einer größeren Auswahl von Patientendaten verglichen werden können. Die Ausdrücke „deidentifizierte Patienteninformationen" und „deidentifizierte Patientendaten", wie sie in dieser Druckschrift verwendet werden, beziehen sich sowohl auf vollständig deidentifizierte Daten, wie von der HIPAA definiert, als auch auf Daten aus begrenzten Datensätzen, wie durch die HIPAA definiert. Ein begrenzter Datensatz besteht aus geschützten Gesundheitsinformationen für die Forschung, das Gesundheitswesen und die medizinische Versorgung, bei denen direkte Identifizierungen (z.B. Name; Postadresse abgesehen von der Stadt, Staat bzw. Land und Postleitzahl; Sozialversicherungsnummer; Nummer der Patientenakte) entfernt sind, in denen aber andere Identifizierungsinformationen verbleiben können (z.B. Untersuchungsdaten; Dokumentation; Diagnose; Verschreibung; Labortestergebnisse). Diese werden von vollständig deidentifizierten Daten gemäß der Definition der HIPAA unterschieden, bei denen alle Daten, die einen Rückschluss auf einen individuellen Patienten ermöglichen, aus der Akte entfernt werden. Aus einer Datenlagervorrichtung erhaltene Informationen, die bestimmte individuelle Patienten betreffen, werden in Form eines Patientengruppenberichts an den ursprünglichen PBV-Standort zurück übertragen. Gruppenberichte werden durch Anfragen generiert, die an das Datenlagersystem gerichtet werden, um die Patientengruppen zu identifizieren. Die individuellen Patienten, die in einem Gruppenbericht aufgenommen sind, werden dann an dem PBV-Standort reidentifiziert, so dass die PBVs bei der Bestimmung von Behandlungsoptionen für die einzelnen Patienten die Informationen berücksichtigen können.
  • Alternativ und/oder zusätzlich kann ein Gruppenreport verwendet werden, um eine Liste von Patienten und/oder für eine bestimmte klinische Studie qualifizierten praktizierenden Ärzten aus dem Gesundheitswesen zurückzusenden. Zum Beispiel wird eine Suchanfrage, die ein Protokoll einer klinischen Studie repräsentiert, zusammengefasst und zu einem PBV oder einem anderen Standort geschickt, wie z.B. einen Spezialisten oder einen Hilfs-Gesundheitspflegeversorger, so dass sie durch eine Host-EMA-Anwendung verarbeitet werden kann. Es wird ein Bericht generiert, der eine Gruppe von Patienten umfasst und darauf hinweisen kann, dass ein oder mehrere „Patiententreffer" vorhanden sind. In bestimmten Ausführungsformen kann eine Gruppenliste geroutet werden, indem eine Vielzahl von Technologien verwendet wird, und sie kann an eine Auswahl von interessierten Parteien versendet werden (z.B. ein Pharmezeutikunternehmen, eine Vertragsforschungsorganisation, andere Dritte etc.).
  • 1 zeigt ein beispielhaftes System zur Sicherung der Patientenidentität. PBV-Systeme 108, die sich an verschiedenen PBV-Standorten befinden, sind mit einem Netzwerk 106 verbunden. Die PBV-Systeme 108 senden medizinische Patientendaten an eine Datenlagervorrichtung, die sich in einem Datenlagersystem 104 befindet. Die PBV-Systeme 108 umfassen typischerweise eine Anwendungssoftware, um eine Datenrückgewinnung oder -extraktion durchzuführen, zusammen mit einer oder mehreren Speichervorrichtungen zur Speicherung von elektronischen medizinischen Aufzeichnungsdaten (EMAs), die zu Patienten gehören, die an dem PBv-Ort behandelt werden. Zusätzlich können die PBV-Systeme 108 PBV-Benutzersysteme 110 umfassen, um auf die EMA-Daten zugreifen zu können, so dass die Datenrückgewinnung initiiert und eine Passwortzeichenkette eingegeben werden kann, die zur Verschlüsselung eines Patientenidentifikationszeichens verwendet wird. Die PBV-Benutzersysteme 110 können direkt mit dem PBV-System 108 verbunden sein, oder sie können über das Netzwerk 106 auf das PBV-System 108 zugreifen. Jedes PBV-Benutzersystem 110 kann unter Verwendung eines Universalcomputers implementiert sein, der ein Computerprogramm zur Ausführung der hier beschriebenen Prozesse ausführt. Das PBV-Benutzersystem 110 kann in Form von Personalcomputern oder an einen Host angeschlossenen Terminal ausgebildet sein. Wenn die PBV-Benutzersysteme 110 PCs sind, kann die hier beschriebene Verarbeitung auf ein PBV-Benutzersystem 110 und ein PBV-System 108 aufgeteilt werden, indem dem PBV-Benutzersystem 110 ein kleines Applikationsprogramm (Applet) bereitgestellt wird. Die Speichervorrichtung, die in dem PBV-System 108 angeordnet ist, kann unter Verwendung verschiedener Vorrichtungen zur Speicherung elektronischer Daten, wie z.B. eines File-Transfer-Protocol-Servers (FTP-Servers) implementiert sein. Es ist verständlich, dass die Speichervorrichtung implementiert sein kann, indem ein Speicher verwendet wird, der in dem PBV-System 108 enthalten ist, oder sie kann eine separate physische Vorrichtung sein. Die Speichervorrichtung umfasst eine Vielzahl von Informationen, zu denen auch eine EMA-Datenbank gehört.
  • Zusätzlich umfasst das System von 1 ein oder mehrere Datenlager-Benutzersysteme 102, durch welche ein Endbenutzer eine Anfrage an ein Anwendungsprogramm in dem Datenlagersystem 104 richten kann, um auf bestimmte in der Datenlagervorrichtung gespeicherte Aufzeichnungen zugreifen zu können (z.B. um einen Gruppenreport zu erstellen). In einer beispielhaften Ausführungsform der vorliegenden Erfindung können zu den Endanwendern Mitglieder des PBV-Personals, Mitglieder des Forschungsteams eines Pharmaun ternehmens sowie das Personal von Unternehmen gehören, welche medizinische und/oder andere Produkte herstellen. Die Datenlager-Benutzersysteme 102 können direkt mit dem Datenlagersystem 104 verbunden sein oder über das Netzwerk 106 an das Datenlagersystem 104 angebunden sein. Jedes Datenlager-Benutzersystem 102 kann unter Verwendung eines Universalcomputers implementiert sein, der ein Computerprogramm zur Ausführung der hier beschriebenen Prozesse durchführt. Die Datenlager-Benutzersysteme 102 können PCs oder mit einem Host verbundene Terminals sein. Wenn die Datenlager-Benutzer-systeme 102 PCs sind, kann die hier beschriebene Verarbeitung von einem Datenlager-Benutzersystem 102 und einem Datenlagersystem 104 geteilt werden, indem das PBV-Benutzersystem 102 mit einem Applet versorgt wird.
  • Das Netzwerk 106 kann eine beliebige Art eines bekannten Netzwerks sein, wozu auch ein lokales Netzwerk (LAN), ein Weitbereichsnetzwerk (WAN), ein Intranet oder ein globales Netzwerk (z.B. Internet) gehört. Ein Datenlager-Benutzersystem 102 kann durch mehrere Netzwerke (z.B. Intranet und Internet) an das Datenlagersystem 104 gekoppelt sein, so dass nicht alle Datenlager-Benutzersysteme 102 über dasselbe Netzwerk an das Datenlagersystem 104 angekoppelt sein müssen. In ähnlicher Weise kann ein PBV-System 108 durch mehrere Netzwerke (z.B. Intranet oder Internet) an ein Datenauswertungs-Hostsystem 104 gekoppelt sein, so dass nicht alle PBV-Systeme 108 über dasselbe Netzwerk mit dem Datenlagersystem 104 verbunden sein müssen. Von den Datenlager-Benutzersystemen 102, den PBV-Systemen 108 und dem Datenlagersystem 104 können eines oder mehrere auf drahtlose Weise mit dem Netzwerk 106 verbunden sein, und das Netzwerk 106 kann ein drahtloses Netzwerk sein. In einer beispielhaften Ausführungsform stellt das Internet das Netz werk 106 dar, und jedes Datenlager-Benutzersystem 102 führt eine Benutzerschnittstellenanwendung aus, um direkt mit dem Datenlagersystem 104 verbunden zu werden. In einer anderen Ausführungsform kann ein Datenlager-Benutzersystem 102 einen Webbrowser ausführen, um über das Netzwerk 106 mit dem Datenlagersystem 104 verbunden zu werden. Alternativ kann ein Datenlager-Benutzersystem 102 unter Verwendung einer Vorrichtung, die primär für den Zugriff auf das Netzwerk 106 programmiert ist, wie z.B. WebTV, implementiert sein.
  • Das Datenlagersystem 104 kann unter Verwendung eines Servers implementiert sein, der in Abhängigkeit von einem Computerprogramm arbeitet, das auf einem Speichermedium gespeichert ist, auf das der Server zugreifen kann. Das Datenlagersystem 104 kann in Form eines Netzwerkservers (oft als Webserver bezeichnet) betrieben werden, um mit den Datenlager-Benutzersystemen 102 und den PBV-Systemen 108 zu kommunizieren. Das Datenlagersystem 104 leitet das Senden und Empfangen von Informationen zu und von den Datenlager-Benutzersystemen 102 und den PBV-Systemen 108 und kann dazugehörige Aufgaben (Tasks) durchführen. Das Datenlagersystem 104 kann auch eine Firewall 104 umfassen, um einen unautorisierten Zugriff auf das Datenlagersystem 104 zu verhindern und beliebige Einschränkungen für den autorisierten Zugriff durchzusetzen. Zum Beispiel kann ein Administrator Zugriff auf das ganze System und die Autorität haben, um Teile des Systems zu modifizieren, wogegen ein Mitglied des PBV-Personals nur auf eine Untergruppe der Datenlagerakten bzw. -aufzeichnungen für bestimmte Patienten Zugriff haben kann. In einer beispielhaften Ausführungsform hat der Administrator die Möglichkeit, neue Benutzer hinzuzufügen, Benutzer zu löschen und Benutzerrechte zu modifizieren. Die Firewall kann unter Verwendung von konventioneller Hardware und/oder Software, wie auf diesem Fachgebiet bekannt, implementiert werden. In bestimmten Ausführungsformen ist das Datenlagersystem 104 in Form mehrerer zugehöriger und/oder miteinander verbundener Datenbanken oder Datenlager implementiert.
  • Das Datenlagersystem 104 arbeitet auch als Anwendungsserver. Das Datenlagersystem 104 führt ein oder mehrere Anwenderprogramme, um einen Zugriff auf ein Datenrepositorium zu ermöglichen, das in dem Datenlagersystem angeordnet ist, sowie Anwendungsprogramme zum Importieren von Patientendaten in einen Bereitstellungsbereich und dann in das Datenlager aus. Zusätzlich kann das Datenlagersystem 104 auch ein oder mehrere Anwendungen ausführen, um Patientengruppenberichte zu erzeugen und die Patientengruppenberichte an die PBV-Systeme 108 zu schicken. Die Verarbeitung kann von dem Datenlager-Benutzersystem 102 und dem Datenlagersystem 104 gemeinsam durchgeführt werden, indem das Datenlager-Benutzersystem 102 mit einer Anwendung (z.B. einem Java-Applet) ausgestattet wird. Alternativ kann das Datenlager-Benutzersystem 102 eine eigenständige Softwareanwendung zum Ausführen eines Teils der hier beschriebenen Verarbeitung umfassen. Ebenso kann die Verarbeitung auf das PBV-System 102 und das Datenlagersystem 104 aufgeteilt werden, indem das PBV-System 102 mit einer Anwendung versehen wird, und alternativ kann das PBV-System 102 eine eigenständige Anwendung zur Durchführung eines Teils der hier beschriebenen Verarbeitungen umfassen. Es versteht sich, dass separate Server verwendet werden können, um die Netzwerkserverfunktionen und die Anwendungsserverfunktionen zu implementieren. Alternativ können der Netzwerkserver, die Firewall und der Anwendungsserver mit einem einzigen Server implemen tiert werden, der Computerprogramme zur Durchführung der erforderlichen Funktionen ausführt.
  • Die Speichervorrichtung, die in dem Datenlagersystem 104 angeordnet ist, kann unter Verwendung verschiedener Vorrichtungen zur Speicherung von elektronischen Informationen, wie z.B. einem File-Transfer-Protocol(FTP)-Server, implementiert sein. Es sei darauf hingewiesen, dass die Speichervorrichtung unter Verwendung eines in dem Datenlagersystem 104 befindlichen Datenspeichers implementiert sein kann, oder sie kann eine separate physische Vorrichtung darstellen. Die Speichervorrichtung enthält vielfältige Informationen, zu denen ein Datenlager gehört, welches medizinische Patientendaten von einem oder mehreren PBVs enthält. Das Datenlagersystem 104 kann auch in Form eines Datenbankservers betrieben werden und den Zugang zu den Anwendungsdaten koordinieren, zu denen auch die in der Speichervorrichtung gespeicherten Daten gehören. Das Datenlager kann physisch als eine einzelne Datenbank gespeichert werden, bei der der Zugang auf der Grundlage von Benutzercharakteristika eingeschränkt ist, oder es kann in physischer Form in verschiedenen Datenbanken gespeichert sein, wozu auch Teile in dem Datenlager-Benutzersystem 102 oder dem Datenlagersystem 104 gehören. In einer beispielhaften Ausführungsform ist das Datenrepositorium unter Verwendung eines relationalen Datenbankensystems implementiert, wobei das Datenbankensystem verschiedenen Endbenutzern je nach Endbenutzercharakteristika verschiedene Ansichten der Daten liefert.
  • 2 zeigt ein Blockschaltbild einer beispielhaften Datenlagerarchitektur. Patientendaten werden aus EMA-Datenbanken wiedergewonnen, die sich in den PBV-Systemen 108 be finden. In einer beispielhaften Ausführungsform der vorliegenden Erfindung umfasst eine EMA-Datenbankakte Daten wie die folgenden: Name und Adresse des Patienten, Medikationen, Allergien, Beobachtungen, Diagnosen und Krankenversicherungsinformationen. Die PBV-Systeme 108 umfassen Anwendungssoftware zur Extraktion von Patientendaten aus der EMA-Datenbank. Die Daten werden dann in deidentifizierte Patienteninformationen umgewandelt und über das Netzwerk 106 zu dem Datenlagersystem 104 (z.B. über Hypertext Transfer Protocol (HTTP) oder Secure HTTP (HTTPS)) übertragen. In bestimmten Ausführungsformen kann das Datenlagersystem 104 z.B. in der Form mehrerer Datenlager und/oder Datenbanken implementiert sein. Das Datenlagersystem 104 umfasst Anwendungssoftware, die der Durchführung einer Datenimportfunktion 206 dient. Die Datenimportfunktion 206 sammelt und säubert deidentifizierte Patientendaten von vielen Orten und speichert die Daten anschließend in einem Bereitstellungsbereich 208. Die Daten, die von mehreren PBV-Systemen 108 empfangen werden, werden normiert, auf ihre Gültigkeit und Vollständigkeit hin überprüft und entweder korrigiert oder als fehlerhaft gekennzeichnet. Daten von mehreren PBV-Systemen 108 werden dann miteinander zu einer relationalen Datenbank zusammengefasst. Durch die Sammlung, Säuberung und Bereitstellung von Daten auf die beschriebene Art und Weise können die Daten in einer sinnvollen und effizienten Art abgefragt werden, entweder als eine Einheit oder spezifisch für jeden einzelnen PBV-Ort 108. Die deidentifizierten Patientendaten werden dann in einem Datenlager 210 bereitgestellt, wo sie zur Abfrage zur Verfügung stehen.
  • Patientengruppenberichte 212 werden durch eine Anwendungssoftware generiert, die in dem Datenlagersystem 104 angeordnet ist, und an die PBV-Systeme 108 zur Benutzung durch Gesundheits-Grundversorger für die Behandlung von individuellen Patienten zurückgeschickt. Die Patientengruppenberichte 212 können durch Ausführung einer vorgespeicherten Abfrage periodisch automatisch generiert werden. PBV-Personalmitglieder, Untersuchungsteammitglieder von Pharmaunternehmen und Personal von Unternehmen, die medizinische und/oder andere Produkte herstellen, können jeweils Patientengruppenberichte 212 ablaufen lassen. Außerdem können Patientengruppenberichte 212 durch einen Endbenutzer erzeugt werden, der auf das Datenlager-Benutzersystem 102 zugreift, um spezifische Berichte zu erzeugen oder um den Ablauf von vorgespeicherten Berichten zu initiieren. Ferner können Patientengruppenberichte 212 in Reaktion auf die Anwendungssoftware automatisch generiert werden, die sich in dem Datenlagersystem 104 befindet, indem festgelegt wird, dass bestimmte Datenkombinationen für einen Patienten in dem Datenlager gespeichert werden. Ein beispielhafter Patientengruppenbericht 212 umfasst sämtliche Patienten mit einer bestimmten Krankheit, die mit einem bestimmten Medikament behandelt wurden. Ein weiterer beispielhafter Patientengruppenbericht 212 schleißt Patienten eines bestimmten Alters und Geschlechts ein, bei denen sich bestimmte Testresultate ergeben haben. Zum Beispiel kann ein Patientengruppenbericht 212 alle Frauen mit einer Herzerkrankung auflisten, die ein Hormonersatztherapiemedikament einnehmen. Der Patientengruppenbericht 212 würde alle Patienten auflisten, für die Akten in dem Datenlager 210 enthalten sind und auf die diese Kriterien zutreffen, zusammen mit einer Warnung über die möglichen Nebenwirkungen und die Wahrscheinlichkeit für das Auftreten dieser Nebenwirkungen. In einer beispielhaften Ausführungsform empfängt jeder PBV-Ort den gesamten Bericht, während in einer anderen Ausfüh rungsform jeder PBV-Ort den Bericht nur für Patienten, die an dem PBV-Standort behandelt werden.
  • In einer beispielhaften Ausführungsform der vorliegenden Erfindung wird die Möglichkeit zur Erzeugung von Patientengruppenberichten 212 auf der Grundlage der Abfrage von longitudinalen Patientendaten durch die Möglichkeit unterstützt, alle Akten bzw. Aufzeichnungen miteinander zu verbinden, die sich auf einen einzelnen Patienten in dem Datenlager 210 beziehen. Dazu ist es erforderlich, dass ein eindeutiges Identifikationszeichen jeder Patientenakte zugeordnet wird, die an das Datenlager 210 übertragen wird. Das eindeutige Identifikationsmittel kennzeichnet einen anonymen oder abstrakten Patienten, der bestimmte Eigenschaften aufweist, liefert jedoch keine Informationen zur direkten Identifizierung, wie Namen, Sozialversicherungsnummer, Straßenadresse etc. Allerdings können einzelne PBVs die Möglichkeit zur Reidentifizierung eines Patienten auf der Grundlage des eindeutigen Identifikationsmittels zurückbehalten wollen, so dass das medizinische Personal an dem PBV-Standort den Patienten in Abhängigkeit von der in dem Patientengruppenbericht 212 enthaltenen Informationen weiterhin behandeln kann. 3 zeigt einen beispielhaften Prozess zur Deidentifizierung von Patientendaten zur Speicherung in dem Datenlager 210 an, das sich in dem Datenlagersystem 104 befindet, und 4 zeigt einen beispielhaften Prozess zur Reidentifizierung eines Patienten anhand der deidentifizierten Patientendaten an, die in einer Patientengruppe 212 enthalten sind.
  • 3 zeigt ein Blockschaltbild eines beispielhaften Prozesses zur Deidentifizierung von Patientendaten während der Datenwiedergewinnung zur Übertragung an ein Datenlager system 104. Bei dem Deidentifizierungsprozess werden Informationen entfernt, anhand derer ein Patient identifiziert werden kann, während klinisch nützliche Informationen über den Patienten noch immer beibehalten werden. Patientendaten werden aus der EMA-Datenbank 302 extrahiert, und identifizierende Informationen werden entfernt, wodurch deidentifizierte Patientendaten entstehen. In einer beispielhaften Implementierung der vorliegenden Erfindung umfasst eine EMA-Datenbank 302 die folgenden demographischen Daten, die einen Patienten identifizieren: Namen, geographische Identifikationsmerkmale einschließlich einer Adresse, Daten, die sich direkt auf ein Individuum beziehen einschließlich Geburtsdatum, Einweisungsdatum, Entlassungsdatum und Todesdatum; Telefon- und Faxnummern, Email-Adresse, Sozialversicherungsnummer; Nummer der Patientenakte; Begünstigter der Krankenkassenleistung; Kontonummern; Attest- oder Lizenznummern, Fahrzeugidentifizierungen und Seriennummern, einschließlich Fahrzeugkennzeichen, Vorrichtungskennungen und Seriennummern; Web Universal Ressource Locators (URLs) und Internetprotokoll(IP)-Adressennummern; biometrische Kennzeichen, einschließlich Fingerabdrücken und Stimmemuster; Photographien des ganzen Gesichts und vergleichbare Bilder; andere einzigartige Identifizierungsnummern, charakteristische Eigenschaften und Codes, die von dem PBV oder von dem EMA-System zu administrativen Zwecken zugeteilt wurden, wozu auch eine Patientenidentifikation (PID) 304 gehört. Die EMA-Datenbank 302 enthält auch Informationen zu: der Diagnose oder dem Problem bei einem Patienten; eingenommenen oder verschriebenen Medikamenten; Beobachtungen, diagnostischen Labortests und vitalen Zeichen; subjektiven und objektiven Befunden, Beurteilungen, Anordnungen, Plänen und Anmerkungen, die von den Versorgern aus dem Gesundheitswesen gemacht wurden. Die EMA-Datenbank 302 umfasst auch Kon troll-Informationen, die das Datum, die Zeit und Identität von Personen aufzeichnen, die die Informationen in der Patientenakte erzeugt, gelesen, aktualisiert oder gelöscht haben. Die Aufzeichnung in der EMA-Datenbank 302 für jeden Patienten umfasst auch einen numerischen Schlüssel, der als PID 304 bekannt ist und verwendet werden kann, um einen einzelnen Patienten eindeutig zu identifizieren. Die PID 304 wird als Teil des Deidentifikationsprozesses kodiert, um eine kodierte Patientenidentifikation (EPID, Encoded Patient Identifier) 308 zu erhalten. Die EPID 308 wird zusammen mit den deidentifizierten Patientendaten an das Datenlagersystem 104 gesandt.
  • Der Extraktions- oder Wiedergewinnungsprozess wird mittels einer Anwendungssoftware durchgeführt, die in dem PBV-System 108 angeordnet ist, und kann im Hintergrund auf einer periodischen Basis durchgeführt werden (z.B. jede Nacht um 2 Uhr, jeden Samstag um 2 Uhr). Auf diese Weise ist es unwahrscheinlicher, dass der Extraktionsprozess die sich auf dem PBV-System 108 befindliche Software beeinträchtigt. Der Extraktionsprozess kann auch durch ein Fernsystem (z.B. das Datenlagersystem 104) ausgelöst werden und kann vollständige oder inkrementelle Sicherungskopieschemata enthalten. In einer beispielhaften Ausführungsform der vorliegenden Erfindung werden die folgenden Identifizierungen entfernt oder umgewandelt, um deidentifizierte Daten zu schaffen, die unter der HIPAA-Definition als vollständig deidentifizierte Daten klassifiziert werden würden: Name, geographische Unterteilungen, die kleiner sind als ein Staat bzw. Land mitsamt einer Straßenadresse, Stadt, Landkreis, Bezirk, Postleitzahl (bis auf die drei letzten Ziffern), Daten, die sich direkt auf ein Individuum beziehen (z.B. Geburtsdatum), Telefon- und Faxnummern, Email-Adres se, Krankenkassenleistungsnummer, Kontonummer, Attest- oder Lizenznummer, Vorrichtungskennung und Seriennummern, Unified Resource Locators (URLs), Internetprotokoll-(IP)-Adressennummern; biometrische Identifizierungen; Photographien des ganzen Gesichts und andere eindeutige Identifizierungsnummern, Charakteristika und Codes.
  • In bestimmten Ausführungsformen kann der Extraktionsprozess von der Ferne ausgelöst werden. In bestimmten Ausführungsformen kann der Extraktionsprozess als Software„Roboter" oder eine andere gepackte Anwendung implementiert sein, die an einen Endnutzer gesandt und z.B. auf einem individuellen Client- oder Firmenserver angewendet werden kann.
  • In einer alternativen beispielhaften Ausführungsform der vorliegenden Erfindung werden die folgenden Identifizierungen entfernt oder umgewandelt, um deidentifizierte Daten zu erzeugen, die unter der HIPAA-Definition als beschränkte Datensatzinformationen klassifiziert werden würden: direkte Identifizierungen wie Name, Postadresse (außer Stadt, Staat/Land und Postleitzahl), Sozialversicherungsnummer und Nummern der Patientenakte. In der Implementierung der vorliegenden Erfindung mit begrenzter Datensatzinformation können einige Identifizierungsinformationen, wie Tage der Untersuchung, Dokumentation, Diagnose, Verschreibung und Labortestergebnisse, verbleiben.
  • Eine neuartige EPID 308 wird jedem Patienten auf der Grundlage der PID 304, die dem Patienten zugeordnet ist, und eines von dem PBV eingegebenen Passwort zugeordnet. Die Abbildung einer PID 304 auf eine EPID 308 wird nicht durchgehend aufrechterhalten. Wie in der in 3 dargestellten beispielhaften Ausführungsform gezeigt, wird von dem PBV über eine Passwortverschlüsselungs-Benutzerschnittstelle 310 auf dem PBV-Benutzersystem 110 ein Passwortstring bzw. eine Passwortzeichenkette 312 geliefert. Dieser Passwortstring 312 ist nur dem PBV bekannt und ist erforderlich, um die EPID 308 in eine PID 304 zu dekodieren. Der Benutzer an dem PBV-Ort muss den Passwortstring 312 haben, um die PID 304 zu erhalten, und dieser Passwortstring 312 muss jedes Mal neu eingegeben werden, wenn ein Patient deidentifiziert werden soll. Die Passwortverschlüsselungs-Benutzerschnittstelle 310 kann eine graphische Benutzerschnittstelle sein. In einer beispielhaften Ausführungsform der vorliegenden Erfindung wird die vom Benutzer eingegeben Passwortzeichenkette 312 unter Verwendung eines Twofish-Algorithmus kodiert. Der Twofish-Algorithmus, wie er in der Technik bekannt ist, ist ein Secret-Key-Block-Cipher-Kryptographie-Algorithmus, der so entworfen ist, dass er sehr sicher und sehr flexibel ist. Dabei wird ein einziger Schlüssel sowohl für die Verschlüsselung als auch die Entschlüsselung verwendet, was häufig auch als symmetrische Verschlüsselung bezeichnet wird. Die Kodierung wird durch eine Patientenidentizierungs-Kodiersoftware 306 durchgeführt, die in dem PBV-System 108 angeordnet ist. befindet. Die Patientenidentifizierungs-Kodiersoftware 306 wendet außerdem eine Hash-Funktion (Streuwertfunktion) auf den kodierten Passwortstring auf, um eine sechzehnstellige Zahl zu erzeugen. Diese sechzehnstellige Zahl wird numerisch zu der PID 304 addiert, um die EPID 308 zu erzeugen. Es können andere Verfahren im Zusammenhang mit einer beispielhaften Ausführungsform der vorliegenden Erfindung verwendet werden, um aus der PID 304 die EPID 308 zu bilden (z.B. Rivest, Shamir und Adelman, RSA, Algorithmus basierend auf dem Patienten namen, dem Alter und der Sozialversicherungsnummer etc.), solange die EPID nur an dem PBV-Ort dekodiert werden kann.
  • 4 zeigt ein Blockschaltbild eines beispielhaften Prozesses zur Reidentifizierueg eines Patienten aus den deidentifizierten Patientendaten. Wie zuvor beschrieben, werden Bevölkerungsgruppenberichte von Risikopatienten erzeugt, indem Anfragen an das Datenlager 210 gerichtet werden. Deidentifizierte Individuen können in Längsrichtung aufgespürt werden und als Mitglieder von anonymen Bevölkerungsgruppierungen auf der Grundlage von klinischen Auswahlkriterien abgefragt werden. Das in dem Gruppenbericht 212 enthaltene Abfrageergebnis stellt eine Liste von EPIDs 308 dar. Die Liste von Patienten-EPIDs 308 in einem Patientengruppenbericht 212 wird vom PBV-System 108 empfangen. Die EPIDs 308 werden in die Patientenidentifizierungs-Dekodierungssoftware 402 eingelesen, die sich auf dem PBv-System befindet, und die originale PID 304 wird wiederhergestellt oder anderweitig wieder mit einer Patientenakte in dem PBV-System 108 verbunden. Die PID 304 kann als Schlüssel verwendet werden, um zusätzliche Identifizierungsinformationen von der EMA-Datenbank 302 einzusehen. Angestellte des PBv können die patientenspezifischen Informationen von der EMA-Datenbank 302 verwenden, um den Patienten zu beraten und eine Entscheidung über Behandlungsalternativen zu treffen.
  • Eine Ausführungsform der vorliegenden Erfindung ermöglicht ambulanten PBVs, Patientendaten an ein Datenlager zu senden, das Patientendaten von anderen ambulanten PBVs enthält. Auf diese Weise können Patientendaten analysiert und mit einer größeren Population von Patienten verglichen werden. Die deidentifizierten Patientendaten beinhalten eine EPID 308, die hilfreich bei der Erstellung von Längsberichten sein kann, in denen mehr als eine Aufzeichnung für einen bestimmten Patienten analysiert wird. Die Wirkungen von bestimmten Medikamenten und Behandlungen bei Patientengruppen 212 können analysiert werden und zu einer Verbesserung in der Verwendung oder der Zusammenstellung der Medikamente und Behandlungen führen. Zusätzlich erlaubt eine Ausführungsform der vorliegenden Erfindung dem PBV, Gruppenberichte 212 zu empfangen, die auf den in dem Datenlager enthaltenen Daten beruhen. Diese Patientengruppenberichte 212 beinhalten eine EPID 308 für jeden Patienten. Die EPID 308 kann am PBV-Standort, an dem die EPID 308 geschaffen wurde, dekodiert und dazu benutzt werden, einen bestimmten Patienten zu identifizieren. Auf diese Weise kann ein PBV in der Lage sein, unter Berücksichtigung der in dem Gruppenbericht enthaltenen Informationen dem Patienten eine verbesserte Behandlung zukommen zu lassen. Diese Fähigkeit, nützliche Informationen auf eine Patientenstufe zurück zu liefern, kann auch mehr PBVs dazu veranlassen, an der Einsendung von Patientendaten an ein Datenlager teilnehmen. Wenn mehr Daten in dem Datenlager enthalten sind, können vielleicht mehr nützliche Informationen über die Auswirkungen und Risiken bestimmter Behandlungen an Dritten, wie Pharmaunternehmen, Medizingeräteherstellern und Ärzten, bereitgestellt werden, während die Gefahr einer Offenbarung von einen Patienten identifizierenden Informationen an Dritte auf ein Minimum reduziert ist. Das kann zu Verbesserungen bei der Präventionsversorgung sowie anderen Arten der medizinischen Versorgung führen.
  • Wie vorstehend beschrieben, können die Ausführungsformen der vorliegenden Erfindung in Form von in einem Computer implementierten Prozessen sowie Geräten zur Ausführung dieser Prozesse ausgeführt werden. Ausführungsformen der Erfindung können auch in Form eines Computerprogrammcodes implementiert werden, der Anweisungen enthält, die in zugänglichen oder zugreifbaren Medien, wie einer Diskette, CD-ROMs, Festplatten oder einem beliebigen anderen computerlesbaren Speichermedium, enthalten sind, wobei der Computer zu einem Gerät zur Ausführung der Erfindung wird, wenn der Computerprogrammcode in den Computer geladen und von diesem ausgeführt wird. Eine Ausführungsform der vorliegenden Erfindung kann auch z.B. in Form eines Computerprogrammcodes ausgeführt sein, der in einem Speichermedium gespeichert, in einen Computer geladen und/oder von diesem ausgeführt wird oder über ein Übertragungsmedium, wie z.B. über eine elektrische Verdrahtung oder Verkabelung, durch Faseroptik oder über elektromagnetische Strahlung, übertragen wird, wobei der Computer zu einer Vorrichtung zur Ausführung der Erfindung wird, wenn der Computerprogrammcode den Computer geladen und von diesem ausgeführt wird. Wenn die Computerprogrammcodesegmente auf einem Universalmikroprozessor implementiert sind, konfigurieren sie den Mikroprozessor so, dass er spezifische logische Schaltungen bildet.
  • In bestimmten Ausführungsformen kann der Benutzer die entsprechende Patientenliste zur weiteren Analyse, Bearbeitung etc. als Anfrage an die EMA schicken, sobald die Patienteninformationen reidentifiziert wurden. Eine reidentifizierte Patientenakte kann modifiziert, verglichen und/oder anderweitig von dem autorisierten Benutzer bearbeitet und lokal und/oder in einer EMA-Datenbank oder einer anderen Speichervorrichtung gespeichert werden. Eine modifizierte Akte kann z.B. vor ihrer Speicherung deidentifiziert werden.
  • In bestimmten Ausführungsformen werden EMA-Updates „gezogen", „geschoben" oder in sonstiger Weise an eine Datenbank, ein Datenlager und/oder eine andere Datenspeichervorrichtung periodisch (z.B. jede Nacht, jede Woche etc.) übertragen. In bestimmten Ausführungsformen werden Veränderungen, die lokal an reidentifizierten Patientenakten vorgenommen wurden, deidentifiziert und zur Speicherung an das EMA-System und/oder die Datenbank übertragen.
  • In bestimmten Ausführungsformen kann ein Benutzer nach einer oder mehreren Patientenakten innerhalb der EMA suchen, indem er einen „Finden"-Dialog oder eine Suchfunktion aktiviert. Der Benutzer kann z.B. anhand der EPID suchen und eine EPID-Nummer eingeben oder auswählen, um eine Suche zu aktivieren. Die entsprechende Patientenaufstellung kann wiedererlangt und angezeigt werden. So kann ein Patient für einen autorisierten Gesundheitspflegeversorger, der identifiziert und verifiziert wurde, reidentifiziert werden.
  • Somit ermöglicht die Deidentifizierung und Reidentifizierung, dass kodierte und unkodierte Daten in physisch getrennten Systemen zusammenarbeiten. Während das verschlüsselte System in Übereinstimmung mit der HIPAA Informationen auf der Patientenstufe hosten/enthalten kann und Möglichkeiten zur sinnvollen Nutzung von verschlüsselten Daten bietet (z.B. zur Lieferung von Datenansichten für ein größeres Publikum, etc), besteht die Notwendigkeit, die Informationen von dem verschlüsselten System wirksam einzusetzen und sie für diejenigen Publikumsgruppen zu reidentifizieren, die physisch von dem verschlüsselten System getrennt sind, aber autorisiert sind, Informationen einzusehen, durch welche Patienten identifiziert werden können. Der Prozess der Reidentifizierung von Patienten ist ein Prozess, der z.B. auf dem lokalen System stattfindet.
  • In bestimmten Ausführungsformen erleichtert die Trennung von deidentifizierten und identifizierten Patientendaten eine breite Analyse von Patientenpopulationen, ohne dass dabei der Datenschutz bei dem individuellen Patienten verletzt wird. Analyse auf der Grundlage von Populationen kann sicher durchgeführt werden, wobei die Privatsphäre des Patienten unangetastet bleibt. Die Reidentifizierung kann auf der lokalen Systemstufe erfolgen, so dass der Gesundheitspflegeversorger eines Patienten diesem eine Diagnose stellen, ihn behandeln und/oder andere Leistungen erbringen kann.
  • So wird eine breitere Analyse von Patienteninformationen ermöglicht, während gleichzeitig die Privatsphäre des Patienten respektiert wird. Gemeinschaften von Gesundheitspflegeversorgern können Patientenpopulationen in Bezug setzen und vergleichen, ohne die Privatsphäre eines Patienten zu verletzen. Gleichzeitig kann der Versorger des Patienten diejenigen Patienten, die vom verschlüsselten Standort aus gehostet/präsentiert werden, auf einer lokalen Stufe aus den Patientenpopulationen reidentifizieren. Reidentifikationsalgorithmen können lokal z.B. auf der Stufe des Gesundheitsversorgers gespeichert werden. Durch diese physische Trennung kann das potentielle Risiko reduziert werden, dass andere Versorger, die die deidentifizierten Daten auf einem Portal einsehen, Informationen sehen, die den Patienten identifizieren können.
  • Bestimmte Ausführungsformen ermöglichen es, Patienteninformationen mit interessierten Parteien zu teilen, ohne dass dabei die Privatsphäre des Patienten verletzt wird. In dem weiter gefassten Gesundheitsversorgungsbereich wird es Anwendungen für Forscher, Regierungsbehörden, Praxisgemeinschaften geben, welche Patientenpopulationen studieren wollen, aber bisher eingeschränkt waren, weil kein guter Mechanismus vorhanden war, um beim Deidentifizieren und Reidentifizieren von Patienten mit Quellendatenlieferanten zusammenzuarbeiten. Bestimmte Ausführungsformen erleichtern solch ein Zusammenwirken. Zum Beispiel können entschlüsselte Informationen reidentifiziert und dann von einem Patientenversorgungssystem aufgenommen oder in das Patientenversorgungssystem im Rahmen von EMA-Anwendungen wie Excel, Centricity Physician Office und/oder anderen Anwendungen importiert werden. Andere Gruppen, wie Forscher und Behörden, können die verschlüsselten oder deidentifizierten Daten mit einem geringeren Risiko, die Privatsphäre des Patienten zu verletzen, einsehen und/oder bearbeiten.
  • In 5 ist ein System 500 zur Patientendatendeidentifikation und -reidentifikation gemäß einer Ausführungsform der vorliegenden Erfindung veranschaulicht. Das System 500 umfasst einen oder mehrere Benutzerarbeitsplätze (Workstations) 510, ein Webportal 520, einen Datenspeicher 530 und eine Datenverbindung 540. Das System 500 kann z.B. auch ein Display bzw. eine Anzeige 550 und/oder einen Datenserver 560 umfassen.
  • Die Komponenten des Systems 500 können allein oder z.B. in Kombination in Hardware, Firmware und/oder als Befehlssatz in Software implementiert werden. Bestimmte Ausführungsformen können als ein Satz von Befehlen geliefert werden, die sich auf einem computerlesbaren Medium, wie einem Datenspeicher, einer Festplatte, DVD oder CD, befinden und zur Ausführung auf einem Universalcomputer oder einer anderen Verarbeitungsvorrichtung bestimmt sind. Bestimmte Komponenten können in verschiedenen Formen integriert sein und/oder als Software und/oder eine andere Funktionalität auf einer Rechenvorrichtung, wie einem Computer, bereitgestellt werden. Bei bestimmten Ausführungsformen können eine oder mehrere Komponenten des Systems 500 ausgelassen werden, um die Reidentifikation und/oder Deidentifikationsfunktionen auszuführen und Daten zwischen einem lokalen Benutzer und einem Datenspeicher zu übermitteln.
  • Im Betrieb kann der Arbeitsplatz 510 Daten über das Webportal 520 anfordern. Zum Beispiel fordert ein Benutzerarbeitsplatz 510 mit dem Patienten im Zusammenhang stehende Daten über einen Webbrowser an, der auf das Webportal 520 zugreift. Das Webportal 520 steht über eine Datenverbindung bzw. einen Datenlink 540 im Datenaustausch mit dem Datenlager 530. Zum Beispiel fordert das Webportal 520 die Daten von dem Datenspeicher 530, wie z.B. von dem EMA-Datenzentrum, über ein Netzwerk wie das Internet oder ein privates Netzwerk, an. Der Datenspeicher 530 liefert die angeforderten Daten über das Webportal 520 an den Arbeitsplatz 510 zurück. Die Daten können z.B. Daten, die nicht gemäß HIPAA geschützt sind, deidentifizierte/verschlüsselte Patientendaten, reidentifizierte Patientendaten und/oder sonstige Daten umfassen.
  • Der Benutzerarbeitsplatz 510 kann mit dem Display 550 im Austausch stehen, so dass von dem Datenspeicher 530 übertragene Daten angezeigt werden können. Daten können auch ausgedruckt und/oder verwendet werden, um z.B. eine Datei zu generieren. Die Workstation 510 kann auch mit dem Daten server 560 kommunizieren, um die Daten und/oder ein anderes Update zu übertragen.
  • In bestimmten Ausführungsformen wird ein deidentifizierter Patientenreport in Reaktion auf eine Anforderung von dem Arbeitsplatz 510 von dem Datenspeicher 530 über das Webportal 520 an den Arbeitsplatz 510 übertragen. Der Arbeitsplatz 510 führt die Reidentifizierung der deidentifizierten Patientendaten lokal an dem Arbeitsplatz 510 durch. Die Reidentifizierung kann über das Nachschlagen einer EPID zur Bestimmung einer zugehörigen PID oder eine andere ähnliche Technik durchgeführt werden. Die Reidentifikationsfunktionalität kann in einem Dokumentenanzeige-/Dokumentenbearbeitungsprogramm, wie z.B. Microsoft Excel, Microsoft Word und/oder einer sonstigen Software, integriert sein. Die Reidentifikationsfunktion kann auf Daten in einer externen Quelle, wie dem Datenspeicher 530 und/oder dem Datenserver 560, zugreifen, um die EPID einer PID zuzuordnen. In bestimmten Ausführungsformen wird die EPID durch die PID und/oder eine andere Patientenidentifizierungsinformation (z.B. den Patientennamen) in einem Dokument an dem Arbeitsplatz 510 ersetzt.
  • In bestimmten Ausführungsformen kann der Arbeitsplatz 510 zuerst z.B. ein Privileg oder ein Zugangsrecht über den Server 560 authentisieren, bevor die Patientendaten reidentifiziert werden. Der Arbeitsplatz 510 kann z.B. auch Patienten- und/oder Versorgerattribute über den Server 560 und/oder an Datenspeicher 530 überprüfen.
  • In bestimmten Ausführungsformen können Informationen in elektronischen medizinischen Berichten und/oder anderen Dokumenten verarbeitet werden, um die Informationen gemäß einem bestimmten Lexikon und/oder einer Grammatik zu normalisieren oder „scrubben" („schruppen"). Zum Beispiel kann eine medizinische Berichttabelle, wie eine medizinische Logician® – Datentabelle, ein oder mehrere Beobachtungswerte von einem untersuchenden Arzt oder einem anderen medizinischen Fachmann enthalten. Das Feld des Beobachtungswertes (z.B. „beo" oder „beowert") kann z.B. ein Feld mit einem freien Format sein. Somit können verschiedene Ärzte verschiedene Sprachen wählen, um sich auf denselben Zustand zu beziehen; Zum Beispiel kann ein Arzt auf einen Herzschlag Bezug nehmen, während ein anderer einen akuten myokardialen Infarkt bezeichnen kann. Begriffe können „geschruppt" oder lexikalisch bzw. grammatikalisch analysiert und mit einem numerischen Wert und/oder einem „Standardbegriff" für ein Lexikon/eine Grammatik in Verbindung gesetzt werden.
  • Zum Beispiel können die Informationen in einer elektronischen medizinischen Aufzeichnung bzw. Akte oder einem anderen Dokument vor der Speicherung in einem Datenlager oder einer anderen Datensammlung durch ein Datenverarbeitungssystem verarbeitet werden. Die Informationen können auf der Grundlage von einer oder mehreren Regeln z.B. an eine Tabelle oder eine andere Auflistung von akzeptierten Begriffen/Werten angepasst werden. Auf der Grundlage der Anpassung kann die Information durch einen akzeptablen Begriff und/oder Wert aus der Auflistung ersetzt werden. Bei dem obigen Beispiel würde, wenn der akzeptierte Begriff „akutes MI" ist, die Verwendung von „Herzschlag" durch einen Arzt in „akutes MI" umgewandelt oder normalisiert werden, und die Verwendung von „akuter myokardischer Infarkt" durch einer Arzt würde ebenfalls in „akuter MI" umgewandelt werden.
  • In bestimmten Ausführungsformen werden bestimmte identifizierte Patientendaten wiedergewonnen und zentral in einem großen Datenlager gespeichert. Während der Speicherung können die Daten gescrubbt und normalisiert werden, indem die Begriffe auf ein allgemeines Vokabular und/oder einen Satz von Regeln abgebildet werden. Wenn z.B. in einer Akte von MI die Rede ist und eine andere Akte sich auf einen myokardialen Infarkt bezieht, werden beide in einer Datenbank als myokardialer Infarkt kodiert. So kann eine Durchsuchung von Aufzeichnungen in einer Datenbank auf der Grundlage des gemeinsamen Vokabulars durchgeführt werden.
  • Ein Benutzer kann eine Suche durchführen, indem er einen oder mehrere Begriffe oder Kriterien für die Suche anwendet. Zum Beispiel kann ein Benutzer nach einem Pool von Patienten fragen, die über 55 Jahre alt sind, eine Vorgeschichte mit akutem myokardialen Infarkten innerhalb der letzten 2 Jahre haben, bestimme Enzymwert aufweisen und im Mittleren Westen leben. Die Begriffe und/oder Kriterien können z.B. schon in der Datenbank kodiert sein und/oder können beim Eingeben der Suchbegriffe durch den Benutzer kodiert/normalisiert werden. In bestimmten Ausführungsformen kann ein Benutzer einen oder mehrere kodierte Begriffe aus einem Menü oder einer sonstigen Auflistung auswählen und einen oder mehrere vorgegebene Algorithmen auswählen, um nach Patienten zu suchen, auf die der ausgewählte Begriff bzw. die ausgewählten Begriffe zutreffen. In bestimmten Ausführungsformen kann ein Benutzer z.B. einen oder mehrere zusätzliche Begriffe kodieren und/oder zusätzliche Regeln/Suchalgorithmen dynamisch aufstellen. In bestimmten Ausführungsformen passt ein Suchsystem die Suchanfrage eines Benutzers an, indem es die in der Suchanfrage benutzte Sprache gemäß eines Standardvokabulars oder eines Satzes von erlaubten Begriffen kodiert. Eine Suche mit mehreren Kriterien kann fortschreiten, indem die mehreren Kriterien aufeinander folgend angewendet werden um den Pool von Kandidaten einzugrenzen. Die Suchbegriffe können an elektronische medizinische Aufzeichnungen und/oder sonstige Eingaben in einem Datenlager und/oder eine andere Datenbank angepasst werden.
  • In bestimmten Ausführungsformen können elektronische medizinische Aufzeichnungsdaten zentralisiert und kodiert werden. In bestimmten Ausführungsformen können elektronische medizinische Aufzeichnungsdaten verteilt und/oder entkodiert werden. In bestimmten Ausführungsformen können elektronische medizinische Aufzeichnungsdaten in verschiedenen Systemen unterschiedlich kodiert sein. Zum Beispiel kann ein lokales Vokabular sich von einem zentralisierten Vokabular unterscheiden, und/oder verschiedene lokale EMA-Systeme können verschiedene lokale Vokabularien haben. In bestimmten Ausführungsformen kann eine Zuordnung zwischen mehreren Kodifizierungen vorhanden sein, so dass eine Umwandlung und Suchen innerhalb verschiedener Kodifizierungsschemata möglich ist.
  • Die von einem Benutzer verwendeten Begriffe oder Eingaben können gemäß einem diagnostischen Code, wie z.B. einem Code ICD-9 (International Classification of Diseases, neunte Version), dem ICD-10-Code oder CPT-Code (Current Procedure Terminology) kodiert werden. Alternativ und/oder zusätzlich können Begriffe gemäß einer eigenen Terminologie oder einem eigenen Kodierungsschema kodiert werden. Zum Beispiel kann ein Industriestandardbegriff wie „akuter Schmerz in der oberen rechten Extremität" als „akuter Schmerz im rechten Oberarm" klassifiziert werden. Bestimmte Begriffe können durch allgemein verwendete Begriffe und/oder Begriffe, die z.B. für eine spezifische Umgebung oder Anwendung angebracht sind, klassifiziert oder ersetzt werden. In bestimmten Ausführungsformen kann ein Benutzer einen Begriff auswählen, wobei eine Mastervokabulartabelle relevante Begriffe zur Benutzung bei der Suche liefert. In bestimmten Ausführungsformen können eine oder mehrere Kategorien z.B. auf der Grundlage eines klinischen Zustandes oder einer Krankheitskategorie durchsucht werden.
  • Wenn ein Benutzer zum Beispiel nach einem „CV" (kardiovaskulären) Thema bzw. Problem suchen möchte, kann er eine Anzahl von CV-Bedingungen aus einer CV-Liste auswählen. Zum Beispiel können bei einer Suchschnittstelle klinische Bedingungen aufgelistet sein, wie z.B. eine Person, die einen Herzinfarkt mit Komplikationen infolge Diabetes hatte, und die Schnittstelle kann diagnostische Codes aufweisen, die zur Auswahl für eine Suche gelistet sind. Ein Benutzer kann dann anhand entweder der klinischen Bedingungen und/oder der Codes suchen, indem er die Bedingungen/Codes von einer flachen oder abgestuften Liste oder einem Menü auswählt und/oder er die Bedingungen/Codes manuell eingibt, um die klinischen Bedingungen und/oder andere Kriterien auszuwählen, die verwendet werden sollen, um auf die Datenbank und die Suche angewendet zu werden.
  • Gemäß einem der obigen Beispiele wählt ein Benutzer die folgenden Kriterien für die Suche aus: Alter über 55 Jahren, akuter myokardialer Infarkt, innerhalb eines Zeitrahmens von 2 Jahren, ein bestimmter spezifischer Enzymwert oder -wertebereich und die geographische Lage im „Mittleren Westen". Eine Suche würde diejenigen Patienten in der Datenbank identifizieren, die über 55 Jahre alt sind. Die Su che würde diese Gruppe eingrenzen, indem diejenigen Patienten in der. Gruppe der über 55-jährigen identifiziert werden, die innerhalb der letzten zwei Jahre einen akuten myokardialen Infarkt hatten. Zusätzlich würde bei der Suche die Patientengruppe weiter eingeengt werden, indem die über 55 Jahre alten Patienten mit einem, akuten myokardialen Infarkt in den letzten zwei Jahren isoliert werden, die im Mittleren Westen wohnen. Das Resultat ist z.B. ein Pool von potentiellen Teilnehmern einer Studie, die die von einem Benutzer bereitgestellten Kriterien erfüllen. Die Studienteilnehmer können beispielsweise klinische Studienobjekte (z.B. Patienten) und/oder Forscher für eine klinische Studie (z.B. Ärzte und/oder sonstige Fachleute) umfassen.
  • 6 veranschaulicht hin Flussdiagramm für ein Verfahren 600 zur Generierung eines Teilnehmerpools aus elektronischen medizinischen Aufzeichnungen gemäß einer Ausführungsform der vorliegenden Erfindung. In Schritt 610 werden ein oder mehrere Suchkriterien eingegeben. Zum Beispiel kann ein Benutzer, wie bspw. ein Arzt oder ein Pharmaforscher, manuell einen oder mehrere Suchbegriffe bzw. -kriterien eingeben. Ein Benutzer kann z.B. gemäß einer oder mehreren vorgegebenen Vokabularien und/oder Codesätzen Kriterien manuell eingeben und/oder auswählen. Alternativ oder zusätzlich kann ein Benutzer Suchkriterien eingeben, die dann z.B. in Übereinstimmung mit einem Vokabular normalisiert oder kodiert werden. In bestimmten Ausführungsformen können Suchkriterien aus einem ein- oder mehrstufigen Menü und/oder einer anderen Auflistung anstatt und/oder zusätzlich zu der manuellen Eingabe durch den Benutzer ausgewählt werden.
  • In Schritt 620 wird eine Suchanfrage für eine elektronische medizinische Aufzeichnungsdatenbank oder einen anderen Datenspeicher kompiliert. Zum Beispiel werden mehrere Suchkriterien/Begriffe, die vom Benutzer eingegeben und/oder anderweitig ausgewählt wurden, in Form einer Anforderung oder Anfrage für die Speicherung von elektronischen medizinischen Aufzeichnungen organisiert. In bestimmten Ausführungsformen kann die Kompilierung oder Organisation einer Suchanfrage z.B. die Normalisierung oder Kodierung von Suchkriterien gemäß einem bestimmten Standardvokabular oder einem bewährten Vokabular oder einer Begriffsliste umfassen.
  • In Schritt 630 wird eine Suche ausgeführt, um jedes der Suchkriterien in den elektronischen medizinischen Aufzeichnungsdaten zu identifizieren. Zum Beispiel kann ein Pool von potentiellen Teilnehmern an einer Studie aus einer Datenbank, einem Datenlager und/oder einem sonstigen Datenspeicher für elektronische medizinische Aufzeichnungsdaten auf der Grundlage der Suchkriterien identifiziert werden. Jedes der Suchkriterien kann den Pool weiter eingrenzen, so dass man eine gewünschte Gruppe von Teilnehmern erhält.
  • In Schritt 640 werden die Suchergebnisse präsentiert. Suchergebnisse können, wie oben beschrieben, deidentifiziert und/oder reidentifiziert sein. Die Suchergebnisse können ein unterschiedliches Maß an Information enthalten. Die Suchergebnisse können z.B. weiter verfeinert und/oder mit einer Priorität belegt werden. In bestimmten Ausführungsformen können die Suchergebnisse zu einer anderen Anwendung geroutet und/oder, wie z.B. einer Benachrichtigungsanwendung, übertragen werden. Suchergebnisse können z.B. angezeigt, formatiert, ausgedruckt, elektronisch ver sendet, über ein Fax und/oder eine andere Übertragungs- oder Speichervorrichtung übertragen werden.
  • Ein oder mehrere der Schritte des Verfahrens 600 können eigenständig oder kombiniert z.B. in Hardware, Firmware und/oder als ein Satz von Instruktionen in Software implementiert werden. Bestimmte Ausführungsformen können in Form eines Satzes von Instruktionen bereitgestellt werden, die sich auf einem computerlesbaren Medium, wie bspw. einem Datenspeicher, einer Festplatte, einer DVD oder einer CD zur Ausführung auf einem Universalcomputer oder einer anderen Verarbeitungsvorrichtung befinden.
  • Bei bestimmten Ausführungsformen der vorliegenden Erfindung können ein oder mehrere dieser Schritte ausgelassen und/oder in einer anderen als der gelisteten Reihenfolge ausgeführt werden. Zum Beispiel können bei bestimmten Ausführungsformen der vorliegenden Erfindung einige Schritte nicht ausgeführt werden. In einem anderen Beispiel können bestimmte Schritte in einer anderen zeitlichen Reihenfolge als der oben aufgelisteten ausgeführt werden, wozu auch eine gleichzeitige Ausführung gehört.
  • 7 veranschaulicht ein Suchsystem 700 für elektronische medizinische Aufzeichnungen, das gemäß einer Ausführungsform der vorliegenden Erfindung verwendet wird. Das System 700 umfasst eine Benutzerschnittstelle 710, eine Datenbank 720 und ein Vokabular 730. Ähnlich zu den oben beschriebenen Ausführungsformen kann ein Benutzer auf die Benutzerschnittstelle 710 zugreifen, um eine Suche zur Identifizierung eines potenziellen Pools von Teilnehmern durchzuführen. In bestimmten Ausführungsformen kann das System 700 z.B. zu dem/den oben in Bezug auf 1 und 5 beschriebenen System(en) ähnlich gestaltet sein.
  • Der Benutzer kann z.B. einen oder mehrere Begriffe eingeben und/oder ein oder mehrere Begriffe aus einem Menü oder einer einfach oder mehrfach abgestuften Liste (bzw. Listen) auswählen. Der Begriff (bzw, die Begriffe) kann/können gemäß einem oder mehreren vorgegebenen und/oder standardmäßigen Vokabularien, Lexika, Grammatiken, Codes etc., wie z.B. dem Vokabular 730, ausgewählt und/oder eingegeben werden. Alternativ kann der Begriff (bzw. können die Begriffe) ohne Bezug auf ein bestimmtes Vokabular, ein 'bestimmtes Lexikon, eine bestimmte Grammatik und/oder einen bestimmten Code ausgewählt und/oder eingegeben und dann normalisiert und/oder anderweitig gemäß einem Vokabular, Lexikon, einer Grammatik, einem Code und/oder einer Begriffsliste umgewandelt werden. In bestimmten Ausführungsformen kann ein Begriff (bzw. können Begriffe) und/oder andere Kriterien eingegeben und für eine Suche ohne Normalisierung oder sonstigen Umwandlung angewendet werden.
  • Es kann ein Begriff (oder können mehrere Begriffe) aus dem Vokabular 730 und/oder andere Suchbegriffe/-kriterien verwendet werden, um eine Datenbank 720 und/oder einen anderen Datenspeicher abzufragen, der elektronische medizinische Patienteninformationen enthält. Wie oben beschrieben, können ein oder mehrere Begriffe/Kriterien verwendet werden, um Patienten in der Datenbank 720 zu identifizieren, die die Kriterien erfüllen und/oder die Begriffe enthalten. Zum Beispiel kann ein Datenbanksuchalgorithmus, eine spezifische maßgeschneiderte Suchroutine und/oder eine sonstige Suche in Bezug auf die Datenbank 720 ausgeführt werden, um relevante Patientendaten zu identifizieren. Eine Suche kann eine iterative Suche sein, bei der jedes der gewünschten Kriterien nacheinander angewendet wird, bis ein gewünschter Pool von potentiellen Teilnehmern identifiziert ist. Die Suchergebnisse können dann über eine Benutzerschnittstelle 710 zur Verwendung durch den Benutzer ausgegeben werden.
  • Die Komponenten des Systems 700 können bspw. allein oder z.B. in Kombination in Hardware, Firmware und/oder als Befehlssatz in Software implementiert werden. Bestimmte Ausführungsformen können als ein Satz von Befehlen geliefert werden, die sich auf einem computerlesbaren Medium wie einem Datenspeicher, einer Festplatte, DVD oder CD, befinden und zur Ausführung auf einem Mehrzweckcomputer oder einer anderen Verarbeitungsvorrichtung bestimmt sind. Bestimmte Komponenten können in verschiedenen Formen integriert werden und/oder als Software und/oder eine andere Funktionalität auf einer Rechenvorrichtung, wie bspw. einem Computer, bereitgestellt werden. Bei bestimmten Ausführungsformen können eine oder mehrere Komponenten des Systems 700 ausgelassen werden, um einen Pool von potentiellen Kandidaten für ein klinische Studie oder einen klinischen Versuch zu identifizieren.
  • Bei dem oben beschriebenen Softwareverfahren zur Erzeugung eines Pools von potentiellen Studienteilnehmern wird jede der Bedingungen gleich gewichtet. Wenn zum Beispiel ein Endnutzer eine Liste von vier Bedingungen eingibt, welche auf die im Pool enthaltenen Personen zutreffen sollten, wird im Allgemeinen ein Pool von Teilnehmern herausgegeben, welche diese vier Bedingungen aufweisen.
  • Zum Zwecke der Veranschaulichung stellt 8 ein Beispiel für vier Bedingungen dar, die ein Benutzer einge ben kann, um einen Pool von Teilnehmern zu erzeugen. 8 dient lediglich der Veranschaulichung, und es können bei einer Ausführungsform der vorliegenden Erfindung mehr oder weniger Bedingungen verwendet werden, die sich von den veranschaulichten Bedingungen unterscheiden können. Wie in 8 gezeigt, kann ein Benutzer die folgenden Bedingungen eingeben: Diabetes, Familienanamnese von koronaren Herzerkrankungen, Alter bei 25-30, im geographischen Bereich von Illinois. Eine Software kann eine Datenbank durchsuchen und einen Pool von Teilnehmern zurückgeben, die jede der Bedingungen erfüllen. In dem Veranschaulichungsbeispiel nach 8 werden nur Teilnehmer mit Diabetes, einer Familienanamnese von koronaren Herzerkrankungen, einem Alter zwischen 25 und 30 und aus dem geographischen Bereich von Illinois herausgegeben.
  • Der Pool von Teilnehmern, der von dem oben beschriebenen Algorithmus geliefert wird, kann jedoch unnötig eingeschränkt sein. Der Algorithmus könnte Teilnehmer entfernen, die den eingegebenen Bedingungen nicht exakt entsprechen, aber dennoch für die Studie passend sein können. Folglich ist es zur Maximierung der Größe eines potentiellen Tools wünschenswert, dem Benutzer zu ermöglichen, einen weniger restriktiven Satz von Bedingungen einzugeben, und zwar im Gegensatz zu der Überprüfung, ob die Bedingungen vorliegen oder ob sie nicht vorliegen. Eine Technik, die es dem Benutzer ermöglicht, einen weniger einschränkenden Satz von Bedingungen einzugeben, kann darin bestehen, dass dem Benutzer ermöglicht wird, die Bedingungen zu gewichten. Mit anderen Worten ist es wünschenswert, den Benutzer in die Lage zu versetzen, die Bedingungen auf der Basis ihrer Wichtigkeit für eine bestimmte Studie zu identifizieren.
  • In einer Ausführungsform der vorliegenden Erfindung verwendet ein Softwarealgorithmus eine Gewichtung, die jeder Bedingung zugeordnet wird, um aus einer Sammlung von kodierten elektronischen medizinischen Patientenaufzeichnungen einen maximal großen Pool zu erzeugen. Die Gewichtung jeder Bedingung ermöglicht der Software, eine Verfeinerungsfunktion durchzuführen, um einen stärker verfeinerten Pool von Teilnehmern zurückzugeben.
  • In einer Ausführungsform erlaubt die Benutzerschnittstelle für den Softwarealgorithmus dem Endnutzer, eine Liste von klinischen Bedingungen einzugeben. Die klinischen Bedingungen können identifizierbar sein und in der Datenbank mit kodierten Begriffen in den elektronischen medizinischen Patientenaufzeichnungen verbunden sein. Der Softwarealgorithmus kann dem Endnutzer ermöglichen, jede Bedingung gemäß einem Rang nach relativer Bedeutung zu klassifizieren und zu bestimmen, ob die Bedingung für den Pool obligatorisch ist. Der Softwarealgorithmus kann ferner dem Endnutzer erlauben, numerischen Bereichsbedingungen eine prozentuale Abweichung zuzuordnen. Wenn der Benutzer die spezifischen Bedingungen eingegeben hat, kann der Softwarealgorithmus anschließend eine Verfeinerungsfunktion durchführen, um gemäß der Gewichtung jeder Funktion, wie diese von dem Benutzer zugeordnet wurde, eine maximale Anzahl von Patienten hervorzubringen. Nachdem die Suche beendet wurde, liefert der Softwarealgorithmus die Ergebnisse zurück und zeigt einen Pool von potentiellen Teilnehmern an. Der Softwarealgorithmus kann dem Endnutzer ermöglichen, Studienparameter auszuwählen oder abzuwählen, die eine hohe Korrelation mit einem größeren Gesamtpatientenergebnis aufweisen.
  • 9 veranschaulicht eine Ausführungsform der Erfindung, bei der die Benutzerschnittstelle dem Endnutzer ermöglicht, jeder der Bedingungen, die zur Erzeugung des Pools verwendet werden, eine Gewichtung zuzuordnen. 9 dient lediglich der Veranschaulichung, und es können im Zusammenhang mit einer Ausführungsform der Erfindung mehr oder weniger Bedingungen verwendet werden, die sich von den dargestellten Bedingungen unterscheiden können.
  • Wie in 9 gezeigt, kann die Bedingungsspalte 910 gefüllt werden, indem ein Benutzer die Bedingungen eingibt. Die Bedingungen können im Allgemeinen durch eine Datenbank zu identifizieren sein und mit den kodierten Begriffen in den elektronischen medizinischen Patientenaufzeichnungen verbunden sein. Zusätzlich kann in einer Ausführungsform die Bedingungsspalte 910 gefüllt werden, indem ein Benutzer einen vorgegebenen Studientyp 915 eingibt und die zu diesem Studientyp gehörenden Bedingungen automatisch in die Bedingungsspalte 910 eingetragen werden. Zum Beispiel kann ein Benutzer einen vorbestimmten Studientyp 915 der Studie A eingeben. Der Studientyp von Studie A kann mit einem vorbestimmten Satz von Bedingungen verbunden sein, welche in die Bedingungsspalte 910 eingetragen werden. In einer Ausführungsform kann die Studie A auch mit den anderen Parametern, wie dem Ranking, der prozentualen Abweichung und ob diese Bedingung obligatorisch ist, verbunden bzw. verlinkt sein. Ähnlich kann eine Studie B mit einem im Voraus festgelegten Satz von Bedingungen verlinkt bzw. sein, die sich von denjenigen der Studie A unterscheiden und in die Bedingungsspalte 910 eingetragen werden. Es kann eine beliebige Anzahl von vorbestimmten Studientypen 915 verwendet werden. Obwohl in 9 nur drei Parameter veranschaulicht sind, können bei den Ausführungsformen der vorliegenden Erfindung mehr oder weniger Parameter verwendet werden. Es wird in Betracht gezogen, dass eine Kombination aus Benutzereingabe und automatischer Eintragung in die Bedingungsspalte 910 in einigen Ausführungsformen der vorliegenden Erfindung benutzt werden kann.
  • Studientypen können zugehörige Such- oder Variablenparameter aufweisen, die als standardmäßige Vorgaben oder Standardeinstellungen angefügt sind und zu denen die geographische Lage, das Patientenvolumen und Krankheits- oder Therapiekategorie gehören können. Studientypenvorgaben können verwendet werden, wenn jede Studie jeweils als primäres Ziel, primärer Fokus oder primäre Aufgabe für den Forscher ausgewählt wird. Das heißt, dass Suchvorgänge in Bezug auf die anvisierten Ziele unter Verwendung von Standardparametern optimiert werden können. Die Suchvorgänge können hinsichtlich der angestrebten Ziele optimiert werden. Zum Beispiel können obligatorische Bedingungen auf bestimmte Orte in einer geographischen Vorgabe angewendet werden, während andere Datenelemente optional oder weniger gewichtet sein können. Diese Vorgaben können z.B. eine einheitliche Suchmethodik unter Datenlagern oder Sponsorenorganisationen schaffen.
  • In dem in 9 gezeigten Beispiel kann ein Benutzer die folgenden Bedingungen in die Bedingungsspalte 910 eintragen: Diabetes, Familienanamnese von koronaren Arterienerkrankungen, Alter zwischen 25-30, im geographischen Bereich von Illinois. Wenn in dem in 10 veranschaulichten Beispiel diese vier Bedingungen in die Benutzerschnittstelle eingegeben würden, würde der Softwarealgorithmus im Allgemeinen einen Pool ausgeben, in dem jeder Patient diese Bedingungen erfüllt. In dem in 9 gezeigten Beispiel stellen die Bedingungen für den Pool nur einen von mehreren Faktoren dar, welche der Softwarealgorithmus verwenden kann, um einen zugeschnittenen Teilnehmerpool zu erzeugen, so dass eine verbesserte Menge von qualifizierten Teilnehmern für eine bestimmte Studie erhalten wird.
  • Sobald der Benutzer die Bedingungen in die Bedingungsspalte 910 eingegeben hat, kann der Benutzer auch andere Informationen zu den Bedingungen eingeben, um die Erzeugung des Pools maßzuschneidern. Wie in 9 gezeigt, kann ein Benutzer jeder Bedingung in der Bedingungsspalte 910 einen Rang in einer Rangfolge zuordnen. Ein Benutzer kann jeder Bedingung je nach Bedeutung für den Pool einen Rang verleihen. Zum Beispiel hat in 9 ein Benutzer Diabetes als die wichtigste Bedingung für den gewünschten Pool eingestuft. Die zweitwichtigste gewünschte Bedingung ist eine Familienanamnese von koronaren Arterienerkrankungen. Die nächst wichtige Bedingung ist das Alter. Und schließlich ist der geographische Aufenthaltsort des Teilnehmers die am wenigsten wichtige Bedingung.
  • Die Bedeutung der Rankings bzw. der Rangvergabe bei den Bedingungen kann je nachdem, ob die Bedingung für den Pool obligatorisch ist, angepasst werden. Wenn eine Bedingung obligatorisch ist, dann muss ein Teilnehmer die Bedingung erfüllen, um für die Aufnahme in den Pool in Betracht gezogen zu werden. Wenn die Bedingung nicht obligatorisch oder fakultativ ist, wird die Bedingung als bevorzugte Bedingung betrachtet. Dennoch können Teilnehmer, die diese Bedingung nicht erfüllen, in den Pool aufgenommen werden. In dem Beispiel, das in 9 gezeigt ist, kann ein Benutzer in der Spalte 940 angeben, ob die Bedingung für den Pool obligatorisch ist. Wie in der Spalte 940 gezeigt, hat der Benutzer angegeben, dass die Bedingungen mit dem Rang 1 und 2 für die Studie obligatorisch sind. In dem angegebenen Beispiel hat der Benutzer angezeigt, dass jedes Mitglied des Pools Diabetes und eine Familienanamnese von koronaren Arterienerkrankungen haben muss. Der Benutzer hat angegeben, dass die im Rang auf Platz 3 befindliche Bedingung, nämlich im Alter von 25-30, sowie die Bedingung auf Platz 4, die geographische Lage Illinois, nicht obligatorisch sind. Diese Bedingungen werden allerdings bevorzugt.
  • Für Bedingungen mit einem numerischen Wert, wie die Bedingung 3 nach 9, die ein Alter von 25-30 anzeigt, kann der Benutzer eine akzeptable Abweichung festlegen. Zum Beispiel hat der Benutzer in Spalte 930 angegeben, dass eine Altersabweichung von 10% für den erwünschten Pool zuverlässig ist. In diesem Beispiel sind 10% von 25 2,5 Jahre, und 10% von 30 sind 3 Jahre. In einer Ausführungsform kann die Software eine Abweichung als Prozentanteil oder als absolute Zahl (ganzzahlig oder nicht-ganzzahlig) enthalten. In einer Ausführungsform kann die Software auf das nächstliegende ganze Jahr runden. In dem Beispiel nach 9 kann die Software die Abweichung als 3 Jahre interpretieren. Die Signifikanz des Abweichungsgrads kann durch den Benutzer angepasst werden. Ein Benutzer kann angeben, dass der numerische Bereich von 25-30 optimal ist, aber dass eine Abweichung von 3 Jahren außerhalb des Altersbereichs, also 22-33, zulässig ist. In einer Ausführungsform kann die Software den Altersbereich mit Abweichungsgrenzen als eine obligatorische Bedingung behandeln. In diesem Fall kann die Software den Altersbereich von 22-33 als eine obligatorische Bedingung behandeln und keine Teilnehmer angeben, die außerhalb dieses Bereichs liegen. Alternativ kann die Software den Altersbereich mit den Abweichungs grenzen als optional behandeln. In solch einer Ausführungsform kann der Altersbereich von 22-33 als bevorzugt interpretiert werden, aber Teilnehmer, die außerhalb dieses Altersbereichs liegen, können dennoch in den Pool aufgenommen werden. Die hier angegebenen numerischen Werte dienen lediglich Veranschaulichungszwecken. Es können beliebige numerische Werte verwendet werden, wozu auch Laborergebnisse oder andere numerische Werte aus Tests oder anderen Prozeduren gehören.
  • So wie die Parameter in 9 gerade festgesetzt sind, müssen die Teilnehmer, die in den Pool aufgenommen werden können, Diabetes und eine Familienanamnese von koronaren Arterienerkrankungen haben. In den Pool werden beliebige Teilnehmer aufgenommen, welche diese beiden Bedingungen erfüllen. Optimale Teilnehmer für den Pool erfüllen die weiteren Bedingungen, haben nämlich ein Alter von 25-30 Jahren und einen geographischen Standort in Illinois. Die nächste Teilnehmergruppe kann die Bedingungen 1, 2 und 4 erfüllen und sich innerhalb der zulässigen numerischen Abweichung von Bedingung 3 befinden. Die nächste Gruppe von Teilnehmern kann die Bedingungen 1, 2 und 3, jedoch nicht Bedingung 4 erfüllen. Die nächste Teilnehmergruppe kann die Bedingungen 1, 2 und 4, jedoch nicht Bedingung 3 erfüllen. Die nächste Teilnehmergruppe kann nur die Bedingungen 1 und 2 erfüllen. Auf diese Weise werden die Teilnehmer in eine Rangordnung gemäß ihrer Eignung für den Pool gebracht. Die Teilnehmer, deren Ranking auf numerischen Werten beruht, kann ihr geringeres Abweichungsmaß gegenüber dem optimalen oder erwünschten numerischen Wert angezeigt werden. Zum Beispiel wird bei Teilnehmern in dem obigen Beispiel, deren Rangordnung auf ihrem Alter beruht, ein Teilnehmer von 31 Jahren vor einem Teilnehmer von 19 Jahren gelistet.
  • In 10 ist das Beispiel von 9 weitergeführt, indem ein Benutzerschnittstellen-Bildschirm veranschaulicht ist, wobei die Benutzerschnittstelle die Ergebnisse des Pools anzeigt, der gemäß den oben in dem Beispiel nach 9 umrissenen Parametern erzeugt wurde. In der ersten Zeile von 10 sind die Bedingungen gemäß ihrer Rangordnung angezeigt. In Spalte 1010 sind alle Teilnehmer A-I aufgelistet, die die oben genannten Parameter erfüllen. Die Teilnehmer sind in der optimalen oder stärker verfeinerten Reihenfolge entsprechend den Parametern gelistet. Spalten 1020 und 1030 veranschaulicht, dass die obligatorischen Bedingungen für jeden Teilnehmer erfüllt sind. In Spalte 1040 ist der erwünschte numerische Wert für jeden der Teilnehmer, in diesem Fall das Alter jedes Teilnehmers, aufgelistet. In Spalte 1050 ist der geographische Wohnort jedes Teilnehmers aufgelistet.
  • Wie in 10 gezeigt, sind die Teilnehmer A-C die besser geeigneten Teilnehmer, da sie alle drei Bedingungen erfüllen. Die Teilnehmer D-E erfüllen die Bedingungen 1, 2 und 4 und befinden sich hinsichtlich der Bedingung 3 innerhalb des zulässigen Abweichungsbereichs. Teilnehmer F erfüllt Bedingungen 1, 2 und 3, jedoch nicht die Bedingung 4. Teilnehmer G erfüllt die Bedingungen 1, 2 und 4, jedoch nicht Bedingung 3. Teilnehmer H und I erfüllen nur die Bedingungen 1 und 2. Der hier gezeigte Rankingalgorithmus stellt lediglich ein Beispiel dar. Ein Benutzer kann die Ranglistenordnung anpassen, und es können andere Ranglistenordnungen benutzt werden. Alternativ oder zusätzlich kann eine Abweichung zwischen dem tatsächlichen geographischen Aufenthaltsort eines Teilnehmers und einem gewünschten geographischen Aufenthaltsort festgelegt werden. Die Abweichung bei einer Variablen wie der geographischen Lage kann durch die Entfernung von einer bestimmten Adresse oder einer Postleitzahl beschrieben werden. In einer Ausführungsform kann ein Benutzer einen Patienten anklicken, um weitere Kontaktinformationen zu erhalten oder Einsicht in medizinische Akten dieses Patienten und/oder seine Krankengeschichte zu erhalten. Alternativ können die Kontaktinformationen dem Benutzer angezeigt werden. In einer weiteren Alternative können Kästchen zum Ankreuzen verfügbar sein, die dem Benutzer die Auswahl einer Untergruppe von Patienten ermöglichen. Durch die Software können dann die Kontaktinformationen und/oder die medizinischen Aufzeichnungen und/oder die Krankengeschichte der ausgewählten Patienten gefunden bzw. abgerufen werden. Zusätzlich können in einer Ausführungsform optimale Kandidaten (in dem oberen Beispiel A-C), die alle gewünschten Bedingungen erfüllen, hervorgehoben oder schattiert werden, so dass sie gegenüber den anderen Kandidaten unterschieden werden.
  • In 11 ist ein Verfahren 1100 gemäß einer Ausführungsform der vorliegenden Erfindung veranschaulicht. In Schritt 1110 werden mehrere klinische Bedingungen an einer Benutzerschnittstelle aufgenommen. Die Bedingungen können grundsätzlich mit kodierten Begriffen in den elektronischen medizinischen Patientenaufzeichnungen verbunden sein. In Schritt 1120 können Parameter zum Zuschneiden bzw. Spezifizieren einer Durchsuchung der elektronischen medizinischen Aufzeichnungen für die klinischen Bedingungen empfangen werden. Zum Beispiel könnten zu solchen Parametern das Ranking bzw. der Rang der Bedingungen, die Bestimmung, ob die Bedingungen für den Pool obligatorisch sind, und die Festlegung einer prozentualen Abweichung für numerische Bereiche gehören. In Schritt 1130 wird eine Optimierungsfunktion durchgeführt, um einen Pool gemäß den spezifizierten Bedingungen und Parametern zu erzeugen. In Schritt 1140 wird der Pool in einer Reihenfolge angezeigt, die von den am besten geeigneten Ergebnissen zu den am wenigsten geeigneten Ergebnissen reicht.
  • 12 veranschaulicht ein Verfahren 1200 gemäß einer Ausführungsform der vorliegenden Erfindung. In Schritt 1210 kann ein Benutzer mehrere klinische Bedingungen an einer Benutzerschnittstelle eingeben. Die Bedingungen können grundsätzlich mit kodierten Begriffen in den elektronischen medizinischen Patientenaufzeichnungen verbunden sein. In Schritt 1220 kann ein Benutzer jeder klinischen Bedingung einen Platz in einer Rangordnung zuweisen. Ein Benutzer kann für jede Bedingung einen numerischen Rangwert eingeben, um die Wichtigkeit einer bestimmten Bedingung für den gewünschten Pool anzugeben. In Schritt 1230 kann ein Benutzer jede klinische Bedingung als obligatorisch oder optional kennzeichnen. Eine Kennzeichnung als obligatorisch bedeutet, dass Mitglieder des Pools die obligatorischen Bedingungen aufweisen müssen. Die Kennzeichnung als optional weist darauf hin, dass die Mitglieder des Pools die optionalen Bedingungen vorzugsweise aufweisen sollten. In Schritt 1240 kann ein Benutzer numerischen Bereichen optional eine prozentuale Abweichung zuordnen. Obwohl Kandidaten in dem numerischen Bereich optimal sind, können auch Kandidaten zulässig die sich innerhalb der Abweichung des numerischen Bereiches befinden.
  • Ein oder mehrere Schritte der Verfahren 1100 und 1200 können allein oder z.B. in Kombination in Hardware, Firmware und/oder als Befehlssatz in Software implementiert sein. Bestimmte Ausführungsformen können als ein Satz von Befeh len bereitgestellt werden, die sich auf einem computerlesbaren Medium, wie bspw. einem Datenspeicher, einer Festplatte, DVD oder CD befinden und zur Ausführung auf einem Universalcomputer oder einer anderen Verarbeitungsvorrichtung bestimmt sind.
  • Bei bestimmten Ausführungsformen der vorliegenden Erfindung können eine oder mehrere Schritte der Verfahren 1100 und 1200 ausgelassen oder in einer anderen Reihenfolge als der hier aufgelisteten durchgeführt werden. Zum Beispiel können einige Schritte in bestimmten Ausführungsformen der vorliegenden Erfindung nicht ausgeführt werden. In einem anderen Beispiel können bestimmte Schritte in einer anderen zeitlichen Reihenfolge als der oben aufgelisteten ausgeführt werden, wozu auch eine gleichzeitige Ausführung gehört.
  • Das oben beschriebene System und Verfahren 1100 kann als Teil eines computerlesbaren Speichermediums ausgeführt sein, das einen Satz von Anweisungen für einen Computer enthält. Der Satz von Anweisungen kann eine erste Empfangsroutine umfassen, die dem Aufnehmen mehrerer klinischer Bedingungen an einer Benutzerschnittstelle dient. Der Satz von Anweisungen kann eine zweite Empfangsroutine umfassen, die dem Empfang von Parametern zur Maßschneiderung einer Durchsuchung der elektronischen medizinischen Aufzeichnungen für die klinischen Bedingungen dient. Der Satz von Instruktionen kann ferner eine Ausführungsroutine umfassen, die der Ausführung der Optimierungsfunktion dient, mit deren Hilfe ein Pool gemäß den spezifizierten Bedingungen und Parametern erzeugt wird. Der Instruktionssatz kann auch eine Anzeigeroutine umfassen, die dem Anzeigen des Pools in einer Reihenfolge von den am besten geeigneten Ergebnissen zu den am wenigsten geeigneten Ergebnissen dient.
  • Das oben beschriebene System und Verfahren 1200 kann als Teil eines computerlesbaren Speichermediums ausgeführt sein, das einen Satz von Befehlen für einen Computer enthält. Der Befehlssatz kann eine Eingaberoutine umfassen, die der Eingabe mehrerer klinischer Bedingungen an einer Benutzerschnittstelle dient. Der Befehlssatz kann eine Rankingroutine oder Rangklassifizierungsroutine zur Zuordnung einer Rangordnungsposition für jede klinische Bedingung enthalten. Der Befehlssatz kann ferner eine Identifizierungsroutine umfassen, die der Festlegung dient, ob eine jede klinische Bedingung obligatorisch oder optional ist. Der Befehlssatz kann ferner eine Zuordnungsroutine umfassen, die dazu dient, numerischen Bereichen optional eine prozentuale Abweichung zuordnen zu können. Der Befehlssatz kann ferner eine Suchroutine umfassen, die dazu dient, kodierte elektronische medizinische Daten zu durchsuchen, um gemäß den Bedingungen, dem Rang der Bedingungen, der Kennzeichnung als obligatorisch und, wenn vorhanden, einer Abweichung für numerische Bereiche einen Pool von Kandidaten zu erzeugen. Der Befehlssatz kann ferner eine Anzeigeroutine umfassen, die dem Anzeigen des Pools von Kandidaten in einer Reihenfolge dient, die sich von den am besten geeigneten Ergebnissen zu den am wenigsten geeigneten Ergebnissen bewegt. Der Befehlssatz kann ferner eine Auswahlroutine umfassen, die dem Auswählen einer Untergruppe der Kandidaten aus dem Pool dient, um zu dieser Untergruppe weitere Informationen abzurufen.
  • So können in bestimmten Ausführungsformen lokale und/oder zentralisierte elektronische medizinische Auf zeichnungsdaten benutzt werden, um Teilnehmer für eine oder mehrere klinische Studien zu identifizieren. In bestimmten Ausführungsformen kann eine Sammlung von kodierten elektronischen medizinischen Patientenaufzeichnungen durchsucht werden, um Teilnehmer für eine klinische Studie zu identifizieren. Eine Benutzerschnittstelle ermöglicht dem Endnutzer, eine Liste von leicht zu interpretierenden klinischen Bedingungen einzugeben. Die Begriffe und Bedingungen können in einer Datenbank mit kodierten Begriffen in den elektronischen medizinischen Patientenaufzeichnungen verbunden oder verknüpft sein. Wenn eine Suche gestartet wird, werden die Aufzeichnungen auf der Grundlage der klinischen Bedingung nach einer größten Häufigkeit durchsucht. Sobald ein anfänglicher Pool von potentiellen Teilnehmern identifiziert ist, wird die klinische Bedingung mit der nächst größeren Häufigkeit (auf der Grundlage einer regulären Grundbeurteilung der Inzidenz klinischer Bedingungen) verwendet, um den anfänglichen Pool einzugrenzen. Eine Eingrenzungsüberprüfung kann solange fortgeführt werden, bis alle Bedingungen erfüllt sind und ein Pool von potentiellen Teilnehmern eine Studie identifiziert worden ist.
  • Bei bestimmten Ausführungsformen wird die relative Auswirkung jeder Bedingung auf die resultierende Gesamtzahl von Patienten in dem Studienprotokoll berücksichtigt, wenn diese auf eine Sammlung von kodierten elektronischen medizinischen Patientenakten angewendet wird. Die Benutzerschnittstelle erlaubt es dem Endnutzer, eine Liste von leicht interpretierbaren klinischen Bedingungen einzugeben, wobei die verwendeten Begriffe in der Datenbank mit kodierten Begriffen in den elektronischen medizinischen Patientenakten verknüpft sind. Wenn die Suche abgeschlossen ist, beschreibt die Anwendung jede klinische Bedingung oder je den Studienparameter und das dazugehörige Patientenergebnis. Die Anwendung kann es dem Endnutzer ermöglichen, Studienparameter auszuwählen oder zu verwerfen, die eine hohe Korrelation mit einer größeren resultierenden Anzahl von Patienten aufweisen. Die Anwendung erlaubt es dem Endnutzer auch, jedem Studienparameter je nach relativer Wichtigkeit einen Platz in einer Rangfolge zuzuweisen und dann eine Verfeinerungsfunktion durchzuführen, bei der der Algorithmus die höchste resultierende Gesamtzahl von Patienten für die Studie erzeugt, wobei er dazu beiträgt, Studienparameter, die für den Nutzer von größter Wichtigkeit sind, zu maximieren.
  • In bestimmten Ausführungsformen wirkt ein Benachrichtigungssystem auf elektronische medizinische Aufzeichnungssysteme ein, so dass potentielle Forscher auf relevante klinische Studien aufmerksam gemacht werden, wobei es eine Option gibt, der Studie „beizutreten" oder sie elektronisch weiterzuverfolgen und wobei Patienten automatisch reidentifiziert werden können, die zuvor durch ein verschlüsseltes Identifikationszeichen (eine Nummer, die jedem Patienten zugeteilt wird) deidentifiziert waren, und wobei diese Patienten im Folgenden von relevanten klinischen Studien in Kenntnis gesetzt werden können, und zwar mit Hilfe einer ähnlichen „Beitritts"-Funktionalität, wie sie oben beschrieben ist. Das System durchsucht Datenbanken, die sehr detaillierte Daten über potentielle Studienforscher und Teilnehmer enthalten, und benachrichtigt automatisch jede Gruppe durch eine elektronische medizinische Aufzeichnung über eingehende elektronische Kommunikationsprotokolle. Dadurch führt das System die Identifizierung von potentiellen Forschern und Teilnehmern gegenüber althergebrachten Verfahren mit großer Effizienz durch, und zwar aufgrund der hohen Spezifizierbarkeit der Suchmöglichkeiten, bei denen nur Forscher und Teilnehmer kontaktiert werden, die für die Studie relevant sind, sowie aufgrund der Tatsache, dass jeder die Möglichkeit hat, sofort „beizutreten" (sich der Studie anzuschließen) oder über das Internet oder ein anderes elektronisches Kommunikationsnetzwerk zusätzliche Informationen anzufordern.
  • So identifizieren bestimmte Ausführungsformen potentielle Teilnehmer einer Studie im Vergleich zu anderen Verfahren bei reduziertem Zeitaufwand, reduzierten Kosten und/oder höherer Qualität. Bei bestimmten Ausführungsformen werden kodierte elektronische medizinische Patientenakten bzw. -aufzeichnungen verwendet, um potenzielle Teilnehmer einer Studie zu identifizieren. Bei bestimmten Ausführungsformen werden kodierte elektronische medizinische Patientenakten verwendet, um klinische Studienprotokolle und die resultierende Anzahl der Patienten zu verbessern sowie um die Eigenschaften von Studienteilnehmern besser anzupassen. Bestimmte Ausführungsformen tragen dazu bei, die Kosten und die aufgewendete Zeit zu reduzieren, die zur Rekrutierung von Forschern und Teilnehmern erforderlich ist, und erleichtern die Anmeldung von Teilnehmern mit Hilfe von elektronischer Benachrichtigungen über eine elektronische medizinische Akte und der damit verbundenen „Beitritts"-Funktion. Ferner wird keine Zeit mit potentiellen Teilnehmern vergeudet, die für das Studienprotokoll (Hintergrund des Forschers und/oder des Patienten) nicht wirklich passend sind. In bestimmten Ausführungsformen werden kodierte elektronische medizinische Patientenakten verwendet, um die Benachrichtigung und die Rekrutierung bei klinischen Studien zu verbessern, wobei die für ungeeignete Teilnehmer aufgewendete Zeit reduziert wird und es den Teilnehmern er möglicht wird, über eine elektronische „Beitritts"-Funktion sofort anzumelden.
  • Obwohl die Erfindung in Bezug auf beispielhafte Ausführungsformen beschrieben wurde, ist es für einen Fachmann ohne weiteres verständlich, dass verschiedene Änderungen vorgenommen werden und die Elemente der Ausführungsformen durch Äquivalente ersetzt werden können, ohne dass von dem Schutzumfang der Erfindung abgewichen wird. Zusätzlich können viele Modifikationen vorgenommen werden, um eine bestimmte Situation oder ein bestimmtes Material an die Lehre dieser Erfindung anzupassen, ohne ihren wesentlichen Rahmen zu berühren. Daher ist vorgesehen, dass die Erfindung nicht auf die spezielle Ausführungsform beschränkt sein soll, die als die beste in Betracht gezogene Ausführungsform beschrieben ist, sondern dass die Erfindung alle Ausführungsformen umfassen soll, die in den Schutzumfang der beigefügten Patentansprüche fallen. Ferner bezeichnen die verwendeten Begriffe erste/erster, zweite/zweiter etc. nicht eine Reihenfolge in Bezug auf die Wichtigkeit; vielmehr werden die Begriffe erste/erster, zweite/zweiter etc. verwendet, um Elemente voneinander zu unterscheiden.
  • Bestimmte Ausführungsformen der vorliegenden Erfindung ergeben Systeme und Verfahren zur Verfeinerung der Identifikation von Kandidaten für klinische Studien. In einer Ausführungsform kann das Verfahren 1100 einen Empfang 1110 mehrerer klinischer Bedingungen an einer Benutzerschnittstelle umfassen. Die Bedingungen können generell mit kodierten Begriffen in elektronischen medizinischen Patientenakten verknüpft sein. Das Verfahren kann ferner einen Empfang 1120 von Parametern zur genauen Anpassung einer Durchsuchung von elektronischen medizinischen Daten nach klinischen Bedingungen umfassen. Zum Beispiel können die Parameter die Bedingungen gewichten und eine Rangklassifizierung der Bedingungen, eine Bestimmung, ob die Bedingungen für den Pool obligatorisch sind, und eine Bestimmung einer prozentualen Abweichung für numerische Bereiche enthalten. Das Verfahren kann ferner eine Ausführung 1130 einer Optimierungsfunktion zur Erzeugung eines Pools gemäß den spezifizierten Bedingungen und Parametern umfassen. Das Verfahren kann ferner eine Anzeige 1140 des Pools in einer Reihenfolge umfassen, die von den am besten geeigneten Ergebnissen zu den am wenigsten geeigneten Ergebnissen verreicht.
  • BEZUGSZEICHENLISTE
    Figure 00610001
  • Figure 00620001
  • Figure 00630001

Claims (10)

  1. Verfahren (1100) zur Durchsuchung kodierter elektronischer medizinischer Daten, um einen Pool von potentiellen Kandidaten für eine Studie zu identifizieren, wobei das Verfahren aufweist: Empfang (1110) mehrerer Bedingungen an einer Benutzerschnittstelle; Empfang (1120) mehrerer Parameter für die genaue Anpassung einer Durchsuchung der elektronischen medizinischen Daten, wobei diese Parameter verwendet werden, um diesen Bedingungen eine Gewichtung zuzuordnen; und Durchsuchung (1130) der kodierten elektronischen medizinischen Daten, um einen Pool von Kandidaten gemäß den gewichteten Bedingungen zu erzeugen.
  2. Verfahren nach Anspruch 1, ferner umfassend den Schritt eines Anzeigens (1140) des Pools von Kandidaten in einer Reihenfolge von den am besten geeigneten Ergebnissen zu den am wenigsten geeigneten Ergebnissen.
  3. Verfahren nach Anspruch 1, wobei die Bedingungen kodierten Begriffen in den kodierten elektronischen medizinischen Daten entsprechen.
  4. Verfahren nach Anspruch 1, wobei die Parameter eine Ordnung der Bedingungen entsprechend einem Rang umfassen.
  5. Verfahren nach Anspruch 1, wobei die Parameter eine Bestimmung von obligatorischen Bedingungen umfassen.
  6. Verfahren nach Anspruch 1, wobei die Parameter eine Bestimmung einer Abweichung für numerische Bereiche umfassen.
  7. Verfahren nach Anspruch 1, wobei die Bedingungen und Parameter auf einem zuvor bestimmten Studientyp beruhen.
  8. Verfahren nach Anspruch 1, wobei die Parameter eine Bestimmung einer Abweichung für geographische Bereiche umfassen.
  9. Computerlesbares Medium mit einem Satz von Instruktionen zur Ausführung durch einen Computer, wobei dieser Instruktionssatz umfasst: eine Eingaberoutine zum Empfangen mehrerer Bedingungen (1210); eine Rankingroutine zum Ordnen der mehreren Bedingungen entsprechend einem Rang (1220); eine Identifizierungsroutine zur Festlegung, ob eine bestimmte Bedingung obligatorisch ist (1230); und eine Zuordnungsroutine zur optionalen Zuordnung einer Abweichung für numerische Bereiche (1240).
  10. Satz von Instruktionen nach Anspruch 9, ferner umfassend eine Suchroutine zur Durchsuchung kodierter e lektronischer medizinischer Daten, um einen Pool von Kandidaten gemäß den Bedingungen, dem Rang der Bedingungen, der Festlegung als obligatorisch und, falls vorhanden, der Abweichung für numerische Bereiche zu erzeugen.
DE102007026799A 2006-06-14 2007-06-06 Systeme und Verfahren zur Verfeinerung der Identifikation von Kandidaten für klinische Studien Withdrawn DE102007026799A1 (de)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US80473806P 2006-06-14 2006-06-14
US60/804,738 2006-06-14
US11/561,240 2006-11-17
US11/561,240 US8032545B2 (en) 2006-06-14 2006-11-17 Systems and methods for refining identification of clinical study candidates

Publications (1)

Publication Number Publication Date
DE102007026799A1 true DE102007026799A1 (de) 2007-12-20

Family

ID=38331988

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102007026799A Withdrawn DE102007026799A1 (de) 2006-06-14 2007-06-06 Systeme und Verfahren zur Verfeinerung der Identifikation von Kandidaten für klinische Studien

Country Status (5)

Country Link
US (1) US8032545B2 (de)
AU (1) AU2007202746B2 (de)
CA (1) CA2590757A1 (de)
DE (1) DE102007026799A1 (de)
GB (1) GB2439197A (de)

Families Citing this family (38)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102008007824A1 (de) * 2008-02-07 2009-08-13 Siemens Aktiengesellschaft Verfahren zum Ermitteln eines oder mehrerer im Rahmen einer medizinischen Diagnose zu betrachtender, zeitlich früher erstellter Datensätze, insbesondere radiologischer Datensätze
US20090313045A1 (en) * 2008-06-11 2009-12-17 Boyce Mark D System and Method for Medical Research and Clinical Trial
US20090313170A1 (en) * 2008-06-16 2009-12-17 Agmednet, Inc. Agent for Medical Image Transmission
US20100138929A1 (en) * 2008-12-02 2010-06-03 Electronics And Telecommunications Research Institute Conditionally traceable anonymous service system
US20110078779A1 (en) * 2009-09-25 2011-03-31 Song Liu Anonymous Preservation of a Relationship and Its Application in Account System Management
US8832079B2 (en) * 2010-04-05 2014-09-09 Mckesson Financial Holdings Methods, apparatuses, and computer program products for facilitating searching
US8484254B1 (en) * 2010-08-26 2013-07-09 GlobalSubmit, Inc. Research study database to compare different research studies and to compare actual activities compared to the protocol
US8542097B2 (en) * 2011-04-13 2013-09-24 Jingle Technologies Llc Systems and methods for transmitting information, alerts, and/or comments to participants based on location information
US8990250B1 (en) 2011-10-11 2015-03-24 23Andme, Inc. Cohort selection with privacy protection
US8756076B2 (en) * 2012-06-21 2014-06-17 Cerner Innovation, Inc. HIPAA-compliant third party access to electronic medical records
JP6095919B2 (ja) * 2012-09-06 2017-03-15 メビックス株式会社 電子カルテスクリーニング結果出力装置、電子カルテスクリーニング結果出力方法及び電子カルテスクリーニング結果出力プログラム
JP6023520B2 (ja) * 2012-09-06 2016-11-09 メビックス株式会社 電子カルテスクリーニングシステム、電子カルテスクリーニング装置、電子カルテスクリーニング方法及び電子カルテスクリーニングプログラム
MX2016007389A (es) * 2013-12-09 2017-04-27 Trinetx Inc Identificacion de candidatos para ensayos clinicos.
US20150269355A1 (en) * 2014-03-19 2015-09-24 Peach Intellihealth, Inc. Managing allocation of health-related expertise and resources
DE102014106112A1 (de) * 2014-04-30 2015-11-05 Clinerion Ltd. Patientenrekrutierungssystem und Patientenrekrutierungsverfahren
US20150324550A1 (en) * 2014-05-07 2015-11-12 Drug Development Analytics LLC Medical information analysis systems and methods
US10510437B2 (en) 2015-03-03 2019-12-17 Verified Clinical Trials Method for creating and using registry of clinical trial participants
US10923234B2 (en) * 2016-03-30 2021-02-16 Jacob Barhak Analysis and verification of models derived from clinical trials data extracted from a database
KR20190022623A (ko) 2016-06-28 2019-03-06 하트플로우, 인크. 지리적 지역들에 걸친 분석용 건강 데이터를 수정 및 편집하기 위한 시스템 및 방법
US11138201B2 (en) 2017-11-29 2021-10-05 Omics Data Automation, Inc. System and method for integrating data for precision medicine
WO2019148175A1 (en) * 2018-01-29 2019-08-01 Laboratory Corporation Of America Holdings Learning filter for detection of indicators in healthcare data
US11670405B2 (en) 2018-07-12 2023-06-06 Direct Supply, Inc. Apparatus for clinical data capture
US10943681B2 (en) * 2018-11-21 2021-03-09 Enlitic, Inc. Global multi-label generating system
US11935652B1 (en) 2019-02-20 2024-03-19 Verily Life Sciences Llc Health status change detection using anomaly detection in latent spaces
JP7263095B2 (ja) * 2019-04-22 2023-04-24 ジェネシスヘルスケア株式会社 研究支援システム、研究支援装置、研究支援方法及び研究支援プログラム
US11328796B1 (en) * 2020-02-25 2022-05-10 Vignet Incorporated Techniques for selecting cohorts for decentralized clinical trials for pharmaceutical research
US11651243B2 (en) 2020-05-14 2023-05-16 Merative Us L.P. Using machine learning to evaluate data quality during a clinical trial based on participant queries
US11556806B2 (en) 2020-05-14 2023-01-17 Merative Us L.P. Using machine learning to facilitate design and implementation of a clinical trial with a high likelihood of success
US11538559B2 (en) 2020-05-14 2022-12-27 Merative Us L.P. Using machine learning to evaluate patients and control a clinical trial
US11461216B1 (en) 2020-05-18 2022-10-04 Vignet Incorporated Monitoring and improving data collection using digital health technology
US11605038B1 (en) 2020-05-18 2023-03-14 Vignet Incorporated Selecting digital health technology to achieve data collection compliance in clinical trials
US11196656B1 (en) 2021-02-03 2021-12-07 Vignet Incorporated Improving diversity in cohorts for health research
US11316941B1 (en) 2021-02-03 2022-04-26 Vignet Incorporated Remotely managing and adapting monitoring programs using machine learning predictions
US11361846B1 (en) 2021-02-03 2022-06-14 Vignet Incorporated Systems and methods for customizing monitoring programs involving remote devices
US11789837B1 (en) 2021-02-03 2023-10-17 Vignet Incorporated Adaptive data collection in clinical trials to increase the likelihood of on-time completion of a trial
US11521714B1 (en) 2021-02-03 2022-12-06 Vignet Incorporated Increasing diversity of participants in health research using adaptive methods
US11296971B1 (en) 2021-02-03 2022-04-05 Vignet Incorporated Managing and adapting monitoring programs
US20220383995A1 (en) * 2021-05-28 2022-12-01 ObjectiveGI, Inc. System and method for identifying candidates for clinical trials

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020087408A1 (en) * 1999-06-25 2002-07-04 Burnett Jonathan Robert System for providing information to intending consumers
US7158989B2 (en) * 2000-10-27 2007-01-02 Buc International Corporation Limit engine database management system
US6714929B1 (en) * 2001-04-13 2004-03-30 Auguri Corporation Weighted preference data search system and method
US7231399B1 (en) * 2003-11-14 2007-06-12 Google Inc. Ranking documents based on large data sets
EP1728189A2 (de) * 2004-03-26 2006-12-06 Convergence Ct System und verfahren zur steuerung des zugangs und der verwendung von aufzeichnungen medizinischer patientendaten
JP4008954B2 (ja) * 2004-10-29 2007-11-14 松下電器産業株式会社 情報検索装置
US7386544B2 (en) * 2005-01-13 2008-06-10 Bridgewell Inc. Database search system
US8069147B2 (en) * 2005-11-10 2011-11-29 Computer Associates Think, Inc. System and method for delivering results of a search query in an information management system
US20080162459A1 (en) * 2006-06-20 2008-07-03 Eliezer Portnoy System and method for matching parties with initiation of communication between matched parties

Also Published As

Publication number Publication date
GB2439197A (en) 2007-12-19
GB0711364D0 (en) 2007-07-25
AU2007202746A1 (en) 2008-01-10
US8032545B2 (en) 2011-10-04
US20070294110A1 (en) 2007-12-20
AU2007202746B2 (en) 2012-07-26
CA2590757A1 (en) 2007-12-14

Similar Documents

Publication Publication Date Title
DE102007026799A1 (de) Systeme und Verfahren zur Verfeinerung der Identifikation von Kandidaten für klinische Studien
DE102007026802A1 (de) Systeme und Verfahren zur Identifizierung von Kandidaten für eine klinische Studie
DE69731884T2 (de) Rechnergestütztes medizinisches diagnose- und beratungssystem mit zugang zu einem kommunikationsnetz
Bhanbhro et al. Assessing the contribution of prescribing in primary care by nurses and professionals allied to medicine: a systematic review of literature
Strong et al. Data quality in context
DE102008002920A1 (de) Systeme und Verfahren für klinische Analyseintegrationsdienste
DE102007019375A1 (de) Systeme und Verfahren zur Re-Identifikation von Patienten
DE112010001870T5 (de) Verfahren und system zum verwalten und anzeigen von medizinischen daten
DE10324673A1 (de) System zur Überwachung von Information betreffend die medizinische Versorgung eines Patienten
DE112004000647T5 (de) Informationssystem für vorbeugende Gesundheitsfürsorge
CN105940427A (zh) 识别用于临床试验的候选人
DE102014103476A1 (de) Datenverarbeitungs-Techniken
DE202019102730U1 (de) Lernmaschine für intelligente Kommunikation und Analyse
US9336351B2 (en) Method and system for collecting, storing and analyzing clinical and radiologic data
Winthereik “We fill in our working understanding”: on codes, classifications and the production of accurate data
DE112019002930T5 (de) Vorrichtung, verfahren und programm zur unterstützung der erstellung eines patientenfragebogens
US20010032102A1 (en) Psychiatric information systems, methods and computer program products that capture psychiatric information as discrete data elements
DE102021123842A1 (de) Bewertung einer verringerung eines krankheitsrisikos und behandlungsentscheidung
Corradi et al. A repository based on a dynamically extensible data model supporting multidisciplinary research in neuroscience
DE202022102083U1 (de) System zur Verwaltung von Patientenanfragen und Dienstleistungen auf einer Online-Plattform für Telemedizin unter Verwendung von maschinellem Lernen
Whalen et al. Linking client records from substance abuse, mental health and Medicaid state agencies
Kogon et al. Integrating dental data in missing persons and unidentified remains investigations: The RESOLVE INITIATIVE and DIP3
DE112020000598T5 (de) Abgleichhilfevorrichtung, abgleichhilfeverfahren und abgleichhilfeprogramm
Chen et al. An automated approach to studying health resource and infobutton use
US20140278504A1 (en) Medical Research Technology Information Consortium

Legal Events

Date Code Title Description
R005 Application deemed withdrawn due to failure to request examination

Effective date: 20140607