Your first Aurabox transfer request
You’ve just recieved an Aurabox Transfer Request. What do you do next?
An Aurabox Transfer Request is a request for medical imaging to be transfered to a new location via the Aurabox service. Transfer Requests are generally created by a treating doctor or hospital. These organisations use Aurabox to solve issues relating to the transfer of medical imaging between locations.
The request will look at bit like this:
Commonly asked questions
Who is Aurabox?
Aurabox helps users of medical imaging connect with imaging providers through its network. We are an Australian company, based in the Nation’s capital, Canberra.
How do I know if this is a legitimate request?
Yes. Aurabox is acting as the Requester’s authorised representative for the transfer of medical imaging. This request is usually made within the patient’s legal rights to disclose their personal information.
Australia
- In Australia, this is a legal request for personal information under the conditions of APP 6 in the Australian Privacy Act 1988.
Singapore
- In Singapore, this is a legal request for personal information under the conditions of the Personal Data Protection Act 2012.
UK
- In the UK, this is a legal request for personal information under the conditions of the General Data Protection Regulation (GDPR).
Should we respond?
It is likely that you have obligations to respond to legitimate requests for medical information. You may not be obligated to respond to Aurabox, however most of the time, you will be obligated to respond to the Requester.
Australia
- In Australia, you are obligated to respond to requests for personal information under the conditions of APP 6 in the Australian Privacy Act 1988. Just because the request comes via Aurabox does not affect your responsibliities to the requester. See OAIC.gov.au > Guide to health privacy > Chapter 4: Giving access to health information for more information.
Singapore
- In Singapore, you are obligated to respond to requests for personal information under the conditions of the Personal Data Protection Act 2012. Just because the request comes via Aurabox does not affect your responsibliites to the requester.
UK
- In the UK, you are obligated to respond to requests for personal information under the conditions of the General Data Protection Regulation (GDPR). Just because the request comes via Aurabox does not affect your responsibliites to the requester.
Can we refuse to respond?
Depending on your jurisdiction, you may be obligated to respond to the request. You may not be required to respond to Aurabox, however you are likely to be required to respond to the Requester. Responding via Aurabox may make the process easier for you and the requester.
Australia
- In Australia, you may refuse the request, however you should provide written notice, following the guidance set out in the Australian Privacy Principles. You can do this by choosing the Reject option on the request. In most cases, you need to provide an alternative. This can be provided when rejecting the request.
The Australian Privacy Act only has a limited number of grounds for refusing a request. Patients have the right to request access to their medical imaging in the manner of their choosing. Generally, you can not require someone to use your system to access imaging.
See OAIC.gov.au > Guide to health privacy > Chapter 4: Giving access to health information for more information.
Singapore
- In Singapore, you may refuse the request, however you should provide written notice, following the guidance set out in the Personal Data Protection Act 2012. You can do this by choosing the Reject option on the request. In most cases, you need to provide an alternative. This can be provided when rejecting the request.
UK
- Under the UK’s General Data Protection Regulation (GDPR) and the Data Protection Act 2018, you may refuse a data subject access request (SAR) if the request is deemed “manifestly unfounded” or “manifestly excessive.” If you choose to refuse the request, you are required to provide the individual with written notice, explaining the reasons for the refusal, their right to complain to the Information Commissioner’s Office (ICO), and their right to seek judicial remedies.
While you are allowed to reject requests, it is generally recommended to offer alternatives where possible. For example, if a request is considered too broad or burdensome, you might suggest narrowing the scope of the request.
Can we direct the requester to use our system?
Whether you can direct the requester to use your system to access imaging depends on laws in your jurisdiction.
However, requesters usually use Aurabox to aggregate imaging from multiple providers, and one reason is because of the poor experience of using multiple imaging portals. You can meet this requesters needs by using Aurabox to provide the imaging.
Since the requester asking for the imaging to be provided, your system must allow downloads.
Australia
- Generally, in Australia, you can not require someone to use your systems to access imaging. This would be a breach of Australian Privacy Principle 12.3b, which outlines that holders of health data must provide it to individuals in the manner requested.
Singapore
- In Singapore, organisations are not required to provide access to personal data through an individual’s chosen method. Instead, under the Personal Data Protection Act (PDPA) 2012, organisations must respond to access requests in a reasonable manner while considering security, feasibility, and privacy risks. The obligation to provide access lies with the organisation (data controller), not the data intermediary, and the organisation has discretion to determine the appropriate method of access, as long as it complies with the PDPA’s standards for handling personal data securely.
UK
- In the UK, under the General Data Protection Regulation (GDPR) and the Data Protection Act 2018, organisations are required to respond to data access requests in a reasonable manner. However, they are not obligated to provide data using the individual’s preferred method if it is unreasonable or impractical. Instead, the organisation must comply with the request in a secure and appropriate way that balances the rights of the individual with the organisation’s own obligations, such as data security and privacy protection.
- The GDPR grants individuals the right to access their personal data, but it allows organisations to determine the format in which the data is provided, as long as it is understandable and commonly accessible.
- While individuals can request access through specific means, the organisation retains discretion to provide data in a format that ensures security and compliance with other legal requirements
How do we verify the patient and requester?
Aurabox uses a number of methods to verify the identity of the patient and the requester. These methods are designed to ensure that the patient’s personal information is only disclosed to the correct person.
Requester Identity is validated using a combination of:
- The Requesters valid identity documents, or
- Has been added and verified by a verified organisation (e.g. a hospital), and
- The Requesters valid medical registration (if appropriate)
The Patients Identity is validated by:
- Aurabox, using the patients valid identity documents, or
- By the requester, as part of their normal operating procedures (for example, hospitals usually validate identity as part of their check in procedures)
The request will include information about the patient, requester, reason for request, consents, and the type of information requested.
More information on how we do this is available in Understanding Requests.
We need more information before proceeding
Aurabox is building a network of healthcare and imaging providers, and we are working to make the transfer of medical imaging easier. We’re here to work with you to understand your obligations and to help you respond to requests.
If you would like to discuss this request with Aurabox, you can contact our team at hello@aurabox.cloud.
If you need confirmation from the requester, you can contact them directly using the contact details provided in the request.