UNIVERSIDADE FEDERAL DE SANTA CATARINADEPARTAMENTO DE INFORMÁTICA E ESTATÍSTICA

Desenvolvimento de um cliente DICOMpara ditado de laudo em iOS

JOÃO OLVI SIQUEROLLI NETO

Florianópolis2013

João Olvi Siquerolli Neto

DESENVOLVIMENTO DE UM CLIENTE DICOMPARA 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ópolis2013

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...........................................................................6

1.1 STT....................................................................................6

1.2 LAUDOS MÉDICOS.........................................................7

1.2.1 Laudo manuscrito........................................................8

1.2.2 Laudo ditado analógico...............................................8

1.2.3 Laudo ditado digital....................................................9

1.3 CENÁRIOS IDENTIFICADOS.......................................10

1.3.1 Cenário 1: gravação de laudos é realizada com um aparelho exclusivamente adquirido para isso................................11

1.3.2 Cenário 2: envio de laudo ditado é realizado através de um sistema web.............................................................................13

1.4 OBJETIVOS....................................................................14

1.4.1 Objetivo geral............................................................14

1.4.2 Objetivos específicos................................................15

1.4.3 Casos de uso..............................................................15

1.5 USABILIDADE...............................................................16

1.5.1 Usabilidade em dispositivos móveis.........................17

2 REVISÃO SISTEMÁTICA....................................................19

2.1 OBJETIVOS DA BUSCA................................................19

2.2 PADRÃO DICOM PARA ARQUIVOS DE ÁUDIO......19

2.2.1 Realização da busca..................................................20

2.2.2 Artigos analisados.....................................................20

2.3 GRAVADORES DE ÁUDIO NO PADRÃO DICOM PARA DISPOSITIVOS MÓVEIS....................................................23

2.3.1 Realização da busca..................................................24

3 DESENVOLVIMENTO..........................................................25

3.1 INTERAÇÃO COM O APLICATIVO............................25

3.2 INTERAÇÃO VIA SMARTPHONE...............................26

3.2.1 Protótipo inicial.........................................................26

3.2.2 Adaptações do protótipo inicial.................................29

3.3 IMPLEMENTAÇÃO.......................................................35

3.4 FLUXO PARA EMISSÃO DE LAUDO.........................37

3.5 FORMATO DE ARQUIVO DE GRAVAÇÃO...............38

3.5.1 Gravação em formato DICOM..................................41

4 Conclusão................................................................................43

Referências.................................................................................44

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

7

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

8

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

9

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).

10

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.

11

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).

12

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;

13

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.

14

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.

15

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

16

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

17

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.

18

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.

19

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.

20

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 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 áudioMedical Nema audio OR waveform OR mpegGoogle Scholar (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.

21

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 definidos padrões de desenvolvimento, isto é, descrição de modelo-relaçã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 waveformTag Number Tag Name(0002,xxxx) Tag de meta-grupo de arquivo(0008,xxxx) Tag de identificação(0010,xxxx) Tag de informação do paciente(0018,xxxx) Tag de aquisição de propriedade(0020,xxxx) Tag de relação de estudo(003a,xxxx) Tag de propriedades waveform(0040,xxxx) Tag de procedimento

22

(5400,xxxx) 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.

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.

23

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 mobile2. DICOM AND mobile3. DICOM AND medical AND report AND audio AND mobile4. DICOM AND medical AND report AND waveform AND mobile5. medical AND report AND mobile AND audio

24

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.

25

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.

26

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, 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).

27

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

28

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.

29

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.

30

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

31

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

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,

32

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 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).

33

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.

34

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.

35

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çãoComportamento Pré-requisito ConsequênciaUsuário não pode fazer login sem uma conta criada

Usuário entra com dados de autenticação inexistentes

Exibe mensagem de erro ao tentar efetuar login

Usuário não pode fazer login com dados de autenticação inválidos

Usuário entra com nome de usuário ou senha incorretos para autenticação

Exibe mensagem de erro ao tentar efetuar login

Usuário pode se autenticar no sistema

Usuário entra com nome de usuário e senha corretos para autenticação

Segue para tela de busca de laudo

Usuário pode encerrar a sessão

Usuário toca no botão “Sair” na tela de busca de laudo

Usuário perde sessão e segue para tela de login, com campos em branco

Usuário não pode iniciar a gravação de um laudo sem ter iniciado o laudo através do STT

Usuário toca no botão de busca de laudo do aplicativo antes de iniciar um laudo através do STT

Exibe mensagem de erro, que indica que não há exame em laudo para aquele usuário

36

Usuário pode buscar por laudo em emissão após iniciado o laudo através do STT

Usuário inicia laudo através do STT

Segue para tela de gravação de laudo ditado

Usuário pode desistir da gravação do laudo

Usuário toca no botão “Voltar” na tela de gravação

Segue para tela de busca de laudo

Usuário pode iniciar gravação de um laudo

Usuário toca no botão para iniciar gravação

Inicia o contador de tempo do gravador; inicia a gravação de áudio

Usuário pode pausar a gravação

Usuário toca no botão de gravação durante a gravação

Pausa a gravação de áudio; pausa o contador de tempo do gravador

Usuário pode continuar a gravação

Usuário toca no botão de gravação, enquanto gravador está pausado

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

Usuário pode conferir dados do exame a receber laudo

Usuário está na tela de gravação

Dados de identificação do exame são exibidos na tela

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

Botão para avançar para o próximo passo deve estar desabilitado enquanto o gravador estiver gravando

Usuário pode seguir para reprodução e confirmação da gravação

Usuário realizou alguma gravação e o gravador está pausado

Segue para tela de reprodução de áudio

Usuário pode voltar para regravar o laudo

Usuário toca no botão “Voltar”, na tela de reprodução

Retorna para tela de gravação de laudo

37

Usuário pode reproduzir o áudio gravado

Gravação foi bem concluída e arquivo de áudio está salvo

Inicia reprodução do áudio; iniciam contadores de tempo de reprodução e tempo restante; barra de progresso de reprodução exibe proporção de tempo reproduzido

Usuário pode pausar reprodução de áudio

Usuário toca no botão de pause enquanto o áudio está sendo 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

Usuário não pode enviar arquivo enquanto ele está sendo reproduzido

Usuário está na tela de reprodução de áudio e o player está tocando

Botão de “Enviar” deve estar desativado enquanto o player está ativo

Usuário pode “navegar” pela reprodução do arquivo em reprodução

Usuário arrasta o indicador da barra de progresso de reprodução

Player passa a tocar a partir do ponto em que o usuário “solta” o indicador; contadores de tempo são atualizados

Usuário pode enviar o arquivo de áudio gravado

Usuário toca no botão “Enviar” e player não está ativo

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:

38

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.

39

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.

40

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).

41

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”.

42

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.

43

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.

44

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.

45

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.

46