(Vale + rep) App para quem é de SP Capital e Grande São Paulo

[VitorD]

Obrigado pelo feedback.
1) Solicitamos cadastro para entender quem é o usuário do app. Pq no futuro queremos oferecer muitos outros features (filtro por operadora e plano de saúde, predileção da melhor hora de visita, etc).
2) Realizamos cerca de 8 atualizações por dia de cada hospital. Totalizando quase 600 por dia. Fizemos questão de manter o horário da atualização pq quanto mais perto, mais confiável.
3) Temos 4 pessoas responsáveis por atualizar as infos durante o dia.

Se quiser detalhes mais específicos, pode me mandar MP.

@Urbach fiz a divulgação e o feedback está sendo muito bom!

O que mais estão me perguntando é como vocês monitoram o tempo de atendimento do Hospital.
Alguns comentaram que normalmente frequentam os mesmos 2 ou 3 hospitais e os números apresentados do tempo de espera é "contraditório" da experiencia deles (ou seja o que normalmente é mais rápido, está com tempo de espera maior do que normalmente é mais demorado)
Me ajuda a responder esses pontos para eles?

Obrigado, Vitor. Parte da operação está manual em hospitais não sistematizados e outros temos a informação online (uns 35% da base). Temos 4 pessoas que estão fazendo apenas isso. No manual, tem que ligar e colher a info mesmo. Se por qualquer motivo, a informação não está disponível, o tempo não será atualizado. Se vc reparar, temos um log do horário da atualização. Estamos atualizando das 7 às 23h, em 8 ciclos diários.
São quase 600 inputs dia (se realizados com sucesso em sua totalidade). Quanto mais próximo do horário do log, mais confiável a informação.

Acho que entendi!
Então o tempo de espera médio é fornecido pelo próprio hospital, e não por alguma medição independente?

Sugestão: O tempo médio fornecido pelo hospital tende a não ser próximo da realidade. Isso pode ser um problema, pois o nivel de confiança da informação é o seu maior valor aqui. Se o publico parar de acreditar no tempo médio informado, eles param de usar a aplicação.
Existem maneiras de medir isso de forma pro-ativa (via geolocalização) ou por informação do próprio usuário (algo semelhante a um check-in)
Vocês deveriam pensar em alguma forma de ter dados para confrontar o informado pelo hospital

[kilates]

Bacana a ideia, gostei, parece realmente resolver um problema bem comum que todos enfrentam.

IMO, talvez o maior desafio do seu negócio é em relação a recorrência na utilização do seu app por parte do usuário.

Não sei qual a média de atendimentos em um Pronto Socorro que a população em geral precisa por ano ou alguma métrica do tipo, mas sempre que alguém precisar ir em um pronto socorro ela precisa lembrar do seu app e isso parece ser uma barreira complicada de trabalhar.

Talvez também o fato das classes menos favorecidas serem seu potencial público alvo (posso estar redondamente enganado), pelo fato de ter menos estrutura e se adoecerem mais e não ter hospital particular ou coisa do tipo para poder ser atendida, talvez essa questão limita tb seu tamanho de mercado (por conta dessas classes menos favorecidas que mais precisam do seu serviço não terem smartphones que suportem esses apps e tal sei lá).

Enfim, são apenas achismos que pensei aqui agora,

Parabéns pela ideia e boa sorte!

[Urbach]

@VitorD

Em geral, os hospitais mais sérios, tendem a superestimar mais do que subestimar. Mesmo pq sistema como da Philips (antigo Tazy) e até mais simples como To Life, monitoram da abertura de ficha à saída do paciente. Digo isso, pelos testes que fizemos antes de colocar pra rodar. Deve existir exceção, claro. O problema de fazer isso colaborativo é que ao contrário de um Waze, por exemplo, onde todo dia as pessoas vão pra rua, a visita a um PS é um evento de exceção (um usuário padrão de plano de saúde visita algo como 2.x ao ano), o que faz a necessidade de base (para criar uma mediana razoável) ser muito grande e espalhada em todos lugares. Temos uma ideia de fazer colaborativo de outra forma, mas não é viável no curto prazo.

[Urbach]

@kilates

Bingo! Meu segundo maior problema (pós tração inicial) é a recorrência mesmo. Certamente teremos que adicionar conteúdos de interesse e consumo do usuário para manter o App instalado.
Existem personas onde isso se torna menos complicado (pais com filhos pequenos, doentes crônicos, etc).
Com tudo isso, mesmo sendo um evento de exceção, Pronto-Socorro tem uma importância institucional multo grande em um hospital (como porta de entrada de relacionamento) e os PSs presentes na base inicial atendem algo como 7-10 milhões atendimentos ano.

Quem é menos tolerante com o tempo de espera, hoje, é o usuário de planos de saúde intermediários+ a premium. A própria cultura de tornar a info pública vem de hospitais bem posicionados.

Em relação, a classes menos favorecidas, temos a pretensão de tb trabalhar no sistema público e se preciso até acrescentando URA e não só App. Apesar que depois que vc vê Secretarias da Prefeitura e o próprio Poupatempo trabalhando online, vc percebe que não parece um grande problema. Mas tudo isso, é só pretensão. Hoje estamos no início, do início do MVP.

[VitorD]

@VitorD

Em geral, os hospitais mais sérios, tendem a superestimar mais do que subestimar. Mesmo pq sistema como da Philips (antigo Tazy) e até mais simples como To Life, monitoram da abertura de ficha à saída do paciente. Digo isso, pelos testes que fizemos antes de colocar pra rodar. Deve existir exceção, claro. O problema de fazer isso colaborativo é que ao contrário de um Waze, por exemplo, onde todo dia as pessoas vão pra rua, a visita a um PS é um evento de exceção (um usuário padrão de plano de saúde visita algo como 2.x ao ano), o que faz a necessidade de base (para criar uma mediana razoável) ser muito grande e espalhada em todos lugares. Temos uma ideia de fazer colaborativo de outra forma, mas não é viável no curto prazo.

Entendo! Mas o meu ponto não é medir de forma colaborativa (apesar de que quando tiver uma grande base instalada, esse deveria ser o caminho) e sim ter números para confrontar as informações.

Existem tecnologias baratas que podem te ajudar
Por exemplo: você coloca um beacon na porta do PS (ou no balcão de primeiro atendimento) e ou outro na entrada da sala de atendimento médico.
Com o App você captura essas informações e tem dados para medir o tempo real de espera (ou ao menos confrontar o informado pelo Hospital).
Dá para fazer um PoC bem barato para isso (desde que vc tenha acesso a um ou mais hospitais para instalar os beacon)

[in_NUTS1]

Animal a ideia, congrats!
Desenvolveram ele nativo ou usaram algum framework como Ionic ou React Native ?

Obrigado. Fizemos com Ionic + Firebase. Mas a ideia é migrar pra nativo, quando justificar.

Utilizaram a versao 1 ou 2 do ionic e pq? E quando acha que justifica mudar pra nativo?

Pergunto pois daqui 1 semana vou entrar em um projeto que vou ter que desenvolver um APP e vou usar pela primeira vez o Ionic. A umas semanas venho estudando ele e vendo alguns cases de APP feitos com ele que são tão completos que não consigo achar um motivo de precisar migrar pra nativo.

[VitorD]

@VitorD

Em geral, os hospitais mais sérios, tendem a superestimar mais do que subestimar. Mesmo pq sistema como da Philips (antigo Tazy) e até mais simples como To Life, monitoram da abertura de ficha à saída do paciente. Digo isso, pelos testes que fizemos antes de colocar pra rodar. Deve existir exceção, claro. O problema de fazer isso colaborativo é que ao contrário de um Waze, por exemplo, onde todo dia as pessoas vão pra rua, a visita a um PS é um evento de exceção (um usuário padrão de plano de saúde visita algo como 2.x ao ano), o que faz a necessidade de base (para criar uma mediana razoável) ser muito grande e espalhada em todos lugares. Temos uma ideia de fazer colaborativo de outra forma, mas não é viável no curto prazo.

Só mais um ponto aqui.
O importante mesmo (que é o que o aplicativo "vende") é qual o menor tempo de espera end-to-end.
Se um hospital diz que demora 40min e na verdade demora 20, e outro diz que demora 30 e realmente demora 30, o aplicativo vai me mandar para o lugar errado (supondo deslocamento igual).


Por isso a aferição é importante

[lukanicos]

Nice Urbach! Show de bola o app.

Nesse semestre que passou fiz uma disciplina de Formação de Novos Negócios onde tínhamos que desenvolver uma start-up. Um dos grupos apresentou uma ideia semelhante no âmbito da saúde mas nada comparado com o seu. GL na empreitada!

[Urbach]

@VitorD

Desculpe o gap na resposta. A ideia da medição independente que eu tinha imaginado não era com beacons, mas era semelhante no ponto principal. Aliás depois quero conversar mais sobre isso, se vc tiver disponibilidade.

Hoje o serviço é isento de erros? Não, mas acreditamos que mesmo no formato atual é muito melhor do que ficar sem a informação e as margens de erro estão dentro do aceitáveis. A ideia é evoluir e ser perfeccionista, mas temos que sair de algum lugar.

[Urbach]

Animal a ideia, congrats!
Desenvolveram ele nativo ou usaram algum framework como Ionic ou React Native ?

Obrigado. Fizemos com Ionic + Firebase. Mas a ideia é migrar pra nativo, quando justificar.

Utilizaram a versao 1 ou 2 do ionic e pq? E quando acha que justifica mudar pra nativo?

Pergunto pois daqui 1 semana vou entrar em um projeto que vou ter que desenvolver um APP e vou usar pela primeira vez o Ionic. A umas semanas venho estudando ele e vendo alguns cases de APP feitos com ele que são tão completos que não consigo achar um motivo de precisar migrar pra nativo.

A primeira versão. O Ionic 2 acho que seria lançado oficialmente apenas em 2017. Aliás, foi lançado?
O híbrido é bem aceitável, mas acho que o look and feel, apesar de legal, ainda é pior do que o nativo. Além disso, para aplicações onde se necessita de mais performance e recursos do telefone, acho que ainda não acompanha de frente aplicações nativas. A grande vantagem é tempo de desenvolvimento e não precisar de profissionais com especializações bem distintas (normalmente).

Não trabalhei com o React Native, por familiaridade e conhecimento de quem desenvolveu para nós. Não sou técnico,então algumas respostas vem da minha percepção e pesquisa.