veja o trabalho - Coordenação de Projetos

UNIVERSIDADE FEDERAL DE SANTA CATARINA
DEPARTAMENTO DE INFORMÁTICA E ESTATÍSTICA
Desenvolvimento de um cliente DICOM
para ditado de laudo em iOS
JOÃO OLVI SIQUEROLLI NETO
Florianópolis
2013
João Olvi Siquerolli Neto
DESENVOLVIMENTO DE UM CLIENTE DICOM
PARA DITADO DE LAUDO EM IOS
Trabalho de Conclusão de Curso
de Bacharelado em Ciências da
Computação
da Universidade Federal de Santa
Catarina.
Orientador: Prof. Dr. rer. nat. Aldo
von Wangenheim
Florianópolis
2013
Agradecimentos
Aos meus pais pelo apoio oferecido em todos os momentos de
minha existência. Por toda a paciência, compreensão e “força” que me
deram durante todo o processo de desenvolvimento deste trabalho.
Vocês são os melhores!
Ao professor e orientador Aldo von Wangenheim pela sugestão
de sugestão do trabalho e por coordenar o importantíssimo projeto de
Telemedicina de Santa Catarina.
Ao professor Harley Wagner por acreditar no projeto e se
disponibilizar para discutir e sanar dúvidas, quando necessário.
À professora Dra. Maria Inês Meurer por todas as sugestões, todo
o enorme interesse e suporte oferecido durante as avaliações a que o
trabalho se submeteu. Maninha, você é demais!
Ao Dr. Rodrigo Ozelame por aceitar participar da banca.
À equipe do laboratório de Telemedicina, desenvolvedores do
STT pela disponibilidade para as reuniões e apoio para a realização do
trabalho.
À Camile Mansur e Nathalie Ferreira por sempre estarem
extremamente dispostas a ajudar a resolver qualquer problema.
RESUMO
O objetivo desse trabalho é desenvolver um aplicativo para envio de
laudo médico ditado via iOS. O aplicativo será disponibilizado como
um app nativo para iPhone e integrado ao STT – Sistema Catarinense de
Telemedicina e Telessaúde. O intuito é substituir aparelhos específicos,
caros e não móveis utilizados atualmente para o mesmo fim.
Palavras-chave: laudo, telemedicina, iOS
Sumário
INTRODUÇÃO ............................................................................7
1.1 STT .....................................................................................7
1.2 LAUDOS MÉDICOS .........................................................8
1.2.1 Laudo manuscrito ........................................................9
1.2.2 Laudo ditado analógico ...............................................9
1.2.3 Laudo ditado digital ..................................................10
1.3 CENÁRIOS IDENTIFICADOS .......................................11
1.3.1 Cenário 1: gravação de laudos é realizada com um
aparelho exclusivamente adquirido para isso................................12
1.3.2 Cenário 2: envio de laudo ditado é realizado através de
um sistema web .............................................................................14
1.4 OBJETIVOS.....................................................................15
1.4.1 Objetivo geral ............................................................15
1.4.2 Objetivos específicos ................................................16
1.4.3 Casos de uso ..............................................................16
1.5 USABILIDADE ...............................................................17
1.5.1 Usabilidade em dispositivos móveis .........................18
2 REVISÃO SISTEMÁTICA ....................................................20
2.1 OBJETIVOS DA BUSCA................................................20
2.2 PADRÃO DICOM PARA ARQUIVOS DE ÁUDIO ......20
2.2.1 Realização da busca ..................................................21
2.2.2 Artigos analisados .....................................................21
2.3 GRAVADORES DE ÁUDIO NO PADRÃO DICOM
PARA DISPOSITIVOS MÓVEIS ....................................................24
2.3.1 Realização da busca ..................................................25
3 DESENVOLVIMENTO..........................................................26
3.1 INTERAÇÃO COM O APLICATIVO ............................26
3.2 INTERAÇÃO VIA SMARTPHONE ...............................27
3.2.1 Protótipo inicial .........................................................27
3.2.2 Adaptações do protótipo inicial.................................30
3.3 IMPLEMENTAÇÃO .......................................................36
3.4 FLUXO PARA EMISSÃO DE LAUDO .........................38
3.5 FORMATO DE ARQUIVO DE GRAVAÇÃO ...............40
3.5.1 Gravação em formato DICOM ..................................43
4 Conclusão ................................................................................44
Referências .................................................................................45
7
INTRODUÇÃO
O processo tradicional de um diagnóstico médico se baseia na
realização de um exame no paciente a ser tratado. O resultado do exame
realizado é encaminhado a um médico especialista, que deve emitir um
laudo, onde está explícito o quadro clínico do paciente.
Com o avanço de tecnologias computacionais e de
telecomunicações tornou-se possível armazenar e gerenciar esse tipo de
dado em sistemas centralizados que permitem o acesso a essas
informações por parte do médico e paciente através da internet a
qualquer momento. Esse tipo de sistema ainda permite que exames
sejam analisados e laudados à distância, sem que médico ou paciente se
desloquem para um encontro físico. Esses sistemas são chamados de
sistemas de telemedicina. A telemedicina está crescendo rapidamente
pelo mundo inteiro. No Brasil temos alguns sistemas em
funcionamento, como, por exemplo, o STT – Sistema Catarinense de
Telemedicina e Telessaúde.
1.1 STT
Telemedicina se baseia no uso de informações eletrônicas e
comunicação a distância para oferecer suporte a pacientes, profissionais
e unidades de saúde (Mcneill et al., 1998). A disponibilidade de dados à
distância despertou interesse mundial pela telemedicina, o que levou à
disseminação dos sistemas de arquivamento e comunicação de imagens
(do inglês, Picture Archiving and Communication System – PACS). O
PACS tem como um de seus componentes a distribuição de imagens e
foi originalmente desenvolvido para serviços de Radiologia, com o
intuito de capturar imagens médicas sem utilizar filme (Huang, 2003;
Clunie, 2008). Atualmente o PACS está sendo estendido para outros
serviços clínicos de imagem e, em conjunto com a telemedicina, já é
possível a manipulação e a avaliação remota dos dados gerados.
Em 2005, após estudos sobre os sistemas de telemedicina a
Universidade Federal de Santa Catarina, juntamente com a Secretaria de
Estado da Saúde de Santa Catarina, desenvolveu um sistema de
telemedicina para dar suporte a pacientes. Estava prevista a ampliação
8
do conjunto de equipamentos médicos conectados em rede, onde seriam
inclusos eletrocardiogramas, equipamentos de ultrassonografia,
tomografia computadorizada e ressonância magnética. O projeto foi
intitulado de Rede Catarinense de Telemedicina e Telessaúde (Andrade,
R., 2011). Foi desenvolvido também o Portal Telemedicina, sistema
para armazenamento centralizado e distribuição de informações de
pacientes, imagens e laudos na internet.
Por ter experiência com telemedicina, o estado catarinense foi
selecionado para fazer parte do programa de criação do Portal de
Telessaúde do Brasil, em 2007. O projeto objetiva auxiliar na
qualificação profissional e nos procedimentos assistenciais da rede de
Atenção Primária. As Equipes de Saúde da Família, formadas por
profissionais credenciados dos municípios participantes do sistema de
Telessaúde, recebem assistência através de serviços de segunda opinião
formativa e ensino à distância, oferecidos em um sistema web
(Andrade, 2011).
Em 2010 o Portal Telemedicina e o projeto Telessaúde foram
unificados e deram origem ao Sistema Catarinense de Telemedicina e
Telessaúde (STT). O sistema atualmente atende 287 dos 293
municípios catarinenses - dos quais 193 enviam exames à distância -,
armazena mais de um milhão de exames de imagens, além de ter 4000
profissionais da saúde e 370 mil pacientes cadastrados, que podem
acessar seus exames.
1.2 LAUDOS MÉDICOS
O laudo médico permite que o quadro clínico de um paciente seja
registrado de acordo com um exame realizado e pode ser consultado
futuramente, em formato de histórico médico do paciente para análise
de situações relevantes para um futuro diagnóstico. Os laudos,
atualmente armazenados em sistemas centrais, são disponibilizados para
acesso via internet pelo paciente e pelo médico responsável por seu
tratamento. Esses laudos devem estar estruturados de forma que sua
consulta futura seja possível, precisa e eficaz.
Apesar de seguirem padrões para armazenamento, a produção de
laudos ainda não tem um padrão definitivo e aceito em todas as
instituições de saúde. Diferentes instituições geram laudos de formas
distintas, o que gera a necessidade de ter equipes para transcrever esses
laudos para o sistema central. Essas equipes transcrevem exatamente as
9
mesmas informações contidas no laudo, mas respeitando os padrões
estabelecidos em sistemas centrais que permitem consultas por partes
interessadas. Essas equipes recebem laudos de médicos responsáveis
por diagnósticos em alguns formatos utilizados atualmente: laudo
manuscrito, laudo ditado analógico e laudo ditado digital (Ruby, 2012).
1.2.1 Laudo manuscrito
O método mais simples é o laudo manuscrito, gerado através de
um formulário em papel. O médico analisa o exame do paciente e
descreve, à mão, seu diagnóstico dos resultados colhidos. Esse
formulário é arquivado em anexo ao exame de referência para futuras
consultas e para compartilhamento do resultado com o próprio paciente.
Esse método tem diversos problemas, pois praticamente não apresenta
automatização alguma.
Há risco em falha de interpretação textual, caligráfica, perdas de
exames ou laudos, troca de formulários, rasuras no texto, etc. Se
considerar a quantidade de exames de um hospital de médio-grande
porte, fica evidente a quantidade de falhas que podem ocorrer durante o
processo.
Esse tipo de laudo tende a ser substituído por soluções
computacionais, onde a margem de falhas simples é drasticamente
inferior. Lidar com sistemas computacionais normalmente acarreta na
organização de uma equipe especialista para que o uso do sistema em
questão se faça produtivo e valha seu uso. Mesmo com uma equipe
especializada na transcrição de laudos manuscritos para meio digital os
problemas já citados não se extinguem. Uma forma de tentar solucionar
problemas com caligrafia e rasuras é o uso de laudo ditado (Ruby,
2012).
1.2.2 Laudo ditado analógico
O médico analisa um exame e grava o laudo verbalmente em
uma fita microcassete. Essa fita segue para uma equipe transcrever o
laudo em forma de texto, que é enviado de volta ao médico que realizou
o laudo para que possa conferir se não houve problemas de
interpretação ou quaisquer outros equívocos.
A fita com gravação original é arquivada temporariamente
durante esse processo de confirmação de laudo e identificada através de
10
etiqueta com nome do paciente manuscrito. Há risco de ocorrer erro na
escrita do nome, má interpretação da caligrafia, confusão entre
pacientes e perda da fita.
Ao término do processo de validação do laudo escrito, a fita
microcassete é reaproveitada para um novo paciente, o que causa perda
da qualidade de áudio. O laudo escrito, então, é armazenado no sistema
STT, isto é, seu histórico médico é incrementado. Este laudo pode ser
usado futuramente para consultas de dados específicos quanto ao quadro
clínico do paciente até um determinado momento.
Após o salvamento no sistema, o laudo pode ser visualizado
diretamente pela internet e há a possibilidade de imprimí-lo, caso
necessário. Antes de estar disponível para o paciente esse laudo passa
por um rigoroso processo de validação pelo médico que realizou o laudo
originalmente. Esse processo tenta diminuir ao máximo as chances de
que o paciente receba qualquer tipo de informação incorreta sobre seu
quadro clínico (Ruby, 2012).
1.2.3 Laudo ditado digital
Nessa modalidade o áudio fica armazenado digitalmente junto ao
exame para futuras consultas e pode ser acessado de qualquer
dispositivo com acesso à internet.
No contexto da telemedicina de Santa Catarina, o gravador
escolhido para essa tarefa é o SpeechMike (Fig. 1), fabricado pela
Philips e oferece um software próprio para ditados médicos. O aparelho
é conectado via USB a um computador e gera o arquivo conforme a
gravação é realizada (Ruby, 2012).
11
Figura 1: Gravador Philips SpeechMike.
Após a gravação estar devidamente concluída, com todos os
ajustes necessários por parte do médico, o arquivo é disponibilizado
para a equipe a transcrever o áudio em formato de laudo textual.
Concluída esta etapa, o laudo passa por correções pelo médico
responsável pelo seu ditado, posteriormente é disponibilizado para
consulta por parte de instituições de saúde e do paciente, através de um
sistema centralizado.
Com o ditado sendo realizado em gravador digital, problemas
como perda na qualidade de áudio conforme uma fita é reutilizada, bem
como perda da própria fita são eliminados. Problemas como vinculação
equivocada de laudo a um paciente e armazenamento de longa data, no
entanto, ainda são realidade.
1.3 CENÁRIOS IDENTIFICADOS
O laudo ditado digital veio para corrigir alguns problemas
importantes na manipulação, gerenciamento e agilidade na realização do
laudo. No entanto, o médico está preso a um gravador específico, que
depende da conexão via USB a um computador, onde o software de
ditado está instalado. São dois problemas evidentes: necessidade de um
aparelho específico e necessidade de um dispositivo com software
específico ao alcance.
12
Em diversas situações médicos precisam analisar exames com
urgência e, em alguns casos, sequer estão presentes fisicamente em uma
instituição de saúde. Nesse tipo de situação não há, normalmente,
acesso a um gravador ou a um computador preparado com o software
necessário.
Um exemplo é quando o médico é o único especialista em uma
área médica em uma determinada região e todos os laudos dessa área
médica são realizados por esse profissional.
Já existe um aplicativo do STT para iPad, que possibilita a
visualização de imagens de exames. Apesar disso, o médico deve
recorrer a outros meios para realizar o laudo, já que o sistema atual não
possibilita a entrada de laudo ditado pelo tablet.
1.3.1 Cenário 1: gravação de laudos é realizada com um aparelho
exclusivamente adquirido para isso
Neste cenário, no contexto atual do sistema de telemedicina de
Santa Catarina, o médico precisa estar com o gravador SpeechMike
conectado a um computador para gravar um laudo ditado. O médico, no
entanto, nem sempre o médico está próximo a um computador; menos
frequente ainda é o médico estar com um gravador a sua disposição.
A qualidade da informação e a redução do tempo ao
disponibilizar um laudo médico são fundamentais aos cuidados com os
pacientes. Com o laudo ditado, o médico poupa bastante tempo na
emissão do laudo e consegue realizar mais laudos em um determinado
período de tempo. Gravações de voz para preparação de documentos
estruturados estão sendo usadas com sucesso nos últimos anos
(Gopakumar et al., 2009).
Nesse cenário, o objetivo de disponibilizar a gravação de laudo
ditado pelo smartphone, que sempre está em posse do profissional. Pela
responsabilidade exigida do trabalho, médicos laudadores estão sempre
com seus smartphones ao alcance. Com a possibilidade de gravar com o
dispositivo, o profissional teria sempre à disposição a ferramenta que
precisa para realizar a gravação de um laudo ditado.
A seguir são apresentados os protótipos das telas da aplicação,
desenvolvidos após observação de fluxo de vida do laudo ditado como é
hoje (Fig. 2).
13
Figura 2: Passo a passo do processo de gravação do laudo
Como fica claro nesse processo ilustrado, as informações mais
relevantes do exame para a execução do laudo estão disponíveis a todo
momento para o médico consultar. Por conta das limitações das telas de
smartphones, não são exibidas as imagens do exame. O médico deve
analisar as imagens em outro dispositivo, seja iPad ou computador
pessoal.
O passo a passo segue o seguinte fluxo:
1. Usuário visualiza lista de exames sem laudo;
2. Dados textuais exibidos para confirmação de seleção;
3. Para iniciar o laudo, usuário opta por gravar um novo laudo
ditado ou selecionar um arquivo previamente gravado no dispositivo;
14
4. Informações do exame expostas, junto a um botão para iniciar
gravação;
5. Cronômetro indica duração da gravação, que pode ser parada a
qualquer momento;
6. Ao parar uma gravação, é possível continuar gravando ou
seguir para o envio.
1.3.2 Cenário 2: envio de laudo ditado é realizado através de um
sistema web
Hoje o envio de laudo ditado digital ao STT é feito através de um
sistema web, exclusivamente. O próprio STT já possui um aplicativo
desenvolvido para iPad que possibilita a visualização de imagens de
exames, o que garante mais mobilidade ao médico. Não é possível
analisar imagens de exames na tela de um smartphone por causa do
tamanho da tela ser muito reduzido. Isso assegura que a análise das
imagens tenha condições aceitáveis para diminuir falhas.
Esse aplicativo, no entanto, possibilita apenas a visualização das
imagens, o que deixa o médico ainda preso ao gravador SpeechMike e a
um computador com software de ditado exclusivo do gravador.
Nesse cenário a proposta é possibilitar o envio do laudo
diretamente de um iPhone, através do aplicativo desenvolvido no
presente. O médico indica no próprio STT que realizará o laudo através
de uma gravação de áudio no smartphone. O processo é muito
semelhante ao processo já utilizado hoje, com o qual os médicos já
estão adaptados. No aparelho, o médico não tem visualização das
imagens, mas tem acesso aos dados textuais do exame para confirmar
que não houve alguma falha no sistema e, portanto, o médico está
realizando o laudo do exame desejado.
A seguir são exibidos protótipos iniciais das telas de submissão
da gravação, construídos após análise do fluxo de submissão de laudo
hoje (Fig 3).
Nesse processo o médico, após realizar a gravação poderá ouvir o
áudio a ser enviado para confirmar a sua validade. Ainda terá acesso aos
dados textuais do exame, para evitar qualquer tipo de divergência entre
laudo e exame. Ao concluir o envio de um laudo, o usuário é notificado
para estar a par de que o laudo já está disponível no sistema central
STT, e pronto para ser transcrito por uma equipe especializada.
15
Figura 3: Passo a passo do processo de envio de laudo ditado
1.4 OBJETIVOS
A seguir são descritos os objetivos a serem alcançados pelo
presente trabalho. Estão separados em objetivo geral e objetivos
específicos para mais fácil compreensão e contextualização.
1.4.1 Objetivo geral
Desenvolver um aplicativo para dispositivos iOS que possibilite
a gravação e submissão de um laudo ditado para o STT. Espera-se
eliminar a necessidade do gravador específico utilizado hoje, bem como
a necessidade de um computador com software específico para ditados.
16
1.4.2 Objetivos específicos
Desenvolver um aplicativo para dispositivos iOS que permita
gravar e submeter laudo ditado ao STT. Esse aplicativo deverá ser capaz
de gerar arquivos válidos em formato padrão DICOM e enviá-lo ao
servidor do STT.
Avaliar a qualidade de áudio conseguida através desses
dispositivos não projetados para este fim.
1.4.3 Casos de uso
A seguir são descritos os principais casos de uso envolvidos na
aplicação, desde o início da emissão do laudo no STT, até o envio da
gravação do laudo ditado, realizada no aplicativo desenvolvido e
submetida ao STT.
1.4.3.1 Médico laudador grava um laudo ditado
Figura 4: Diagrama do caso de uso "Médico laudador grava um laudo
ditado"
No caso de uso acima, o médico se conecta ao STT e visualiza
um exame sem laudo. Esse acesso pode ocorrer pelo navegador do
computador, pelo aplicativo de visualização de exame disponível para
iPad. O médico, então, apanha seu smartphone e acessa o aplicativo
desenvolvido neste trabalho. Neste aplicativo o médico faz sua
17
autenticação no sistema, da mesma forma que o fez no navegador, por
exemplo; então o profissional busca dados do exame que ele está
visualizando em seu computador, e faz a gravação do laudo ditado do
exame a ser laudado.
1.4.3.2 Médico laudador submete a gravação do laudo ditado
Figura 5: Diagrama do caso de uso "Médico laudador submete a
gravação do laudo ditado"
Esse caso de uso tem por objetivo possibilitar a submissão da
gravação realizada pelo médico ao STT, para futura transcrição. O atual
processo de acesso posterior e transcrição da gravação não sofre
modificação. O aplicativo deve, após concluída a gravação, converter o
arquivo de áudio gerado para o padrão DICOM. Ambos os arquivos –
gravação em formato DICOM e gravação original, em formato Wave são enviados para o STT.
1.5 USABILIDADE
A usabilidade de registro eletrônico de saúde (RES) tem recebido
cada vez mais atenção, pois é identificada como umas das principais
barreiras à adoção dessa tecnologia. Diariamente médicos se deparam
com uso de RES problemáticos, com workflow diferente do processo
clínico abordado, excesso de informações ou mesmo excesso de alertas
(devido aos cuidados que um sistema médico deve oferecer) e
complexidade desnecessária para realização de tarefas comuns (Liu et
al, 2011).
Usabilidade é definida pelo Instituto Nacional de Padrões de
Tecnologia americano (2007) como “a eficácia, eficiência e satisfação
com que o usuário pode realizar suas tarefas no contexto abordado pelo
18
produto”. A usabilidade de RES pode ser medida através dessas
propriedades. Mais especificamente o aplicativo a ser desenvolvido
deverá garantir que o usuário tenha uma boa experiência de uso, que
seja rápido, fácil, confiável, e eficiente.
Para alcançar a melhor usabilidade possível, uma ferramenta
RES deve ser inteligente o bastante para intervir no uso por parte do
médico apenas quando necessário. Isso significa que a ferramenta não
deve encher o médico de informações e pedidos de confirmações sem
necessidade. Deve apenas fazê-lo para evitar que o médico cometa um
erro real, como entrada de algum dado inconsistente.
Com intuito de facilitar o uso de um sistema RES, deve ser
garantido ao médico acesso rápido a quaisquer informações
relacionadas à tarefa a ser realizada. Como, por exemplo, no caso do
sistema de laudo ditado, deve ser fácil de o médico acessar quaisquer
dados relevantes sobre o exame a receber o laudo para que o
profissional confirme que está realizando um laudo consistente.
Para evitar erros por falta de atenção ou qualquer distração que
aconteça durante o processo de uso do sistema, opções perigosas devem
ser eliminadas nos primeiros passos de um processo.
O sistema ainda deve ser rápido o bastante, para que o usuário
não perca o foco em seu objetivo final. O sistema deve ter um processo
simples o bastante para que o usuário não precise refletir sobre qual
atitude deve tomar em determinado passo e possa se concentrar
totalmente na tarefa que está realizando (Schumacher et al., 2010).
1.5.1 Usabilidade em dispositivos móveis
Com a popularização e adoção cotidiana de dispositivos móveis,
a usabilidade desses dispositivos ganhou muita atenção de
desenvolvedores e designers de software. Hoje a usabilidade no
consumo de dados estruturados nesse tipo de dispositivo já está bem
avançada, usuários já estão bastante adaptados ao uso e novos usuários
facilmente aprendem e se acostumam com o uso de um novo sistema
móvel.
19
No entanto, para diversas aplicações com conteúdo mais
específico, dispositivos móveis ainda sofrem com diversos problema,
visto que ainda somos acostumados com o uso de um computador de
mesa ou laptop, com sistemas de propósito geral muito mais
abrangentes. A falta de padronização e inconsistências de design, como,
por exemplo, a falta de um padrão para o botão “voltar” em diversas
aplicações móveis dificulta o uso da ferramenta. Cada aplicação faz seu
próprio padrão e o usuário tem que se acostumar com todos os padrões
de todas as aplicações que utiliza no dia a dia.
Além de problemas com design, há problemas como a garantia
ou necessidade de conexão do dispositivo no momento da realização de
uma tarefa pelo usuário, onde há comunicação via internet. Aplicações
que necessitam de conexão com internet deveriam ser repensadas, na
transferência entre plataforma PC e móvel, por exemplo. Essas
aplicações devem ser pensadas para lidar com esse tipo de problema de
conexão sem incomodar o usuário ou simplesmente falhar durante a
comunicação e ignorar a tarefa a ser realizada.
Em dispositivos móveis diversos pontos extras em relação a
sistemas para PC devem ser considerados, como a considerável
variedade de dispositivos, os tipos de conexão, fragmentação de
conteúdo, contexto de uso a cada passo de uma aplicação, tamanho da
tela e consequente tamanho de textos e imagens a serem exibidas,
duração da bateria do dispositivo, entre outros (Hulme e Traxler, 2005).
O trabalho foi desenvolvido para garantir a fácil e boa utilização
da aplicação. Se houver falha na comunicação entre cliente e servidor, a
aplicação deve tentar novamente realizar a requisição e só incomodar o
usuário com esse tipo de falha quando em casos mais críticos, como
diversas tentativas falhas. A aplicação conta ainda com design simples e
intuitivo, com textos de fácil leitura. O processamento para preparar o
áudio gravado para enviar ao servidor não foi desenvolvido de forma a
otimizar o uso de recursos do dispositivo e não tomar toda a
performance.
20
2 REVISÃO SISTEMÁTICA
Serão apresentadas a seguir as pesquisas realizadas para
encontrar artigos científicos e trabalhos acadêmicos que foram
relevantes para a realização desse trabalho. Foram buscados artigos para
cada parte envolvida no projeto: padrão DICOM para trabalhar com
áudio, gravadores de áudio no padrão DICOM para dispositivos móveis,
desenvolvimento de ferramentas que utilizam padrão DICOM para
arquivos de áudio para dispositivos móveis, com foco no sistema
operacional iOS.
Cada etapa de busca será descrito de forma detalhada, relatando
as buscas realizadas e os resultados de interesse encontrados, as
motivações para a seleção destes resultados e como contribuem para a
realização desse trabalho.
2.1 OBJETIVOS DA BUSCA
A busca foi realizada em bibliotecas digitais conhecidas e
conceituadas do meio científico: Medical Nema, Scielo, IEEE Xplore.
Pela dificuldade em encontrar exemplos de aplicações, com mesmo
objetivo final, já existentes hoje, foram realizadas algumas buscas no
Google Scholar, que reúne trabalhos acadêmicos de diversas grandes
universidades. Exclusivamente no caso de método de trabalho com
áudio no padrão DICOM, o site oficial do padrão foi consultado, e não
houve necessidade de consultar bibliotecas digitais científicas.
Houveram alguns artigos com acesso restringido ou que não estavam
completamente publicados nas bibliotecas, mas que serviram de base
para identificar alguns dados relevantes para o trabalho. Cada caso
especial é relatado a seguir, para maior transparência do processo.
2.2 PADRÃO DICOM PARA ARQUIVOS DE ÁUDIO
A busca foi realizada no site oficial do padrão DICOM e no
Google Scholar, onde foram buscadas palavras-chave relacionadas ao
escopo do trabalho. Como o padrão DICOM é um padrão de arquivos e
21
definição de protocolos de comunicação, não foram necessárias
restrições de plataforma, busca mais avançadas sobre o uso do padrão
em sistemas móveis ou, mais especificamente, no iOS. O objetivo era
buscar um modo de utilizar o padrão DICOM em arquivos de áudio.
Por estar no site oficial DICOM a busca já estava bastante
restritiva e pôde ser realizada de forma mais direta, através da seguinte
Search String: audio OR waveform OR mpeg
Tabela 1: Strings buscadas por padrão DICOM para arquivos de áudio
Medical Nema
Google Scholar
audio OR waveform OR mpeg
(audio OR waveform OR mpeg) AND DICOM
AND mobile
2.2.1 Realização da busca
A busca foi realizada em outubro de 2013 e obteve um total de
670 resultados. Muitos deles, no entanto, eram repetições, muitos outros
irrelevantes para o objetivo do trabalho e o escopo a ser trabalhado.
Alguns refinamentos na busca foram realizados, como limitar à busca
aos títulos dos artigos. Dois artigos, no entanto, foram analisados mais a
fundo para avaliar a relevância para o presente trabalho.
2.2.2 Artigos analisados
A seguir os artigos encontrados mais relevantes são analisados,
bem como é exposta a importância de cada um para a realização desse
trabalho ou como cada um ajudou em algum esclarecimento desejado.
2.2.2.1 Supplement 30: Waveform Interchange
Esse artigo é da documentação oficial DICOM e descreve as
definições de objetos utilizados para diversos tipos de exames que
utilizam waveform para armazenamento de dados digital. Estão
descritas diversas propriedades, referências, informativos e estruturas
utilizadas na composição de elementos DICOM Waveform. São
22
definidos padrões de desenvolvimento, isto é, descrição de modelorelação a ser utilizado no uso desse padrão.
São detalhados padrões e sintaxes de transferência de dados
waveform para algumas arquiteturas de processadores e recomendações
de encapsulamento de dados, modelos de garantia de sincronização e
harmonização de dados.
2.2.2.2 DICOM Waveform Generator
Esse artigo descreve a criação de um arquivo padrão DICOM
Waveform através de um stream de arquivo de texto. Isso é bastante
interessante para transferência de arquivo pela rede, uma vez que o dado
deve ser serializado para ser transferido entre dois pontos de rede.
O trabalho é um excelente esclarecedor de como o processo de
envio do áudio do laudo ditado ao STT, através do aplicativo a ser
desenvolvido nesse trabalho, funcionará. Além de esclarecer dados
bastante técnicos e importantes, como as tags DICOM utilizadas no
padrão DICOM Waveform, bem como explicação de como gerar um
waveform a partir de uma entrada de stream de texto.
Tabela 2: tags obrigatórias em um arquivo no padrão DICOM waveform
Tag Number
(0002,xxxx)
(0008,xxxx)
(0010,xxxx)
(0018,xxxx)
(0020,xxxx)
(003a,xxxx)
(0040,xxxx)
(5400,xxxx)
Tag Name
Tag de meta-grupo de arquivo
Tag de identificação
Tag de informação do paciente
Tag de aquisição de propriedade
Tag de relação de estudo
Tag de propriedades waveform
Tag de procedimento
Tag de dados waveform
O trabalho analisado também foi útil para compreender melhor
como são gerados os arquivos em padrão DICOM, como mostrado a
seguir.
23
Figura 6: formato de arquivo DICOM
A figura acima mostra como o é formado um arquivo DICOM
(extensão .dcm). Cada arquivo .dcm inicia com um cabeçalho de 128
bytes com valor 0x00, se seguido pelo prefixo de 4 bytes “DICM” como
valor. Cada elemento de dado (Data Element) consiste em um valor de
tag, um código de representação de valor – value representation (VR) -,
comprimento do valor e o campo valor. A estrutura desse elemento de
dado pode ser conferido na figura a seguir.
24
Figura 7: estrutura de elemento de dados DICOM
2.3 GRAVADORES DE ÁUDIO NO PADRÃO DICOM PARA
DISPOSITIVOS MÓVEIS
A busca foi realizada no Google Scholar, onde foram buscadas
palavras-chave generalistas e específicas ao escopo do trabalho. Como o
padrão DICOM é um padrão de arquivos e definição de protocolos de
comunicação, não foram feitas restrições de plataforma. O objetivo da
busca era encontrar quaisquer artigos que descrevessem sistemas com
implementação de uma aplicação minimamente semelhante à aplicação
a ser desenvolvida.
Como o intuito era conseguir registros da existência de
aplicações com mesmo objetivo final que o desse trabalho, os termos
buscados foram generalistas. Assim, eis a composição das Search
Strings:
1. DICOM AND waveform AND mobile
2. DICOM AND mobile
3. DICOM AND medical AND report AND audio AND mobile
4. DICOM AND medical AND report AND waveform AND mobile
5. medical AND report AND mobile AND audio
25
2.3.1 Realização da busca
As buscas foram realizadas entre outubro e novembro de 2013 e
obteve milhares de resultados. Com refinamento das buscas, limitações
por palavras exclusivamente no título, entre outros, ficou evidente que
não há registro de algum sistema de laudo médico ditado via áudio, para
dispositivos móveis. O mais próximo disso encontrado foi justamente o
sistema disponível hoje para médicos do STT: laudo ditado através de
um software para PC, utilizado com um gravador específico e que segue
alguns padrões.
Na busca por uma ferramenta não documentada via artigos, ou,
ao menos não registrada nas principais bibliotecas digitais, foi realizada
busca em buscador de conteúdo genérico: Google Search, pelas mesmas
Seach Strings. Nenhum resultado relevante foi encontrado, da mesma
forma.
26
3 DESENVOLVIMENTO
O desenvolvimento do aplicativo foi realizado inteiramente com
o software de desenvolvimento XCode, disponível para sistema
operacional Mac OS X. O aplicativo foi planejado para suportar iPhone
com versão do sistema operacional iOS 6 e superiores, uma vez que
ainda há um número significativo de usuários que não atualizaram mais
o sistema – hoje disponível na versão 7.
O planejamento da produção do aplicativo iniciou com
discussões com a equipe hoje responsável pela manutenção do STT, os
quais têm contato constante e direto com médicos usuários do sistema e
usuários potenciais da ferramenta desenvolvida.
3.1 INTERAÇÃO COM O APLICATIVO
O aplicativo foi desenvolvido com foco principalmente na
facilidade, agilidade e confiabilidade. Foi projetado para ser intuitivo,
ter uma interface de interação amigável, facilmente compreensível para
usuários com pouca familiaridade com a tecnologia onde o aplicativo
será aplicado – aparelhos iPhone. A interface leva em consideração, no
entanto, os costumes já obtidos pelo uso do sistema operacional em
questão, ou seja, segue padrões impostos e recomendações de
desenvolvimento de interface feitas pela Apple, empresa que
desenvolve o sistema operacional do dispositivo.
A aplicação foi projetada para ser confiável, passar o sentimento
de confiança e de que as tarefas estão sendo realizadas de acordo com o
esperado. Isso implica em tratar as mais variadas exceções e problemas
que possam ocorrer durante todo o processo. Exemplo disso é uma falha
na conexão com a rede durante o processo de envio da gravação do
laudo. A aplicação tem inteligência o bastante para tentar reenviar um
pacote corrompido por conta de uma falha de comunicação com a
internet, por exemplo.
Os alertas de andamento do processo e avisos seguem sempre as
diretivas de interação com usuário, estabelecidas pela Apple.
Especialmente no que diz respeito ao tratamento de tarefas prolongadas,
27
onde a tela do usuário não pode ficar impedida de receber interações,
por exemplo. Essas diretivas são melhor abordadas a seguir.
A interação do processo de submissão como um todo é bastante
parecida em qualquer aparelho com o qual o médico deseje submeter o
laudo, porém até chegar ao processo de gravação, efetivamente, há
algumas diferenças conforme o aparelho e aplicação utilizados.
3.2 INTERAÇÃO VIA SMARTPHONE
A seguir será apresentada a interação pelo iPhone – smartphone
que roda o sistema operacional iOS – tanto a proposta inicial, quanto a
interação implementada, após diversas discussões com os envolvidos no
desenvolvimento do STT hoje.
O protótipo inicial do aplicativo segue fielmente as propostas
levantados na descrição dos cenários, no item 1.3 (Cenários
identificados) do presente trabalho.
3.2.1 Protótipo inicial
No smartphone – iPhone – não há aplicação desenvolvida para
visualização de imagens de exames submetidos ao STT. Após a
autenticação com o STT, o médico requisita ao sistema dados do exame
que receberá o laudo a ser gravado. Há um botão para busca desses
dados. A seguir é apresentado o diagrama de sequência da interação
médico laudador com o aplicativo, conforme prototipação inicial (Fig.
8).
28
Figura 8: Diagrama de sequência do aplicativo
É exibida uma lista de exames – a mesma lista de exames sem
laudo e visíveis ao médico, disponíveis via web através STT – onde o
médico deve selecionar um dos itens. São mostradas informações do
29
exame para evitar confusão durante a seleção. As informações exibidas
nessa lista são: nome do paciente e modalidade do exame.
Após a seleção de um dos exames na lista, detalhes mais
completos serão exibidos para que o médico possa ter certeza de que
selecionou o exame correto. Confirmada a seleção, o laudador pode
seguir para a o processo de submissão do laudo ditado.
Na tela de gravação o médico pode realizar a gravação do laudo
ou utilizar um arquivo de áudio, salvo no dispositivo, previamente
gravado pela aplicação. Nessa mesma tela há um botão para
iniciar/parar a gravação, bem como informação do tempo de gravação já
corrido, para controle do médico.
Após a gravação ser realizada, o arquivo é salvo no diretório da
aplicação para poder ser consultado futuramente. O médico segue,
então, para a tela de confirmação de arquivo.
Ao selecionar a opção de utilizar um arquivo previamente salvo,
é exibida a tela de navegação da biblioteca de gravações realizadas. Ao
selecionar um arquivo, o usuário segue para a tela de confirmação de
arquivo.
Na tela de confirmação de arquivo são exibidos dados da
gravação, bem como alguns detalhes do exame a receber o laudo, para
uma segunda confirmação pelo profissional. Aqui é possível ouvir a
gravação a ser submetida, conferir seu tempo de duração, tamanho do
arquivo, entre outros. Ao confirmar o arquivo, é iniciado o processo de
envio do exame ao STT. O usuário é redirecionado par a tela de seleção
de exames, para que possa iniciar o processo com outro exame.
Durante o processo de envio, a aplicação não tem sua tela travada
de interações, isto é, é possível continuar executando todas as tarefas no
aparelho normalmente. Um serviço em segundo plano é responsável
pela conversão para o padrão DICOM e envio do arquivo. Qualquer
problema crítico e que exija atenção do médico deverá ser prontamente
manifestado e são dadas as devidas orientações ao profissional de quais
opções ele tem para contornar o problema. Há uma lista de envios, com
histórico de envios, envios em curso e arquivos na fila de envio, caso
um segundo laudo seja submetido, enquanto um primeiro laudo não
concluiu seu processo de envio.
30
Após a conclusão do envio do laudo ditado ao STT, o usuário é
notificado através de uma notificação do sistema e tem sua lista de
envios atualizada, bem como seu histórico de laudos submetidos através
do aplicativo.
3.2.2 Adaptações do protótipo inicial
A prototipação apresentada nos cenários e casos de uso expostos
no capítulo anterior do presente trabalho foi avaliada e discutida para
ser adaptada à realidade de uso e às necessidades existentes no sistema.
Algumas adaptações que se mostraram necessárias são referentes
à estrutura atual do sistema STT, e foram incorporadas na aplicação. A
seguir serão apresentadas as adaptações realizadas com detalhes.
3.2.2.1 Login automático
O login (autenticação no sistema) automático foi removido da
aplicação por segurança. É comum de aplicação de celular armazenarem
dados de autenticação (usuário e senha, normalmente) pois celulares são
de uso muito pessoal, além de ser mais fácil e cômodo não precisar
entrar com dados de autenticação a cada vez que se usa uma aplicação.
Hoje, no STT, o médico não tem opção de realiza login
automático por questão de segurança. É um sistema com informações
críticas, portanto o login deve ser efetuado a toda vez que o médico
encerra sua sessão no sistema.
Seguindo a mesma lógica, o aplicativo, apesar de não ser
convencional, não tem a opção de realizar login automático. A cada
inicialização da aplicação o médico deve entrar com seus dados de
autenticação.
Essa medida visou eliminar a possibilidade de alguém não
autorizado ter acesso a dados críticos, em caso de perda ou desvio de
um aparelho de um profissional da saúde. A figura 9 mostra o protótipo
construído da tela de login.
31
Figura 9: Tela de login
3.2.2.2 Busca pelo exame
Devido ao tamanho reduzido da tela do iPhone, a usabilidade da
busca de exames se mostrou muito ruim. Ainda, o médico já teria que
buscar por um exame no sistema, através do computador ou iPad e teria
que buscar mais uma vez o exame do qual deseja emitir laudo no
celular.
Outro problema era a possibilidade de erro na busca pelo exame
no aparelho celular. Apesar de todas as informações disponíveis durante
o processo de emissão laudo, ainda poderia acontecer de o médico
selecionar um exame errado e enviar um laudo para um exame diferente
do desejado.
Foi decidido reestruturar a forma de armazenamento de
informação de qual exame está em laudo no sistema. Antes o STT
apenas armazenava que um determinado exame estava sendo laudado,
mas não armazenava informação clara de qual médico estava emitindo o
32
laudo. Com a adaptação realizada, o sistema armazena informação do
médico responsável pelo laudo em emissão.
No aplicativo, o médico precisa pressionar o botão de busca de
laudo, então o aplicativo se comunica com o STT e exibe o laudo que o
médico está emitindo. Isso elimina a necessidade de busca manual pelo
exame que está sendo visualizado no desktop, por exemplo. Ainda
elimina a possibilidade de seleção incorreta do exame a receber o laudo.
Ainda com a segurança de que o médico estará emitindo o laudo
para o exame correto, dados relevantes para a identificação do exame
estão visíveis durante todo o fluxo do aplicativo. A figura 10 mostra a
tela de busca de laudo em emissão, iniciado através do STT como o
médico já está acostumado hoje.
Figura 10: Tela de busca de laudo em emissão
33
3.2.2.3 Manutenção de sessão do usuário
O STT utiliza recursos para garantir que um laudo iniciado não
seja abandonado no meio da emissão e nunca mais realizado. Para isso,
o sistema inicia um contador de tempo quando a emissão de um laudo é
iniciada. Se o usuário não realizar nenhuma interação com o sistema
num intervalo de 30 minutos, o sistema assume que o laudo não será
mais emitido. O laudo, então, é recolocado na fila de exames sem laudo,
para aguardar a atenção de um médico – possivelmente o mesmo.
Essa duração era ignorada pela aplicação, que considerava que o
médico teria quanto tempo quisesse para encerrar a gravação e emissão
de laudo. O médico, no entanto, pode estar com problemas de
comunicação com o servidor, problemas de conexão com a internet, etc.
Isso poderia acarretar no cancelamento da emissão de um laudo, quando
médico estivesse realizando o envio do arquivo de laudo para o
servidor.
A solução adotada foi a interação a cada 5 minutos entre o
aplicativo e o servidor do STT para atualização o status da emissão de
laudo e o sistema não cancelar o laudo. Portanto, a menos que o
profissional esteja com problemas muito graves de conectividade, a
ponto de que provavelmente não conseguirá realizar o envio do arquivo
de laudo, o sistema saberá que a sessão do usuário ainda é válida, apesar
de estar sendo utilizada em outro dispositivo.
Esse problema de o sistema exigir uma interação dentro do
intervalo de trinta minutos também invalidou a possibilidade de enviar
um arquivo previamente gravado pelo usuário no aparelho. Exames
recebem laudo rapidamente no STT, portanto permitir o usuário fazer
uma gravação, mas demorar para utilizá-la como laudo de um exame
não se mostrou pertinente.
3.2.2.4 Dados de identificação do exame
Não é necessário exibir todos os dados do exame para sua
identificação. Em discussão com a equipe desenvolvedora do STT foi
constatado que apenas os seguintes dados são suficientes para confirmar
34
qual exame receberá o laudo em gravação: nome do paciente,
modalidade do exame e instituição de saúde onde o exame foi emitido.
A seguir são apresentadas as telas de gravação de laudo (Fig. 11) e
reprodução da gravação (Fig. 12).
Figura 11: Tela de gravação do laudo
Pode-se notar a diferença clara entre o protótipo inicial e a
implementação realizada. Com menos informações a tela ficou muito
mais limpa, com o que importa (gravação ou reprodução do áudio) em
maior destaque.
35
Figura 12: Tela de reprodução da gravação
3.2.2.4 Envio de arquivo de laudo em plano de fundo
Como dito anteriormente, há bastante pressa no recebimento de
um laudo de exame, portanto o médico quer se assegurar de que o laudo
realizado esteja pronto para ser avaliado quando encerrar o processo.
Sendo assim, o envio do arquivo de laudo em plano de fundo, que
permitiria ao médico continuar interagindo com a aplicação durante o
processo, se mostrou inaceitável.
O médico, ao mandar a aplicação enviar o arquivo, deverá
aguardar a confirmação do envio do arquivo pelo sistema. Isso evita que
o médico tenha que ficar gerenciando sua lista de arquivos pendentes
para envio e o deixa seguro quanto à confirmação de envio do laudo.
Quando o profissional decidir iniciar um novo laudo, terá
garantia de que o laudo anterior está assegurado no sistema, salvo e
pronto para avaliação.
36
3.3 IMPLEMENTAÇÃO
O aplicativo foi desenvolvido em paralelo com desenvolvimento
das adaptações supracitadas no servidor do STT pela equipe que
mantém o sistema. Foram realizadas reuniões constantes de atualização
de status e rediscussão de melhorias.
O software foi desenvolvido utilizando orientação a objetos, com
padrão MVC e desenvolvimento top-down, isto é, iniciou-se o
desenvolvimento com prototipação das interfaces de usuário, com muito
foco em usabilidade. A aceitação da implementação de funcionalidades
ocorreu com uso de BDD (Behavior Driven Development), técnica de
desenvolvimento ágil que estabelece padrões para aceitação de tarefas
quando seu comportamento está de acordo com o esperado. A tabela a
seguir mostra os comportamentos oferecidos pelo aplicativo.
Tabela 3: Comportamentos atendidos pela aplicação
Comportamento
Usuário não pode
fazer login sem uma
conta criada
Usuário não pode
fazer login com dados
de
autenticação
inválidos
Usuário
pode
se
autenticar no sistema
Usuário pode encerrar
a sessão
Usuário não pode
iniciar a gravação de
um laudo sem ter
iniciado
o
laudo
através do STT
Usuário pode buscar
Pré-requisito
Usuário entra com
dados de autenticação
inexistentes
Usuário entra com
nome de usuário ou
senha incorretos para
autenticação
Usuário entra com
nome de usuário e
senha corretos para
autenticação
Usuário toca no botão
“Sair” na tela de
busca de laudo
Usuário toca no botão
de busca de laudo do
aplicativo antes de
iniciar um laudo
através do STT
Usuário inicia laudo
Consequência
Exibe mensagem de
erro ao tentar efetuar
login
Exibe mensagem de
erro ao tentar efetuar
login
Segue para tela de
busca de laudo
Usuário perde sessão
e segue para tela de
login, com campos
em branco
Exibe mensagem de
erro, que indica que
não há exame em
laudo para aquele
usuário
Segue para tela de
37
por laudo em emissão
após iniciado o laudo
através do STT
Usuário pode desistir
da gravação do laudo
Usuário pode iniciar
gravação de um laudo
através do STT
gravação
ditado
Usuário toca no botão
“Voltar” na tela de
gravação
Usuário toca no botão
para iniciar gravação
Segue para tela de
busca de laudo
Usuário pode pausar a
gravação
Usuário toca no botão
de gravação durante a
gravação
Usuário
pode
continuar a gravação
Usuário toca no botão
de gravação, enquanto
gravador está pausado
Usuário pode conferir
dados do exame a
receber laudo
Usuário está na tela
de gravação
Usuário não pode
seguir
para
reprodução enquanto
o
gravador
está
gravando
Usuário está na tela
de gravação e o
gravador está ativado
Usuário pode seguir
para reprodução e
confirmação
da
gravação
Usuário pode voltar
para regravar o laudo
Usuário
realizou
alguma gravação e o
gravador está pausado
Usuário
pode
Usuário toca no botão
“Voltar”, na tela de
reprodução
Gravação foi bem
de
laudo
Inicia o contador de
tempo do gravador;
inicia a gravação de
áudio
Pausa a gravação de
áudio;
pausa
o
contador de tempo do
gravador
Continua a gravar o
áudio; na gravação
final a pausa é
invisível; continua o
contador de tempo do
gravador do mesmo
instante em que havia
parado
Dados
de
identificação
do
exame são exibidos
na tela
Botão para avançar
para o próximo passo
deve
estar
desabilitado enquanto
o gravador estiver
gravando
Segue para tela de
reprodução de áudio
Retorna para tela de
gravação de laudo
Inicia reprodução do
38
reproduzir
gravado
o
áudio
concluída e arquivo
de áudio está salvo
Usuário pode pausar
reprodução de áudio
Usuário toca no botão
de pause enquanto o
áudio está sendo
reproduzido
Usuário não pode
enviar
arquivo
enquanto ele está
sendo reproduzido
Usuário
pode
“navegar”
pela
reprodução
do
arquivo
em
reprodução
Usuário está na tela
de reprodução de
áudio e o player está
tocando
Usuário arrasta o
indicador da barra de
progresso
de
reprodução
Usuário pode enviar o
arquivo de áudio
gravado
Usuário toca no botão
“Enviar” e player não
está ativo
áudio;
iniciam
contadores de tempo
de
reprodução
e
tempo restante; barra
de
progresso
de
reprodução
exibe
proporção de tempo
reproduzido
Player de áudio pausa
a
reprodução;
contadores de tempo
de
reprodução
e
tempo restante param;
barra de progresso de
reprodução para
Botão de “Enviar”
deve estar desativado
enquanto o player está
ativo
Player passa a tocar a
partir do ponto em
que o usuário “solta”
o
indicador;
contadores de tempo
são atualizados
Inicia a conversão do
arquivo de gravação e
ambos os arquivos
(original
e
convertido)
são
enviados
para
o
servidor
3.4 FLUXO DE EMISSÃO DE LAUDO
O fluxo de emissão de um laudo (Fig. 13) agora se dá através das
seguintes etapas:
39
1. Iniciar laudo: o médico laudador acessa o sistema Web do
STT, se autentica e segue para a área de emissão de laudo. O processo é
idêntico ao processo existente hoje, o médico não tem nenhuma
novidade a aprender até aqui. A diferença é que o sistema agora
armazena em seu banco de dados a relação entre o médico laudador e o
laudo que ele iniciou.
2. Iniciar emissão de laudo ditado: o profissional apanha seu
iPhone (ou qualquer dispositivo iOS) e inicia o aplicativo desenvolvido
nesse trabalho. Realiza, então, a autenticação com o sistema (mesma
autenticação que ele realizou no STT pelo navegador do computador,
por exemplo. Será apresentada a tela de busca de exame em laudo
apresentada acima (Fig. 10). O STT envia dados do exame que este
profissional está emitindo.
3. Gravação do laudo: ao receber os dados do exame, o médico é
redirecionado para a tela de gravação de laudo. Ao realizar a gravação o
médico pode seguir para o próximo passo – reprodução da gravação
realizada. Ao confirmar a gravação, o médico pode enviar o arquivo
gerado para o STT.
4. Transcrição do exame: um membro de uma equipe digitadora
acessa a gravação enviada e transcreve os dados do laudo para o
sistema. Preenche toda a ficha de laudo que o médico iria preencher. O
laudo se torna temporário e aguarda aprovação do médico. Só o próprio
médico que enviou o laudo pode confirmar a autenticidade das
informações inseridas no sistema.
5. Publicação: a partir daqui o fluxo volta ao já utilizado hoje,
isto é, o laudo entra em estado de “laudo temporário” e aguarda ser
verificado e publicado.
40
Figura 13: Fluxo (simplificado) de emissão de laudo ditado utilizando aplicação
3.5 FORMATO DE ARQUIVO DE GRAVAÇÃO
O framework de desenvolvimento para iOS permite salvar
gravações de áudio em diversos formatos, com várias configurações de
qualidade, taxa de compressão, quantidade de canais de saída, etc. Com
tantas opções disponíveis, algumas pesquisas foram realizadas para
garantir que a gravação a ser enviada como laudo ditado tenha
qualidade aceitável, mas que o arquivo não seja tão grande.
É importante também considerar que o STT é um sistema web,
visualizado principalmente em computadores pessoais; portanto, a
gravação precisa ser facilmente reproduzida através de um navegador
convencional. O STT dá suporte oficialmente para navegadores Google
Chrome e Mozilla Firefox. É muito desejável o arquivo de áudio
produzido pelo aplicativo desenvolvido nesse trabalho seja facilmente
reproduzido nestes navegadores. Foi buscado algum formato de arquivo
de áudio compatível nativamente com ambos, ou que não exigisse que o
usuário do sistema adquirisse algum plugin específico.
41
Dados estes requisitos, algumas pesquisas foram realizadas por
artigos expondo os melhores formatos para gravação de voz, que
garantam qualidade e assegurem uma boa compressão, para manter o
arquivo razoavelmente pequeno.
Dentre os formatos mais comuns, três foram considerados devido
a compatibilidade com ambos os navegadores suportados oficialmente
pelo STT: MP3, Ogg e Wav. O primeiro, no entanto, não é suportado na
gravação de áudio do iOS, por ser um formato fechado e não haver
acordo firmado com a desenvolvedora do sistema – a Apple.
Algumas comparações foram buscadas entre arquivos Ogg e
Wav, quanto à qualidade e taxa de compressão realizada pelo sistema
operacional do iPhone. Importante relembrar que, como dito no capítulo
anterior, o aplicativo se propõe a enviar arquivo de gravação em
formato DICOM, além do formato original de gravação.
O formato Ogg apresenta uma ótima qualidade de áudio e boa
taxa de compressão. Consegue diferenciar canais de áudio muito bem e
apresenta som cristalino em reprodução estéreo. Tem algumas
limitações de perda de dados em frequências a partir de 16kHz com
compressão (Carlacci, 2002). Essa perda pode ser observada na figura
14 a seguir.
Figura 14: MP3 e Ogg perdem dados após compressão de áudio com
frequência de 16Khz
Em altas frequências apresenta áudio quase idêntico ao áudio
original (Carlacci, 2002). Frequências altas são comuns em gravações
de voz, portanto é maior foco da busca por qualidade em formato de
áudio definido. A figura 15 exibe ondas de uma amostra de áudio Ogg
comparadas com ondas originais do áudio (Wav).
42
Figura 15: Ogg apresenta um som cristalino em frequências altas, com
waveform muito próxima à original
Para converter um arquivo de áudio para o formato DICOM é
necessário utilizar o waveform do arquivo. Isso significa que ainda que
se opte por gravar áudio em Ogg, é necessário trabalhar com a
waveform original do áudio para trabalhar com DICOM. Nesse sentido
o formato Wav se destaca bastante, pois tendo o waveform original do
arquivo, sem “retoques” por conta de conversão, permite manipular com
mais liberdade o áudio. Numa possível futura conversão, por exemplo,
perderiam-se muito mais dados relevantes utilizando Ogg do que
utilizando Wav.
Ainda, para utilizar o formato Ogg teria que sempre converter o
arquivo para o formato Wav antes de produzir o arquivo DICOM a ser
enviado para o servidor. Isso se mostra uma problemática quando se
pensa em manutenção do sistema como um todo.
Por exemplo, se no futuro uma aplicação semelhante fosse
desenvolvida para outra plataforma móvel, como Android ou Windows
Phone, teria que ser implementada a conversão de Ogg para Wav para o
novo sistema operacional a ser suportado.
Tendo em vista esses pontos o formato Wav se mostrou muito
vantajoso se comparado com o formato Ogg. O arquivo é facilmente
reproduzido nos navegadores suportados pelo sistema, que utiliza
HTML 5 – que suporta reprodução de áudio com uso do elemento
HTML “audio”.
43
3.5.1 Gravação em formato DICOM
Um sistema, para ser considerado PACS deve tratar apenas de
arquivos DICOM. Só recebe e disponibiliza para acesso arquivos neste
mesmo formato. Hoje o Sistema Catarinense de Telemedicina e
Telessaúde caminha para se tornar um sistema PACS, onde novas
funcionalidades inseridas no sistema devem respeitar a regra de lidar
com arquivos DICOM (Huang, 2010).
O intuito do aplicativo é ser utilizado a longo prazo e estar
adaptado às regras impostas pelos mantenedores do STT; logo, o
arquivo de áudio deve ser disponibilizado em formato DICOM. A
aplicação desenvolvida, então, envia dois arquivos após a conclusão do
processo de gravação de laudo: um arquivo no formato Wav, pronto
para fácil uso pelo sistema como é hoje e fácil para possivelmente
reproduzir o áudio em um navegador; e um arquivo em formato
DICOM, que armazena o waveform “cru” do arquivo de áudio e,
portanto, respeita a regra básica de um sistema PACS.
Esse foi um dos maiores desafios do presente trabalho, pela
ausência de uma ferramenta com a mesma capacidade hoje. Foram
realizadas diversas pesquisas, mas nenhuma ferramenta de gravação de
áudio para dispositivo móvel – no caso, smartphones – foi encontrada. É
possível afirmar que o software desenvolvido é o primeiro aplicativo
móvel a gravar áudio em formato DICOM e submetê-lo a um sistema de
telemedicina.
44
4 Conclusão
Esse trabalho teve como objetivo principal aperfeiçoar o processo
de emissão de laudo ditado disponível hoje no STT e disponibilizar a
funcionalidade para usuários de iPhone, maioria dos médicos que
compõem o corpo de profissionais da saúde do sistema de Telemedicina
de Santa Catarina. Preocupações constantes eram com a usabilidade do
sistema, que deveria ser bastante intuitivo e facilmente adaptável à
rotina de uso do sistema por um médico que emite laudos.
Por ser uma aplicação móvel, é importante que funcionalidades
relevantes propiciem resultados esperados e satisfatórios com pouca
interação do usuário, portanto a aplicação foi desenvolvida da forma
mais “enxuta” possível. O fluxo de uso da aplicação se encaixa bem no
costumeiro uso atual do sistema, pois o médico inicia o processo de
laudo da mesma forma que está acostumado, basicamente.
Com perspectiva de uso prolongado da plataforma, o software
desenvolvido consegue se comunicar com um sistema PACS, isto é,
consegue submeter um arquivo em formato DICOM a ser consumido
através do sistema acessado por outro meio (como um navegador web,
por exemplo).
Espera-se que o aplicativo resolva alguns problemas do processo
atual de emissão de laudo ditado, pois elimina o gravador
especificamente adquirido para este fim, não exige instalação de
software no PC do usuário e elimina chances de associação de um laudo
ditado a um exame indesejado.
Como trabalhos futuros sugere-se a implementação de um
aplicativo com mesma funcionalidade para outras plataformas móveis,
para garantir que todos os médicos emissores de laudo tenham acesso à
ferramenta. Outra sugestão seria o aperfeiçoamento do gravador de
áudio da aplicação, que hoje não permite edições no próprio dispositivo.
45
Referências
ANDRADE, R. Um modelo para recuperação de comunicação do
conhecimento em documentos médicos. Tese (Doutorado), 2011.
CARLACCI, A. A. F., Ogg Vorbis and MP3 Audio Stream
charecterization. University of Alberta, 2002.
CLUNIE, D. A. DICOM Standart. 2008. Disponível em:
<http://www.dclunie.com/dicom-status/status.html>. Acesso em: 23 set
2013.
DICOM Standards Committee, Working Group 1 – Cardiac and
Vascular Information. Supplement 30: Waveform Interchange, 1999.
Disponível em: http://medical.nema.org/Dicom/supps/sup30_lb.pdf.
Acesso em: 23 nov 2013.
GOPAKUMAR, B., WANG, S., KHASAWNEH, M. T., CUMMINGS,
D., SRIHARI, K. Reengineering Radiology Transcription Process
through Voice Recognition. IEEE IEEM, 2008.
HUANG, H. Enterprise PACS and Imaging distribution – Basic
Principles and Applications. Wiley-Blackwell, 2010. 2ª edição, rev. p.
HUANG, H. PACS and image Informatics. Computerized Medical
Imaging and Graphics, v. 27, n. 2-3, p. 241-253, 2003.
HULME, A. K., TRAXLER, John. Mobile Learning: a handbook for
educators and trainers. Routledge, 2005. p. 45-54. Open and flexible
learning series.
KRISTIANTO, B., WEN-YAW, C., YUH-SHOW, T. DICOM
Waveform
Generator,
2008.
Disponível
em:
<http://libir.tmu.edu.tw/bitstream/987654321/21661/1/B09.pdf>.
Acesso em: 22 nov 2013.
46
LIU, C., ZHU, Q., HOLROYD, K. A., SENG, E. K. Status and trends
of mobile-health applications for iOS devices: A developer’s
perspective. Journal of Systems and Software, v. 84, p. 2022-2033,
2011.
MCNEILL, K.; WEINSTEIN, R.; HOLCOMB, M. Arizona
telemedicine program. Journal of the American Medical Informatics
Association, v. 5, n. 5, p. 441, 1998.
RUBY, C. Transcrição automática de ditados técnicos. Tese (Mestrado),
2012.
SCHUMACHER, R. M., BERKOWITZ, L., ABRAMSON, P.,
LIEBOVITZ, D. Eletronic Health Records: Physician’s Perspective on
Usability. Proceedings of the Human Factors and Ergonomics Society
Annual Meeting September v. 54, n. 12, p. 816-820, 2010.