Desenvolvimento de ferramentas auxiliares leves conectadas a sistemas de registros eletrônicos de saúde

Construa suas próprias soluções em cima de sistemas EHR existentes

A Lei HITECH de incentivo de 2009 oferece dinheiro a médicos, hospitais e sistemas multi-hospitais se eles se tornarem "usuários significativos" de sistemas de registros eletrônicos de saúde (EHR). Para atender às regras de uso significativo de sistemas EHR, será preciso criar sua própria arquitetura para suportar aplicativos leves. Este artigo descreve como incluir uso significativo e outros requisitos de negócio como ferramentas auxiliares leves conectadas ao seu próprio sistema EHR sem risco para o ambiente existente.

Shahid N Shah, CEO and Chief Architect, Netspective Communications, LLC

Shahid Shah photoShahid N. Shah é líder de ideias de TI para assistência médica, influente e internacionalmente reconhecido. Na internet, ele é conhecido como "O cara de TI para assistência médica". É consultor de várias agências federais sobre assuntos de TI e vencedor do cobiçado prêmio "Fed 100" da Federal Computer Week, concedido a especialistas de TI que tiveram um grande impacto no governo. Shahid desenvolveu diversas soluções clínicas ao longo de seus quase 20 anos de carreira. Ajudou a projetar uma solução de registro eletrônico de saúde para a Cruz Vermelha Norte-Americana e implementá-lo em milhares de sites, construiu dois EMRs baseados na Web usados por médicos e projetou grandes sites de colaboração e groupware usado por milhares de pessoas. Como ex-CTO de uma divisão bilionária da CardinalHealth, ajudou a projetar interfaces clínicas avançadas para dispositivos médicos e hospitais. Shahid também serve como orientador senior de estratégia de tecnologia para o programa SBIR/STTR da NIH, ajudando pequenas empresas a comercializar seus aplicativos de assistência médica.



31/Ago/2012

O uso significativo lançou o EHR de volta ao centro das atenções

A Lei HITECH de incentivo de 2009 oferece de dezenas de milhares de dólares a médicos particulares a dezenas de milhões de dólares a hospitais e sistemas multi-hospitais se eles se tornarem "usuários significativos" de sistemas EHR. O governo fez um bom trabalho ao definir o uso significativo (MU) como independente de tecnologia e fornecedor. Com o Instituto Nacional de Padrões e Tecnologia (NIST) à frente dos critérios de teste e certificação, os requisitos para atender o MU são claros. Consulte Resources para obter mais informações sobre uso significativo e os programas de incentivo do governo norte-americano.

Agora que os critérios de MU e os planos de teste estão disponíveis, os desenvolvedores com aplicativos únicos e pequenos poderão atualizar seus aplicativos no prazo de poucos meses a um ano e estar preparados para certificação. A orientação atual para certificação funciona bem para fornecedores de software independentes que vendem para diversos clientes; no entanto, ela não é tão prática ou fácil para fornecedores legados, empresas de software livre ou para aqueles que constroem sistemas locais de registros médicos.

Para atender às regras de MU de sistemas EHR locais ou sistemas de mais fornecedores comerciais bem estabelecidos como a Meditech, que fornece sistemas EHR a muitos hospitais, será preciso criar sua própria arquitetura para suportar a nova funcionalidade. Este estudo descreve uma abordagem que permite incluir requisitos de MU como ferramentas auxiliares leves conectadas ao seu sistema EHR.


A abordagem monolítica de fornecedor único não funcionará por muito tempo

Muitos CIOs apoiam uma abordagem monolítica ou de fornecedor único para sistemas EHR porque acreditam que ela simplifica seu ambiente, oferece a eles um contato quando há problemas e, em última análise, reduz o risco de TI. Os sistemas de TI para hospitais são mais complexos do que os sistemas em geral. Embora o aplicativo de fornecedor único e monolítico seja bom em teoria, a maioria dos CIOs entende com relutância que não pode viver com um fornecedor para seu EHR e atingir todas as metas de usuário final do hospital e todos os requisitos regulamentares, incluindo uso significativo. Os fornecedores não gostam de atualizar seus sistemas por causa de um cliente; eles incluem funcionalidade e serviços em seus sistemas quando há muitos clientes que precisam da mesma nova funcionalidade. O roteiro de recursos do fornecedor raramente se alinhará diretamente com a estratégia e requisitos de TI do hospital, e o CIO do hospital irá querer outras opções.

Outro motivo para que as abordagens de fornecedor único sejam difíceis é que os fornecedores bem-sucedidos geralmente crescem por aquisição, e não organicamente. Eles compram sistemas separados de várias empresas e precisam integrá-los no ambiente de TI do hospital. O usuário de assistência médica típico precisa interagir com uma série de aplicativos diferentes, mesmos que os aplicativos sejam de um mesmo fornecedor. Por exemplo, um médico particular precisa interagir com aplicativos para se programar, gerenciar um registro médico eletrônico, escrever pedidos, ditar uma transcrição, revisar envio de reclamações e e-mails de pacientes e continuar sua educação médica. Uma enfermeira precisará fazer o planejamento, lidar com codificação ICD/CPT e faturamento, realizar o processamento de entrada e alta de pacientes, atender telefonemas, conduzir o gerenciamento de registro médico e acompanhamento e participar de uma educação contínua. É óbvio que essas tarefas e responsabilidades exigem informações para cruzar as barreiras de cada um desses aplicativos, mesmo se eles forem do mesmo fornecedor. Cada vez que os usuários precisam se mover de um aplicativo para outro (ou de uma forma baseada em papel de fazer coisas no computador), tempo é desperdiçado ao reinserir informações ou recuperar informações duplicadas (consulte Figura 1).

Figura 1. Infraestrutura existente ineficiente
Infraestrutura existente ineficiente

A arquitetura orientada a serviços (SOA) e uma abordagem integrada são necessárias

Os sistemas EHR legados foram criados com uma mentalidade focada no aplicativo. Para integrar dados e evitar duplicação de funcionalidade e captura de informações, precisamos de uma maneira de modelar e criar serviços comuns em vez de aplicativos. Nesse contexto, services se referem a pedaços de código computacional que são pequenos, reutilizáveis, focados em grânulos de funcionalidade em vez de grandes aplicativos monolíticos. Por exemplo, um aplicativo usado para registrar um paciente ou editar dados demográficos do paciente usaria um serviço de registro de pacientes comum. Um aplicativo usado para descobrir as prescrições de um paciente usaria um serviço de medicação de paciente comum. Um aplicativo que acessa as credenciais de um provedor de serviços de saúde usaria um serviço de credenciamento centralizado. Esses são todos exemplos de serviços de assistência médica que foram desenvolvidos uma vez e depois reutilizados em dezenas de aplicativos.

Sistemas críticos de segurança usados no ponto de atendimento ou em dispositivos médicos possuem considerações especiais tanto em termos práticos quanto regulamentares. Por exemplo, um sistema que controla os sinais vitais do paciente em tempo real para monitoramento em uma bomba IV requer muito mais atenção para planejar, construir, testar e validar do que um sistema que monitora registros de faturamento para reembolso do seguro-saúde. A abordagem com orientação ao serviço permite que os sistemas críticos de segurança que podem ser usados em dispositivos médicos regulamentados sejam projetados e testados de uma forma diferente dos sistemas puros focados em informações.

Ao definir e projetar serviços especializados, e ao permitir que aplicativos pequenos quebrem os serviços reutilizáveis, os aplicativos se tornam menos monolíticos. Serviços menores e mais ágeis são mais fáceis de se adaptarem aos requisitos de negócio e regulamentares em constante transformação. Considerando que todo aplicativo requer algo tão comum quanto à funcionalidade de registro de pacientes, um serviço de registro de pacientes permite que novos aplicativos sejam construídos mais rapidamente e com melhor qualidade. Aplique o exemplo em outros serviços comuns e multiplique as economias de custo por dezenas de aplicativos e as reduções de tempo e custo se tornam significativas o suficiente para afetar os resultados na maioria dos grupos de TI. Liberar preciosos recursos de TI para focar a otimização adicional do negócio permite que até organizações fora do segmento de TI vejam um crescimento no faturamento devido à inovação (consulte Figura 2).

Figura 2. A abordagem de SOA
A abordagem de SOA

Aplicativos leves quebrados em torno de serviços são necessários agora

Se você é responsável pela estratégia e implementação de MU em seu hospital ou organização de provedor de serviços de saúde, você irá enfrentar desafios práticos. Provavelmente você já possui aplicativos monolíticos, mas sabe que precisa de mais orientação sobre serviço. É preciso entender como criar aplicativos leves que podem ser quebrados em torno de serviços existentes, ou como os aplicativos construídos em cima de aplicativos existentes do fornecedor podem acessar diretamente os bancos de dados. Nenhuma delas é fácil, mas há quatro opções primárias:

  • Copiar funcionalidade entre aplicativos (não recomendado).
  • Integrar os dados, mas copiar a funcionalidade.
  • Integrar dados, funcionalidade e lógica de negócios.
  • Integrar interface com o usuário, funcionalidade, dados e lógica de negócios.

Opção 1: Copiar recursos e aprimorar (tudo é separado)

A opção 1 é o típico modelo legado no qual você copia recursos e os aprimora, e no qual todo código novo é gravado, testado e implementado separadamente (consulte Figura 3). Essa é a forma mais cara de desenvolver software e causa uma significativa duplicação de esforços. Esse método não é recomendado.

Figura 3. Opção 1
Opção 1

Opção 2: Integrar dados existentes, mas copiar recursos e aprimorar

A segunda opção é a abordagem de integração mais comum quando não se tem acesso ao código do aplicativo, mas é possível acessar o banco de dados. É possível vincular dados do novo aplicativo a dados do aplicativo existente acessando o banco de dados existente a partir do novo aplicativo (consulte Figura 4). Essa abordagem é recomendada se não for possível usar as opções mais sofisticadas apresentadas nas opções 3 e 4.

Figura 4. Opção 2
Opção 2

Opção 3: Criar uma API entre os aplicativos, integrar dados e criar novos dados

Nesta terceira opção, é possível criar uma API entre os aplicativos, integrar dados existentes e criar novos dados (consulte Figura 5). Esse estilo permite reutilizar funcionalidade e dados; ele é altamente recomendado que você escolha esta opção se não puder fazer o modelo puro de serviços mostrado abaixo.

Figura 5. Opção 3
Opção 3

Opção 4: Criar serviços comuns para que todos os aplicativos possam usá-los

O design ideal é criar serviços comuns para que todos os aplicativos possam usá-los. Esta opção é a mais difícil de realizar, mas é a abordagem mais ideal. Sempre tente usar este design, e volte para a terceira opção se esta opção não for possível para você (consulte Figura 6 ).

Figura 6. Opção 4
Opção 4

Os tipos de aplicativos leves solicitados por usuários

Os tipos mais comuns de aplicativos leves que o lado dos negócios do hospital ou sua organização provedora solicitará estão em três categorias:

  • Funcionalidade adicional que permite que os requisitos de MU sejam preenchidos.
  • Acesso remoto a dados clínicos através de novos tablets, telefones celular e outros dispositivos.
  • Melhor comunicação entre:
    • Provedores e provedores relacionados (de médicos para médicos ou de hospitais para hospitais)
    • Provedores e seus pagadores (os provedores enviam documentos clínicos e outros materiais aos pagadores)
    • Pacientes e seus provedores (os pacientes enviam informações a seus médicos)
    • Provedores e seus pacientes (os provedores enviam informações a seus pacientes sem serem contatados por pacientes)
    • Organizações públicas de saúde e provedores (as organizações enviam avisos e regulamentos aos provedores)
    • Organizações públicas de saúde e pacientes (as organizações enviam dados públicos de saúde a pacientes)
    • Pagadores e seus pacientes (registros pessoais de saúde e outras transferências de dados)

As expectativas de TI dos usuários não caem em somente uma única categoria. Essas expectativas e os novos requisitos regulamentares exigirão que você se conecte a seu sistema EHR usando uma das opções mencionadas na seção anterior. Este artigo técnico não entra nos detalhes do negócio, mas quando você se comprometer a criar aplicativos leves quebrados em torno de serviços novos ou existentes, você precisará:

  • Criar um mecanismo de autenticação e conexão única para que seus novos aplicativos não exijam login toda vez.
  • Criar um repositório de dados clínicos (CDR) ou data mart central que pode ser usado para armazenar dados do seu sistema EHR (a menos que planeje se conectar diretamente).
  • Conectar-se a um barramento de serviço corporativo (ESB) que suporte integração HL7 para preencher seu CDR ou data mart.
  • Armazenar apenas pequenas quantidades de dados em seus novos aplicativos e recuperar outros dados do CDR ou data mart central.
  • Construir seus aplicativos usando tecnologias da Web e HTML5 para apresentações remotas.

Abordaremos cada uma das tarefas acima nas seções a seguir.


Autenticação, autorização e conexão única (SSO) do usuário

Um atributo dos aplicativos leves é que eles proliferam. Você começa com um pequeno, depois outro e mais outro. Isso é exatamente o que deveria acontecer, mas se você não gerenciar a autenticação e autorização do usuário centralmente e permitir que pessoas alternem entre esses aplicativos usando um login e senha comuns, brevemente você terá aplicativos que os usuários não querem usar.

Felizmente, há muitas boas opções para autenticação comum e conexão única (as autorizações comuns e controle de acesso baseado na função, ou RBAC, é um pouco mais difícil). Vamos esclarecer algumas definições antes de vermos as opções:

  • A conexão única (SSO) permite que os usuários se conectem uma vez a qualquer aplicativo e depois sejam automaticamente autorizados a usar qualquer outro aplicativo que use o mesmo provedor de SSO.
  • A conexão comum permite que os usuários se conectem a diversos aplicativos usando o mesmo nome de usuário e senha. Ela não é tão legal quanto a SSO, mas é útil porque é mais fácil de ser implementada e, embora ela não impeça diversos logins, ela não exige nomes de usuário e senhas separados para aplicativos diferentes.
  • Autenticação, fornecida por um sistema de gerenciamento de usuário, confirma se um usuário é quem ele diz ser. A autenticação meramente valida a identidade de uma pessoa.
  • Authorization é o que um sistema de gerenciamento faz para verificar a qual grupo a pessoa pertence, qual função ela tem em um sistema e quais permissões específicas devem ser concedidas a ela em aplicativos específicos.

Opção 1 de SSO: Atlassian Crowd

Se você não possui muita autenticação ou conhecimento de SSO em sua organização, a plataforma comercial de SSO Atlassian Crowd é um bom começo. Ela possui muitos recursos e funções e pode se conectar a diversos aplicativos e diretórios por meio de um único nome de usuário e senha. Diferentemente de muitas outras opções (como OpenID ou CAS), ela faz um bom trabalho com gerenciamento de grupo e autorização, além de autenticação.

Opção 2 de SSO: CAS e SAML

Se você possui uma boa equipe de engenharia, deseja usar produtos de software livre e manter-se focado em padrões e protocolos abertos, escolha o serviço de autenticação comum (CAS) para autenticação e linguagem de marcações de asserção de segurança (SAML) para autorização e troca de perfil do usuário. É possível usar a CAS como login virtual em qualquer aplicativo backend que possuir (depois que você gravar conectores customizados ou usar os conectores integrados para ActiveDirectory ou LDAP). Para passar informações do usuário do perfil comum de usuário, use uma asserção SAML para transmitir identidade, grupos e informações relacionadas.

Opção 3 de SSO: Microsoft® Active Directory (AD)

Se você está trabalhando principalmente no ambiente do Microsoft Windows® , você deve tentar vincular todos os seus aplicativos juntos ao Active Directory. Qualquer aplicativo .NET e muitos aplicativos PHP, Java™ e outros podem se conectar ao AD (embora os aplicativos .NET tenham o tempo mais fácil).

Opção 4 de SSO: Lightweight Directory Access Protocol (LDAP)

O LDAP pronto para uso pode oferecer a capacidade de permitir conexão comum em oposição à conexão única. O LDAP já é suportado pela maioria dos ambientes de TI e é uma boa escolha se nenhuma das outras opções mencionadas anteriormente funcionar para você.

Opção 5 de SSO: OpenID

O OpenID é um protocolo de identidade comum suportado por muitos aplicativos da Web; não é muito comum ver o OpenID suportado por fornecedores de software médico, mas é algo que pode ser construído em cima dos seus próprios produtos internos. Como a CAS, o OpenID é independente de backend, linguagem e sistema. É possível construí-lo em cima de praticamente qualquer aplicativo legado que ofereça acesso ao seu sistema de gerenciamento de usuário.

Implementação de SSO

Qualquer que seja a opção de SSO escolhida, certifique-se de que você possui algo funcionando que permita que seus novos aplicativos da Web e aplicativos remotos leves se conectem à sua nova funcionalidade sem que os usuários precisem aprender um novo nome de usuário e senha. Se você não fornecer a funcionalidade de conexão comum ou única, as chances de sucesso dos novos aplicativos serão dificultadas. Como mostrado Figura 7, a solução de conexão única deve ser um serviço centralizado usado por todos os seus aplicativos, e não um recurso de qualquer aplicativo em particular. Se a SSO for implementada adequadamente, será fácil incluir funcionalidade ao seu EHR, já que a nova funcionalidade deve se separar do EHR e passar pela solução de SSO.

Figura 7. Opções de SSO
Opções de SSO

Criação de novos aplicativos leves

Se você possui a tarefa de construir novos aplicativos, seu primeiro requisito será não causar nenhum dano, o que significa que a nova funcionalidade nunca deve provocar danos a aplicativos ou dados existentes. Dado o objetivo prioritário, Figura 8 mostra uma boa arquitetura a ser considerada.

Figura 8. Nova arquitetura de EHR
Nova arquitetura de EHR

Nessa arquitetura, os novos aplicativos, que podem ser aplicativos remotos, da Web ou de desktop, devem ter cada um seu próprio banco de dados para os tipos de dados que não precisam ser compartilhados. Eles devem, ainda, se comunicar com um data mart clínico por causa de todos os dados que precisam ser compartilhados.

Crie um repositório comum de dados clínicos (CDR) ou data mart

Trabalhar com seus sistemas de TI legados ou estabelecidos pode ser difícil, então você pode pensar em um data mart clínico comum sincronizado, no qual seja possível armazenar o EHR em um formato mais acessível. Considere seu data mart cuidadosamente e só coloque nele o subconjunto pequeno de dados de EHR. Os data marts são muitas vezes criados para dados analíticos, mas dada a potência e desempenho dos bancos de dados modernos como IBM DB2®, CouchDB e MySQL, a diferença entre data marts analíticos e armazenamento de dados para uma finalidade especial, como repositórios de dados clínicos, é tão pequena que é considerada insignificante para os tipos de dados que estão sendo considerados aqui.

Se não for solicitado que você use um banco de dados relacional devido a padrões corporativos em seu hospital, pense em começar com um banco de dados NoSQL. CouchDB é uma boa chance.

Conecte o CDR ou data mart a um barramento de serviço corporativo (ESB) que suporte HL7

O data mart clínico que compartilha dados com seus aplicativos leves precisará ser sincronizado com os dados do EHR. Há diversas opções aqui, mas você pode começar com ferramentas de nível corporativo, como IBM WebSphere® Enterprise Service Bus, ferramentas de software livre como Mule ou ServiceMix (e inclua suporte a análise de HL7), ou escolha um ESB construído para uma finalidade e ativado por HL7 como o Mirth. Você pode estar interessado em monitorar e colocar as mensagens mostradas na Tablela 1 em um data mart clínico.

Tablela 1. Mensagens para um data mart clínico
Tipo de dadosTipo de mensagem HL7
Incluir pacienteA04, A28
Atualizar pacienteA08, A31
Agendar consultaS12
Cancelar consultaS15
Efetuar o registro de entrada da consultaA01, S13
Efetuar o registro de saída da consultaA01, S13
Cobrar captação e faturamentoFT1 DFT^P03
Admitir pacienteVaria
Liberar pacienteVaria
Atualizar admissãoVaria

Persistência para seus aplicativos leves

Embora seja uma boa ideia centralizar bancos de dados sempre que possível, para aplicativos leves que precisam ser criados rapidamente e que podem ser remotos, faz sentido considerar bancos de dados locais para cada um dos seus aplicativos ou grupos de aplicativos. Manter os bancos de dados locais e ter uma estratégia de sincronização oferece aos seus usuários e desenvolvedores de negócios bastante liberdade e flexibilidade para criar aplicativos quando necessário e não causar danos acidentais a sistemas legados existentes.

Em vez de um armazenamento de dados relacionais completo, você deve considerar bancos de dados NoSQL, como CouchDB e MongoDB, para os bancos de dados locais em seus aplicativos leves.

Aplicativos da Web e HTML5 para apresentações remotas

Você irá querer escolher aplicativos padrão da Web ou os novos padrões remotos de HTML 5 como sua camada de apresentação para manter os aplicativos o mais leve e ágil possível. O Adobe Flash, Flex, AIR, Microsoft Silverlight e o desktop do Microsoft Windows, além de outras opções, são favorecidos à medida que o lado dos negócios pede mais funcionalidade interativa e visual. No entanto, ao manter seus aplicativos em HTML4 ou HTML5, com um pouco de AJAX para interatividade, você oferecerá aos seus usuários a capacidade de executar aplicativos em iPads, telefones inteligentes, nos tablets Android que estão para serem lançados e muitos outros dispositivos, incluindo estações de trabalho.


Conclusão

Para atender às regras de MU e fornecer os aplicativos que seus usuários demandam, pode ser necessário construir suas próprias soluções em cima de sistemas EHR existentes. Há muitas escolhas, mas se você escolher a abordagem orientada a serviço com um data mart clínico e ESB HL7 para separar os dados, ela oferecerá a você mais flexibilidade e liberdade para construir novos aplicativos sem ser obstruído por sua infraestrutura legada.

Recursos

Aprender

  • A Tour of the Healthcare New Media Marketing Landscape: Leia uma apresentação sobre as várias técnicas que os hospitais podem usar para comercializar seus serviços nesse blog por Shahid N. Shah.
  • HITECH Survival Guide: Saiba mais sobre a Lei Health Information Technology for Economic and Clinical Health (HITECH)
  • Registros eletrônicos de saúde e uso significativo: Veja a descrição do Gabinete do Coordenador Nacional de Tecnologia da Informação para Saúde dos registros eletrônicos de saúde e uso significativo, e encontre links para informações sobre os dois programas de incentivo. Um programa incentiva o uso significativo por provedores de assistência médica e o outro certifica os sistemas EHR.
  • Nationwide Health Information Network (NHIN) é um conjunto de normas, serviços e políticas que ativam a troca segura de informações sobre saúde pela Internet.
  • NHIN Direct: Saiba mais sobre esse projeto de expandir as definições de normas e serviço que, com uma estrutura de política, constituem o NHIN.
  • Open Health Tools: Saiba mais sobre essa comunidade de software livre dedicada a melhorar a saúde das pessoas através da transformação das tecnologias de informação sobre saúde.
  • Projeto OpenExchange : Leia sobre como o OpenExchange fornece infraestruturas de núcleo baseadas em padrões para trocar informações de saúde do paciente de maneira segura e oportuna, para avançar a qualidade, a segurança e a eficiência da entrega de assistência médica.
  • How Meaningful Use Impacts Healthcare Data Management Professionals: Saiba quais profissionais de gerenciamento de dados de assistência médica precisam saber como obter o uso significativo e certificação da HITECH durante este webinar on demand.
  • Segmentos de mercado no developerWorks : Explore todos os recursos técnicos mais recentes específicos dos segmentos de mercado para desenvolvedores.
  • SOA e serviços da Web do developerWorks: Encontre artigos, tutoriais, padrões e outros recursos técnicos para serviços da Web e SOA.
  • Information Management do developerWorks : Encontre gerenciamento de dados da IBM e recursos relacionados a bancos de dados.
  • IBM WebSphere Application Server: Crie, implemente e gerencie aplicativos de negócios SOA robustos, ágeis e reutilizáveis de todos os tipos, ao mesmo tempo em que reduz custos de infraestrutura de aplicativos com o IBM WebSphere Application Server.
  • Zona do Websphere Portal no developerWorks : Encontre informações e recursos do IBM WebSphere Portal, um aplicativo composto ou estrutura de mashup de negócios e o conjunto de ferramentas avançadas necessárias para construir soluções flexíveis baseadas em SOA.
  • Podcasts do developerWorks: Ouça entrevistas e discussões interessantes para desenvolvedores de software.
  • developerWorks: Permaneça atualizado com os webcasts e eventos técnicos do developerWorks.

Obter produtos e tecnologias

Discutir

Comentários

developerWorks: Conecte-se

Los campos obligatorios están marcados con un asterisco (*).


Precisa de um ID IBM?
Esqueceu seu ID IBM?


Esqueceu sua senha?
Alterar sua senha

Ao clicar em Enviar, você concorda com os termos e condições do developerWorks.

 


A primeira vez que você entrar no developerWorks, um perfil é criado para você. Informações no seu perfil (seu nome, país / região, e nome da empresa) é apresentado ao público e vai acompanhar qualquer conteúdo que você postar, a menos que você opte por esconder o nome da empresa. Você pode atualizar sua conta IBM a qualquer momento.

Todas as informações enviadas são seguras.

Elija su nombre para mostrar



Ao se conectar ao developerWorks pela primeira vez, é criado um perfil para você e é necessário selecionar um nome de exibição. O nome de exibição acompanhará o conteúdo que você postar no developerWorks.

Escolha um nome de exibição de 3 - 31 caracteres. Seu nome de exibição deve ser exclusivo na comunidade do developerWorks e não deve ser o seu endereço de email por motivo de privacidade.

Los campos obligatorios están marcados con un asterisco (*).

(Escolha um nome de exibição de 3 - 31 caracteres.)

Ao clicar em Enviar, você concorda com os termos e condições do developerWorks.

 


Todas as informações enviadas são seguras.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=80
Zone=Segmentos de mercado
ArticleID=630312
ArticleTitle=Desenvolvimento de ferramentas auxiliares leves conectadas a sistemas de registros eletrônicos de saúde
publish-date=08312012