We tackle the problem of sharing eHealth data across different jurisdictions. As a general rule, and due to the sensitive nature of the information, different national regulations impose severe limits on what can be exchanged, even in case of emergencies. Furthermore, different systems in different jurisdictions do not communicate. We propose BRUE as a scheme that allows eHealth data to be securely exchanged, with the data subject always in the position of mediation. We combine several technologies, namely, Blockchain, OAuth and User-Managed Access, and concept Receipts, to achieve our aim.Index Terms-eHealth data exchange, blockchain, smartcontracts, distribute, cross-jurisdiction mediates all steps and is, effectively, the (cryptographically) trusted communication channel between all the parties. Second, we combine a set of technologies and standards, each addressing a particular requirement. For authorisation and managing access to the records, we use and extend OAuth'sbased User-Managed Access (UMA) [1]. For a trusted and confidential communication channel, distributed discoverability and overall accountability, we use a public blockchain able to run smart-contracts. To handle the requirement of demonstration of valid consent, we use Kantara's Consent Receipts [2]. This combination of technologies motivates the name of our scheme: Blockchain, Receipts and UMA for eHealth data exchange (BRUE).To illustrate the problem, we informally analyse a simple working scenario of international eHealth data exchange.Alice (A) has had heart trouble since she was born in France. She has registered a GP (F GP ) in her original city. Then she moved to the UK after 10 years. When she was 20 years old and travelled to Canada, she fell sick and visited a GP (CGP ) to get e temporary treatment in Canada. After that trip, she returned to the UK and visited her British doctor (BGP , where GP stands for "General Practitioner"). She would like to share the British GP with her previous medical data which is stored respectively in Canada and France. However, she doesn't want to simply give British GP her personal credential but would rather authorize British GP which could gain access using GP's credential.In the scenario, there are four entities: the data subject A, a requesting party BGP , and data controllers which are healthcare service providers F GP and CGP . To note that A, BGP , CGP , and F GP , are independent parties located in different jurisdictions. Some of them are not known to the others; their only point of contact is their relationship with A, the patient and data subject. Furthermore, we assume, as is overwhelmingly the case, that there is no global system in place that allows all parties to directly communicate, find each other, or self-certify. In other words, BGP needs to access A's medical data from F GP and CGP but F GP and CGP do not recognise BGP so A needs to intermediate the request and grant access.