O 'Agile' pode ser aplicado às equipes de TI da área de saúde?

O Agile pode ser empregado em um campo como Healthcare IT, onde grande parte do atendimento ao paciente depende da qualidade e da entrega pontual dos sistemas?

Sim, o desenvolvimento ágil tem absolutamente um papel no desenvolvimento de TI em assistência médica. Ninguém, nem o usuário final, nem o paciente e certamente a equipe de desenvolvimento não são bem atendidos por um processo de desenvolvimento mal realizado. Considerando alguns dos princípios subjacentes ao manifesto Ágil (lista descaradamente vergonhosa da Wikipedia com meu comentário):

• Satisfação do cliente pela entrega rápida de software útil . Quando isso não é um objetivo?
• Bem-vindo, alterando os requisitos, mesmo no final do desenvolvimento . A TI da área de saúde se integra a um campo que, embora absolutamente inundado de tecnologia, não é particularmente focado na TI. O potencial de um sistema ser projetado para "acertar" logo de cara é muito baixo.
• O software de trabalho é entregue com frequência (semanas em vez de meses) . Como usuário final de algumas dessas coisas, Deus adoraria isso. As mudanças rápidas e de trabalho são inestimáveis, e o que faz com que a TI da área de saúde "daquilo que precisamos fazer" para "aquilo que muda a maneira como faço meu trabalho".
• O software de trabalho é a principal medida de progresso . Faz sentido na maioria dos aplicativos, portanto, não há realmente nenhuma razão para que isso não se estenda ao HIT.
• Desenvolvimento sustentável, capaz de manter um ritmo constante . Você vê isso em toda a área da saúde, desde a vigilância de infecções até o HIT até as instalações. A assistência médica não é um ciclo de expansão ou contração, é uma constante batida.
• Cooperação estreita e diária entre empresários e desenvolvedores . A maioria do HIT não é uma ferramenta de desenvolvedor. É uma ferramenta feita por desenvolvedores. O contato com o cliente é e deve ser fundamental. Também é muito mais fácil obter um sistema adotado se ele funciona e se integra ao fluxo de trabalho dos clientes, em vez de precisar ser corrigido, corrigido etc.
• A conversa cara a cara é a melhor forma de comunicação (co-localização) . Da minha interação com os médicos, é muito mais fácil fazer as coisas pessoalmente, de preferência com blocos de papel, do que qualquer outra maneira.
• Os projetos são construídos em torno de indivíduos motivados, nos quais se deve confiar . Isso é algo que vai melhorar sua vida - então sim, deve ser adotado;)
• Atenção contínua à excelência técnica e bom design . Este é novamente um daqueles "todo mundo deveria fazer isso, então é claro que você deveria". Mas considere a complexidade dos sistemas HIT e as inúmeras maneiras pelas quais eles acabam sendo usados ​​dia após dia. Um sistema de má qualidade não é suficiente.
• Simplicidade . Deve funcionar imediatamente. Deveria funcionar bem, o tempo todo, e da maneira que deveria. As pessoas são idiotas. Trabalhadores da saúde são pessoas. Portanto ... você sabe o resto. Simplicidade ajuda.
• Equipes auto-organizadas . Este pode ser um pouco mais difícil para o HIT. Honestamente, não tenho confiança suficiente para dizer de uma maneira ou de outra se a auto-organização nesse cenário é boa ou não.
• Adaptação regular às novas circunstâncias . O HIT é um setor ativo e crescente, com encargos regulatórios complexos e variáveis. Ser capaz de se adaptar parece uma ideia decente.

As discussões em torno do uso do Desenvolvimento Ágil de Software para Dispositivos Médicos em um ambiente regulamentado pela FDA já existem há algum tempo e são relevantes para esta questão. Aqui estão algumas razões do porquê:

1. Os prós e contras do desenvolvimento Waterfall vs. Iterative são essencialmente os mesmos e precisariam ser considerados para qualquer projeto de TI de saúde.
2. Os sistemas de qualidade exigidos pela FDA (consulte Princípios gerais de validação de software; Diretrizes finais para a indústria e a equipe da FDA ) para o desenvolvimento de software de dispositivos médicos usados ​​são o padrão-ouro da indústria. Deve-se notar que esses regulamentos não ditam nenhuma metodologia de desenvolvimento específica. De qualquer forma, a qualidade do software de TI de saúde seria muito melhorada se essas melhores práticas fossem seguidas por todos.
3. Atualmente, a maior parte do desenvolvimento de software de TI da Heath não opera sob esses padrões regulamentares da FDA. À medida que as barreiras à interoperabilidade de dispositivos médicos continuam a cair, principalmente para plataformas móveis, isso provavelmente vai mudar - consulte o FDA Addresses Mobile Medical Apps .
4. Além disso, se você estiver desenvolvendo um software comercial de TI de saúde, terá que se perguntar se está criando um sistema de dados de dispositivos médicos (MDDS): Meu produto é um MDDS?

A resposta curta é sim". Uma resposta mais longa, porém mais precisa, é "Se você levar a sério".

Há alguns temas a serem lembrados, que eu gosto de separar em preocupações relacionadas a (a) segurança do paciente e qualidade do produto e (b) regulamentação da indústria.

No lado da segurança e qualidade, lembre-se de que é difícil criar software seguro. Alguns bons programadores com algum conhecimento de domínio podem criar softwares incrivelmente úteis que são bastante seguros. Se eles fazem parte da implantação em um ambiente clínico local e podem continuar respondendo e se ajustando aos eventos durante a implantação e o uso do software, o software pode fornecer valor, salvar ou melhorar vidas com apenas alguns ferimentos ou mortes relacionados a erros de uso ou erros de software. Mas o software exigirá que os programadores estejam lá, o tempo todo, respondendo e co-evoluindo o software à medida que o uso do software evoluir. Este não é um processo escalonável e, quando os programadores morrem ou ficam entediados, o sistema pode facilmente se tornar muito perigoso rapidamente. Para melhorar esses resultados e criar software seguro, existem etapas importantes do processo de desenvolvimento que precisam ser executadas enquanto o software é desenvolvido. Uma boa introdução "pronta para uso" pode ser encontrada no padrão internacional para desenvolvimento de software para dispositivos médicos, ISO / IEC 62304. O conceito principal é o gerenciamento de riscos de segurança em todas as etapas - durante a análise de casos de uso e desenvolvimento de histórias, requisitos elucidação, projeto de arquitetura e sistema, implementação, testes de unidade e integração. Ser ágil não fará com que todo esse trabalho desapareça ou seja menos difícil, mas concentrando-se na criação de valor e na eliminação do trabalho (como recursos desnecessários ou ciclos excessivos de teste / correção de verificação) que não criam valor, o desenvolvimento ágil pode permitir que uma equipe integre esse trabalho ao desenvolvimento, resultando em um software mais seguro desenvolvido ao mesmo tempo. As práticas de desenvolvimento iterativo comumente usadas pelas equipes ágeis são muito adequadas para concluir o trabalho de gerenciamento de riscos de segurança, evoluindo ao longo da vida do projeto, em vez de ser uma reflexão tardia. E depois que o software estiver operacional, é necessário considerar o feedback dos usuários e quaisquer eventos que possam levar a ferimentos, individualmente e em conjunto, para manter o software seguro. O Agile pode ajudar aqui se fornecer um processo rápido e seguro para incorporar alterações sem quebrar outras partes do sistema - o que, por sua vez, exige uma boa arquitetura e interações de design bem conhecidas que foram criadas quando o software foi desenvolvido. evoluindo ao longo da vida do projeto, em vez de ser uma reflexão tardia. E depois que o software estiver operacional, é necessário considerar o feedback dos usuários e quaisquer eventos que possam levar a ferimentos, individualmente e em conjunto, para manter o software seguro. O Agile pode ajudar aqui se fornecer um processo rápido e seguro para incorporar alterações sem quebrar outras partes do sistema - o que, por sua vez, exige uma boa arquitetura e interações de design bem conhecidas que foram criadas quando o software foi desenvolvido. evoluindo ao longo da vida do projeto, em vez de ser uma reflexão tardia. E depois que o software estiver operacional, é necessário considerar o feedback dos usuários e quaisquer eventos que possam levar a ferimentos, individualmente e em conjunto, para manter o software seguro. O Agile pode ajudar aqui se fornecer um processo rápido e seguro para incorporar alterações sem quebrar outras partes do sistema - o que, por sua vez, exige uma boa arquitetura e interações de design bem conhecidas que foram criadas quando o software foi desenvolvido.

A segunda preocupação é regulatória. Em um mundo ideal, os regulamentos de segurança se aplicariam a todos os produtos que poderiam ser suficientemente perigosos, e um fornecedor seria capaz de cumprir fazendo algumas coisas simples assim que começassem a cruzar a linha. Na prática, as regulamentações globais são complexas e de rápida evolução nesse setor, o que significa que um dia você poderá desenvolver um pequeno aplicativo para iPhone que mostre alguns dados médicos e, no próximo, deverá cumprir os padrões ISO e FDA para "gerenciamento de qualidade" sistema "ou SGQ. Isso pode ser assustador para empresas que não tinham um SGQ formal no passado. E o agile pode agravar isso porque você pode começar com um conceito de produto e, através do desenvolvimento evolutivo, entrar inconscientemente em um uso pretendido regulamentado (como exibir dados de diagnóstico clínico para um usuário). É outubro de 2011; meu conselho a qualquer empresa que pretenda comercializar um produto com "saúde", "médico", "assistência médica" no nome da categoria é que eles devem ter um plano para quando o produto que fabricam for regulamentado por um ou mais reguladores de dispositivos médicos em todo o mundo. Aqui, novamente, o ágil pode ajudar, porque as práticas ágeis geralmente produzem (ou facilmente podem produzir) saídas compatíveis para satisfazer os clientes reguladores, tanto para envios de autorização de pré-mercado (como FDA 510k), certificação (como ISO 13485) e operações pós-comercialização. O desenvolvimento do primeiro teste se encaixa perfeitamente no software médico. A integração contínua, os testes automatizados de unidade e os metadados do SCRUM sprint podem fornecer evidências objetivas completas de que o gerenciamento de riscos e a verificação adequada são feitos não apenas como uma reflexão tardia, mas incorporados ao processo de desenvolvimento. Na maioria dos casos, acho que o ágil produz mais artefatos do que "cascata", talvez não da mesma forma. Mas a conversão dos produtos em algo que satisfaça os reguladores é um problema relativamente pequeno a ser resolvido.

Então, em resumo ... sim, na Virgínia, há um ágil desenvolvimento de software para TI em saúde (e outros dispositivos médicos). Como todas as coisas ágeis, é preciso dedicação ao processo, suporte aos negócios e coragem.

Sim, uma das premissas do desenvolvimento ágil é o envolvimento do cliente. Isso é crítico nos sistemas e processos de TI da área de saúde. Os departamentos de TI da área de saúde tomarão melhores decisões se um representante do cliente estiver envolvido e fornecer informações sobre como as decisões afetarão o atendimento ao paciente.

Eu acho que é possível, mas a indústria precisa de uma enorme mudança de paradigma. Estou no meu segundo ano como desenvolvedor de serviços de saúde, e confiança e auto-organização não são aparentes em lugar algum. Os serviços de saúde se beneficiariam muito da adoção formal do ágil, já que, na maioria das vezes, é um caos, com o desenvolvimento iterativo chamado "thrash" e os requisitos de alterações tardias, porque, bem, o grande projeto inicial não funciona de qualquer maneira.

Eu entendo sua pergunta. Um bom exemplo de desenvolvimento ágil é a criação de um site para alguém. Normalmente, um cliente não sabe exatamente o que ele / ela deseja, portanto, há muita interação com o cliente.

A área de TI da área de saúde pode parecer um campo muito predefinido na ciência da computação; com seus padrões rígidos (DICOM, HL7), parece que há apenas uma maneira de implementá-los, mas também há muitas preferências e tomadas de decisão.

Na minha opinião, qualquer que seja o produto que você esteja fabricando, você não poderá determinar TODOS os requisitos com antecedência, portanto, um método ágil de desenvolvimento de software funciona muito bem.

Como observado, a resposta é sim.

Ao aplicar o Agile a áreas regulamentadas ou de alto risco, você deve definir "Concluído" a cada iteração, de forma que a conformidade regulatória e outras estratégias de mitigação de risco sejam incluídas. Por exemplo, isso pode exigir que a documentação do controle de qualidade, a rastreabilidade dos requisitos, a auditoria de segurança e outras ações sejam concluídas a cada iteração.

Por exemplo, existe boa arte e prática para a aplicação de abordagens ágeis para ambientes regulamentados pela FDA.

A resposta curta: Sim. Existe um bom blog sobre o Agile em ambientes de alta garantia que fornece algumas dicas.

No entanto, existem alguns compromissos que precisam ser feitos. Considere o Manifesto Ágil :

Indivíduos e interações sobre processos e ferramentas

Software de trabalho sobre documentação abrangente

Colaboração do cliente sobre negociação de contrato

Respondendo à mudança após seguir um plano

Os órgãos reguladores valorizam o lado esquerdo tanto quanto as equipes ágeis, mas exigem mais ênfase no lado direito do que uma equipe ágil típica faria. O FDA, por exemplo, exige que você valide seus processos e ferramentas, solicita documentação de projeto e teste bastante abrangente e, definitivamente, exige uma boa dose de planejamento.

Por outro lado, muitos princípios ágeis se encaixam muito bem no mundo da saúde, incluindo:

• TDD e Programação de Pares - aumente a qualidade
• Loops apertados de feedback do cliente - a validação antecipada é excelente
• Planejamento iterativo - os órgãos reguladores têm tudo a ver com planejamento

Algumas disciplinas já são de natureza ágil. A enfermagem, por exemplo, depende de um ciclo de avaliação, avaliação, planejamento e intervenção, que depende de várias iterações de diagnóstico / prognóstico para alcançar resultados finais incrementais.

No entanto, seria uma confusão fatal tentar sugerir que os serviços de saúde prestados dessa maneira sejam especificamente adequados para uma aplicação essencialmente de instância única do desenvolvimento de software Agile em direção a uma ferramenta ou sistema de software para uso na referida prestação de serviços.

A AAMI está trabalhando ativamente em um Relatório de Informações Técnicas, intitulado:
AAMI TIR SW1, Diretrizes sobre o uso de práticas ágeis no desenvolvimento de software para dispositivos médicos.

Ouvi dizer que pode ser publicado em 2012.

Ele discute o alinhamento dos princípios do Manifesto Ágil (consulte a resposta da EpiGrads) com os requisitos regulamentares, processos típicos e outros aspectos práticos do produto associados ao software de dispositivos médicos.