Faculdade de Engenharia da Universidade do Porto Mestrado ...mgi98020/mgi/BD/Trabalho_adad.pdf ·...

Faculdade de Engenharia da Universidade do

Porto

Mestrado em Gestão de Informação

BASE de DADOS

Trabalho prático realizado por

Fernando Luis Poças da Silva

Lisboa, Junho de 2002

____________Sistema informacional do Centro de Cirurgia Torácica – H.São João

2

Introdução

Este trabalho aborda o estudo, o levantamento das dificuldades e a implementação, de

parte do sistema de informatização do Centro de Cirurgia Torácia do Hospital de São

João do Porto. Este trabalho enquadra-se na opção 4 das opções apresentadas a estudo.

A crescente necessidade do Serviço de Cirurgia Torácica do Hospital de São João de

apresentar casos de estudo sobre a sua população, nomeadamente estudo sobre

determinadas técnicas cirúrgicas, estudo de quais as melhores técnicas em determinados

casos, quais as melhores valvulares, quais as que traduzem menores complicações pós-

operatório, quais as causa para a taxa de mortalidade, quais são os factores que influem

na mortalidade de determinado diagnóstico, e aparte do estudo cirúrgico temos ainda o

controlo administrativo do Centro dos quais se realça controlo de custos, facturação às

diversas entidades responsáveis com convenções com o Centro, controlo de exames, etc.

A modelação práctica que se apresenta no presente trabalho, contempla apenas a parte

da base de dados instalada, e que tem directamente a ver com a gestão administrativa,

nomeadamente a gestão de consultas, e toda a caracterização da entidade doente.

De realçar, que a base de dados instalada no centro desde 1992, e revista totalmente

recentemente, tem vindo a alimentar um conjunto de trabalhos, resultantes da

informação daí extraída, para publicação e apresentação em congressos. Os médicos do

Centro têm-se apercebido do grande potencial da informação contida nos dados, como

forma de conhecerem as reacções e resultados dos tratamentos aplicados. Os resultados

da análise destes dados são um instrumento que lhes permite entender como evolui a

situação do doente, como melhorar o nível de assistência, quais as melhores técnicas, e

outros estudos que se poderão efectuar.

Este relatório está organizado da seguinte forma: na Secção 2 introduz-se a fase de

levantamento das necessidades do SI – Sistema de Informação, quais os recursos

afectados ,tanto humanos como técnicos, as alterações ao serviço que a adopção de

novos métodos de trabalho trarão, possíveis pontos de conflito, quais os pontos fracos e

que beneficios o serviço terá com a implementação deste sistema, de realçar que dado o


3

carácter técnico deste relatório será uma secção sucinta. A Secção 3 tratará da criação

do modelo relacional que se traduzirá na modelação por objectos. A secção 4

representará algum do conhecimento que se poderá extraír do modelo, será constituído

por perguntas à base de dados e pela sua tradução em algebra relacional. Uma última

secção explorará a normalização da base de dados.

Secção 2

Antes de analisar a parte técnica da base de dados instalada no Centro convém dar uma

ideia de como o serviço se encontra organizado. Existe um Director Clinico que também

é Director Administrativos, o Centro presta serviço de consulta e serviço de cirurgia

cardiaca. Existem cerca de 15 cirurgiões e 2 cardiologistas que realizam os exames

cardiacos.

O anterior sistema informacional baseava-se em três computadores ligados em rede,

dois na mesma sala de informática e um na consulta, e ainda um PC na sala da prova de

esforço. Os PC’s na sala de informática tinham por missão registar o processo clinico

dos doentes operados no serviço, no entanto a triagem era feita de uma forma

desorganizada e pouco fiável, e sempre que se realizava um estudo, esses dados apenas

serviam para selecionar determinado número de doentes e depois era necessário retirar o

processo, rever os dados pelo médico e introduzir os dados correctos ou outros que se

achassem necessários numa base de dados à parte. Isto levava a uma duplicação de

informação.

O PC da Consulta servia para que se abrisse a ficha de um novo doente, os dados

pessoais, e inserção num campo que não foi criado para esse efeito, da data da próxima

consulta. Não era no entanto dados muito fiáveis, pois doentes que fossem particulares

não eram inseridos, não se sabia qual a entidade responsável, a quem o hospital teria de

facturar, todo o trabalho administrativo era controlado por fichas em papel. Fichas essas

que muitas vezes ficavam dentro do processo do doente, ou o médico esquecia-se de

preencher, ou o funcionário.

O PC da prova de esforço, continha informação muito importante para estudo do

Serviço, pois continha dados da prova de esforço e de exames de ecografia que serviam

de indicação e de diagnóstico para cerca de 80-90% dos doentes operados no serviço.


4

Este PC não tinha qualquer ligação em rede, e o programa que servia para registar estes

elementos, não se integrava no sistema da base da dados central.

As grandes mudanças implementadas pelo novo sistema informacional, foram:

1. A elaboração de protocolos de cirurgia únicos para três tipos de doentos,

representantes do universo de doentes operados, (Congénitos, Pulmonares, e

Torácicos adultos) – Existindo um caso à parte que são os transplantes.

A elaboração destes três protocolos estiveram a cargo de três cirurgiões

responsáveis por cada uma destas áreas, com o meu envolvimento directo. Estes

protocolos servirão de guia para a introdução dos dados na base de dados

directamente por duas operadoras.

Num futuro próximo, logo que haja rede de dados no hospital e PC’s, o

objectivo será instalar dois terminais à saída da sala do bloco e outros dois na

enfermaria, onde será introduzido directamente todo o processo pelos

perfusionistas, cirurgiões, anestesistas, e enfermeiros que acompanham o pós-

operatório até à data da alta. No entanto, e dado a adversidade que determinadas

entidades ainda tem aos PC’s optou-se por fazer esta mudança de forma suave.

2. Elaboração de um novo programa, que é um módulo do sistema informacional,

para o registos dos dados provenientes da prova de esforço e ecocardiograma.

Este módulo não foi necessário criar protocolo pois actualmente os dados estão a

ser inseridos à medida que o exame é realizado. A grande mudança verificou-se

em termos de referenciação dos doentes, pois os doentes deste serviço de exame

passaram a ser a entidade que reside na base de dados do Serviço.

3. Inserção de novos campos para o sector administrativo, nomeadamente através

da inserção on- line de todos os doentes que se dirigem ao serviço. Desta forma o

sector administrativo poderá ver qual a entidade responsável por um

determinado doente, que tipo de assistência requereu em determinado dia,

marcação e histórico de consultas e exames, os doentes com exame marcado

poderão ser visualizados na PC da prova de esforço e eco, qual o regime de taxa

moderadora que esse doente se enquadra.


5

4. A eficiência e a eficácia em termos de trabalhos realizados saiu reforçada,

implementação da apresentação de casos de estudo por parte dos cirurgiões

tornou-se práctica corrente, a fiabilidade nos dados contidos pelo sistema

informático saiu muito melhorada. O sistema foi desenhado tendo em atenção os

trabalhos (ideia que serviu de base à informatização do Centro) possibilitando a

informação na zona da Consulta, por activação de alertas para determinados

doentes que estão a ser seguidos nos trabalhos de follow-up por forma a

contactar o médico que tenha interesse nesse doente.

No entanto, existiram bastantes dificuldades, nomeadamente, sendo um serviço onde a

antiguidade é um posto, e em que desde que as pessoas entraram para o serviço sempre

fizeram os mesmos deveres as mesmas obrigações, as pessoas sentiram-se ameaçadas.

Existiu no inicio bastante agressividade em relação à mudança, principalmente e

únicamente no sector administrativo, observou-se mesmo um certo alheamento. As

pessoas desse sector não se sentiam motivadas para trabalhar com o computador, não

viam que grandes vantagens podiam tirar, no entanto este tipo de comportamento já

tinha sido previsto e portanto depois de uma primeira semana difícil o sistema começou

a ser usado normalmente, com mais ou menos dificuldade por parte de alguns

utilizadores.

Existe ainda um problema que teve que ser abordado de uma maneira directa com os

utilizadores, que prende-se com a informação manuseada pelos utilizadores. O antigo

sistema permitia que todos os utilizadores tivessem acesso aos dados e os

manipulassem. Actualmente os utilizadores só tem acesso aos dados que lhes dizem

respeito. Esta situação originou um certo desconforto entre os utilizadores no entanto e

explicando que dada a natureza sensível dos dados, é necessário implementar medidas

de segurança, atendendo à protecção dos dados pessoais. Esta validação é realizada pelo

programa consultando as permissões que cada funcionário tem quando acede ao

programa, a cada modulo do programa foi atribuído um número binário permitindo

desta forma verificar se determinado operador possui ou não permissões para aceder aos

dados.


6

Seguidamente passa-se a descrever parte do sistema informacional implementado,

contendo a entidade doente, as consultas, o registo da prova do eco e ainda o registo no

histórico do doente.

Secção 3

O modelo relacional que a seguir se apresenta tem por base apenas uma parte do sistema

informacional, parte das relações com outras entidades foram suprimidas por forma a

evitar a saturação do modelo e a descrição exaustiva de cada uma das entidades

envolvidas.

Caracterização de:

• Doente - Código de doente, nº hospitalar, nome do doente, data de nascimento,

Estado Civil (Estado), Profissão, morada, código postal, localidade, telefone,

nome do pai, nome da mãe, Entidade responsável (entidade_responsável), nº

de beneficiário, cirurgião (nome do médico), sexo, nº de utente, médico

assistente, localidade do médico assistente, observações, {regime da taxa

moderadora (isento, normal, especial, particular, motivo de isenção (motivo de

isenção)}, .

• Consultas – Código do doente, data da consulta, hora da consulta, médico

(nome do médico), consulta, exames, prova de esforço, eco, ecg, holter, provas

funcionais respiratórias.

• Eco – nº de exame, processo, ano do processo, data de exame, código de doente,

cardiologista (nome de médico), exame pedido ( nome do médico), técnico

assistente (nome de técnico), peso, altura, nº cassete, ano da cassete, modo M,

Modo 2-D, pulsado, continuo, cor, qualidade da imagem, medida da Aurícula

esquerda, medida de Ventrículo direito, Ventrículo esquerdo em sístole,

Ventrículo esquerdo em diástole, medida Septo, Medida da Aorta, Parede

posterior, fração de Ejecção, fracção de encurtamento, conclusões, conclusões

finais.


7

• História – nº processo, peso, altura, área corporal, atraso no crescimento

(indicação), Crise de Cianose (situação), Infecção respiratória, fadiga, cianose,

Taquipneia, Taquicardia, Vasoconstrição, Choque, Hepatomegalia, Ascite,

Cardiomegalia, Insuficiencia Renal Aguda, RX (descrição), Inótropicos,

Digitálico, Diurético, IECA, BetaBloqueador, Malformação, doença cardiaca,

obesidade, História familiar, Hipertensão arterial, fumador (situação),

dislipidémia, diabetes, AVC (tipo), data do AVC, Ugd, Doença Vascular

periférica, Dpoc, diálise, anemia, percentagem de anemia, endocardite

(situação), alergia, menopausa (situação), morbida, perda de peso, doença

coronária, Diabetes (descrição), Imunodepressão, Toxicodependência,

HipoAlbuminemia, S. da veia cava superior.

• Alertas – alerta (descrição do alerta), data de inicio, data de fim.

A partir destas definições de projecto chegou-se ao seguinte esquema conceptual,

representado nas figuras seguintes.


8

Coddoente

nº Beneficiário localidade

Sexo

datanascimento

Doente

Estdo Civil

Estado

Código

localidade de médicoassistente

médicoassistente telefone

Ematenção

participa em trabalhos

Data Inicio

Data de Fim

cirugião

Operado por

nº Hospitalar

Médico

Nr Nome

Descrição doAlerta

N

Regime de Taxamoderadora

regime

Alertas

particular

isento

normal

especial

Motivo deisenção

Entidaderesponsável

nºutente

cod postal

Eco_doente

Ecocardiograma

Coddoente

cod_processo

ano_processo

ano_cassete

DopplerPulsado

data de exame

peso

2-D

fich_numero

altura

nº da casseteidade

Médicoeco

realizado por

Doppler cor

DopplerContinuo

Pedido por

Qualidade deimagem

técnicoEco

Técnico auxiliar

Nr Nome

médico auxiliado por

Observações

morada

profissão

Conclusões

Septo

V. EsquerdoDiastole

modo_m

AuriculaEsquerda

Aorta

V. Esq. Sistole

Ventr. Direito

N

Fracção deEjecção

Fracção deEncurtamento

ParedePosterior

História

Vasoconstrição

cianose

fadiga

Cardiomegalia

infecçãorespiratória

peso

IRA

Taquipneia

altura

Area corporal

Ascite

Hepatomegalia

Nr

Descrição

Processo

BBloqueador

DoençaCardiaca

Inotropicos

Digitálico

Malformação

IECA

Atraso Crescimento

Nr

DescriçãoCrise cianose

Nr

DescriçãoRX

choque

Nr

Descrição AVC

Nr

Descrição

endocardite

Dpoc

D. Vasc.Periférica

Imunodepres.

Diálise

perda de pesor

anemia Toxicodepen.

diabetes

Ugd

Hx Familiar

HTA Obesidade

dislipidémia

S.Veia CavaS.

Hipoalbumina

AcontecimentoData de

Acontecimento

N

M

Consulta

doenteConsulta

Tipo

hora

DataAcontecimento

Eco

HolterProva Esfor

ECG

Pro. Func.Resp

N

MedicoConsulta

M

MorteDoenteMorte

nome mãe

nome

Data MorteCausa

Observação

nome pai


9


10


11

Descrição do modelo

Na inserção de valores, foram impostas regras rigorosas por forma a evitar os valores nulos, por

exemplo, é obrigatório a inserção do nome, data de nascimento, morada, e outros elementos

considerados essenciais, isto por forma a garantir a integridade da base de dados.

Relações que representam classes:

• Doente (Coddoente, nome, no_hospitalar, data_nasc, Estado_civil, profissão, morada,

codigo_postal, localidade, telefone, nome_pai, nome_mae, ent_responsavel, n_beneficiário,

medico, sexo, n_utente, Med_assistente, Local_assistente, observacoes)

• Eco (Coddoente, fich_num, cod_proc, ano_proc, data_exam, cod_med, cod_tec,

exa_pedido, peso, altura, idade, cassete_nr, ano_cassete, modo_m, 2-d, D_puldado,

D_continuo, D_cor, Q_boa, Q_regular, Q_ma, AE, VD, Ved, Ves, VESepto, Aorta,

Par_post, conclusao, fr_ejeccao, fr_encurtamento, fr_ejecao_2d, conc_final)

• História (Processo, peso, altura, AC, Atraso, cri_cianoses, infec_resp, fadiga, cianose,

taquipneia, Clubbing, Taquicardia, vasoconstricao, Choque, Hepatomegalia, Ascite,

Cardiomegalia, IRA, Inotropicos, Digitálico, Diuretico, IECa, PG_E1, Betabloqueador,

Malformacao, Doenca_card, obesidade, HXFamiliar, HTA, fumador, dislipidémia, AVC,

data_avc, Ugd, Dvperiferica, dpoc, dialise, anemia, anemia_perc, endocardite, alergia,

alergia_desc, morbida, perda_peso, dc, tipo_diab, n_macos, hx_DP, Imunodepressao,

Toxicodependente, Hipoalbuminemia, Sveia).

Relações que representam associações:

• Consulta (Coddoente, data_consulta, hora, cod_med, consulta, exames, Pe, ECO, ECG,

Holter, PFR)

• Acontecimento (coddoente, processo, data_acon, resumo)

• Morte (coddoente, data_morte, causa, observacao)

• Regime (Coddoente, cod_isencao, isento, normal, especial, particular)

• Alertas (coddoente, data_inicio, data_fim, cod_alerta)


12

Secção 4

Nesta secção, caberá agora demonstrar o porquê do uso de bases de dados. Fazendo perguntas à

base de dados e obter resultados para essas mesmo perguntas e depois aplicar ferramentas

estatísticas para obter conhecimento da informação extraída.

O pedido era realizar cinco perguntas à base de dados e fazer a respectiva apresentação em SQL e

em Álgebra Relacional.

Desta forma temos:

1. Qual o nome dos doentes solteiros e sexo feminino?

∏nome [σsexo=2 Λ estado_civil=1 (doente)]

em SQL seria:

SELECT nome, sexo, estado_civil

FROM Doentes

WHERE (sexo=2 AND estado_civil=1);

2. Qual o nome dos doentes e o seu peso, com a idade, à altura do exame de eco, entre 25 e 50

anos?

∏nome, peso [σidade between 25 Λ 50 (doente x Eco)]

em SQL:

SELECT Doentes.nome, eco.idade, eco.peso

FROM Doentes, eco

WHERE ((eco.idade) Between 25 And 50) and doentes.coddoente=eco.coddoente;


13

Ou ainda, como temos as relações definidas pelo código do doente:

SELECT Doentes.nome, eco.idade, eco.peso

FROM eco INNER JOIN Doentes ON eco.coddoente = Doentes.coddoente

WHERE (((eco.idade) Between 25 And 50));

3. Saber a soma das idades, e média das idades, dos doentes que fizeram exame de eco no ano

2000?

∏soma=SUM(idade), Media=Avg(idade) [σyear(data_exame)=2000 (eco)]

em SQL teremos:

SELECT Sum(idade) AS “Soma das Idades”, Avg(idade) AS “media das Idades”

FROM eco

HAVING ((Year([data_exam]))=2000);

4. Saber o numero total de consultas por médico, realizadas no ano de 1999?

∏total_consultas99=count(designacao), designacao [σyear(data_consulta)=1999 (medico x consulta)]

em SQL teremos:

SELECT Medico.Designacao, Count(Medico.Designacao) AS “Consultas efectuadas em 1999”

FROM Medico INNER JOIN Consulta ON Medico.Cod_est = Consulta.cod_med

GROUP BY Medico.Designacao, Year([data_consulta])

HAVING ((Year([data_consulta]))=1999)

Notar que a pergunta não contará as consultas cujo o médico não está atribuído, se quisesse forçar

essa situação, exibindo uma linha com nome de médico null e o número de consultas sem médico

atribuído bastaria trocar o INNER JOIN por um RIGHT JOIN e dessa forma incluiria todos os

dados da consulta mesmo com o código de médico a nulo. De notar que esta situação não deveria


14

acontecer, no entanto a tabela contém alguns destes dados nulos pois da conversão da anterior

tabela este campo não era de preenchimento obrigatório)

5. Selecionar todos os doentes que ainda não fizeram exame de ecocardiograma em 2000, e

que tenham consulta marcada para 2000?

D=∏nome [σyear(data_consulta)=2000 (consulta x doentes)]

Ec=∏nome [σyear(data_exame)=2000 (eco)]

R=Doentes-∏nome [D-Ec]

Em SQL teremos:

SELECT Doentes.nome

FROM Doentes INNER JOIN Consulta ON Doentes.coddoente = Consulta.coddoente

WHERE (((Doentes.coddoente) Not In

(Select eco.coddoente from eco

where year(eco.data_exam)=2000)) AND ((Year([data_consulta]))=2000));

Normalização

Este será o processo a partir do qual, poderemos assegurar que a estrutura em bases de dados

relacionais é eficiente. Neste sentido, quando as tabelas foram criadas, teve-se o cuidado de

minimizar a possibilidade de inserção de valores nulos, pois o seu uso leva a resultados

inconsistentes quando se realiza trabalhos de investigação.

Posso referir, por experiência, que existe uma perda significativa de extracção correcta de

informação, quando se analisa as amostras que pretendemos, devido aos missing values, pois em

termos estatísticos torna-se complicado chegar a conclusões fiáveis devido a dados que se

encontram incompletos, obrigando muitas das vezes a rever todos os processos em papel, para que

se possa completar os dados.

Nesse sentido, a actual base de dados teve esses problemas em consideração e campos que são

considerados delicados são obrigados a completar.


15

A construção do modelo teve em conta a redundância que por vezes estes modelos poderão

introduzir, neste modelo a redundância foi reduzida ao máximo, no entanto ela poderá existir

nalguns campos, nomeadamente no que respeita ao médico assistente e localidade do mesmo. Mas

por questões de eficiência optou-se por manter o campo em texto livre. Este é um dos exemplos da

existência da redundância nesta base de dados aqui apresentados.

A inconsistência da base de dados foi minimizada ao forçar a integridade referencial, pelo uso das

regras de propagação em cascata da actualização dos doados.

Primeira forma normal (1FN):

Tentando que todos os atributos da tabela doentes fossem atómicos, da forma como a base de

dados está organizada, é relativamente fácil violar a inserção ou actualizações da base de dados,

embora por exemplo, na tabela doentes em cada instante, cada valor de código de doente

corresponde um único valor de nome logo, referenciando a relação R, dado ao atributo Nome posso

dizer que é dependente funcional do atributo coddoente.

Coddoente-> nome,

pois se a relação apenas tivesse dois atributos, doentes.coddoente e doentes.nome, se eu souber o

coddoente sei o nome associado.

Segunda forma Normal (2FN):

A relação encontra-se na 2FN se a 1FN e todos os atributos não chave, são dependentes funcionais

em relação à chave.

Notar por exemplo que a tabela histórico em relação a doentes.

Doentes -> coddoente, Doentes ->nome

Mas a relação Acontecimento-Histórico (processo, coddoente, data_acont, .....)

=> histórico (processo, .....)


16

Desta forma:

Acontecimento(processo, coddoente, data_acont)

Doentes(coddoente, nome, ...)

Histórico (processo, peso, altura, .....)

A relação terceira forma normal (3FN):

Essa está garantida desde que as chaves não apareçam duplicadas, e é a mais simples de se aplicar.

Faculdade de Engenharia da Universidade do Porto Mestrado ...mgi98020/mgi/BD/Trabalho_adad.pdf ·...

Documents

Transcript of Faculdade de Engenharia da Universidade do Porto Mestrado ...mgi98020/mgi/BD/Trabalho_adad.pdf ·...