Methods, systems, computer networks

Abstract

This invention provides a computer implementation method, system, and computer network for processing healthcare data. [Solution] A computer implementation method for processing healthcare data includes the steps of: receiving a healthcare data stream containing technical data (S102); screening the received data stream using a pre-trained machine learning model to identify potential inclusion of personal data within the received data stream (S104); and, once the potential inclusion of personal data within the received data stream has been identified, performing mitigation actions with respect to the potential personal data identified in the received data stream (S106). The pre-trained machine learning model is trained only on technical data to identify technical data in the data stream and to identify potential personal data as anomalous data in the received data stream.

Description

Technical Field

[0001] The present invention relates to a method, a system, and a computer network.

Background Art

[0002] In diagnostic healthcare, extensive processing of technical data and personal data used to enhance diagnosis often leads to inadvertent privacy violations due to including personal information in datasets intended only for technical use. Distinguishing between personal data and technical data is important but difficult. This becomes complex in a rapid development environment focused on innovation and minimal viable product deployment, where control mechanisms may be avoided.

[0003] The present invention has been made in view of the above considerations.

Summary of the Invention

[0004] Thus, in a first aspect, an embodiment of the present invention provides a computer-implemented method for processing healthcare data, comprising receiving a healthcare data stream, wherein the data stream includes technical data, screening the received data using a pre-trained deep learning model to identify potential inclusion of personal data within the received data stream, and upon identifying potential inclusion of personal data within the received data stream, performing a mitigation operation with respect to the potential personal data identified in the received data stream, wherein the pre-trained machine learning model is fine-tuned only with respect to technical data to identify potential personal data as abnormal data within the received data stream.

[0005] Such a method can advantageously improve the quality of the technical data provided by identifying and mitigating the inclusion of personal data, which also improves privacy compliance.

[0006] A healthcare data stream is data collected from one or more healthcare data sources, such as laboratory information systems, hospital management systems, in vitro diagnostic equipment, point-of-care devices, or laboratory middleware. It includes technical data, including technical value related to the data source (e.g., reagent levels within the equipment). It may also include personal data such as name, date of birth, and location. This personal data may have been removed by the source or the healthcare data system connected to the source, but may remain in some cases (e.g., because it cannot be identified). A healthcare data stream may be received from a healthcare data system that may be outside the entity performing the screening.

[0007] A data stream refers to a continuously received stream of data containing individual data elements. Data elements may be contained within messages sent from a healthcare data source, and therefore, a data stream may be a series of received messages. Thus, screening of a data stream can be performed element by element (or message by message), in which case a pre-trained machine learning model can examine each data element individually. In other examples, messages may be grouped, or each message may contain multiple data elements, such as data records. A data record may include a group of data elements, such as clinical entries regarding the results of a panel of blood tests, or parameterized radiographic images.

[0008] A pre-trained machine learning model may have architecture size parameters below a predetermined threshold, which is determined based on the amount of available computing resources. The pre-trained model may undergo a portability process after training but before deployment to reduce its size (e.g., to reduce the number of parameters, neural network depth, number of nodes, cache size, etc.). A pre-trained model may have up to 210 million parameters, up to 100 million parameters, up to 90 million parameters, up to 80 million parameters, up to 70 million parameters, or up to 66 million parameters. The amount of computing resources may be memory, such as RAM, and may be 16GB or less, 32GB or less, or 64GB or less. The pre-trained model should be configured to utilize approximately 5% or less of the available RAM (e.g., approximately 800MB).

[0009] A pre-trained machine learning model may be trained on a dataset of at least 300,000 and / or no more than 700,000 tagged data points. The training data is technical data that contains only technical value about the data source, as described above. For example, device IDs, message timestamp values, etc. An example of dataset entries is shown in Appendix A.

[0010] The step of screening the received data can be performed on an edge device. For example, it can be performed on an in vitro diagnostic analyzer, point-of-care device, laboratory middleware, laboratory information management system, or desktop computer.

[0011] The method may be performed by a data monitoring component. The data monitoring component may be located on an edge device, in a cloud computing environment, or on a computer connected to the edge device via a local area network.

[0012] The method may further include the step of storing the processed data stream in a database (e.g., classified, screened, or tagged data) if the potential inclusion of personal data has not been identified. The database may be outside the source of the healthcare data stream (e.g., the healthcare data system). That is, the database may be within a different control area (e.g., on a different computer network and / or isolated from the entity, with the data screened by a firewall and / or controlled by a different entity). Successful screening of the data stream may be communicated to the data source.

[0013] The method can utilize protocols for managing data streams, processed data, and training datasets, ensure data diversity to reduce false positives, and outline measures to prevent the accidental generation and / or transmission of personal data.

[0014] The method may utilize access control methods and authentication (e.g., multi-factor authentication), and / or data classification methods to further protect the data. For example, 1. Data classification and ownership 1.1 Establish clear data ownership by assigning data controllers to different datasets in order to oversee data handling, use, and security policies. 1.2 Data classification is performed by classifying datasets based on confidentiality and privacy requirements in order to apply appropriate handling protocols to ensure that only technical data is included. 2. Access control and authentication 2.1 Enforce strict access control policies to ensure that only authorized personnel can access technical datasets based on their role and needs. 2.2 Add an additional layer of security by using multi-factor authentication (MFA) to access technical datasets. 3. Data encryption and masking 3.1 Encrypt data at rest and in transit using strong encryption standards to protect data from unauthorized access at rest and in transit. 4. Minimizing and diversifying data 4.1 To reduce the risk of inclusion of personal data, we will implement data minimization and collect and store only the data necessary for specific legitimate purposes. 4.2 Ensure data diversity and enhance model reliability by incorporating diverse datasets into the anomaly detection model to minimize bias and false positives. 5. Incident Response and Data Violation Protocols 5.1 Develop an incident response plan and establish a comprehensive incident response plan that details the response to a data breach, including reporting procedures. 5.2 Conduct regular security audits and perform regular security assessments and audits to identify vulnerabilities and ensure compliance with data protection policies.

[0015] Mitigation actions may include one or more of the following: removing and / or anonymizing identified personal data, sending alerts to data management components, and generating synthetic technical data or personal data based on at least the received technical data. The synthesis of technical data or personal data may be performed using a machine learning model, which may be the same machine learning model used to screen the received data stream that has the ability to generate (e.g., LLM). Synthesis may be performed using only technical data. Alternatively, the synthesis of technical data may be performed by a separate machine learning model trained to synthesize technical data or personal data from input technical data or personal data. The generation of synthetic technical data or personal data may include adding noise to the data or query results to prevent the identification of any individual's data. Mitigation actions may be triggered when the received data stream identifies a potential inclusion of non-technical material (e.g., personal data).

[0016] The method may include a step of performing secondary validation to identify personal data, which is performed before mitigation but after determination of potential personal data. Secondary validation may include regular expression checking of personal data, detection of anomalies, and / or verification of data integrity. Secondary validation may be performed by a secondary validation module separate from the entity performing the screening, or it may be performed by the same entity performing the screening.

[0017] The data stream may be supplied via an API exposure layer that interfaces with a machine learning model that has been pre-trained for screening.

[0018] The method may include an initial validation step performed before screening the received data, which checks the format and / or integrity of the data stream.

[0019] The method may further include the steps of obtaining feedback on identifying potential inclusion of personal data, and adjusting a pre-trained machine learning model based on the feedback obtained. For example, reinforcement learning techniques can be applied to the pre-trained machine learning model.

[0020] A pre-trained machine learning model may be a large-scale language model. In other examples, a pre-trained machine learning model may be a supervised learning model trained on a labeled dataset of technical data, or an unsupervised model designed to detect outliers from the technical data on which it was trained. A pre-trained machine learning model may be a transformer-based encoder-only model. This may be a pre-trained model that has undergone a fine-tuning process later. For example, the model may be a GPT-2, DistilBERT, or RoBERTa-based model. The model can be trained to identify anomalous data from distribution patterns (i.e., for the model to distinguish patterns that have not been trained). The model can use Gram matrices to characterize activity patterns. Gram matrices used for anomaly detection can be effectively incorporated during the fine-tuning process of the LLM.

[0021] LLM can adapt to a wide variety of data formats and contexts due to extensive training on diverse datasets. This adaptability allows it to recognize and flag potential privacy concerns in data that may not follow predictable patterns, going beyond rule-based systems. Furthermore, unlike rule-based systems that operate on explicit patterns, LLM can understand the context surrounding the data, enabling a better distinction between personal and technical information. This context-aware processing reduces the possibility of personal data slipping through due to subtle wording or unusual data presentations.

[0022] Furthermore, by using only technical data for training and leveraging the capabilities of the LLM to identify anomalies, the methods and systems disclosed herein can minimize or reduce false positives (where benign data is incorrectly flagged as containing personal data) and false negatives (where personal data is not detected). The LLM can also process large amounts of data quickly and efficiently, making it suitable for environments where large-scale data processing is required. This is particularly useful in the context of healthcare data, where the volume is continuously increasing.

[0023] The data stream may be an encrypted data stream that is decrypted during the screening process and re-encrypted before storage or subsequent resending. In a second aspect, embodiments of the present invention provide a data monitoring component including one or more processors and a memory, the memory including machine-executable instructions that, when executed on the processor, cause the processor to, receive a healthcare data stream, the data stream including technical data, screen the received data stream to identify potential inclusion of personal data within the received data stream using a pre-trained machine learning model, upon identifying potential inclusion of personal data within the received data stream, cause a mitigation action to be performed with respect to the potential personal data identified in the received data stream, the pre-trained machine learning model being trained only on the technical data to identify the technical data of the data stream and identify potential personal data as anomalous data within the received data stream.

[0024] The machine-executable instructions can cause the processor to perform the method of the first aspect, including any one of the optional features described with reference thereto, or any combination as long as they are compatible. In a third aspect, an embodiment of the invention is a computer network comprising the data monitoring component of the second aspect, a healthcare data source connected to the data monitoring component and supplying a healthcare data stream to the data monitoring component, and a database, wherein the data monitoring component is configured to send the data stream to the database when potential inclusion of personal data is not identified, providing a computer network.

[0025] The computer network may further comprise a synthetic data generator configured to receive at least a part of the data stream from the data monitoring component and generate synthetic technology data based on at least the received part of the data stream.

[0026] The computer network may further comprise a secondary verification module connected to the data monitoring component and configured to perform secondary verification to identify personal data.

[0027] The invention includes the described aspects and combinations of preferred features, except where such combinations are clearly unacceptable or explicitly avoided.

[0028] A further aspect of the invention provides a computer program comprising code which, when executed on a computer, causes the computer to execute the method of the first aspect, a non - transient computer - readable medium storing a computer program comprising code which, when executed on a computer, causes the computer to execute the method of the first aspect, and a computer system programmed to execute the method of the first aspect. BRIEF DESCRIPTION OF THE DRAWINGS

[0029] [Figure 1A] shows a method. [Figure 1B]This shows the architecture of a pre-trained machine learning model. [Figure 2] This shows the system. [Figure 3] The diagram shows the swimlane for continuous anomaly detection processing. [Figure 4] This diagram shows the swimlane for real-time integration with the external verification algorithm process. [Figure 5] This diagram shows the swimlanes of the entire system's processes. [Modes for carrying out the invention]

[0030] Hereinafter, aspects and embodiments of the present invention will be described with reference to the attached figures. Further aspects and embodiments will be apparent to those skilled in the art.

[0031] Figure 1A illustrates the method. In the first step S102 of the method, a healthcare data stream is received, and the data stream contains technical data. Next, in step S104, the healthcare data stream is screened for potential inclusion of personal data using a pre-trained deep learning model. If personal data is identified and the answer is "yes", the method proceeds to step S106, where mitigation actions are performed with respect to the potential personal data identified in the received data stream. If no personal data is identified, the method proceeds to step S108, where the processed data stream is stored in a database.

[0032] As mentioned above, a data stream can take the form of a stream of messages, each containing one or more data elements. Screening is performed on the data elements individually, in groups, or (if the messages contain data records) on each data record. After each element or group of elements has been screened, the method returns to step S104 when the next data element is screened.

[0033] In this example, the pre-trained machine learning model is a large-scale language model of the type described above. In this example, it was an implementation of the DistilBERT transformer model. This model is a lightweight and efficient version of BERT (Bidirectional Encoder Representations from Transformers), retaining 97% of BERT's performance while being 60% faster and 40% smaller. It has 66 million parameters and was fine-tuned using only technical data (and also requires less data than the original pre-training). Fine-tuning typically requires only smaller datasets representing a particular domain. The training data was of high quality and well-tagged. The supplied training data had between 100,000 and 2,000,000 tagged data points, preferably between 300,000 and 700,000 tagged data points. An example of the training data is presented in Annex A.

[0034] Screening is achieved by feeding specific data elements into a model and identifying whether the elements are out of distribution (i.e., represent patterns or elements that the model has not trained on). We used Gram matrix anomaly detection techniques because they can be added to standard architectures. This involved fine-tuning the model to recognize normal patterns and flagging deviations from these as potentially out-of-distribution instances. If technical data is incorrectly flagged as out-of-distribution (i.e., false positives), the model can be fine-tuned again and the Gram matrix can be quickly updated.

[0035] The model is trained to perform classifications similar to sentiment analysis and is therefore typically only suitable for scaling to specific, readily available cognitive tasks. For this reason, the model was a transformer-based "encoder-only" model with an architecture like that shown in Figure 1B, which includes multiple transformer layers. The use of Gram matrices here allows us to capture the model's internal activity patterns, which facilitates out-of-distribution detection in the samples.

[0036] Mitigation actions in S106 can take several forms. In some examples, data identified as abnormal is simply discarded / deleted and therefore not stored. In other examples, it may be anonymized. In such examples, the method may include replacing personal data with synthetic non-identifiable personal data (e.g., a synthetic name is generated to replace names in the data stream). Mitigation actions may also include, or only, sending a warning to a data management component (which may be the source of the data) and stopping the data stream. A warning may also be sent (as a note to the data source) when data has simply been discarded. Furthermore, mitigation actions may include composing replacement (technical or personal) data so that the data stream is continuous and ongoing.

[0037] Other examples of the method include an initial verification step, performed before step S104 but after step S102, to check the format of the data stream and / or integrity stream. For example, this may be done by comparing elements of the data stream with the data specification or by calculating checksums of the data stream or its elements to check integrity. Some examples of the method also include, after step S106 or S108, obtaining feedback on identifying potential inclusion of personal data and adjusting or fine-tuning the LLM based on the feedback obtained. In some examples, since the data stream is received in encrypted form, there may be a step after S102 to decrypt the data stream or its elements, and after S104 but before S108, to re-encrypt the data stream or elements before sending them for storage.

[0038] An example of a received message is shown below. { "device_id": "DX10023", "timestamp": "2024-09-23T12:00:00Z", "heart_rate": 75, "patient_name": "John Doe", "patient_age": 45, "patient_id": "P12345", "test_result": "Negative" }

[0039] As you can see, the received message contains two entries that are technical data (device_id and timestamp). The following entries, heart_rate, patient_name, patient_age, patient_id, and test_result, are not considered technical data and are therefore screened. The mitigation action in this case is to replace the values ​​of the personal data entries with the deleted flag. { "device_id": "DX10023", "timestamp": "2024-09-23T12:00:00Z", "heart_rate": [REDACTED], "patient_name": [REDACTED], "patient_age": [REDACTED], "patient_id": [REDACTED], "test_result": [REDACTED] }

[0040] Figure 2 shows the system. The system includes one or more data sources 202a-202n, e.g., in vitro diagnostic equipment, point-of-care devices, and hospital / laboratory information systems. These supply a stream of data to a data monitoring component 204 configured to perform the method shown in Figure 1. When the data monitoring component clears the data, i.e., when step S108 is reached, it transmits the data to a data store 212 via a wide-area network 210. The network also includes a data management component 206 and a data synthesizer 208 to which the data monitoring component is connected.

[0041] The data monitoring component 204 does so by sending a message to the data management component 206 when it issues a warning that potentially personal data has been identified. In some examples, the data management components may be given data sources 202a-202n. In fact, in some examples, the data monitoring component 204 may be located in or installed in a given data source (e.g., in an IVD device or point-of-care device). In these examples, as described above, it is possible to ensure that data can be effectively screened before being sent from the device for sharing using a pre-trained machine learning model with reduced complexity and / or reduced resource requirements.

[0042] The data monitoring component 208 is also connected to the data synthesizer 208, which can generate data using a generative model and replace data that has been flagged as potentially containing personal data. This generated data can take two forms: (i) replacement technical data that conforms to the surrounding technical data (so that the data stream continues in a continuous manner), or (ii) replacement personal data in which replacement personal data is generated to satisfy the data requirements without disclosing any personally identifiable information (e.g., name replacement by generated name replacement).

[0043] The network also includes a secondary verification module 209 connected to a data monitoring component 204, which receives either a processed data stream or flagged potential personal data from the data monitoring component. The secondary verification module then performs secondary checks on the elements of the received data (either the stream or specifically the flagged potential personal data). For example, the secondary verification module may apply regular expression checks to screen for dates of birth, postal addresses, and / or email addresses.

[0044] The system architecture can be implemented at a container level that can be visualized using the C4 framework. The components shown in Figures 3-5 are briefly discussed.

[0045] It can be implemented as a Web API / GUI-external system, providing a graphical user interface for healthcare providers to interact with the LLM engine, particularly for submitting datasets and retrieving processing results, including those related to reinforcement from human feedback (RLHF).

[0046] The API exposure layer acts as a gateway to the LLM engine, handling requests from Web APIs / GUIs and other external systems. It is responsible for exposing the LLM engine's capabilities, including data analysis and integration with other components.

[0047] The LLM engine is the core component that performs anomaly detection, synthetic data generation / refinement, and RLHF. It is directly integrated with the API exposure layer to process data and interact with external databases for data storage needs.

[0048] Databases are classified as external systems and store logs, configurations, and temporary data used in the operation of the LLM engine. The external status of the database emphasizes its role as a shared or third-party service accessible by the LLM engine. This can be an SQL or NoSQL database.

[0049] Synthetic data generation and validation algorithms - external systems that interact with the API exposure layer for synthetic data generation and additional data validation, respectively.

[0050] Figure 3 is a diagram of the swimlanes for the continuous anomaly detection process. As shown in the diagram, the healthcare system streams data to a web API / GUI, which forwards this stream to the API publishing layer. The API publishing layer can perform the initial validation of the type described above before starting screening using the LLM engine. The LLM engine continuously analyzes the data for anomalies and, if it detects one (box alt[Anomaly Detected]), logs the detected anomaly. In this example, the anomaly is logged to an external database, but could instead be logged to the healthcare system. Once the logging of the anomaly is certified, the LLM engine reports the anomaly detection to the API publishing layer, which then sequentially notifies the healthcare system. If the LLM does not detect any anomalies ([No Anomalies Detected]), the LLM engine instead verifies the integrity of the data to the API publishing layer and then notifies the healthcare system.

[0051] Figure 4 shows a swimlane diagram of the real-time integration with the external validation algorithm process. This diagram begins after the LLM receives and screens the data stream, and once the data stream is cleared, it is sent to the validation algorithm container for secondary validation (or, if potential anomalies are identified, they are forwarded to the container for secondary checks before being reported). If the secondary validation is performed and successful ([Validation Success]), this is returned to the LLM engine, which then logs the validation result (in this case to the external database). If the secondary validation fails ([Validation Failed]), the validation algorithm container sends a validation failure message to the LLM engine, which notifies the API publishing layer of this. This is then reported to the healthcare system. In either case, the external database confirms the logging of the result to the API publishing layer, which notifies the healthcare system of the validation result.

[0052] Figure 5 shows a swimlane diagram of the entire system process. As discussed previously, this begins with the healthcare system streaming data to a web API / GUI, which then forwards that streamed data to the API exposure layer. Here, initial validation of the streaming data can be performed of the types described above. These steps can be collectively called data ingestion. Next, the anomaly detection section begins, which starts with the API exposure layer forwarding the data stream to the LLM engine to begin anomaly detection. The LLM engine then analyzes the data for anomalies in the continuous anomaly detection process.

[0053] This process includes a synthetic data integration section, where the LLM integrates synthetically generated data for the improvement of the data stream and / or the LLM itself. Next, the process enters a secondary validation section, where the LLM sends the screened data stream, or any specifically flagged data elements considered anomalous, to a validation algorithm container that performs secondary validation as described above. Once the data stream is cleared, the results of the analysis are then stored in an external database, which sends notifications to the healthcare system via an API exposure layer. This is done in the results compilation and notification section.

[0054] This process also includes a false positive / negative feedback loop section, where the healthcare system (e.g., its operator) provides feedback to a web API / GUI, which then forwards it to the API exposure layer. The API exposure layer, in the continuous learning and model tuning section, tunes the model within the LLM engine based on the feedback, resulting in model retraining and optimization. The reporting and analysis section can generate detailed reports on generated anomalies, system performance, and feedback analysis results. An analysis dashboard can also be provided for the healthcare system to review system findings, provide feedback, and monitor ongoing improvements.

[0055] Finally, the process includes a data storage, management, and retrieval section where the LLM engine stores and manages the screened data on an external database. This data can be retrieved on demand via an API exposure layer (e.g., in response to requests from healthcare systems), enabling continuous system monitoring and maintenance for operational efficiency.

[0056] The systems and methods of the above embodiments may be implemented in a computer system (particularly computer hardware or computer software), in addition to the structural components and user interactions described.

[0057] The term "computer system" includes hardware, software, and data storage devices for the embodiment of the system or the execution of the method according to the embodiments described above. For example, a computer system may comprise a central processing unit (CPU), input means, output means, and data storage devices. A computer system may have a monitor that provides a visual output display. Data storage devices may comprise RAM, disk drives, or other computer-readable media. A computer system may comprise a plurality of computing devices connected by a network and capable of communicating with each other through that network.

[0058] The method of the above embodiment may be provided as a computer program, or as a computer program product or computer-readable medium carrying a computer program configured to perform the above method when executed on a computer.

[0059] The term “computer-readable media” includes, but is not limited to, any non-temporary media that can be directly read and accessed by a computer or computer system. Examples of such media include, but are not limited to, magnetic storage media such as floppy disks, hard disks, and magnetic tapes; optical storage media such as optical disks or CD-ROMs; electrical storage media such as RAM, ROM, and flash memory; and hybrids and combinations of the above, such as magnetic / optical storage media.

[0060] While this disclosure has been described in relation to the exemplary embodiments described above, many equivalent modifications and variations will be apparent to those skilled in the art in light of this disclosure. Therefore, the exemplary embodiments of this disclosure described above are illustrative and not limiting. Various modifications to the embodiments described may be made without departing from the spirit and scope of this disclosure.

[0061] In particular, although the methods of the embodiments described above are described as being implemented on the systems of the embodiments described, the methods and systems of this disclosure do not need to be implemented in relation to each other, and may be implemented on alternative systems or using alternative methods.

[0062] Features disclosed in this Specified

[0063] While this disclosure has been described in relation to the exemplary embodiments described above, many equivalent modifications and variations will be apparent to those skilled in the art in light of this disclosure. Therefore, the exemplary embodiments of this disclosure described above are illustrative and not limiting. Various modifications to the embodiments described may be made without departing from the spirit and scope of this disclosure.

[0064] To avoid any misunderstanding, any theoretical explanations provided herein are provided solely for the purpose of improving the reader's understanding. The inventors do not wish to be bound by any of these theoretical explanations.

[0065] Any headings used herein are for organizational purposes only and should not be construed as limiting the subjects described.

[0066] Throughout this Spec., including the following claims, unless the context requires otherwise, the words “equip” and “include,” as well as variations such as “equip,” “equip,” and “include,” will be understood to mean the inclusion of the described integer or step or group of integers or steps, but not the exclusion of any other integer or step or group of integers or steps.

[0067] It should be noted that the singular forms “a,” “an,” and “the” as used herein and in the appended claims include multiple referents unless the context clearly indicates otherwise. Ranges may be expressed herein as “about” one particular value to and / or “about” another particular value. When such ranges are expressed, another embodiment includes one particular value to and / or other particular values. Similarly, the use of the antecedent “about” will be understood to mean that a particular value forms another embodiment when the value is expressed as an approximation. The term “about” with respect to numbers is arbitrary and means, for example, + / - 10%.

[0068] Appendix A { "specversion": "1.0", "type": "com.healthcare.device.event", "source": " / devices / {deviceId}", "id": "{uniqueEventId}", "time": "{eventTimestamp}", "subject": "device.{deviceType}", "datacontenttype": "application / json", "data": { "deviceId": "{deviceId}", "deviceType": "{deviceType}", "manufacturer": "{manufacturerName}", "modelNumber": "{modelNumber}", "serialNumber": "{serialNumber}", "firmwareVersion": "{version}", "softwareVersion": "{version}", "hardwareRevision": "{revision}", "eventCode": "{eventCode}", "eventDescription": "{eventDescription}", "eventSeverity": "{severityLevel}", / / e.g., "info", "warning", "critical" "operationalStatus": "{operationalStatus}", / / e.g., "operational", "maintenance", "offline" "measurements": { "temperature": "{value}", "pressure": "{value}", "flowRate": "{value}", "signalQuality": "{value}", "batteryLevel": "{percentage}", "powerConsumption": "{watts}" / / Additional measurements relevant to diagnostic devices }, "calibration": { "lastCalibrationDate": "{timestamp}", "nextCalibrationDue": "{timestamp}", "calibrationStatus": "{status}", "calibratedBy": "{technicianId}" }, "maintenance": { "lastMaintenanceDate": "{timestamp}", "nextMaintenanceDue": "{timestamp}", "maintenanceStatus": "{status}", "maintenancePerformedBy": "{technicianId}", "maintenanceLogs": [ { "maintenanceId": "{maintenanceId}", "description": "{description}", "actionsTaken": "{actions}", "partsReplaced": [ { "partId": "{partId}", "partName": "{partName}", "serialNumber": "{serialNumber}" } / / Additional parts ] } / / Additional maintenance entries ] }, "alerts": [ { "alertId": "{alertId}", "alertCode": "{alertCode}", "alertType": "{alertType}", "alertMessage": "{alertMessage}", "timestamp": "{timestamp}", "resolved": "{boolean}", "resolution": { "resolvedBy": "{technicianId}", "resolutionTime": "{timestamp}", "resolutionDescription": "{description}" } } / / Additional alert entries ], "usageStatistics": { "totalOperatingHours": "{hours}", "usageCount": "{numberOfUses}", "averageUsageDuration": "{duration}", "lastUsed": "{timestamp}" / / Additional usage statistics }, "connectivity": { "networkStatus": "{status}", "ipAddress": "{ipAddress}", "macAddress": "{macAddress}", "signalStrength": "{value}", "connectionType": "{type}", / / e.g., "WiFi", "Ethernet", "Cellular" "latency": "{milliseconds}" }, "location": { "facility": "{facilityName}", "department": "{departmentName}", "room": "{roomNumber}", "coordinates": { "latitude": "{latitude}", "longitude": "{longitude}" } }, "environmentalConditions": { "ambientTemperature": "{value}", "humidity": "{percentage}", "vibration": "{value}", "noiseLevel": "{decibels}" }, "softwareModules": [ { "moduleId": "{moduleId}", "moduleName": "{moduleName}", "version": "{version}", "status": "{status}", "lastUpdate": "{timestamp}" } / / Additional software modules ], "timestamps": { "eventGenerated": "{timestamp}", "eventReceived": "{timestamp}", "lastUpdated": "{timestamp}" / / Additional relevant timestamps }, "compliance": { "regulatoryStandards": [ "ISO 13485", "FDA 21 CFR Part 820" / / Additional standards ], "complianceStatus": "{status}", / / e.g., "compliant", "non-compliant" "lastAudit": "{timestamp}", "auditFindings": [ { "findingId": "{findingId}", "description": "{description}", "status": "{status}", / / e.g., "open", "closed" "correctiveActions": "{actions}" } / / Additional findings ] }, "metadata": { "tags": [ "{tag1}", "{tag2}" / / Additional tags ], "notes": "{additionalNotes}", "documentationLinks": [ "{url1}", "{url2}" / / Additional links ] } } }

Claims

1. A computer implementation method for processing healthcare data, A step of receiving a healthcare data stream, wherein the data stream includes technical data, The steps include: using a pre-trained machine learning model to screen the received data stream to identify the potential inclusion of personal data within the received data stream; and The steps include: identifying the potential inclusion of the personal data in the received data stream, and performing a mitigation action with respect to the potential personal data identified in the received data stream; A computer implementation method wherein the pre-trained machine learning model is trained only on technical data to identify technical data in a data stream and identify potential personal data as anomalous data in the received data stream.

2. The computer implementation method according to claim 1, wherein the pre-trained machine learning model has architecture size parameters below a predetermined threshold, and the predetermined threshold is determined based on the amount of available computing resources.

3. The computer implementation method according to claim 1 or 2, further comprising the step of storing the stream of processed data in a database when no potential inclusion of personal data has been identified.

4. The aforementioned mitigation action is, Removing and / or anonymizing any identified personal data, Sending alerts to data management components, and A computer implementation method according to any one of claims 1 to 3, comprising at least one or more of the following: generating synthesized technical data based on the received technical data.

5. The computer implementation method according to any one of claims 1 to 4, further comprising the step of performing a secondary verification for identifying personal data, which is performed before the mitigation operation.

6. The computer implementation method according to claim 5, wherein the secondary verification includes regular expression checking of personal data, detection of anomalies, and / or verification of data integrity.

7. The computer implementation method according to any one of claims 1 to 6, wherein the data stream is supplied via an API exposure layer that interfaces with the pre-trained machine learning model for screening.

8. A computer implementation method according to any one of claims 1 to 7, comprising an initial verification step performed before screening the received data, wherein the initial verification step checks the format of the data stream and / or the integrity of the data stream.

9. Steps to obtain feedback regarding the identification of the potential inclusion of personal data, and A computer implementation method according to any one of claims 1 to 8, further comprising the step of adjusting the pre-trained machine learning model based on the feedback obtained.

10. The computer implementation method according to any one of claims 1 to 9, wherein the pre-trained machine learning model is a large-scale language model.

11. The computer implementation method according to any one of claims 1 to 10, wherein the data stream is an encrypted data stream which is decrypted during the screening process and re-encrypted before storage or subsequent retransmission.

12. A data monitoring component comprising one or more processors and memory, wherein the memory includes machine-executable instructions, and when the machine-executable instructions are executed on the processor, the processor... A healthcare data stream is received, and the data stream includes technical data. Using a pre-trained machine learning model, the received data stream is screened to identify the potential inclusion of personal data within the received data stream. When the potential inclusion of the personal data is identified in the received data stream, a mitigation action is performed with respect to the potential personal data identified in the received data stream. A data monitoring component, wherein the pre-trained machine learning model is trained only on technical data to identify technical data in a data stream and identify potential personal data as anomalous data in the received data stream.

13. It is a computer network, The data monitoring component according to claim 12, A healthcare data source connected to the data monitoring component and supplying the healthcare data stream to the data monitoring component, and Includes database, The data monitoring component is configured to send a stream of data to the database when no potential inclusion of personal data has been identified.

14. The computer network according to claim 13, further comprising: a synthetic data generator configured to receive at least a portion of the data stream from the data monitoring component and to generate synthetic technical data based on the received at least portion of the data stream.

15. The computer network according to claim 13 or 14, further comprising a secondary verification module connected to the data monitoring component and configured to perform secondary verification to identify personal data.

Images