US20140324455A1 - Central control of distributed organizational structures - Google Patents

Central control of distributed organizational structures Download PDF

Info

Publication number
US20140324455A1
US20140324455A1 US14/359,103 US201214359103A US2014324455A1 US 20140324455 A1 US20140324455 A1 US 20140324455A1 US 201214359103 A US201214359103 A US 201214359103A US 2014324455 A1 US2014324455 A1 US 2014324455A1
Authority
US
United States
Prior art keywords
user
database systems
umbilical cord
cord blood
hospital
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.)
Abandoned
Application number
US14/359,103
Other languages
English (en)
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 US14/359,103 priority Critical patent/US20140324455A1/en
Assigned to CYTOLON AG reassignment CYTOLON AG ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: SCHLIEHE-DIECKS, RALF, KLEIN, THOMAS, SCHIMANSKI, ANDREAS
Publication of US20140324455A1 publication Critical patent/US20140324455A1/en
Abandoned legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/90—Details of database functions independent of the retrieved data types
    • G06F16/901—Indexing; Data structures therefor; Storage structures
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/90—Details of database functions independent of the retrieved data types
    • G06F16/95—Retrieval from the web
    • G06F16/951—Indexing; Web crawling techniques
    • G06F19/327—
    • 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
    • G06F17/30864—
    • 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

  • New technical data structures are required in order to support the complex organizational structures.
  • the problem underlying the invention therefore, is that a control system must be created, which does not have the disadvantages of the prior art and is able to support distributed organizational structures primarily with regard to the administration of umbilical cord blood data.
  • the invention relates to a control system for distributed organizational structures, comprising
  • At least one organization with at least one organizational unit wherein the organizational unit has technical attributes and the organizational units can be providers and/or inquiring parties; at least two users, wherein the users are assigned to at least one organization; and at least one role, wherein the role is assigned to at least one user and the role determines the available functionalities within the organization that is assigned to the user, the organization to which a user is assigned determines the view that is shown to the user and a first user can create a search request, which is sent to organizations that include provider organizational units and the user can then send a request to an organization and another user that is assigned to the organization to which the request has been made processes the request.
  • control system can be used for many different application areas and platform participants and directly supports more complex organizational structures such as registries.
  • the control advantageously system makes it advantageously possible to control a multitude of connected organizational units.
  • the organizational unit is selected from a group including network, hospital, institution, and/or administration.
  • the organizational unit can preferably adopt various technical characteristics:
  • a network is preferably a network of at least two hospitals, a network of at least two institutions, or a network of at least one hospital and at least one institution.
  • a particularly preferable embodiment is a network of umbilical cord blood banks and/or umbilical cord blood databases.
  • a network of one or more hospital(s) and one or more umbilical cord blood bank(s) is preferable.
  • the invention does not provide that a network includes another network. It also does not provide that a hospital includes other hospitals or that an umbilical cord blood database includes other umbilical cord blood databases. In addition, an umbilical cord blood database may contain no network.
  • An organization can correspond to an organizational unit, for example if the organizational unit is an independent hospital. In such a case, the hospital is the organizational unit and the organization at the same time.
  • the prior art uses only domain models that provide a systematic separation of the query side and the database side. This is disadvantageous since it is becoming more and more usual on the one hand, for various institutions to combine, but also for institutions to combine, for example, with hospitals so that in the networks, the classic inquiring party side merges with the database side.
  • an organizational unit can also contain other organizational units (for example a network includes a hospital). It is not possible, however, for a hospital to contain a network. Preferably, only a network can contain other organizational units.
  • an institution is selected from the group including an umbilical cord blood bank, an umbilical cord blood database, a blood bank, a stem cell bank, a donor registry, a tissue bank, and/or an organ bank.
  • a hospital prefferably includes one or more subsidiary hospitals.
  • Users are assigned to the specific organizational unit (for example a hospital).
  • One advantage of the invention is that via the network, users can also be assigned to a plurality of hospitals and/or umbilical cord blood databases.
  • the invention permits these users a central access to the organization with only one account. It is preferable that a user who has been assigned to a network cannot be assigned to hospitals/umbilical cord blood databases outside the network.
  • Another advantage of the invention is also the fact that the platform and/or the system support(s) users regardless of the organization. In other words, it is no longer necessary, as in the prior art, for there to be specific “search center users” and “provider users.” Consequently, the users are permitted access to various organizational units if the users have been assigned to the organization to which these organizational units belong
  • a user is assigned to the organization or organizational units for which he is responsible or for which he works.
  • the assignment to a network therefore does not result in the assignment to all of the organizational units that belong to the network; this must occur explicitly.
  • an additional protection is built in, which is advantageous since the field of personalized medicine sometimes involves very sensitive data that not every user should be automatically permitted to see.
  • the assignment to the back office is likewise exclusive, which is already assured by the fact that the back office is its own organizational unit, which is preferably not combined with any other organizational units.
  • the user receives an account with which he can access the organizations or organizational units to which he has been assigned.
  • a user is assigned to a network, a hospital, an institution, or a back office.
  • the available functions within the organizations and organizational units are defined by means of a role concept.
  • the assignment defines only the access to the corresponding organizational units, but not which specific data can be accessed and which processing functions can be performed. This is important in order to permit data protection and to ensure a coordinated sequence of queries and responses to them.
  • the role is preferably selected from the group including administrator, manager, supervisor, and coordinator.
  • a user is assigned roles that define the available functionality within the organizational unit(s) to which the user is assigned.
  • the roles in this case are preferably hierarchically arranged; in other words, a role always includes the rights of the roles of a lower level.
  • the 1 st level being the highest:
  • the role of the manager has the functionality of accepting approval processes.
  • the role of the supervisor permits access to all data of the assigned organizational units as well as the right to read, write, and/or delete them.
  • the role of coordinator permits access to the data belonging to the assigned organizational units as well as the right to read, write, and/or delete them.
  • a higher level always includes the functionalities of the levels below it.
  • the hospital administrator has access to
  • the access rights of the back office agent are restricted by comparison with the back office administrator.
  • the back office agent cannot manage patient data and umbilical cord blood units or the data relating to them.
  • the role of hospital manager permits approval of queries and requests that require acceptance.
  • umbilical cord blood database manager permits approval of queries and requests that require acceptance.
  • the hospital supervisor has access—for assigned hospitals—to patient data, messages, physician data, search profiles, and hospital data
  • the umbilical cord blood database supervisor has access—for assigned umbilical cord blood databases—to data about umbilical cord blood units (CBUs) and to data about umbilical cord blood databases
  • the role of the hospital coordinator permits access—for assigned hospitals—to his own patient data, in particular patient data that he himself has created, and to messages relating to these patients.
  • the role of the umbilical cord blood database coordinator permits access to messages for assigned umbilical cord blood databases.
  • the user is assigned to hospital(s)+umbilical cord blood database(s) and is given a hospital role+umbilical cord blood database role 2.
  • the user is assigned to hospital(s) and is given a hospital role 3.
  • the user is assigned to umbilical cord blood database(s) and receives an umbilical cord blood database role 4.
  • the user is assigned to the back office and is given a back office role
  • the other user that is assigned to the organization to which the query has been submitted processes the query, namely approves it and as a result, a display showing that the query has been approved is shown to the user who submitted the query.
  • the other user that is assigned to the organization to which the query has been submitted processes the query and activates an approval step.
  • control system can also be used for other organizations in addition to a registry.
  • structure which includes a method, a system, and/or a device, to be used for pharmaceutical companies, governmental structures, medications, the distribution/administration of medications, or treatment methods and/or produces a connection between the physician, hospital, control instrument, and/or governmental authority in order, for example, to appropriately administer and or distribute medications or treatment methods.
  • the invention can in particular be referred to as a means for personalized medicine.
  • the invention permits the support of networks of registries, for example, consequently simplifying prior systems in the area of personalized medicine.
  • the platform preferably the umbilical cord blood data platform, supports the creation of networks (for example a registry) of hospitals and/or umbilical cord blood banks (umbilical cord blood databases) as an organizational unit.
  • networks for example a registry
  • umbilical cord blood banks umbilical cord blood databases
  • independent hospitals and independent institutions are supported as organizational units. In other words, preferably, there can still also be hospitals or institutions that are not assigned to any network. Only those hospitals that have no subsidiary hospitals are identified as independent hospitals.
  • the system and/or the platform continues to support independent umbilical cord blood banks and umbilical cord blood databases as organizational units, i.e. those umbilical cord blood databases that are not assigned to any network.
  • An independent umbilical cord blood database cannot include other umbilical cord blood databases.
  • One advantage of the invention is the flexibility of the system, which makes it possible to add additional organizational units to it at any time.
  • donor registries or tissue databases can be added as additional institutions and can therefore greatly expand the application range of the invention.
  • newly added institutions can likewise be part of a network.
  • an umbilical cord blood database is the institution and includes or offers these umbilical cord blood units as preparations.
  • the organizational units have technical attributes.
  • some attributes are ones that all organizational units possess. These attributes include: name, description, address, contact person, billing address, contact person billing, and logo.
  • a network it is preferable for a network to have no other attributes. It is also preferable for a hospital and an institution to have an identification (ID) as an additional attribute. Furthermore, it is preferable for umbilical cord blood databases to also have an accreditation in addition to an identification.
  • ID identification
  • umbilical cord blood databases it is preferable for umbilical cord blood databases to also have an accreditation in addition to an identification.
  • the attribute “default language” it is preferable for the attribute “default language” to no longer be an attribute of the organizational units.
  • the default language is defined for the specific user. This prevents the occurrence of conflicts when a user is assigned to different organizational units.
  • Groups view for networks that include hospitals and institutions, preferably umbilical cord blood databases
  • Hospitals view for networks of hospitals or for independent hospitals
  • Umbilical cord blood databases view for networks of umbilical cord blood databases or independent umbilical cord blood databases
  • Back office view for administration of the system
  • the user is then shown the respective view as a function of his assignment to organizational units or organizations.
  • the functionalities that are available in a view are in turn dependent on his user roles.
  • the views available to the user as well as their design are thus a function of the organizations and organizational units to which the user is assigned and their configuration (for example the network contains only hospitals).
  • the visibility of the functionalities (and of the menu items that enable the access) depends on the assignment of the user to the organizations or organizational units and on his roles.
  • a user is assigned to one or more hospitals. The user sees only the hospitals view. 2. A user is assigned to one or more umbilical cord blood databases. The user therefore sees only the umbilical cord blood databases view. 3. A user is assigned to one or more hospitals and one or more umbilical cord blood databases. The user sees the groups view, which provides access to the hospital view and the umbilical cord blood databases view.
  • the top-level menu item is not respectively shown.
  • the “groups view” and the “back office view” are never shown as menu items.
  • the “hospitals view” and “umbilical cord blood databases view” are only shown if a network contains hospital(s) and umbilical cord blood database(s).
  • the data (patients, messages, hospitals) shown in the accessible overviews are restricted by the assignment of the user to one or more hospitals and by the role of the user. It is thus possible to determine very individually which data a user can access and edit.
  • an umbilical cord blood database or a plurality of umbilical cord blood databases of a network a component or view is required, which makes accessible or provides the following functionalities:
  • This view is only visible if the network contains only umbilical cord blood databases; otherwise, this component is the network view. 5. Preferences—Access to the preferences of the currently logged-in user; this view is only visible if the network contains only umbilical cord blood databases; otherwise, the component is the “groups view.”
  • the organizations overview is only accessible for back office users and displays in tabular form all organizations that have been created in the platform and/or system and also offers the functionality of creating all available organizations and organizational units and their users as well as associated data (see FIG. 3 ).
  • the organizations overview in this case is hierarchically arranged in accordance with the structures that are available in the platform and/or the system. In other words, on the top level, for example only independent hospitals, umbilical cord blood databases, and networks are visible. In addition, the create function is restricted to only these organization types. To edit the structure of a network, it is necessary to correspondingly navigate one level down. Here, it is then possible to create and edit the units and users of the network.
  • the back office does in fact also technically constitute an organizational unit, but it represents a special organizational unit that does not possess any properties or the like.
  • the creation of users for the back office occurs through direct access via the back office view.
  • hospitals it is advantageously possible to show hospitals and the data associated with a hospital. In this case, it is not important whether it is an independent hospital, a hospital in an “exclusively hospitals” network, or a hospital in a “mixed” network.
  • the hospitals overview always shows the corresponding hospital(s) in tabular form. Only in the case of a back office user is it also necessary to provide the functionality of creating a hospital for the corresponding network from which one has navigated into the hospitals overview.
  • the hospitals overview shows the hospitals and their data in tabular, context-sensitive form and permits access to the following functions:
  • Context-sensitive displays 3.1 Access via the “organizations view” or “hospitals view”
  • the display of hospitals is also limited by the assignment of the user. In other words, the user only sees the hospitals to which he is assigned. A back office user is not subject to these restrictions.
  • the umbilical cord blood databases overview is in particular used to display umbilical cord blood databases and to edit the data associated with umbilical cord blood databases. In this case, it is not important whether they are independent umbilical cord blood databases, umbilical cord blood databases in networks made up of exclusively umbilical cord blood databases, or umbilical cord blood databases in mixed networks.
  • the umbilical cord blood database overview always shows the corresponding umbilical cord blood database(s) in tabular form. Only in the case of a back office user is it necessary to provide the functionality of creating an umbilical cord blood database for the corresponding network from which one has navigated into the umbilical cord blood databases overview.
  • the umbilical cord blood database overview shows the umbilical cord blood databases and their data in tabular, context-sensitive form and permits access to the following functions:
  • Context-sensitive displays 3.1 Access via the “organizations view” or “umbilical cord blood databases view” (contains the network of the umbilical cord blood databases)
  • the display of umbilical cord blood databases is also limited by the assignment of the user. In other words, the user only sees the umbilical cord blood databases to which he is assigned. A back office user is not subject to these restrictions.
  • the users overview is used to display user data and to create and/or edit these data.
  • the users view is also flexible and displayed in tabular form in accordance with the navigation path and/or organization to which the user is assigned.
  • the users overview shows the users and their data in tabular, context-sensitive form and permits access to the following functions:
  • Email address last name, first name, role, assignments (to organization(s)), and last login
  • Edit (user), create (access to create/edit users view), show patients, reassign patients
  • Context-sensitive displays 3.1 Access via the groups view (network with hospitals and umbilical cord blood databases)
  • the access to the users view is permitted only to users with administrator roles and/or to back office users.
  • the system also includes a create/edit users view, which offers the following functionalities:
  • the invention has also added primarily the following functionalities:
  • the user is always created and implicitly assigned in the context in which the create function has been activated.
  • the user is automatically assigned to this hospital.
  • the assignment is to the network. The detailed assignment to organizations of the network is carried out as described above.
  • the user is assigned to the back office.
  • Group 1 back office roles
  • Group 2 hospital roles
  • Group 3 umbilical cord blood database roles
  • the user that has been/will be created is a “network user,” i.e. the user was created in the context of a network (groups), then it is possible in the create/edit users view to carry out the assignment to the organizations (hospital(s) and/or umbilical cord blood database(s)).
  • a view of the available organizations and the already performed assignments is required here. It is also possible to simultaneously assign a user to all available organizations of the network.
  • a “hospital administrator” and/or an “umbilical cord blood database administrator” who belongs to a network can advantageously assign users that he creates only to organizations to which he himself is assigned.
  • the create and edit groups view is opened from the organizations overview and permits the display and editing of fields of the master data of a network (groups).
  • the patients overview shows all patient data in tabular, context-sensitive form.
  • the display of patients depends on a user's assignment to organizational units (hospitals) and on the user's role.
  • hospitals organizational units
  • a user can only see the patients of the hospitals to which he is assigned.
  • hospital coordinator he is even restricted to only the patients that he himself has created.
  • the hospital to which a patient is assigned is shown in the “patients overview” (new column). This is necessary in order to be able to filter by the patients of a hospital.
  • the user When creating the patient, the user, depending on his assignment to a hospital or to several hospitals, must correspondingly have the option to select the hospital to which he wishes to assign the patient.
  • the hospitals available for selection were always the hospitals of the search center to which the user was assigned.
  • the user When creating CBUs, the user, depending on his assignment to an umbilical cord blood database or to several umbilical cord blood databases, has the option to select the umbilical cord blood database to which he wishes to assign the CBU.
  • the umbilical cord blood database there was always one unique assignment here in the context of the umbilical cord blood database. Now, it is advantageously possible to assign it selectively.
  • the umbilical cord blood database ID can be determined by the platform. This is because the user is assigned to exactly one database.
  • the umbilical cord blood database to which a CBU is assigned must be visible in the “CBU overview.” This is necessary in order to be able to filter by the CBUs of an umbilical cord blood database.
  • the hospital messages overview shows all messages in tabular, context-sensitive form.
  • the display of messages depends on a user's assignment to organizational units (hospitals) and on the user's role.
  • hospitals organizational units
  • a user can only see the messages of patients from the hospitals to which he is assigned.
  • hospital coordinator In the case of a “hospital coordinator,” he is even restricted to only the patients that he himself has created.
  • a user preferably has access only to messages of patients to whose data he has access.
  • the hospital to which a message is assigned is shown in the “hospital messages overview.” This advantageously permits a filtering by messages of a hospital.
  • the umbilical cord blood database messages overview shows all messages in tabular, context-sensitive form.
  • the display of messages depends on a user's assignment to organizational units (umbilical cord blood databases).
  • organizational units umbilical cord blood databases.
  • a user can only see the messages from the umbilical cord blood databases to which he is assigned.
  • the umbilical cord blood database to which a message is assigned is shown in the “umbilical cord blood database messages overview” (new column). This is necessary in order to be able to filter by the messages of an umbilical cord blood database.
  • the back office messages overview shows all messages in tabular, context-sensitive form.
  • each request type For each hospital and umbilical cord blood database, it is possible for each request type to activate an approval step that comes after the creation of a request and before its transmission to the umbilical cord blood database.
  • the confirmation steps can only be carried out by users in a manager role.
  • the invention has added the following new request statuses:
  • a request After a request is created, it is given the “Waiting for approval” status if a confirmation step is defined for the corresponding request type. After the confirmation by a user with the role of “hospital manager” (requests were previously created only on the hospital side), then in accordance with the request type, the status is moved one step further (for example “Requested”) and can then be seen on the umbilical cord blood database side.
  • the user with the role “hospital manager” must have the option to refuse a request with a status of “Waiting for approval.” In this case, the request is then given the status “Refused.” When it has this status, the request is only visible on the hospital side.
  • the status value “Waiting for approval” in this case is only visible on the hospital side because the request only becomes visible on the umbilical cord blood database side after it has the status “Requested” (Reservation request “Reserved”).
  • the status value “Approved” is visible on both the hospital side and the umbilical cord blood database side.
  • request type For each request type, it must be possible to configure whether a confirmation step by a user in a manager role is required or not. This relates to all request types that are available in the platform and/or system. Preferred request types are: reservation request, order request, HLA-typing request, sample request, colony assay request.
  • the hospital administrator can activate confirmation steps on the hospital level (only for assigned hospitals).
  • the umbilical cord blood database administrator can activate confirmation steps on the umbilical cord blood database level (only for assigned umbilical cord blood databases).
  • the back office user can activate confirmation steps on both of the hospital level and the umbilical cord blood database level.
  • an option to define confirmation-relevant request types must not be available at a network (groups) level.
  • the status bar displays the new status as follows:
  • reservation request If a reservation request has turned into an order request and a confirmation step is defined for the order request, then the reservation request must continue until the order request has been confirmed, i.e. switches from the status “Waiting for approval” to the status “Requested.”
  • the reservation request continues unchanged and expires when the order request has the status “Waiting for approval.” The user is then free to extend the reservation as usual.
  • another level is provided for restricting the visibility of requests.
  • the visibility of a request is additionally dependent on the assignment of the user to one or more organizations, the user's role, and the status of the request. According to the combination of these factors, the request is either visible or not in the request overview.
  • New or changed requests can be marked.
  • a request must be marked as changed by a user in the context of a hospital role basically when the other side performs a modification and the user is the owner of the request.
  • requests are basically only marked for users with the role “umbilical cord blood database supervisor” and “umbilical cord blood database coordinator” if the requests are new or have been changed by the other side.
  • the invention relates to the control system; the user sends a query to an organization in order to identify inventories; the inventories are stored in locally available database systems and in remote database systems, characterized in that
  • a user can therefore create a query that is simultaneously sent to all relevant database systems contained within the organizational units.
  • the new and optimized access rights make it possible to quickly and selectively answer customized queries.
  • 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, characterized in that
  • the use is particularly preferable when it is intended for identification of an umbilical cord blood unit. It has turned out that primarily in this area, there is a considerable need for systems and platforms that support complex organizational structures and permit searches in distributed inventories. The invention therefore simplifies these processes and is advantageous in comparison to the prior art.
  • the invention consequently describes a new technology for searching for stem cell products in distributed inventories. It supports complex, decentralized organizational structures that the search function is able to make use of in an advantageous way.
  • the invention also relates to a method for identifying inventories in which the inventories are stored in locally available database systems and remote database systems, characterized in that
  • the system and the method support the searching of inventories of for example stem cell products provided in direct, i.e. locally available, databases or systems and in distributed ones, i.e. ones composed of other databases or systems that are also remote.
  • the search is performed in hierarchical fashion with the different inventories, based on the different response times and structures:
  • the access to functionalities for the user of a network with hospitals and umbilical cord blood databases is provided through the combination of corresponding roles. For example, if a user is assigned to a hospital and to an umbilical cord blood database of a network (groups) and if he should in this case have access to all patients and messages, etc., then he must be assigned the roles of “hospital supervisor” and “umbilical cord blood database supervisor.”
  • FIG. 1 shows a preferred organizational model. It shows the new technical data structures that support the complex organizational structure of the invention.
  • FIG. 2 shows the available views in the example of an umbilical cord blood database.
  • FIG. 3 shows a preferred organizational overview. This overview is only accessible to the back office user and displays in tabular fashion all of the organizations that have been created in the platform/system and also offers the functionality of creating all available organizations as well as their users and associated data.
  • FIG. 4 shows a preferred hospital overview that is used for displaying hospitals and for editing data associated with them.
  • FIG. 5 shows a preferred umbilical cord blood database overview.
  • FIG. 6 shows a preferred user overview, which is used for displaying the users and for editing and creating them.
  • FIG. 7 shows how new users can be created and how existing users can be edited.
  • FIG. 8 gives an overview of the approval process. The figure schematically depicts the status transitions.
  • FIG. 9 schematically depicts the structure of the system for searching distributed inventories.
  • FIGS. 1 through 9 show the detailed schedule of the request workflow along with all of the requirements for display by the system.
  • User A hospital+umbilical cord blood database administrator
  • the network A is composed of two hospitals and an umbilical cord blood database. Consequently, user A is shown the groups view. He therefore has access to the hospitals view and to the umbilical cord blood databases view and, through the administrator roles, also has access to user administration for the hospitals and for the umbilical cord blood database.
  • HLA-A String Values for both (HLA loci, n digits + N, value) validation with HLA validator HLA-B
  • HLA validator HLA-C String Values for both (HLA loci, n digits + N, value) validation with HLA validator HLA-DRB1
  • HLA validator HLA-DQB1 String Values for both (HLA loci, n digits + N, value) validation with HLA validator Comment Text Standard x x x comment field Comment Display Comment history history displayed with the date/time Created/ Display Creation/modification modified date displayed the same as in the patient chart Create Next status “Requested” depends on or “Request “Waiting approval” settings for (by manager) approval” Approve Approve button in Requested Approved “Requested” status is only visible
  • HLA-A String Values for both loci
  • HLA n digits + N, value validation with HLA validator HLA-B
  • HLA n digits + N, value validation with HLA validator HLA-C
  • HLA n digits + N, value validation with HLA validator HLA-DRB1
  • HLA n digits + N, value validation with HLA validator HLA-DQB1 String Values for both loci
  • HLA-A String Values for both loci, x (HLA n digits + N, validation value) with HLA validator HLA-B String Values for both loci, x (HLA n digits + N, validation value) with HLA validator HLA-C String Values for both loci, x (HLA n digits + N, validation value) with HLA validator HLA-DRB1 String Values for both loci, x (HLA n digits + N, validation value) with HLA validator HLA-DQB1 String Values for both loci, x (HLA n digits + N, validation value) with HLA validator Comment Text Standard comment field x Comment Display Comment history history displayed with the date/time Created/ Display Creation/modification modified date displayed the same as in the patient chart Create Next status depends on “Request approval” settings (by manager) Approve Approve button in “Requested” status is only visible on CBB side when “Request approval” is activated Save Typing
  • Request confirmation dialog text (scheme) Request type Part Action Message type Text All C/CBB/BO Any Message Do you really want to ⁇ action> the ⁇ requesttype> request? Special cases All CBB/BO Reject Warning Do you really want to reject the ⁇ requesttype> request? Reservation C Cancel Warning Do you really want to cancel the ⁇ requesttype> request? Order, DNA C Cancel Warning Do you really want to cancel the sample, HLA ⁇ requesttype> request? There may be typing, colony costs associated. assay Order, DNA C Create Warning Do you really want to cancel the sample, HLA ⁇ requesttype> request? You will be typing, colony charged for the costs incurred.
  • assay Order DNA C Approve Warning Do you really want to cancel the sample, HLA ⁇ requesttype>request? You will be typing, colony charged for the costs incurred.
  • DNA C Shipping Message Do you really want to set the sample failed ⁇ requesttype> request to “Shipping failed”?
  • Step 1 Step 2 Step 3 Step 4 Step 5 Step 6
  • Step 6 In status HLA typing request Create Requested Processing Completed Received “Creation” or “Waiting for approval” Create Requested Processing Completed Received Requested Create Requested Processing Completed Received Received “Approved” or “Processing” Create Requested Processing Completed Received Completed Create Requested Processing Completed Received Received Create Requested Canceled Canceled Create Requested Rejected Rejected Create Refused Refused Order request Create Requested Processing Shipped Received “Creation” or “Waiting for approval” Create Requested Processing Shipped Received Requested Create Requested Processing Shipped Received “Approved” or “Processing” Create Requested Processing Shipped Received Shipped Create Requested Processing Shipped Shipped Received Create Requested Processing Shipped Shipped Shipment Shipment failed failed Create Requested Inquiry Processing Shipped Received Inquiry Create Requested Inquiry Processing Shipped
  • M Marking: The request is marked for the user when it reaches the status marked. After the request is activated, the marking disappears. If the request reaches the same status again because a user with a role on the other side (hospital roles versus CBB roles) has made a change, then the request is marked again (for example saving again after a change to the hospital address of a request with the status “Requested” results in the request being marked again on the CBB side)
  • A Action required: The user must perform an action in order to continue the workflow. The field “Action required” is set to “Yes.” Owner: The user is the owner of the request, i.e. he is assigned to the patient to which the solution and the associated CBUs and their requests belong.

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)
US14/359,103 2011-11-18 2012-11-19 Central control of distributed organizational structures Abandoned US20140324455A1 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US14/359,103 US20140324455A1 (en) 2011-11-18 2012-11-19 Central control of distributed organizational structures

Applications Claiming Priority (7)

Application Number Priority Date Filing Date Title
US201161561398P 2011-11-18 2011-11-18
EP11075253.2 2011-11-18
EP11075253 2011-11-18
EP11075252 2011-11-18
EP11075252.4 2011-11-18
PCT/EP2012/072991 WO2013072524A1 (de) 2011-11-18 2012-11-19 Zentrale steuerung verteilter organisationsstrukturen
US14/359,103 US20140324455A1 (en) 2011-11-18 2012-11-19 Central control of distributed organizational structures

Publications (1)

Publication Number Publication Date
US20140324455A1 true US20140324455A1 (en) 2014-10-30

Family

ID=48429018

Family Applications (1)

Application Number Title Priority Date Filing Date
US14/359,103 Abandoned US20140324455A1 (en) 2011-11-18 2012-11-19 Central control of distributed organizational structures

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)

Cited By (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

Citations (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
US20060184455A1 (en) * 2005-02-11 2006-08-17 Meyer Steven P System and method for privacy management
US20060218394A1 (en) * 2005-03-28 2006-09-28 Yang Dung C Organizational role-based controlled access management system

Patent Citations (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
US20060184455A1 (en) * 2005-02-11 2006-08-17 Meyer Steven P System and method for privacy management
US20060218394A1 (en) * 2005-03-28 2006-09-28 Yang Dung C Organizational role-based controlled access management system

Cited By (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

Also Published As

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

Similar Documents

Publication Publication Date Title
US10474646B2 (en) Systems and methods for creating a form for receiving data relating to a health care incident
US9779210B2 (en) Enterprise management system
US8271477B2 (en) Methods and systems for accessing data
US20110010728A1 (en) Method and System for Service Provisioning
US10109027B1 (en) Database access and community electronic medical records system
US20190095080A1 (en) Database management system
US20020083075A1 (en) System and method for a seamless user interface for an integrated electronic health care information system
US20030045958A1 (en) System and user interface for processing task schedule information
US20030078810A1 (en) Resource monitoring and user interface system for processing location related information in a healthcare enterprise
TW201721573A (zh) 用於管理電子健康護理資訊的系統和方法
CA2531887A1 (en) System and method for providing forms on a user interface
CA2408991A1 (en) A user interface system for maintaining organization related information for use in supporting organization operation
JP2005507123A (ja) ヘルスケア事業の活動を支援するヘルスケア関連情報を管理するシステム
US20030225728A1 (en) Pharmacy system and method
US20160357919A1 (en) Centralized formulary system and method
JPH0857021A (ja) 配合禁忌チェック方式
US20140324455A1 (en) Central control of distributed organizational structures
US20040102998A1 (en) System and method to support patient identifiers for imaging and information systems in health care enterprise
JP2011008543A (ja) 看護指示通知装置および看護指示通知プログラム
JPH1166203A (ja) オーダリングシステム
JP2002183302A (ja) 病院情報システム
KR20140124208A (ko) 진료 오더 처리 서비스 제공 방법 및 시스템
AU2002232767A1 (en) System and method for integration of health care records, and for a seamless user interface, for an integrated electronic health care information system
Shea et al. Large-Scale Clinical Systems. Large Scale Integrated Ambulatory Care Systems: Columbia-Presbyterian Medical Center Integrated Academic Information Management System (IAIMS) Outpatient Clinical Information System Implemented in a Faculty General Medicine Practice
AU2005201124A1 (en) System and method for integration of health care records, and for a seamless user interface, for an integrated electronic health care information system

Legal Events

Date Code Title Description
AS Assignment

Owner name: CYTOLON AG, GERMANY

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:SCHIMANSKI, ANDREAS;SCHLIEHE-DIECKS, RALF;KLEIN, THOMAS;SIGNING DATES FROM 20140417 TO 20140422;REEL/FRAME:032957/0359

STCB Information on status: application discontinuation

Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION