Managed Health Information Exchange

Abstract

To facilitate collaborative approaches to management of information, particularly, management of information related to medication preparation information received in relation to provision of medical care.SOLUTION: A management method of medical information includes collecting medical information from a data source, editing at least a portion of medical records, and / or formatting the medical information according to access by users. Accordingly, exchange of medical information can be facilitated, for example, can facilitate data analysis by internal users and / or one or more external business operators. Before the medical information is stored in a shareable data part to which users can access, patient identifying information and / or protected health information (PHI) can be deleted from the medical information. Further, the medical information in the shareable data part can be formatted according to identity of a user accessing the data, environment in which the data is to be used, and / or a requested format of the data. Thus, the exchange of medical information can facilitate data analysis that can contribute to a variety of beneficial purposes.SELECTED DRAWING: Figure 1

Description

[Technical Field]

[0001] [CROSS REFERENCE TO RELATED APPLICATIONS] This application claims priority to U.S. Provisional Patent Application No. 62 / 019,227, "MANAGED MEDICAL INFORMATION EXCHANGE," filed June 30, 2014, the entire contents of which are incorporated herein by reference. [Background technology]

[0002] Many healthcare facilities utilize pharmacies / pharmacy resources to prepare medications to be administered to patients. These pharmacies may be located within the healthcare facility or may be remote from the healthcare facility. In either case, medications can be dispensed in the pharmacy in response to a medical dose order. Often, these dose orders are patient-specific, such as those issued by a healthcare professional, which corresponds to a request to prepare a medication to be administered to a patient. In other applications, the dose order may be a stock order or may be non-patient specific.

[0003] In many healthcare facilities, records are created for dispensing orders prepared by the dispensing lab. These records include information received with the dispensing order and / or information that may be added to the record by the dispensing lab, including details about the products and / or formulations used to prepare the doses for the dispensing order. These records may be stored locally in the dispensing lab and / or used for a variety of purposes, including, for example, regulatory compliance, patient safety, inventory management, personnel decisions, or other purposes related to dispensing lab and / or pharmaceutical management.

[0004] Furthermore, the ever-increasing development of communication technologies and collaboration tools facilitates the sharing and access of data in networked environments, such as through software services, data-sharing platforms, or other network connections, sometimes collectively referred to as "cloud services." However, access and / or transfer of medical information (including, for example, pharmacy order records) may be restricted. For example, access to such data may be restricted to appropriate personnel within a healthcare facility or pharmacy. Furthermore, the Health Insurance Portability and Accountability Act (HIPAA) in the United States regulates the handling, distribution, and other privacy-related activities of medical records that may contain protected health information (PHI). Therefore, the use, distribution, and / or access of pharmacy order records, and particularly patient-specific pharmacy order records that may contain PHI, may be restricted due to regulatory compliance and / or other privacy concerns. Thus, while it can be beneficial for cloud service applications to collaborate and share data, there are limitations on the use of this valuable data and access restrictions may be placed on it.

[0005] Furthermore, the systems used to maintain and / or create medical information may be proprietary and use specific data formats, which may impose limitations on data exchange. For example, data created or stored in a proprietary format specific to one provider may not be readable by another provider. Summary of the Invention

[0006] The present disclosure relates to systems and methods that facilitate a collaborative approach to information management, particularly information related to pharmaceutical information received in connection with the delivery of healthcare. The disclosure also relates to a managed exchange of medical information. Improvements to the exchange of medical information can be achieved through the use of selective redaction and / or formatting of medical information. For example, certain data within the medical information can be redacted to facilitate the exchange of medical information that may contain patient-identifying information or PHI. Furthermore, cryptographic hash functions can be applied to reliably convert portions of the information (e.g., information related to patient identifiers) into non-identifying values. Furthermore, records can be associated with a patient even if the patient's PHI and / or patient-identifying information is deleted.

[0007] Furthermore, given the breadth of data analysis possibilities applicable to the health information exchange described herein, data can be formatted prior to access by users of the data exchange platform to facilitate specific data analysis. This formatting can be standardized for all users of the system and / or specific to a particular user, specific data usage, and / or specific data type. In either case, the exchange platform described herein can improve data accessibility, thereby enabling more scalable, robust, and efficient data analysis in a variety of environments. In particular, data exchange between parties can be improved through data formatting rules associated with the collaboration system described herein. This ability to provide data from multiple sources in a format allows for enhanced data analysis. For example, data analysis associated with multiple interparty data sources can be facilitated in accordance with the present disclosure, which can improve patient safety (e.g., by recognizing data collection trends that may be potentially harmful), provide business intelligence (BI), help reduce healthcare costs, or provide other meaningful benefits.

[0008] Thus, a first aspect includes a system for exchanging information related to patient-specific product formulations. The system includes a data storage device operable to communicate with one or more healthcare facilities. The data storage device receives, from the one or more healthcare facilities, information related to patient-specific product formulations prepared at corresponding ones of the one or more healthcare facilities. In some embodiments, the medical information may include non-patient-specific data received from one or more additional data sources. The data storage device includes a sharable data portion, which stores redacted data records from which patient-identifying information (e.g., PHI) has been removed. The redacted data records correspond to the information related to the product received from the one or more healthcare facilities. The system also includes a collaboration module operable to communicate with the data storage device. The collaboration module functions to access and extract data from the sharable data portion, transform the extracted data into a data format based on predetermined usage requirements, and load the reformatted data into a remotely accessible data repository, such as a data storage location that is remotely accessible from the data storage device. The predetermined usage requirements may be based on the analysis of the identified data to be performed, the identity of the party accessing the data, the format requested by the party accessing the data, or other specific purposes for the data.

[0009] Numerous refinements and additional features may be made to this first aspect, either individually or in combination, such that each of the features discussed below may, but need not, be used in conjunction with any other feature or combination of features of the first aspect.

[0010] For example, PHI may include a patient identifier. Furthermore, the system of the first aspect facilitates the removal of patient-identifying information while still allowing the data record to remain linked to a given patient. Accordingly, one or more of the updated data records stored in the shareable data portion may include a unique identifier that is linked to one or more pieces of information about a given patient's drug product without providing any identifying information about that patient. The unique identifier may include a hash value obtained by applying a hash function to the patient identifier.

[0011] A hash function may be executed by a processor at the data storage device to create a revised data record that is stored in the shareable data portion. Alternatively, the hash function may be executed locally at one or more healthcare facilities to remove patient identifying information before placing the data in the data storage device. Thus, the system may receive revised medical information at the data source. A hash function may then be executed by a processor at one or more healthcare facilities to create a revised data record that is received by the central storage server and stored in the shareable data portion. In some embodiments, the hash value may comprise a deterministic, irreversible value based on the patient identifier. This means that for each unique identifier for a given patient used to generate the hash value, a corresponding unique hash value is generated. Furthermore, the plaintext patient identifier may be unrecognizable to a user using only the hash function.

[0012] In some embodiments, the data storage device may also include a backup data portion containing a full data record (i.e., potentially including PHI) corresponding to at least a portion of the drug product-related information received from one or more healthcare facilities. The backup data portion and the sharable data portion may be separately accessible on the data storage device, i.e., a user who has access to the sharable data portion may not also have access to the backup data portion. The collaboration module may provide multiple users with selective and secure access to the sharable data portion based on multiple layers of security applied to access to the sharable data portion.

[0013] In some embodiments, the data format in which the collaboration module provides the revised data may include a standardized data format that is accessible to multiple users, and may include multiple separate data formats, such that each of the multiple separate data formats is accessible to a corresponding one of the multiple users.

[0014] In some embodiments, the data storage device may include a data storage server located remotely from one or more healthcare facilities. More specifically, the data storage device may include multiple mirrored data servers at different geographic locations, thereby providing redundancy and reducing the risk of data loss on any one of the distributed data servers.

[0015] In some embodiments, the system of the first aspect may be used in connection with ordering, preparing, and / or dispensing to a patient, where the product-related information may include a dispensing order record generated in response to a received dispensing order for a product to be administered to a patient.

[0016] The system of the first aspect may also include an analysis module operable to communicate with the data repository to obtain the formatted data. In this case, the analysis module may be operable to perform one or more analyses on the drug product-related information for a patient without specifically requiring the identity of the patient. Thus, the analyses performed by the data analysis module may include at least an analysis on the patient's unique identifier. For example, an analysis may be performed on the dose administered to a given patient.

[0017] An unlimited number of other analyses can be facilitated or performed. An example of such an analysis would be error tracking for one or more given dispensing order data fields. That is, the tracked errors can be examined to determine whether common data parameters exist that can aid in root cause investigation. For example, a high error rate found in dispensing of a given drug or medical product could help identify hidden causes for that drug or medical product (e.g., misleading labeling).

[0018] Additionally, data analysis can be facilitated or performed to help parameterize and evaluate the supply chain for manufacturing, ordering, preparing, distributing, and / or administering doses. That is, providing the system with data about a given dose (including information about the medical products used to prepare that dose) can enable inventory tracking and supply chain evaluation at one or more points in the supply chain (e.g., from the medical product manufacturer to the administration of the dose). Such analysis can be based, at least in part, on one or more pharmacy order data fields contained in the medical information received by the system.

[0019] In some embodiments, the product-related information may be received in a data storage device in accordance with local data policies of each of one or more healthcare facilities. As described above, this allows for patient-identifying information to be removed from the medical information prior to receipt by the system of the first aspect. Such removal of patient identifiers may be based, at least in part, on the local data policies of each healthcare facility. Each healthcare facility may establish its own local data policies.

[0020] A second aspect includes a method for creating shareable information regarding patient-specific product formulations. The method includes receiving, from one or more healthcare facilities, information related to patient-specific product formulations prepared for administration to patients at corresponding ones of the one or more healthcare facilities. The method also includes storing the information as a shareable data portion on a data storage device in the form of an updated data record, where the updated data record corresponds to the patient-specific product-related information received from the one or more healthcare facilities and has removed patient-identifying information (e.g., PHI). The method also includes formatting the updated data record to a format compliant with predetermined usage requirements and loading the formatted data into a remotely accessible storage location for access by users located away from the remote storage location.

[0021] Numerous refinements and additional features may be incorporated into this second aspect. These refinements and additional features may be incorporated individually or in combination. That is, each of the features discussed below may, but need not, be used with any other feature or combination of features of the second aspect. Furthermore, any one or more of the refinements and additional features discussed above with respect to the first aspect may, but need not, be used in the second aspect.

[0022] For example, in some embodiments, the PHI may include at least a patient identifier. The method may also include associating a unique identifier with one or more of the updated data records corresponding to a given patient, without providing the ability to identify characteristics related to the patient. In this case, the storing step may further include applying a hash function to the patient identifier and generating a unique identifier therefrom. Such a unique identifier may include a hash value resulting from the application of the hash function.

[0023] In some embodiments, the method may further include providing selective and secure access to the revised data record to multiple users, for example by requiring a user to go through multiple layers of security, which may require the user to provide authentication information, in order to access the revised data record.

[0024] In some embodiments, the formatting step may include formatting the revised data record into a standardized format accessible to a plurality of users, or additionally or alternatively, the formatting step may include formatting the revised data record into a plurality of different data formats, each of which may be accessible by a corresponding one of the plurality of users.

[0025] In some embodiments, the method may further include generating formulation-related information including a dispensing order record in response to receiving a dispensing order for a formulation to be administered to a patient. The method may also include accessing a data repository to obtain the formatted data and analyzing the formulation-related information for a particular patient without disclosing the identity of the particular patient. The method may also include performing any one or more of the analysis techniques described above for the first aspect.

[0026] Additionally, in the method, receiving the product-related information may be based at least in part on a local data policy of each of the one or more healthcare facilities, thereby enabling compliance with the local data policy at the healthcare facility, as described above.

[0027] While the above description relates to receiving medical information from a healthcare facility, aspects of the systems and methods described above can also be utilized to receive medical information from one or more of a plurality of data sources. Such data sources may include pharmaceutical manufacturers that manufacture pharmaceutical or medical products (e.g., those usable in preparing doses). Data sources may also include hospital information systems. Hospital information systems may provide data related to inventory tracking of medical products received and / or distributed through a healthcare facility. Hospital information systems may also provide medical information, including treatment records. Additional data sources may include, for example, information from medical device operations databases (e.g., including administration devices such as infusion pumps) and / or information from dispensers. Furthermore, any one or more of these data sources may, but are not required to, access data for purposes such as data analysis. This facilitates data analysis of data received and aggregated from multiple data sources. That is, data from multiple data sources related to the manufacturing, ordering, preparation, and / or administration of doses may be aggregated to provide extensive analytical freedom for the data. Increasing access to this aggregated, revised, and formatted data promises to improve numerous environments, including patient safety, pharmacy efficiency, business development, and inventory management. [Brief explanation of the drawings]

[0028] [Figure 1] FIG. 1 is a schematic diagram illustrating an embodiment of a system for exchanging information about pharmaceutical products. [Figure 2] FIG. 1 is a schematic diagram illustrating an embodiment of a system for exchanging information about pharmaceutical products. [Figure 3] FIG. 1 is a schematic diagram illustrating an embodiment of a collaborative platform involving collaborative data analysis of shared information about pharmaceutical products. [Figure 4] 1 is a flow chart illustrating an embodiment of a method for exchanging information about pharmaceutical products. [Figure 5] FIG. 1 is a schematic diagram illustrating an embodiment of an example implementation of a collaborative platform for the exchange of medical information in a specific environment involving dispensing and administration. DETAILED DESCRIPTION OF THE INVENTION

[0029] The following description is not intended to limit the invention to the disclosed form. Indeed, variations and modifications commensurate with the teachings, techniques, and knowledge of the relevant art are within the scope of the present invention. The embodiments described in this disclosure are also intended to illustrate known modes of practicing the invention and to enable others skilled in the art to utilize the invention in such a manner, or to utilize other embodiments and various modifications as required for a particular application or use of the invention.

[0030] The present disclosure relates generally to the exchange of medical information, and more particularly to managing the exchange of medical information, which may include pharmacy order records for pharmaceutical products prepared for administration to patients, for the purpose of providing data analytics related to the medical information. Such exchange of medical information may facilitate a data collaboration platform that enables various parties to perform data analytics on medical information that may originate from multiple sources for various purposes, including, for example, improving patient safety, tracking medical trends, deriving business intelligence, or other purposes related to the medical information.

[0031] Each party may have an incentive or expertise to provide different types of analytics. Thus, the present disclosure facilitates a collaboration platform that enables broad data sharing among multiple parties that can provide data analytics to each other. By providing a data collaboration platform that allows multiple parties, not necessarily related to each other, to provide collected and / or aggregated data in an appropriate format, improved data analysis can be facilitated based on the various sources that can access and / or analyze the formatted data provided by the platform.

[0032] The platform can be facilitated by a collaboration system having one or more data storage devices (including a backup data portion and a sharable data portion). Such a collaboration system may further include a collaboration module. The collaboration system can receive medical information from multiple data sources. Furthermore, the collaboration system can provide access to multiple users who access the collaboration system to receive data (e.g., for data analysis purposes). Parties including data sources may also include parties accessing the collaboration system to access data for data analysis purposes. This means that a party providing data to the collaboration system (e.g., an individual user, corporate user, government user, etc.) may retrieve data from the collaboration system, which includes aggregated data provided by that party and / or data from other parties.

[0033] A particular concern with the exchange of medical information is maintaining patient privacy as it relates to the exchange of medical information. For example, medical information may include patient-identifying information (potentially including PHI). In such cases, distribution of the medical information may be restricted by regulatory issues (e.g., U.S. HIPAA laws prohibiting the distribution of medical information that includes PHI) or other privacy concerns. Accordingly, embodiments described in this disclosure may function to redact medical information to remove patient-identifying information (e.g., PHI) from the data.

[0034] Compliance with regulations such as HIPAA and other privacy considerations requires that PHI and other patient-identifying information be removed before disseminating medical information. However, linking relevant medical records to a given patient can be useful even if it does not reveal the patient's identity. For example, consider a number of medical records associated with a patient named "Hanako." This disclosure uses unique identifiers to facilitate redaction of these records. For example, Hanako's medical records can be linked to "Patient X," whose identity cannot be traced back to Hanako's. Some data analyses may benefit from this non-identifying association between medical records and a given patient (e.g., analyzing trends related to a given patient or analyzing correlations with specific patients). For purposes of such analyses, simply identifying relevant medical records for a given patient may be useful, even if they do not reveal the patient's identity. Thus, embodiments of the present disclosure can provide a unique identifier that can be linked to medical information about a given patient, without providing any patient-identifying information. For example, the patient identifier can be used as input to a one-way cryptographic hash function. Such a hash function generates a hash value that may include the unique identifier. In this way, each unique identifier has a corresponding unique hash value. Inputting this unique hash value into the hash function cannot be traced back to the patient's identity. Thus, a unique identifier (e.g., a hash value) can be used to link medical information to a given patient, but not to identify the patient.

[0035] Thus, collaboration platforms facilitated by embodiments of the present disclosure can create and / or store revised medical information. Collaboration platforms can also provide access to formatted data created from the revised data records to facilitate data analysis. The formats provided may be standardized formats familiar to a wide range of users, or may include specialized or specific formats (e.g., proprietary formats) based on user, application, or other criteria. In any case, platforms of the present disclosure, including the systems and methods described below, can facilitate improved data sharing, making medical information more accessible to cloud services and other data analysis for a variety of purposes.

[0036] FIG. 1 illustrates an embodiment of a system 100 that facilitates the exchange of medical information. In some applications, the medical information may include pharmaceutical product-related information in response to a dispensing order. For example, a healthcare facility 110 may utilize a local or remote dispensing lab capable of dispensing pharmaceutical products (also referred to herein as doses) for administration to patients. Multiple healthcare facilities 110a, 110b, and 110c may be operable to communicate with a data storage device 120. While FIG. 1 illustrates three healthcare facilities 110a-110c, fewer or more healthcare facilities 110 may be operable to communicate with the data storage device 120 without limitation.

[0037] The healthcare facilities 110a-110c shown in FIG. 1 may represent any suitable healthcare facility that creates, stores, provides, or accesses medical information. Such healthcare facilities 110 may include, but are not limited to, hospitals, pharmacies, ambulatory care providers, and home health care providers. In any case, the information provided to the data storage device 120 may include any medical information. In some embodiments, the medical information may relate to a pharmaceutical product, such as a dosage to be prepared and administered to a patient in accordance with a dispensing order. In certain embodiments, the medical information may include a patient-specific record corresponding to a pharmaceutical product (dose) that the healthcare facility 110 has prepared or requests to prepare for administration to a patient. Thus, the healthcare facility 110 may have access to and utilize a dispensing room to prepare medications for administration to a patient. It should be noted that access to a dispensing lab may include use of a pharmacy local to the healthcare facility or may include use of a remote pharmacy that can provide medical information (e.g., dispensing order records) and pharmaceutical products to the healthcare facility 110. For example, at least a portion of the healthcare facility 110 may include a healthcare facility that may include a local dispensing lab that, in response to receiving a dispensing order, generates a dispensing order record for the requested pharmaceutical product.

[0038] In such cases, the healthcare facility 110 may use a pharmacy workflow manager to create and / or provide the medical information to be provided to the data storage device 120. Such a pharmacy workflow manager may include any or all of the details of U.S. Patent Application No. 14 / 022,415, which is incorporated herein by reference in its entirety. An example of such a pharmacy workflow manager may include the DoseEdge™ pharmacy workflow manager (available from Baxter Healthcare Corporation, Deerfield, Illinois). The healthcare facility 110 may then employ tools capable of capturing pharmacy order information to create and / or provide a pharmacy order record corresponding to the dose to be prepared for administration to the patient. Such techniques may include capturing pharmacy order data received from an order-taking system and / or providing a pharmacy order record with pharmacy order metadata related to the dose to be prepared and / or the preparation of the dose. As described in more detail below, the pharmacy order record may include medical information that can be provided to the data storage device 120.

[0039] The data storage device 120 may then be operable to store pharmaceutical product-related information, such as a dispensing order record received from the healthcare facility 110. In this case, the healthcare facility 110 may provide a dispensing order record corresponding to a dispensing order received from a healthcare provider. One example may be a dispensing order record created in response to a provider creating a dispensing order received by a pharmacy for a pharmaceutical product dose to be administered to a patient. Upon receiving the dispensing order, the healthcare facility 110 may create a dispensing order record corresponding to the dispensing order.

[0040] A pharmacy order record may include one or more pharmacy order record data fields. Such pharmacy order record data fields may capture pharmacy order metadata related to the pharmacy order. Such pharmacy order metadata may be obtained from a received pharmacy order (e.g., by a pharmacy order accepting system) or may be associated with the pharmacy order after it is received (e.g., by a pharmacy workflow management system during administration, preparation, and / or distribution of the dose corresponding to the pharmacy order). The pharmacy order record data fields may include one or more fields providing patient identification information. For example, pharmacy order record data fields may include data related to patient name, geographic data, relevant dates (e.g., date of birth, date of admission, date of administration), telephone number, fax number, email address, Social Security number, medical record number, health insurance beneficiary number, account number, certificate / license number, vehicle identifier and serial number (including license plate number), device identifier and serial number, Uniform Resource Locator (URL), Internet Protocol address, biometric identifier (retinal scan or fingerprint), identifying image, or any unique identifying number, characteristic, or code, where patient identifier may include PHI linked to the pharmacy order record.

[0041] Other dispensing order record data fields may also be provided relating to the manufacture, preparation, distribution, and / or administration of the dose. For example, these dispensing order record data fields may include: scheduled drug administration date and time, actual drug administration date and time, scheduled distribution date and time, actual distribution date and time, expiration date of the formulation, dilution value, count of medical products in the dose, date and time the dispensing order was received, volume measurement of the dose, date and time of the first dose in a series, an indication of whether the dose is the first dose in a series, an indication of whether the dose contains a hazardous substance, an indication of whether the dose is a high-risk dose, a dose identifier, an indication of whether the dose is a test dose, the label format of the label corresponding to the dose, the unit of care corresponding to the dose, an order order, whether the dispensing order is pending, date and time the dispensing order was pending, an overdose of the dose, the patient's basal energy metabolism value, the patient's body surface area value, the patient's height, the patient's weight, the duration of the dose, date and time the dose was prepared, whether the dispensing order is printed on the label, when the dose was prepared, The fields may include whether a dispensing order label was printed, the name of the printer that printed the dispensing order label, the dose administration rate, an indication of whether the dose was ever rejected by a pharmacist during preparation, the date and time the dose was rejected, the identity of the pharmacist who rejected the dose, the route of administration of the dose, any scan history for the dose, the date and time the dose was scanned, the date and time the dose was classified, an indication of the status of the dose, an indication of whether the dose was an inventory dose, whether the dose was for total parenteral nutrition (TPN), an indication of the type of TPN associated with the dose, the date and time the dose was verified by a pharmacist, the identity of who verified the dose, an indication of who performed certain steps associated with the dose, dispensing documentation (including, for example, an image of the drug product and / or product preparation for the ingredients in the dispensing order), an error log for the dose, or other suitable information associated with the dose. In some embodiments, a dispensing order record containing any one or more of the above fields may be provided in the data storage device 120.

[0042] The data storage device 120 may be located remotely from, but in communication with, each healthcare facility 110. In some embodiments, the information received by the data storage device 120 may be a complete data record obtained from the healthcare facility 110. A complete data record is a data record in which the data storage device 120 receives the same information that was included in the data record held by the healthcare facility 110. In other words, a complete data record can be thought of as one in which no data has been deleted. The information received by the data storage device 120 may be a pharmacy order record containing information associated with one or more of the pharmacy order record fields described above. In other words, the data storage device 120 may store backup copies of records provided by each healthcare facility 110. In other words, a complete copy of a pharmacy order record from the healthcare facility 110 may be provided and stored in the data storage device 120. The data storage device 120 may then include a backup data portion 130 that stores the complete data records (e.g., medication order records) received from each of the healthcare facilities 110. As will be appreciated, the data provided by the healthcare facilities 110 may be in a proprietary data format that may not be readable by third parties except using proprietary compatible software executed by the healthcare facility 110.

[0043] In some embodiments, the backup data unit 130 may function to provide backup versions of data to one or more of the healthcare facilities 110. For example, if a data loss occurs at one or more of the healthcare facilities 110a-110c, the backup data unit 130 may provide a backup copy of the database to the healthcare facility 110 for database recovery purposes. That is, data provided by any one of the healthcare facilities 110 may be returned to that healthcare facility 110 as a data backup. In this manner, the healthcare facility 110 may benefit from the provision of medical information by the healthcare facility 110 in the form of a data backup. Medical information relating to the health of patients may then be efficiently backed up by the backup data unit 130 and available for data recovery at the healthcare facility 110 in the event of a data loss at the healthcare facility 110.

[0044] The data storage device 120 may also include a shareable data portion 150. The shareable data portion 150 may store data records resulting from redacting at least a portion of the medical information. For example, in some embodiments, PHI may be removed from records in the shareable data portion 150. In this case, a data screening module 140 may be included. The data screening module 140 may have access to the full data records stored in the backup data portion 130. The data screening module 140 may remove one or more types of data (e.g., PHI or other patient-identifying information) from the full data records. The redacted data records may then be stored in the shareable data portion 150.

[0045] Additionally, the backup data portion 130 and the sharable data portion 150 may be separated, with access to each portion controlled. While each portion may reside on the same device (e.g., a common drive or server), the isolation of each portion may ensure that access to one portion does not necessarily imply permission to access another portion. In some embodiments, each portion of data may be stored on multiple, different, corresponding devices.

[0046] Linking data records for a given patient can be useful even if the patient's identity cannot be traced (i.e., the data record has been redacted). Therefore, the system 100 can function to link redacted data records to the patient to determine which medications were associated with the patient without revealing the patient's actual identity. Because patient identifying information may contain PHI, the patient's identifying information can be redacted from the data record while still maintaining the link between all records for that patient. This means that the data filtering module 140 can generate a unique identifier for a given patient, but cannot trace the patient's identity back to it. In this way, all data records associated with the patient can be assigned the unique identifier for that patient. Thus, all data records for that patient can be identified, but the patient's identity itself can be made anonymous.

[0047] An example of a unique identifier may be a hash value that may be generated by applying a cryptographic hash function to one or more portions of the full data record prior to storing the revised data record in the shareable data portion 150. Thus, the revised data record (which may include the unique identifier) ​​may be stored with the generated hash value. In some embodiments, the full pharmacy record may include one or more patient identifiers. For example, the pharmacy record may include a field containing the patient's name and / or other identifying information about the patient. Such other identifying information may include, for example, an institution identifier for the patient, a date of birth, a Social Security number, or other patient identifying information as described above. Thus, the patient identifier may include PHI. One or more patient identifiers in the full pharmacy record may then comprise inputs to a hash function. The resulting output hash value provides the unique identifier. Such unique identifiers may be stored in the corresponding revised data record stored in the shareable data portion 150.

[0048] The data filtering module 140 can apply a hash function to one or more patient identifier fields in the full pharmacy order record. For example, one or more cryptographic hash functions can be applied, such as SHA-1, SHA-2, SHA-3, MD5, RIPEMD-128 / 256, RIPEMD-320, RTR0, or other suitable hash functions currently in existence or to be developed. Preferably, the applied hash function is deterministic; that is, for each unique input, the hash function produces a corresponding unique output without data collisions. Furthermore, the hash function is preferably irreversible; for example, the input from which the hash value was derived should not be retrievable. Thus, the hash function preferably enables the irreversible transformation of the patient identifier into an anonymous, unique value that is unique for each of multiple patients. In this way, each application of the hash function will produce the same unique value for a given patient. Therefore, two or more different pharmacy order records for a given patient can be assigned the same unique identifier by applying the hash function to the data records. Then, upon review of the revised pharmacy order records that include the unique identifier instead of the patient identifier, the pharmacy order record corresponding to a given patient can be identified based on the common unique value (e.g., a hash value), and such hash value may be further encoded, for example, using Base64 encoding on the resulting hash value.

[0049] System 100 may also include a collaboration module 160 that has access to the shareable data portion 150 containing the revised data records. The collaboration module 160 can then retrieve the revised data records for conversion into a format usable by one or more remote users 170 and / or local users 165 of system 100. The format to which collaboration module 160 converts the revised data records may be based, at least in part, on the predetermined usage requirements of the local users 165 and / or remote users 170 requesting data from collaboration module 160.

[0050] The collaboration module 160 can also facilitate selective and secure access for local users 165 and / or remote users 170 who desire access to the formatted data extracted by the collaboration module 160 from the shareable data portion 150. In this case, multiple access layers can be configured so that users must traverse them before accessing the formatted data from the shareable data portion 150. For example, a remote user 170 can be configured to require access to a first layer such as a virtual private network (VPN). To access the VPN, the remote user 170 can be required to present appropriate credentials. Such credentials can include a valid username and password combination, an encryption key, a one-time password, or a biometric value. Alternatively, a local user 165 can be configured to require an access terminal on a common network (e.g., a LAN) that includes the collaboration module 160. A user may provide additional credentials (such as a valid username and password, an encryption key, a one-time password, or a biometric value) to access collaboration module 160. After a user provides the credentials required to access collaboration module 160 by entering a VPN or accessing collaboration module 160 on a common network, collaboration module 160 provides the user with access to formatted data based on the revised data records in shareable data portion 150. This multiple layer of access helps prevent unauthorized access to shareable data portion 150.

[0051] The collaboration module 160 can access the revised data records in the shareable data portion 150 and extract data from them. The collaboration module 160 then converts the data into a given format and loads it (e.g., into storage on the collaboration module 160 and / or into the shareable data portion 150) for access by the users 165 / 170. The data format may include a standardized format that is accessible to anyone with access to the collaboration module 160. Standardized formats include Extensible Markup Language (XML) formats. Additionally or alternatively, the standardized format may be provided as a delineated text file, a pivot table, or any other standardized format or data representation. In this way, data that may be provided in a proprietary format (such as those described above) can be formatted for access and / or viewing by other parties / users who would not otherwise be able to view it. This allows the data to be widely distributed and subjected to further related data analysis.

[0052] In some embodiments, collaboration module 160 may format the revised data records obtained from shareable data portion 150 based, at least in part, on the identity of the user accessing the data, the intended use of the data, the format requested by the user, and / or other suitable criteria. For example, different remote users 170 may have access to the collaboration module. As described above, access to collaboration module 160 by a remote user 170 may include one or more access protocol layers that require authentication (e.g., including providing a username and password). In this manner, access to collaboration module 160 may at least partially identify the identity of the remote user 170 accessing collaboration module 160. Thus, the format of data accessed by remote user 170 may depend at least on the identity of user 170. For example, a first remote user 170 associated with a first party may receive formatted data in a first format associated with the first party (e.g., a proprietary data format associated with the first party). A second remote user associated with a second party may receive formatted data in a second format associated with the second party (e.g., a proprietary data format associated with the second party). The first and second formats may be different and may be unique to the particular user accessing the collaboration module 160. As discussed in more detail below, different remote users 170 provided with formatted data by the collaboration module 160 may have different usage requirements, as the collaboration module 160 relates to the data stored in the shareable data portion 150. That is, the format of the data provided to the user 165 / 170 can be based on how the user 165 / 170 will use the data and / or the format requested by the user 165 / 170.

[0053] As can be seen in FIG. 1 , data storage module 120 and collaboration module 160 may collectively comprise collaboration system 305. Healthcare facilities 110a-110c may include data sources that provide data to collaboration system 305. The data provided by data sources 110a-110c may then be accessible by users 170 and / or users 165 using collaboration system 305. Thus, the embodiment depicted in FIG. 1 provides an exemplary embodiment of collaboration system 305. However, other embodiments of collaboration system 305 are contemplated, as discussed below in conjunction with FIG. 2.

[0054] Additionally, the various components depicted in FIG. 1 may be operable to communicate with one or more networks. That is, the various depicted modules and devices may be operable to communicate with one another over a network. Network communication may utilize a wide area network, such as the Internet. Additionally or alternatively, communication may occur via one or more local area networks, intranets, dedicated networks, etc. Furthermore, these modules and devices may comprise an integrated system or may be distributed. For example, in one embodiment, data storage device 120 may have distributed hardware for backup data portion 130 and sharable data portion 150. For example, each data portion may reside on separate hardware (e.g., separate hard drives or separate servers). Alternatively, each data portion may have an isolated data space on a common device (e.g., a common hard drive or a common server). Similarly, data selection module 140 and / or collaboration module 160 may be standalone modules executing on distributed hardware devices, or each module may execute on a common hardware device. Such common hardware device may or may not include a backup data portion 130 and / or a shareable data portion 150 .

[0055] FIG. 2 illustrates another embodiment of a system 200 for information exchange. The variations and details described above with respect to FIG. 1 are applicable to the system 200 of FIG. 2, unless otherwise noted. The system 200 generally includes a healthcare facility 210a and a healthcare facility 210b, which are operable to communicate with a primary data storage device 222. The primary storage device 222 is operable to communicate with a secondary / backup data storage device 224. A data mart module 260 is also operable to communicate with the backup data storage device 224. A remote user 270 has access to the data mart module 260. Medical information received from the healthcare facilities 210a and 210b can be selectively provided to the remote user 270 for useful data analysis.

[0056] As shown in FIG. 2 , each healthcare facility 210 may include a backup service module 212. The backup service module 212 may be operable to communicate with one or more local databases maintained by the healthcare facility. For example, the backup service module 212 at healthcare facility 210 a may be operable to communicate with local database 214 and local database 216. Local database 214 and local database 216 may store information at healthcare facility 210 a. The backup service module 212 at healthcare facility 210 b may be operable to communicate with local database 218 at healthcare facility 210 b. In some embodiments, as described above, the information may include a dispensing order record in response to a dispensing order for a pharmaceutical product to be administered to a patient.

[0057] In either case, the backup service module 212 can access the local databases of the healthcare provider 210 and provide the information to the primary data store 222. The backup service module 212 can periodically pool one or more databases with which it is in communication and provide new or modified data records to the primary data store 222. Alternatively, the backup service module 212 can continuously monitor one or more databases and provide the data records to the primary data store 222 in real time or near real time.

[0058] The backup service module 212 may also apply local backup policies established by each healthcare facility 210. For example, the healthcare facility 210 may not want information containing certain data fields (e.g., data fields corresponding to patient identifiers and / or PHI) provided to the primary data store 222. In this case, the backup service module 212 may facilitate redacting one or more portions of the data prior to providing it to the primary data store 222. In some embodiments, the backup service module 212 may operate to generate a unique identifier corresponding to a given patient (as described above with respect to the data filtering module 140). That is, the backup service module 212 locally generates a unique value that uniquely links a given patient to one or more data records, but does not reveal the patient's identity. In this manner, the backup service module 212 may operate to redact the patient identifier by applying a hash function to the data records. Additionally, the information provided by the backup service module 212 to the primary data storage device 222 may include a unique identifier instead of patient identification information.

[0059] The primary data storage device 222 may include a backup data portion 232 within the primary data storage device 222. The primary data storage device 222 may also be operable to communicate with the backup data storage device 224. The backup data storage device 224 may have a backup data portion 234. The backup data portion 232 of the primary data storage device 222 may be replicated and stored in the backup data portion 234 of the backup data storage device 224. The primary data storage device 222 and the backup data storage device 224 may be located at separate locations. For example, the primary data storage device 222 may be located at a first location on the east coast of the United States, and the backup data storage device 224 may be located at a second location on the west coast of the United States. The primary data storage device 222 may periodically communicate data from the backup data portion 232 to the backup data portion 234 of the backup data storage device 224. In this way, backups of the backup data unit 234 can be stored at each location. Therefore, using geographically distributed storage locations reduces the risk of data loss occurring at multiple facilities at the same time. In this way, not only does the primary data storage device 222 facilitate data backup services for the healthcare facility 210, but it also creates the possibility of further backups using the backup data storage device 224. In this way, in the event of data loss at the healthcare facility 210 and / or the primary data storage device 222, backup copies of the data from the backup data storage device 224 can be provided to the healthcare facility 210 and / or the primary data storage device 222, facilitating data recovery.

[0060] The backup data storage device 224 may include a data filtering module 240. The data filtering module 240 may be located in the primary data storage device 222, either coexisting with or replacing the backup data storage device 224. In either case, the operation of the data filtering module 240 remains unchanged. As described with reference to FIG. 1, the data filtering module 240 may generate a unique identifier associated with a patient identifier for the purpose of redacting a portion of a data record (e.g., containing a patient identifier and / or PHI) that will be stored in the shareable data portion 250 of the backup data storage device 224. In the embodiment depicted in FIG. 2, the backup service module 212 at the healthcare facility may provide the data record in a revised form. In this case, the data filtering module 240 may further revise the data record or pass the already-revised data record to the shareable data portion 250. In any event, the information stored in the shareable data portion 250 can be revised (eg, patient identifiers and / or PHI can be removed from the data).

[0061] The shareable data portion 250 may be operable to communicate with a collaboration module 262, which may be located within a data mart module 260. The data mart module may be configured to allow the collaboration module 262 to extract, transform (e.g., format), and load the formatted data into a data mart storage 264 for access by a remote user 270. As noted above, the formatted data may be provided in a standardized format or in a specific format accessible by the remote user 270.

[0062] 2 illustrates another embodiment of collaboration system 305, which includes the previously described primary data storage device 222, backup data storage device 224, and data mart module 260. Collaboration system 305 may also include geographically separated backup data storage devices to further enhance data redundancy. Healthcare facility 210a and healthcare facility 210b may also include data sources that provide medical information to collaboration system 305, which may then provide updated and formatted medical information to remote users 270.

[0063] FIG. 3 is a schematic diagram illustrating an embodiment of a collaboration platform 300. The collaboration platform 300 can be used to provide users with medical information from one or more sources to facilitate data analysis of the medical information. The collaboration platform 300 can include a collaboration system 305. The collaboration system 305 can be a system such as the collaboration system 305 described above with respect to system 100 of FIG. 1 or the collaboration system 305 of FIG. 2. In either case, the collaboration system 305 can receive information from a healthcare facility 310. The information can be provided in a shareable data portion of the collaboration system 305 for user access, thereby transforming the information received from the healthcare facility 310 prior to access by one or more third parties. For example, such transformations may include redacting patient identifiers and / or PHI from the data and / or converting the data into a format more accessible to users of the collaborative system 305.

[0064] However, the collaboration system 305 may be operable to communicate with one or more other data sources in addition to or instead of the healthcare facility 310. For example, the collaboration system 305 may be operable to communicate with a medical device operations database (e.g., a dosage administration device database or other suitable medical device information source), a hospital information system 314, an external pharmacy 316, and / or other suitable medical information source. If the medical information received from such a data source (e.g., the healthcare facility 310, the medical device operations database, the hospital information system 314, the external pharmacy 316, and / or other suitable medical information source) contains information that needs to be redacted (e.g., a patient identifier and / or PHI), the collaboration system 305 may be operable to redact the medical information and, for example, generate a unique identifier that is associated with the patient but does not reveal the patient's identity, as described above.

[0065] The collaboration system 305 may provide access to formatted data from one or more data sources. Regardless of the data source, the data provided by the collaboration system 305 may include redacted data records in which patient identifiers and / or PHI have been removed. The data provided by the collaboration system 305 may also be formatted as described above in connection with the collaboration module embodiments. That is, the collaboration system 305 may format data from multiple data sources that originally used different formats. The collaboration system 305 may then combine and / or aggregate data from different sources and present it to a user in a standardized or specific format.

[0066] The collaboration system 305 can therefore aggregate and format large amounts of medical information from multiple data sources. Users can then access the aggregated and formatted data provided by the collaboration system 305. These users can be local users 320 (e.g., users on a common network to which the collaboration system 305 is connected, such as users on a LAN or intranet) who access the collaboration system 305 locally, facilitating internal analysis within a given organization. Furthermore, the collaboration system 305 can also be accessed by external users 330 (e.g., users who access the collaboration system 305 via a wide area network or other means). This allows internal analysis users 320 and / or external service providers 330 to access the collaboration system 305. The formats available and / or accessible to different users can depend on the user's identity, whether they are an internal or external user, and / or the purpose of the user accessing the data.

[0067] The modules of the present disclosure may be implemented in software, hardware, or both. For example, the modules of the system may include specially configured hardware, such as application-specific integrated circuits (ASICs), programmable field gate arrays, or other suitable processors. In some embodiments, the modules may include a microprocessor operable to communicate with memory. The memory may include a non-transitory computer-readable medium (which may contain machine-readable instructions). The processor may thus be specifically configured to access the memory and perform any of the functions set forth in the present disclosure in accordance with the machine-readable instructions stored therein. Additionally, the modules may be executed by a general-purpose processor operable to communicate with memory (which may provide the functionality of multiple modules). The modules may be executed using a single general-purpose processor, or separate modules may be executed using separate processors.

[0068] Turning to FIG. 4 , an embodiment of a method 400 for exchanging medical information via a collaboration platform is illustrated in flow chart form. The method may include collecting 402 information from one or more data sources. As discussed above, the data sources from which the medical information is collected may include a healthcare facility, a medical device operations database, a hospital information system, an external pharmacy, or other suitable medical information source. The method 400 may also include storing 404 the medical information in a backup data portion. As discussed above, the shareable data portion may include a portion of a data storage device.

[0069] In some embodiments, method 400 may include creating 406 backup data records. The backup data records may include copies of the full data records stored in the backup data portion. The backup data records may be stored at a remote location, separate from the backup data portion, in step 404. The backup data records may also be used to recover data that is lost or corrupted at the healthcare facility and / or other data sources.

[0070] Method 400 may also include a step 408 of accessing the complete medical information (e.g., the complete data record). As discussed above, it may be beneficial to redact a portion of the complete data record (e.g., to remove patient-identifying information). Thus, method 400 may include a step 410 of redacting one or more portions of information from the medical record accessed in step 408. As discussed above, redacting 410 may include applying a hash function to at least a portion of the data record (e.g., including patient identifiers and / or PHI) to generate a hash value. Method 400 then includes a step 412 of storing the redacted medical information in a shareable data portion. Separating this shareable data portion from the backup data portion may facilitate selective access to either portion.

[0071] In some embodiments, method 400 includes step 414 of extracting the revised data record from the shareable data portion. Method 400 may further include step 416 of formatting the revised data record into a data format that is user-friendly for users accessing the revised data record (e.g., for data analysis purposes). This format may be a standardized format presented to all users of the system, or may be a format specifically tailored to a particular user and / or data analysis environment in which the data will be used. Method 400 may further include step 418 of loading the formatted revised data record (e.g., via a collaboration module) to make it more accessible. Method 400 may also include step 420 of granting selective and secure access to the formatted revised data record by users of the platform. As described above, users may be individually granted access to the standardized format, or users may be provided with a specific data format based on their identity and stated intended use of the data. Alternatively, it is possible to provide the user with the information in the format requested by the user.

[0072] Additionally, medical information collected from various medical sources via the collecting step 402 may be transformed and made available to a user, for example, for data analysis of the medical information. Accordingly, method 400 may include a step 422 of performing data analysis on the formatted, revised data records accessed via the selectively accessing step 420. Examples of data analysis include monitoring trends related to ordered doses to improve patient safety and / or enhance business opportunities by obtaining usable business intelligence data regarding activities corresponding to the medical information obtained from one or more sources. Other data analysis may also be performed, such as those described in more detail below. This provision of data analysis as a service allows users to access and / or perform data analysis on the revised and formatted medical information stored in a cloud architecture (e.g., using network resources), thereby improving efficiency, speed, and resource utilization.

[0073] FIG. 5 illustrates an embodiment of a platform 500 using a collaboration system 305 to collect data and then provide the revised, formatted data to one or more users, who can then access the data. Here, collaboration system 305 may comprise a collaboration system according to the embodiment of collaboration system 305 shown in FIG. 1 and / or the embodiment of collaboration system 305 shown in FIG. 2. Furthermore, any other combination of modules, components, or other devices, including collaboration system 305, can be envisioned to facilitate the revision and formatting of medical information obtained from one or more sources. It should be noted that collaboration system 305 may include more or fewer modules than those described with respect to the specific embodiment shown in FIGS. 1 and 2. Thus, the embodiments shown in FIGS. 1 and 2 are illustrative and not intended to be limiting.

[0074] Figure 5 discusses collaboration system 305 in the context of patient dose preparation. The solid arrows in Figure 5 should be thought of as representing the flow of physical goods between the various parties described herein, and the dashed arrows in Figure 5 represent the flow of data between the various parties in collaboration system 305. Thus, platform 500 shown in Figure 5 illustrates one application of collaboration system 305 as it relates to the preparation and administration of patient doses and the flow of materials associated with a healthcare facility.

[0075] Platform 500 may include a pharmaceutical supplier 510. The pharmaceutical supplier 510 may manufacture medical products in dosage amounts, such as drug compounds and / or other intermediates (including diluents, etc.). That is, the pharmaceutical supplier 510 may manufacture and deliver medical products to hospitals using a hospital information system 512. In particular, an inventory management system implemented by the hospital information system 512 at the healthcare facility may enable receipt and tracking of goods from the pharmaceutical supplier 510.

[0076] The pharmaceutical manufacturer 510 may also provide data to the collaborative system 305. In this case, the pharmaceutical manufacturer 510 may include a data source that provides medical information to the collaborative system 305. Examples of suitable data that the pharmaceutical manufacturer 510 may provide to the collaborative system 305 include a medical product identifier, a lot number, an expiration date, an inventory control number, a product strength, a product size, or other information related to a medical product manufactured by the pharmaceutical manufacturer 510.

[0077] The inventory management component of the hospital information system 512 may monitor the medical products after receiving them from the pharmaceutical supplier 510, for example, by monitoring the time a request for the medical product was placed at the pharmacy and / or by tracking information associated with the medical product (e.g., lot number, expiration date, product identifier, etc.). A pharmacy workflow manager 514 may be located within the health care facility's pharmacy. The pharmacy workflow manager 514 may receive products from an inventory management system within the hospital information system 512. For example, the pharmacy workflow manager 514 may request medical products from the inventory management system 512 for use in preparing doses. Thus, the inventory management system 512 may facilitate the supply of medical products to pharmacies, facilitating tracking by the pharmacy workflow manager 514.

[0078] The inventory management portion of the hospital information system 512 may also provide data to the collaboration system 305. Examples of such data include average inventory, current inventory, inventory supply parameters (including the average length of time a medical product remains in stock before being used), and / or data regarding the movement of medical products within the hospital (including the supply of pharmaceutical products to the pharmacy workflow manager 514 for use in preparing doses).

[0079] The pharmacy workflow manager 514 facilitates the preparation of doses for administration to patients. As described above, dose preparation can be initiated in response to a dispensing order from a healthcare provider or the like. The pharmacy workflow manager 514 can then receive dispensing order information as described above. The pharmacy workflow manager 514 can further supplement such data with information related to the preparation of the dose. For example, images of the medical products used to prepare the dose can be captured. Data regarding the medical products can be aggregated and used to create a specific dispensing order record corresponding to the dispensing order. The dispensing order can be patient-specific or non-patient-specific. That is, the dispensing order record can include information regarding the lot number and expiration date of the medical products used to prepare the dose. The pharmacy workflow manager 514 can also supplement data such as the identity of the pharmacy technician who prepared the dose, the pharmacist who approved the dose, and related parameters (e.g., the date and time of the event). Additionally, the pharmacy workflow manager 514 may provide the pharmacy technician with the procedures to be used in dispensing the medication, and the specific procedures to be used may also be linked to the dispensing order record.

[0080] The pharmacy workflow manager 514 can also provide data to the collaboration system 305. In this case, the pharmacy workflow manager 514 can provide one or more portions of the above-mentioned data created and / or received. Thus, the pharmacy workflow manager 514 can provide information about dispensing and / or information about the medical product(s) used to prepare the dose. Furthermore, the data provided by the pharmacy workflow manager 514 to the collaboration system 305 can include information about the date and time of an event related to the generation of the dispensing order. The pharmacy workflow manager 514 can also detect errors that occur during the preparation of a dispensing order. For example, a pharmacy technician can detect that the wrong medical product was used for the dose to be prepared. The pharmacy workflow manager 514 can alert the pharmacy technician to the error so that it can be corrected, and can also record the error history for the dispensing order in which the error occurred.

[0081] The pharmacy workflow manager 514 may dispense doses from the pharmacy into a dose dispensing cabinet 516 after dispensing the doses. The dose dispenser 516 may be accessible by the patient, healthcare facility personnel, or another party obtaining the prepared doses. The dose dispenser 516 may then track and / or collect information about the doses. Examples of such data include the time the dose was placed in the dispenser 516 before being retrieved, the identity of the person who placed the dose in and / or retrieved the dose from the dispenser 516, the number of doses available in the dispenser 516, the number of free spaces remaining in the dispenser 516, or other relevant data. The dispenser 516 may also track errors in retrieving dispensing orders from the dispenser 516. For example, attempts at unauthorized entry into a storage area may be recorded. Furthermore, the fact that an attempt was made to use the wrong storage location or the fact that an attempt was made to use a location on the wrong floor can also be tracked. In this way, any or all of the data collected or available by the dispenser 516 can be provided to the collaboration system 305.

[0082] After obtaining a dose from the dispenser 516, the dose can be administered to a patient using an administration device 518. That is, a healthcare facility staff member (e.g., a nurse) can obtain the dose from the dispenser 516. The dose can also be connected to an administration device 518, such as an infusion pump used to deliver the dose to the patient. The administration device 518 can record information related to the administered dose, such as information about the patient who received the dose, other relevant information, such as the time of administration, administration parameters (e.g., administration rate and duration), and other information collected regarding the administration of the dose. The administration device 518 can also provide any information accessed or created by the administration device 518 to the collaboration system 305.

[0083] Once the dose is delivered to the patient, the patient record in the hospital information system 520 can be updated to record the administration of the dose to the patient. Parameters that can be recorded in the patient record in the hospital information system 520 include, for example, the hospital staff member responsible for administering the dose, the date and time of the dose, or other relevant medical records (including the healthcare provider's log). This information can also be provided to the collaboration system 305. The administration device 518 can also track errors. For example, the administration device 518 can include a mechanism to check whether the administration device 518 is properly programmed. If improper programming is detected, the administration device 518 can record the error.

[0084] Thus, collaboration system 305 can collect information from various stages of dose manufacturing, preparation, and / or administration to a patient. As discussed above, collaboration system 305 can aggregate, revise, and format such data. Collaboration system 305 also includes a collaboration module that can provide access to the aggregated, revised, and formatted data for data analysis purposes. As briefly discussed above, data sources (one or more of the parties listed in Figure 5) can benefit from not only providing data to collaboration system 305 but also retrieving data from collaboration system 305 for various reasons. As can be seen from Figure 5, the parties listed are not the only entities served by collaboration system 305, but also include users who access collaboration system 305 to access the aggregated, revised, and formatted data. That is, through the power of the collaboration system 305 for revision and formatting, any of the parties shown in FIG. 5 can gain access to the shareable data portion of the collaboration system 305 and thereby gain access to the data for use in data analysis.

[0085] This means that data available to each of these specific parties can be made available beyond their own domain. A pharmaceutical manufacturer 510 can then access collaboration system 305 to obtain data related to hospital information system 512 and / or hospital information system 520, pharmacy workflow manager 514, dose dispenser 516, or administration device 518. Without collaboration system 305, each of the parties shown in Figure 5's independent collection and use of this data would be cumbersome, requiring direct requests for information from other parties and subject to data privacy and security concerns. However, collaboration system 305 pools the shared data and centrally aggregates, revise, and format it, efficiently accessing data beyond the domains available to each individual party for the portion of the data each party provides to collaboration system 305.

[0086] Related examples of data analytics that may be performed using the platform 500 shown in FIG. 5 include analytics for improving patient safety, medical records, inventory management, business insights, security, or other useful outcomes related to data analytics. For example, as described above, errors may be tracked in one or more of the pharmacy workflow manager 514, dispenser 516, or administration device 518. To improve patient safety, the pharmaceutical manufacturer 510 may view data provided by the collaboration system 305. By aggregating the data, the collaboration system 305 can gain insight into the occurrence of errors across multiple parameters (including the specific medical product used to prepare the dose), allowing the pharmaceutical manufacturer 510 to determine whether error rates in one or more of the pharmacy workflow manager 514, dispenser 516, or administration device 518 are more prevalent for a particular medical product. Identifying such trends may allow the pharmaceutical manufacturer 510 to identify and address the root cause of the errors. For example, the pharmacy workflow manager 514 may determine that a packaging labeling mix-up is the cause of an elevated error rate for a particular medical product. The pharmaceutical manufacturer 510 can then identify the elevated error rate for that medical product and begin a root cause analysis. By identifying that the error is due to a labeling mix-up, the pharmaceutical manufacturer 510 can then improve the labeling to reduce errors associated with that medical product.

[0087] Similarly, an analysis of inventory aimed at improving supply chain performance at one or more points in the supply chain from the pharmaceutical manufacturer to the administration of a dose to a patient may be of analytical interest to one or more of the parties shown in Figure 5. For example, data provided by the collaboration system 305 may be used for analysis related to round trip times, dose usage (throughput), cycle times, etc. Furthermore, information provided by various data sources may be used for analysis related to optimal raw materials for a dose. For example, the pharmacy workflow manager 514 may analyze data from the collaboration system 305 to determine whether it is more efficient to manufacture doses in-house or to purchase pre-made doses, for example, from an external vendor. Furthermore, the party responsible for the dose dispenser 516 may use data obtained from the collaboration system 305 to determine whether product is being diverted from the dose dispenser.

[0088] By leveraging the many valuable parameters contained in the data provided by the collaboration system 305, valuable insights can be gained during data analysis. In particular, de-identifying medical information while retaining the ability to link various pieces of medical information to a given patient allows for patient-specific analysis. This configuration can be useful for gaining insight into the administration of doses to specific patients. For example, the delay between order receipt and dose administration can be examined for a specific patient. Correlations can also be made with the type of formulation, the route of administration, the nursing unit associated with the dose, or even general equipment. This means that examining metrics related to these various parameters in relation to the delay between order receipt and administration can improve the efficiency of the preparation and patient administration process. Furthermore, urgent or "STAT" doses are specific situations, such as emergency situations, where time is of the essence to ensure a patient's therapeutic benefit. With this understanding, the above configuration can be particularly useful for such urgent or "STAT" doses.

[0089] While the invention has been shown and described in detail in the drawings and foregoing specification, the drawings and specification are illustrative only and not restrictive in nature. For example, the embodiments described above may be combined with other described embodiments and / or organized in other ways (e.g., elements of the steps may be performed in a different order). It is therefore to be understood that only preferred embodiments and variations thereof have been shown, and that all variations and modifications are within the spirit and spirit of the invention desired to be protected.

Claims

1. 1. A system for exchanging information regarding dispensing, the system comprising: a data storage device operable to communicate with a plurality of healthcare facilities and configured to receive, from the plurality of healthcare facilities, information relating to a plurality of medications prepared at the plurality of healthcare facilities; a processor operable to communicate with said data storage device; Including, wherein the data storage device comprises: (i) a shareable data portion storing a revised data record for each of the plurality of dispensings in which patient-identifying information has been removed; (ii) a backup data unit that synchronously stores a data record including the patient identification information for each of the plurality of prescriptions; wherein the sharable data portion is configured to have a first access control and the backup data portion is configured to have a different second access control to prevent cross-access between the sharable data portion and the backup data portion; the processor: generating a unique hash value by encrypting the patient identification information when information regarding the plurality of prescriptions is received from the plurality of healthcare facilities; generating a revised data record that includes the unique hash value in place of the patient identifying information; storing said revised data record in said shareable data portion; configured to perform A system characterized by:

2. 2. The system of claim 1, wherein the processor performs the encryption process when information regarding the plurality of dispensings is received from the plurality of healthcare facilities.

3. moreover a collaboration module operable to communicate with said data storage device; wherein the collaboration module comprises: accessing the shareable data portion using the first access control; extracting data from the shareable data portion; converting the extracted data into a data format based at least in part on predetermined operational requirements specified by the third health facility or a third party; loading the formatted data into a remotely accessible data storage location that is remotely accessible from said data storage device; configured to perform 2. The system according to claim 1, characterized in that

4. 4. The system of claim 3, wherein the third health facility or the third party remotely accesses the formatted data from the remotely accessible data repository, thereby enabling the third health facility or the third party to use the formatted data at the third health facility.

5. The system of claim 1 , wherein the patient-identifying information includes protected health information (PHI) including at least a patient identifier.

6. the unique hash value includes a unique identifier; The unique identifier is linked to one or more pieces of information about each patient and does not provide identifying information about the patient.

6. The system according to claim 5, characterized in that

7. 7. The system of claim 6, wherein the unique identifier comprises a first unique hash value generated by applying a cryptographic process to the patient identifier.

8. 2. The system of claim 1, wherein the processor is part of the data storage device for creating the revised data record stored in the shareable data portion.

9. 2. The system of claim 1, wherein the processor is located at the plurality of healthcare facilities to generate the revised data records that are received in the data storage device and stored in the shareable data portion.

10. 10. The system of claim 1, wherein the unique hash value comprises a deterministic, irreversible value based on the patient identifier.

11. The backup data section a complete data record including the patient identifying information corresponding to at least a portion of the information regarding the plurality of dispensing procedures received from the plurality of healthcare facilities; Contains 2. The system according to claim 1, characterized in that

12. 12. The system of claim 11, wherein the backup data portion and the shareable data portion are separately accessible on the data storage device.

13. 10. The system of claim 1, further comprising a collaboration module for providing selective and secure access to the shareable data portion to multiple users based on multiple security layers applied to access to the shareable data portion.

14. 14. The system of claim 13, wherein the data format comprises a standardized data format accessible by multiple users.

15. The data format includes a plurality of distinct data formats; Each of the plurality of distinct data types is accessible by a corresponding one of a plurality of users.

14. The system according to claim 13, characterized in that

16. 10. The system of claim 1, wherein the data storage device comprises a data storage server located remotely from the plurality of healthcare facilities.

17. The system of claim 1 , wherein the data storage device comprises multiple mirrored data servers distributed across multiple separate geographic locations.

18. 10. The system of claim 1, wherein the information regarding the plurality of medications comprises a medication order record created in response to receiving medication orders for the plurality of medications to be administered to the patient.

19. moreover an analysis module operable to communicate with the remotely accessible data repository and to obtain the formatted data; Including, The analysis module is operable to perform one or more analyses on information regarding a first formulation to be administered to a first patient while not identifying the first patient.

2. The system according to claim 1, characterized in that

20. 20. The system of claim 19, wherein the one or more analyses include one or more of error analysis, inventory management, or supply chain management.

21. 10. The system of claim 1, wherein the information regarding the plurality of dispensings is received in the data storage device in accordance with local data policies of each of the plurality of healthcare facilities.

22. 1. A method for generating shareable information regarding a pharmacy, comprising: receiving, from a plurality of healthcare facilities, information regarding a plurality of prescriptions prepared at the plurality of healthcare facilities into a collaborative system; storing the information in the form of a data record for each of the plurality of dispensings, including patient identification information, on a data storage device of the collaborative system as a backup data portion by the data storage device or by a processor of the plurality of health care facilities; storing, by the processor, the information in the form of updated data records corresponding to each of the plurality of dispensings as a shareable data portion on a data storage device, wherein patient identifying information has been removed from the updated data records; configuring, by the processor, a first access control for the sharable data portion and a different second access control for the backup data portion to prevent cross-access between the sharable data portion and the backup data portion; and before storing the information as the shareable data portion, generating a unique hash value by encrypting the patient-identifying information when the information regarding the plurality of prescriptions is received from the plurality of healthcare facilities into the collaborative system; storing, by the processor, a unique hash value for each of the revised data records in place of the patient identifying information; loading, by said processor, said revised data record to a remotely accessible storage location for access by a user remote from said storage location; A method comprising:

23. 23. The method of claim 22, wherein the patient-identifying information includes protected health information (PHI) including at least a patient identifier.

24. the first unique hash value includes a unique identifier corresponding to the first patient; 24. The method of claim 23, wherein the unique identifier does not provide the ability to identify the first patient.

25. The saving step is further generating a unique identifier in response to applying the encryption process to the patient identifier; Contains 23. The method according to claim 22.

26. moreover providing selective and secure access to the revised data record to multiple users via the collaborative system.

23. The method of claim 22, comprising:

27. ​​Furthermore formatting, by said processor, said revised data record into a standardized format accessible to multiple users.

27. The method of claim 26, comprising:

28. Furthermore formatting, by the processor, the revised data record into a plurality of different formats; Including, wherein each of the plurality of different formats is accessible by a corresponding one of a plurality of users.

27. The method according to claim 26.

29. moreover generating, by the processor, information regarding the plurality of medications, including a medication order record, in response to receiving medication orders for the plurality of medications to be administered; 23. The method of claim 22, comprising:

30. moreover accessing the storage location by the collaboration system to obtain the formatted data; analyzing, by the collaborative system, information regarding a first formulation for administration to a first patient, while not analyzing the identity of the first patient; 23. The method of claim 22, comprising:

31. The analyzing step One or more of the following: error analysis, inventory management, or supply chain management 31. The method of claim 30, comprising:

32. 23. The method of claim 22, wherein receiving information regarding the plurality of dispensings is based at least in part on local data policies of each of the plurality of healthcare facilities.

33. receiving information regarding the plurality of prescriptions; receiving first information from a first healthcare facility regarding a first formulation prepared at the first healthcare facility for administration to a first patient; 23. The method of claim 22, comprising:

34. The step of receiving information regarding the plurality of prescriptions further comprises: receiving second information from a second healthcare facility regarding a second formulation prepared at the second healthcare facility for administration to a second patient; 34. The method of claim 33, comprising:

35. The method of claim 22 , wherein the remote user is associated with a third party.

36. moreover formatting, by the processor, the revised data record into a format that complies with predetermined operational requirements of a third party; 23. The method of claim 22, comprising:

Images