GRHANITE™

Introduction to GRHANITE™

GRHANITE™ is computer software that provides researchers, managers, and health professionals with the means to collect data for the purposes of audit, clinical research, and health surveillance.

GRHANITE™ is designed to work in any environment where data is being routinely collected and addresses the many complex legal, ethical, organisational, and technical barriers that prevent or hinder such vital activities in Australia.

Many data collection tools are designed for audit, not research. For audit, data is often summarised or transformed before use. Researchers normally require data to be in as close to its original state as possible, including all historic changes to the data. GRHANITE™ is designed specifically for this purpose with an ability to collect data from health and social services while enabling management of consent and privacy preserving data linkage.

GRHANITE™ prototype was created by Professor Douglas Boyle in 2007 and has been further developed and used by the University of Melbourne in the primary care arena. GRHANITE™ is currently installed in well over 1,000 general practices and other organisations throughout Australia. GRHANITE™ can extract from most data repositories, for example, in hospitals, pathology laboratories, general practices, community health centres, Council administrative systems, birth registries and other administrative sources.

GRHANITE™ Cybersecurity

As a data informatics centre, we understand the importance of ensuring that our cyber security measures are of the highest standard. With the recent surge in cyber-attacks around the world, we recognise that the security of our clients' data is paramount.

At our centre, we have implemented robust cyber security protocols to protect our clients' sensitive data. Our team of experts continuously monitor and update our systems to stay ahead of emerging threats and vulnerabilities. We use state-of-the-art encryption technology to safeguard our clients' data both in transit and at rest.

In addition, we adhere to industry best practices and regulatory requirements to ensure that our clients' data is handled in compliance with relevant privacy laws. Our staff are regularly trained in cyber security awareness and are vigilant in detecting and reporting any potential security incidents.

We take pride in the security and privacy of our clients' data and are committed to providing a safe and secure environment for their information.

GRHANITE™ Data Security

GRHANITE™ in a surgery uses outbound network connections only and as a result, a practice does not need any change in firewalls for GRHANITE™ unless the practice has out-bound rules as well as in-bound.

What this means is that any hacking of a practice will be because of limitations in the standard security provisions the practice has already put in place.

The GRHANITE™ data in the surgery is held in a database with the connection string heavily encrypted in-code. Unless the connection string is known, the data held by GRHANITE™ cannot be accessed. This is NOT true of the GP’s Electronic Medical Records (EMR). Some EMR admin connection strings are widely known across the industry and hence any compromise of patient data held in a practice is much more likely to happen from the EMR than GRHANITE. Strength of user passwords for the EMR is also a potential point of vulnerability.

GRHANITE™ uses several internationally recognised encryption mechanisms to protect data in transit, providing many layers of security.

• Each instance of GRHANITE™ has a unique password and licence, and site-specific encryption keys that are themselves encrypted.
• GRHANITE™ exhibits ‘end to end’ encryption with endpoint authentication.
• All GRHANITE™ messaging is via IP Port 443 and is always TLS encrypted.
• GRHANITE™ communications are never initiated from the Web Server – the communications always initiate from within the practice to avoid opening a practice to in-bound attacks.
• The same mechanism applies to GRHANITE™ clients and data banks where the data ultimately resides. These communicate with the Web Server but not the other way around.
• GRHANITE™ has a remote XML definition update mechanism that allows a data extract to be modified remotely should the database schema change.
• GRHANITE™ uses similar encryption protocols to the NEHTA Secure Message Delivery system (SMD). GRHANITE™ does not use SMD as SMD is designed for secure small clinical message communication for direct clinical care between care providers. As such, GRHANITE™ cannot fit within this framework as extractions can be bulk-oriented and destined for secure servers rather than health provider organisations.

We implement national and international best practice policies and procedures across our GRHANITE™ web service hosting and infrastructure, ensuring stringent compliance with national legislation pertaining to privacy and data security. Our active risk mitigation strategies undergo regular and comprehensive reviews to maintain their efficacy. Moreover, it is a legal mandate to report any notifiable data breaches to the Australian Information Commissioner without delay.

Enabling Research

The University of Melbourne supports the ethical advancement of health-related research to improve population health, by enabling controlled, ‘secondary’ use of data that has previously been collected for other purposes.

Since inception, GRHANITE™ has been used for research projects across a range of subjects, including cancer management, mental health, chronic disease management, Indigenous wellbeing and intimate partner violence. GRHANITE’s privacy-protected record linkage enables investigation of the onset and progression of disease, care pathways, and patient outcomes.

Data exported can be restricted using any data held in the source database to exactly match study inclusion criteria. E.g., Extract data for all patients who had two or more consultations in 2008 who were aged 16 - 29 at the time of consultation and who had an HBA1c test undertaken in the year prior to the first consultation.

GRHANITE™ can analyse data while it is still within the originating clinic organisation. It can aggregate data at any level, so that only essential data is exported. This includes removing aggregated data cells where the number of participants is too low to guarantee anonymity.
With data custodian permission, and subject to ethics committee approval and legal agreement,

GRHANITE™ extracts and curates the delivery of sensitive data to secure research data storage facilities. With security and privacy at its heart, data is de-identified and encrypted at source, with decryption keys held only by the authorised recipient organisation. Person identifiers are removed from the data in all but ethically approved and exceptional circumstances. GRHANITE™ also provides informed consent mechanisms allowing participants to opt-in, opt-out or withdraw.

GRHANITE™ manages consent process

Depending on the consent requirements of a project, GRHANITE™ can help document who has given consent, when and for what purpose. GRHANITE™ will only transmit data where the appropriate permissions are in-place.

Opt-in consent: If an individual needs to give their permission to be involved in a project, GRHANITE™ can read this consent information if recorded in the clinical database.

Opt-out consent: If a research project is deemed by ethics committees to be of low risk to the individual, it is commonplace for consent to be managed in an opt-out manner. GRHANITE™ provides mechanisms to implement opt-out consent.
Waiver of consent: It is sometimes not practical to obtain individual consent. If certain criteria are met, waivers of consent may be granted by ethics committees. Because of the extreme lengths taken by GRHANITE™ to protect identity, this is a common model for GRHANITE™ projects.

Non-exclusive data collection

GRHANITE™ is independent of other health related software. It is not an audit tool, and it does not interfere or impact in-house clinical software, GP audit or workflow tools.

GRHANITE™ data in-transit

We have great confidence in the continued security of the GRHANITE™ comms and the security of data in-transit. This confidence is not due to the technologies we implement alone – we have comprehensive Standard Operating Procedures, on-going staff training and operational reviews and incident reporting mechanisms. We continually review our security profile and have active links and active intrusion alerting and response mechanisms via our large, experienced University of Melbourne Cybersecurity team and their toolsets.

Our own team is highly experienced in cybersecurity, and we maintain our own secure research environments that have been penetration tested by an independent contractor in the last year. This testing covered our operating procedures and documentation in addition to the technical testing itself. Our environments were unable to be compromised.

To ensure data security, we employ end-to-end encryption using asymmetric cryptography for all data transmissions. The data bank securely stores the private keys, while the GRHANITE™ web services possess only the corresponding public keys. Before sending data from the GP surgery, it is encrypted utilising one of the 10,000 available RSA public keys. This public key is randomly assigned and changes for each file transmission, as requested by the GRHANITE™ web service.

The data is partitioned across numerous files, with each individual file containing only a fraction of any single patient record. Throughout the entirety of the GRHANITE™ transmission chain, there exists no avenue for an unauthorised party to acquire the decryption keys, unless the data bank server infrastructure itself has been compromised. Furthermore, the decryption keys are stored in an encrypted format, rendering their acquisition an exceedingly complex endeavour. The GRHANITE™ encryption protocol employs a robust security measure wherein the encryption key is dynamically altered for each data transmission. In the event of unauthorised access, the perpetrator would be compelled to decipher the unique encryption key corresponding to each individual file received. This approach ensures that the breach of a single key does not compromise the confidentiality of the entire data set, as the remaining files remain inaccessible without their respective keys.

Consequently, acquiring the practice data by intercepting the transmissions would require an immense computing power to brute force up to 10,000 RSA keys. This effort renders the practice's EMR a more probable target for malicious actors, as the data contained therein is also readily identifiable on the General Practitioner's EMR system.

In the event of a phishing attempt, where a malicious entity impersonates the GRHANITE™ communication servers, all communications are initiated with a public-private key exchange, followed by the generation of AES keys for the decryption of the messaging cycle and on each subsequent communication. No data is transmitted in plaintext format. Every GRHANITE™ installation is equipped with its own unique set of public-private communication keys, which are meticulously established manually during the software installation process.

Our communication mechanism employs standard encryption algorithms (AES and RSA); however, the cycling mechanism employed is significantly more advanced than any standard communication implementation utilised in industry. Any hacking tools designed for phishing attempts would necessitate the replication of this intricate and non-standard encrypted, cycling messaging mechanism. Standard resources available on the dark web would be incapable of replicating such a complex system.

The central GRHANITE™ web servers are managed and patched according to Standard Operating Procedures with us reviewing known vulnerabilities on an active basis. We initiate any recommended essential security patches at the earliest opportunity usually within days of any new vulnerability being recognised.

GRHANITE™ uses the same industry and US federal-recommended public/private key encryption algorithms underpinning the banking and eCommerce sectors. This encryption ensures that any data in-transit is secure.

GRHANITE™ Privacy

GRHANITE™ optimises patient and health provider privacy by systematically excluding person identifiable data fields from data extracts. Data de-identification also depends, to some extent, on people who input data using the correct fields in their own computer systems (e.g. clinical software systems). Additional privacy filters are used by GRHANITE™ in fields where user error is known to occur.

If necessary, the data originating from a GP practice can be re-identified by sending it back to that practice and using a re-identification ‘key’. This sort of re-identification might be done if a practice agrees to participate in a clinical trial (pending appropriate data and ethical approvals) where the practice may contact patients with certain characteristics to determine their interest in participating.

Partnering general practices agree to display communication materials at all locations of their practice so that they can be viewed by patients. GRHANITE™ software includes an easy to access patient ‘opt-out’ checkbox so that practice staff can stop data related to individual patients from being extracted.

GRHANITE™ Client

The GRHANITE™ Client software resides on one of the clinician's computers and accesses the internal EMR database installed on that computer/server. Patients have the option to opt-out from participating, in which case their medical data will not be downloaded and transmitted through the GRHANITE™ system.

Usable patient data is retrieved and de-identified on a nightly basis. Every week, a collection run is conducted to obtain a reference point through a delta zero extract of the data. At a later time, typically after one week, a delta one extract can be created to identify and record changes in the data. A GUID (Globally Unique Identifier) is created, this enables a link to be made for the newly identified data. The software that creates the link IDs reviews the data to see if there are duplicate records. If duplicate data records are found then an algorithm runs over the data to determine if the records are for the same person, then merge the data. Privacy filters are added to the data as a final measure to make sure all names are eliminated. Up until this point no data has left the practice. The data is then encrypted and sent to a secure data landing area.

Currently, GRHANITE™ is deployed at over 1,000 general practitioner (GP) sites and is utilised by various organisations across Australia as a tool to retrieve recorded sensitive data. This data is then leveraged for a multitude of purposes, encompassing research endeavours, clinical trials, and various health surveillance initiatives.

Image above demonstrates the main components of GRHANITE™ within a clinic or GP surgery. The numbers in red correspond to the numbering below:

1. GRHANITE™ is installed on a workstation in the GP practice. It is installed there rather on the practice server to minimise practice impact and liability.
2. When GRHANITE™ runs, it does so at a scheduled time and queries data from the practice database server. This is the only time GRHANITE™ communicates with the practice server.
3. GRHANITE™ is a suite of three windows services installed on a practice PC: a scheduler service, an updater service, and a patient consent management service.
4. Installed with GRHANITE™ is an XML-based Data Extract Definition document. This document, which is remotely updatable, contains the information GRHANITE™ needs to determine how to connect to the GP database (verified at install-time), how to query the GP database, and how to manipulate the data prior to data transmission.
5. GRHANITE™ also utilises SQL Server Express to stage practice data while it is being manipulated.
6. As part of the data manipulation, GRHANITE™ can compare data held during the last data extract with the data as it is held now - Delta processing.
7. GRHANITE™ maintains a list of patients who have been consented to or who have denied consent (depending on the consent model operated). Data will only be extracted for consented patients or for patients who have not denied consent.
8. When the data for export has been prepared, it is encrypted using RSA encryption that prevents the data from being decrypted anywhere except its final, authorised destination. This secures the data during the transmission process.
9. The data is transmitted to the GRHANITE™ Middle Tier, a collection of services hosted at two locations in Melbourne, Australia.
10. GRHANITE™ data contains a unique ID number for each patient. This is exported with the GRHANITE™ data and can be used to re-identify a patient when required within the practice. Re-identification is not possible elsewhere.

GRHANITE™ Web Services

General Architecture

The GRHANITE™ general architecture in the above figure shows the overall GRHANITE™ data export process. At a top level it works as follows:

• GRHANITE™ installed in a GP surgery queries the GP databases and collates the data stored from the EMR. GRHANITE™ can work with many different technologies and hence can interface and query many different GP computer systems.
• The data required for export is compiled and transmitted to the GRHANITE™ web server infrastructure.
• The data is staged on the web server infrastructure until such time as a destination data custodian is ready to download the data. The GRHANITE™ Heartbeat website allows engineers to monitor the process.
• When scheduled, the staged data is picked-up from the web server and transmitted to a GRHANITE™ data bank.
• The data files are then decrypted and uploaded to SQL Server ready for analysis.
• Data from other sources that have utilised the GRHANITE™ Hash Generator (e.g. Death data from AIHW) can be imported also contributing to the overall data store. Such data can then be record-linked.

Heartbeat and Ticketing

GRHANITE™ handles large traffic volumes, this is managed utilising load balanced virtualized web servers located in Melbourne. This gives a failover redundancy capability. The load-balancing solution also allows for gradual scaling of the infrastructure. The virtual machines (VMs) are hosted on the Melbourne University node of the ARDC NeCTAR Research Cloud infrastructure.

GRHANITE™ Heartbeat is a web-based monitoring tool that extracts telemetry data from both GRHANITE™ clients and data banks, providing near real-time visibility into the health and operational status of the installed software across the entire system. This capability enables technical support personnel to swiftly identify and address any issues within hours of their occurrence. Heartbeat's mobile-friendly design ensures that its monitoring and oversight functionalities are accessible from virtually any device anywhere, enabling continuous real-time visibility into the system's operational status, regardless of the user's geographic location.

GRHANITE™ Databank and Databank Automation

GRHANITE™ Databank Client creates an RSA encrypted secure communication to the GRHANITE™ Web services. At scheduled intervals or on demand, GRHANITE™ Databank Client can be run to pull-back any GRHANITE™ client data that is staged for it on the web server file store. The transmitted files are held encrypted on the Databank server in a file landing area until required.

The GRHANITE™ Databank tool can be run manually or fully automated to decrypt the files and upload them to the SQL data repository. The upload process includes comprehensive logging to identify any issues with missing, incomplete, or out-of-order files sent to it.
Once the data is in the SQL database, control of the data hands over to the client for cleansing, QA and analysis.

Diagram above shows the main components of a GRHANITE™ Databank (Data Tier). GRHANITE™ Databanks are Windows Servers running GRHANITE™ data landing and loading software and running SQL Server databases where the data is ultimately uploaded.

GRHANITE™ data export process

• GRHANITE™ Scheduler initiates a data extract request at a scheduled time
• The GRHANITE™ Interface checks it is allowed to run by checking with the GRHANITE™ web server. Assuming permission is granted, the interface uses the GRHANITE™ XML definition to determine which database is to be queried. The interface queries the GP database and brings the data back to the local workstation for processing.
• The GRHANITE™ software then applies consent constraints and does any other pre-processing such as calculating patient ages.
• The software uses patient identifiers to generate hashes for record linkage
• The interface then removes person-identifiable information.
• If the project is large, GRHANITE™ can be configured to transmit only data changes. If this is the case, GRHANITE™ will compare every row of data held today with the data as it was at the time of the last extract. The system will determine any new, modified or deleted records and will prepare them for export.
• The interface will then request an encryption key from the web server that will be used to encrypt the data in a manner that can only be decrypted when the data arrives at its ultimate destination. The data is then compressed and encrypted.
• The data is then queued for transmission and so long as the internet connection is valid, the software will transmit the data to the GRHANITE™ web server.
• The GRHANITE™ web server will receive the project data and will stage it ready for transmission to the research repository.
• At a predetermined time, the research repository computer will communicate with the web server and pull-back all pending data. Web communication problems can prevent the successful transmission of some data. Should this happen, the data remains on the web server until any outstanding files are transmitted.
• At a predetermined time, the data received on the research repository is automatically uploaded to a SQL Server database.
• Once the data is in the SQL Server database it is available for use