Névoa para gestão dos registros médicos centrada no paciente
4.3 Arquitetura de software proposta
5.3.1 QP1: A arquitetura de software proposta permite que o paciente controle a privacidade de seus dados médicos?
A abordagem proposta neste trabalho oferece ao paciente a real posse sobre os seus dados médicos, possibilitando que o mesmo controle as aplicações que podem acessar esses dados e os subconjuntos de informações que as mesmas podem manipular. Os submódulos Digital Wallet dos módulos Patient Application, Nurse Application e IoT Gateway são fundamentais nesse processo.
Conforme mostrado na Figura 43a, a criação de uma conta pelo paciente para registrar sua aplicação é o primeiro passo para ele começar a controlar a privacidade de seus dados médicos na solução. A Digital Wallet dessa aplicação chama o método mostrado na Listagem 1 passando a senha fornecida pelo paciente e cria a carteira para o mesmo. Por conseguinte, a Digital Wallet da Patient Application envia uma transação do tipo RPA à solução por meio do método mostrado na Listagem 2.
1 private void createWallet ( String password ) {
2 try {
3 WalletUtils . generateLightNewWalletFile ( password , new
File ( directory )); 4 } catch ( NoSuchAlgorithmException e) { 5 e. printStackTrace (); 6 } catch ( NoSuchProviderException e) { 7 e. printStackTrace (); 8 } catch ( InvalidAlgorithmParameterException e) {
9 e. printStackTrace (); 10 } catch ( CipherException e) { 11 e. printStackTrace (); 12 } catch ( IOException e) { 13 e. printStackTrace (); 14 } 15 }
Listagem 1: Método para criação de uma carteira nos submódulos Digital Wallet.
1 public void sendTransaction ( String to , Map <String , List < Operation >>
permissions , Type type , Long expiresIn , String others ) {
2 PatientMedicalRecordPermission pmrs = new
PatientMedicalRecordPermission ( permissions , type , expiresIn , others );
3 // Converte as permissões em JSON
4 Gson gson = new Gson ();
5 String pmrsStr = gson . toJson ( pmrs ); 6 // Converte as permissões JSON para HEXA 7 String pmrsHex = "";
8 try {
9 pmrsHex = Hex. toHexString ( pmrsStr . getBytes ("UTF -8"));
10 } catch ( UnsupportedEncodingException e) {
11 e. printStackTrace ();
12 }
13 // Configurações necessárias para envio de transações
Ethereum omitidas
14 ...
15 // Criação do objeto que representa a transação 16 RawTransaction rawTransaction = RawTransaction .
createTransaction ( getNonce () , gasprice , gaslimit , to , value , pmrsHex );
17 // Assinatura digital da transação pelo módulo que a envia 18 byte[] signedMessage = TransactionEncoder . signMessage (
rawTransaction , credentials );
19 String hexValue = Numeric . toHexString ( signedMessage ); 20 // Envio da transação
21 EthSendTransaction ethSendTransaction = null;
23 ethSendTransaction = web3j . ethSendRawTransaction ( hexValue ). send (); 24 } catch ( IOException e) { 25 e. printStackTrace (); 26 } 27 } 28 }
Listagem 2: Método para o envio de transações pelos submódulos Digital Wallet. Um método sendTransaction recebe por parâmetro a indicação de qual a carteira do Blockchain de destino da transação, a lista de permissões que o módulo está requerendo, o tipo da transação, o tempo em que a transação irá expirar e, opcionalmente, outras informações que se queira passar na transação. Posteriormente, o sendTransaction realiza algumas conversões de dados e con gurações necessárias ao envio da transação (linhas 2 à 14). Finalmente, esse método cria o objeto que representa a transação, a assina com as credenciais da carteira do módulo e a envia ao Blockchain Node (linhas 15 à 23).
Em se tratando da transação para registro da Patient Application, os principais dados passados para esse método são: o próprio endereço da carteira dessa aplicação como destino da transação, pois ela é a única envolvida nesse processo; a lista de permissões indicando que essa aplicação poderá ler todos os registros médicos relacionados ao paciente; e o tipo RPA, indicando que essa é uma transação de registro de aplicação do paciente. Uma exempli cação de dados enviados nesse processo foi mostrada anteriormente na Figura 29. As Digital Wallets da Nurse Application e do IoT Gateway também criam carteiras que representam esses módulos por meio do método mostrado na Listagem 1. Após isso, as Digital Wallets deles poderão enviar uma transação RDA solicitando acesso para manipular os dados médicos do paciente.
No caso dessa transação RDA, a Nurse Application passa para o método sendTran- saction: o endereço da carteira da aplicação do paciente como destino da transação; a lista de permissões indicando que esse módulo quer realizar leituras sobre os dados co- letados pelo E-Health Shield utilizado pelo paciente; o tipo RDA, indicando que essa é uma transação de requisição de acesso para manipulação de dados do paciente; e o times- tamp, indicando que esse módulo pretende ler esses dados até às 12h de 12/01/2020. A funcionalidade da Nurse Application que permite a enfermeira realizar essa solicitação foi mostrada anteriormente na Figura 46a.
o método sendTransaction apenas uma informação diferente das passadas pela Nurse Application. Como esse módulo é responsável por enviar os dados coletados pelo E-Health Shield para serem adicionados no Registro Pessoal de Saúde do paciente, ele requisita permissão para inserir dados nesse registro e não para lê-los, como é o caso da Nurse Application.
A Digital Wallet da Patient Application recebe, por meio das instruções mostradas na Listagem 3, as informações passadas ao sendTransaction referentes às transações de RDA descritas anteriormente. Em seguida, ela exibe uma noti cação informando ao paciente que há um módulo requisitando acesso a dados do Registro Pessoal de Saúde dele, conforme visto anteriormente na Figura 47a.
1 Subscription subscription = web3j . transactionObservable (). subscribe
(tx -> {
2 if ( credentials . getAddress (). equals (tx. getTo ())) { 3 // Conversões de formato de dados
4 String inputHex = tx. getInput ();
5 String inputJson = fromHexString ( inputHex );
6 PatientMedicalRecordPermission pmrp = gson . fromJson (
inputJson , PatientMedicalRecordPermission .class);
7 // Verifica se a transação é para requisitar acesso
8 if (pmr. getType (). equals ( PatientMedicalRecordPermission .
Type .RDA)) { 9 showNotification (tx. getFrom () , i, pmrp ); 10 i++; 11 } 12 } 13 });
Listagem 3: Código fonte para recebimento de transações pelo submódulo Digital Wallet da Patient Application.
O paciente pode analisar a requisição através da tela mostrada anteriormente na Figura 47b e, assim, permitir que o módulo possa realizar as manipulações de dados solicitadas. No momento em que o paciente pressiona o botão Grant Access, é enviada uma nova transação através do método sendTransaction concedendo a permissão ao módulo solicitante.
Nesse caso é enviada uma transação GDA pela Digital Wallet da Patient Application, a qual passa para o método sendTransaction: o endereço da carteira do módulo que
solicitou acesso (Nurse Application ou IoT Gateway) como destino da transação; a lista de permissões indicando quais subconjuntos de dados o paciente permite que o módulo solicitante possa manipular, bem como as operações que esse módulo poderá realizar sobre esses dados; o tipo GDA, indicando que essa é uma transação de concessão de acesso para manipulação de dados do paciente; e o timestamp, indicando até quando o paciente permite que o módulo solicitante realize as manipulações concedidas.
O IoT Gateway e a Nurse Application, de forma análoga a Listagem 3, receberão suas respectivas transações de concessão contendo as informações passadas pela Digital Wallet da Patient Application ao sendTransaction. A partir desse momento, o IoT Gateway poderá enviar os dados coletados pelo E-Health Shield para serem inseridos no Registro Pessoal de Saúde do paciente e a Nurse Application poderá visualizar essas informações, como visto anteriormente na Figura 46b.
O Blockchain Node é um submódulo que também tem um papel importante nesse processo. Ele recebe todos esses tipos de transações, as veri ca, calcula o hash das mesmas e as envia para serem validadas e seladas em blocos pelas Authorities. A Figura 49 mostra o contêiner que contém o Blockchain Node executando no Raspberry Pi.
Figura 49: Blockchain Node em execução no Raspberry Pi. Fonte: autoria própria.
Na Figura 50 é mostrada uma das Authorities da rede Blockchain criada. Ela executa em um contêiner na Nuvem e é responsável por validar todas as transações, selá-las em blocos e disponibilizá-las na rede Blockchain.
A estratégia de controle de privacidade baseada em Blockchain de nida neste traba- lho também mantém o anonimato do paciente. Todas as transações enviadas pelo método sendTransaction (Listagem 2) utilizam os endereços anônimos que representam os sub- módulos Digital Wallet implementados. Desse modo, a identidade das pessoas envolvidas nesse processo é mantida privada.
Figura 50: Authority em execução na Nuvem. Fonte: autoria própria.
vinculados aos endereços digitais da Digital Wallet da Patient Application, evitando-se que esses dados possam ser associados a um determinado indivíduo.