EP2780870A1 - Zentrale steuerung verteilter organisationsstrukturen - Google Patents

Zentrale steuerung verteilter organisationsstrukturen

Info

Publication number
EP2780870A1
EP2780870A1 EP12788202.5A EP12788202A EP2780870A1 EP 2780870 A1 EP2780870 A1 EP 2780870A1 EP 12788202 A EP12788202 A EP 12788202A EP 2780870 A1 EP2780870 A1 EP 2780870A1
Authority
EP
European Patent Office
Prior art keywords
request
user
cord blood
clinic
database systems
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP12788202.5A
Other languages
English (en)
French (fr)
Inventor
Andreas Schimanski
Ralf Schliehe-Diecks
Thomas Klein
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.)
Cytolon 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
Priority to EP12788202.5A priority Critical patent/EP2780870A1/de
Publication of EP2780870A1 publication Critical patent/EP2780870A1/de
Withdrawn legal-status Critical Current

Links

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

Definitions

  • the invention relates to a distributed organization structure control system comprising one or more organizations having one or more organizational units, wherein users are assigned to at least one organization and wherein roles are assigned to the users, the roles determining available functionalities within the organization assigned to the user. Moreover, the invention relates to
  • control system uses locally available database systems and remote database systems, preferably umbilical cord blood data.
  • this is usually about the request for certain drugs or, for example, transplants.
  • this is a sales process that is initiated by a search request based on specific criteria.
  • a disadvantage of the prior art is that the structure of organizations (for example, a register) is not supported. Thus, only limited possibilities are available.
  • the invention was therefore based on the problem that a control system must be provided which addresses the disadvantages of the prior art does not have technology and can support distributed organizational structures, especially with regard to the management of umbilical cord blood data.
  • the invention relates to a control system for distributed organizational structures, comprising at least one organization, comprising at least one organizational unit, wherein the organizational unit has technical attributes and wherein the organizational units can be providers and / or interrogators, at least two users, wherein the users at least assigned to an organization, at least one role, wherein the role is assigned to at least one user, and wherein the role determines the available functionalities within the organization assigned to the user, the organization to which a user is assigned determines the view that the user views and wherein a first user can create a search job that is sent to organizations that include provider organizational units, and then the user can make a request to an organization, and one further he user associated with the organization to which the request was made, the request processed.
  • An advantage of the invention is that the control system for many different
  • control system makes it possible Advantageously, to control a plurality of connected organizational units.
  • the organizational unit is selected from the group comprising composite, clinic, facility and / or administration. In doing so, the organizational unit can preferably assume different technical characteristics:
  • An association is preferably a combination of at least two clinics, a grouping of at least two institutions or a combination of at least one clinic and at least one institution.
  • Cord blood databases An association of one or more clinics and one or more umbilical cord blood bank (s) is also preferred.
  • a composite comprises a further composite. Also, there is no provision for clinics to include other clinics or one
  • Umbilical cord blood database includes other umbilical cord blood databases. Furthermore, an umbilical cord blood database can not contain a composite.
  • An organization corresponds to an organizational unit, for example, if the organizational unit is a stand-alone clinic. In such a case, the clinic is organizational unit and organization at the same time.
  • an organizational unit can also contain further organizational units (for example, a group contains a clinic). However, it is not possible for a clinic to contain a compound. Preferably, only one federation can contain further organizational units. It is preferred that a device is selected from the group comprising an umbilical cord blood bank, umbilical cord blood database, a blood bank, a stem cell bank, a donor registry, a tissue bank (also a tissue bank) and / or an organ bank.
  • a clinic contains one or more sub-clinics.
  • the concrete organizational unit (for example a clinic) is assigned to users.
  • One advantage of the invention is that users can also be assigned to several clinics and / or umbilical cord blood database via the composite. This user is enabled by the invention, a central access of the organization with only one account. It is preferable that a user assigned to a federation has no
  • a further advantage of the invention is that the platform and / or the system support organization-independent users. That is, it is no longer necessary, as in the prior art, for there to be specific "Search Center Users" and "Provider Users". Thus, the users are allowed to access different organizational units if they are associated with the organization to which these organizational units belong.
  • a user is assigned to the organization or organizational units for which he is responsible or active. There may be restrictions such that a user can only be assigned to individual organizational units within a network. The assignment to a compound therefore does not result in the assignment to all the organizational units belonging to the group; this must be done explicitly. As a result, an additional backup is installed, which is advantageous because in the personalized medical field is sometimes very sensitive data in which not every user should automatically get insight.
  • the assignment to the back office is also exclusive, which is already ensured by the fact that the back office is a separate organizational unit, which is preferably combined with no other organizational units.
  • the user receives an account with which he has access to the organizations or
  • a user is assigned to a network, a clinic, a facility or a back-office.
  • the user can not simultaneously a composite and independent
  • Organizations and organizational units are defined by a role concept. This means that the assignment defines only the access to the corresponding organizational units but not soft data can be specifically accessed and which processing can take place. This is important to enable privacy and to ensure a coordinated flow of inquiries and their response.
  • the role is preferably selected from the group comprising administrator, manager, supervisor, coordinator.
  • a user is assigned roles that define the available functionality within the user-assigned organizational unit (s).
  • the roles here are preferably hierarchical, that is to say a role always contains the authorizations of the role of a lower level.
  • Level represents the highest level: 1. Administrator 2. Manager
  • the role of the manager has the functionality of accepting acceptance processes.
  • the role of the supervisor allows access to all data of the associated
  • the role of the coordinator allows access to own data of the assigned organizational units and their reading, writing and / or deleting.
  • a higher level always includes the functionalities of the level below.
  • the following roles and functions result:
  • the clinic administrator has access to - Administration of hospital users
  • the access rights of the BackOffice Agent are limited to the Back Office administrator.
  • the BackOffice Agent can not provide patient information and
  • the role of the clinic manager allows the release of requests or requests requiring approval.
  • the clinic supervisor has access to patient data, messages, medical data, search profiles and clinical data for assigned clinics.
  • 3.2 Cord blood database supervisor (including all rights of role 4.2)
  • the umbilical cord blood database supervisor has access to umbilical cord blood unit (CBU) data, umbilical cord blood database data for associated umbilical cord blood databases
  • CBU umbilical cord blood unit
  • the role of the Clinic Coordinator allows associated clinics access to their own, in particular self-created patient data and messages to these patients.
  • the role of the umbilical cord blood database coordinator allows access to messages for associated umbilical cord blood databases.
  • the hierarchical role system eliminates the need to assign any number of roles to a user.
  • the roles are dependent on the
  • User is assigned to clinic (s) and receives clinic role 3.
  • User is assigned umbilical cord blood database (s) and receives one
  • the additional user associated with the organization to which the request has been made handle the request, namely accept and display the acceptance to the user who made the request.
  • the additional user assigned to the organization to which the request has been made, the request processed and a release step activated.
  • control system also applies to others
  • Organizations can be applied next to a register. It may be advantageous, for example, that the structure, preferably a method, a system and / or a Device is applied to pharmaceutical companies, government structures, pharmaceuticals, the distribution / management of drugs or treatment methods and / or establishes a link between the doctor, clinic, control instrument and / or authority, for example, to administer and / or appropriate drugs or treatment methods to distribute.
  • the invention may be referred to in particular as means for personalized medicine.
  • the invention allows the support of networks, for example registers, and thus simplifies previous systems in the field of personalized medicine.
  • the platform preferably the umbilical cord blood data platform, supports the creation of networks (for example a registry) of clinics and / or cord blood banks (umbilical cord blood databases) as an organizational unit. This provides new and improved ways to search for data or query inventory.
  • networks for example a registry
  • cord blood banks umbilical cord blood databases
  • independent clinics and stand-alone facilities will support as an organizational unit. That is, it may also continue to give preference clinics or facilities that are not associated with a network. An independent clinic is only those clinics that do not contain sub-clinics. It is particularly preferred that the system and / or the platform continue to be independent umbilical cord blood or umbilical cord blood databases
  • An advantage of the invention is the flexibility of the system, which allows it at any time to expand to other organizational units. For example, donor registers or tissue databases may be added as additional facilities and the Scope of the invention thus expand many times. These newly added facilities can also be part of a network.
  • the clinics and / or associations with clinics exist as "seekers” or “requestors” and on the other hand, facilities and / or associations with institutions that offer inventories, preparations and / or data. It is quite preferable that an umbilical cord blood database is the device and this
  • Umbilical cord blood units (Cordbloodunits) as preparations include or offer.
  • the organizational units have technical attributes. There are attributes that all organizational units have. Such attributes include: Name, Description, Address, Contact Person, Billing Address, Contact Person Billing, logo.
  • a composite has no further attributes. It is further preferred that a clinic and a facility have an identification (ID) as an additional attribute. In addition, it is preferred that the umbilical cord blood database has not only an identification but also an accreditation.
  • the attribute "default language" is no longer an attribute of the organizational units.
  • the default language is defined for the specific user. This prevents overlaps when a user is assigned to different organizational units.
  • Groups (Group) view (for groups containing clinics and facilities, preferably umbilical cord blood databases) 2. Clinics View (for groupings of clinics or for independent clinics)
  • Umbilical cord blood database view (for alliances of umbilical cord blood databases or independent umbilical cord blood databases) 4.
  • BackOffice view (for the administration of the system)
  • the user is then shown the respective view according to his assignment to organizational units or organizations.
  • the available functionalities in a view depend in turn on its user roles.
  • a user is assigned to one or more clinics. The user only sees the clinic view.
  • a user is associated with one or more umbilical cord blood databases. The user therefore only sees the umbilical cord blood database view.
  • a user is one or more clinics and one or more
  • the top level menu item is not displayed here. That is, "Groups View” and “Back Office View” are never displayed as menu items. "Clinics View” and “Cord Blood Database View” are displayed only if Clinic (s) and
  • Cord blood database exists in a network.
  • a component or view is necessary which grants access to the following views:
  • Patient Access to "Patient Overview” Contains patient data from an independent clinic or all clinics in the network
  • Compound contains only clinics, otherwise it is part of the composite view.
  • Umbilical cord blood database of the association of the association.
  • CBU Umbilical Cord Blood Units
  • Umbilical cord blood database or all umbilical cord blood databases of a network This view is only visible if composite is exclusive
  • Cord blood databases and networks are shown.
  • the system is navigated to the concrete network and the "Clinics Overview" and “Umbilical Cord Blood Database Overview” are accessed here. There, in turn, the creation of those in the direct context of the network is possible and the assignment is thus implicit.
  • the back office is technically also an organizational unit, but it represents a special organizational unit that it has no properties or the like. Creating users for the back office is done via direct access from the back office view.
  • the Clinics Overview displays the clinics as well as their data in a tabular context-dependent manner and allows access to the following functions: 1. Presented data
  • Umbilical cord blood databases as well as the processing of the umbilical cord blood database associated data. It does not matter if it is an independent one
  • Umbilical cord blood database Umbilical cord blood database, umbilical cord blood databases in umbilical cord blood database exclusive or mixed networks.
  • the umbilical cord blood database overview always displays the corresponding umbilical cord blood database (s) in tabular form. Only in the case of a BackOffice user, the functionality for creating an umbilical cord blood database for the corresponding group from which one has navigated the umbilical cord blood database overview must be available.
  • the representation of the umbilical cord blood databases is also limited by the assignment of the user. This means that the user sees only the umbilical cord blood databases to which he is assigned. A BackOffice user is not subject to these restrictions.
  • the users overview is also flexible and according to the navigation path or the organization the users are displayed in a table.
  • the Users Overview displays the users and their data in a tabular context-dependent manner and allows access to the following functions:
  • the system also includes a Create / Edit User View that provides the following functionality:
  • the user is always created and implicitly assigned in the context in which the Create function was called.
  • the user In the context of an independent clinic, the user is automatically assigned to this clinic. If you are in the context of a composite, the assignment is made to the composite. The detailed assignment to organizations of the network is as described above. In the context of the back office, the user is assigned to the back office.
  • the presentation of the roles has to be adapted, as there are no specific users (SearchCenter User / Cord Blood Database User) anymore.
  • the roles are preferably grouped:
  • the user to be created / created is a "composite user", ie the user was created in the context of a group (groups), it is possible in the Create / Edit User View to assign to the organizations (Klink (s) and / or (umbilical cord blood databases)).
  • a "clinic administrator” or “umbilical cord blood database administrator” which belongs to a network, can advantageously users he creates only
  • Umbilical cord blood databases of a group (groups) is a robust behavior for dealing with the assigned roles (for example
  • the create and edit group view is opened from the organization overview and enables the display and editing of the fields of the master data of a group (groups).
  • the patient overview displays all patient data in a tabular and context-dependent manner.
  • All patients of an independent clinic 2.
  • Patients of all hospitals of a group In addition, the presentation of patients depends on the assignment of a user to organizational units (clinics) and its role. In principle, a user can only see the patients from the clinics to which they are assigned. In the case of a "clinic coordinator" even only the self-created patients are visible.
  • the clinic to which a patient is assigned can be seen in the "Patient Overview" (new column). This is necessary to be able to filter for patients in a clinic.
  • the user When the patient is created, the user must be able to select which clinic he wants to assign to the patient according to his assignment to a clinic or to several clinics. Until now the pawls of the search center were always available for selection.
  • Umbilical cord blood database or to several umbilical cord blood databases the ability to select which umbilical cord blood database he wants to assign the CBU.
  • the assignment in the context of the umbilical cord blood database has always been clear. Now it is advantageously possible to assign these targeted.
  • Umbilical cord blood databases are always independent umbilical cord blood database, the umbilical cord blood bank ID can be determined here by the platform. Because the user is assigned to exactly one bank.
  • the clinic message overview presents all messages in a tabular and context-dependent manner.
  • the presentation of messages depends on the assignment of a user to organizational units (clinics) and its role.
  • a user can only see the messages of patients from the clinics to which they are assigned.
  • a "clinic coordinator" even only messages from self-created patients are visible.
  • a user prefers to only see messages from patients whose data he has access to.
  • the umbilical cord blood database Message Overview displays all messages in a tabular and context-dependent manner.
  • the umbilical cord blood database to which a message is assigned must be in the
  • the BackOffice Message Overview displays all messages in a tabular and context-sensitive manner.
  • the Clinic, Cord Blood Database and the Federation (if any) to which a message is associated can be seen in the "Back Office News Overview". This is necessary to be able to filter the messages accordingly. So far, "only" the Search Center and the Cord Blood Database have been listed. There is per request type for each clinic and umbilical cord blood database.
  • Request the ability to enable a release step, which takes place after the creation of a "request” and before the transmission to the umbilical cord blood database.
  • “Umbilical cord blood database manager” may give a confirmation of a "request”, taking into account the assignment of the user to the corresponding organizational unit, and only if the user is assigned to the corresponding clinic / cord blood database, can he perform the confirmation steps for them Adoption process, the invention introduced the following new "Requests" statuses:
  • Umbilical cord blood database visible. On the umbilical cord blood database page, a user must have the role
  • the status value "waiting for acceptance” is only visible on the part of the clinic, as the "Request” on the umbilical cord blood database page is not visible until it has the status
  • request types It must be configurable per request type if a confirmation step by a user in a "manager role" is necessary or not. This applies to all requesf types available in the platform and / or the system.
  • Preferred request types are:
  • the clinic administrator can activate confirmation steps at the hospital level (only for assigned clinics). 2.
  • the umbilical cord blood database administrator can confirm steps
  • Enable cord blood database level (only for assigned umbilical cord blood databases).
  • the BackOffice user can confirm steps on clinic as well
  • Enable umbilical blood database level The definition for which requesf types require a confirmation step by a user in a manager role must be individually definable / editable per clinic and umbilical cord blood database. According to the invention, no definition of confirmation-relevant Requesf types may be available at the level of a group (groups).
  • the status bar represents the new status as follows:
  • the detailed "Requesfmatrix” defines the exact status transitions, status buttons (the “reques dialoge”), status texts, confirmation texts and status graphics.
  • New or modified "Requests” can be marked On the hospital side, a "request” by a user in the context of a hospital role must then be in principle be marked as changed if the other party makes an adjustment and the user is the owner of the "request”.
  • the invention relates to the control system, wherein the user makes a request to an organization for the identification of inventories, wherein the inventories in locally available database systems and in remote
  • Database systems are stored, characterized in that 1) locally available database systems and / or local copies of inventories
  • Database systems can respond synchronously and / or asynchronously, and
  • Results from remote database systems are displayed at specific time intervals.
  • the cached results be updated.
  • a user can thus make inquiries, which at the same time to all relevant ones
  • Database system which are in the organizational units to be sent. Thanks to the new and optimized access authorizations, tailor-made inquiries can be answered quickly and specifically. Furthermore, it is preferred that regularly search queries to remote
  • Database systems are placed and the results are stored in the cache. Thus, a user can be informed at regular intervals about the results and also new arrivals.
  • the search provides particularly up-to-date results.
  • the invention relates to the use of a control system according to the invention for identifying inventories from locally available database systems and remote database systems
  • remote database systems are searched and 6) query data is sent to remote database systems, the
  • Database systems can respond synchronously and / or asynchronously, and 7) the results are displayed, whereby the user asynchronously receives results from remote database systems at specific time intervals, and
  • the use is particularly preferred for the identification of an umbilical cord blood unit. It has been shown that, especially in this field, there is a great need for systems and platforms that support complex organizational structures and allow searches in distributed inventories. The invention therefore simplifies these processes and is advantageous over the prior art.
  • the invention thus describes a new technology for the search for stem cell products in distributed inventories. It supports complex decentralized organizational structures, from which the search function advantageously benefits.
  • the invention relates to a method for identifying inventories, wherein the inventories are stored in locally available database systems and remote database systems, characterized in that a. locally available database systems and / or local copies of inventories from remote database systems are searched and b. Query data to be sent to remote database systems, the
  • Database systems can respond synchronously and / or asynchronously and c. the results are displayed, arriving asynchronously to the user
  • Results from remote database systems are displayed at specific time intervals, and d. with the results from remote database systems being cached.
  • Cord blood banks allow a particularly efficient handling and fast processing of such questions. This is especially necessary or supplemented by the structural options that have been expanded in the Verbund concept.
  • the system or the method supports the search in direct, that is locally available, and distributed, that is, from more distant databases or systems, provided inventories of, for example, stem cell products.
  • the system first searches locally available inventories and local copies
  • the remote systems can respond synchronously or asynchronously. c) The user will be directly shown the results of the local search together with already arrived results from remote systems. d) The user is informed of asynchronously arriving results from remote systems at adjustable time intervals. e) If search results from remote systems contain products that have already been locally identified in the cache, the search results are updated accordingly and the user is informed. f) Results from remote systems are cached locally to be locally available for later searches. g) The system can periodically make artificial searches on remote systems
  • pitching that are used to populate the local cache. This feature is called "pitching".
  • Cord blood databases result from the combination of appropriate roles. If, for example, a user is assigned to a clinic and an umbilical cord blood database of a group (groups) and should have access to all patients and messages, etc., the roles “clinic supervisor” and “umbilical cord blood database supervisor” can be assigned to him.
  • Figure 1 shows a preferred organizational model. It presents the new technical data structures that support the complex organizational structures of the invention.
  • Figure 2 shows the available views using the example of an umbilical cord blood database.
  • Figure 3 shows a preferred organization overview. This overview is accessible only to the BackOffice user and displays in tabular form all the organizations created in the platform / system and additionally offers the functionality to create all available organizations and their users as well as related data.
  • Figure 4 shows a preferred clinic overview, which is used to display clinics and to process the data assigned to the clinic.
  • Figure 5 shows a preferred umbilical cord blood database overflow.
  • Figure 6 shows a preferred user overview, which is used to display the users and to edit and create them.
  • Figure 7 shows how new users can be created or existing users can be edited.
  • FIG 8 gives an overview of the acceptance process (approval process). The figure shows schematically the status transitions.
  • Figure 9 shows schematically how the system for the search for distributed inventories is structured.
  • Tables 1 to 9 show a detailed list of Reques workflows with all conditions for presentation by the system.
  • Verbund A (Clinic + Cord Blood Database Admin) is associated with Federation A and its contained entities.
  • Verbund A consists of two clinics and one umbilical cord blood database.
  • user A will see the group view. He thus has access to the clinics view, as well as the umbilical cord blood database view and through the administrator roles also access to the user management for the clinics and the umbilical cord blood database.
  • Example 2 The following is an example of the user view illustrates:
  • Table 2.4 Reservation Request - Workflow / Data
  • Table 3.1 Sample Request - Workflow / Data
  • Approve activates d d
  • HLA-C value HLA-C value
  • HLA-DQB1 value HLA-DQB1 value
  • HLA-DQB1 Low resolution (see / Medium / Screen design), High / None) Option field Default completely empty
  • HLA-A string validation with HLA input field (HLA value) Validator HLA value
  • HLA-B string validation with HLA input field (HLA value) Validator
  • HLA-C string validation with HLA input field (HLA value) Validator HLA value
  • HLA-D B1 String validation with HLA input field (HLA value) Validator
  • HLA-DQB1 String validation with HLA input field (HLA value) Validator
  • Approve activates d Approved
  • HLA-A string validation with HLA input field (HLA value) Validator HLA value
  • HLA-C string validation with HLA input field (HLA value) Validator HLA value
  • HLA value HLA value
  • HLA-DRB1 String validation with HLA input field (HLA value) Validator, X
  • HLA-DQB1 String validation with HLA input field (HLA value) Validator, X
  • HLA-A string validation with HLA input field (HLA value) Validator HLA value
  • HLA-B string validation with HLA input field (HLA value) Validator
  • HLA-C string validation with HLA input field (HLA value) Validator HLA value

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)
  • Health & Medical Sciences (AREA)
  • Economics (AREA)
  • Strategic Management (AREA)
  • General Engineering & Computer Science (AREA)
  • Data Mining & Analysis (AREA)
  • Game Theory and Decision Science (AREA)
  • Biomedical Technology (AREA)
  • Tourism & Hospitality (AREA)
  • Development Economics (AREA)
  • Quality & Reliability (AREA)
  • Operations Research (AREA)
  • Marketing (AREA)
  • Educational Administration (AREA)
  • Epidemiology (AREA)
  • General Health & Medical Sciences (AREA)
  • Medical Informatics (AREA)
  • Primary Health Care (AREA)
  • Public Health (AREA)
  • Software Systems (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Medical Treatment And Welfare Office Work (AREA)

Abstract

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.

Description

Zentrale Steuerung verteilter Organisationsstrukturen
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 weiche 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 Abbildung 3). 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 Nabelschnurblutdatenbank- exklusiven 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„Requesftyps einen Schritt weiter gesetzt (zum Beispiel "„Requesfed") 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
"„Requesfed" steht (Reservation„Request" "reserved"). Der Statuswert "approved" ist auf Klinik, als auch auf Nabelschnurblutdatenbank-Seite sichtbar.
Es muss pro„Requesf-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„Requesf-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„Requesf-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„Requesf-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 "„Requesfed ü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„Requesfmatrix sind die exakten Statusübergänge, Status-Buttons (der „Reques 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„Requesf-Übersicht sichtbar oder nicht.
Ist zum Beispiel auf Seiten der Nabelschnurblutdatenbank ein„Request" im Status
"„Requesfed" und der Annahme-Prozess ist für diesen„Requesftyp 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 "„Requesfed" 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 „Reques 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 „Reques typ der Annahme-Prozess aktiviert ist, findet kein direkter Wechsel in den Status "„Requesfed" 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 Abbildung 1 ist ein bevorzugtes Organisationsmodell gezeigt. Es werden dabei die neuen fachlichen Datenstrukturen dargestellt, welche die komplexe Organisationsstrukturen der Erfindung unterstützen.
Abbildung 2 zeigt die verfügbaren Ansichten am Beispiel einer Nabelschnurblutdatenbank. Abbildung 3 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 Abbildung 4 wird eine bevorzugte Klinik-Übersicht gezeigt, welche zur Darstellung von Kliniken, sowie der Bearbeitung der der Klinik zugeordneten Daten dient.
Abbildung 5 zeigt eine bevorzugte Nabelschnurblutdatenbank-Überischt.
Abbildung 6 zeigt eine bevorzugte Nutzer-Übersicht, welche zur Darstellung der Nutzer sowie zum Bearbeiten und Anlegen dieser dient.
Abbildung 7 zeigt, wie neue Nutzer angelegt werden können beziehungsweise bestehende Nutzer bearbeitet werden können.
Abbildung 8 gibt einen Überblick über den Annahme-Prozess (Approval-Prozess). Die Abbildung zeigt schematisch die Statusübergänge .
Abbildung 9 zeigt schematisch wie das System für die Suche nach verteilten Inventaren aufgebaut ist. In den Tabellen 1 bis 9 werden detaillierte Aufstellung des„Reques -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
Vorbelegen mit
Rechnungsanschrift
der Klinik des
Billing Patienten (Komplette
Address Text x 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!
Standard
Comment Text Kommentarfeld X X X X
Anzeige der
Comment Kommentarhistory
Hi Störy Anzeige mit Datum/Uhrzeit
Anzeige des
Creation/Modification
Created / Date wie im Patient
Modified Anzeige Chart
"Requeste
Folgestatus abhängig d" oder
von Einstellungen zur "Waiting
"Requestfreigabe" for
Create (durch Manager) approval"
Approve-Button im
Status "Requested"
auf CBB-Seite nur
sichtbar wenn
"Requestfreigabe"
Approve aktiviert Requested Approved
Save Adjusted
Shipped
Answer
Inquiry
Cancel Canceled Canceled efuse Refused
Reject Rejected
Inquiry-Button im
Staus "Requested"
auf CBB-Seite
ausblenden wenn
"Requestfreigabe"
Inquiry aktiviert Inquiry Process-Button im
Staus "Requested"
auf CBB-Seite
ausblenden wenn
"Requestfreigabe"
Process aktiviert Processing
Siphment
failed
Shipment
eceived
Tabellel .2: Order Request - Workflow / Daten
Shipment
Link URL Nicht vorbelegt!
Tracking
Number String Nicht vorbelegt!
Shipper Text Nicht vorbelegt!
Standard
Comment Text Kommentarfeld X X X X
Anzeige der
Comment Kommentarhistory
History Anzeige mit Datum/Uhrzeit
Anzeige des
Creation/Modification
Created / Date wie im Patient
Modified Anzeige Chart
Folgestatus abhängig
von Einstellungen zur
"Requestfreigabe"
Create (durch Manager)
Approve-Button im
Status "Requested"
auf CBB-Seite nur
sichtbar wenn
"Requestfreigabe"
Approve aktiviert
Save Adjusted Inquiry
Shipped
Answer Inquiry Inquiry Answered
Cancel Canceled Canceled efuse
Reject Rejected Rejected
Inquiry-Button im
Staus "Requested"
auf CBB-Seite
ausblenden wenn
"Requestfreigabe"
Inquiry aktiviert Inquiry
Process-Button im
Staus "Requested"
auf CBB-Seite
ausblenden wenn
"Requestfreigabe" Processi
Process aktiviert Processing ng
Siphment
failed Shipment
eceived
Tabelle 1 .3: Order Request - Workflow / Daten
Anzeige der
Comment Kommentarhistory
History Anzeige mit Datum/Uhrzeit
Anzeige des
Creation/Modification
Created / Date wie im Patient
Modified Anzeige Chart
Folgestatus abhängig
von Einstellungen zur
"Requestfreigabe"
Create (durch Manager)
Approve-Button im
Status "Requested"
auf CBB-Seite nur
sichtbar wenn
"Requestfreigabe"
Approve aktiviert
Save Adjusted Adjusted
Shipped
Answer
Inquiry
Cancel Canceled Canceled efuse
Reject Rejected Rejected
Inquiry-Button im
Staus "Requested"
auf CBB-Seite
ausblenden wenn
"Requestfreigabe"
Inquiry aktiviert Inquiry Inquiry
Process-Button im
Staus "Requested"
auf CBB-Seite
ausblenden wenn
"Requestfreigabe"
Process aktiviert Processing Processing
Siphment
failed
Shipment
Received
Tabelle 1 .4: Order Request - Workflow / Daten
Label Type Mandatory Beschreibung Rejected Rejected Canceled Canceled
Delivery Date Date X Nicht vorbelegt!
Vorbelegt mit
Kontaktperson der
Contact Klinik (Komplette
Person Kontaktfelder laut
(Delivery) Text X Spec)
Vorbelegen mit
Anschrift der Klinik
des Patienten
Delivery (Komplette Felder
Address Text X laut Spec)
Emergency
Number Text X Nicht vorbelegt!
Vorbelegt mit
Contact Kontaktdaten des SC
Person Users (Komplette
(Coordinator) Text X Felder laut Spec)
Vorbelegen mit
Rechnungsanschrift
der Klinik des
Billing Patienten (Komplette
Address Text X Felder laut Spec)
Shipment
Date Date X Nicht vorbelegt!
Shipment
Link URL Nicht vorbelegt!
Tracking
Number String Nicht vorbelegt!
Shipper Text Nicht vorbelegt!
Standard
Comment Text Kommentarfeld
Anzeige der
Comment Kommentarhistory
History Anzeige mit Datum/Uhrzeit
Anzeige des
Creation/Modification
Created / Date wie im Patient
Modified Anzeige Chart Folgestatus abhängig von Einstellungen zur "Requestfreigabe"
Create (durch Manager)
Approve-Button im Status "Requested" auf CBB-Seite nur sichtbar wenn "Requestfreigabe"
Approve aktiviert
Save
Shipped
Answer
Inquiry
Cancel
efuse
Reject
Inquiry-Button im Staus "Requested" auf CBB-Seite ausblenden wenn "Requestfreigabe"
Inquiry aktiviert
Process-Button im Staus "Requested" auf CBB-Seite ausblenden wenn "Requestfreigabe"
Process aktiviert
Siphment
failed
Shipment
Received
Tabelle 1 .5: Order Request - Workflow / Daten Vorbelegt mit
Kontaktperson der
Contact Klinik (Komplette
Person Kontaktfelder laut
(Delivery) Text X Spec)
Vorbelegen mit Anschrift der Klinik des Patienten
Delivery (Komplette Felder Address Text X laut Spec)
Emergency
Number Text X Nicht vorbelegt!
Vorbelegt mit
Contact Kontaktdaten des SC Person Users (Komplette
(Coordinator) Text X Felder laut Spec)
Vorbelegen mit Rechnungsanschrift der Klinik des
Billing Patienten (Komplette Address Text X Felder laut Spec)
Shipment
Date Date X Nicht vorbelegt!
Shipment
Link URL Nicht vorbelegt!
Tracking
Number String Nicht vorbelegt!
Shipper Text Nicht vorbelegt!
Standard
Comment Text Kommentarfeld
Anzeige der
Comment Kommentarhistory History Anzeige mit Datum/Uhrzeit
Anzeige des
Creation/Modification
Created / Date wie im Patient Modified Anzeige Chart
Folgestatus abhängig von Einstellungen zur "Requestfreigabe"
Create (durch Manager) Approve-Button im
Status "Requested" auf CBB-Seite nur sichtbar wenn "Requestfreigabe"
Approve aktiviert
Save
Shipped
Answer
Inquiry
Cancel
efuse
Reject
Inquiry-Button im Staus "Requested" auf CBB-Seite ausblenden wenn "Requestfreigabe"
Inquiry aktiviert
Process-Button im Staus "Requested" auf CBB-Seite ausblenden wenn "Requestfreigabe"
Process aktiviert
Siphment
failed
Shipment
Received
Tabelle 2.1 : Reservation Request - Workflow / Daten Kommentarfeld
Comment Nur Anzeige der
History Anzeige Kommentarhistory
Anzeige des
Creation /
Modification Date
Created / Nur wie im Patient
Modified Anzeige Chart
CBU
Folgestatus reserved
abhängig von or
Einstellungen zur waiting
"Requestfreigabe" for
Create (durch Manager) approval
CBU
Approve reserved
Save
Cancel Canceled Canceled efuse Refused
Reject Rejected
Extend Extended
CBU
Order Ordered
Tabelle 2.2: Reservation Request - Workflow / Daten
Folgestatus
abhängig von
Einstellungen zur
"Requestfreigabe"
Create (durch Manager)
Approve
Save
Cancel
efuse
Reject Rejected
Extend Extended
CBU
Order Ordered
Tabelle 2.3: Reservation Request - Workflow / Daten
Tabelle 2.4: Reservation Request - Workflow / Daten Tabelle 3.1 : Sample Request - Workflow / Daten
String Werte für beide Loci, n
(HLA- digits + N, Validierung
HLA-DQB1 Wert) mit HLA-Validator
Comment Text Standard Kommentarfeld X X X X
Anzeige der
Comment Kommentarhistory mit
History Anzeige Datum/Uhrzeit
Anzeige des Creation /
Created / Modification Date wie im
Modified Anzeige Patient Chart
"Request
ed" oder
Folgestatus abhängig von "Waiting
Einstellungen zur for
"Requestfreigabe" approval
Create (durch Manager)
Approve-Button im
Status "Requested" auf
CBB-Seite nur sichtbar
wenn "Requestfreigabe" Requeste Approve
Approve aktiviert d d
Requeste
Save d
Shipped
Cancel Canceled Canceled efuse Refused
Reject Rejected
Process-Button im Staus
"Requested" auf CBB- Seite ausblenden wenn
"Requestfreigabe" Processin
Process aktiviert g
Siphment
failed
Shipment
Received
Tabelle 3.2: Sample Request - Workflow / Daten Vorbelegt mit
Contact Kontaktperson der Klinik
Person (Komplette
(Delivery) Text Kontaktfelder laut Spec)
Vorbelegen mit Anschrift der Klinik des Patienten
Delivery (Komplette Felder laut Address Text Spec)
Emergency
Number Text Nicht vorbelegt!
Vorbelegt mit
Contact Kontaktdaten des SC Person Users (Komplette Felder
(Coordinator) Text laut Spec)
Vorbelegen mit Rechnungsanschrift der Klinik des Patienten
Billing (Komplette Felder laut Address Text Spec)
List / Nicht vorbelegt!
Temperature Single (Auswahl aus "Room Condition Choice Temperature", "Frozen")
Shipment
Date Date Nicht vorbelegt!
Shipment Link URL Nicht vorbelegt!
Tracking
Number String Nicht vorbelegt!
Shipper Text Nicht vorbelegt!
String Werte für beide Loci, n (HLA- digits + N, Validierung
HLA-A Wert) mit HLA-Validator
String Werte für beide Loci, n (HLA- digits + N, Validierung
HLA-B Wert) mit HLA-Validator
String Werte für beide Loci, n (HLA- digits + N, Validierung
HLA-C Wert) mit HLA-Validator
String Werte für beide Loci, n (HLA- digits + N, Validierung
HLA-DRB1 Wert) mit HLA-Validator
String Werte für beide Loci, n (HLA- digits + N, Validierung
HLA-DQB1 Wert) mit HLA-Validator
Comment Text Standard Kommentarfeld
Anzeige der
Comment Kommentarhistory mit History Anzeige Datum/Uhrzeit
Anzeige des Creation /
Created / Modification Date wie im Modified Anzeige Patient Chart Folgestatus abhängig von
Einstellungen zur
"Requestfreigabe"
Create (durch Manager)
Approve-Button im
Status "Requested" auf
CBB-Seite nur sichtbar
wenn "Requestfreigabe"
Approve aktiviert
Save
Shipped
Cancel
efuse
Reject
Process-Button im Staus
"Requested" auf CBB- Seite ausblenden wenn
"Requestfreigabe"
Process aktiviert
Siphment Shipment failed failed
Shipment
Received Received
Tabelle 3.3: Sample Request - Workflow / Daten
(Coordinator) Users (Komplette Felder
laut Spec)
Vorbelegen mit
Rechnungsanschrift der
Klinik des Patienten
Billing (Komplette Felder laut
Address Text X Spec)
List / Nicht vorbelegt!
Temperature Single (Auswahl aus "Room
Condition Choice X Temperature", "Frozen")
Shipment
Date Date X Nicht vorbelegt!
Shipment Link URL Nicht vorbelegt!
Tracking
Number String Nicht vorbelegt!
Shipper Text Nicht vorbelegt!
String Werte für beide Loci, n (HLA- digits + N, Validierung
HLA-A Wert) mit HLA-Validator X
String Werte für beide Loci, n (HLA- digits + N, Validierung
HLA-B Wert) mit HLA-Validator X
String Werte für beide Loci, n (HLA- digits + N, Validierung
HLA-C Wert) mit HLA-Validator X
String Werte für beide Loci, n (HLA- digits + N, Validierung
HLA-D B1 Wert) mit HLA-Validator X
String Werte für beide Loci, n (HLA- digits + N, Validierung
HLA-DQB1 Wert) mit HLA-Validator X
Comment Text Standard Kommentarfeld X
Anzeige der
Comment Kommentarhistory mit
History Anzeige Datum/Uhrzeit
Anzeige des Creation /
Created / Modification Date wie im
Modified Anzeige Patient Chart
Folgestatus abhängig von
Einstellungen zur
"Requestfreigabe"
Create (durch Manager)
Approve-Button im
Status "Requested" auf
CBB-Seite nur sichtbar
wenn "Requestfreigabe"
Approve aktiviert
Typing
Save Completed Shipped
Cancel
efuse
Reject
Process-Button im Staus "Requested" auf CBB- Seite ausblenden wenn "Requestfreigabe"
Process aktiviert
Siphment
failed
Shipment
Received
Tabelle 4.1 : HLA-Typing Request - Workflow / Daten
Optionsfelder zur
Auswahl der Typing-
HLA-DQB1 (Low Auflösung (siehe / Medium / Screenentwurf), High / None) Optionsfeld Default komplett leer
Werte für beide Loci, n digits + N,
HLA-A String Validierung mit HLA- Eingabefeld (HLA-Wert) Validator,
Werte für beide Loci, n digits + N,
HLA-B String Validierung mit HLA- Eingabefeld (HLA-Wert) Validator,
Werte für beide Loci, n digits + N,
HLA-C String Validierung mit HLA- Eingabefeld (HLA-Wert) Validator,
Werte für beide Loci, n digits + N,
HLA-D B1 String Validierung mit HLA- Eingabefeld (HLA-Wert) Validator,
Werte für beide Loci, n digits + N,
HLA-DQB1 String Validierung mit HLA- Eingabefeld (HLA-Wert) Validator,
x (nicht
mandat
ory im
Status
"request
ed"
wenn
"Reques
tfreigab Datum. Bis wann das e" Typing wahrscheinlich
Typing available aktiviert abgeschlossen sein until Date ) wird
Vorbelegt mit Kontaktdaten des SC
Contact Person Users (Komplette (Coordinator) Text Felder laut Spec)
Vorbelegen mit Rechnungsanschrift der Klinik des Patienten (Komplette
Billing Address Text Felder laut Spec)
Standard
Comment Text Kommentarfeld
Anzeige der
Comment Kommentarhistory History Anzeige mit Datum/Uhrzeit
Created / Anzeige Anzeige des Creation Modified / Modification Date
wie im Patient Chart
"Reque
sted"
oder
Folgestatus abhängig "Wait
von Einstellungen zur g for
" equestfreigabe" approv
Create (durch Manager) al"
Approve-Button im
Staus "Requested"
auf CBB-Seite nur
sichtbar wenn
"Requestfreigabe" Requeste
Approve aktiviert d Approved
Save
Cancel Canceled Canceled
Refuse Refused
Reject Rejected
Process-Button im
Staus "Requested"
auf CBB-Seite
ausblenden wenn
"Requestfreigabe"
Process aktiviert Processing
Completed
Received
Tabelle 4.2: HLA-Typing Request - Workflow / Daten
Screenentwurf),
Default komplett leer
Optionsfelder zur
Auswahl der Typing-
HLA-B (Low / Auflösung (siehe
Medium / High Screenentwurf),
/ None) Optionsfeld X Default komplett leer
Optionsfelder zur
Auswahl der Typing-
HLA-C (Low / Auflösung (siehe
Medium / High Screenentwurf),
/ None) Optionsfeld X Default komplett leer
Optionsfelder zur
Auswahl der Typing-
HLA-D B1 (Low Auflösung (siehe
/ Medium / Screenentwurf),
High / None) Optionsfeld X Default komplett leer
Optionsfelder zur
Auswahl der Typing-
HLA-DQB1 (Low Auflösung (siehe
/ Medium / Screenentwurf),
High / None) Optionsfeld X Default komplett leer
Werte für beide Loci,
n digits + N,
HLA-A String Validierung mit HLA- Eingabefeld (HLA-Wert) Validator, X
Werte für beide Loci,
n digits + N,
HLA-B String Validierung mit HLA- Eingabefeld (HLA-Wert) Validator, X
Werte für beide Loci,
n digits + N,
HLA-C String Validierung mit HLA- Eingabefeld (HLA-Wert) Validator, X
Werte für beide Loci,
n digits + N,
HLA-DRB1 String Validierung mit HLA- Eingabefeld (HLA-Wert) Validator, X
Werte für beide Loci,
n digits + N,
HLA-DQB1 String Validierung mit HLA- Eingabefeld (HLA-Wert) Validator, X
x (nicht
mandat
ory im
Status
"request
ed"
wenn Datum. Bis wann das
"Reques Typing wahrscheinlich
Typing available tfreigab abgeschlossen sein
until Date e" wird X X aktiviert
)
Vorbelegt mit
Kontaktdaten des SC
Contact Person Users (Komplette
(Coordinator) Text Felder laut Spec)
Vorbelegen mit
Rechnungsanschrift
der Klinik des
Patienten (Komplette
Billing Address Text Felder laut Spec)
Standard
Comment Text Kommentarfeld
Anzeige der
Comment Kommentarhistory
History Anzeige mit Datum/Uhrzeit
Anzeige des Creation
Created / / Modification Date
Modified Anzeige wie im Patient Chart
Folgestatus abhängig
von Einstellungen zur
"Requestfreigabe"
Create (durch Manager)
Approve-Button im
Staus "Requested"
auf CBB-Seite nur
sichtbar wenn
"Requestfreigabe"
Approve aktiviert
Save
Canceled (mit
Abfrage/H inweis
Cancel Canceled Kosten)
Refuse
Rejecte
Reject d Rejected
Process-Button im
Staus "Requested"
auf CBB-Seite
ausblenden wenn
"Requestfreigabe" Process
Process aktiviert ing
Completed Completed
Received
Tabelle 4.3: HLA-Typing Request - Workflow / Daten CBB Clinic I CBB I Clinic
Mandat Comple Complet
Label Type ory Beschreibung ted ed eceived Received
Original-HLA-Werte
HLA-A Anzeige Anzeige der CBU
Original-HLA-Werte
HLA-B Anzeige Anzeige der CBU
Original-HLA-Werte
HLA-C Anzeige Anzeige der CBU
HLA-DRB1 Original-HLA-Werte
Anzeige Anzeige der CBU
HLA-DQB1 Original-HLA-Werte
Anzeige Anzeige der CBU
Optionsfelder zur
Auswahl der Typing-
HLA-A (Low / Auflösung (siehe
Medium / High Screenentwurf),
/ None) Optionsfeld Default komplett leer
Optionsfelder zur
Auswahl der Typing-
HLA-B (Low / Auflösung (siehe
Medium / High Screenentwurf),
/ None) Optionsfeld Default komplett leer
Optionsfelder zur
Auswahl der Typing-
HLA-C (Low / Auflösung (siehe
Medium / High Screenentwurf),
/ None) Optionsfeld Default komplett leer
Optionsfelder zur
Auswahl der Typing-
HLA-DRB1 (Low Auflösung (siehe
/ Medium / Screenentwurf),
High / None) Optionsfeld Default komplett leer
Optionsfelder zur
Auswahl der Typing-
HLA-DQB1 (Low Auflösung (siehe
/ Medium / Screenentwurf),
High / None) Optionsfeld Default komplett leer
Werte für beide Loci,
n digits + N,
HLA-A String Validierung mit HLA- Eingabefeld (HLA-Wert) Validator,
Werte für beide Loci,
n digits + N,
HLA-B String Validierung mit HLA- Eingabefeld (HLA-Wert) Validator,
Werte für beide Loci,
n digits + N,
HLA-C String Validierung mit HLA- Eingabefeld (HLA-Wert) Validator,
ave Cancel
efuse
Reject
Process-Button im
Staus "Requested"
auf CBB-Seite
ausblenden wenn
"Requestfreigabe"
Process aktiviert
Completed
Received Received
Tabelle 5.1 : Colony Assay Request - Workflow / Daten
Vorbelegen mit
Rechnungsansch
rift der Klinik des
Patienten
Billing (Komplette
Address Text X Felder laut Spec) X X
Standard
Comment Text Kommentarfeld X X X X
Anzeige der
Kommentarhisto
Comment Anzei ry mit
History ge Datum/Uhrzeit
Anzeige des
Creation /
Modification
Created / Anzei Date wie im
Modified ge Patient Chart
Folgestatus "Request
abhängig von ed" oder
Einstellungen zur "Waiting
"Requestfreigabe for
" (durch approval
Create Manager)
Approve-Button
im Staus
"Requested" auf
CBB-Seite nur
sichtbar wenn
"Requestfreigabe Requeste
Approve " aktiviert d Approved
Save
Cancel Canceled Canceled efuse Refused
Reject Rejected
Process-Button
im Staus
"Requested" auf
CBB-Seite
ausblenden
wenn
"Requestfreigabe
Process " aktiviert Processing
Completed
Received
Tabelle 5.2: Colony Assay Request - Workflow / Daten CBB Clinic CBB Clinic
Label Type Mandatory Beschreibung Approved Approved Processing Processing x (nicht
mandatory
im Status
"requested
" wenn
"Requestfr Datum. Bis wann
Available eigabe" das Ergebnis
until Date aktiviert) vorliegt X X
BFU-E Float X
CFU-GM Float X
CFU- GEMM Float X
mehrzelliges
Textfeld für
Additional weitere
esults Text Ergebnisse X
Vorbelegt mit
Kontaktdaten
des SC Users
(Feld nicht in
Contact Spec, aber falls
Person ohne größeren
(Coordinat Aufwand möglich
or) Text X bitte ergänzen)
Vorbelegen mit
Rechnungsansch
rift der Klinik des
Patienten
Billing (Komplette
Address Text X Felder laut Spec)
Standard
Comment Text Kommentarfeld X X X X
Anzeige der
Kommentarhisto
Comment Anzei ry mit
History ge Datum/Uhrzeit
Anzeige des
Creation /
Modification
Created / Anzei Date wie im
Modified ge Patient Chart
Folgestatus
abhängig von
Einstellungen zur
"Requestfreigabe
" (durch
Create Manager) Approve-Button
im Staus
"Requested" auf
CBB-Seite nur
sichtbar wenn
"Requestfreigabe
Approve " aktiviert
Save
Canceled (Abfrage/ Hinweis
Cancel Canceled Kosten) efuse
Reject Rejected Rejected
Process-Button
im Staus
"Requested" auf
CBB-Seite
ausblenden
wenn
"Requestfreigabe
Process " aktiviert Processing
Complete
Completed d
Received
Tabelle 5.3: Colony Assay Request - Workflow / Daten
Spec, aber falls
ohne größeren
Aufwand möglich
bitte ergänzen)
Vorbelegen mit
Rechnungsansch
rift der Klinik des
Patienten
Billing (Komplette
Address Text X Felder laut Spec)
Standard
Comment Text Kommentarfeld X
Anzeige der
Kommentarhisto
Comment Anzei ry mit
History ge Datum/Uhrzeit
Anzeige des
Creation /
Modification
Created / Anzei Date wie im
Modified ge Patient Chart
Folgestatus
abhängig von
Einstellungen zur
"Requestfreigabe
" (durch
Create Manager)
Approve-Button
im Staus
"Requested" auf
CBB-Seite nur
sichtbar wenn
"Requestfreigabe
Approve " aktiviert
Save
Cancel
efuse
Reject
Process-Button
im Staus
"Requested" auf
CBB-Seite
ausblenden
wenn
"Requestfreigabe
Process " aktiviert
Completed eceived Received
Tabelle 6: Abstract request status text
Tabelle 7: Request Bestätigunsdialog-Texte (Schema) Sample, HLA request to "received"?
Typing, Colony
Assay
DNA Sample,
HLA Typing, (Typing) Do you really want to set the <requesttype> Colony Assay C/CBB Completed Message request to "completed"?
C - Clinic
CBB - Cord
Clood Bank
BO - Back Office
Tabelle 8: Request-Maske Status-Graphiken
Create equested Processing Adjusted Shipped Received Adjusted
Create Requested Canceled Canceled
Create Requested Rejected Rejected
Create Refused Refused
Sample Request
"Creation" or
Typing "Waiting for
Create Requested Processing Shipped Received Comp. approval"
Typing
Create Requested Processing Shipped Received Comp. Requested
Typing "Approved" or
Create Requested Processing Shipped Received Comp. "Processing"
Typing
Create Requested Processing Shipped Received Comp. Shipped
Typing
Create Requested Processing Shipped Received Comp. Received
Typing
Create Requested Processing Shipped Received Compl. Typing completed
Shipment
Create Requested Processing Shipped Failed Shipment failed
Create Requested Canceled Canceled
Create Requested Rejected Rejected
Create Refused Refused
Reservation Request
"Creation" or
CBU CBU "Waiting for
Create reserved Ordered approval"
CBU CBU
Create reserved Ordered CBU reserved
CBU CBU
Create reserved Ordered CBU ordered
CBU CBU
Create reserved Extended Ordered Extended
CBU
Create reserved Expired Expired
CBU
Create reserved Canceled Canceled
CBU
Create reserved Rejected Rejected
Create Refused Refused
Colony Assay Request
"Creation" or "Waiting for
Create Requested Processing Completed Received approval"
Create Requested Processing Completed Received Requested "Approved" or
Create equested Processing Completed Received "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)
Tabelle 9.2: Request conditions overview (Sichtbarkeit/Editierbarkeit)
CBB Bemerkungen Manager Supervisor Coordinator
"Waiting for
approval" - - -
Vorraussetzung auf CBB-Seite, der
Request war vor Erreichen des Status
"Cancel" S S/M* S/M * "Canceled" bereits auf CBB-Seite sichtbar.
" efused" - - -
"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

Patentansprüche
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.
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.
Steuerungssystem nach mindestens einem der vorhergehenden Ansprüche, wobei die Rolle ausgewählt ist aus der Gruppe umfassen Administrator, Manager, Supervisor, Koordinator.
Steuerungssystem nach mindestens einem der vorhergehenden Ansprüche, wobei die Rollen hierarchisch aufgebaut sind.
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.
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.
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.
Steuerungssystem nach dem vorhergehenden Anspruch, wobei die im Cache gespeicherten Ergebnisse aktualisiert werden.
Steuerungssystem nach Anspruch 9 oder 10, wobei regelmäßig automatische Suchanfragen an entfernte Datenbanksysteme gestellt werden und die Ergebnisse im Cache gespeichert werden.
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
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 wobei die Ergebnisse aus entfernten Datenbanksystemen im Cache gespeichert werden.
Verwendung nach dem vorhergehenden Anspruch zur Identifikation
Nabelschnurbluteinheit.
EP12788202.5A 2011-11-18 2012-11-19 Zentrale steuerung verteilter organisationsstrukturen Withdrawn EP2780870A1 (de)

Priority Applications (1)

Application Number Priority Date Filing Date Title
EP12788202.5A EP2780870A1 (de) 2011-11-18 2012-11-19 Zentrale steuerung verteilter organisationsstrukturen

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
US201161561398P 2011-11-18 2011-11-18
EP11075253 2011-11-18
EP11075252 2011-11-18
PCT/EP2012/072991 WO2013072524A1 (de) 2011-11-18 2012-11-19 Zentrale steuerung verteilter organisationsstrukturen
EP12788202.5A EP2780870A1 (de) 2011-11-18 2012-11-19 Zentrale steuerung verteilter organisationsstrukturen

Publications (1)

Publication Number Publication Date
EP2780870A1 true EP2780870A1 (de) 2014-09-24

Family

ID=48429018

Family Applications (1)

Application Number Title Priority Date Filing Date
EP12788202.5A Withdrawn EP2780870A1 (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
WO2013072524A1 (de) 2013-05-23
AU2012338744A1 (en) 2014-06-05
SG10201602914TA (en) 2016-05-30
SG11201402403XA (en) 2014-09-26
DE202012012534U1 (de) 2013-05-13
US20140324455A1 (en) 2014-10-30

Similar Documents

Publication Publication Date Title
DE60025778T2 (de) Verfahren zum Speichern und Verwalten von Daten
DE102006057149A1 (de) System und Verfahren zum Erleichtern eines visuellen Vergleichs von Eingangsdaten mit vorhandenen Daten
EP1783633B1 (de) Suchmaschine für eine ortsbezogene Suche
DE112016002395T5 (de) Zugriffskontrolle für Datenressourcen
DE202016008173U1 (de) Einbindung von auswählbaren Anwendungsverknüpfungen in Nachrichtenaustausch-Threads
EP0855062A2 (de) Informationssystem und verfahren zur speicherung von daten in einem informationssystem
DE10253676B4 (de) Verfahren und Vorrichtung für die Fernübertragung sensibler Daten
WO2007022874A1 (de) System, verfahren und computerprogrammprodukt zur arbeitsflussbasierten datenverarbeitung
EP1611538A2 (de) Verfahren und anordnung zur automatischen aufbereitung und auswertung medizinischer daten
DE202019102730U1 (de) Lernmaschine für intelligente Kommunikation und Analyse
DE102021123842A1 (de) Bewertung einer verringerung eines krankheitsrisikos und behandlungsentscheidung
DE102018132623A1 (de) System und Verfahren zur Informationsübermittlung von Gesundheitsinformationen
Watchman Practitioner‐raised issues and end‐of‐life care for adults with Down syndrome and dementia
DE112017000695T5 (de) Arbeitsablauf-Erstellung anhand natürlicher Sprache
EP2780870A1 (de) Zentrale steuerung verteilter organisationsstrukturen
EP3776257B1 (de) Objektdatenbank zur geschäftsmodellierung mit verbesserter datensicherheit
DE112020001314T5 (de) System und Verfahren für eine Datenkuration
Whitford The hierarchical consequences of reinvention: evidence from the American bureaucracy
DE602004001762T2 (de) Verfahren und computersystem zur datenzuweisung
EP1285315B1 (de) Informationsverarbeitungssystem und verfahren zu dessen betrieb
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
Kiese-Himmel Early detection of primary developmental language disorders-increasing relevance due to changes in diagnostic criteria?
WO2024067920A1 (de) Datenbank eines rechners
EP1443447A2 (de) Drahtloses System und Verfahren zum Einfügen von kryptographischen Daten

Legal Events

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

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20140417

AK Designated contracting states

Kind code of ref document: A1

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

DAX Request for extension of the european patent (deleted)
17Q First examination report despatched

Effective date: 20161028

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

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20170308