OpenEMR: diferenças entre revisões

Revisão das 08h01min de 6 de julho de 2015

OpenEMR Logo

OpenEMR
Sigla
Designação	OpenEMR
Data de Lançamento	6/2001
Entidade Criadora	OEMR
Entidade Gestora	OEMR
Versão Atual	4.2.0 / Dezembro de 2014
Requisitos Técnicos
Tipo de Licenciamento
Arquitetura
Sistema Operativo	Windows, Mac OS, Linux, etc.
Especialidade Médica
Utilizadores Principais
Função	Gestão da Prática Médica, Registos clinicos electrónicos

OpenEMR é uma aplicação open source para a gestão dos registos electrónicos e da prática médica. Sendo uma aplicação open source pode ser executada a partir de vários sistemas operativos, tal como Windows, Mac OS, Linux, etc. A OpenEMR é certificada pela ONC e é suportada por uma vasta comunidade de voluntários que trabalham com o único propósito de tornar a aplicação uma alternativa melhor que as aplicações pagas.

A aplicação OpenEMR abrange várias áreas que vão desde a gestão dos pacientes e do registo clínico, passando pela prescrição de medicamentos até à gestão da área financeira e a interação com as seguradoras. Listam-se a seguir um conjunto de parametrizações e funcionalidades que tornam esta aplicação bastante completa:

CDR Motor: Um motor de regras associadas à decisão clínica;
Gestor de serviços (área de backoffice);
Uma API OpenEMR: Interfaces de programação para o OpenEMR;
Uma API de Formulários: Uma interface para adicionar novas componentes e alterar os formulários existentes;
Uma API de Notas: Uma interface para adicionar e gerir notas, que não são do foro médico, ligadas ao arquivo de um paciente;
Uma API de Lembretes: Uma interface para adicionar e gerir lembretes;
Listas e Layouts: Edição de Listas built-in e forma simples editar e alterar o layout;
Envio de e-mail: Mecanismo preferencial de envio de e-mail(s);
Módulo de Prescrição: parametrização e navegação pelo módulo de prescrição;
Tipos de código: Explica o esquema atual para importar os tipos de código (como ppr exemplo o ICD9, CPT, etc.);
Códigos de Diagnóstico: Plano de implementação de conjuntos de códigos de diagnóstico (ICD9, CID10, SNOMED, etc.).

História

A OpenEMR foi originalmente desenvolvida pela Synitech e a primeira versão foi disponibilizada como MP Pro (Medical Practice Professional). Muito do seu código foi reajustado para obedecer à Health Insurance Portability and Accountability Act (HIPAA) e para melhorar a segurança. Por este motivo foi disponibilizada a versão 1.3 um ano depois. Em Agosto de 2002 a OpenEMR foi disponibilizada ao publico sob a GNU General Public License (GPL), e passou a ser um projecto open-source, registada na SourceForge. O projecto foi evoluindo para a versão 2.0 e a Pennfirm passou a ser a principal responsável pela manutenção da plataforma. Em 2005, Walt Pennington transferiu todo o repositório para a SourceForge, onde permanece nos dias de hoje. Pennington promoveu Rod Roark, Andres Paglayan e James Perry Jr. a administradores do projecto. Estes a uma dada altura começaram a divergir nas ideias tomadas, o que levou a serem substituídos por Brady Miller em Agosto de 2009. Assim, nos dias de hoje Rod Roark e Brady Miller são os únicos dois co-administradores do projecto OpenEMR.

Certificação

A certificação é um processo de aferição do cumprimento dos requisitos específicos, através de testes de performance ou cumprimento de critérios de qualidade de um produto, sistema ou serviço. Estes processos conferem uma maior credibilidade ao produto, sistema ou serviço, atendendo de forma … as expectativas do consumidor. Geralmente as certificações são efetuados por entidades externas, credenciadas para tal, sendo baseadas em teorias e heurísticas que utilizam métodos definidos e sistemáticos capazes de mensurar características de modo reprodutível.

As versões da OpenEMR 4.1.0, 4.1.1 e 4.1.2 tem a certificação ONC Complete Ambulatory EHR Certification pelo ICSA Labs. A versão 4.2.0 é certificada com a ONC Modular Ambulatory EHR Certification pela InfoGard Laboratories

No âmbito da disciplina “Sistemas de Informação em Saúde e Registos Clínicos Eletrónicos”, do Mestrado em Informática Médica, foi efetuada a avaliação de um conjunto de requisitos, tendo por base o “Manual de Certificação para sistemas de registos eletrónicos em Saúde (S-RES) – versão 4.0” documento promovido pela Sociedade Brasileira de Informática em Saúde (SBIS). Neste processo de avaliação foram apenas selecionados alguns dos requisitos. Podem ser consultados os requisitos avaliados, o resultado da avaliação e algumas recomendações nos casos das não conformidades, na seguinte página: XXXXXXXXXXXXXXX

Requisitos de nivel de garantia de segurança

Controlo Versões SW

ID	Requisito	Avaliação	Observações
NGS1.1.01.01	Versão de sw	Não conforme	Nenhum menu principal apresenta a versão do sw utilizado. Recomenda-se a apresentação desta informação.
NGS1.1.01.02	Código fonte	Não conforme	Não permite, via interface, ratrear os ficheiros que deram origem ao codigo fonte. Recomenda-se a apresentação desta informação.
NGS1.1.01.03	Histórico de alterações	Não conforme	Não existe nenhum interface onde sejam descritas as alterações de cada versão e respetivos responsáveis. Recomenda-se a apresentação desta informação.
NGS1.1.01.04	Repositório de versões	Não conforme	Não existe nenhum interface onde sejam apresentadas todas as versões instaladas, permitindo voltar a versões anteriores em caso de atualizações mal sucedidas. Recomenda-se a apresentação desta informação.
NGS1.1.01.05	Dependências dos componentes	Conforme parcialmente	As dependências não são apresentadas de forma detalhada. Recomenda-se a apresentaçã desta informação.

Identificação e autenticação do utilizador

ID	Requisito	Avaliação	Observações
NGS1.1.02.01	Identificação e autenticação do utilizador	Conforme
NGS1.1.02.02	Método de autenticação	Conforme
NGS1.1.02.03	Proteção dos parâmetros de autenticação	Conforme
NGS1.1.02.04	Segurança das senhas	Conforme parcialmente	Não valida todos os citérios de qualidade da senha. Recomenda-se apresentação de mensagem co critérios de qualidade das senhas
NGS1.1.02.05	Controlo de tentativas de login	Não conforme	Independentemente do nº de tentativas, o utilizador nunca é bloqueado. Recomenda-se a implementação deste procedimento.
NGS1.1.02.06	Identidade única do utilizador	Conforme

Controlo da sessão do utilizador

ID	Requisito	Avaliação	Observações
NGS1.1.03.01	Encerramento por inatividade	Conforme
NGS1.1.03.02	Segurança contra roubo de sessão do utilizador	Conforme

Autorização e controle de acesso

ID	Requisito	Avaliação	Observações
NGS1.1.04.01	Impedir acesso por entidades não autorizadas	Conforme
NGS1.1.04.03	Gerenciamento de usuários	Conforme
NGS1.1.04.04	Papéis relacionados à TI	Conforme
NGS1.1.04.05	Configuração de controle de acesso	Conforme
NGS1.1.04.06	Concessão de autorizações	Conforme
NGS1.1.04.07	Delegação de poder	Não conforme	Não existe controlo na delegação de poder
NGS1.1.04.08	Acesso ao RES pelo paciente	Conforme
NGS1.1.04.09	Restrições de acesso ao RES adicionadas pelo paciente	Não conforme	Não existem restrições na consulta dos dados

Disponibilidade do SI

ID	Requisito	Avaliação	Observações
NGS1.1.05.01	Cópia de segurança	Conforme
NGS1.1.05.02	Verificação da integridade na recuperação de dados	Não foi possível verificar

Segurança de dados

ID	Requisito	Avaliação	Observações
NGS1.1.07.01	Importação de dados	Conforme
NGS1.1.07.03	Impedir exclusão e alteração	Não conforme	É possível alterar/eliminar dados sem mecanismo que o impeçam
NGS1.1.07.04	Verificação de integridade dos dados	Não conforme
NGS1.1.07.10	Visualização do histórico de alterações	Não conforme	Não existem logs

Auditoria

ID	Requisito	Avaliação	Observações
NGS1.1.08.01	Auditoria contínua	Conforme parcialmente	Não foi encontrada a parametrização de alertas de forma a atuar preventivamente. Recomenda-se esta implementação.
NGS1.1.08.02	Integridade das linhas de auditoria	Conforme
NGS1.1.08.03	Acesso a trilhas de autitoria	Conforme
NGS1.1.08.04	Eventos e informações registadas	Conforme parcialmente	Não foi possível confirmar a existencia de toda a informação exigida (ex. ponto de acesso do utilizador, dados de autenticaçao e de sessão do utilizador, etc.). Recomenda-se a disponibilização da informação em falta.
NGS1.1.08.05	Interface de vizualiação de registos de auditoria	Conforme
NGS1.1.08.06	Exportação e visualização de registos de auditoria	Não conforme	Não apresenta possibilidade de exportação de dados de auditoria. Recomenda-se esta implementação.

Privacidade

ID	Requisito	Avaliação	Observações
NGS1.1.13.01	Exibição de mensagem de ciência de uso	Não conforme
NGS1.1.13.02	Consentimento do paciente	Não conforme
NGS1.1.13.04	Acesso de emergência	Não conforme	Não faz logs
NGS1.1.13.05	Propósito de uso	Conforme

Requisitos de Estrutura e Conteúdo para S-RES Assistencial

Dados Administrativos

ID	Requisito	Avaliação	Observações
ESTR.03.01	Registo de identificação do paciente	Conforme
ESTR.03.02	Padrões do CNS, CNES, CNPJ	Não conforme
ESTR.03.03	Episódios de atenção	Não conforme
ESTR.03.04	Informações financeiras e comerciais	Conforme
ESTR.03.05	Situação legal	Não conforme	Não se conseguiu encontrar uma opção nesta área
ESTR.03.06	Vigilância	Não conforme	Não existe de uma forma directa

Dados clínicos

ID	Requisito	Avaliação
ESTR.04.01	Conjunto mínimo de dados	Conforme
ESTR.04.02	Laudos e resultados de exames	Conforme
ESTR.04.03	Envio eletrônico de dados	Conforme
ESTR.04.04	Arquétipos	Conforme

Tipos de dados

ID	Requisito	Avaliação	Observações
ESTR.05.01	Dados numéricos e quantificáveis	Conforme
ESTR.05.02	Precisão da medida	Conforme
ESTR.05.03	Percentagem em valor absoluto	Conforme
ESTR.05.04	Limites	Conforme
ESTR.05.05	Lógica de valores fracionados	Conforme
ESTR.05.06	Lógica de data e hora	Conforme parcialmente	Não foi encontrada possibilidade de definir fuso horário. Recomenda-se esta implementação.
ESTR.05.07	Definições incompletas	Conforme parcialmente	Não foi encontrada possibilidade de registar definições incompletas. Recomenda-se esta implementação.
ESTR.05.08	Eventos e ações futuras	Conforme
ESTR.05.09	Linha de tempo	Conforme
ESTR.05.10	Fuso horário	Não conforme	Recomenda-se esta implementação.
ESTR.05.11	Precisão de milisegundos	Não conforme	Recomenda-se esta implementação.
ESTR.05.12	DICOM, MIME e ECG	Conforme

Representação de conceitos em saúde

ID	Requisito	Avaliação	Observações
ESTR.09.01	Multiplos sistemas de codificação	Conforme	ICD9, CPT4, HCPCS, CVX
ESTR.09.02	Captura do código	Conforme
ESTR.09.03	Vocabulário padrão e de origem	Conforme
ESTR.09.04	Ambiguidade	Conforme
ESTR.09.05	Mapeamentos	Não conforme	Não foi encontrado nenhum interface com este mapeamneto dispoínvel. Recomenda-se esta implementação.
ESTR.09.06	Serviços de terminologia	Conforme	SNOMED

Requisitos de funcionalidade para S-RES Assistencial

Assistência integral

ID	Requisito	Avaliação	Observações
FUNC.07.01	Assistência integral	Conforme

Garantia de qualidade

ID	Requisito	Avaliação	Observações
FUNC.08.01	Performance clínica e operacional	Conforme

Captura de dados

ID	Requisito	Avaliação	Observações
FUNC.09.01	Entrada e acréscimo de dados	Conforme
FUNC.09.02	Validação dos dados	Parcialmente conforme	Por ex. permite registar datas de nascimento para um futuro longinquo, valores negativos em campos que não o deveriam aceitar. Recomenda-se a implementação das validações exigidas.
FUNC.09.03	Pesquisa com filtros	Conforme

Recuperação/consultas e visões

ID	Requisito	Avaliação	Observações
FUNC.10.01	Visões	Conforme

Apresentação dos dados

ID	Requisito	Avaliação	Observações
FUNC.11.01	Sumário clínico	Conforme
FUNC.11.02	Resolução para interpretação clinica	Não conforme	Não existe uma opção deste género
FUNC.11.03	Imagens médicas	Não conforme

Consentimento

ID	Requisito	Avaliação	Observações
FUNC.16.01	Consentimento informado	Não conforme	Não foi encontrado nenhum interface que permitisse o registo ou submissão do ficheiro com o consentimento informado. Recomenda-se esta implementação.
FUNC.16.02	Situação do consentimento informado	Não conforme	Não foi encontrado nenhum interface que apresenta o estado do consentimento informado. Recomenda-se esta implementação.
FUNC.16.03	Propósito do consentimento informado	Não conforme	Não foi encontrado nenhum interface que apresenta o motivo do consentimento informado. Recomenda-se esta implementação.
FUNC.16.04	Instante do consentimento informado	Não conforme	Não foi encontrado nenhum interface que apresenta a data com o timestamp do consentimento informado. Recomenda-se esta implementação.

Controlo de versão

ID	Requisito	Avaliação	Observações
FUNC.23.01	Controlo de versões	Não conforme
FUNC.23.02	Medidas de discernimento	Não conforme

Links Externos

@@ Linha 7: / Linha 7: @@
 |Data de Lançamento=6/2001
 |Versão Atual=4.2.0 / Dezembro de 2014
+|Tipo de Licenciamento=GNU General Public License (GNU GPL)
 |Sistema Operativo do Sistema de Informação=Windows, Mac OS, Linux, etc.
 }}

OpenEMR: diferenças entre revisões

Revisão das 08h01min de 6 de julho de 2015

Índice

História

Certificação

Requisitos de nivel de garantia de segurança

Requisitos de Estrutura e Conteúdo para S-RES Assistencial

Requisitos de funcionalidade para S-RES Assistencial

Links Externos

Menu de navegação

Ações da página

Operações da página

Ferramentas pessoais

Navegação

Pesquisa

Ferramentas