MVP na área da saúde: como lançar rapidamente sem arriscar a

No caso de produtos mínimos viáveis para cuidados de saúde, não tens escolha de lançar quando ainda estás envergonhado. Mesmo que a velocidade de comercialização seja muito essencial neste mercado altamente competitivo, a segurança, proteção e conformidade regulamentar do produto de cuidados de saúde são ainda mais importantes. Então, como seria um MVP ideal para a área da saúde e como os inovadores podem ser rápidos sem comprometer a qualidade clínica ou a segurança? Conseguimos acumular experiências de mais de 300 projetos para definir como lançar um MVP para a área da saúde o mais rápido possível e sem deixar nada para trás.

Em geral, um MVP, também conhecido como produto mínimo viável, é a versão protótipo do teu produto que tens de lançar para ver se o conceito do produto resolve o problema específico que o utilizador está a enfrentar. O conceito fundamental por trás da fase de desenvolvimento do MVP é que ele deve ser criado na forma de um produto que tenha apenas os recursos básicos considerados suficientes para permitir que o produto seja funcional. Depois de lançado, os desenvolvedores compilam o feedback do utilizador para que possam incorporar integrações adicionais, dependendo da demanda do mercado-alvo. No entanto, um produto mínimo viável na área da saúde é bem diferente dos MVPs comuns voltados para o consumidor:

Principais diferenças entre MVPs padrão e MVPs para cuidados de saúde

Ao contrário do que se pensa, um produto mínimo viável na área da saúde precisa de estratégias diferentes. Resumindo, o ponto de partida é ditado pelo seu maior risco:

Quando usar cada abordagem

Prova de Conceito (PoC) - Quando estiver na fase «Será que podemos construir isto com segurança?», o seu projeto de saúde precisa de uma prova de conceito para ver se a sua ideia de tecnologia de alto risco pode ser implementada com sucesso tecnicamente. Uma PoC normalmente é focada internamente. Protótipo - A resposta para «Os médicos e pacientes usarão isso corretamente?» é responder com um protótipo. Um protótipo é um modelo ilustrado e interativo de uma ideia de produto que mostra a aparência e as ações do produto. MVP - O primeiro marco real que fornece a resposta para "Isto funciona e está em conformidade?" é um MVP. Ao contrário dos PoCs e protótipos, os MVPs enfrentam e também podem ser submetidos a testes no mundo real em condições controladas.

Os MVPs na área da saúde não são mínimos. O processo de criação de um MVP tem mais a ver com o desenvolvimento de um Produto Mínimo Viável e Validado no qual os utilizadores possam confiar, tanto clinicamente quanto eticamente. A velocidade é importante, mas, para ganhar impulso, os inovadores precisam lidar com questões de desenvolvimento específicas do setor.

Avançando rapidamente com um manual regulatório

No caso de uma empresa que está a desenvolver uma aplicação para ser usada na prática clínica, a barreira regulatória é considerável — e bastante razoável. Esses produtos de software, devido à sua capacidade de influenciar os resultados dos cuidados de saúde, influenciar as decisões clínicas e até mesmo resultar em danos relacionados à saúde, estão sujeitos à FDA, EU MDR e outras estruturas regulatórias no mundo. As regulamentações médicas geralmente implicam que as equipas de desenvolvimento devem ter:

• Processos organizados (Sistema de Gestão da Qualidade ISO 13485)
• Registos do design e dos controlos de risco (IEC 62304 Ciclo de Vida do Software e ISO 14971 Gestão de Risco)
• Os sistemas validados estão presentes, mesmo que seja apenas um MVP

Ao contrário de outros MVPs baseados em campo, os MVPs de saúde não visam apenas o envolvimento do utilizador. O seu objetivo principal é provar a sua segurança e eficácia em ambientes reais de atendimento ao paciente e no fluxo de trabalho clínico. Isso pode envolver:

• Avaliações profissionais com produto
• Testes de usabilidade
• Programas-piloto aprovados por um IRB

Nem todos os MVPs de saúde precisam passar por extensos ensaios clínicos; no entanto, todos eles precisam basear-se em ciência plausível, porque a fronteira entre bem-estar e medicina é tênue.

Confiança do utilizador em jogo

O software de saúde não é apresentado a um grupo de utilizadores com alto risco (pacientes) e baixo risco (prestadores de cuidados de saúde), que o software não pode deixar de satisfazer sem procurar qualquer solução alternativa. Para criar esse nível de confiança ao desenvolver o MVP, a equipa de desenvolvimento precisará:

• Trabalhe junto com a equipe da linha de frente para mapear as características clínicas para os caminhos clínicos já existentes
• Entenda e baseie os recursos em diretrizes médicas ou evidências
• Crie a experiência do utilizador de acordo com as melhores práticas de acessibilidade (WCAG, ADA)
• Seja transparente sobre as limitações da aplicação

Garantindo a segurança e a interoperabilidade dos dados

Um MVP na área da saúde nem sequer vai chegar a conversas sobre projetos-piloto ou parcerias com um nível mínimo de segurança de dados. É por isso que a encriptação, o acesso baseado em funções, os registos de auditoria e outros padrões existentes na indústria de segurança de dados são inegociáveis para uma aplicação de saúde desde o primeiro dia. Além da segurança dos dados, as equipas de desenvolvedores de saúde devem considerar a interoperabilidade na fase inicial, caso o produto tenha de fazer parte de um ambiente tecnológico de saúde mais amplo. A interoperabilidade envolve a criação de uma aplicação que partilhará dados com EHRs, sistemas hospitalares e dispositivos vestíveis. Do ponto de vista técnico, a interoperabilidade é garantida com a ajuda de:

• Padrões de dados, incluindo HL7 ou FHIR
• Vocabulários padrão, incluindo SNOMED CT, LOINC ou ICD-10

A criação de um MVP no setor de saúde vai demorar, em média, entre 2 e 6 meses. O cronograma depende principalmente da complexidade do produto, das regulamentações e dos recursos que foram incorporados no MVP.

Descoberta do produto

O processo de desenvolvimento do produto começa com uma descoberta do produto aprofundada, que ajuda os envolvidos no projeto a ter uma noção bem clara do objetivo do produto, dos utilizadores e do ambiente regulatório. Resultados esperados: Especificações de produtos de qualidade para cuidados de saúde, wireframes, um protótipo funcional e um modelo de negócio aprovado para o produto.

Planeamento do desenvolvimento

Embora na fase de descoberta do produto seja definida uma lista de funcionalidades essenciais, quando a equipa refina as funcionalidades e as classifica posteriormente, baseia-se no seguinte:

• Necessidade clínica - O que é necessário para garantir a segurança do paciente e a usabilidade?
• Risco regulatório - Que características podem levar a um aumento das exigências de conformidade?
• Orçamento e cronograma - Como podemos encontrar um equilíbrio entre o escopo e a viabilidade?

Resultados esperados: Definição da pilha de tecnologia, composição da equipa e cronograma, projeto da arquitetura da solução, estimativa preliminar de custos.

Desenvolvimento e teste do MVP

Embora o MVP de saúde tenha características únicas na implementação, as fases de design e desenvolvimento seguem os mesmos modelos de desenvolvimento ágil ou iterativo de outros projetos, embora com uma organização mais forte e um nível mais alto de documentação. Caso a equipa crie aplicações destinadas a recolher resultados clínicos ou enviá-los às autoridades (FDA/CE Mark), os programadores devem cumprir as normas ISO 13485 e IEC 62304. Entregáveis: Sistema final de design de UI/UX, MVP funcional, código-fonte e documentação técnica, relatórios de testes.

Validação e lançamento do MVP

Isso significa que um MVP de saúde deve ser testado no mundo real, por exemplo, através de testes clínicos e regulatórios, quando o MVP estiver quase concluído. Em vez de um lançamento geral, ele é iniciado inicialmente em ambientes controlados, que podem incluir:

• Programas-piloto com prestadores de cuidados de saúde
• Estudos aprovados pelo IRB
• Implementações para uso interno em colaboração com consultores clínicos
• Ambientes sandbox combinados com instâncias de teste de EHRs ou sistemas de terceiros

Os preços do desenvolvimento de MVP no mercado de saúde dependem do projeto e das especificidades da aplicação, do processo de regulamentação e das tecnologias. É por isso que sempre sugerimos que a pessoa receba uma estimativa gratuita da empresa de desenvolvimento para ter uma visão realista do valor antecipadamente.

Exemplo de discriminação de custos

Com base no nosso projeto de plataforma de monitorização remota de pacientes, aqui está uma análise detalhada dos custos (estimados em US$ 50/hora):

Se há algo que aprendemos durante 15 anos no mercado, é que os projetos de desenvolvimento de software para saúde são uma história muito complicada, que envolve inúmeras variáveis.

Comece com a questão específica e correta (e não com a tecnologia bacana)

As empresas não podem tentar transformar todo o cuidado da v1 numa reviravolta. Começar com uma pequena (tão pequena quanto possível) fatia, como a digitalização de um fluxo de trabalho manual ou uma área específica de foco em dor clínica, ajudará o produto a ganhar tração e credibilidade iniciais. Exemplo: A Teladoc não começou como um modelo abrangente de cuidados virtuais. Inicialmente, o produto era uma solução simples, que proporcionava aos pacientes acesso 24 horas por dia, 7 dias por semana, a médicos licenciados, em casos não urgentes.

Invista na documentação como parte do produto

Embora as empresas que pretendem seguir uma via regulamentar muitas vezes já tenham isso em vigor, as empresas que estão a desenvolver uma solução inicialmente não regulamentada muitas vezes omitem esta etapa.

Design com restrições regulamentares

Na maioria dos casos de inovação, os inovadores na área da saúde acreditam que a conformidade ou a experiência do utilizador (UX) fácil de usar são as duas opções. No entanto, isso não precisa necessariamente ter um custo tão alto, desde que a conformidade regulatória seja utilizada pela equipa de design como restrições criativas.

Familiarize-se com a classificação do seu SaMD

Caso a sua solução de saúde tenha uma ou mais utilizações médicas, que realizam essas utilizações médicas sem se qualificar como um dispositivo médico de hardware, é provável que se enquadre na categoria de Software como Dispositivo Médico.

Não basta dizer que a IA deles tem 99% de precisão, é preciso demonstrar isso

Na área da saúde, uma empresa não pode sair por aí dizendo que os seus algoritmos são os melhores. Os reguladores, como a FDA (e os médicos, aliás), querem uma demonstração concreta e real de que a sua ferramenta cumpre o que promete.

A velocidade nunca é barata na inovação na área da saúde

Você só pode ir até certo ponto com o desenvolvimento rápido de funcionalidades críticas em detrimento da segurança, conformidade e confiança do utilizador. O MVP na área da saúde não envolve a criação do menor produto possível. Trata-se de criar a iteração mais segura da sua visão que ainda a concretize em termos de impacto no mundo real. Quando você começa com um pensamento regulatório em primeiro lugar, paraleliza a validação clínica e estrutura de forma modular para expandir no futuro, você pode entrar no mercado mais rapidamente — sem ter que fazer cortes que acabam voltando para assombrá-lo.