SYSTEMS, METHODS AND MACHINE READABLE PROGRAMS FOR ISOLATION OF DATA
The disclosure provides systems, methods and machine readable programs for isolation of data. In some implementations, this is performed on a healthcare information system (HCIS). It will be noted, however, that the disclosed embodiments can be used for different fields of endeavor, and for data other than medical patient data. After capturing data elements, such as patient records, the system automatically reviews and can extract the data elements in an isolated location, generates and stores reports, encrypts the reports, and sends them to multiple designated workstations and devices throughout a network at regular intervals to ensure that the most recent patient data is captured. After a compromising event, such as a system outage or a cyberattack, the updated patent data can be accessed locally by way of a locally installed client program.
The present patent application claims the benefit of priority to U.S. Provisional Patent Application No. 62/802,769, filed Feb. 8, 2019. The aforementioned patent application is hereby incorporated by reference in its entirety for any purpose whatsoever.
COPYRIGHT NOTICEA portion of the disclosure of this patent document (including Appendices) contains material which is subject to copyright protection. The copyright owner has no objection to the reproduction by anyone of the patent document or patent disclosure as it appears in the Patent and Trademark Office, patent file or records, but otherwise reserves all copyrights whatsoever.
BACKGROUNDDuring a ransomware attack, a user loses access to their computer system. This can have grave consequences in various settings, such as hospitals and clinics. The present disclosure provides solutions for these and other problems, as set forth herein.
SUMMARY OF THE DISCLOSUREThe purpose and advantages of embodiments of the present disclosure will be set forth in and become apparent from the description that follows. Additional advantages of embodiments of the present disclosure will be realized and attained by the methods and systems particularly pointed out in the written description and claims hereof, as well as from the appended drawings.
To achieve these and other advantages and in accordance with the purpose of the disclosure, as embodied herein, in accordance with some aspects, the disclosure provides methods, and related devices and machine readable programs that allow a user to capture or generate reports using data located on a computer system. In some implementations, including those illustrated herein, this is illustrated as being performed on a healthcare information system (HCIS). It will be noted, however, that the disclosed embodiments can be used for different fields of endeavor, and for data other than medical patient data. After capturing data elements, such as patient records, the system automatically reviews and can extract the data elements in an isolated location, generates and stores encrypted reports, for example, at multiple local designated workstations and devices throughout a network at regular intervals to ensure that the most recent patient data is captured. Having up-to-date patient information available whenever clinicians and admissions need it ensures they can deliver quality patient care, maintain high patient satisfaction and avoid costly or life threatening mistakes even when their systems or networks are unavailable, such as in the event of a compromising event, such as a system outage or cyberattack. By ensuring clinicians have access to critical data during periods of system failure or extended downtime, healthcare organizations mitigate risks to patient care and safety.
In accordance with one embodiment, a method of isolating data to protect the data from a compromising event, such as a cyberattack, is provided that permits access to the data after the compromising event initiates. The method includes identifying data to be isolated on a first computer system via processor, the first computer system being vulnerable to a compromising event. The method further includes selecting the data to be isolated on the first computer system, forwarding the data to a second computer system via processor to isolate the data from the first computer system, analyzing the data on the second computer system via processor, and transforming the data into a document file.
In accordance with some embodiments, the method can further include writing the selected data to a data file via a processor on the first computer system. The method can further include reading the data from the data file on the second computer system via processor prior to the analyzing step. The data can be selected on the first computer system in accordance with a plurality of predefined rules. In certain embodiments, the data file includes no executable code. In certain embodiments, the data file is a text file. If desired, the data file can be a database file. The text file includes ASCII characters. In some implementations, writing the data to the data file can include sending the data to a printer port. The data file can be a print file, such as a PCL file or a post script file.
In accordance with particular embodiments, the data to be transferred typically includes patient data. But, the data to be transferred can additionally or alternatively include financial data, message data, personal data, form data and image data.
In some embodiments, the analyzing step can include analyzing characters in the data file for patient information. If desired, transforming the data into the document file can include encrypting the data in the document file.
In further embodiments, the method can include storing the document file and/or delivering the document file to a third computer system. If desired, analyzing the data while on the second computer system can include determining at least one location for delivering a document file based on at least one user-defined rule. The document file can be delivered to the at least one location automatically. If desired, the document file can be delivered to a plurality of disparate locations that may be disparate locations. If desired, the method can include permitting a user to monitor and correct delivery errors through report queues. In some embodiments, the third computer system can be physically located remotely with respect to the first computer system and the second computer system.
In some implementations, the method can further include purging data older than a predetermined age, and/or data based on location of the data.
In some embodiments, the method can further include analyzing the forwarded data file on the second computer system via processor to determine if the data file includes any computer viruses therein or attached thereto prior to reviewing data in the data file.
The disclosure further provides methods of retrieving medical patient data after a compromising event, such as a cyberattack or other system outage. Some embodiments of the method include providing a non-transitory machine readable medium storing instructions executable by a processor which, when executed by the processor, cause the processor to provide an authentication interface to permit a user to be granted access to at least one encrypted document file that is also stored on the non-transitory machine readable medium, said at least one encrypted document including patient data for at least one patient.
In some embodiments, the method can further include authenticating and unencrypting said at least one encrypted document on a local machine. The method can still further include providing instructions to the user in order to access the at least one encrypted document file. The instruction to access the at least one encrypted document file can be located on and accessed from a server. The instruction to access the at least one encrypted document file can be located on and accessed from a web-enabled server. If desired, the instruction to access the at least one encrypted document file can be located on and accessed from the non-transitory machine readable medium. The authentication interface can be provided by executable code stored on the non-transitory machine readable medium. In some embodiments, executable code stored on the non-transitory machine readable medium can be configured to seek an active directory on a server in order to authenticate the user. If desired, the executable code can be configured to generate and store audit trail data in an encrypted audit trail data file indicating when data was accessed from the non-transitory machine readable medium and who accessed the data from the non-transitory machine readable medium. The audit trail data file can be set to an active directory path and is configured to query said active directory path by default.
The disclosure also provides embodiments of a method of providing updated data to clinicians in a hospital or clinic after a compromising event, such as a cyberattack has compromised a computer system of the hospital clinic. Certain embodiments of the method include generating patient data reports that include patient data obtained from a healthcare information system (HCIS) of the hospital or clinic prior to the compromising event, encrypting the patient reports, storing the encrypted reports on a secure server in a manner that permits their retrieval after the network of the hospital or clinic becomes disabled due to the compromising event, and repeating the aforementioned steps at regular intervals to ensure that recent patient data is captured to permit said recent patient data to be accessed by clinicians after the compromising event.
The disclosure further provides various embodiments of a non-transitory machine readable medium storing instructions executable by a processor which, when executed by the processor, cause the processor to carry out any of the functions set forth herein. The disclosure also provides various embodiments of systems for carrying out the functions set forth herein.
It is to be understood that both the foregoing general description and the following detailed description are exemplary and are intended to provide further explanation of the claimed embodiments.
The accompanying drawings, which are incorporated in and constitute part of this specification, are included to illustrate and provide a further understanding of the methods and systems of the disclosure. Together with the description, the drawings serve to explain the principles of embodiments of the present disclosure.
Reference will now be made in detail to the present preferred embodiments of the disclosure, examples of which are illustrated in the accompanying drawings. The methods and corresponding steps of the disclosure will be described in conjunction with the detailed description of the system.
The devices, machine readable programs and methods presented herein may be used for myriad purposes. In particular illustrated embodiments, they may be used for management of patient medical data. But, they may additionally or alternatively used for other types of sensitive data, including financial data, or other personal or private data, business processes, technical information, manufacturing specifications, identification information, government information, military information, law enforcement data, and the like. Additional illustrative, non-limiting examples of the disclosed embodiments are provided in the Appendix appended to U.S. Provisional Patent Application No. 62/802,769, filed Feb. 8, 2019, which is incorporated by reference herein in its entirety for any purpose whatsoever.
In the medical field, network and system downtime, whether unplanned or scheduled, can create a potential risk of reduced patient care. When the electronic patient information is unavailable due to network or system outages, an organization's ability to care for the patients can be compromised. Being able to continually retrieve and review patient information and reports can be critical, if the host system is available or unreachable for any reason. Embodiments in accordance with the present disclosure allow for decentralized backup of patient information. Unlike a centralized approach, in accordance with various embodiments herein, a user can capture reports generated by a HCIS, for example, automatically extract data elements from the reports, and store the reports at locations throughout a network at regular intervals.
Some of the disclosed embodiments are configured so that the most recent patient data is captured. Thus, if a user's network or system becomes unavailable, those individuals who need immediate access to timely information can search the locally stored reports for patient information, and view or print it as needed.
Thus, embodiments are provided that can in turn provide business continuance, for example, after a compromising event such as a cyberattack or other system outage or system maintenance. In some embodiments, two applications are provided. A first administrator server application can be used for isolating important data on a vulnerable computer system for being accessed after a disruption by moving the isolated data to a secured server, and a client application can be provided for a user to access the isolated data on the secured server after the disruption. A variety of different types of reports can be prepared and sent to the secured server. It is also possible to separate, process, and deliver to specific workstations located throughout an organization, such as a hospital.
In some embodiments, a system is provided that can receive reports, separate reports by patient, converts reports to a portable document (e.g., .PDF) format, encrypt the reports, and distributes reports to workstations throughout a facility (e.g., hospital). These distributed reports are available during system down time. The system can receive many different types of reports, such as a EMAR (Electronic Medication Administration Record), a MAR (Medication Administration Record), a LAB Summary Report, a MPI (Master Patient Index), a Nursing Rounds Report, a Physician Rounds Report, a KARDEX report, a Patient Profile report, a Surgical Case List report, an Alpha Census report, a Location Census report, a Dietary Report, and batch reports.
For purposes of illustration, and not limitation, as illustrate in
In some implementations, certain reports can print as a single file for an individual patient, while others can print as a batch-file, which contains multiple patients. The system can be configured to determine if such batch-reports are separated by patient or location. If a report is separated by patient, each patient can have a separate report that can be delivered to the workstation that is in the unit housing the patient. If a report is separated by location, each location can have a separate file that only contains patients for that location. Those reports can then be delivered to the workstations that are mapped to those locations. Reports, for example, for an ICU (Intensive Care Unit) location can be delivered to the workstation in the ICU. Reports for a physical location in a facility (e.g., “2West”) can be delivered to a workstation in that location.
In some implementations, certain reports may not need to be separated. This can be due to a variety of reasons. For example, it may not be possible or practicable to separate the report by patient or location. An example of a report that cannot be separated by patient or location is a patient census listing all patients present in the facility, or admitted during a particular time window. Moreover, in some instances, a report may be better presented as a whole document without being broken out by patient or location. An example of this may be the LAB Summary, which is delivered to a downtime workstation in the LAB. If desired, the system can be configured to separate one or more reports at the middle or end of a page. One or more user-selected criteria can be used by the system to separate reports, such as a patient's name, patient's account number, location, and the like. Or, certain key words or criteria can be used for separating reports, such as END OF REPORT. Various embodiments are configured so as to not remove or add information to a report. If desired, a given system can be configured to separate or not separate a specific report based on specified criteria. Separated reports can be delivered to certain workstations while unseparated versions of the same report can be delivered to other workstations. For example, a MAR report can be separated by patient and be delivered to workstations at a first set of locations. A non-separated MAR report can be delivered to a workstation in a second location, such as a hospital pharmacy.
Email Notifications
It is preferred that systems in accordance with the present disclosure are able to continuously process reports without interruption. This helps ensure that if system downtime does occur, workstations throughout the hospital will have the most up-to-date information available for their staff. In some implementations, this can be facilitated by setting up Email Notifications that inform an administrator know if a report was not able to process through the system correctly.
In some embodiments, to set up email notifications, a connection to a facility's (e.g., hospital's) (SMTP) Simple Mail Transfer Protocol server can be configured. As an illustrative embodiment, the interface in
After establishing the SMTP settings, the next step is to enable different email alerts. Enabling different email alerts can be done under the email notifications menu in the settings list. The Email Notification Dialog lists all the alert notifications that can be set up. The different alerts illustrated below relate to different queues, which in turn correspond to different stages that a report is in while it is processing through the system.
If desired, a user can set up alerts such that the user can receive a notification soon after a problem arises. The timing of the alerts can be set up in accordance with an expected timing scheduling of the delivery of reports. For example, if a report is expected to come in to the LPD Queue every hour. the initial alert may be set to one hour and fifteen-minutes. In this example, there is a fifteen-minute window for the LPD issue to get addressed before an alert is triggered. The same user may alternatively choose to set the delay to two-hours, so the user is not getting inundated with alert reminders while they work on fixing the original LPD issue. Further details on email notifications can be found in the Appendix appended to U.S. Provisional Patent Application No. 62/802,769, filed Feb. 8, 2019, which is incorporated by reference herein in its entirety for any purpose whatsoever.
Distribution Group ConfigurationDistribution Groups are used in cases where a report needs to be sent to multiple locations. This feature is illustrated with the use of two non-limiting examples. In a first example, an Intensive Care Unit (ICU) has multiple workstations that need to receive a copy of a report. A user of the system can set up an ICU Distribution Group that encompasses all the workstations within that unit that should be receiving reports. In accordance with another example, an Alpha Census of patients in a hospital facility might need to be sent to multiple units. In this example, a user of the system can set up a Distribution Group that includes the work stations that the Alpha Census needs to be sent to.
In some embodiments, a distribution groups can be built under the Location Mnemonic menu illustrated in
Next, a user can navigate to the distribution list menu as illustrated in
If the distribution group includes a general group of PC workstations that need to receive all instances of a specific report, the distribution group can be assigned to a report template. With reference to
The user can set up an active directory within the system using the GUI presented in
To enable active directory integration, a user can select the (Deliver Active Directory Enabled Client) check box and navigate through the prompts. A user can click on the Setup Active Directory button to obtain a list of available Domains. Domains that are to be granted access to the system Client will need to be moved from the Disabled table to the Enabled table. A user can move any security groups which should have access to log into the system Clients, over to the Enabled table. If the Security Group Enabled table is left blank, then all security groups have access to log into the system Clients. If there are multiple Domains, a Default Domain will need to be selected. Users in the Default Domain will not need to enter a Domain when logging into the System Client. Users not being logged into the Default Domain will need to enter in a Domain name as part of their login. With reference to
In order to set up an Active Directory for a specific location, with reference to the GUI in
To log into a system Client, users enter a user name and password. The system allows for the use of Active Directory accounts for logging into a system Client. The Active Directory settings allow a user to specify, enable, and disable Active Directories and Security Groups. Active Directory settings can be defined either globally, for all location mnemonics, or for an individual location mnemonic. It may be desirable to specify Active Directory settings for an individual location mnemonic. To specify the Active Directory settings for all location mnemonics, see “Active Directory Settings” in Chapter 15, “System Settings” in the Appendix appended to U.S. Provisional Patent Application No. 62/802,769, filed Feb. 8, 2019, which is incorporated by reference herein in its entirety. Table 5 below lists and describes the Active Directory settings:
The Active Directory settings allow you to specify which users can log into a system Client. To configure Active Directory settings, perform the steps illustrated in Table 6 below:
In some embodiments, after the system administrator processes reports the system administrator then encrypts the reports. The system administrator then delivers the reports to a workstation where they may be available for viewing during downtime by using the system Client.
In some implementations, the system Client does not get installed. Rather, the Client is provided as an executable file (.exe) which is copied from the server to the shared folders along with patient reports. This permits the Client software to be accessed by a user from the shared folders. The system Client, when executed, decrypt's the reports on the workstation. The system Client can create an audit log to track access to the reports. The system Client can be configured to purge older reports from the workstation. A domain account should be assigned to run a variety of system services. The present discussion is directed to a Microsoft Windows environment, but it will be appreciated that the system can be configured to run on any operating system as appropriate. A first Admin Agent service permits the certificate password for each Location Mnemonic to be changed at each workstation. A Relay Agent service allows the reports, certificates, databases, and client to be delivered to each workstation. A further Purge Agent service allows the reports, and databases to be purged based on the criteria setup in the system Administrator. A GUI showing a listing of the services is presented in
Overall, embodiments of the disclosed systems are preferably so as to direct information as it is sent from an initial source, such as a Healthcare Information System (HCIS) system, in the case of a hospital, to the system administrator, and then to the workstations where it resides in case of downtime. Sometimes, it is possible that a report may not be forwarded by the system.
For purposes of illustration, and not limitation, as illustrated in
With reference to
With reference to
After the report has been processed through a template successfully by the secure server, it is sent to the Relay Queue/Pending database. The report is then taken up by the Relay Agent service running on the secure server. If the report is processed through the template successfully; but the system cannot identify which location it should be sent to, the report is then moved to the Unknown Location Logs as illustrated in
With reference to
With reference to
Once a report is identified and separated from a batch report, for example, it needs to be given a filename. Unseparated reports also need a filename. Using the features in the Filename Template Dialog discussed below, it is possible for a user to specify the filename assigned to a report. The filename can be, for example, a static text string, a name that is created from text captured from the report, or a combination of both. Filenames can be used in several places within the disclosed system. For example, filenames can be used to track reports within the system Administrator application, or to see if a report has been processed or delivered. Filenames can appear in Email alerts, letting administrators know which reports are having problems. The filenames display to the end users in the system Client and allow end users to more easily filter, organize and search for reports.
With reference to
The process of defining a filename for the report can be a two-step process. First, a user creates the format for the filename, that is, its template. Second, a user can formulate rules to locate the data on the report. The data can be entered in the variable fields within the filename template. Filenames can include free text and variable fields. Free text is any text that is entered manually and will remain static or unchanging within the filename. A variable field is text that can be extracted from within the report, and placed in to the filename. The variable field can change as it is dependent on the text in the report. Variable fields can help make filenames unique.
In accordance with one illustrative example, an EMAR (electronic medication administration record) is usually separated by individual patients so a filename will contain information about the patients, such as the patient name, account number, unit number, and location:
In accordance with further embodiments, the secure server of the system can be configured to permit a user to automatically capture and preserve information, such as patient information, generated from an information system, such as a HCIS. This information can then be sent at regular intervals and stored on local PCs, for example. The patient information can thus be stored as a backup strategy in the event of a network or system outage, such as one due to a cyberattack or other compromising event. The system can permit a user to access this patient information, which can be stored, for example, as PDF files for lookup, review, and/or printing. This eliminates the need for continuous printing of patient reports, substantially reduces paper usage, and saves hours of work generating the reports locally. Having up-to-date patient information whenever it is needed ensures access to the information when systems or networks are unavailable. It will be appreciated that this can facilitate the delivery of quality patient care.
Once installed and configured, embodiments in accordance with the present disclosure permit a user, such as a system administrator, to define rule-sets that are formulated based on the needs and requirements of a particular organization. These rule-sets can capture different types of reports and documents, and automatically direct them to a hard drive on a PC or to a printer. A secure server can receives reports on a scheduled basis from the HCIS in the form of print files, convert the print files to PDF documents and encrypt them for distributing them to workstations throughout the facility (e.g., hospital). These reports reside on those workstations until a downtime occurs at which point users may access the reports and use them to work through the downtime.
In planning which workstations should be used to receive downtime reports, there are several criteria which should be considered. It can be advantageous for the workstation to be located in an area that can be easily accessed by end users that will need to view downtime reports. It is also useful if the downtime workstation is connected to a backup power supply in case the facility suffers a power outage. It is also useful for the workstation to have a printer physically connected to it, or one connected nearby, that is also connected or connectable to an alternate power supply. Also, it is best to not select a workstation that tends to be turned off periodically or frequently, such as at the end of a shift. The secure server needs to be able to send reports to workstations that are able to receive them constantly to ensure that if a downtime does occur, that the workstations have the latest reports.
Logging in to System Client to Access InformationTo log in to a system Client, users are required to enter a user name and password. Normally, this would be the users' their Active Directory user name and password. However, there may be occasions when connectivity between the Active Directory server and the system Client is lost such that logging in is not possible in this manner. In this situation, users can use a backup login user name and password and the system (Client executable file) should be so configured. Thus, an associated Client Login Backup dialog can be provided in the system, accessible by a system administrator on the secure server, to permit a user to specify one or more backup login user names and passwords for use when connectivity between the Active Directory server and the system Client is lost.
With reference to
In further accordance with the disclosure, a report can be set up to automatically populate the list of users in the Client Login Backup. The LPD Queue name userloginsimport can be used to indicate to the system that the report contains data that can be imported into the Client Login Backup database. In accordance with some embodiments, the report can use the following data structure format:
username password
For example:
These procedures can be observed if the Active Directory system Client is enabled in the System Setting. To log into a system Client, a user is required to enter their username and password found in Active Directory. This is done through communication between an Active Directory domain controller and the client location. However, there may be occasions when connectivity between the Active Directory domain controller and the system Client is lost. In this situation, users will need to specify a username and password that is found within the Client Login Backup database to gain access to the client.
In further accordance with the disclosure, when Client Login Backup accounts are downloaded to the system Clients, there are settings that can be specified and applied for each download. To specify update settings, a user can perform the following steps set forth in the below Tables.
After these parameters have been set, an administrator can communicate this information to those individuals accessing the system Client.
The system coordinator includes a processor 901 that executes program instructions (e.g., system program instructions). The processor may be implemented using integrated circuits (ICs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), and/or the like. The processor may be connected to system memory 905 via a system bus 903. The system bus may interconnect these and/or other elements of the system coordinator via electrical, electronic, optical, wireless, and/or the like communication links. In various embodiments, the system bus may comprise one or more control buses, address buses, data buses, memory buses, peripheral buses, and/or the like. The processor may access, read from, write to, store in, erase, modify, and/or the like, the system memory in accordance with program instructions executed by the processor. The system memory may facilitate accessing, storing, retrieving, modifying, deleting, and/or the like data by the processor.
In various embodiments, input/output devices 910 may be connected to the processor and/or to the system memory, and/or to one another via the system bus. In some embodiments, the input/output devices may include one or more graphics devices 911. The processor may make use of the one or more graphic devices in accordance with program instructions (e.g., system program instructions) executed by the processor. The graphics device may be discreet, external, embedded, integrated into a CPU, and/or the like. A graphics device may operate in combination with other graphics devices (e.g., in parallel) to provide improved capabilities, data throughput, color depth, and/or the like.
In some embodiments, the input/output devices may include one or more audio devices 913. The processor may make use of the one or more audio devices in accordance with program instructions (e.g., system program instructions) executed by the processor. In one implementation, an audio device may be a sound card that may obtain (e.g., via a connected microphone), process, output (e.g., via connected speakers), and/or the like audio data (e.g., system data). The audio device may be discreet, external, embedded, integrated into a motherboard, and/or the like. An audio device may operate in combination with other audio devices (e.g., in parallel) to provide improved capabilities, data throughput, audio quality, and/or the like.
In some embodiments, the input/output devices may include one or more network devices 915. The processor may make use of the one or more network devices in accordance with program instructions (e.g., system program instructions) executed by the processor. In one implementation, a network device may be a network card that may obtain, process, output, and/or the like network data (e.g., system data). The network device may be discreet, external, embedded, integrated into a motherboard, and/or the like. The network device may operate in combination with other network devices (e.g., in parallel) to provide improved data throughput, redundancy, and/or the like. In some embodiments, the input/output devices may include one or more storage devices 919. The processor may access, read from, write to, store in, erase, modify, and/or the like a storage device in accordance with program instructions (e.g., system program instructions) executed by the processor. A storage device may facilitate accessing, storing, retrieving, modifying, deleting, and/or the like data (e.g., system data) by the processor. In one implementation, the processor may access data from the storage device directly via the system bus. In another implementation, the processor may access data from the storage device by instructing the storage device to transfer the data to the system memory and accessing the data from the system memory.
The storage device 919 may be discreet, external, embedded, integrated (e.g., into a motherboard, into another storage device), and/or the like. A storage device 919 may operate in combination with other storage devices to provide improved capacity, data throughput, data redundancy, and/or the like. Together and/or separately the system memory 905 and the one or more storage devices 919 may be referred to as memory 920 (i.e., physical memory).
System memory 920 contains processor-operable (e.g., accessible) system data stores 930. Data stores 930 comprise data that may be used (e.g., by the system) via the system coordinator. Such data may be organized using one or more data formats such as a database (e.g., a relational database with database tables, an object-oriented database, a graph database, a hierarchical database), a flat file (e.g., organized into a tabular format), a binary file (e.g., a GIF file, an MPEG-4 file), a structured file (e.g., an HTML file, an XML file), a text file, and/or the like. Data stores 930 may comprise a non-transitory machine readable medium storing instructions executable by processor 901 to perform a specified function. Accordingly, each of the respective data stores 930a-930c include programmatic instructions which, when executed by processor 901, provide for carrying out the steps of the systems described elsewhere herein.
For example, data stores 930a-930c may include instructions executable by processor 901 to retrieve from at least one database structured to recognize relations between the entities and the company, information regarding competitive suppliers of each of the plurality of entities, revenue information for each of the plurality of entities, and industry segment information for each of the plurality of entities.
Data stores 930a-930c may also include instructions executable by processor 901 to generate for display on a graphical user interface a first display including information for storing or processing reports as described herein, and provide for carrying out the steps of the systems described elsewhere herein.
Data may be organized using one or more data structures such as an array, a queue, a stack, a set, a linked list, a map, a tree, a hash, a record, an object, a directed graph, and/or the like. In various embodiments, data stores may be organized in any number of ways (i.e., using any number and configuration of data formats, data structures, system coordinator elements, and/or the like) to facilitate system operation. For example, system data stores may comprise data stores 930a-c implemented as one or more databases.
The entirety of this disclosure (including the written description, figures, claims, abstract, appendices, and/or the like) for SYSTEMS, METHODS AND MACHINE READABLE PROGRAMS FOR ISOLATION OF DATA shows various embodiments via which the claimed innovations may be practiced. It is to be understood that these embodiments and the features they describe are a representative sample presented to assist in understanding the claimed innovations, and are not exhaustive and/or exclusive. As such, the various embodiments, implementations, examples, and/or the like are deemed non-limiting throughout this disclosure.
Furthermore, alternate undescribed embodiments may be available (e.g., equivalent embodiments). Such alternate embodiments have not been discussed in detail to preserve space and/or reduce repetition. That alternate embodiments have not been discussed in detail is not to be considered a disclaimer of such alternate undescribed embodiments, and no inference should be drawn regarding such alternate undescribed embodiments relative to those discussed in detail in this disclosure. It is to be understood that such alternate undescribed embodiments may be utilized without departing from the spirit and/or scope of the disclosure. For example, the organizational, logical, physical, functional, topological, and/or the like structures of various embodiments may differ. In another example, the organizational, logical, physical, functional, topological, and/or the like structures of the system coordinator, system coordinator elements, system data stores, system components and their subcomponents, capabilities, applications, and/or the like described in various embodiments throughout this disclosure are not limited to a fixed operating order and/or arrangement, instead, all equivalent operating orders and/or arrangements are contemplated by this disclosure. In yet another example, the system coordinator, system coordinator elements, system data stores, system components and their subcomponents, capabilities, applications, and/or the like described in various embodiments throughout this disclosure are not limited to serial execution, instead, any number and/or configuration of threads, processes, instances, services, servers, clients, nodes, and/or the like that execute in parallel, concurrently, simultaneously, synchronously, asynchronously, and/or the like is contemplated by this disclosure.
Furthermore, it is to be understood that some of the features described in this disclosure may be mutually contradictory, incompatible, inapplicable, and/or the like, and are not present simultaneously in the same embodiment. Accordingly, the various embodiments, implementations, examples, and/or the like are not to be considered limitations on the disclosure as defined by the claims or limitations on equivalents to the claims.
This disclosure includes innovations not currently claimed. Applicant reserves all rights in such currently unclaimed innovations including the rights to claim such innovations and to file additional provisional applications, non-provisional applications, continuation applications, continuation-in-part applications, divisional applications, and/or the like. It is to be understood that while some embodiments of the system discussed in this disclosure have been directed to monitoring real time electronic trading data systems, the innovations described in this disclosure may be readily applied to a wide variety of other fields and/or applications.
Claims
1. A method of isolating data to permit access to the data during a system outage, comprising:
- identifying data to be isolated on a first computer system via processor;
- selecting the data to be isolated on the first computer system;
- forwarding the data to a second computer system via processor to isolate the data from the first computer system;
- analyzing the data on the second computer system via processor; and
- transforming the data into a document file.
2. The method of claim 1, further comprising writing the selected data to a data file via a processor on the first computer system.
3. The method of claim 2, further comprising reading the data from the data file on the second computer system via processor prior to the analyzing step.
4. The method of claim 1, wherein the data is selected on the first computer system in accordance with a plurality of predefined rules.
5. The method of claim 2, wherein the data file includes no executable code
6. The method of claim 2, wherein the data file is a text file.
7. The method of claim 6, wherein the text file includes ASCII characters.
8. The method of claim 2, wherein writing the data to the data file includes sending the data to a printer port.
9. The method of claim 2, wherein the data file is a print file.
10. The method of claim 9, wherein the print file is a PCL file.
11. The method of claim 8, wherein the print file is a post script file.
12. The method of claim 1, wherein the data to be transferred is patient data.
13. The method of claim 1, wherein the data to be transferred is selected from the group consisting of financial data, message data, personal data, form data and image data.
14. The method of claim 2, wherein the analyzing step include analyzing characters in the data file for patient information.
15. The method of claim 1, wherein transforming the data into the document file includes encrypting the data in the document file.
16. The method of claim 15, wherein the data file includes a database file.
17. The method of claim 1, further comprising delivering the document file to a third computer system.
18. The method of claim 1, wherein analyzing the data includes determining at least one location for delivering the document file based on at least one user-defined rule.
19. The method of claim 17, wherein the document file is delivered to the at least one location automatically.
20. The method of claim 18, wherein said at least one location includes a plurality of disparate locations.
Type: Application
Filed: Feb 7, 2020
Publication Date: Sep 3, 2020
Inventors: Arthur Young (Natick, MA), Brian Main (Natick, MA)
Application Number: 16/785,180