DE202012012534U1 - Zentrale Steuerung verteilter Organisationsstrukturen - Google Patents

Zentrale Steuerung verteilter Organisationsstrukturen Download PDF

Info

Publication number
DE202012012534U1
DE202012012534U1 DE202012012534U DE202012012534U DE202012012534U1 DE 202012012534 U1 DE202012012534 U1 DE 202012012534U1 DE 202012012534 U DE202012012534 U DE 202012012534U DE 202012012534 U DE202012012534 U DE 202012012534U DE 202012012534 U1 DE202012012534 U1 DE 202012012534U1
Authority
DE
Germany
Prior art keywords
control system
user
cord blood
umbilical cord
request
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.)
Expired - Lifetime
Application number
DE202012012534U
Other languages
English (en)
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.)
Pirche AG
Original Assignee
Cytolon AG
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 Cytolon AG filed Critical Cytolon AG
Publication of DE202012012534U1 publication Critical patent/DE202012012534U1/de
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/90—Details of database functions independent of the retrieved data types
    • G06F16/901—Indexing; Data structures therefor; Storage structures
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/90—Details of database functions independent of the retrieved data types
    • G06F16/95—Retrieval from the web
    • G06F16/951—Indexing; Web crawling techniques
    • 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/06—Resources, workflows, human or project management; Enterprise or organisation planning; Enterprise or organisation modelling
    • 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
    • G16H40/00—ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices
    • G16H40/20—ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices for the management or administration of healthcare resources or facilities, e.g. managing hospital staff or surgery rooms

Landscapes

  • Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Theoretical Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • Human Resources & Organizations (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Strategic Management (AREA)
  • Health & Medical Sciences (AREA)
  • Economics (AREA)
  • General Engineering & Computer Science (AREA)
  • Data Mining & Analysis (AREA)
  • Biomedical Technology (AREA)
  • Medical Informatics (AREA)
  • Game Theory and Decision Science (AREA)
  • Tourism & Hospitality (AREA)
  • Quality & Reliability (AREA)
  • Epidemiology (AREA)
  • General Health & Medical Sciences (AREA)
  • Educational Administration (AREA)
  • Primary Health Care (AREA)
  • Public Health (AREA)
  • Development Economics (AREA)
  • Operations Research (AREA)
  • Marketing (AREA)
  • Software Systems (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Medical Treatment And Welfare Office Work (AREA)

Abstract

Steuerungssystem für verteilte Organisationsstrukturen, umfassend mindestens eine Organisation, umfassend mindestens eine Organisationseinheit, wobei die Organisationseinheit fachliche Attribute besitzt und wobei die Organisationseinheiten Anbieter und/oder Abfrager sein können, mindestens zwei Nutzer, wobei die Nutzer mindestens einer Organisation zugewiesen sind, mindestens eine Rolle, wobei die Rolle mindestens einem Nutzer zugewiesen ist und wobei die Rolle die verfügbaren Funktionalitäten innerhalb der dem Nutzer zugewiesenen Organisation bestimmt, wobei die Organisation, welcher ein Nutzer zugewiesen ist, die Ansicht bestimmt, welche dem Nutzer angezeigt wird und wobei ein erster Nutzer einen Suchauftrag erstellen kann, welcher an Organisationen gesendet wird, die Anbieter-Organisationseinheiten umfassen und wobei der Nutzer anschließend eine Anfrage an eine Organisation stellen kann und wobei ein weiterer Nutzer, der der Organisation zugeordnet ist, an welche die Anfrage gestellt wurde, die Anfrage bearbeitet.

Description

  • Zusammenfassung
  • Die Erfindung betrifft ein Steuerungssystem für verteilte Organisationsstrukturen, umfassend eine oder mehrere Organisationen mit einer oder mehreren Organisationseinheiten, wobei Nutzer mindestens einer Organisation zugewiesen sind und wobei Rollen den Nutzern zugewiesen werden, wobei die Rollen die verfügbaren Funktionalitäten innerhalb der dem Nutzer zugewiesenen Organisation bestimmen. Außerdem betrifft die Erfindung die Verwendung des Steuerungssystem zur Identifikation von Inventaren aus lokal verfügbaren Datenbanksystemen und entfernten Datenbanksystemen, bevorzugt Nabelschnurblutdaten.
  • Stand der Technik
  • Im Stand der Technik sind Datenbanken und Organisationsstrukturen bekannt, mit denen Suchanfragen an Inventare bearbeitet werden können. Im medizinischen und pharmazeutischen Bereich geht es dabei meist um die Anfrage bezüglich bestimmter Medikamente oder beispielsweise Transplantate. Es handelt sich somit in der Regel um einen Verkaufsvorgang, der durch eine Suchanfrage nach bestimmten Kriterien eingeleitet wird. Nachteilig im Stand der Technik ist, dass die Struktur von Organisationen (zum Beispiel ein Register) nicht unterstützt wird. Somit stehen nur eingeschränkte Möglichkeiten zur Verfügung.
  • Es kommt vor, dass einzelne Nutzer beispielsweise für zwei Kliniken arbeiten oder in einer Nabelschnurblutdatenbank und einer Klinik. Bisher war es nicht möglich, diesen Nutzern einen zentralen Zugang zu dieser Organisationsstruktur mit nur einem Account zu ermöglichen.
  • Da sich immer mehr Kliniken zu Verbünden zusammenschließen oder auch Kliniken mit bestimmten Einrichtungen kooperieren, ist eine strenge Zuordnung eines Nutzers zu nur einer einzelnen Klinik oder Einrichtung nachteilig.
  • Es werden neue fachliche Datenstrukturen notwendig um die komplexen Organisationsstrukturen zu Unterstützen. Der Erfindung lag daher das Problem zu Grunde, dass ein Steuerungssystem bereitgestellt werden muss, welches die Nachteile des Standes der Technik nicht aufweist und verteilte Organisationsstrukturen vor allem in Bezug auf die Verwaltung von Nabelschnurblutdaten unterstützen kann.
  • Beschreibung:
  • Gelöst wird die Aufgabe durch die unabhängigen Ansprüche. Vorteilhafte Ausführungsformen finden sich in den abhängigen Ansprüchen.
  • In einer ersten bevorzugten Ausführungsform betrifft die Erfindung ein Steuerungssystem für verteilte Organisationsstrukturen, umfassend
    mindestens eine Organisation, umfassend mindestens eine Organisationseinheit,
    wobei die Organisationseinheit fachliche Attribute besitzt und
    wobei die Organisationseinheiten Anbieter und/oder Abfrager sein können,
    mindestens zwei Nutzer,
    wobei die Nutzer mindestens einer Organisation zugewiesen sind,
    mindestens eine Rolle,
    wobei die Rolle mindestens einem Nutzer zugewiesen ist und
    wobei die Rolle die verfügbaren Funktionalitäten innerhalb der dem Nutzer zugewiesenen Organisation bestimmt,
    wobei die Organisation, welcher ein Nutzer zugewiesen ist, die Ansicht bestimmt, welche dem Nutzer angezeigt wird und
    wobei ein erster Nutzer einen Suchauftrag erstellen kann, welcher an Organisationen gesendet wird, die Anbieter-Organisationseinheiten umfassen und
    wobei der Nutzer anschließend eine Anfrage an eine Organisation stellen kann und
    wobei ein weiterer Nutzer, der der Organisation zugeordnet ist, an welche die Anfrage gestellt wurde, die Anfrage bearbeitet.
  • Ein Vorteil der Erfindung ist, dass das Steuerungssystem für viele unterschiedliche Anwendungsgebiete und Plattformteilnehmer verwendet werden kann und direkt komplexere Organisationsstrukturen wie Register unterstützt. Das Steuerungssystem ermöglicht es vorteilhafterweise eine Vielzahl von angeschlossenen Organisationseinheiten zu kontrollieren.
  • Es ist bevorzugt, dass die Organisationseinheit ausgewählt aus der Gruppe umfassend Verbund, Klinik, Einrichtung und/oder Verwaltung. Dabei kann die Organisationseinheit bevorzugt verschiedene fachliche Ausprägungen annehmen:
    • 1. Verbund (auch Gruppen oder Group)
    • 2. Klinik (auch Clinic)
    • 3. Einrichtung (auch Facility)
    • 4. Verwaltung (auch Back Office)
  • Ein Verbund ist bevorzugt ein Verbund von mindestens zwei Kliniken, ein Verbund von mindestens zwei Einrichtungen oder ein Verbund aus mindestens einer Klinik und mindestens einer Einrichtung.
  • Besonders bevorzugt ist ein Verbund von Nabelschnurblutbanken und/oder Nabelschnurblutdatenbanken. Auch ein Verbund von einer oder mehrerer Klinik(en) und einer oder mehrerer Nabelschnurblutbank(en) ist bevorzugt.
  • Es ist nicht erfindungsgemäß vorgesehen, dass ein Verbund einen weiteren Verbund umfasst. Auch ist nicht vorgesehen, dass Klinik weitere Kliniken umfasst oder eine Nabelschnurblutdatenbank weitere Nabelschnurblutdatenbanken umfasst. Weiterhin kann eine Nabelschnurblutdatenbank keinen Verbund beinhalten.
  • Eine Organisation einer Organisationseinheit entsprechen, zum Beispiel wenn es sich bei der Organisationseinheit um eine eigenständige Klinik handelt. In einem solchen Fall ist die Klinik Organisationseinheit und Organisation zugleich.
  • Im Stand der Technik werden bisher ausschließlich Domänenmodelle verwendet, welche eine konsequente Trennung von der Anfrage-Seite und Datenbank-Seite vorsehen. Die ist nachteilig da es immer gängiger wird, dass sich zum einen unterschiedliche Einrichtungen zusammenschließen aber auch dass sich Einrichtungen mit zum Beispiel Kliniken zusammenschließen, sodass in den Verbünden die klassische Anfragerseite mit der Datenbank-Seite teilweise verschmilzt.
  • Es kann somit eine Organisationseinheit auch weitere Organisationseinheiten enthalten (zum Beispiel ein Verbund enthält eine Klinik). Es ist jedoch nicht möglich, dass eine Klinik einen Verbund enthält. Bevorzugt, kann nur ein Verbund weitere Organisationseinheiten enthalten.
  • Es ist bevorzugt, dass eine Einrichtung ausgewählt ist aus der Gruppe umfassend eine Nabelschnurblutbank, Nabelschnurblutdatenbank, eine Blutbank, eine Stammzellbank, ein Donor-Register, eine Gewebebank (auch Tissue-Bank) und/oder eine Organbank.
  • Es ist auch bevorzugt, dass eine Klinik eine oder mehrere Subklinik enthält.
  • Der konkreten Organisationseinheit (zum Beispiel einer Klinik) sind Nutzer zugewiesen. Ein Vorteil der Erfindung ist es, dass über den Verbund Nutzer auch mehreren Kliniken und/oder Nabelschnurblutdatenbank zugewiesen werden können. Diesen Nutzer wird durch die Erfindung ein zentraler Zugang der Organisation mit nur einem Account zu ermöglicht. Es ist bevorzugt, dass ein Nutzer der einem Verbund zugewiesen wurde keinen Kliniken/Nabelschnurblutdatenbanken außerhalb des Verbundes zugewiesen werden kann.
  • Ein weiterer Vorteil der Erfindung ist außerdem, dass die Plattform und/oder das System organisationsunabhängige Nutzer unterstützen. Das heißt ist nicht mehr wie im Stand der Technik notwendig, dass es spezifische ”SucheCenter-Nutzer” und ”Anbieter-Nutzer” gibt. Somit wird den Nutzern der Zugriff auf verschiedene Organisationseinheiten ermöglicht, wenn sie der Organisation zu dem diese Organisationseinheiten gehören zugeordnet sind.
  • Ein Nutzer wird dabei der Organisation oder Organisationseinheiten zugewiesen für die er zuständig beziehungsweise tätig ist. Es kann dabei Beschränkungen geben, sodass ein Nutzer auch nur einzelnen Organisationseinheiten innerhalb eines Verbundes zugewiesen werden kann. Die Zuordnung zu einem Verbund hat somit nicht die Zuordnung zu allen dem Verbund angehörigen Organisationseinheiten zur Folge, dies muss explizit geschehen. Hierdurch wird eine zusätzliche Sicherung eingebaut, welche vorteilhaft ist da es im personalisierten medizinischen Bereich um teilweise sehr sensible Daten geht, in die nicht jeder Nutzer automatisch Einblick bekommen soll.
  • Die Zuordnung zum Back-Office ist ebenfalls exklusiv, was bereits dadurch gewährleistet wird, dass das Back-Office eine eigene Organisationseinheit ist, welche bevorzugt mit keinen weiteren Organisationseinheiten zusammengeschlossen wird.
  • Der Nutzer erhält einen Account mit welchem er Zugriff auf die Organisationen oder Organisationseinheiten erhält, welchen er zugewiesen wurde.
  • Bevorzugt wird ein Nutzern einem Verbund, einer Klinik, einer Einrichtung oder einem Back-Office zugeordnet.
  • Der Nutzer kann hierbei nicht gleichzeitig einem Verbund und eigenständigen Organisationseinheiten zugewiesen sein.
  • Erfindungsgemäß ist vorgesehen, dass die verfügbaren Funktionen innerhalb der Organisationen und Organisationseinheiten über ein Rollenkonzept definiert sind. Das heißt die Zuordnung definiert nur den Zugriff auf die entsprechenden Organisationseinheiten nicht jedoch auf welche Daten konkret zugegriffen werden kann und welche Bearbeitung erfolgen kann. Dies ist wichtig um den Datenschutz zu ermöglichen und einen koordinierten Ablauf von Anfragen und deren Beantwortung zu gewährleisten.
  • Die Rolle ist bevorzugt ausgewählt aus der Gruppe umfassend Administrator, Manager, Supervisor, Koordinator.
  • Einem Nutzer werden Rollen zugewiesen, welche die verfügbare Funktionalität innerhalb der dem Nutzer zugewiesenen Organisationseinheit(en) definieren. Die Rollen sind hierbei bevorzugt hierarchisch aufgebaut das heißt eine Rolle beinhaltet immer die Berechtigungen der Rolle einer tieferen Ebene.
  • Bevorzugt gibt es folgende Rollenebenen, wobei die 1. Ebene die höchste Ebene darstellt:
    • 1. Administrator
    • 2. Manager
    • 3. Supervisor
    • 4. Koordinator
  • Die Rolle des Managers verfügt beispielsweise über die Funktionalität der Zustimmung zu Annahme-Prozessen.
  • Die Rolle des Supervisors erlaubt den Zugriff auf alle Daten der zugeordneten Organisationseinheiten sowie deren lesen, schreiben und/oder löschen.
  • Die Rolle des Koordinators (auch Coordinator) erlaubt den Zugriff auf eigene Daten der zugeordneten Organisationseinheiten sowie deren lesen, schreiben und/oder löschen.
  • Eine höhere Ebene beinhaltet immer die Funktionalitäten der darunter befindlichen Ebene.
  • Für einen Nabelschnurblutdatenbank-Nutzer ergeben sich beispielsweise folgende Rollen und Funktionen:
  • 1.1 Klinik-Administrator (inklusive alle Rechte der Rolle 2.1)
  • Der Klinik-Administrator hat Zugriff auf
    • – Verwaltung Kliniknutzer
    • – Patienten neu zuweisen
  • 1.2 Nabelschnurblutdatenbank-Administrator (inklusive alle Rechte der Rolle 2.2)
    • – Verwaltung Nabelschnurblutdatenbank-Nutzer
  • 1.3 BackOffice-Administrator
    • – Alles Systemweit
  • 1.4 BackOffice-Agent
  • Die Zugriffsrechte des BackOffice Agenten sind gegenüber dem Back Office-Administrator eingeschränkt. Der BackOffice Agent kann keine Patientendaten und Nabelschnurbluteinheiten beziehungsweise Daten hierzu verwalten.
  • 2.1 Klinik-Manager (inklusive alle Rechte der Rolle 3.1)
  • Die Rolle des Klinik-Managers erlaubt die Freigabe von zustimmungspflichtigen Anfragen beziehungsweise Requests.
  • 2.2 Nabelschnurblutdatenbank-Manager (inklusive alle Rechte der Rolle 3.2)
  • Die Rolle des Nabelschnurblutdatenbank-Managers erlaubt die Freigabe von zustimmungspflichtigen Anfragen beziehungsweise Requests.
  • 3.1 Klinik-Supervisor (inklusive alle Rechte der Rolle 4.1)
  • Der Klinik-Supervisor hat für zugeordnete Kliniken Zugriff auf Patientendaten, Nachrichten, Ärztedaten, Suchprofile und Klinikdaten
  • 3.2 Nabelschnurblutdatenbank-Supervisor (inklusive alle Rechte der Rolle 4.2)
  • Der Nabelschnurblutdatenbank-Supervisor hat für zugeordnete Nabelschnurblutdatenbanken Zugriff auf Daten von Nabelschnurbluteinheiten (CBUs), Nabelschnurblutdatenbank-Daten
  • 4.1 Klinik-Koordinator
  • Die Rolle des Klinik-Koordinators erlaubt für zugeordnete Kliniken Zugriff auf eigene, insbesondere selbst angelegte Patientendaten und Nachrichten zu diesen Patienten.
  • 4.2 Nabelschnurblutdatenbank-Koordinator
  • Die Rolle des Nabelschnurblutdatenbank-Koordinators erlaubt für zugeordnete Nabelschnurblutdatenbanken den Zugriff auf Nachrichten.
  • Durch das hierarchische Rollensystem ist es nicht mehr notwendig einem Nutzer eine beliebige Anzahl von Rollen zuzuweisen. Die Rollen sind abhängig von den Organisationseinheiten denen der Nutzer zugewiesen ist. Es ergeben sich folgende Rollenzuweisungen:
    • 1. Nutzer ist Klinik(en) + Nabelschnurblutdatenbank(en) zugewiesen und erhält eine Klinik-Rolle + Nabelschnurblutdatenbank-Rolle
    • 2. Nutzer ist Klinik(en) zugewiesen und erhält eine Klinik-Rolle
    • 3. Nutzer ist Nabelschnurblutdatenbank(en) zugewiesen und erhält eine Nabelschnurblutdatenbank-Rolle
    • 4. Nutzer ist BackOffice zugewiesen und erhält eine BackOffice-Rolle
  • Im Falle der Zuordnung eines Nutzers zu einem Verbund ist eine vereinfachte Zuweisung zu allen Organisationseinheiten des Verbundes vorzusehen. Dies kann bevorzugt sein, da dadurch beim Anlegen des Nutzers nicht viele einzelne Zuweisungen durchzuführen sind, was vor allem bei großen Verbünden einen hohen Aufwand bedeuten würde.
  • Alleinig BackOffice Nutzer sind berechtigt Organisationen und Organisationseinheiten anzulegen und Organisationsstrukturen anzupassen. Dies ist vorteilhaft, da das System weniger anfällig für Fehler ist, wenn nur ein beschränkter Kreis an Nutzern diese Zugriffe und Änderungsberechtigungen besitzt.
  • Das heißt nur Back Office Nutzer können Kliniken, Nabelschnurblutdatenbanken und Verbünde anlegen & löschen.
  • Es ist außerdem bevorzugt, dass der weitere Nutzer, der der Organisation zugeordnet ist, an welche die Anfrage gestellt wurde, die Anfrage bearbeitet, nämlich annimmt und dem Nutzer, der die Anfrage gestellt hat die Annahme angezeigt wird.
  • Es ist weiterhin bevorzugt, dass der weitere Nutzer, der der Organisation zugeordnet ist, an welche die Anfrage gestellt wurde, die Anfrage bearbeitet und ein Freigabeschritt aktiviert wird.
  • Erfindungsgemäß ist vorgesehen, dass das Steuerungssystem auch auf andere Organisationen neben einem Register angewendet werden kann. Es kann beispielsweise vorteilhaft sein, dass die Struktur, die bevorzugt ein Verfahren, ein System und/oder eine Vorrichtung umfasst, auf Pharmafirmen, staatliche Strukturen, Arzneimittel, die Verteilung/Verwaltung von Arzneimitteln oder Behandlungsmethoden angewendet wird und/oder eine Verknüpfung zwischen Arzt, Klinik, Kontrollinstrument und/oder Behörde herstellt, um beispielsweise Arzneimittel oder Behandlungsmethoden entsprechend zu verwalten und/oder zu verteilen. In diesem Zusammenhang kann die Erfindung insbesondere als Mittel für die personalisierte Medizin bezeichnet werden.
  • Die Erfindung wird im Folgenden anhand der Verwaltung von Nabelschnurblutpräparaten erläutert, jedoch ist die Erfindung nicht auf diese beschränkt.
  • Im Konkreten stellen derartige Organisationsstrukturen praktisch Gruppierungen von Kliniken und/oder Nabelschnurblutdatenbanken dar, darüber hinaus müssten aber auch weiterhin eigenständige Nabelschnurblutdatenbanken, wie auch eigenständige Kliniken (zuvor als Suche Center mit einer Klinik abgebildet) unterstützt werden.
  • Der Erfindung erlaubt durch eine Neustrukturierung der fachlichen Daten die Unterstützung von Verbünden zum Beispiel Registern und vereinfacht somit bisherige Systeme im Bereich der personalisierten Medizin.
  • Die Plattform, bevorzugt die Nabelschnurblutdaten-Plattform, unterstützt das Anlegen von Verbünden (zum Beispiel einem Register) von Kliniken und/oder Nabelschnurblutbanken (Nabelschnurblutdatenbanken) als Organisationseinheit. Hierdurch stehen den Nutzen neue und verbesserte Möglichkeiten für die Suche nach Daten oder die Abfrage von Inventaren zur Verfügung.
  • Außerdem ist bevorzugt, dass eigenständige Kliniken und eigenständige Einrichtungen als Organisationseinheit unterstützen werden. Das heißt es kann weiterhin auch bevorzugt Kliniken oder Einrichtungen geben, die keinem Verbund zugeordnet sind. Als eigenständige Klinik werden nur solche Kliniken bezeichnet, die keine Subkliniken enthalten.
  • Es ist besonders bevorzugt, dass das System und/oder die Plattform weiterhin eigenständige Nabelschnurblutbanken beziehungsweise Nabelschnurblutdatenbanken als Organisationseinheit unterstützen, das heißt solche Nabelschnurblutdatenbanken die keinem Verbund zugeordnet sind. Eine eigenständige Nabelschnurblutdatenbank kann keine weiteren Nabelschnurblutdatenbanken enthalten.
  • Ein Vorteil der Erfindung ist die Flexibilität des Systems, welche es erlaubt dieses jederzeit um weitere Organisationseinheiten zu erweitern. Zum Beispiel können Donor-Register oder Gewebedatenbanken als weitere Einrichtungen hinzugefügt werden und den Anwendungsbereich der Erfindung somit um ein Vielfaches erweitern. Diese neu hinzugefügten Einrichtungen können ebenfalls Teil eines Verbundes sein.
  • Auf der einen Seite existieren somit die Kliniken und/oder Verbünde mit Kliniken als ”Suchende” oder ”Anfragende” und auf der anderen Seite Einrichtungen und/oder Verbünde mit Einrichtungen, die Inventare, Präparaten und/oder Daten anbieten. Ganz bevorzugt ist dabei, dass eine Nabelschnurblutdatenbank die Einrichtung ist und diese Nabelschnurbluteinheiten (Cordbloodunits) als Präparaten umfassen beziehungsweise anbieten.
  • Erfindungsgemäß besitzen die Organisationseinheiten fachliche Attribute besitzen. Dabei gibt es solche Attribute, die alle Organisationseinheiten besitzen. Zu solchen Attributen zählen: Name, Beschreibung (Description), Adresse (Address), Kontaktperson (Contact Person), Rechnungsadresse (Billing Address), Kontaktperson Rechnung (Contact Person Billing), Logo.
  • Es ist bevorzugt, dass ein Verbund keine weiteren Attribute besitzt. Es ist weiterhin bevorzugt, dass eine Klinik und eine Einrichtung als zusätzliches Attribut eine Identifikation (ID) besitzen. Bevorzugt ist außerdem, dass Nabelschnurblutdatenbank neben einer Identifikation auch über eine Akkreditierungen verfügen.
  • Es ist bevorzugt, dass das Attribut ”Standardsprache” (Default Language) kein Attribut der Organisationseinheiten mehr ist. Im System und/oder Plattform der Erfindung wird die Standardsprache für den spezifischen Nutzer definiert. So wird verhindert, dass es zu Überschneidungen kommt, wenn ein Nutzer verschiedenen Organisationseinheiten zugewiesen wird.
  • Es kann weiterhin die folgenden Attribute geben ”Standard Duration for Reservations” und ”Number of Reservations”.
  • Es ist bevorzugt, dass die verfügbaren Ansichten (Views), den beschriebenen neuen fachlichen Datenstruktur Sorge tragen. Hierbei werden bevorzugt die folgenden Ansichten unterstützt:
    • 1. Gruppen (Group) Ansicht (für Verbünde welche Kliniken und Einrichtungen, bevorzugt Nabelschnurblutdatenbanken enthalten)
    • 2. Kliniken Ansicht (für Verbünde von Kliniken oder für eigenständige Kliniken)
    • 3. Nabelschnurblutdatenbank Ansicht (für Verbünde von Nabelschnurblutdatenbanken oder eigenständige Nabelschnurblutdatenbanken)
    • 4. BackOffice-Ansicht (für die Administration des Systems)
  • Dem Nutzer wird dann entsprechend seiner Zuordnung zu Organisationseinheiten oder Organisationen die jeweilige Ansicht angezeigt. Die verfügbaren Funktionalitäten in einer Ansicht sind wiederum von seinen Nutzerrollen abhängig.
  • Die dem Nutzer verfügbaren Ansichten, sowie deren Ausgestaltung (zum Beispiel untergeordnete Übersichten) sind also von den dem Nutzer zugeordneten Organisationen und Organisationseinheiten und deren Beschaffenheit (zum Beispiel Verbund enthält nur Kliniken) abhängig.
  • Die Sichtbarkeit der Funktionalitäten (beziehungsweise der Menüeinträge welche den Zugriff ermöglichen) ist von der Zuordnung des Nutzers zu den Organisationen oder den Organisationseinheiten und seinen Rollen abhängig.
  • Es ergeben sich somit folgende Fälle:
    • 1. Ein Nutzer ist einer oder mehreren Kliniken zugeordnet. Der Nutzer sieht nur die Klinik-Ansicht.
    • 2. Ein Nutzer ist einer oder mehreren Nabelschnurblutdatenbanken zugeordnet. Der Nutzer sieht daher nur die Nabelschnurblutdatenbank-Ansicht.
    • 3. Ein Nutzer ist einer oder mehreren Kliniken und einer oder mehreren Nabelschnurblutdatenbanken zugeordnet. Der Nutzer sieht die Gruppen Ansicht, welche einen Zugriff auf Klinik- sowie Nabelschnurblutdatenbank-Ansicht hat.
  • Der Top-Level-Menüpunkt wird dabei jeweils nicht angezeigt. Das heißt ”Gruppen Ansicht” und ”Back Office Ansicht” werden niemals als Menüpunkte angezeigt. ”Kliniken Ansicht” und ”Nabelschnurblutdatenbank Ansicht” werden nur angezeigt, wenn Klinik(en) und Nabelschnurblutdatenbank(en) in einem Verbund existieren.
  • Für die Funktionalitäten eines Verbundes welcher Kliniken und Einrichtungen, bevorzugt Nabelschnurblutdatenbanken, enthält ist eine Komponente beziehungsweise Ansicht notwendig, die Zugriff auf folgende Ansichten gewährt:
    • 1. Kliniken Ansicht
    • 2. Nabelschnurblutdatenbank Ansicht
    • 3. User Übersicht
    • 4. Präferenzen
  • Kliniken Ansicht:
  • Für die Funktionalitäten einer Klinik beziehungsweise mehrerer Kliniken eines Verbunds war eine Komponente beziehungsweise Ansicht wünschenswert die folgende Funktionalitäten erreichbar macht beziehungsweise zur Verfügung stellt:
    • 1. Patienten-Zugriff auf ”Patienten Übersicht”: Enthält Patientendaten einer eigenständigen Klinik beziehungsweise aller Kliniken des Verbundes
    • 2. Nachrichten-Zugriff auf ”Klinik Message Übersicht”: Enthält Nachrichten einer eigenständigen Klinik beziehungsweise aller Kliniken des Verbundes. Der Begriff „Nachrichten” wird im Sinne der Erfindung analog zu „messages” verwendet.
    • 3. Kliniken-Zugriff auf ”Kliniken Übersicht”: Enthält die Daten einer eigenständige Klinik beziehungsweise aller Kliniken des Verbundes
    • 4. Users-Zugriff auf ”Users Übersicht”: Enthält Nutzerdaten einer eigenständigen Klinik beziehungsweise aller Kliniken eines Verbundes. Diese Ansicht ist nur sichtbar, wenn der Verbund ausschließlich Kliniken enthält, sonst ist die Bestandteil der Verbundsicht.
    • 5. Präferenzen-Zugriff auf Präferenzen des aktuell eingeloggten Nutzers. Diese Ansicht ist nur sichtbar, wenn der Verbund ausschließlich Kliniken enthält, sonst ist die Bestandteil der ”Gruppen Ansicht”.
  • Die in den aufrufbaren Übersichten dargestellten Daten (Patienten, Nachrichten, Kliniken) werden dabei durch die Zuordnung des Nutzers zu einer beziehungsweise mehreren Kliniken sowie der Rolle des Nutzers eingeschränkt. Somit kann sehr individuell bestimmt werden, welche Daten ein Nutzer abrufen beziehungsweise bearbeiten kann.
  • Für die Funktionalitäten einer Nabelschnurblutdatenbank beziehungsweise mehrerer Nabelschnurblutdatenbanken eines Verbunds ist eine Komponente beziehungsweise Ansicht notwendig die folgende Funktionalitäten erreichbar macht beziehungsweise zur Verfügung stellt:
    • 1. Nachrichten-Zugriff auf ”Nabelschnurblutdatenbank Nachrichten-Übersicht”: Enthält Nachrichten einer eigenständigen Nabelschnurblutdatenbank beziehungsweise aller Nabelschnurblutdatenbank des Verbundes.
    • 2. Nabelschnurbluteinheiten (CBU) Management-Zugriff auf ”CBU Übersicht”: Enthält CBUs einer eigenständigen Nabelschnurblutdatenbank beziehungsweise aller Nabelschnurblutdatenbank des Verbundes.
    • 3. Nabelschnurblutdatenbanken-Zugriff auf ”Nabelschnurblutdatenbank Übersicht”: Enthält eine eigenständige Nabelschnurblutdatenbank beziehungsweise alle Nabelschnurblutdatenbanken des Verbundes.
    • 4. Users-Zugriff auf ”Users Übersicht”: Enthält Nutzerdaten einer eigenständigen Nabelschnurblutdatenbank beziehungsweise aller Nabelschnurblutdatenbanken eines Verbundes. Diese Ansicht ist nur sichtbar wenn Verbund ausschließlich Nabelschnurblutdatenbanken enthält, sonst ist dies Bestandteil der Verbundsicht.
    • 5. Präferenzen-Zugriff auf Präferenzen des aktuell eingeloggten Nutzers, wobei die Ansicht nur sichtbar ist, wenn der Verbund ausschließlich Nabelschnurblutdatenbanken enthält, sonst ist diese Ansicht Bestandteil der ”Gruppen Ansicht”.
  • Auch hier werden die in den aufrufbaren Übersichten dargestellten Daten (Nachrichten, CBUs, Nabelschnurblutdatenbanken) durch die Zuordnung des Nutzers zu einer beziehungsweise mehreren Nabelschnurblutdatenbanken sowie der Rolle des Nutzers eingeschränkt.
  • Back-Office-Ansicht:
  • Für die Funktionalitäten des Back Office war eine Komponente beziehungsweise Ansicht bevorzugt, die folgende Funktionalitäten erreichbar macht beziehungsweise zur Verfügung stellt:
    • 1. Nachrichten-Zugriff auf ”BackOffice Message Übersicht”
    • 2. Organisations-Zugriff auf ”Organisations-Ansicht”: Enthält alle Organisationen und Organisationseinheiten (zum Beispiel Verbünde, eigenständige Kliniken, eigenständige Nabelschnurblutdatenbanken)
    • 3. Users-Zugriff auf ”Users Übersicht”
    • 4. Präferenzen
  • Die Organisations-Übersicht ist nur für BackOffice Nutzer zugänglich und stellt tabellarisch alle in der Plattform beziehungsweise dem System angelegten Organisationen dar und bietet zudem die Funktionalität zum Erstellen aller verfügbaren Organisationen und Organisationseinheiten und deren Nutzer sowie zugehörige Daten (siehe ).
  • Die Organisations-Übersicht ist hierbei hierarchisch entsprechend der in der Plattform beziehungsweise dem System verfügbaren Strukturen aufgebaut. Das heißt auf oberster Ebene sind zum Beispiel nur eigenständige Kliniken, Nabelschnurblutdatenbank und Verbünde sichtbar. Auch das Anlegen ist hier auf diese Organisationstypen beschränkt. Für das strukturelle Bearbeiten eines Verbunden wird entsprechend eine Ebene tiefer navigiert. Hier können dann die Einheiten und Nutzer des Verbundes angelegt beziehungsweise bearbeitet werden.
  • Somit bildet die Organisations-Ansicht direkt die verfügbare fachliche Struktur der Organisationen ab.
  • Organisations-Übersicht
  • Die Organisations-Übersicht stellt tabellarisch und hierarchisch die Organisationen, sowie deren Daten dar und erlaubt Zugriff auf folgende Funktionen:
  • 1. Dargestellte Daten
    • Identifikation, Name, Typ (Klinik, Nabelschnurblutdatenbank, Gruppen), Land (analog zu ”country”)
  • 2. Zugriff auf Funktionalitäten
  • 2.1 (generell)
    • – Erstelle (analog zu „create”) Klinik (Anlegen von eigenständigen Kliniken)
    • – Erstelle Nabelschnurblutdatenbank (Anlegen von eigenständigen Nabelschnurblutdatenbanken)
    • – Erstelle Gruppen (Anlegen von Gruppens (Verbünden))
  • 2.2 (pro Organisation – über Managespalte der Tabelle)
    • – Editieren („master data”)
    • – Users (Zugriff auf ”Users Übersicht”
    • – Kliniken [nur bei Typ ”Gruppen”] (Zugriff auf ”Kliniken Übersicht”
    • – Nabelschnurblutdatenbanken [nur bei Typ ”Gruppen”] (Zugriff auf ”Nabelschnurblutdatenbank Übersicht”
    • – CBU [nur bei Typ ”Nabelschnurblutdatenbank”] (Zugriff auf bisherige Funktionalität)
    • – Arzt (analog zu „Physicians”) [nur bei Typ ”Klinik”] (Zugriff auf bisherige Funktionalität)
    • – Such Profile [nur bei Typ ”Klinik”] (Zugriff auf bisherige Funktionalität)
  • In der Organisations-Übersicht werden somit nur eigenständige Kliniken, sowie Nabelschnurblutdatenbanken und Verbünde (Gruppen) dargestellt. Um ein Verbund weiter zu strukturieren, wird zum konkreten Verbund navigiert und hier auf die ”Kliniken Übersicht” sowie ”Nabelschnurblutdatenbank Übersicht” zugegriffen. Dort wiederum ist dann das Anlegen derer im direkten Kontext des Verbundes möglich auch die Zuweisung erfolgt somit implizit.
  • Das Back Office stellt zwar fachlich auch eine Organisationseinheit, es stellt aber eine besondere Organisationseinheit dar, dass es keine Eigenschaften oder ähnliches besitzt. Das Anlegen von Nutzern für das Back Office geschieht über den direkten Zugriff aus der Back Office Ansicht heraus.
  • Bei der Kliniken-Übersicht können vorteilhafterweise Kliniken, sowie die einer Klinik zugeordneten Daten dargestellt werden. Hierbei spielt es keine Rolle ob es sich um eine eigenständige Klinik, Kliniken in ”Klinik exklusiven” oder ”gemischten” Verbünden handelt. Die Kliniken Übersicht stellt immer die entsprechende(n) Klinik(en) tabellarisch dar. Lediglich im Falle eines BackOffice Nutzers muss zusätzlich die Funktionalität zum Anlegen einer Klinik für den entsprechenden Verbund, von dem aus man in die Kliniken Übersicht navigiert ist, verfügbar sein.
  • Die Kliniken Übersicht stellt tabellarisch kontextabhängig die Kliniken, sowie deren Daten dar und erlaubt Zugriff auf folgende Funktionen:
  • 1. Dargestellt Daten
    • Identifikation, Name, Stadt, Kontakt Person
  • 2. Zugriff auf Funktionalitäten
    • Editieren („master data”), Arzt „Physicians”, Such Profile, Erstelle Klinik (Nur im Back Office sichtbar).
  • 3. Kontextabhängige Darstellungen:
  • 3.1 Zugriff über die ”Organisations-Ansicht” oder ”Kliniken-Ansicht”
    • – Darstellung aller Kliniken des entsprechenden Verbundes
  • 3.2 Zugriff über Kliniken Ansicht (eigenständige Klinik)
    • – Darstellung der konkreten Klinik
  • Die Darstellung der Kliniken ist darüber hinaus durch die Zuordnung des Nutzers eingeschränkt. Das heißt, der Nutzer sieht nur die Kliniken, denen er zugeordnet ist. Ein BackOffice Nutzer unterliegt diesen Einschränkungen nicht.
  • Die Nabelschnurblutdatenbank Übersicht dient insbesondere zur Darstellung von Nabelschnurblutdatenbanken, sowie der Bearbeitung der der Nabelschnurblutdatenbank zugeordneten Daten. Hierbei spielt es keine Rolle ob es sich um eine eigenständige Nabelschnurblutdatenbank, Nabelschnurblutdatenbanken in Nabelschnurblutdatenbankexklusiven oder gemischten Verbünden handelt. Die Nabelschnurblutdatenbank Übersicht stellt immer die entsprechende(n) Nabelschnurblutdatenbank(en) tabellarisch dar. Lediglich im Falle eines BackOffice Nutzers muss zusätzlich die Funktionalität zum Anlegen einer Nabelschnurblutdatenbank für den entsprechenden Verbund, von dem aus man in die Nabelschnurblutdatenbank Übersicht navigiert ist, verfügbar sein.
  • Die Nabelschnurblutdatenbank Übersicht stellt tabellarisch kontextabhängig die Nabelschnurblutdatenbanken, sowie deren Daten dar und erlaubt Zugriff auf folgende Funktionen:
  • 1. Dargestellte Daten
    • Identifikation, Name, Land, Kontakt Person, Telefonnummer, E-Mail-Adresse
  • 2. Zugriff auf Funktionalitäten
    • Editieren (master data), ”Manage” CBU, Erstelle Nabelschnurblutdatenbank (Nur im Back Office sichtbar).
  • 3. Kontextabhängige Darstellungen:
  • 3.1 Zugriff über die ”Organisations-Ansicht” oder ”Nabelschnurblutdatenbank Ansicht” (Verbund der Nabelschnurblutdatenbanken enthält)
    • – Darstellung aller Nabelschnurblutdatenbanken des entsprechenden Verbundes
  • 3.2 Zugriff über Nabelschnurblutdatenbank Ansicht (eigenständige Nabelschnurblutdatenbank)
    • – Darstellung der konkreten Nabelschnurblutdatenbank
  • Die Darstellung der Nabelschnurblutdatenbanken ist darüber hinaus durch die Zuordnung des Nutzers eingeschränkt. Das heißt der Nutzer sieht nur die Nabelschnurblutdatenbanken denen er zugeordnet ist. Ein BackOffice Nutzer unterliegt diesen Einschränkungen nicht.
  • Die Users Übersicht dient zur Darstellung der Nutzerdaten, sowie zum Anlegen beziehungsweise Bearbeiten dieser. Auch die Users Übersicht ist flexibel und entsprechend des Navigationspfades beziehungsweise der Organisation die Nutzer tabellarisch dargestellt.
  • Die Users Übersicht stellt tabellarisch kontextabhängig die Nutzer, sowie deren Daten dar und erlaubt Zugriff auf folgende Funktionen:
  • 1. Dargestellt Daten
    • E-Mail-Adresse, Nachname, Vorname, Rolle (engl. Role), Zugehörigkeit zu einer Organisation (engl.: Assignments (to Organization(s))), Letzte Anmeldung (engl.: Last Login)
  • 2. Zugriff auf Funktionalitäten
    • Editieren (User), Erstelle (Zugriff auf Erstelle/Editieren Users Ansicht), Zeige Patienten, Neuzuweisung (engl: Reassign) Patienten
  • 3. Kontextabhängige Darstellungen:
  • 3.1 Zugriff über die Gruppen Ansicht (Verbund mit Klinken und Nabelschnurblutdatenbanken)
    • – Darstellung aller Nutzer des entsprechenden Verbundes
  • 3.2 Zugriff über Kliniken Ansicht (Verbund enthält ausschließlich Kliniken)
    • – Darstellung aller Nutzer der Kliniken des Verbundes
  • 3.3 Zugriff über Kliniken Ansicht (eigenständige Klinik)
    • – Darstellung aller Nutzer der konkreten Klinik
  • 3.4 Zugriff über Nabelschnurblutdatenbank Ansicht (Verbund enthält ausschließlich Nabelschnurblutdatenbank)
    • – Darstellung aller Nutzer der Nabelschnurblutdatenbanken des Verbundes
  • 3.5 Zugriff über Nabelschnurblutdatenbank Ansicht (eigenständige Nabelschnurblutdatenbank)
    • – Darstellung aller Nutzer der konkreten Nabelschnurblutdatenbank
  • 3.6 Zugriff über Back Office Ansicht
    • – Darstellung aller Nutzer des Back Office
  • Der Zugriff auf die Users Übersicht ist nur Nutzern mit Administratorrollen beziehungsweise BackOffice Nutzern gestattet.
  • Das System umfasst außerdem eine Erstelle/Editieren User Ansicht, welche die folgenden Funktionalitäten bietet:
  • Funktionalitäten der bisherigen Erstelle/Editieren User Ansicht:
    • 1. Darstellung der Felder der Nutzerstammdaten
    • 2. Darstellung der Nutzeroptionen (der Zeit: ”default language” und ”show deleted object”)
  • Durch die Erfindung wurden vor allem die folgenden Funktionalitäten eingeführt:
    • 1. Zuweisung der Nutzerrollen
    • 2. Zuweisung zu konkreten Organisationen (im Falle eines Verbundes)
  • Hierbei wird der Nutzer immer in dem Kontext in dem man die Erstelle Funktion aufgerufen hat angelegt und implizit zugewiesen. Das heißt im Kontext einer eigenständigen Klinik, wird der Nutzer automatisch dieser Klinik zugewiesen. Ist man im Kontext eines Verbundes erfolgt die Zuweisung zum Verbund. Die detaillierte Zuweisung zu Organisationen des Verbundes erfolgt wie oben beschrieben. Ist man im Kontext des Back Office, wird der Nutzer dem Back Office zugewiesen.
  • Die Darstellung der Rollen muss angepasst werden, da es keine spezifischen Nutzer (SucheCenter User/Nabelschnurblutdatenbank User) mehr gibt.
  • Die Rollen werden bevorzugt gruppiert dargestellt:
    Gruppe 1 – Back Office Rollen
    Gruppe 2 – Klinik-Rollen
    Gruppe 3 – Nabelschnurblutdatenbank-Rollen
  • Es ist dabei bevorzugt, dass pro Gruppe kann nur eine Rolle gewählt werden und dass die Menge der verfügbaren Rollen von der Zuordnung zu Organisationseinheiten abhängig ist. Außerdem ist bevorzugt, dass die Back Office Rollen exklusiv sind, hier ist eine weitere Zuordnung zu Klinik und/oder Nabelschnurblutdatenbank Rollen nicht notwendig
  • Zuweisung zu Organisationen eines Verbundes:
  • Handelt es sich bei dem anzulegenden/angelegten Nutzer um einen ”Verbundnutzer”, das heißt der Nutzer wurde im Kontext eines Verbundes (Gruppen) angelegt, ist es möglich in der Erstelle/Editieren User Ansicht die Zuweisung zu den Organisationen (Klink(en) und/oder (Nabelschnurblutdatenbanken)) vorzunehmen.
  • Eine Ansicht der verfügbaren Organisationen und der bereits erfolgten Zuweisungen ist hier notwendig. Auch ist es möglich einem Nutzer alle verfügbaren Organisationen des Verbundes mit gleichzeitig zuzuweisen.
  • Ein ”Klinik Administrator” beziehungsweise ”Nabelschnurblutdatenbank Administrator” welcher einem Verbund angehört, kann vorteilhafterweise Nutzer die er anlegt nur Organisationen zuweisen, welchen er selbst zugeordnet ist.
  • Weiterhin kann solch ein Administrator keine BackOffice Rollen vergeben. Dies können nur BackOffice Administratoren.
  • Wird für einen Nutzer die Zuweisung zu Organisationen eines Typs (zum Beispiel Nabelschnurblutdatenbanken) eines Verbundes (Gruppen) aufgehoben ist ein robustes Verhalten für den Umgang mit den vergebenen Rollen (zum Beispiel ”Nabelschnurblutdatenbank Supervisor”) zu definieren. Es ist bevorzugt, dass die Rollen mit entfernt, um ein unvorhersehbares Verhalten zu verhindern. Somit wird das System sicherer und besser zu kontrollieren.
  • Die Erstelle und Editieren Gruppen Ansicht wird aus der Organisation Übersicht geöffnet und ermöglicht die Darstellung und Bearbeitung der Felder der Stammdaten eines Verbundes (Gruppen).
  • Die Patient Übersicht stellt alle Patientendaten tabellarisch und kontextabhängig dar.
    • 1. Alle Patienten einer eigenständigen Klinik
    • 2. Patienten aller Kliniken eines Verbundes
  • Darüber hinaus ist die Darstellung der Patienten von der Zuordnung eines Nutzers zu Organisationseinheiten (Kliniken) und seiner Rolle abhängig. Ein Nutzer kann prinzipiell nur die Patienten von den Kliniken sehen, welchen er zugeordnet ist. Im Falle eines ”Klinik Koordinators” sind sogar nur die selbst angelegten Patienten sichtbar.
  • Die Klinik welcher ein Patient zugeordnet ist, ist in der ”Patienten Übersicht” ersichtlich (neue Spalte). Dies ist notwendig um nach Patienten einer Klinik filtern zu können.
  • Beim Anlegen des Patienten muss der Nutzer entsprechend seiner Zuordnung zu einer Klinik beziehungsweise zu mehreren Kliniken die Möglichkeit haben auszuwählen welcher Klinik er den Patienten zuordnen will. Bisher standen hier immer die Klinken des Suche Zentrums dem der Nutzer zugeordnet war zur Auswahl.
  • Ist der Nutzer nur einer Klinik zugewiesen, ist diese direkt vorausgewählt.
  • Beim Anlegen von CBUs hat der Nutzer entsprechend seiner Zuordnung zu einer Nabelschnurblutdatenbank beziehungsweise zu mehreren Nabelschnurblutdatenbanken die Möglichkeit, auszuwählen welcher Nabelschnurblutdatenbank er die CBU zuordnen will. Bisher war hier die Zuordnung im Kontext der Nabelschnurblutdatenbank immer eindeutig. Nun ist es vorteilhafterweise möglich, diese gezielt zuzuordnen.
  • Da die Möglichkeit besteht, dass ein Nutzer verschiedenen Nabelschnurblutdatenbanken zugewiesen ist, ist es notwendig, beim Import über die Schnittstelle die Nabelschnurblutdatenbank-ID anzugeben, für welche die CBUs importiert werden sollen. Im Stand der Technik war die Zuordnung im Kontext des Nutzers immer eindeutig, weshalb diese Eigenschaft erst durch die Erfindung nötig wird. Durch die gezielte Auswahl sind, können Ablaufe optimiert werden und an bestimmte Gegebenheiten angepasst werden.
  • Es ist bevorzugt, dass aus Gründen der Abwärtskompatibilität für die bisherigen Nabelschnurblutdatenbanken einen Import auch ohne Angabe der Nabelschnurblutdatenbank-ID weiterhin zu möglich ist. Da die bisherigen Nabelschnurblutdatenbanken immer eigenständige Nabelschnurblutdatenbank sind, kann hier von der Plattform die Nabelschnurblutdatenbank-ID ermittelt werden. Da der Nutzer genau einer Bank zugeordnet ist.
  • Sobald der Nutzer mehr als einer Bank zugeordnet ist, ist ein Import ohne Nabelschnurblutdatenbank-ID nicht mehr möglich.
  • Die Nabelschnurblutdatenbank welcher eine CBU zugeordnet ist muss in der ”CBU Übersicht” ersichtlich sein Dies ist notwendig um nach CBUs einer Nabelschnurblutdatenbank filtern zu können.
  • Die Klinik Nachricht (engl.: message) Übersicht stellt alle Nachrichten tabellarisch und kontextabhängig dar.
    • 1. Alle Nachrichten einer eigenständigen Klinik
    • 2. Nachrichten aller Kliniken eines Verbundes
  • Darüber hinaus ist die Darstellung der Nachrichten von der Zuordnung eines Nutzers zu Organisationseinheiten (Kliniken) und seiner Rolle abhängig. Ein Nutzer kann prinzipiell nur die Nachrichten von Patienten von den Kliniken sehen, welchen er zugeordnet ist. Im Falle eines ”Klinik Koordinators” sind sogar nur Nachrichten von selbst angelegten Patienten sichtbar. Ein Nutzer sieht bevorzugt nur Nachrichten von Patienten auf deren Daten er Zugriff hat.
  • Die Klinik welcher eine Nachricht zugeordnet ist, ist in der ”Klinik Nachrichten-Übersicht” ersichtlich. Dies ist vorteilhaft, das so nach Nachrichten einer Klinik gefiltert werden kann.
  • Die Nabelschnurblutdatenbank Message Übersicht stellt alle Nachrichten tabellarisch und kontextabhängig dar.
    • 1. Alle Nachrichten einer eigenständigen Nabelschnurblutdatenbank
    • 2. Nachrichten aller Nabelschnurblutdatenbanken eines Verbundes
  • Darüber hinaus ist die Darstellung der Nachrichten von der Zuordnung eines Nutzers zu Organisationseinheiten (Nabelschnurblutdatenbanken). Ein Nutzer kann prinzipiell nur die Nachrichten von den Nabelschnurblutdatenbanken sehen, welchen er zugeordnet ist.
  • Die Nabelschnurblutdatenbank welcher eine Nachricht zugeordnet ist muss in der ”Nabelschnurblutdatenbank Nachrichten-Übersicht” ersichtlich sein (neue Spalte). Dies ist notwendig um nach Nachrichten einer Nabelschnurblutdatenbank filtern zu können.
  • Bisher ist in der ”Nabelschnurblutdatenbank Nachrichten-Übersicht” der Zugriff auf die Daten des entsprechenden Suche Centers möglich. Hier muss nun der Zugriff auf die Klinikdaten erfolgen.
  • Die BackOffice Message Übersicht stellt alle Nachrichten tabellarisch und kontextabhängig dar.
  • Die Klinik, Nabelschnurblutdatenbank und der Verbund (wenn vorhanden) welchem eine Nachricht zugeordnet ist, ist in der ”Back Office Nachrichten-Übersicht” ersichtlich. Dies ist notwendig um die Nachrichten entsprechend filtern zu können. Bisher wurden ”lediglich” das Suche-Center und die Nabelschnurblutdatenbank aufgeführt.
  • Es gibt für jede Klinik und Nabelschnurblutdatenbank pro Anforderungs-Typ (engl. „Request”) die Möglichkeit, einen Freigabeschritt zu aktivieren, der nach dem Anlegen eines „Requests” und vor der Übermittlung an die Nabelschnurblutdatenbank erfolgt.
  • Auf Nabelschnurblutdatenbank-Seite ist die Freigabe direkt nach Eingang des „Requests” durchzuführen.
  • Dafür ist eine zusätzliche Rolle ”Manager” notwendig, die diese Freigabe erteilen darf. Hintergrund ist die zusätzliche Freigabe von kostenpflichtigen „Requests”, vor allem durch Register-Mitarbeiter für angeschlossene Kliniken und Nabelschnurblutdatenbanken, die kostenpflichtige „Requests” beauftragen oder bearbeiten.
  • Die Bestätigungsschritte sind nur durch Nutzer in Managerrolle durchführbar.
  • Nur Nutzer mit der entsprechenden Managerrolle ”Klinik Manager” beziehungsweise ”Nabelschnurblutdatenbank Manager” dürfen die Bestätigung zu einem „Request” geben. Dabei ist die Zuordnung des Nutzers zu der entsprechenden Organisationseinheit zu beachten. Nur wenn der Nutzer der entsprechenden Klinik/Nabelschnurblutdatenbank zugeordnet ist, kann er für diese die Bestätigungsschritte durchführen.
  • Im Rahmen des Annahme-Prozesses wurden durch die Erfindung folgende neue „Requests” Status eingeführt:
    • 1. Klinik-Seite: ”waiting for Approval” oder „Warten auf Annahme”
    • 2. Klinik-Seite: ”refused” oder „abgewiesen”
    • 3. Einrichtungs-Seite (Nabelschnurblutdatenbank): ”approved” oder „angenommen”
  • Nach dem Anlegen eines „Requests” wird dieser in den Status ”waiting for Approval” versetzt, sofern für den entsprechenden „Request”-Typ ein Bestätigungsschritt definiert ist. Nach der Bestätigung durch einen Nutzer mit der Rolle ”Klinik Manager” (Anlegen von „Requests” bisher nur auf Klinikenseite) wird der Status entsprechend des „Request”typs einen Schritt weiter gesetzt (zum Beispiel ”„Request”ed”) und ist nun auf Seiten der Nabelschnurblutdatenbank sichtbar.
  • Auf der Nabelschnurblutdatenbank-Seite muss ein Nutzer mit der Rolle ”Nabelschnurblutdatenbank Manger” diesen „Request” nun wiederum bestätigen, vorausgesetzt es ist auch auf Nabelschnurblutdatenbank-Seite ein entsprechender Bestätigungsschritt definiert. Ist dies geschehen, hat der „Request” den Status ”approved” und die Bearbeitung kann weitergehen.
  • Auf der Klinik-Seite muss der Nutzer mit der Rolle ”Klinik-Manager” die Möglichkeit haben, einen „Request” im Status ”waiting for Annahme” abzulehnen. In diesem Fall bekommt der Request den Status ”refused”. In diesem Status ist der „Request” ausschließlich auf der Klinik-Seite sichtbar.
  • Die beiden neuen Statuswerte werden wie bisherige Statuswerte in der „Request”-Übersicht angezeigt.
  • Der Statuswert ”waiting for Annahme” ist hierbei nur auf Seiten der Klinik sichtbar, da der „Request” auf Nabelschnurblutdatenbank-Seite erst sichtbar wird, wenn er im Status ”„Request”ed” steht (Reservation „Request” ”reserved”). Der Statuswert ”approved” ist auf Klinik, als auch auf Nabelschnurblutdatenbank-Seite sichtbar.
  • Es muss pro „Request”-Typ konfigurierbar sein, ob ein Bestätigungsschrittes durch einen Nutzer in einer ”Managerrolle” notwendig ist oder nicht. Dies betrifft alle in der Plattform und/oder dem System verfügbaren „Request”-Typen. Bevorzugte Request-Typen sind: Reservierung „Request”, Bestellung „Request”, HLA-Typing „Request”, Probe „Request”, Colony Assay „Request”
  • Nur Nutzer mit folgenden Nutzerrollen können die Bestätigungsschritte aktivieren beziehungsweise editieren:
    • 1. Der Klinik Administrator kann Bestätigungsschritte auf Klinikebene (nur für zugewiesene Kliniken) aktivieren.
    • 2. Der Nabelschnurblutdatenbank Administrator kann Bestätigungsschritte auf Nabelschnurblutdatenbank-Ebene (nur für zugewiesene Nabelschnurblutdatenbanken) aktivieren.
    • 3. Der BackOffice-User kann Bestätigungsschritte auf Klinik- als auch Nabelschnurblutdatenbank-Ebene aktivieren.
  • Die Definition für welche „Request”-Typen ein Bestätigungsschritt durch einen Nutzer in einer Managerrolle notwendig ist, muss pro Klinik und Nabelschnurblutdatenbank individuell definierbar/editierbar sein.
  • Erfindungsgemäß darf auf der Ebene eines Verbundes (Gruppen) keine Definition von bestätigungsrelevante „Request”-Typen verfügbar sein.
  • Standardmäßig sind keine Bestätigungsschritte für Kliniken beziehungsweise Nabelschnurblutdatenbanken aktiviert.
  • Die Status-Bar stellt den neuen Status wie folgt dar:
    Befindet sich der „Request” im Status ”waiting for Annahme” wird weiterhin der Status ”Erstelle” in der Status-Bar hervorgehoben.
  • Befindet sich der „Request” im Status ”approved” wird der Status ”processing” in der Status-Bar hervorgehoben.
  • Befindet sich der „Request” im Status ”refused” ist eine neue Status-Bar notwendig die die Status ”Erstelle” und ”Refused” enthält und in der der Status ”refused” hervorgehoben ist Wird ein Order „Request” aus einem Reservation „Request” heraus erzeugt und ist für den Order „Request” ein Bestätigungsschritt definiert, muss der Reservation „Request” so lange weiterlaufen, bis der Order „Request” bestätigt wurde, also vom Status ”waiting for Annahme” in ”„Request”ed übergeht”.
  • Der Reservation „Request” läuft unverändert weiter, beziehungsweise läuft aus, wenn der Order „Request” im Status ”waiting for Annahme” ist. Dem Nutzer steht es dabei frei wie üblich die Reservierung zu verlängern.
  • In der detaillierten „Request”matrix sind die exakten Statusübergänge, Status-Buttons (der „Request”dialoge), Statustexte, Bestätigungstexte, sowie Status Graphiken definiert.
  • Im Rahmen des Annahme-Konzeptes ist erfindungsgemäß eine weitere Ebene zur Einschränkung der Sichtbarkeit von „Requests” vorgesehen. Die Sichtbarkeit eines „Requests” ist zusätzlich zur Zuordnung des Nutzers zu einer oder mehreren Organisationen und der Nutzerrolle auch vom Status des „Requests” abhängig. Entsprechend der Kombination dieser Faktoren ist der „Request” in der „Request”-Übersicht sichtbar oder nicht.
  • Ist zum Beispiel auf Seiten der Nabelschnurblutdatenbank ein „Request” im Status ”„Request”ed” und der Annahme-Prozess ist für diesen „Request”typ aktiviert, ist dieser „Request” ausschließlich für Nutzer mit der Rolle ”Klinik Manager” (und höher) sichtbar.
  • Neuen beziehungsweise geänderten „Requests” können markiert werden. Auf der Klinik-Seite muss ein „Request” durch einen Nutzer im Kontext einer Klinikrolle grundsätzlich dann als geändert markiert sein, wenn die Gegenseite eine Anpassung vornimmt und der Nutzer der Besitzer (engl. Owner) des „Requests” ist.
  • Eine Ausnahme ist hier zum Beispiel das Erreichen des Status ”Refused”. Hier wird der Besitzer auch informiert, obwohl die Anpassung nicht durch die Gegenseite vorgenommen wurde (Klinik Manager hat „Request” abgelehnt).
  • Auf der Seiten der Nabelschnurblutdatenbank werden „Requests” grundsätzlich nur für Nutzer mit der Rolle ”Nabelschnurblutdatenbank Supervisor” und ”Nabelschnurblutdatenbank Coordinator” markiert, wenn die „Requests” neu sind beziehungsweise von der Gegenseite geändert wurden.
  • Die einzige Ausnahme bildet hier der Status ”„Request”ed” im Falle eines aktivierten Annahme-Prozesses. In diesem Fall wird der „Request” für Nutzer mit der Rolle ”Nabelschnurblutdatenbank Manager” als neu beziehungsweise aus fachlicher Sicht als ”zu bestätigen” markiert. Eine Markierung für Nutzer in der Rolle ”Nabelschnurblutdatenbank Coordinator” beziehungsweise ”Nabelschnurblutdatenbank Supervisor” ist auf Grund der Anforderung der eingeschränkten Sichtbarkeit nicht möglich.
  • Auf Grund des Annahme-Prozesses ergibt sich für die Kennzeichnung der Notwendigkeit des nächsten Bearbeitungsschrittes (”Action required”) eine Erweiterung der bestimmenden Faktoren. Hier wird jetzt zusätzlich die Nutzerrolle berücksichtigt. Im Stand der Technik war hier bisher die Domäne alleinig ausschlaggebend.
  • Wurde zum Beispiel auf Seiten der Klinik ein neuer „Request” angelegt und ist für dessen „Request”typ der Annahme-Prozess aktiviert, befindet sich der „Request” nach dem Anlegen im Status ”Waiting for Annahme”. Der nächste Bearbeitungsschritt muss nun von einem Nutzer in der Rolle ”Klinik Manager” (oder höher) durchgeführt werden, somit ist die positive Kennzeichnung (”Action required” = ”yes”) auch nur für Nutzer dieser Rolle(n) notwendig. Für Kliniknutzer mit den Rollen ”Klinik Coordinator” beziehungsweise ”Klinik Supervisor” steht dieser Wert entsprechend auf ”no”.
  • Wenn ein Nutzer mit der Rolle ”Klinik-Manager” einen „Request” erzeugt, für dessen „Request”typ der Annahme-Prozess aktiviert ist, findet kein direkter Wechsel in den Status ”„Request”ed” statt.
  • Auch in diesem Fall wechselt der „Request” erst in den Status ”Waiting for Annahme”. Somit wird dieser „Request” auch erneut als ”Neu” und als ”Zu bearbeiten” (”Action Required” = ”Yes”) für den Nutzer in der Rolle Klinik-Manager (oder höher) markiert.
  • In einer weiteren bevorzugten Ausführungsform betrifft die Erfindung das Steuerungssystem, wobei der Nutzer eine Anfrage an eine Organisation stellt zur Identifikation von Inventaren, wobei die Inventare in lokal verfügbaren Datenbanksystemen und in entfernten Datenbanksystemen gespeichert sind, dadurch gekennzeichnet, dass
    • 1) lokal verfügbare Datenbanksysteme und/oder lokale Kopien von Inventaren aus entfernten Datenbanksystemen durchsucht werden und
    • 2) Abfragedaten an entfernte Datenbanksysteme gesendet werden, wobei die Datenbanksysteme synchron und/oder asynchron antworten können, und
    • 3) die Ergebnisse angezeigt werden, wobei dem Nutzer asynchron eintreffende Ergebnisse aus entfernten Datenbanksystemen in bestimmten Zeitintervallen angezeigt werden, und
    • 4) wobei die Ergebnisse aus entfernten Datenbanksystemen im Cache gespeichert werden.
  • Es ist außerdem bevorzugt, dass die im Cache gespeicherten Ergebnisse aktualisiert werden.
  • Ein Nutzer kann somit Anfragen stellen, welche gleichzeitig an alle relevanten Datenbanksystem, welche in den Organisationseinheiten liegen, gesendet werden. Durch die neuen und optimierten Zugriffsberechtigungen, können maßgeschneiderte Anfragen schnell und gezielt beantwortet werden.
  • Weiterhin ist bevorzugt, dass regelmäßig automatische Suchanfragen an entfernte Datenbanksysteme gestellt werden und die Ergebnisse im Cache gespeichert werden. Somit kann ein Nutzer in regelmäßigen Abständen über die Ergebnisse und auch neu eintreffende Ergebnisse informiert werden. Die Suche liefert dadurch besonders aktuelle Ergebnisse.
  • In einer weiteren bevorzugten Ausführungsform betrifft die Erfindung die Verwendung eines erfindungsgemäßen Steuerungssystems zur Identifikation von Inventaren aus lokal verfügbaren Datenbanksystemen und entfernten Datenbanksystemen, dadurch gekennzeichnet, dass
    • 5) lokal verfügbare Datenbanksysteme und/oder lokale Kopien von Inventaren aus entfernten Datenbanksystemen durchsucht werden und
    • 6) Abfragedaten an entfernte Datenbanksysteme gesendet werden, wobei die Datenbanksysteme synchron und/oder asynchron antworten können, und
    • 7) die Ergebnisse angezeigt werden, wobei dem Nutzer asynchron eintreffende Ergebnisse aus entfernten Datenbanksystemen in bestimmten Zeitintervallen angezeigt werden, und
    • 8) wobei die Ergebnisse aus entfernten Datenbanksystemen im Cache gespeichert werden.
  • Die Verwendung ist besonders zur Identifikation einer Nabelschnurbluteinheit bevorzugt. Es hat sich gezeigt, dass vor allem auf diesem Gebiete ein großer Bedarf an Systemen und Plattformen besteht, die komplexe Organisationsstrukturen unterstützen und Suchen in verteilten Inventaren erlauben. Die Erfindung vereinfacht diese Prozesse daher und ist vorteilhaft gegenüber dem Stand der Technik.
  • Die Erfindung beschreibt somit eine neue Technologie zur Suche nach Stammzellprodukten in verteilten Inventaren. Es werden dabei komplexe dezentrale Organisationsstrukturen unterstützt, wovon die Suchfunktion in vorteilhafterweise profitiert.
  • Außerdem betrifft die Erfindung ein Verfahren zur Identifizierung von Inventaren, wobei die Inventare in lokal verfügbaren Datenbanksystemen und entfernten Datenbanksystemen gespeichert sind, dadurch gekennzeichnet, dass
    • a. lokal verfügbare Datenbanksysteme und/oder lokale Kopien von Inventaren aus entfernten Datenbanksystemen durchsucht werden und
    • b. Abfragedaten an entferne Datenbanksysteme gesendet werden, wobei die Datenbanksysteme synchron und/oder asynchron antworten können und
    • c. die Ergebnisse angezeigt werden, wobei dem Nutzer asynchron eintreffende Ergebnisse aus entfernten Datenbanksystemen in bestimmten Zeitintervallen angezeigt werden, und
    • d. wobei die Ergebnisse aus entfernten Datenbanksystemen im Cache gespeichert werden.
  • Die Einführung eines Freigabeprozesses für Anfragen (Requests) durch Nutzer in bestimmten Rollen für definierte Organisationseinheiten, wie Kliniken oder Nabelschnurblutbanken ermöglicht eine besonders effiziente Abwicklung und schnelle Bearbeitung solcher Fragen. Dies wird gerade durch die im Verbund-Konzept erweiterten strukturellen Möglichkeiten notwendig beziehungsweise ergänzt diese.
  • Das System beziehungsweise das Verfahren unterstützt die Suche in direkten, das heißt lokal verfügbaren, und verteilten, das heißt von weiteren auch entfernten Datenbanken oder Systemen, bereitgestellten Inventaren von zum Beispiel Stammzellprodukten.
  • Für die Suche wird aufgrund der unterschiedlichen Antwortzeiten und Strukturen gestaffelt mit den verschiedenen Inventaren gearbeitet:
    • a) Das System durchsucht zunächst lokal verfügbare Inventare und lokale Kopien entfernter Inventare, die von früheren Suchen zwischengespeichert wurden (Cache).
    • b) Das System sendet parallel Abfragen mit den Patientendaten an entfernte Systeme. Die entfernten Systeme können synchron oder asynchron antworten.
    • c) Dem Benutzer werden die Ergebnisse der lokalen Suche zusammen mit bereits eingetroffenen Ergebnissen aus entfernten Systemen direkt angezeigt.
    • d) Der Benutzer wird über asynchron eintreffende Ergebnisse aus entfernten Systemen in einstellbaren Zeitintervallen informiert.
    • e) Sind in Suchergebnissen aus entfernten Systemen Produkte enthalten, die bereits lokal im Cache identifiziert wurden wird das Suchergebnis entsprechend aktualisiert und der Benutzer informiert.
    • f) Ergebnisse aus entfernten Systemen werden lokal im Cache gespeichert um für spätere Suchen lokal zur Verfügung zu stehen.
    • g) Das System kann regelmäßig künstliche Suchanfragen an entfernte Systeme durchführen, die zum Füllen des lokalen Caches genutzt werden. Diese Funktion wird als „Pitching” bezeichnet.
  • Beispiele und Abbildungen
  • Der Zugriff auf Funktionalitäten für Nutzer eines Verbundes mit Klinken und Nabelschnurblutdatenbanken ergibt sich durch Kombination entsprechender Rollen. Ist zum Beispiel ein Nutzer einer Klinik und einer Nabelschnurblutdatenbank eines Verbundes (Gruppen) zugeordnet und soll hier Zugriff auf alle Patienten und Nachrichten usw. haben, sind ihm die Rollen ”Klinik-Supervisor” und ”Nabelschnurblutdatenbank Supervisor” zuzuordnen.
  • In ist ein bevorzugtes Organisationsmodell gezeigt. Es werden dabei die neuen fachlichen Datenstrukturen dargestellt, welche die komplexe Organisationsstrukturen der Erfindung unterstützen.
  • zeigt die verfügbaren Ansichten am Beispiel einer Nabelschnurblutdatenbank.
  • zeigt eine bevorzugte Organisations-Übersicht. Diese Übersicht ist dabei nur für den BackOffice Nutzer zugänglich und stellt tabellarisch alle in der Plattform/System angelegten Organisationen dar und bietet zudem die Funktionalität zum Erstellen aller verfügbaren Organisationen und deren Nutzer sowie zugehörige Daten.
  • In wird eine bevorzugte Klinik-Übersicht gezeigt, welche zur Darstellung von Kliniken, sowie der Bearbeitung der der Klinik zugeordneten Daten dient.
  • zeigt eine bevorzugte Nabelschnurblutdatenbank-Überischt.
  • zeigt eine bevorzugte Nutzer-Übersicht, welche zur Darstellung der Nutzer sowie zum Bearbeiten und Anlegen dieser dient.
  • zeigt, wie neue Nutzer angelegt werden können beziehungsweise bestehende Nutzer bearbeitet werden können.
  • gibt einen Überblick über den Annahme-Prozess (Approval-Prozess). Die Abbildung zeigt schematisch die Statusübergänge.
  • zeigt schematisch wie das System für die Suche nach verteilten Inventaren aufgebaut ist.
  • In den Tabellen 1 bis 9 werden detaillierte Aufstellung des „Request”-Workflows samt aller Bedingung für die Darstellung durch das System gezeigt.
  • Beispiel 1:
  • Nutzer A (Klinik + Nabelschnurblutdatenbank Admin) ist dem Verbund A und seinen enthaltenen Einheiten zugeordnet. Der Verbund A besteht aus zwei Kliniken und einer Nabelschnurblutdatenbank. Somit wird Nutzer A die Gruppen-Ansicht angezeigt. Er hat damit also Zugriff auf die Kliniken Ansicht, sowie die Nabelschnurblutdatenbank-Ansicht und durch die Administratorrollen auch Zugriff auf die Nutzerverwaltung für die Kliniken sowie die Nabelschnurblutdatenbank.
  • Beispiel 2
  • Im Folgenden wird an einem Beispiele für die User-Ansicht verdeutlicht:
  • 1. Zugriff über die Gruppen Ansicht (Verbund mit Klinken und Nabelschnurblutdatenbanken)
    • – Darstellung aller Nutzer des entsprechenden Verbundes
  • 2. Zugriff über Kliniken Ansicht (Verbund enthält nur Kliniken)
    • – Darstellung aller Nutzer der Kliniken des Verbundes
  • 3. Zugriff über Kliniken Ansicht (eigenständige Klinik)
    • – Darstellung aller Nutzer der Klinik
  • Tabelle 1.1: Order Request-Workflow/Daten
    Clinic Clinic CBB Clinic
    Label Type Mandatory Beschreibung Create Waiting for approval Requested Requested
    Delivery Date Date x Nicht vorbelegt! x x x
    Contact Person (Delivery) Text x Vorbelegt mit Kontaktperson der Klinik (Komplette Kontaktfelder laut Spec) x x x
    Delivery Address Text x Vorbelegen mit Anschrift der Klinik des Patienten (Komplette Felder laut Spec) x x x
    Emergency Number Text x Nicht vorbelegt! x x x
    Contact Person (Coordinator) Text x Vorbelegt mit Kontaktdaten des SC Users (Komplette Felder laut Spec) x x x
    Billing Address Text x Vorbelegen mit Rechnungsanschrift der Klinik des Patienten (Komplette Felder laut Spec) x x x
    Shipment Date Date x Nicht vorbelegt!
    Shipment Link URL Nicht vorbelegt!
    Tracking Number String Nicht vorbelegt!
    Shipper Text Nicht vorbelegt!
    Comment Text Standard Kommentarfeld x x x x
    Comment History Anzeige Anzeige der Kommentarhistory mit Datum/Uhrzeit
    Created/Modified Anzeige Anzeige des Creation/Modification Date wie im Patient Chart
    Create Folgestatus abhängig von Einstellungen zur ”Requestfreigabe” (durch Manager) ”Requested” oder ”Waiting for approval”
    Approve Approve-Button im Status ”Requested” auf CBB-Seite nur sichtbar wenn ”Requestfreigabe” aktiviert Requested Approved
    Save Adjusted
    Shipped
    Answer Inquiry
    Cancel Canceled Canceled
    Refuse Refused
    Reject Rejected
    Inquiry Inquiry-Button im Staus ”Requested” auf CBB-Seite ausblenden wenn ”Requestfreigabe” aktiviert Inquiry
    Process Process-Button im Staus ”Requested” auf CBB-Seite ausblenden wenn ”Requestfreigabe” aktiviert Processing
    Siphment failed
    Shipment Received
    Tabelle 1.2: Order Request – Workflow/Daten
    CBB Clinic CBB Clinic
    Label Type Mandatory Beschreibung Approved Approved Inquiry Inquiry
    Delivery Date Date x Nicht vorbelegt! x x
    Contact Person (Delivery) Text x Vorbelegt mit Kontaktperson der Klinik (Komplette Kontaktfelder laut Spec) x x
    Delivery Address Text x Vorbelegen mit Anschrift der Klinik des Patienten (Komplette Felder laut Spec) x x
    Emergency Number Text x Nicht vorbelegt! x x
    Contact Person (Coordinator) Text x Vorbelegt mit Kontaktdaten des SC Users (Komplette Felder laut Spec) x x
    Billing Address Text x Vorbelegen mit Rechnungsanschrift der Klinik des Patienten (Komplette Felder laut Spec) x x
    Shipment Date Date x Nicht vorbelegt!
    Shipment Link URL Nicht vorbelegt!
    Tracking Number String Nicht vorbelegt!
    Shipper Text Nicht vorbelegt!
    Comment Text Standard Kommentarfeld x x x x
    Comment History Anzeige Anzeige der Kommentarhistory mit Datum/Uhrzeit
    Created/Modified Anzeige Anzeige des Creation/Modification Date wie im Patient Chart
    Create Folgestatus abhängig von Einstellungen zur ”Requestfreigabe” (durch Manager)
    Approve Approve-Button im Status ”Requested” auf CBB-Seite nur sichtbar wenn ”Requestfreigabe” aktiviert
    Save Adjusted Inquiry
    Shipped
    Answer Inquiry Inquiry Answered
    Cancel Canceled Canceled
    Refuse
    Reject Rejected Rejected
    Inquiry Inquiry-Button im Staus ”Requested” auf CBB-Seite ausblenden wenn ”Requestfreigabe” aktiviert Inquiry
    Process Process-Button im Staus ”Requested” auf CBB-Seite ausblenden wenn ”Requestfreigabe” aktiviert Processing Processing
    Siphment failed
    Shipment Received
    Tabelle 1.3: Order Request – Workflow/Daten
    CBB Clinic CBB Clinic
    Label Type Mandatory Beschreibung Inquiry Answered Inquiry Answered Adjusted Adjusted
    Delivery Date Date x Nicht vorbelegt! x x
    Contact Person (Delivery) Text x Vorbelegt mit Kontaktperson der Klinik (Komplette Kontaktfelder laut Spec) x x
    Delivery Address Text x Vorbelegen mit Anschrift der Klinik des Patienten (Komplette Felder laut Spec) x x
    Emergency Number Text x Nicht vorbelegt! x x
    Contact Person (Coordinator) Text x Vorbelegt mit Kontaktdaten des SC Users (Komplette Felder laut Spec) x x
    Billing Address Text x Vorbelegen mit Rechnungsanschrift der Klinik des Patienten (Komplette Felder laut Spec) x x
    Shipment Date Date x Nicht vorbelegt!
    Shipment Link URL Nicht vorbelegt!
    Tracking Number String Nicht vorbelegt!
    Shipper Text Nicht vorbelegt!
    Comment Text Standard Kommentarfeld x x x x
    Comment History Anzeige Anzeige der Kommentarhistory mit Datum/Uhrzeit
    Created/Modified Anzeige Anzeige des Creation/Modification Date wie im Patient Chart
    Create Folgestatus abhängig von Einstellungen zur ”Requestfreigabe” (durch Manager)
    Approve Approve-Button im Status ”Requested” auf CBB-Seite nur sichtbar wenn ”Requestfreigabe” aktiviert
    Save Adjusted Adjusted
    Shipped
    Answer Inquiry
    Cancel Canceled Canceled
    Refuse
    Reject Rejected Rejected
    Inquiry Inquiry-Button im Staus ”Requested” auf CBB-Seite ausblenden wenn ”Requestfreigabe” aktiviert Inquiry Inquiry
    Process Process-Button im Staus ”Requested” auf CBB-Seite ausblenden wenn ”Requestfreigabe” aktiviert Processing Processing
    Siphment failed
    Shipment Received
    Tabelle 1.4: Order Request – Workflow/Daten
    CBB Clinic CBB Clinic
    Label Type Mandatory Beschreibung Rejected Rejected Canceled Canceled
    Delivery Date Date x Nicht vorbelegt!
    Contact Person (Delivery) Text x Vorbelegt mit Kontaktperson der Klinik (Komplette Kontaktfelder laut Spec)
    Delivery Address Text x Vorbelegen mit Anschrift der Klinik des Patienten (Komplette Felder laut Spec)
    Emergency Number Text x Nicht vorbelegt!
    Contact Person (Coordinator) Text x Vorbelegt mit Kontaktdaten des SC Users (Komplette Felder laut Spec)
    Billing Address Text x Vorbelegen mit Rechnungsanschrift der Klinik des Patienten (Komplette Felder laut Spec)
    Shipment Date Date x Nicht vorbelegt!
    Shipment Link URL Nicht vorbelegt!
    Tracking Number String Nicht vorbelegt!
    Shipper Text Nicht vorbelegt!
    Comment Text Standard Kommentarfeld
    Comment History Anzeige Anzeige der Kommentarhistory mit Datum/Uhrzeit
    Created/Modified Anzeige Anzeige des Creation/Modification Date wie im Patient Chart
    Create ”Folgestatus abhängig von Einstellungen zur Requestfreigabe” (durch Manager)
    Approve Approve-Button im Status ”Requested” auf CBB-Seite nur sichtbar wenn ”Requestfreigabe” aktiviert
    Save
    Shipped
    Answer Inquiry
    Cancel
    Refuse
    Reject
    Inquiry Inquiry-Button im Staus”Requested” auf CBB-Seite ausblenden wenn ”Requestfreigabe” aktiviert
    Process Process-Button im Staus”Requested” auf CBB-Seite ausblenden wenn ”Requestfreigabe” aktiviert
    Siphment failed
    Shipment Received
    Tabelle 1.5: Order Request – Workflow/Daten
    CBB Clinic CBB Clinic
    Label Type Mandatory Beschreibung Rejected Rejected Canceled Canceled
    Delivery Date Date x Nicht vorbelegt!
    Contact Person (Delivery) Text x Vorbelegt mit Kontaktperson der Klinik (Komplette Kontaktfelder laut Spec)
    Delivery Address Text x Vorbelegen mit Anschrift der Klinik des Patienten (Komplette Felder laut Spec)
    Emergency Number Text x Nicht vorbelegt!
    Contact (Person Coordinator) Text x Vorbelegt mit Kontaktdaten des SC Users (Komplette Felder laut Spec)
    Billing Address Text x Vorbelegen mit Rechnungsanschrift der Klinik des Patienten (Komplette Felder laut Spec)
    Shipment Date Date x Nicht vorbelegt!
    Shipment Link URL Nicht vorbelegt!
    Tracking Number String Nicht vorbelegt!
    Shipper Text Nicht vorbelegt!
    Comment Text Standard Kommentarfeld
    Comment History Anzeige Anzeige der Kommentarhistory mit Datum/Uhrzeit
    Created/Modified Anzeige Anzeige des Creation/Modification Date wie im Patient Chart
    Create Folgestatus abhängig von Einstellungen zur ”Requestfreigabe” (durch Manager)
    Approve Approve-Button im Status ”Requested” auf CBB-Seite nur sichtbar wenn ”Requestfreigabe” aktiviert
    Save
    Shipped
    Answer Inquiry
    Cancel
    Refuse
    Reject
    Inquiry Inquiry-Button im Staus ”Requested” auf CBB-Seite ausblenden wenn ”Requestfreigabe” aktiviert
    Process Process-Button im Staus ”Requested” auf CBB-Seite ausblenden wenn ”Requestfreigabe” aktiviert
    Siphment failed
    Shipment Received
    Tabelle 2.1: Reservation Request – Workflow/Daten
    Clinic Clinic CBB Clinic
    Label Type Mandatory Beschreibung Create Waiting for approval CBU reserved CBU reserved
    Reservation until Date Creation Date + n Tage (ab 1.1 konfigurierbar pro SC), nicht editierbar
    Extended Integer n times (Wie oft wurde die Reservierung bereits verlängert), nicht editierbar
    Comment Text Standard x x x x
    Comment History Nur Anzeige Kommentarfeld Anzeige der Kommentarhistory
    Created/Modified Nur Anzeige Anzeige des Creation/Modification Date wie im Patient Chart
    Create Folgestatus abhängig von Einstellungen zur ”Requestfreigabe” (durch Manager) CBU reserved or waiting for approval
    Approve CBU reserved
    Save
    Cancel Canceled Canceled
    Refuse Refused
    Reject Rejected
    Extend Extended
    Order CBU Ordered
    Tabelle 2.2: Reservation Request – Workflow/Daten
    CBB Clinic CBB Clinic
    Label Type Mandatory Beschreibung Extended Extended Rejected Rejected
    Reservation until Date Creation Date + n Tage (ab 1.1 konfigurierbar pro SC), nicht editierbar
    Extended Integer n times (Wie oft wurde die Reservierung bereits verlängert), nicht editierbar
    Comment Text Standard Kommentarfeld x x
    Comment History Nur Anzeige Anzeige der Kommentarhistory
    Created/Modified Nur Anzeige Anzeige des Creation/Modification Date wie im Patient Chart
    Create Folgestatus abhängig von Einstellungen zur ”Requestfreigabe” (durch Manager)
    Approve
    Save
    Cancel
    Refuse
    Reject Rejected
    Extend Extended
    Order CBU Ordered
    Tabelle 2.3: Reservation Request – Workflow/Daten
    CBB Clinic CBB Clinic
    Label Type Mandatory Beschreibung Expired Expired Canceled Canceled
    Reservation until Date Creation Date + n Tage (ab 1.1 konfigurierbar pro SC), nicht editierbar
    Extended Integer n times (Wie oft wurde die Reservierung bereits verlängert), nicht editierbar
    Comment Text Standard Kommentarfeld
    Comment History Nur Anzeige Anzeige der Kommentarhistory
    Created/Modified Nur Anzeige Anzeige des Creation/Modification Date wie im Patient Chart
    Create Folgestatus abhängig von Einstellungen zur ”Requestfreigabe” (durch Manager)
    Approve
    Save
    Cancel
    Refuse
    Reject
    Extend
    Order
    Tabelle 2.4: Reservation Request – Workflow/Daten
    CBB Clinic
    Label Type Mandatory Beschreibung CBU Ordered CBU Ordered
    Reservation until Date Creation Date + n Tage (ab 1.1 konfigurierbar pro SC), nicht editierbar
    Extended Integer n times (Wie oft wurde die Reservierung bereits verlängert), nicht editierbar
    Comment Text Standard Kommentarfeld
    Comment History Nur Anzeige Anzeige der Kommentarhistory
    Created/Modified Nur Anzeige Anzeige des Creation/Modification Date wie im Patient Chart
    Create Folgestatus abhängig von Einstellungen zur ”Requestfreigabe” (durch Manager)
    Approve
    Save
    Cancel
    Refuse
    Reject
    Extend
    Order
    Tabelle 3.1: Sample Request – Workflow/Daten
    Clinic Clinic CBB Clinic
    Label Type Mandatory Beschreibung Create Waiting for approval Requested Requested
    Sample Type List/Single Choice x ”DNA”, ”Plasma”, ”Erythrocytes”, ”ALIQUOTS (Other)” x x x
    Minimum Quantitiy Float x Float, μg/ml, 2 Nachkommastellen x x x
    Contact Person (Delivery) Text x Vorbelegt mit Kontaktperson der Klinik (Komplette Kontaktfelder laut Spec) x x x
    Delivery Address Text x Vorbelegen mit Anschrift der Klinik des Patienten (Komplette Felder laut Spec) x x x
    Emergency Number Text x Nicht vorbelegt! x x x
    Contact Person (Coordinator) Text x Vorbelegt mit Kontaktdaten des SC Users (Komplette Felder laut Spec) x x x
    Billing Address Text x Vorbelegen mit Rechnungsanschrift der Klinik des Patienten (Komplette Felder laut Spec) x x x
    Temperature Condition List/Single Choice x Nicht vorbelegt! (Auswahl aus ”Room Temperature”, ”Frozen”)
    Shipment Date Date x Nicht vorbelegt!
    Shipment Link URL Nicht vorbelegt!
    Tracking Number String Nicht vorbelegt!
    Shipper Text Nicht vorbelegt!
    HLA-A String (HLA-Wert) Werte für beide Loci, n digits + N, Validierung mit HLA-Validator
    HLA-B String (HLA-Wert) Werte für beide Loci, n digits + N, Validierung mit HLA-Validator
    HLA-C String (HLA-Wert) Werte für beide Loci, n digits + N, Validierung mit HLA-Validator
    HLA-DRB1 String (HLA-Wert) Werte für beide Loci, n digits + N, Validierung mit HLA-Validator
    HLA-DQB1 String (HLA-Wert) Werte für beide Loci, n digits + N, Validierung mit HLA-Validator
    Comment Text Standard Kommentarfeld x x x x
    Comment History Anzeige Anzeige der Kommentarhistory mit Datum/Uhrzeit
    Created/Modified Anzeige Anzeige des Creation/Modification Date wie im Patient Chart
    Create Folgestatus abhängig von Einstellungen zur ”Requestfreigabe” (durch Manager) ”Requested” oder ”Waiting for approval”
    Approve Approve-Button im Status ”Requested” auf CBB-Seite nur sichtbar wenn ”Requestfreigabe” aktiviert Requested Approved
    Save Requested
    Shipped
    Cancel Canceled Canceled
    Refuse Refused
    Reject Rejected
    Process Process-Button im Staus ”Requested” auf CBB-Seite ausblenden wenn ”Requestfreigabe” aktiviert Processing
    Siphment failed
    Shipment Received
    Tabelle 3.2: Sample Request – Workflow/Daten
    Clinic CBB Clinic CBB
    Label Type Mandatory Beschreibung Shipped Shipment failed Shipment failed Received
    Sample Type List/Single Choice x ”DNA”, ”Plasma”, ”Erythrocytes”, ”ALIQUOTS (Other)”
    Minimum Quantitiy Float x Float, μg/ml, 2 Nachkommastellen
    Contact Person (Delivery) Text x Vorbelegt mit Kontaktperson der Klinik (Komplette Kontaktfelder laut Spec)
    Delivery Address Text x Vorbelegen mit Anschrift der Klinik des Patienten (Komplette Felder laut Spec)
    Emergency Number Text x Nicht vorbelegt!
    Contact Person (Coordinator) Text x Vorbelegt mit Kontaktdaten des SC Users (Komplette Felder laut Spec)
    Billing Address Text x Vorbelegen mit Rechnungsanschrift der Klinik des Patienten (Komplette Felder laut Spec)
    Temperature Condition List/Single Choice x Nicht vorbelegt! (Auswahl aus ”Room Temperature”, ”Frozen”)
    Shipment Date Date x Nicht vorbelegt!
    Shipment Link URL Nicht vorbelegt!
    Tracking Number String Nicht vorbelegt!
    Shipper Text Nicht vorbelegt!
    HLA-A String (HLA-Wert) Werte für beide Loci, n digits + N, Validierung mit HLA-Validator
    HLA-B String (HLA-Wert) Werte für beide Loci, n digits + N, Validierung mit HLA-Validator
    HLA-C String (HLA-Wert) Werte für beide Loci, n digits + N, Validierung mit HLA-Validator
    HLA-DRB1 String (HLA-Wert) Werte für beide Loci, n digits + N, Validierung mit HLA-Validator
    HLA-DQB1 String (HLA-Wert) Werte für beide Loci, n digits + N, Validierung mit HLA-Validator
    Comment Text Standard Kommentarfeld
    Comment History Anzeige Anzeige der Kommentarhistory mit Datum/Uhrzeit
    Created/Modified Anzeige Anzeige des Creation/Modification Date wie im Patient Chart
    Create Folgestatus abhängig von (Einstellungen zur ”Requestfreigabe” durch Manager)
    Approve Approve-Button im Status ”Requested” auf CBB-Seite nur sichtbar wenn ”Requestfreigabe” aktiviert
    Save
    Shipped
    Cancel
    Refuse
    Reject
    Process Process-Button im Staus ”Requested” auf CBB-Seite ausblenden wenn ”Requestfreigabe” aktiviert
    Siphment failed Shipment failed
    Shipment Received Received
    Tabelle 3.3: Sample Request – Workflow/Daten
    Clinic CBB Clinic
    Label Type Mandatory Beschreibung Received Typing Completed Typing Completed
    Sample Type List/Single Choice x ”DNA”, ”Plasma”, ”Erythrocytes”, ”ALIQUOTS (Other)”
    Minimum Quantitiy Float x Float, μg/ml, 2 Nachkommastellen
    Contact Person (Delivery) Text x Vorbelegt mit Kontaktperson der Klinik (Komplette Kontaktfelder laut Spec)
    Delivery Address Text x Vorbelegen mit Anschrift der Klinik des Patienten (Komplette Felder laut Spec)
    Emergency Number Text x Nicht vorbelegt!
    Contact Person (Coordinator) Text x Vorbelegt mit Kontaktdaten des SC Users (Komplette Felder laut Spec)
    Billing Address Text x Vorbelegen mit Rechnungsanschrift der Klinik des Patienten (Komplette Felder laut Spec)
    Temperature Condition List/Single Choice x Nicht vorbelegt! (Auswahl aus ”Room Temperature”, ”Frozen”)
    Shipment Date Date x Nicht vorbelegt!
    Shipment Link URL Nicht vorbelegt!
    Tracking Number String Nicht vorbelegt!
    Shipper Text Nicht vorbelegt!
    HLA-A String (HLA-Wert) Werte für beide Loci, n digits + N, Validierung mit HLA-Validator x
    HLA-B String (HLA-Wert) Werte für beide Loci, n digits + N, Validierung mit HLA-Validator x
    HLA-C String (HLA-Wert) Werte für beide Loci, n digits + N, Validierung mit HLA-Validator x
    HLA-DRB1 (String HLA-Wert) Werte für beide Loci, n digits + N, Validierung mit HLA-Validator x
    HLA-DQB1 String (HLA-Wert) Werte für beide Loci, n digits + N, Validierung mit HLA-Validator x
    Comment Text Standard Kommentarfeld x
    Comment History Anzeige Anzeige der Kommentarhistory mit Datum/Uhrzeit
    Created/Modified Anzeige Anzeige des Creation/Modification Date wie im Patient Chart
    Create Folgestatus abhängig von Einstellungen zur ”Requestfreigabe” (durch Manager)
    Approve Approve-Button im Status ”Requested” auf CBB-Seite nur sichtbar wenn ”Requestfreigabe” aktiviert
    Save Typing Completed
    Shipped
    Cancel
    Refuse
    Reject
    Process Process-Button im Staus ”Requested” auf CBB-Seite ausblenden wenn ”Requestfreigabe” aktiviert
    Siphment failed
    Shipment Received
    Tabelle 4.1: HLA-Typing Request – Workflow/Daten
    Clinic Clinic CBB Clinic
    Label Type Mandatory Beschreibung Create Waiting for approval Requested Requested
    HLA-A Anzeige Anzeige Original-HLA-Werte der CBU
    HLA-B Anzeige Anzeige Original-HLA-Werte der CBU
    HLA-C Anzeige Anzeige Original-HLA-Werte der CBU
    HLA-DRB1 Anzeige Anzeige Original-HLA-Werte der CBU
    HLA-DQB1 Anzeige Anzeige Original-HLA-Werte der CBU
    HLA-A (Low/Medium/High/None) Optionsfeld x Optionsfelder zur Auswahl der Typing-Auflösung (siehe Screenentwurf), Default komplett leer x
    HLA-B (Low/Medium/High/None) Optionsfeld x Optionsfelder zur Auswahl der Typing-Auflösung (siehe Screenentwurf), Default komplett leer x
    HLA-C (Low/Medium/High/None) Optionsfeld x Optionsfelder zur Auswahl der Typing-Auflösung (siehe Screenentwurf), Default komplett leer x
    HLA-DRB1 (Low/Medium/High/None) Optionsfeld x Optionsfelder zur Auswahl der Typing-Auflösung (siehe Screenentwurf), Default komplett leer x
    HLA-DQB1 (Low/Medium/High/None) Optionsfeld x Optionsfelder zur Auswahl der Typing-Auflösung (siehe Screenentwurf), Default komplett leer x
    HLA-A Eingabefeld String (HLA-Wert) Werte für beide Loci, n digits + N, Validierung mit HLA-Validator,
    HLA-B Eingabefeld String (HLA-Wert) Werte für beide Loci, n digits + N, Validierung mit HLA-Validator,
    HLA-C Eingabefeld String (HLA-Wert) Werte für beide Loci, n digits + N, Validierung mit HLA-Validator,
    HLA-DRB1 Eingabefeld String (HLA-Wert) Werte für beide Loci, n digits + N, Validierung mit HLA-Validator,
    HLA-DQB1 Eingabefeld String (HLA-Wert) Werte für beide Loci, n digits + N, Validierung mit HLA-Validator,
    Typing available until Date x (nicht mandatory im Status ”requested” wenn ”Requestfreigabe” aktiviert) Datum. Bis wann das Typing wahrscheinlich abgeschlossen sein wird x
    Contact Person (Coordinator) Text x Vorbelegt mit Kontaktdaten des SC Users (Komplette Felder laut Spec) x x
    Billing Address Text x Vorbelegen mit Rechnungsanschrift der Klinik des Patienten (Komplette Felder laut Spec) x x
    Comment Text Standard Kommentarfeld x x x x
    Comment History Anzeige Anzeige der Kommentarhistory mit Datum/Uhrzeit
    Created/Modified Anzeige Anzeige des Creation/Modification Date wie im Patient Chart
    Create Folgestatus abhängig von Einstellungen zur ”Requestfreigabe” (durch Manager) ”Requested” oder ”Waiting for approval”
    Approve Approve-Button im Staus ”Requested” auf CBB-Seite nur sichtbar wenn ”Requestfreigabe” aktiviert Requested Approved
    Save
    Cancel Canceled Canceled
    Refuse Refused
    Reject Rejected
    Process Process-Button im Staus ”Requested” auf CBB-Seite ausblenden wenn ”Requestfreigabe” aktiviert Processing
    Completed
    Received
    Tabelle 4.2: HLA-Typing Request – Workflow/Daten
    CBB Clinic CBB Clinic
    Label Type Mandatory Beschreibung Approved Approved Processing Processing
    HLA-A Anzeige Anzeige Original-HLA-Werte der CBU
    HLA-B Anzeige Anzeige Original-HLA-Werte der CBU
    HLA-C Anzeige Anzeige Original-HLA-Werte der CBU
    HLA-DRB1 Anzeige Anzeige Original-HLA-Werte der CBU
    HLA-DQB1 Anzeige Anzeige Original-HLA-Werte der CBU
    HLA-A (Low/Medium/High/None) Optionsfeld x Optionsfelder zur Auswahl der TypingAuflösung (siehe Screenentwurf), Default komplett leer
    HLA-B (Low/Medium/High/None) Optionsfeld x Optionsfelder zur Auswahl der Typing-Auflösung (siehe Screenentwurf), Default komplett leer
    HLA-C (Low/Medium/High/None) Optionsfeld x Optionsfelder zur Auswahl der Typing-Auflösung (siehe Screenentwurf), Default komplett leer
    HLA-DRB1 (Low/Medium/High/None) Optionsfeld x Optionsfelder zur Auswahl der Typing-Auflösung (siehe Screenentwurf), Default komplett leer
    HLA-DQB1 (Low/Medium/High/None) Optionsfeld x Optionsfelder zur Auswahl der Typing-Auflösung (siehe Screenentwurf), Default komplett leer
    HLA-A Eingabefeld String (HLA-Wert) Werte für beide Loci, n digits + N, Validierung mit HLA-Validator, x
    HLA-B Eingabefeld String (HLA-Wert) Werte für beide Loci, n digits + N, Validierung mit HLA-Validator, x
    HLA-C Eingabefeld String (HLA-Wert) Werte für beide Loci, n digits + N, Validierung mit HLA-Validator, x
    HLA-DRB1 Eingabefeld (String HLA-Wert) Werte für beide Loci, n digits + N, Validierung mit HLA-Validator, x
    HLA-DQB1 Eingabefeld String (HLA-Wert) Werte für beide Loci, n digits + N, Validierung mit HLA-Validator, x
    Typing available until Date x (nicht mandatory im Status ”requested” wenn ”Requestfreigabe” aktiviert) Datum. Bis wann das Typing wahrscheinlich abgeschlossen sein wird x x
    Contact Person (Coordinator) Text x Vorbelegt mit Kontaktdaten des SC Users (Komplette Felder laut Spec)
    Billing Address Text x Vorbelegen mit Rechnungsanschrift der Klinik des Patienten (Komplette Felder laut Spec)
    Comment Text Standard Kommentarfeld x x x x
    Comment History Anzeige Anzeige der Kommentarhistory mit Datum/Uhrzeit
    Created/Modified Anzeige Anzeige des Creation/Modification Date wie im Patient Chart
    Create Folgestatus abhängig ”von Einstellungen zur Requestfreigabe” (durch Manager)
    Approve Approve-Button im Staus ”Requested” auf CBB-Seite nur sichtbar wenn ”Requestfreigabe” aktiviert
    Save
    Cancel Canceled Canceled (mit Abfrage/Hinweis Kosten)
    Refuse
    Reject Rejected Rejected
    Process Process-Button im Staus ”Requested” auf CBB-Seite ausblenden wenn ”Requestfreigabe” aktiviert Processing
    Completed Completed
    Received
    Tabelle 4.3: HLA-Typing Request – Workflow/Daten
    CBB Clinic CBB Clinic
    Label Type Mandatory Beschreibung Completed Completed Received Received
    HLA-A Anzeige Anzeige Original-HLA-Werte der CBU
    HLA-B Anzeige Anzeige Original-HLA-Werte der CBU
    HLA-C Anzeige Anzeige Original-HLA-Werte der CBU
    HLA-DRB1 Anzeige Anzeige Original-HLA-Werte der CBU
    HLA-DQB1 Anzeige Anzeige Original-HLA-Werte der CBU
    HLA-A (Low/Medium/High/None) Optionsfeld x Optionsfelder zur Auswahl der Typing-Auflösung (siehe Screenentwurf), Default komplett leer
    HLA-B (Low/Medium/High/None) Optionsfeld x Optionsfelder zur Auswahl der Typing-Auflösung (siehe Screenentwurf), Default komplett leer
    HLA-C (Low/Medium/High/None) Optionsfeld x Optionsfelder zur Auswahl der Typing-Auflösung (siehe Screenentwurf), Default komplett leer
    HLA-DRB1 (Low/Medium/High/None) Optionsfeld x Optionsfelder zur Auswahl der Typing-Auflösung (siehe Screenentwurf), Default komplett leer
    HLA-DQB1 (Low/Medium/High/None) Optionsfeld x Optionsfelder zur Auswahl der Typing-Auflösung (siehe Screenentwurf), Default komplett leer
    HLA-A Eingabefeld String (HLA-Wert) Werte für beide Loci, n digits + N, Validierung mit HLA-Validator,
    HLA-B Eingabefeld String (HLA-Wert) Werte für beide Loci, n digits + N, Validierung mit HLA-Validator,
    HLA-C Eingabefeld String (HLA-Wert) Werte für beide Loci, n digits + N, Validierung mit HLA-Validator,
    HLA-DRB1 Eingabefeld (String HLA-Wert) Werte für beide Loci, n digits + N, Validierung mit HLA-Validator,
    HLA-DQB1 Eingabefeld String (HLA-Wert) Werte für beide Loci, n digits + N, Validierung mit HLA-Validator,
    Typing available until Date x (nicht mandatory im Status ”requested” wenn ”Requestfreigabe” aktiviert) Datum. Bis wann das Typing wahrscheinlich abgeschlossen sein wird
    Contact Person (Coordinator) Text x Vorbelegt mit Kontaktdaten des SC Users (Komplette Felder laut Spec)
    Billing Address Text x Vorbelegen mit Rechnungsanschrift der Klinik des Patienten (Komplette Felder laut Spec)
    Comment Text Standard Kommentarfeld x
    Comment History Anzeige Anzeige der Kommentarhistory mit Datum/Uhrzeit
    Created/Modified Anzeige Anzeige des Creation/Modification Date wie im Patient Chart
    Create Folgestatus abhängig von Einstellungen zur ”Requestfreigabe” (durch Manager)
    Approve Approve-Button im Staus ”Requested” auf CBB-Seite nur sichtbar wenn ”Requestfreigabe” aktiviert
    Save
    Cancel
    Refuse
    Reject
    Process Process-Button im Staus ”Requested” auf CBB-Seite ausblenden wenn ”Requestfreigabe” aktiviert
    Completed
    Received Received
    Tabelle 5.1: Colony Assay Request – Workflow/Daten
    Clinic Clinic CBB Clinic
    Label Type Mandatory Beschreibung Create Waiting for approval Requested Requested
    Available until Date x (nicht mandatory im Status ”requested” wenn ”Requestfreigabe” aktiviert) Datum. Bis wann das Ergebnis vorliegt x
    BFU-E Float
    CFU-GM Float
    CFU-GEMM Float
    Additional Results Text mehrzeiliges Textfeld für weitere Ergebnisse
    Contact Person (Coordinator) Text x Vorbelegt mit Kontaktdaten des SC Users (Feld nicht in Spec, aber falls ohne größeren Aufwand möglich bitte ergänzen) x x
    Billing Address Text x Vorbelegen mit Rechnungsanschrift der Klinik des Patienten (Komplette Felder laut Spec) x x
    Comment Text Standard Kommentarfeld x x x x
    Comment History Anzeige Anzeige der Kommentarhistory mit Datum/Uhrzeit
    Created/Modified Anzeige Anzeige des Creation/Modification Date wie im Patient Chart
    Create Folgestatus abhängig von Einstellungen zur ”Requestfreigabe” (durch Manager) ”Requested” oder ”Waiting for approval”
    Approve Approve-Button im Staus ”Requested” auf CBB-Seite nur sichtbar wenn ”Requestfreigabe” aktiviert Requested Approved
    Save
    Cancel Canceled Canceled
    Refuse Refused
    Reject Rejected
    Process Process-Button im Staus ”Requested” auf CBB-Seite ausblenden wenn ”Requestfreigabe” aktiviert Processing
    Completed
    Received
    Tabelle 5.2: Colony Assay Request – Workflow/Daten
    CBB Clinic CBB Clinic
    Label Type Mandatory Beschreibung Approved Approved Processing Processing
    Available until Date x (nicht mandatory im Status ”requested” wenn ”Requestfreigabe” aktiviert) Datum. Bis wann das Ergebnis vorliegt x x
    BFU-E Float x
    CFU-GM Float x
    CFU-GEMM Float x
    Additional Results Text mehrzeiliges Textfeld für weitere Ergebnisse x
    Contact (Person Coordinator) Text x Vorbelegt mit Kontaktdaten des SC Users (Feld nicht in Spec, aber falls ohne größeren Aufwand möglich bitte ergänzen)
    Billing Address Text x Vorbelegen mit Rechnungsanschrift der Klinik des Patienten (Komplette Felder laut Spec)
    Comment Text Standard Kommentarfeld x x x x
    Comment History Anzeige Anzeige der Kommentarhistory mit Datum/Uhrzeit
    Created/Modified Anzeige Anzeige des Creation/Modification Date wie im Patient Chart
    Create Folgestatus abhängig von Einstellungen zur ”Requestfreigabe” (durch Manager)
    Approve Approve-Button im Staus ”Requested” auf CBB-Seite nur sichtbar wenn ”Requestfreigabe” aktiviert
    Save
    Cancel Canceled Canceled (Abfrage/Hinweis Kosten)
    Refuse
    Reject Rejected Rejected
    Process Process-Button im Staus ”Requested” auf CBB-Seite ausblenden wenn ”Requestfreigabe” aktiviert Processing
    Completed Completed
    Received
    Tabelle 5.3: Colony Assay Request – Workflow/Daten
    CBB Clinic CBB Clinic
    Label Type Mandatory Beschreibung Completed Completed Received Received
    Available until Date x (nicht mandatory im Status ”requested” wenn ”Requestfreigabe” aktiviert) Datum. Bis wann das Ergebnis vorliegt
    BFU-E Float
    CFU-GM Float
    CFU-GEMM Float
    Additional Results Text mehrzeiliges Textfeld für weitere Ergebnisse
    Contact Person (Coordinator) Text x Vorbelegt mit Kontaktdaten des SC Users (Feld nicht in Spec, aber falls ohne größeren Aufwand möglich bitte ergänzen)
    Billing Address Text x Vorbelegen mit Rechnungsanschrift der Klinik des Patienten (Komplette Felder laut Spec)
    Comment Text Standard Kommentarfeld x
    Comment History Anzeige Anzeige der Kommentarhistory mit Datum/Uhrzeit
    Created/Modified Anzeige Anzeige des Creation/Modification Date wie im Patient Chart
    Create Folgestatus abhängig von Einstellungen zur ”Requestfreigabe” (durch Manager)
    Approve Approve-Button im Staus ”Requested” auf CBB-Seite nur sichtbar wenn ”Requestfreigabe” aktiviert
    Save
    Cancel
    Refuse
    Reject
    Process Process-Button im Staus ”Requested” auf CBB-Seite ausblenden wenn ”Requestfreigabe” aktiviert
    Completed
    Received Received
    Tabelle 6: Abstract request status text
    Requesttyp Status Text
    Alle beliebig <requesttyp> – <status> at <date of status change>
    Sonderfälle
    Reservation Reserved\Extended Reserved until <reservation until date>
    Order Processing\Shipped <requesttyp> – <status> – delivery at <delivery date>
    HLA Typing, Sample, Colony Assay Processing <requesttyp> – <status> since <date of status change>
    Sample Shipped <requesttyp> – shipped at <shipment date>
    Alle Waiting for Approval <requesttyp> – <status> since <date of status change>
    Tabelle 7: Request Bestätigunsdialog-Texte (Schema)
    Requesttyp Part Aktion Message Type Text
    Alle C/CBB/BO beliebig Message Do you really want to <Aktion> the <requesttype> request?
    Sonderfälle
    Alle CBB/BO Reject Warning Do you really want to reject the <requesttype> request?
    Reservation C Cancel Warning Do you really want to cancel the <requesttype> request?
    Order, DNA Sample, HLA Typing, Colony Assay C Cancel Warning Do you really want to cancel the <requesttype> request? There may be costs associated.
    Order, DNA Sample, HLA Typing, Colony Assay C Create Warning Do you really want to create the <requesttype> request? You will be charged for the costs incurred.
    Order, DNA Sample, HLA Typing, Colony Assay C Approve Warning Do you really want to approve the <requesttype> request? You will be charged for the costs incurred.
    Order CBB Inquiry placed Message Do you really want to place an inquiry for the <requesttype> request?
    Order C Inquiry Answered Message Do you really want to answer the inquiry for the <requesttype> request?
    Order, DNA Sample CBB Shipped Message Do you really want to set the <requesttype> request to ”shipped”?
    Order, DNA Sample C Shipping Failed Message Do you really want to set the <requesttype> request to ”shipping failed”?
    Order, DNA Sample, HLA Typing, Colony Assay C Received Message Do you really want to set the <requesttype> request to ”received”?
    DNA Sample, HLA Typing, Colony Assay C/CBB (Typing) Completed Message Do you really want to set the <requesttype> request to ”completed”?
    C – Clinic
    CBB – Cord Clood Bank
    BO – Back Office
    Tabelle 8: Request-Maske Status-Graphiken
    Schritte in Requestgrafik
    Schritt 1 Schritt 2 Schritt 3 Schritt 4 Schritt 5 Schritt 6 in Status
    HLA Typing Request
    Create Requested Processing Completed Received ”Creation” or ”Waiting for approval”
    Create Requested Processing Completed Received Requested
    Create Requested Processing Completed Received ”Approved” or ”Processing”
    Create Requested Processing Completed Received Completed
    Create Requested Processing Completed Received Received
    Create Requested Canceled Canceled
    Create Requested Rejected Rejected
    Create Refused Refused
    Order Request
    Create Requested Processing Shipped Received ”Creation” or ”Waiting for approval”
    Create Requested Processing Shipped Received Requested
    Create Requested Processing Shipped Received ”Approved” or ”Processing”
    Create Requested Processing Shipped Received Shipped
    Create Requested Processing Shipped Received Received
    Create Requested Processing Shipped Shipment Failed Shipment failed
    Create Requested Inquiry Processing Shipped Received Inquiry
    Create Requested Inquiry Answered Processing Shipped Received Inquiry anwered
    Create Requested Processing Adjusted Shipped Received Adjusted
    Create Requested Canceled Canceled
    Create Requested Rejected Rejected
    Create Refused Refused
    Sample Request
    Create Requested Processing Shipped Received Typing Comp. ”Creation” or ”Waiting for approval”
    Create Requested Processing Shipped Received Typing Comp. Requested
    Create Requested Processing Shipped Received Typing Comp. ”Approved” or ”Processing”
    Create Requested Processing Shipped Received Typing Comp. Shipped
    Create Requested Processing Shipped Received Typing Comp. Received
    Create Requested Processing Shipped Received Typing Compl. Typing completed
    Create Requested Processing Shipped Shipment Failed Shipment failed
    Create Requested Canceled Canceled
    Create Requested Rejected Rejected
    Create Refused Refused
    Reservation Request
    Create CBU reserved CBU Ordered ”Creation” or ”Waiting for a pproval”
    Create CBU reserved CBU Ordered CBU reserved
    Create CBU reserved CBU Ordered CBU ordered
    Create CBU reserved Extended CBU Ordered Extended
    Create CBU reserved Expired Expired
    Create CBU reserved Canceled Canceled
    Create CBU reserved Rejected Rejected
    Create Refused Refused
    Colony Assay Request
    Create Requested Processing Completed Received ”Creation” or ”Waiting for approval”
    Create Requested Processing Completed Received Requested
    Create Requested Processing Completed Received ”Approved” or ”Processing”
    Create Requested Processing Completed Received Completed
    Create Requested Processing Completed Received Received
    Create Requested Canceled Canceled
    Create Requested Rejected Rejected
    Create Refused Refused
    Tabelle 9.1: Request conditions overview (Sichtbarkeit/Editierbarkeit)
    Clinic
    Manager Manager + Owner Supervisor Supervisor + Owner Coordinator Coordinator + Owner
    ”Waiting for approval” S/M/A S/M/A S S S S
    ”Cancel” S S S S S S
    ”Refused” S S S S/M S S/M
    ”Requested” (approval activ) S S S S S S
    ”Requested” (no approval) S S S S S S
    ”Approved” S S S S S S
    ”Rejected” S S/M S S/M S S/M
    ”Inquiry” S S/M/A S S/M/A S S/M/A
    ”Inquiry answered S S S S S S
    ”Processing” S S/M S S/M S S/M
    ”Adjusted” S S S S S S
    ”Shipped” S S/M/A S S/M/A S S/M/A
    ”Shipping failed” S S S S S S
    ”Received” S S/M*/A* S S/M*/A* S S/M*/A*
    ”Completed” S S/M/A S S/M/A S S/M/A
    ”Typing completed” S S S S S S
    ”Extended” S S S S S S
    ”Expired” S S/M S S/M S S/M
    Tabelle 9.2: Request conditions overview (Sichtbarkeit/Editierbarkeit)
    CBB Bemerkungen
    Manager Supervisor Coordinator
    ”Waiting for approval” - - -
    ”Cancel” S S/M* S/M* * Vorraussetzung auf CBB-Seite, der Request war vor Erreichen des Status ”Canceled” bereits auf CBB-Seite sichtbar.
    ”Refused” - - -
    ”Requested” (approval activ) S/M/A - -
    ”Requested” (no approval) S S/M/A S/M/A
    ”Approved” S S/M/A S/M/A
    ”Rejected” S S S
    ”Inquiry” S S S
    ”Inquiry answered S S/M/A S/M/A
    ”Processing” S S/A S/A
    ”Adjusted” S S/M/A S/M/A
    ”Shipped” S S S
    ”Shipping failed” S S/M S/M
    ”Received” S S/M S/M * Nur im Falle des Sample Requests
    ”Completed” S S S
    ”Typing completed” S S S
    ”Extended” S S/M S/M
    ”Expired” S S S
    S = Sichtbarkeit: Der Nutzer kann den Request in der Reqeust-Overview sehen. Auch hier gilt generell, der Nutzer muss der Klinik/CBB zugewiesen sein und Klinik-Koordinatoren sehen nur Ihre eigenen Requests.
    M = Markierung: Der Request wird für den Nutzer bei Erreichen des Status markiert. Nach Aufrufen des Requests verschwindet die Markierung. Erreicht der Request denselben Status erneut, dadurch das ein Nutzer mit einer Rolle der anderen Seite (Clinic Rollen vs. CBB-Rollen) eine Änderung vorgenommen hat, wird der Request erneut markiert (zum Beispiel Erneutes Speichern nach Änderung der Klinikadresse eines Requests im Status ”Requested” hat zur Folge, dass auf Seiten CBB der Request neu markiert wird)
    A = Aktion erforderlich: Der Nutzer muss eine Aktion durchführen, um den Workflow fortzusetzen. Das Feld ”Action required” wird auf ”Yes” gesetzt.
    Owner: Der Nutzer ist Owner des Requests d. h. er ist dem Patienten welchem die Lösung und die damit verbunden CBUs und deren Requests zugehörig sind zugeordnet.

Claims (60)

  1. Steuerungssystem für verteilte Organisationsstrukturen, umfassend mindestens eine Organisation, umfassend mindestens eine Organisationseinheit, wobei die Organisationseinheit fachliche Attribute besitzt und wobei die Organisationseinheiten Anbieter und/oder Abfrager sein können, mindestens zwei Nutzer, wobei die Nutzer mindestens einer Organisation zugewiesen sind, mindestens eine Rolle, wobei die Rolle mindestens einem Nutzer zugewiesen ist und wobei die Rolle die verfügbaren Funktionalitäten innerhalb der dem Nutzer zugewiesenen Organisation bestimmt, wobei die Organisation, welcher ein Nutzer zugewiesen ist, die Ansicht bestimmt, welche dem Nutzer angezeigt wird und wobei ein erster Nutzer einen Suchauftrag erstellen kann, welcher an Organisationen gesendet wird, die Anbieter-Organisationseinheiten umfassen und wobei der Nutzer anschließend eine Anfrage an eine Organisation stellen kann und wobei ein weiterer Nutzer, der der Organisation zugeordnet ist, an welche die Anfrage gestellt wurde, die Anfrage bearbeitet.
  2. Steuerungssystem nach Anspruch 1, wobei die Organisationseinheit ausgewählt aus der Gruppe umfassend Verbund, Klinik, Einrichtung und/oder Verwaltung.
  3. Steuerungssystem nach Anspruch 2, wobei ein Verbund bevorzugt ein Verbund von mindestens zwei Kliniken, ein Verbund von mindestens zwei Einrichtungen oder ein Verbund aus mindestens einer Klinik und mindestens einer Einrichtung ist.
  4. Steuerungssystem nach mindestens einem der vorhergehenden Ansprüche, wobei, die Einrichtung ausgewählt aus der Gruppe umfassend eine Nabelschnurblutbank, eine Blutbank, eine Stammzellbank, eine Gewebebank und/oder eine Organbank.
  5. Steuerungssystem nach mindestens einem der vorhergehenden Ansprüche, wobei die Rolle ausgewählt ist aus der Gruppe umfassen Administrator, Manager, Supervisor, Koordinator.
  6. Steuerungssystem nach mindestens einem der vorhergehenden Ansprüche, wobei die Rollen hierarchisch aufgebaut sind.
  7. Steuerungssystem nach mindestens einem der vorhergehenden Ansprüche, wobei der weitere Nutzer, der der Organisation zugeordnet ist, an welche die Anfrage gestellt wurde, die Anfrage bearbeitet, nämlich annimmt und dem Nutzer, der die Anfrage gestellt hat die Annahme angezeigt wird.
  8. Steuerungssystem nach mindestens einem der vorhergehenden Ansprüche, wobei der weitere Nutzer, der der Organisation zugeordnet ist, an welche die Anfrage gestellt wurde, die Anfrage bearbeitet und ein Freigabeschritt aktiviert wird.
  9. Steuerungssystem nach mindestens einem der vorhergehenden Ansprüche, wobei der Nutzer eine Anfrage an eine Organisation stellt zur Identifikation von Inventaren, wobei die Inventare in lokal verfügbaren Datenbanksystemen und in entfernten Datenbanksystemen gespeichert sind, dadurch gekennzeichnet, dass 1) lokal verfügbare Datenbanksysteme und/oder lokale Kopien von Inventaren aus entfernten Datenbanksystemen durchsucht werden und 2) Abfragedaten an entfernte Datenbanksysteme gesendet werden, wobei die Datenbanksysteme synchron und/oder asynchron antworten können, und 3) die Ergebnisse angezeigt werden, wobei dem Nutzer asynchron eintreffende Ergebnisse aus entfernten Datenbanksystemen in bestimmten Zeitintervallen angezeigt werden, und 4) wobei die Ergebnisse aus entfernten Datenbanksystemen im Cache gespeichert werden.
  10. Steuerungssystem nach dem vorhergehenden Anspruch, wobei die im Cache gespeicherten Ergebnisse aktualisiert werden.
  11. Steuerungssystem nach Anspruch 9 oder 10, wobei regelmäßig automatische Suchanfragen an entfernte Datenbanksysteme gestellt werden und die Ergebnisse im Cache gespeichert werden.
  12. Verwendung eines Steuerungssystem gemäß mindestens einem der vorhergehenden Ansprüche zur Identifikation von Inventaren aus lokal verfügbaren Datenbanksystemen und entfernten Datenbanksystemen, dadurch gekennzeichnet, dass 1) lokal verfügbare Datenbanksysteme und/oder lokale Kopien von Inventaren aus entfernten Datenbanksystemen durchsucht werden und 2) Abfragedaten an entfernte Datenbanksysteme gesendet werden, wobei die Datenbanksysteme synchron und/oder asynchron antworten können, und 3) die Ergebnisse angezeigt werden, wobei dem Nutzer asynchron eintreffende Ergebnisse aus entfernten Datenbanksystemen in bestimmten Zeitintervallen angezeigt werden, und 4) wobei die Ergebnisse aus entfernten Datenbanksystemen im Cache gespeichert werden.
  13. Verwendung nach dem vorhergehenden Anspruch zur Identifikation einer Nabelschnurbluteinheit.
  14. Steuerungssystem nach mindestens einem der vorhergehenden Ansprüche, wobei über den Verbund Nutzer auch mehreren Kliniken und/oder Nabelschnurblutdatenbank zugewiesen sind.
  15. Steuerungssystem nach mindestens einem der vorhergehenden Ansprüche, wobei die Plattform und/oder das System organisationsunabhängige Nutzer unterstützen.
  16. Steuerungssystem nach mindestens einem der vorhergehenden Ansprüche, wobei das Back-Office eine eigene Organisationseinheit ist, welche bevorzugt mit keinen weiteren Organisationseinheiten zusammengeschlossen ist.
  17. Steuerungssystem nach mindestens einem der vorhergehenden Ansprüche, wobei ein Nutzer einem Verbund, einer Klinik, einer Einrichtung oder einem Back-Office zugeordnet ist.
  18. Steuerungssystem nach mindestens einem der vorhergehenden Ansprüche, wobei der Nutzer nicht gleichzeitig einem Verbund und eigenständigen Organisationseinheiten zugewiesen ist.
  19. Steuerungssystem nach mindestens einem der vorhergehenden Ansprüche, wobei die verfügbaren Funktionen innerhalb der Organisationen und Organisationseinheiten über ein Rollenkonzept definiert sind.
  20. Steuerungssystem nach mindestens einem der vorhergehenden Ansprüche, wobei einem Nutzer Rollen zugewiesen werden, welche die verfügbare Funktionalität innerhalb der dem Nutzer zugewiesenen Organisationseinheit(en) definieren.
  21. Steuerungssystem nach mindestens einem der vorhergehenden Ansprüche, wobei die Rolle eines Managers über die Funktionalität der Zustimmung zu Annahme-Prozessen verfügt.
  22. Steuerungssystem nach mindestens einem der vorhergehenden Ansprüche, wobei die Rolle eines Supervisors den Zugriff auf alle Daten der zugeordneten Organisationseinheiten erlaubt sowie deren Lesen, Schreiben und/oder Löschen.
  23. Steuerungssystem nach mindestens einem der vorhergehenden Ansprüche, wobei die Rolle eines Koordinators (auch Coordinator) den Zugriff auf eigene Daten der zugeordneten Organisationseinheiten erlaubt sowie deren Lesen, Schreiben und/oder Löschen.
  24. Steuerungssystem nach mindestens einem der vorhergehenden Ansprüche, wobei eine höhere Ebene immer die Funktionalitäten der darunter befindlichen Ebene beinhaltet.
  25. Steuerungssystem nach mindestens einem der vorhergehenden Ansprüche, wobei die Zugriffsrechte eines BackOffice Agenten gegenüber dem Back Office-Administrator eingeschränkt sind.
  26. Steuerungssystem nach mindestens einem der vorhergehenden Ansprüche, wobei der BackOffice Agent keine Patientendaten und Nabelschnurbluteinheiten beziehungsweise Daten verwaltet.
  27. Steuerungssystem nach mindestens einem der vorhergehenden Ansprüche, wobei die Rolle eines Klinik-Managers die Freigabe von zustimmungspflichtigen Anfragen beziehungsweise Requests erlaubt.
  28. Steuerungssystem nach mindestens einem der vorhergehenden Ansprüche, wobei die Rolle eines Nabelschnurblutdatenbank-Managers die Freigabe von zustimmungspflichtigen Anfragen beziehungsweise Requests erlaubt.
  29. Steuerungssystem nach mindestens einem der vorhergehenden Ansprüche, wobei ein Klinik-Supervisor für zugeordnete Kliniken Zugriff auf Patientendaten, Nachrichten, Ärztedaten, Suchprofile und Klinikdaten hat.
  30. Steuerungssystem nach mindestens einem der vorhergehenden Ansprüche, wobei ein Nabelschnurblutdatenbank-Supervisor für zugeordnete Nabelschnurblutdatenbanken Zugriff auf Daten von Nabelschnurbluteinheiten (CBUs), Nabelschnurblutdatenbank-Daten hat.
  31. Steuerungssystem nach mindestens einem der vorhergehenden Ansprüche, wobei die Rolle eines Klinik-Koordinators für zugeordnete Kliniken Zugriff auf eigene, insbesondere selbst angelegte Patientendaten und Nachrichten zu diesen Patienten erlaubt.
  32. Steuerungssystem nach mindestens einem der vorhergehenden Ansprüche, wobei die Rolle eines Nabelschnurblutdatenbank-Koordinators für zugeordnete Nabelschnurblutdatenbanken den Zugriff auf Nachrichten erlaubt.
  33. Steuerungssystem nach mindestens einem der vorhergehenden Ansprüche, wobei die Rollen abhängig von den Organisationseinheiten sind, denen der Nutzer zugewiesen ist.
  34. Steuerungssystem nach mindestens einem der vorhergehenden Ansprüche, wobei alleinig BackOffice Nutzer eine Berechtigung zur Anlage von Organisationen und Organisationseinheiten und zur Anpassung von Organisationsstrukturen haben.
  35. Steuerungssystem nach mindestens einem der vorhergehenden Ansprüche, wobei nur Back Office Nutzer Kliniken, Nabelschnurblutdatenbanken und Verbünde anlegen und löschen.
  36. Steuerungssystem nach mindestens einem der vorhergehenden Ansprüche, wobei das Steuerungssystem auch auf andere Organisationen neben einem Register anzuwenden ist.
  37. Steuerungssystem nach mindestens einem der vorhergehenden Ansprüche, wobei das Steuerungssystem durch eine Neustrukturierung der fachlichen Daten die Unterstützung von Verbünden erlaubt.
  38. Steuerungssystem nach mindestens einem der vorhergehenden Ansprüche, wobei die Plattform das Anlegen von Verbünden von Kliniken und/oder Nabelschnurblutbanken als Organisationseinheit unterstützt.
  39. Steuerungssystem nach mindestens einem der vorhergehenden Ansprüche, wobei eigenständige Kliniken und eigenständige Einrichtungen als Organisationseinheit unterstützt werden.
  40. Steuerungssystem nach mindestens einem der vorhergehenden Ansprüche, wobei die Organisationseinheiten fachliche Attribute besitzen.
  41. Steuerungssystem nach mindestens einem der vorhergehenden Ansprüche, wobei die Ansichten Gruppen (Group) Ansicht, Kliniken Ansicht, Nabelschnurblutdatenbank Ansicht, BackOffice-Ansicht unterstützt werden.
  42. Steuerungssystem nach mindestens einem der vorhergehenden Ansprüche, wobei die Sichtbarkeit von Funktionalitäten oder Menüeinträgen, welche den Zugriff ermöglichen, von der Zuordnung des Nutzers zu den Organisationen oder den Organisationseinheiten und seinen Rollen abhängig ist.
  43. Steuerungssystem nach mindestens einem der vorhergehenden Ansprüche, wobei eine Komponente oder Ansicht Zugriff auf Ansichten ausgewählt aus der Gruppe Kliniken Ansicht, Nabelschnurblutdatenbank Ansicht, User Übersicht, Präferenzen gewährt.
  44. Steuerungssystem nach mindestens einem der vorhergehenden Ansprüche, wobei individuell bestimmt ist, welche Daten durch einen Nutzer abzurufen beziehungsweise zu bearbeiten sind.
  45. Steuerungssystem nach mindestens einem der vorhergehenden Ansprüche, wobei für Funktionalitäten einer Nabelschnurblutdatenbank eine Komponente beziehungsweise Ansicht die Funktionalitäten Nachrichten-Zugriff auf ”Nabelschnurblutdatenbank Nachrichten-Übersicht”, Nabelschnurbluteinheiten (CBU) Management-Zugriff auf ”CBU Übersicht”, Nabelschnurblutdatenbanken-Zugriff auf ”Nabelschnurblutdatenbank Übersicht”, Users-Zugriff auf ”Users Übersicht”, Präferenzen-Zugriff auf Präferenzen des aktuell eingeloggten Nutzers zur Verfügung stellt.
  46. Steuerungssystem nach mindestens einem der vorhergehenden Ansprüche, wobei für Funktionalitäten des Back Office eine Komponente beziehungsweise Ansicht die Funktionalitäten Nachrichten-Zugriff auf ”BackOffice Message Übersicht”, Organisations-Zugriff auf ”Organisations-Ansicht”, Users-Zugriff auf ”Users Übersicht”, Präferenzen zur Verfügung stellt.
  47. Steuerungssystem nach mindestens einem der vorhergehenden Ansprüche, wobei eine Organisations-Übersicht tabellarisch und hierarchisch die Organisationen sowie deren Daten darstellt.
  48. Steuerungssystem nach mindestens einem der vorhergehenden Ansprüche, wobei das Anlegen von Nutzern für das Back Office über den direkten Zugriff aus der Back Office Ansicht heraus geschieht.
  49. Steuerungssystem nach mindestens einem der vorhergehenden Ansprüche, wobei bei Kliniken-Übersicht Kliniken, sowie die einer Klinik zugeordneten Daten dargestellt sind.
  50. Steuerungssystem nach mindestens einem der vorhergehenden Ansprüche, wobei die Darstellung der Kliniken durch die Zuordnung des Nutzers eingeschränkt ist.
  51. Steuerungssystem nach mindestens einem der vorhergehenden Ansprüche, wobei die Darstellung der Nabelschnurblutdatenbanken durch die Zuordnung des Nutzers eingeschränkt ist.
  52. Steuerungssystem nach mindestens einem der vorhergehenden Ansprüche, wobei der Zugriff auf die Users Übersicht nur Nutzern mit Administratorrollen beziehungsweise BackOffice Nutzern gestattet ist.
  53. Steuerungssystem nach mindestens einem der vorhergehenden Ansprüche, wobei das System eine Erstelle/Editieren User Ansicht umfasst.
  54. Steuerungssystem nach mindestens einem der vorhergehenden Ansprüche, wobei die Rollen gruppiert dargestellt sind.
  55. Steuerungssystem nach mindestens einem der vorhergehenden Ansprüche, wobei die Bestätigungsschritte nur durch Nutzer in Managerrolle durchführbar sind.
  56. Steuerungssystem nach mindestens einem der vorhergehenden Ansprüche, wobei nur Nutzer mit Nutzerrollen Klinik Administrator, Nabelschnurblutdatenbank Administrator, BackOffice-User die Bestätigungsschritte aktivieren beziehungsweise editieren.
  57. Steuerungssystem nach mindestens einem der vorhergehenden Ansprüche, wobei auf der Seite der Nabelschnurblutdatenbank „Requests” nur für Nutzer mit der Rolle ”Nabelschnurblutdatenbank Supervisor” und ”Nabelschnurblutdatenbank Coordinator” markiert sind, wenn die „Requests” neu sind beziehungsweise von der Gegenseite geändert wurden.
  58. Steuerungssystem nach mindestens einem der vorhergehenden Ansprüche, wobei das System zur Identifikation einer Nabelschnurbluteinheit verwendbar ist.
  59. Steuerungssystem nach mindestens einem der vorhergehenden Ansprüche, wobei das System eine Technologie zur Suche nach Stammzellprodukten in verteilten Inventaren ist.
  60. Steuerungssystem nach mindestens einem der vorhergehenden Ansprüche, wobei das System die Suche in direkten bereitgestellten Inventaren von zum Beispiel Stammzellprodukten unterstützt.
DE202012012534U 2011-11-18 2012-11-19 Zentrale Steuerung verteilter Organisationsstrukturen Expired - Lifetime DE202012012534U1 (de)

Applications Claiming Priority (6)

Application Number Priority Date Filing Date Title
US201161561398P 2011-11-18 2011-11-18
US61/561,398 2011-11-18
EP11075252 2011-11-18
EP11075252.4 2011-11-18
EP11075253 2011-11-18
EP11075253.2 2011-11-18

Publications (1)

Publication Number Publication Date
DE202012012534U1 true DE202012012534U1 (de) 2013-05-13

Family

ID=48429018

Family Applications (1)

Application Number Title Priority Date Filing Date
DE202012012534U Expired - Lifetime DE202012012534U1 (de) 2011-11-18 2012-11-19 Zentrale Steuerung verteilter Organisationsstrukturen

Country Status (6)

Country Link
US (1) US20140324455A1 (de)
EP (1) EP2780870A1 (de)
AU (1) AU2012338744A1 (de)
DE (1) DE202012012534U1 (de)
SG (2) SG11201402403XA (de)
WO (1) WO2013072524A1 (de)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20160306503A1 (en) * 2015-04-16 2016-10-20 Vmware, Inc. Workflow Guidance Widget with State-Indicating Buttons

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020082866A1 (en) * 2000-06-27 2002-06-27 Dave Ladouceur Integrated management of medical information
US6615317B2 (en) * 2000-07-07 2003-09-02 Fitech Laboratories, Inc. Methods and systems for providing a highly scalable synchronous data cache
EP1851667A4 (de) * 2005-02-11 2011-06-08 Hipaat Inc System und verfahren zur privatsphärenverwaltung
US20060218394A1 (en) * 2005-03-28 2006-09-28 Yang Dung C Organizational role-based controlled access management system

Also Published As

Publication number Publication date
SG10201602914TA (en) 2016-05-30
US20140324455A1 (en) 2014-10-30
SG11201402403XA (en) 2014-09-26
WO2013072524A1 (de) 2013-05-23
EP2780870A1 (de) 2014-09-24
AU2012338744A1 (en) 2014-06-05

Similar Documents

Publication Publication Date Title
DE60025778T2 (de) Verfahren zum Speichern und Verwalten von Daten
Goldman et al. Legal status and health insurance among immigrants
DE60038707T2 (de) Internet-Schnittstellensystem
EP2989563B1 (de) Datenbank verwaltungssystem
EP1783633B1 (de) Suchmaschine für eine ortsbezogene Suche
DE102006057149A1 (de) System und Verfahren zum Erleichtern eines visuellen Vergleichs von Eingangsdaten mit vorhandenen Daten
DE102007026799A1 (de) Systeme und Verfahren zur Verfeinerung der Identifikation von Kandidaten für klinische Studien
EP1611538A2 (de) Verfahren und anordnung zur automatischen aufbereitung und auswertung medizinischer daten
DE69709918T2 (de) Relationelle datenbank die in einer speicherstruktur compiliert und gespeichert ist
DE102021123842A1 (de) Bewertung einer verringerung eines krankheitsrisikos und behandlungsentscheidung
DE102018132623A1 (de) System und Verfahren zur Informationsübermittlung von Gesundheitsinformationen
DE202012012534U1 (de) Zentrale Steuerung verteilter Organisationsstrukturen
DE202011107588U1 (de) System zum Erstellen und/oder Führen einer persönlichen Medikationsakte mithilfe eines Computersystems
EP3776257B1 (de) Objektdatenbank zur geschäftsmodellierung mit verbesserter datensicherheit
DE112020001314T5 (de) System und Verfahren für eine Datenkuration
DE602004001762T2 (de) Verfahren und computersystem zur datenzuweisung
DE60100846T2 (de) Verfahren und system zur verwaltung und benutzung von artikeldateien in einem informationsraum, insbesondere medizinische information, und verwendung in informationssystemen
Schaal et al. Deconstructing “The Truth about Post-Truth”. The contingencies of algorithm-based text analyses
Remmers et al. Bioethics, care and gender
Hand Süchte,«Verhaltenssüchte» und die neue «Sucht-Sucht»
EP1443447A2 (de) Drahtloses System und Verfahren zum Einfügen von kryptographischen Daten
WO2024067920A1 (de) Datenbank eines rechners
Praus et al. COVID-19 vaccinations in institutions for forensic commitment: some considerations on ethical and medico-legal aspects
DE102007052087A1 (de) System und Verfahren zur Erstellung von Rückmeldeberichten betreffend Heilberufler
DE102018108972A1 (de) Verfahren zur kommunikativen Vernetzung von digitalen Teilnehmern des Gesundheitswesens

Legal Events

Date Code Title Description
R207 Utility model specification

Effective date: 20130704

R081 Change of applicant/patentee

Owner name: PIRCHE AG, DE

Free format text: FORMER OWNER: CYTOLON AG, 10785 BERLIN, DE

R082 Change of representative

Representative=s name: HERTIN & PARTNER RECHTS- UND PATENTANWAELTE PA, DE

R150 Utility model maintained after payment of first maintenance fee after three years
R157 Lapse of ip right after 6 years