[go: up one dir, main page]

EP2766863A1 - Verfahren zur bearbeitung von patientenbezogenen datensätzen - Google Patents

Verfahren zur bearbeitung von patientenbezogenen datensätzen

Info

Publication number
EP2766863A1
EP2766863A1 EP12801524.5A EP12801524A EP2766863A1 EP 2766863 A1 EP2766863 A1 EP 2766863A1 EP 12801524 A EP12801524 A EP 12801524A EP 2766863 A1 EP2766863 A1 EP 2766863A1
Authority
EP
European Patent Office
Prior art keywords
data
patient
record
sensitive
generated
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.)
Ceased
Application number
EP12801524.5A
Other languages
English (en)
French (fr)
Inventor
Thomas Friese
Thomas Gossler
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.)
Siemens Healthcare GmbH
Original Assignee
Siemens AG
Siemens Corp
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 Siemens AG, Siemens Corp filed Critical Siemens AG
Publication of EP2766863A1 publication Critical patent/EP2766863A1/de
Ceased legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/28—Databases characterised by their database models, e.g. relational or object models
    • G06F16/284—Relational databases
    • G06F16/285—Clustering or classification
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/604—Tools and structures for managing or administering access control systems
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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
    • 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
    • G16Z—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS, NOT OTHERWISE PROVIDED FOR
    • G16Z99/00—Subject matter not provided for in other main groups of this subclass

Definitions

  • the invention relates to a method for processing patient-related data records, which in each case comprise medical data and sensitive patient data as plain data.
  • Recent developments in the medical field aim to provide a centralized information technology system that assembles and archives the medical records of each patient so that each physician designated by the patient has the ability to easily and quickly access all the medical information they need To access patient data.
  • PHI Protected Health Information
  • DICOM Digital Imaging and Communications in Medicine
  • image data which are created, for example, during examinations by means of a computer tomograph
  • the anonymization of the "Protected Health Information” can also be done, for example, by aliasing provided the pseudonym is known only to the originator of the data, ie the respective medical institution.
  • the object of the invention is to specify an alternative and advantageous method for processing patient-related data records.
  • the back-related claims contain in part advantageous and in part self-inventive developments of this invention.
  • the method serves for the processing of patient-related data records, which each comprise medical data and sensitive Pa ⁇ tientenish as plain data.
  • patient-related data records which each comprise medical data and sensitive Pa ⁇ tientenish as plain data.
  • sensitive patient data from each patient-related data record are anonymous, thus anonymous Pati ⁇ ducks related records are generated.
  • test data are generated from the respective sensitive patient data of each patient-related data record and integrated into the respective patient-related data record. Subsequently, the anonymized patient-related data records with the test data are made available in a cloud computing architecture.
  • sensitive patient data of a selected patient are specified on a client computer, which is connected to the cloud computing architecture, as part of a processing of a specific patient-related data record, and query data is generated from this predetermined sensitive patient data with the aid of the algorithm. If the query data of the selected patient not with the test data of the particular pa- tienten soliciten record match, throws an Siche ⁇ insurance function.
  • the patient-related data sets are encrypted, but only individual information contained therein, namely the sensitive patient data, is concealed. This is done, for example, by encrypting the sensitive patient data, such as the name of the patient, their date of birth, etc., in a manner in which the corresponding clear data is replaced by suitable placeholders.
  • the patient-related data sets can be further processed even after the anonymization of the sensitive patient data, without the anonymization of the sensitive patient data having to be reversed beforehand.
  • the anonymized patient-related data sets can be made available in the cloud computing architecture and stored and / or further processed in it without the sensitive patient data occurring as clear data within the cloud computing architecture.
  • the sensitive patient data albeit anonymized, remains firmly embedded in the patient-related data records, so that the two aforementioned and contradictory demands are met in this method.
  • Client computers connected to the cloud computing architecture then gain access to the patient-related data records. Since only an adjustment takes place in which the anonymized sensitive patient data generated at the client computer is compared with the anonymized sensitive patient data in the anonymized patient-related data records, the clear data does not appear even when accessing the cloud computing architecture.
  • the anonymous sensitive patient data so in particular the placeholder, also used to form an additional so-called “tag” and the corresponding "tag” is included in the corresponding patient-related record to this quasi with a label for a To provide archiving.
  • Tag generally refers to additional information added to the data record.
  • the sensitive patient data of each patient-related data record is first divided into key data and other sensitive patient data and subsequently all sensitive patient data from each patient-related data record are anonymous, where patient-related data records generated by anonymous ⁇ . However are generated using the algorithm only from each ⁇ itch key data of each patient-related data record test data and included in the respective patientenbe ⁇ coated record.
  • the anonymized patient-related data records with the test data are subsequently made available in the cloud computing architecture.
  • key data of a selected patient are specified on the client computer that is connected to the cloud computing architecture, and query data is generated from these predetermined key data with the aid of the algorithm. If these polling data of the selected patient not with the test data of certain patient-related data set match, is consequently triggered the Si ⁇ cherungsfunktion.
  • a method variant in which the algorithm is given by a one-way hash function also called a hash algorithm or a scatter value function
  • the same one-way hash function uses ge ⁇ tientenish is preferred for the anonymity of the sensitive parity and for generating the test data, the same algorithm.
  • the skilled worker are well known for cryptography appropriate way hash functions, so that can be found with favorable properties readily ei ⁇ ne way hash function.
  • a method variant in which a number of the anonymized patient-related data records with the test data from the cloud computing architecture contain display data for display on the client computer is expedient.
  • a variant of the method is useful in a number of pati ⁇ ducks related records contain image data of an image zeugenen modality and in generated from the image data of these patient-related records in the cloud computing architecture display data for display on the client machine. This means, for example, that image data generated on a computer tomograph as part of an examination of a patient are also available to every medical professional who, via a computer, has access to the collected medical records of his patient via the cloud computing architecture Patient has.
  • volume rendering is carried out in the cloud computing architecture, for example a processing of the data of the entire examined volume of the patient generated by the computer tomograph
  • physician's computer is merely a finished image of a single one selected by him View on the volume or a single one
  • a variant of the method is preferred to first display data and the test data an be ⁇ voted anonymized patient-related data set will be made available on the client computer when this test data are compared to the query data below when and where the safety function is triggered if the check data does not match the query data.
  • the adjustment of the data or the test process thus preferably takes place entirely locally on the client computer.
  • This checking process is preferably implemented by a separate and entirely separate from the processing of the anonymous patient-related data records application, so that in this way the desired strict separation of the anonymous patientenbezo ⁇ genes records is ensured by the plain data.
  • test data are integrated into the display data graphically and more preferably in the manner of a 2D barcode.
  • cloud computing architecture X- Provided picture from patient which is only displayed on the monitor of the computer of the physician, so be ⁇ found for example in a predetermined area of the displayed image, for example in the upper right corner, the image of a bar code or QR Codes representing the anonymized sensitive patient data and in particular the key data.
  • a suitable in this case query process this is part of the process is then designed ⁇ example, as follows.
  • the physician enters the name and date of birth of his patient in an input window, whereupon a QR code is generated by means of a given one-way hash function based on the name and date of birth.
  • a number code is generated using a two ⁇ th one-way hash.
  • the cloud computing architecture then calls up a file that has the same numeric code tagged in.
  • the image data from that file is then edited to generate a set of display data, and the display data is then sent to the computer physician gesen- det, said display data is also a QR code contained ⁇ th.
  • the inspection process is started, in which the QR code from the display and which is preferably software-based quasi-optically on the computer of the physician ge ⁇ nerêt QR code together are compared. If the two QR codes match, the display data are displayed as an image on the monitor of the computer of the physician. This image is superimposed by a second picture will be ⁇ vorzugt in the area of the displayed QR code in which the plain data, which are represented by the QR code, that is, the name and date of birth of the patient, so the doctor does not see X-ray image in the upper right corner of a QR code is shown, but an X-ray image in the obe ⁇ rer right corner of the name and date of birth of the patient to see and read.
  • the security function is triggered and, for example, an error message is displayed.
  • a display of the display data is inhibited when the backup function is triggered. If the test data and the query data do not match, the physician will not see the display data and thus will not see it. So for example, a radiograph of a patient in the cloud computing architecture quasi stored in a medical record of another patient and is now trying a physician th to sich- the medical records in this patient record, this is the attempt to the X-ray ⁇ see , receive a warning message that the X-ray image is not an X-ray image of his patient and the X-ray image is not displayed.
  • FIG. 1 shows a block diagram representation of a method for processing patient-related data records.
  • the method variant described below by way of example allows an archive for medical data to be located outside the subordinate control area of a medical facility, in this case a hospital.
  • This archive is distributed to several PACS servers (Picture Archiving and Communication System), which are part of a cloud computing architecture 2.
  • PACS servers Physical Archiving and Communication System
  • This sensitive patient information advertising the further supplemented by more sensitive patient data characterizing the performed on the computer tomograph 4 Un ⁇ and examining and clearly marked. This was, for example, the date and time of the investigation, the investigation mode, the radiation dose the patient off set etc ..
  • This patient-related data set is so ⁇ then transmitted to a server station 12 within the immediate control area of the hospital.
  • the raw data of the patient-related data record are processed further and during an image process step 14 into image data, more precisely in so-called
  • Transversal sections converted.
  • the thus processed patien ⁇ ten lovede data is subsequently stored as a copy in the Ser ⁇ verstation 12 and also for storage in the archive for medical data outside the immediate control area of the hospital, that is in the cloud computing architecture 2, processed.
  • an additional "tag” for identification is included in the patient-related data record, which contains a numerical sequence or character sequence as test data.
  • These test data are anonymized key data, whereby the key data in turn clearly assign the patient-related data record to the patient
  • the patient's name and date of birth are selected as key data from the sensitive patient data during a selection process step 16.
  • the test data here the number or character sequence, are generated from these key data by means of a one-way hash function and using the additional "tags" to the characteristic ⁇ drawing of patient-related data set involved in this.
  • all the data items contained in the patient-related data record are Anonymous patient data is anonymized using the same one-way hash function and replaced by numbers or character sequences as placeholders.
  • the key data are installed as test data in the form of a QR code in each transverse section, so that this QR code is always displayed in the representation of a corresponding transverse section on egg ⁇ nem monitor at the top right edge of the screen.
  • the corresponding QR code is thereby generated by means of a further hash algorithm, a 2D barcode hash algorithm
  • the anonymized patient-related data record is then released from the immediate control area of the hospital into the cloud computing architecture 2 and stored there in the course of a filing process step 22 in the archive for medical records. If this is the patient's first anonymized patient-related data record, a new patient record is first created in the archive, which is identified by the test data, ie the corresponding number or character sequence. Then the anonymous patient-related data is entered into the new set of ⁇ patient record. Pa ⁇ a tientenakte already exists with the corresponding test data, so deleted to create a new patient record and the anonymous patient-related data set of the patient record with the testing ⁇ data of the anonymous patient-related data record is assigned.
  • a physician is instructed by the patient to evaluate diagnostically the examination performed on the computer tomograph 4 in the hospital, he has the option of accessing the archive for medical documents via a client computer 24 which is connected to the cloud computing architecture 2 access.
  • the physician starts an application available locally on the client computer 24, by which he is requested to enter the key data of the patient, that is to say his name and date of birth, in an input window on the client computer 24.
  • the same disposable Hash function with which the sensitive patient data from the patient related data set are made anonymous to the server station 12 of the hospital are under a Anfra ⁇ ge process step 26 to the client computer 24 by the application query data, that is, in turn, a figure or character string generated.
  • the archive for medical documents in the cloud computing architecture 2 search is made for data records whose test data match the query data or whose number or character sequence matches the number or character sequence generated on the client computer 24. If corresponding data records are found, the physician is asked to select a type of display from a selection, ie, for example, a sectional view with a specially selected section plane or a 3D representation of a selected body region.
  • a type of display ie, for example, a sectional view with a specially selected section plane or a 3D representation of a selected body region.
  • the anonymized patient-related data record found is processed in the cloud computing architecture 2 as part of a processing process step 28, as a result of which display data for display on a monitor is generated.
  • Such a preparation is, for example, a so-called multiplanar reformatation (MRT), also called multiplanar reconstruction, in which the transverse sections
  • Sectional views are calculated with arbitrarily selected cutting plane to an image processing according to the MIP principle (Maximum Intensity Protection) or even a so-called ray casting method.
  • the QR code that is included in each transverse section is embedded in the display data ⁇ .
  • the display data is then transmitted to the client computer 24, where ge ⁇ genge certified as part of a reconciliation process step 30th
  • the key data entered by the physician at the client computer 24 are converted into a QR code with the aid of the aforementioned 2D bar code hash algorithm, and the QR code thus generated is combined with the QR code in the display data from the cloud.
  • Computing Architecture 2 compared.
  • a backup function is triggered, as a result of which the display data is discarded by the client computer 24 and as a result an error notification appears on the monitor of the client computer 24, which alerts the physician that the display data is assigned to an unknown patient.
  • the QR codes agree to the ⁇ released the display data as part of a release process ⁇ step 32 and displayed as an image on the monitor of the client computer ⁇ 24th
  • an additional image is also generated in the context of an overlapping process step 34, which is superimposed on the image based on the display data.

Landscapes

  • Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Theoretical Computer Science (AREA)
  • General Health & Medical Sciences (AREA)
  • Health & Medical Sciences (AREA)
  • Medical Informatics (AREA)
  • Public Health (AREA)
  • Primary Health Care (AREA)
  • Epidemiology (AREA)
  • Strategic Management (AREA)
  • Human Resources & Organizations (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Data Mining & Analysis (AREA)
  • Databases & Information Systems (AREA)
  • General Business, Economics & Management (AREA)
  • Tourism & Hospitality (AREA)
  • Quality & Reliability (AREA)
  • Operations Research (AREA)
  • Marketing (AREA)
  • Economics (AREA)
  • General Engineering & Computer Science (AREA)
  • Automation & Control Theory (AREA)
  • Bioethics (AREA)
  • Computer Hardware Design (AREA)
  • Computer Security & Cryptography (AREA)
  • Software Systems (AREA)
  • Medical Treatment And Welfare Office Work (AREA)
  • Storage Device Security (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

Die Erfindung betrifft ein Verfahren zur Bearbeitung von patientenbezogenen Datensätzen, die jeweils medizinische Daten und sensitive Patientendaten als Klardaten umfassen, bei dem die sensitiven Patientendaten eines jeden patientenbezogenen Datensatzes anonymisiert werden (20), wodurch anonymisierte patientenbezogene Datensätze erzeugt werden, bei dem mit Hilfe eines Algorithmus aus den jeweiligen sensitiven Patientendaten eines jeden patientenbezogenen Datensatzes Prüfdaten generiert und in dem jeweiligen patientenbezogenen Datensatz eingebunden werden (18), bei dem die anonymisierten patientenbezogenen Datensätze mit den Prüfdaten in einer Cloud- Computing-Architektur (2) zur Verfügung gestellt werden (22), bei dem an einem Clientrechner (24), der an die Cloud- Computing-Architektur (2) angebunden ist, im Rahmen einer Bearbeitung eines bestimmten patientenbezogenen Datensatzes sensitive Patientendaten eines ausgewählten Patienten vorgegeben werden und bei dem mit Hilfe des Algorithmus aus diesen vorgegeben sensitiven Patientendaten Abfragedaten generiert werden (26) und bei dem eine Sicherungsfunktion ausgelöst wird, wenn die Prüfdaten des bestimmten patientenbezogenen Datensatzes nicht mit den Abfragedaten des ausgewählten Patienten übereinstimmen.

Description

Beschreibung
Verfahren zur Bearbeitung von patientenbezogenen Datensätzen Die Erfindung betrifft ein Verfahren zur Bearbeitung von patientenbezogenen Datensätzen, die jeweils medizinische Daten und sensitive Patientendaten als Klardaten umfassen.
Aktuelle Entwicklungen im Medizinbereich zielen darauf ab, ein zentrales Informationstechnologie-System zu schaffen, mit dessen Hilfe die medizinischen Daten eines jeden Patienten zusammengetragen und derart archiviert werden, dass jeder vom Patienten bestimmte Mediziner die Möglichkeit hat, einfach und schnell auf alle von ihm benötigten medizinischen Daten des Patienten zuzugreifen.
Dazu ist es notwendig medizinische Daten des Patienten aus dem unmittelbaren Kontrollbereich einzelner medizinischer Einrichtungen heraus in eine von mehreren Nutzern gemeinsam verwendete Cloud-Computing-Architektur zu übertragen. Hierbei ist es wünschenswert oder, aufgrund gesetzlicher Regelungen, häufig auch notwendig, dass die sogenannten „Protected Health Information" (PHI), also alle Daten, die den Patienten eindeutig identifizierbar machen, aus den medizinischen Daten des Patienten entfernt werden. Dies gilt beispielsweise auch für Daten, die nach dem DICOM-Standard (Digital Imaging and Communications in Medicine) ausgebaut sind und die Bilddaten enthalten, welche beispielsweise bei Untersuchungen mittels eines Computertomographen erstellt werden. Die Anonymisierung der „Protected Health Information" kann dabei z.B. auch durch Pseudonym-Vergabe erfolgen, sofern das Pseudonym nur dem Urheber der Daten, also der jeweiligen medizinischen Einrichtung, bekannt ist. Um die Patientensicherheit zu gewährleisten und insbesondere um Fehldiagnosen zu vermeiden besteht zudem die Forderung, dass bei der Generierung von Bilddaten im Rahmen einer Untersuchung mittels eines bilderzeugenden medizinischen Systems die Patientenidentität untrennbar mit den generierten Bildda¬ ten verknüpft wird, sodass eine fehlerhafte Zuordnung von Bilddaten zu einem Patienten möglichst ausgeschlossen wird. Aufgrund dieser beiden widersprüchlichen Anforderungen wurde bisher meist auf den Einsatz von Cloud-Computing-Architek- turen, welche eine Vielzahl von Nutzern gemeinsam verwenden, verzichtet oder aber die Cloud-Computing-Architektur wurde mitsamt allen Zugängen im Kontrollbereich einer einzelnen me- dizinischen Einrichtung angesiedelt, da in diesem Fall eine Anonymisierung der „Protected Health Information" nicht notwendig ist. Bei einer anderen häufig verwendeten Lösung werden lediglich verschlüsselte Daten an die Cloud-Computing- Architektur abgegeben und in dieser zur Verfügung gestellt, wobei eine Entschlüsselung der Daten durch eine lokal beim Nutzer installierte Client-Application ermöglicht wird. Je nach Datenmenge und Art der Verschlüsselung ist mit einer entsprechenden Verschlüsselung der Daten oder Entschlüsselung der Daten ein sehr großer Rechenaufwand verbunden. Da die Da- ten für die Weiterverarbeitung in der Regel entschlüsselt vorliegen müssen, ist es in diesem Fall außerdem notwendig jeweils den gesamten Datensatz zu übertragen. Daher ist diese Lösung insbesondere bei Bilddaten und/oder im Falle von Nutzerzugängen, bei denen lokal nur eine relativ geringe Rechen- leistung gegeben ist, und/oder bei Netzwerken, bei denen einige Netzwerkverbindungen eine relativ geringe Bandbreite für die Datenübertragung aufweisen, unvorteilhaft.
Ausgehend hiervon liegt der Erfindung die Aufgabe zugrunde, ein alternatives und vorteilhaftes Verfahren zur Bearbeitung von patientenbezogenen Datensätzen anzugeben.
Diese Aufgabe wird erfindungsgemäß durch ein Verfahren mit den Merkmalen des Anspruchs 1 gelöst. Die rückbezogenen An- sprüche beinhalten teilweise vorteilhafte und teilweise für sich selbst erfinderische Weiterbildungen dieser Erfindung. Das Verfahren dient zur Bearbeitung von patientenbezogenen Datensätzen, die jeweils medizinische Daten und sensitive Pa¬ tientendaten als Klardaten umfassen. Im Rahmen des Verfahrens werden die sensitiven Patientendaten eines jeden patientenbe- zogenen Datensatzes anonymisiert, wodurch anonymisierte pati¬ entenbezogene Datensätze erzeugt werden. Weiter werden mit Hilfe eines Algorithmus aus den jeweiligen sensitiven Patientendaten eines jeden patientenbezogenen Datensatzes Prüfdaten generiert und in den jeweiligen patientenbezogenen Datensatz eingebunden. Nachfolgend werden die anonymisierten patientenbezogenen Datensätze mit den Prüfdaten in einer Cloud- Computing-Architektur zur Verfügung gestellt. Zudem werden an einem Client-Rechner, der an die Cloud-Computing-Architektur angebunden ist, im Rahmen einer Bearbeitung eines bestimmten patientenbezogenen Datensatzes sensitive Patientendaten eines ausgewählten Patienten vorgegeben und mit Hilfe des Algorithmus werden aus diesen vorgegebenen sensitiven Patientendaten Abfragedaten generiert. Stimmen die Abfragedaten des ausgewählten Patienten nicht mit den Prüfdaten des bestimmten pa- tientenbezogenen Datensatzes überein, so wird eine Siche¬ rungsfunktion ausgelöst. Der Ausdruck patientenbezogene Da¬ tensätze steht dabei insbesondere für Dateien nach dem DICOM- Standard (Digital Imaging and Communications in Medicine) und der Ausdruck sensitive Patientendaten umfasst vor allem soge- nannte „Protected Health Information" (PHI).
Es werden bei diesem Verfahren also nicht die kompletten patientenbezogenen Datensätze verschlüsselt, sondern es werden lediglich einzelne darin enthaltene Informationen, nämlich die sensitiven Patientendaten, verschleiert. Dies geschieht beispielsweise, indem die sensitiven Patientendaten, wie der Name des Patienten, dessen Geburtsdatum usw. auf eine Art und Weise verschlüsselt werden, bei der die entsprechenden Klardaten durch geeignete Platzhalter ersetzt werden. Infolgedes- sen lassen sich die patientenbezogenen Datensätze auch nach der Anonymisierung der sensitiven Patientendaten weiterverarbeiten, ohne dass die Anonymisierung der sensitiven Patientendaten zuvor rückgängig gemacht werden muss. Dementspre- chend können die anonymisierten patientenbezogenen Datensätze in der Cloud-Computing-Architektur zur Verfügung gestellt und in dieser gespeichert und/oder weiterverarbeitet werden, ohne dass die sensitiven Patientendaten innerhalb der Cloud- Computing-Architektur als Klardaten auftreten. Außerdem verbleiben die sensitiven Patientendaten, wenn auch anonymisiert, fest in den patientenbezogenen Datensätze eingebunden, so dass die beiden eingangs genannten und widersprüchlichen Forderungen bei diesem Verfahren erfüllt werden. Zugang zu den patientenbezogenen Datensätzen erhalten nur autorisierte Personen, insbesondere die vom jeweiligen Patienten ausgewählten Mediziner, denen die sensitiven Patientendaten als Klardaten bekannt sind und die Zugang zu einer Anwendung haben, mit deren Hilfe sie aus den Klardaten die anonymisierten sensitiven Patientendaten, also insbesondere die Platzhalter, an einem Client-Rechner generieren können. Über diesen
Client-Rechner, der an die Cloud-Computing-Architektur angebunden ist, erhalten sie dann Zugang zu den patientenbezogenen Datensätzen. Da hierbei lediglich ein Abgleich erfolgt, bei dem die am Client-Rechner generierten anonymisierten sensitiven Patientendaten mit den anonymisierten sensitiven Patientendaten in den anonymisierten patientenbezogenen Datensätzen verglichen werden, tauchen auch bei einem Zugriff auf die Cloud-Computing-Architektur die Klardaten in dieser nicht auf.
Zugunsten einer möglichst einfach gestalteten Datenverarbeitung, werden die anonymisierten sensitiven Patientendaten, also insbesondere die Platzhalter, zudem zur Bildung eines zusätzlichen sogenannten „Tags" herangezogen und das entsprechende „Tag" wird in den entsprechenden patientenbezogenen Datensatz eingebunden, um diesen quasi mit einer Kennzeichnung für eine Archivierung zu versehen. Unter „Tag" wird allgemein eine dem Datensatz hinzugefügte Zusatzinformation ver- standen.
In vorteilhafter Weiterbildung werden die sensitiven Patientendaten eines jeden patientenbezogenen Datensatzes zunächst in Schlüsseldaten und sonstige sensitive Patientendaten eingeteilt und nachfolgend werden alle sensitiven Patientendaten eines jeden patientenbezogenen Datensatzes anonymisiert, wo¬ durch anonymisierte patientenbezogene Datensätze erzeugt wer- den. Jedoch werden mit Hilfe des Algorithmus nur aus den je¬ weiligen Schlüsseldaten eines jeden patientenbezogenen Datensatzes Prüfdaten generiert und in den jeweiligen patientenbe¬ zogenen Datensatz eingebunden. Die anonymisierten patientenbezogenen Datensätze mit den Prüfdaten werden nachfolgend in der Cloud-Computing-Architektur zur Verfügung gestellt. Im
Rahmen einer Bearbeitung eines bestimmten patientenbezogenen Datensatzes werden an dem Client-Rechner, der an die Cloud- Computing-Architektur angebunden ist, Schlüsseldaten eines ausgewählten Patienten vorgegeben und mit Hilfe des Algorith- mus werden aus diesen vorgegebenen Schlüsseldaten Abfragedaten generiert. Stimmen diese Abfragedaten des ausgewählten Patienten nicht mit den Prüfdaten des bestimmten patientenbezogenen Datensatzes überein, so wird infolge dessen die Si¬ cherungsfunktion ausgelöst.
Diese Verfahrensvariante soll vor allem einen einfachen Um¬ gang mit der hier vorgestellten Lösung erlauben. Dabei gilt es zu bedenken, dass die sensitiven Patientendaten mitunter sehr große Informationsmengen enthalten können, während be- reits eine kleine Teilmenge in der Regel ausreichend ist, um den entsprechenden Patienten eindeutig zu identifizieren. Es ist also beispielsweise vorgesehen, dass ein Mediziner, der die medizinischen Daten seines Patienten abfragen möchte, von einer Anwendung auf seinem Rechner aufgefordert wird, den Na- men und das Geburtsdatum seines Patienten in ein Eingabefenster einzutragen und dass diese Daten dann als Schlüsseldaten fungieren. Sonstige sensitive Patientendaten, die häufig ebenfalls in den patientenbezogenen Datensätzen enthalten sind, wie beispielsweise das Geschlecht des Patienten, dessen Anschrift, dessen Krankenversicherungsnummer usw., müssen dem Mediziner weder bekannt sein noch muss dieser jene Informationen über ein Eingabefenster eingeben. Die sonstigen sensitiven Patientendaten spielen also insbesondere bei der Identi- fikation der patientenbezogenen Datensätze keine Rolle, werden aber ebenfalls anonymisiert, bevor die entsprechenden Da¬ tensätze in der Cloud-Computing-Architektur zur Verfügung gestellt werden.
Bevorzugt wird weiter eine Verfahrensvariante, bei der der Algorithmus durch eine Einweg-Hashfunktion, auch Hash- Algorithmus oder Streuwertfunktion genannt, gegeben ist. Zudem wird bevorzugt für die Anonymisierung der sensitiven Pa- tientendaten und für die Generierung der Prüfdaten derselbe Algorithmus, insbesondere dieselbe Einweg-Hashfunktion, ge¬ nutzt. Für die Kryptografie geeignete Einweg-Hashfunktionen sind dem Fachmann wohlbekannt, so dass sich ohne Weiteres ei¬ ne Einweg-Hashfunktion mit günstigen Eigenschaften finden lässt. Von Vorteil sind hierbei insbesondere Einweg-Hashfunk¬ tionen vom Typ MD5, SHA1 oder SHA2.
Zweckmäßig ist zudem eine Verfahrensvariante, bei der eine Anzahl der anonymisierten patientenbezogenen Datensätze mit den Prüfdaten aus der Cloud-Computing-Architektur Anzeigedaten zur Anzeige am Client-Rechner enthalten. Ebenso ist eine Verfahrensvariante zweckmäßig, bei der eine Anzahl der pati¬ entenbezogenen Datensätze Bilddaten einer bilderzeugenen Modalität enthalten und bei der aus den Bilddaten einer dieser patientenbezogenen Datensätze in der Cloud-Computing-Architektur Anzeigedaten zur Anzeige am Client-Rechner erzeugt werden. Das bedeutet, dass beispielsweise Bilddaten, die an einem Computertomographen im Rahmen einer Untersuchung eines Patienten erzeugt werden, ebenfalls jedem Mediziner zur Ver- fügung stehen, der über einen Rechner Zugriff auf die über die Cloud-Computing-Architektur zur Verfügung gestellten gesammelten medizinischen Unterlagen seines Patienten hat. Dabei ist es insbesondere vorgesehen, dass die Bearbeitung der Bilddaten mit Hilfe von leistungsstarken Ressourcen innerhalb der Cloud-Computing-Architektur vorgenommen wird und dass lediglich Anzeigedaten an den Client-Rechner, also den Rechner des Mediziners, gesendet werden, die dann ohne eine weitere Bearbeitung am Anzeigegerät, also beispielsweise einem Moni- tor, angezeigt werden. Es werden also quasi fertige Bilder zum Rechner des Mediziners geschickt, die dann lediglich bei ihm angezeigt werden. Die rechenintensive Aufbereitung der vom Computertomographen generierten Daten und insbesondere die Berechnung von 3D-Bildern erfolgt hingegen in der Cloud- Computing-Architektur . Der Datenumfang derartiger fertiger Bilder, die dann zum Rechner des Mediziners geschickt werden, ist zudem relativ gering. Während in der Cloud-Computing- Architektur beispielsweise ein sogenanntes „Volume Rendering" vorgenommen wird, also zum Beispiel eine Bearbeitung der vom Computertomographen generierten Daten des gesamten untersuchten Volumens des Patienten, wird an den Rechner des Mediziners lediglich ein fertiges Bild einer einzelnen von ihm ausgewählten Ansicht auf das Volumen oder einer einzelnen
Schnittdarstellung gesendet. Für eine Übertragung dieser Daten und somit für die Netzwerkanbindung des Rechners des Me¬ diziners ist daher eine relativ geringe Bandbreite ausrei¬ chend . Darüber hinaus wird eine Verfahrensvariante bevorzugt, bei der zunächst die Anzeigedaten und die Prüfdaten eines be¬ stimmten anonymisierten patientenbezogenen Datensatzes am Client-Rechner zur Verfügung gestellt werden, bei der nachfolgend diese Prüfdaten mit den Abfragedaten verglichen wer- den und bei der die Sicherungsfunktion ausgelöst wird, wenn die Prüfdaten mit den Abfragedaten nicht übereinstimmen. Der Abgleich der Daten oder der Prüfprozess erfolgt somit bevorzugt zur Gänze lokal am Client-Rechner. Dieser Prüfprozess wird dabei bevorzugt durch einen separate und damit von der Bearbeitung der anonymisierten patientenbezogenen Datensätze gänzlich getrennte Anwendung umgesetzt, so dass hierdurch die gewünschte strikte Trennung der anonymisierten patientenbezo¬ genen Datensätze von den Klardaten gewährleistet wird. Außerdem ist eine Verfahrensvariante von Vorteil, bei der die Prüfdaten in die Anzeigedaten grafisch und weiter bevorzugt nach Art eines 2D-Barcodes eingebunden werden. Wird also bei¬ spielsweise über die Cloud-Computing-Architektur ein Röntgen- Bild vom Patienten zur Verfügung gestellt, welches am Monitor des Rechners des Mediziners lediglich angezeigt wird, so be¬ findet sich beispielsweise in einem vorgegebenen Bereich des angezeigten Bildes, zum Beispiel in der rechten oberen Ecke, die Abbildung eines Strich-Codes oder eines QR-Codes, die die anonymisierten sensitiven Patientendaten und insbesondere die Schlüsseldaten repräsentiert. Ein in diesem Fall geeigneter Abfrageprozess , dieser ist Teil des Verfahrens, ist dann bei¬ spielsweise wie folgt gestaltet. Zunächst gibt der Mediziner den Namen und das Geburtsdatum seines Patienten in ein Eingabefenster ein, woraufhin mittels einer gegebenen Einweg-Hash- funktion auf der Basis des Namens und des Geburtsdatums ein QR-Code generiert wird. Zusätzlich wird mit Hilfe einer zwei¬ ten Einweg-Hashfunktion ein Zahlencode generiert. In der Cloud-Computing-Architektur wird daraufhin eine Datei aufgerufen, in der derselbe Zahlencode als „Tag" eingebunden ist. Die Bilddaten aus dieser Datei werden daraufhin bearbeitet, so dass hierdurch ein Satz Anzeigedaten generiert wird. Die Anzeigedaten werden dann an den Rechner des Mediziners gesen- det, wobei diese Anzeigedaten ebenfalls einen QR-Code enthal¬ ten. Daraufhin wird der Prüfprozess gestartet, bei dem der QR-Code aus der Anzeige und der am Rechner des Mediziners ge¬ nerierte QR-Code vorzugsweise auf Softwarebasis quasi optisch miteinander verglichen werden. Stimmen die beiden QR-Codes überein, so werden die Anzeigedaten als Bild am Monitor des Rechners des Mediziners angezeigt. Dieses Bild wird dann be¬ vorzugt im Bereich des angezeigten QR-Codes durch ein zweites Bild überlagert, in welchem die Klardaten, die durch den QR- Code repräsentiert werden, also der Name und das Geburtsdatum des Patienten, angezeigt werden. Der Mediziner sieht somit nicht ein Röntgenbild in dessen oberer rechter Ecke ein QR- Code abgebildet ist, sondern ein Röntgenbild, in dessen obe¬ rer rechter Ecke der Name und das Geburtsdatum des Patienten zu sehen und zu lesen sind. Stimmen die beiden QR-Codes hin- gegen nicht überein, so wird die Sicherungsfunktion ausgelöst und es wird beispielsweise eine Fehlermeldung angezeigt. Vorteilhaft ist zudem eine Verfahrensvariante, bei der eine Anzeige der Anzeigedaten unterbunden wird, wenn die Sicherungsfunktion ausgelöst wird. Stimmen also die Prüfdaten und die Abfragedaten nicht überein, so bekommt der Mediziner die Anzeigedaten nicht angezeigt und somit nicht zu sehen. Wird also beispielsweise ein Röntgenbild eines Patienten in der Cloud-Computing-Architektur quasi in einer Patientenakte eines anderen Patienten abgelegt und versucht nun ein Mediziner die medizinischen Unterlagen in dieser Patientenakte zu sich- ten, so wird dieser beim Versuch, sich das Röntgenbild anzu¬ sehen, eine Warnmeldung erhalten, dass das Röntgenbild kein Röntgenbild seines Patienten ist und das Röntgenbild wird nicht angezeigt. Ausführungsbeispiele der Erfindung werden nachfolgend anhand einer schematischen Zeichnung näher erläutert. Darin zeigen:
FIG 1 in einer Blockschaltbilddarstellung ein Verfahren zur Bearbeitung von patientenbezogenen Datensätzen.
Die nachfolgend exemplarisch beschriebene Verfahrensvariante erlaubt es ein Archiv für medizinische Daten außerhalb des untermittelbaren Kontrollbereichs einer medizinischen Einrichtung, hier einem Krankenhaus, anzusiedeln. Dieses Archiv ist dabei auf mehrere PACS-Server (Picture Archiving and Com- munication System) verteilt, die Teil einer Cloud-Computing- Architektur 2 sind.
Soll nun ein Patient beispielsweise mit Hilfe eines Computer- tomographen 4 im Krankenhaus untersucht werden, so werden im Vorfeld der Untersuchung während eines Eingabe-Prozessschrit¬ tes 6 zunächst einmal einige sensitive Patientendaten, wie beispielsweise der Name des Patienten und dessen Geburtsda¬ tum, in einem Speicher des Computertomographen 4 hinterlegt. Anschließend erfolgt die eigentliche Untersuchung des Patien¬ ten, bei der mittels des Computertomographen 4 während eines Scan-Prozessschrittes 8 Rohdaten generiert werden. Ist dieser Scan-Prozessschritt 8 abgeschlossen, so wird aus den Rohdaten ein patientenbezogener Datensatz erstellt, in welchen im Rahmen eines Einbettungs-Prozessschrittes 10 die sensitiven Pa¬ tientendaten, die im Eingabe-Prozessschritt 6 eingegeben wurden, eingebunden werden. Diese sensitiven Patientendaten wer- den darüber hinaus durch weitere sensitive Patientendaten ergänzt, welche die am Computertomographen 4 durchgeführte Un¬ tersuchung charakterisieren und eindeutig kennzeichnen. Dies sind beispielsweise Datum und Uhrzeit der Untersuchung, der Untersuchungsmodus, die Strahlungsdosis der der Patient aus- gesetzt war usw.. Dieser patientenbezogene Datensatz wird so¬ dann an eine Serverstation 12 innerhalb des unmittelbaren Kontrollbereichs des Krankenhauses übertragen.
In der Serverstation 12 werden die Rohdaten des patientenbe- zogenen Datensatzes weiterverarbeitet und während eines Bild- Prozessschrittes 14 in Bilddaten, genauer in sogenannte
Transversalschnitte, umgewandelt. Der so bearbeitete patien¬ tenbezogene Datensatz wird nachfolgend als Kopie in der Ser¬ verstation 12 hinterlegt und zusätzlich für eine Speicherung im Archiv für medizinische Daten außerhalb des unmittelbaren Kontrollbereichs des Krankenhauses, also in der Cloud- Computing-Architektur 2, aufbereitet.
Dazu wird in den patientenbezogenen Datensatz ein zusätzli- ches „Tag" zur Kennzeichnung eingebunden, welches eine Ziffernfolge oder Zeichenfolge als Prüfdaten enthält. Bei diesen Prüfdaten handelt es sich um anonymisierte Schlüsseldaten, wobei die Schlüsseldaten wiederum den patientenbezogenen Datensatz eindeutig dem Patienten zuordnen. Im Ausführungsbei- spiel werden im Rahmen eines Auswahl-Prozessschrittes 16 aus den sensitiven Patientendaten der Name des Patienten und dessen Geburtsdatum als Schlüsseldaten ausgewählt. Nachfolgend werden aus diesen Schlüsseldaten mittels einer Einweg-Hash- funktion die Prüfdaten, hier die Ziffern- oder Zeichenabfol- ge, generiert und mit Hilfe des zusätzlichen „Tags" zur Kenn¬ zeichnung des patientenbezogenen Datensatzes in diesen eingebunden. Zusätzlich werden in einem Anonymisierungs-Prozess- schritt 20 alle in dem patientenbezogenen Datensatz enthalte- nen sensitiven Patientendaten mit Hilfe derselben Einweg- Hashfunktion anonymisiert und durch Ziffern- oder Zeichenabfolgen als Platzhalter ersetzt. Darüber hinaus werden die Schlüsseldaten als Prüfdaten in Form eines QR-Codes in jeden Transversalschnitt eingebaut, so dass dieser QR-Code bei der Darstellung eines entsprechenden Transversalschnittes an ei¬ nem Monitor stets am rechten oberen Bildrand abgebildet wird. Der entsprechende QR-Code wird dabei mittels weiteren Hash- Algorithmus, eines 2D-Barcode-Hash-Algorithmus , aus den
Schlüsseldaten generiert.
Der auf diese Weise anonymisierte patientenbezogene Datensatz wird sodann aus dem unmittelbaren Kontrollbereich des Krankenhauses in die Cloud-Computing-Architektur 2 abgegeben und dort im Zuge eines Ablage-Prozessschrittes 22 im Archiv für medizinische Unterlagen gespeichert. Sofern dies der erste anonymisierte patientenbezogene Datensatz des Patienten ist wird zunächst im Archiv eine neue Patientenakte angelegt, welche durch die Prüfdaten, also die entsprechende Ziffern- oder Zeichenabfolge, gekennzeichnet ist. Anschließend wird der anonymisierte patientenbezogene Datensatz in die neu an¬ gelegte Patientenakte eingepflegt. Existiert bereits eine Pa¬ tientenakte mit den entsprechenden Prüfdaten, so entfällt das Anlegen einer neuen Patientenakte und der anonymisierte pati- entenbezogene Datensatz wird der Patientenakte mit den Prüf¬ daten des anonymisierten patientenbezogenen Datensatzes zugeordnet .
Wird nun ein Mediziner vom Patienten beauftragt, die am Com- putertomographen 4 im Krankenhaus vorgenommene Untersuchung diagnostisch auszuwerten, so hat dieser die Möglichkeit, über einen Clientrechner 24, der an die Cloud-Computing-Architektur 2 angebunden ist, auf das Archiv für medizinische Unterlagen zuzugreifen. Hierzu startet der Mediziner eine lokal am Clientrechner 24 zur Verfügung stehende Anwendung, durch die er aufgefordert wird, die Schlüsseldaten des Patienten, also dessen Name und dessen Geburtsdatum, in ein Eingabefenster am Clientrechner 24 einzugeben. Mit Hilfe derselben Einweg- Hashfunktion, mit der die sensitiven Patientendaten des patientenbezogenen Datensatzes in der Serverstation 12 des Krankenhauses anonymisiert wurden, werden im Rahmen eines Anfra¬ ge-Prozessschrittes 26 am Clientrechner 24 durch die Anwen- dung Abfragedaten, also wiederum eine Ziffern- oder Zeichenabfolge, generiert. Daraufhin wird im Archiv für medizinische Unterlagen in der Cloud-Computing-Architektur 2 nach Datensätzen gesucht, deren Prüfdaten mit den Abfragedaten übereinstimmen bzw. deren Ziffern- oder Zeichenabfolge mit der am Clientrechner 24 erzeugten Ziffern- oder Zeichenabfolge übereinstimmt. Werden entsprechende Datensätze gefunden, so wird der Mediziner aufgefordert aus einer Auswahl eine Art der Darstellung auszuwählen, also z.B. eine Schnittdarstellung mit speziell gewählter Schnittebene oder eine 3D-Darstellung einer gewählten Körperregion. Daraufhin wird der gefundene anonymisierte patientenbezogene Datensatz im Rahmen eines Be- arbeitungs-Prozessschrittes 28 in der Cloud-Computing- Architektur 2 aufbereitet, wodurch Anzeigedaten zur Anzeige an einem Monitor generiert werden. Bei einer solchen Aufbe- reitung handelt es sich beispielsweise um eine sogenannte multiplanare Reformatierung (MRT) , auch multiplanare Rekonstruktion genannt, bei der aus den Transversalschnitten
Schnittdarstellungen mit beliebig gewählter Schnittebene berechnet werden, um eine Bildverarbeitung nach dem MIP-Prinzip (Maximum Intensity Protection) oder auch um ein sogenanntes Raycasting-Verfahren. In jedem Fall wird der QR-Code, der in jedem Transversalschnitt enthalten ist, auch in die Anzeige¬ daten eingebettet. Die Anzeigedaten werden dann an den Clientrechner 24 übertragen und dort im Zuge eines Abgleich-Prozessschrittes 30 ge¬ gengeprüft. Zu diesem Zwecke werden die vom Mediziner am Clientrechner 24 eingegebenen Schlüsseldaten mit Hilfe des zuvor genannten 2D-Barcode-Hash-Algorithmus in einen QR-Code umgewandelt und der so generierte QR-Code wird mit dem QR- Code in den Anzeigedaten aus der Cloud-Computing-Architektur 2 verglichen. Stimmen die beiden QR-Codes nicht überein so wird eine Sicherungsfunktion ausgelöst, infolgedessen die An- zeigedaten vom Clientrechner 24 verworfen werden und infolgedessen am Monitor des Clientrechners 24 eine Fehlerbenachrichtigung erscheint, die den Mediziner darauf aufmerksam macht, dass die Anzeigedaten einem unbekannten Patienten zu- geordnet sind. Stimmen die QR-Codes hingegen überein so wer¬ den die Anzeigedaten im Rahmen eines Freigabe-Prozess¬ schrittes 32 freigegeben und als Bild am Monitor des Client¬ rechners 24 dargestellt. Mit Hilfe der vom Mediziner lokal am Clientrechner 24 gestarteten Anwendung wird außerdem im Rah- men eines Überlapp-Prozessschrittes 34 ein zusätzliches Bild erzeugt, welches über das auf den Anzeigedaten basierende Bild gelegt wird. Dadurch sieht der Mediziner am Monitor des Clientrechners 24 nicht das gewünschte Röntgenbild, in wel¬ chem oben rechts der QR-Code abgebildet wird, sondern das ge- wünschte Röntgenbild, in dem oben rechts die Schlüsseldaten als Klardaten abgebildet sind, also in dem oben rechts der Name und das Geburtsdatum des Patienten zu lesen sind.
Die Erfindung ist nicht auf das vorstehend beschriebene Aus- führungsbeispiel beschränkt. Vielmehr können auch andere Va¬ rianten der Erfindung von dem Fachmann hieraus abgeleitet werden, ohne den Gegenstand der Erfindung zu verlassen. Insbesondere sind ferner alle im Zusammenhang mit dem Ausführungsbeispiel beschriebenen Einzelmerkmale auch auf andere Weise miteinander kombinierbar, ohne den Gegenstand der Erfindung zu verlassen.

Claims

Patentansprüche
1. Verfahren zur Bearbeitung von patientenbezogenen Datensätzen, die jeweils medizinische Daten und sensitive Patien- tendaten als Klardaten umfassen,
bei dem die sensitiven Patientendaten eines jeden patientenbezogenen Datensatzes anonymisiert werden (20), wo¬ durch anonymisierte patientenbezogene Datensätze erzeugt werden,
- bei dem mit Hilfe eines Algorithmus aus den jeweiligen sensitiven Patientendaten eines jeden patientenbezogenen Datensatzes Prüfdaten generiert und in dem jeweiligen pa¬ tientenbezogenen Datensatz eingebunden werden (18), bei dem die anonymisierten patientenbezogenen Datensätze mit den Prüfdaten in einer Cloud-Computing-Architektur
(2) zur Verfügung gestellt werden (22),
bei dem an einem Clientrechner (24), der an die Cloud- Computing-Architektur (2) angebunden ist, im Rahmen einer Bearbeitung eines bestimmten patientenbezogenen Datensat- zes sensitive Patientendaten eines ausgewählten Patienten vorgegeben werden und bei dem mit Hilfe des Algorithmus aus diesen vorgegeben sensitiven Patientendaten Abfragedaten generiert werden (26) und
bei dem eine Sicherungsfunktion ausgelöst wird, wenn die Prüfdaten des bestimmten patientenbezogenen Datensatzes nicht mit den Abfragedaten des ausgewählten Patienten übereinstimmen .
2. Verfahren nach Anspruch 1,
- bei dem die sensitiven Patientendaten eines jeden patientenbezogenen Datensatzes in Schlüsseldaten und sonstige sensitive Patientendaten eingeteilt werden (16),
bei dem alle sensitiven Patientendaten eines jeden patientenbezogenen Datensatzes anonymisiert werden (20), wo- durch anonymisierte patientenbezogene Datensätze erzeugt werden,
bei dem jedoch mit Hilfe des Algorithmus nur aus den je¬ weiligen Schlüsseldaten eines jeden patientenbezogenen Datensatzes Prüfdaten generiert und in dem jeweiligen pa¬ tientenbezogenen Datensatz eingebunden werden (18), bei dem die anonymisierten patientenbezogenen Datensätze mit den Prüfdaten in einer Cloud-Computing-Architektur (2) zur Verfügung gestellt werden,
bei dem an einem Clientrechner (24), der an die Cloud- Computing-Architektur (2) angebunden ist, im Rahmen einer Bearbeitung eines bestimmten patientenbezogenen Datensatzes Schlüsseldaten eines ausgewählten Patienten vorgegeben werden und bei dem mit Hilfe des Algorithmus aus die¬ sen vorgegeben Schlüsseldaten Abfragedaten generiert werden (26) und
bei dem eine Sicherungsfunktion ausgelöst wird, wenn die Prüfdaten des bestimmten patientenbezogenen Datensatzes nicht mit den Abfragedaten des ausgewählten Patienten übereinstimmen .
3. Verfahren nach Anspruch 1 oder 2,
bei dem der Algorithmus durch eine Einweg-Hashfunktion gege- ben ist.
4. Verfahren nach einem der Ansprüche 1 bis 3,
bei dem eine Anzahl der anonymisierten patientenbezogenen Datensätze mit den Prüfdaten aus der Cloud-Computing- Architektur (2) Anzeigedaten zur Anzeige am Clientrechner (24) enthalten.
5. Verfahren nach einem der Ansprüche 1 bis 4,
bei dem eine Anzahl der patientenbezogenen Datensätze Bildda- ten einer bilderzeugenden Modalität (4) enthalten und bei dem aus den Bilddaten einer dieser patientenbezogenen Datensätze in der Cloud-Computing-Architektur (2) Anzeigedaten zur Anzeige am Clientrechner (24) erzeugt werden (28) .
6. Verfahren nach einem der Ansprüche 1 bis 3 und 4 oder 5, bei dem zunächst die Anzeigedaten und die Prüfdaten eines be¬ stimmten anonymisierten patientenbezogenen Datensatzes am Clientrechner (24) zur Verfügung gestellt werden, bei dem nachfolgend diese Prüfdaten mit den Abfragedaten verglichen werden (30) und bei dem die Sicherungsfunktion ausgelöst wird, wenn die Prüfdaten mit den Abfragedaten nicht übereinstimmen .
7. Verfahren nach einem der Ansprüche 1 bis 6 und 4 oder 5, bei dem die Prüfdaten in die Anzeigedaten graphisch eingebunden sind.
8. Verfahren nach Anspruch 7,
bei dem die Prüfdaten als 2D-Barcode in die Anzeigedaten eingebunden sind.
9. Verfahren nach einem der Ansprüche 1 bis 8 und 4 oder 5, bei dem eine Anzeige der Anzeigedaten unterbunden wird, wenn die Sicherungsfunktion ausgelöst wird.
EP12801524.5A 2012-02-22 2012-12-04 Verfahren zur bearbeitung von patientenbezogenen datensätzen Ceased EP2766863A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102012202701A DE102012202701A1 (de) 2012-02-22 2012-02-22 Verfahren zur Bearbeitung von patientenbezogenen Datensätzen
PCT/EP2012/074334 WO2013124014A1 (de) 2012-02-22 2012-12-04 Verfahren zur bearbeitung von patientenbezogenen datensätzen

Publications (1)

Publication Number Publication Date
EP2766863A1 true EP2766863A1 (de) 2014-08-20

Family

ID=47358146

Family Applications (1)

Application Number Title Priority Date Filing Date
EP12801524.5A Ceased EP2766863A1 (de) 2012-02-22 2012-12-04 Verfahren zur bearbeitung von patientenbezogenen datensätzen

Country Status (9)

Country Link
US (2) US20140372149A1 (de)
EP (1) EP2766863A1 (de)
JP (1) JP6038185B2 (de)
KR (1) KR101712969B1 (de)
CN (1) CN104137129A (de)
DE (1) DE102012202701A1 (de)
IN (1) IN2014CN04064A (de)
RU (1) RU2601199C2 (de)
WO (1) WO2013124014A1 (de)

Families Citing this family (21)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10037410B2 (en) * 2013-11-27 2018-07-31 General Electric Company Cloud-based clinical information systems and methods of use
US10331852B2 (en) 2014-01-17 2019-06-25 Arterys Inc. Medical imaging and efficient sharing of medical imaging information
US10117597B2 (en) * 2014-01-17 2018-11-06 Arterys Inc. Apparatus, methods and articles for four dimensional (4D) flow magnetic resonance imaging using coherency identification for magnetic resonance imaging flow data
DE102014106109A1 (de) * 2014-04-30 2015-11-05 Clinerion Ltd. Patientenrekrutierungssystem und Patientenrekrutierungsverfahren
DE102014106112A1 (de) * 2014-04-30 2015-11-05 Clinerion Ltd. Patientenrekrutierungssystem und Patientenrekrutierungsverfahren
KR101628276B1 (ko) * 2015-04-20 2016-06-08 주식회사 루닛 클라우드 기반 병리 분석 시스템 및 방법
US10242209B2 (en) * 2015-08-27 2019-03-26 International Business Machines Corporation Task scheduling on hybrid clouds using anonymization
DK3380982T3 (da) 2015-12-16 2019-07-22 Cbra Genomics S A Håndtering af genom forespørgsel
US20180189685A1 (en) * 2017-01-04 2018-07-05 GM Global Technology Operations LLC System and method to identify a vehicle fiducial marker
EP3410324B1 (de) * 2017-05-30 2019-05-08 Siemens Healthcare GmbH Bestimmen eines anonymisierten dosisberichtbildes
US11443837B2 (en) 2017-11-17 2022-09-13 International Business Machines Corporation Generation of test data for a data platform
US20200054220A1 (en) * 2018-08-14 2020-02-20 Ebm Technologies Incorporated Physiological Parameter Recording System and Method Thereof
US11087862B2 (en) 2018-11-21 2021-08-10 General Electric Company Clinical case creation and routing automation
PT115479B (pt) 2019-04-29 2021-09-15 Mediceus Dados De Saude Sa Sistema de computador e método de operação para gerir dados pessoais anonimizados
GB2585691B (en) 2019-07-11 2024-03-20 Cmr Surgical Ltd Anonymising robotic data
US20210043284A1 (en) * 2019-08-11 2021-02-11 HealthBlock, Inc. Deniable digital health diagnoses
RU2748052C1 (ru) * 2021-03-18 2021-05-19 Общество С Ограниченной Ответственностью "Джибукинг" Способ и система обмена медицинскими данными
KR102708638B1 (ko) * 2021-03-25 2024-09-24 주식회사 한컴위드 2차원 코드를 이용하여 환자의 진료 기록 정보의 저장 및 관리를 가능하게 하는 정보 관리 서버 및 그 동작 방법
KR102676569B1 (ko) 2021-05-17 2024-06-20 주식회사 코어라인소프트 의료 영상 분석 장치 및 방법, 의료 영상 시각화 장치 및 방법
EP4125094A1 (de) * 2021-07-29 2023-02-01 Siemens Healthcare GmbH Pseudonymisierte speicherung und wiederauffindung von medizinischen daten und informationen
US20230410982A1 (en) * 2022-05-18 2023-12-21 PacificMD Biotech, LLC Secure Storage, Access, And Display Of Medical Image Data

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2001018631A1 (en) * 1999-09-02 2001-03-15 Medical Data Services Gmbh Method for anonymizing data
US20100250271A1 (en) * 2009-03-30 2010-09-30 Zipnosis, Inc. Method and system for digital healthcare platform

Family Cites Families (31)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CA2336303A1 (en) * 1999-04-28 2000-11-02 Alean Kirnak Electronic medical record registry including data replication
US8380630B2 (en) * 2000-07-06 2013-02-19 David Paul Felsher Information record infrastructure, system and method
US7587368B2 (en) * 2000-07-06 2009-09-08 David Paul Felsher Information record infrastructure, system and method
JP2002149497A (ja) * 2000-11-14 2002-05-24 Ntt Advanced Technology Corp プライバシー情報保護システム及びその方法
US20020128860A1 (en) * 2001-01-04 2002-09-12 Leveque Joseph A. Collecting and managing clinical information
US20040078238A1 (en) * 2002-05-31 2004-04-22 Carson Thomas Anonymizing tool for medical data
DE10253676B4 (de) * 2002-11-18 2008-03-27 Siemens Ag Verfahren und Vorrichtung für die Fernübertragung sensibler Daten
JPWO2004084483A1 (ja) * 2003-03-20 2006-06-29 株式会社日本医療データセンター 情報管理システム
WO2005098736A2 (en) * 2004-03-26 2005-10-20 Convergence Ct System and method for controlling access and use of patient medical data records
JP2006043084A (ja) * 2004-08-04 2006-02-16 Hamamatsu Kagaku Gijutsu Kenkyu Shinkokai 医用フィルム印刷装置
US20060074983A1 (en) * 2004-09-30 2006-04-06 Jones Paul H Method of maintaining data confidentiality
JP2006198043A (ja) * 2005-01-19 2006-08-03 Toshiba Corp 医用画像診断システム、患者情報管理システム及び患者情報管理方法
US20110110568A1 (en) * 2005-04-08 2011-05-12 Gregory Vesper Web enabled medical image repository
US8037052B2 (en) * 2006-11-22 2011-10-11 General Electric Company Systems and methods for free text searching of electronic medical record data
US20080208624A1 (en) * 2007-02-22 2008-08-28 General Electric Company Methods and systems for providing clinical display and search of electronic medical record data from a variety of information systems
US10231077B2 (en) * 2007-07-03 2019-03-12 Eingot Llc Records access and management
JP5088201B2 (ja) * 2008-03-27 2012-12-05 日本電気株式会社 緊急時の該当者検索システム、その方法及びプログラム
CN101295332A (zh) * 2008-04-30 2008-10-29 深圳市蓝韵实业有限公司 一种dicom文件病人信息匿名化处理方法
US10096075B2 (en) * 2008-09-12 2018-10-09 Epic Systems Corporation Patient community system with anonymized electronic medical data
JP2010237811A (ja) * 2009-03-30 2010-10-21 Nec Corp 個人情報管理システム及び個人情報管理方法
KR20120008059A (ko) * 2009-04-20 2012-01-25 인비져니어 메디컬 테크놀로지스, 인코포레이티드 이미징 시스템
JP2010267041A (ja) * 2009-05-14 2010-11-25 Konica Minolta Medical & Graphic Inc 医療データ管理システム
US20110119089A1 (en) * 2009-11-19 2011-05-19 Carlisle Jeffrey A System and Method for Personal Electronic Medical Records
US20120070045A1 (en) * 2009-12-17 2012-03-22 Gregory Vesper Global medical imaging repository
RU98104U1 (ru) * 2010-01-27 2010-10-10 Государственное образовательное учреждение высшего профессионального образования "Московский государственный медико-стоматологический университет Федерального агентства по здравоохранению и социальному развитию" Распределенная автоматизированная система мониторинга здоровья
KR101022213B1 (ko) * 2010-01-29 2011-03-17 동국대학교 경주캠퍼스 산학협력단 멀티 프록시 재암호화 기반 의료데이터 공유 방법 및 장치
US20120136678A1 (en) * 2010-11-16 2012-05-31 Joseph Steinberg System of Managing Healthcare Information and its Communication and Centralized Searching of Non-Centralized Data to Allow for Patient Control, Choice, and Empowerment
JP2013134711A (ja) * 2011-12-27 2013-07-08 Nis Plus Co Ltd 医療クラウドシステム
US8682049B2 (en) * 2012-02-14 2014-03-25 Terarecon, Inc. Cloud-based medical image processing system with access control
US8553965B2 (en) * 2012-02-14 2013-10-08 TerraRecon, Inc. Cloud-based medical image processing system with anonymous data upload and download
JP5965728B2 (ja) * 2012-05-31 2016-08-10 株式会社医療情報技術研究所 カルテ情報地域共有システム

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2001018631A1 (en) * 1999-09-02 2001-03-15 Medical Data Services Gmbh Method for anonymizing data
US20100250271A1 (en) * 2009-03-30 2010-09-30 Zipnosis, Inc. Method and system for digital healthcare platform

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of WO2013124014A1 *

Also Published As

Publication number Publication date
US20140372149A1 (en) 2014-12-18
CN104137129A (zh) 2014-11-05
RU2601199C2 (ru) 2016-10-27
KR20140127350A (ko) 2014-11-03
JP2015515659A (ja) 2015-05-28
RU2014138065A (ru) 2016-04-10
JP6038185B2 (ja) 2016-12-07
KR101712969B1 (ko) 2017-03-07
DE102012202701A1 (de) 2013-08-22
US20190122753A1 (en) 2019-04-25
IN2014CN04064A (de) 2015-09-04
WO2013124014A1 (de) 2013-08-29

Similar Documents

Publication Publication Date Title
EP2766863A1 (de) Verfahren zur bearbeitung von patientenbezogenen datensätzen
EP2147388B1 (de) Computersystem und verfahren zur speicherung von daten
EP2759957B1 (de) Übertragungsmittel für sicherheitskritische medizinische Bildinhalte
DE112010001870T5 (de) Verfahren und system zum verwalten und anzeigen von medizinischen daten
DE102006000713A1 (de) Medizinisches Bildbetrachtungsmanagement- und Statussystem
DE102008020610A1 (de) Vorrichtungen und Verfahren zur Validierung klinischer Daten
DE102007020364A1 (de) Bereitstellen eines medizinischen Berichtes
DE102009018423B4 (de) Verfahren zur Ausgabe von medizinischen Dokumenten
DE102015201361A1 (de) Datensystem zum Identifizieren von Radiologiedatensätzen
DE102020212187A1 (de) Medizinisches Datenverwaltungssystem
DE102007012784B4 (de) Verfahren, etc. zum Datenaustausch zwischen medizinischen Geräten
DE102013202825A1 (de) Verfahren und System zur Darstellung medizinischer Inhalte
DE202019005316U1 (de) Computerprogramm und System zum Verwalten von auf einen Patienten bezogenen Medizindaten
DE102007021275A1 (de) Verfahren zur Übertragung und/oder zur Bereitstellung persönlicher elektronischer Daten eines Inhabers, insbesondere gesundheitsbezogener elektronischer Daten eines Patienten
EP3785159A1 (de) Verfahren zum zusammenführen von unterschiedlichen teildaten
DE19922793B4 (de) Medizinisches Gerätesystem
WO2016012040A1 (de) Verfahren und datenverarbeitungssystem zur datenerhebung für eine klinische studie
DE102007043730B3 (de) Pre-Fetching von Dünn- und Dickschichtbilddaten
EP2693352A1 (de) System zur Übertragung personenbezogener und nicht personenbezogener Daten (Data-Split)
DE102014202953A1 (de) Netzbasierte Kollaboration zum gesicherten Datenaustausch von Bilddatensätzen mit vertraulichen Anteilen
EP3433778A1 (de) Software mit steuerlogik zur sicheren übermittlung persönlicher daten über das internet von computern auf den server mit sicherer lagerung der daten auf servern
EP3792925A1 (de) Verfahren und vorrichtung zur datentechnischen kommunikation in einem netzwerk
WO2000030012A1 (de) Patientendatenfile-managementsystem mit zugriffsmöglichkeit durch den patienten
EP3176714B1 (de) Gesichertes teilen von medizinischen bildern
DE10307995B4 (de) Verfahren zum Signieren von Daten

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20140512

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

DAX Request for extension of the european patent (deleted)
RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: SIEMENS HEALTHCARE GMBH

17Q First examination report despatched

Effective date: 20160616

REG Reference to a national code

Ref country code: DE

Ref legal event code: R003

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION HAS BEEN REFUSED

18R Application refused

Effective date: 20191112