Site menu Antidote, a biblioteca IEEE 11073 de código aberto
e-mail icon
Site menu

Antidote, a biblioteca IEEE 11073 de código aberto

e-mail icon

2011.04.25

Este artigo expressa a opinião do autor na época da sua redação. Não há qualquer garantia de exatidão, ineditismo ou atualidade nos conteúdos. É proibida a cópia na íntegra. A citação de trechos é permitida mediante referência ao autor e este sítio de origem.

Neste artigo, vou falar um pouco sobre o padrão IEEE 11073, concebido para dispositivos médicos pessoais. E naturalmente vou falar da biblioteca Antidote, a implementação de código-fonte aberto da Signove para este padrão.

Figura 1: Medidor de pressão Omron

Bem, para início de conversa, o que é "dispositivo médico pessoal"?

PHD (personal health device) é uma classe de aparelhos que o usuário ou paciente usa de forma independente, ou semi-independente.

É algo mais comum do que parece. Quase todo mundo possui uma balança, termômetro ou um medidor de pressão em casa. Diabéticos mais "antenados" provavelmente possuem um glucosímetro.

No bojo dos PHDs também entram alguns dispositivos "health & fitness", tão na moda ultimamente: podômetros, medidores de batimentos cardíacos, etc.

Tais dispositivos permitem que as pessoas monitorem sua saúde e sua condição física sem precisar deslocar-se ao médico ou ao hospital toda hora, o que representa uma enorme economia de dinheiro. Principalmente tendo em vista o custo cada vez mais alto da saúde, e o envelhecimento da população.

Há vinte anos, toda balança ou medidor de pressão eram mecânicos. Hoje, praticamente todos são eletrônicos. O passo seguinte é adicionar conectividade a estes aparelhos, para que possam remeter seus dados para o celular ou computador do paciente. E dali para o médico, ou para o hospital. Este vídeo mostra um medidor de pressão com suporte a Bluetooth.

Como deve ser óbvio, o ideal é que todos estes aparelhos sigam um único padrão nesta transmissão de dados. Aqui entra o padrão IEEE 11073.

IEEE 11073:20601

Nas palavras de um amigo, o IEEE 11073 é um padrão "prolixo". Quem vem do mundo TCP/IP e está acostumado com RFCs escritas de forma leve, informal e esclarecedora, os documentos do padrão IEEE parecem realmente intimidadores, estranhos, antiquados e áridos.

Não é meu objetivo aqui fazer uma análise crítica do padrão IEEE, e prefiro que haja um padrão do que dois, ou nenhum padrão. O sanduíche do McDonalds não é o melhor, mas todo mundo acaba comendo, não é?

A base de tudo é o ASN.1. A "linguagem" ASN.1 é uma forma neutra de especificar tipos, estruturas e mensagens do protocolo. Para transmitir e receber mensagens "de verdade", é preciso adotar uma regra de codificação. No caso do IEEE 11073 é a MDER (que suporta apenas um subconjunto do ASN.1).

Acima do ASN.1, temos os PHD types, ou tipos PHD. São tipos de dados simples e complexos construídos com base nos tipos primitivos ASN.1 que são suportados pelo MDER.

Por exemplo, FLOAT é um tipo de ponto flutuante de 32 bits, com 24 bits de mantissa e 8 de expoente, análogo porém diferente do padrão de ponto flutuante que normalmente utilizamos (IEEE 754), inclusive porque o expoente é base-10.

No topo da "cadeia alimentar" está o DIM — domain information model, uma espécie de árvore de informações médicas.

A alegada orientação a objetos do DIM advém do fato de haver "classes" de dados. Um conjunto de dados médicos implementa uma classe DIM bem definida; assim a aplicação que interpretar estes dados sabe perfeitamente o que encontrar ali.

Uma classe DIM pode ser estendida. Um termômetro de determinado fabricante pode transmitir uma informação adicional qualquer não prevista na classe DIM "original"; ou um dispositivo pode implementar duas funções simultâneas (e.g. balança com medidor de gordura corporal). Para acomodar estas necessidades, o fabricante simplesmente implementa uma sub-classe DIM.

A propósito, o conjunto de classes e constantes adicionais necessários para suportar um tipo de dispositivo, é denominado "especialização" e é documentada em separado. Por exemplo, o documento 11073:10404 é a especialização do oxímetro.

O protocolo IEEE possui mecanismos para que a contraparte "aprenda" novas classes DIM. Isto garante a interoperabilidade presente e futura; um software que controla o peso do paciente não vai explodir porque uma balança nova transmita também a % de gordura corporal...

Continua Alliance e Bluetooth

Figura 2: Oxímetro com Bluetooth

Continua Alliance é uma organização sem fins lucrativos dedicada à promoção destes conceitos de medicina à distância, acompanhamento remoto de doenças crônicas, etc.

Uma das atividades do Continua é a promoção de padrões, e a respectiva certificação. Um dos padrões adotado é justamente o IEEE 11073.

Como o IEEE não especifica o transporte, o Continua trata de fazer isso, procurando tecnologias que mantenham os dispositivos razoavelmente baratos, e facilmente conectáveis com computador ou celular que o paciente já possua, ou possa comprar "na esquina".

Assim, o Continua atualmente prevê três meios de comunicação: Bluetooth, USB e Zigbee. Outras poderão ser adotadas no futuro.

No Bluetooth, o suporte a dispositivos médicos é coberto pelo perfil HDP. Para poder usar, por exemplo, um oxímetro ou medidor de pressão com Bluetooth, em seu computador, a pilha Bluetooth do sistema operacional precisa implementar HDP.

O BlueZ (pilha Bluetooth do Linux) implementa HDP há alguns meses, desde a versão 4.81. Se sua distribuição usa um BlueZ mais antigo, sempre é possível instalar versão mais nova a partir do código-fonte.

Mas o HDP fornece apenas o transporte de dados. Ainda é preciso rodar alguma aplicação que implemente o protocolo de sessão (IEEE 11073).

Antidote

Antidote é uma implementação do IEEE 11073, desenvolvida pela Signove Tecnologia. No momento, parece ser a única biblioteca IEEE 11073 de código-fonte aberto.

A biblioteca é escrita em C, e possui pouquíssimas dependências em relação a outras bibliotecas, arquiteturas ou meios de comunicação. Embora ela tenha sido testada quase unicamente com Linux, não há empecilhos à portabilidade.

As "pontes" entre pilha IEEE, aplicação, e o mundo exterior, é feita por meio de um plug-in de transporte. Sobre este recaem todas as dependências.

Por exemplo, o plug-in BlueZ HDP incluso no fonte depende de Linux, BlueZ e main loop GLib. Se nossa aplicação usa Qt, a solução é escrever outro plug-in que faça uso de main loop Qt. Não é muito difícil tendo um plug-in GLib no qual se basear, mas tem de ser feito.

Um outro tipo de plug-in (também linkado estaticamente) do Antidote é o codec de dados. Sua função é basicamente transformar um objeto DIM do IEEE numa representação mais simples, como XML ou JSON. Isto pode poupar a aplicação de ter de lidar diretamente com as estruturas DIM.

A biblioteca possui rotinas de teste unitário, documentação de diversos tipos (Doxygen, wiki, texto introdutório), aplicação de exemplo (vide tópico a seguir) e uma empresa trabalhando ativamente pelo produto.

O serviço com.signove.health

Na mesma árvore de código-fonte da biblioteca, o Antidote traz uma aplicação completa de exemplo: um serviço D-Bus para dispositivos médicos Bluetooth.

A implementação deste serviço no mesmo fonte, serve a dois propósitos. O primeiro propósito é a auto-documentação. O desenvolvedor pode analisar o fonte e interagir com a aplicação, usando um script Python, D-Feet, etc.

O segundo propósito é oferecer uma forma ainda mais simples de lidar com dispositivos médicos. Em vez de linkar com a biblioteca, a aplicação só precisa usar a API D-Bus do serviço com.signove.health.

Além da API D-Bus ser muito mais simples (embora menos poderosa que utilizar Antidote diretamente), a aplicação pode ser escrita em qualquer linguagem ou plataforma. Basta que suporte D-Bus.

Outra vantagem é a centralização. Não daria muito certo se duas aplicações tentassem acessar um dispositivo HDP ao mesmo tempo. A presença de um serviço intermediário evita este tipo de conflito.

Este serviço tem sido usado "a sério", e pode muito bem vir a tornar-se um padrão amplamente utilizado.

e-mail icon