Televitas 2A
Votre écosystème e-santé universel
79 500 €
montant total du tour de table
- Eligible à une réduction d’impôts
Cette campagne de financement est clôturée
Modèle de revenus
Le modèle de revenus de Televitas comprend les éléments suivants:
Revenus primaires
- La plate-forme e-santé Televitas :
La plate-forme est proposée sous la forme de licences dans une version Pro (par exemple pour les hôpitaux) et une version Light (par exemple pour les centres de soins). La plateforme fait le lien entre l'environnement de travail du professionnel de santé et les différents générateurs de données (wearables, capteurs,...). La version Pro offre des fonctionnalités supplémentaires autour de l'analyse de données et de la prise en charge de l'IA. - Televitas Hub :
Le Hub est proposé sous la forme d'un abonnement as-a-service. - Les connecteurs de données :
Les connecteurs data assurent la connexion entre les dispositifs portables/capteurs/applications et la plate-forme ou le hub de santé en ligne. Ceux-ci sont proposés sous la forme d' abonnements as-a-service.
Revenus secondaires
- Tarification numérique :
Frais de transaction récurrents sur la fourniture de services de tarification numérique pour la prestation de services de soins à distance par des professionnels de santé. - Services de données :
Développement de modèles d'IA (soins prédictifs/prévention) et livraison de rapports personnalisés. Ces services sont fournis à des tarifs journaliers - Conseil :
Location de ses propres consultants pour des projets d'intégration dans le secteur de la santé sur la base de tarifs journaliers.
Televitas détient 100% des droits de propriété intellectuelle sur le développement du Televitas Data Hub, des algorithmes Televitas, des interfaces et de ses propres connecteurs logiciels / matériels. Un plan financier et des prévisions à jour sont disponibles dans la « Equity Term Sheet ».
Modèle d’affaires
- B2P : Business to Professionals
Extension des services existants des professionnels de santé (hôpitaux, médecins, centres de soins, soins à domicile,...) avec soins à distance. - B2B2C : Business to Business to Consumer
Par les services de communication, d'éducation ou de bien-être pour les entreprises de télécommunications et de médias, les banques, les gouvernements (locaux), ...
Répartition des ressources acquises
Recherche & développement: 50%
Marketing & Ventes: 40%
Général & administratif: 10%
Marketing et ventes
Televitas s'adressera directement aux clients finaux (B2P et B2B2C) par :
- Image de marque de Televitas (RemotisWelfare, RemotisCure et RemotisCare)
- Mise à disposition d'une application mobile aux fournisseurs de soins de santé pour augmenter le nombre d'ambassadeurs
- Verrouillage du widget via des systèmes de fichiers logiciels de soins de santé reconnus pour les infirmières (EVD), pour les médecins (DSE), les établissements de santé (DSE) et les prestataires de soins résidentiels (WZD).
- Événements et salons dans le domaine de la santé
- Différentes campagnes de marketing B2B à travers des cas clients spécifiques
- Développement d'une équipe de vente directe, initialement pour le Benelux, la France, le Royaume-Uni et l'Allemagne
- Connexion aux écosystèmes existants tels que la facturation électronique, les centres d'alarme et de soins, les services de prêt (auprès des compagnies d'assurance maladie), les magasins de soins à domicile, etc.
- Appartenance à divers groupes autour de la technologie des soins de santé / innovation des soins et du secteur de la santé / bien-être
Recherche & Développement
Quel est le concept utilisé dans le développement du logiciel?
Conceptuellement, nous sommes partis du prestataire de soins / établissement de soins, de son équipe et de ses patients. Ces acteurs participent aux soins à distance et, d’une part, devraient être soulagés de la charge des soins continus sur place au moyen d'une technologie simple et, d'autre part, être soulagés de la charge administrative du remboursement de ces soins à un distance. La plateforme est développée et gérée à partir d'une optique de modèle de soins hybrides, où le développement n'est jamais séparé du modèle de soins opérationnel et de l'utilisation de la plateforme.
Le plus grand nombre possible de processus de développement sont automatisés: test, intégration, déploiement et mise à disposition du logiciel (déploiement continu et amélioration continue), par lesquels à tout moment une nouvelle version du logiciel entre en production ou est rappelée de manière entièrement automatisée et vérifiable. Techniquement, la solution de base est divisée en couches.
Ces couches fournissent une séparation logique au sein de l’architecture de l’application, par laquelle il est important de créer la plus grande interdépendance possible entre ces couches, qui doivent être aussi fonctionnellement cohérentes que possible (« découplage »). L'objectif est de séparer les intérêts fonctionnels (écrans utilisateurs, logique applicative & métier, accès aux données, etc.) et ainsi faciliter la maintenance de la plateforme sur le long terme, car ces intérêts peuvent être abordés séparément.
Quelles sont les différentes étapes du logiciel utilisées lors des phases de planification, de conception, de construction et de test ?
Nous travaillons avec un programme de développement, dans le sens d’un ensemble de projets. Chaque fois qu’un projet est presque terminé, un nouveau projet est défini sur la base des connaissances, de l’expérience, des idées et des besoins à ce moment-là et dans un avenir proche (tactique), et approprié à long terme et au programme de développement lui-même (stratégique). L’avancement d’un projet dans le cadre du programme de développement fait l’objet d’un suivi hebdomadaire. Tous les deux mois, il y a le comité directeur avec les sponsors. En termes de développement logiciel, les tests ont été mis en avant. Tout d’abord, les règles de test sont codées, que ce soit à l’aide ou non de données historiques. Le développement logiciel réel vient après. Les tests sont exécutés rapidement et automatiquement afin que le développeur ait un retour immédiat.
De nouveaux logiciels peuvent ainsi être déployés rapidement et en toute sécurité. Afin de s’assurer que ce qui est nécessaire est rendu opérationnel, on s'assure à ce que la démarcation habituelle entre l’entreprise et les développeurs soit très perméable. Les membres des deux groupes forment une seule équipe au sein des projets partiels et sont conjointement responsables de la qualité du service aux clients internes et externes. Cela permet aux développeurs de connaitre parfaitement l'entreprise. Les personnes chargées des opérations connaissent les données (des capteurs) et y ont accès. Cela leur permet d'analyser et de définir plus précisément les problèmes, les deux groupes s'appropriant ainsi le produit, les données et le service fourni.
Quelle méthodologie et quelle infrastructure logicielle sont utilisées pendant la recherche et le développement?
Une utilisation maximale est faite de tous les types de services en nuage afin de pouvoir se concentrer autant que possible sur le développement d'une logique d'entreprise spécifique, en particulier pour les aspects pour lesquels nous, en tant que startup, pouvons faire la différence. La plateforme technique choisie est Microsoft Windows Azure et offre une certification Safe-Harbor en standard dans ses contrats, ce qui permet de construire des solutions soumises à la législation belge et à la réglementation européenne sur la confidentialité et l’anonymat des données des patients. Les communications entre les différents modules fonctionnels et entre la solution et les prestataires de soins est cryptée. La plateforme es constituée en grande partie d’API (Web) et est gérée par le biais d'un système de gestion des API composée de quatre parties:
- API Gateway: est l’environnement technique qui est situé d’une part pour les API de nos partenaires stratégiques et d’autre part pour les API développées en interne , au moyen de microservices. Il agit comme un point d’accès unique pour un groupe défini de (micro) composants de produits. Étant donné qu’un protocole API Gateway gère les traductions, il s’agit également d’une valeur ajoutée pour les applications front-end créées avec plusieurs interfaces disparates (non-) API.
- Portail API : comble techniquement le fossé entre les fournisseurs d’API (produits logiciels Televitas) et les consommateurs d’API (utilisateurs finaux Televitas) qui fournissent des informations (techniques) sur les API à chaque étape du cycle de vie d’une API. Il permet également à Televitas d’ouvrir et de publier techniquement ses API, d’informer les développeurs tiers, d’accorder l’accès aux utilisateurs, de générer des certificats, etc. Pour les consommateurs d’API, le portail API est l’endroit idéal pour fournir des commentaires sur la qualité de l’API, signaler des bogues, lire la documentation utilisateur, etc.
- Catalogue d’API : un catalogue d’API se comporte comme une partie logique de l’API Gateway et de l’API Portal. L’URL de l’appel d’API et le portail API sont spécifiques à chaque catalogue. Pour chaque catalogue de produits (groupes) Televitas, il y aura un catalogue de développement pour tester les API en cours de développement et un catalogue de production pour héberger des API prêtes à être pleinement utilisées. Des tests unitaires automatiques seront effectués sur le catalogue de développement, des tests « smoke » sur le catalogue de tests d’intégration et des tests distincts pour les utilisateurs finaux sur le catalogue de production.
- Data Flow Manager : est une entité centrale du Televitas Data Hub. Il se compose de composants logiciels qui ingèrent, transforment et distribuent les données à l’intérieur et à l’extérieur du portail Televitas. Le Gestionnaire de flux de données rend les données transférables et permet également l’évolution des données entre les différentes couches, de sorte que les données brutes sont fiables et consommables en offrant des API de données (intelligentes artificielles) et en offrant des ensembles de données personnalisés (business intelligence) ), où les clients peuvent indiquer leur préférence en matière de technologie et de format de données souhaité. Sur les données fournies, les clients peuvent continuer à développer leurs activités.
Conceptuellement, nous sommes partis du prestataire de soins / établissement de soins, de son équipe et de ses patients. Ces acteurs participent aux soins à distance et, d’une part, devraient être soulagés de la charge des soins continus sur place au moyen d'une technologie simple et, d'autre part, être soulagés de la charge administrative du remboursement de ces soins à un distance. La plateforme est développée et gérée à partir d'une optique de modèle de soins hybrides, où le développement n'est jamais séparé du modèle de soins opérationnel et de l'utilisation de la plateforme.
Le plus grand nombre possible de processus de développement sont automatisés: test, intégration, déploiement et mise à disposition du logiciel (déploiement continu et amélioration continue), par lesquels à tout moment une nouvelle version du logiciel entre en production ou est rappelée de manière entièrement automatisée et vérifiable. Techniquement, la solution de base est divisée en couches.
Ces couches fournissent une séparation logique au sein de l’architecture de l’application, par laquelle il est important de créer la plus grande interdépendance possible entre ces couches, qui doivent être aussi fonctionnellement cohérentes que possible (« découplage »). L'objectif est de séparer les intérêts fonctionnels (écrans utilisateurs, logique applicative & métier, accès aux données, etc.) et ainsi faciliter la maintenance de la plateforme sur le long terme, car ces intérêts peuvent être abordés séparément.
Quelles sont les différentes étapes du logiciel utilisées lors des phases de planification, de conception, de construction et de test ?
Nous travaillons avec un programme de développement, dans le sens d’un ensemble de projets. Chaque fois qu’un projet est presque terminé, un nouveau projet est défini sur la base des connaissances, de l’expérience, des idées et des besoins à ce moment-là et dans un avenir proche (tactique), et approprié à long terme et au programme de développement lui-même (stratégique). L’avancement d’un projet dans le cadre du programme de développement fait l’objet d’un suivi hebdomadaire. Tous les deux mois, il y a le comité directeur avec les sponsors. En termes de développement logiciel, les tests ont été mis en avant. Tout d’abord, les règles de test sont codées, que ce soit à l’aide ou non de données historiques. Le développement logiciel réel vient après. Les tests sont exécutés rapidement et automatiquement afin que le développeur ait un retour immédiat.
De nouveaux logiciels peuvent ainsi être déployés rapidement et en toute sécurité. Afin de s’assurer que ce qui est nécessaire est rendu opérationnel, on s'assure à ce que la démarcation habituelle entre l’entreprise et les développeurs soit très perméable. Les membres des deux groupes forment une seule équipe au sein des projets partiels et sont conjointement responsables de la qualité du service aux clients internes et externes. Cela permet aux développeurs de connaitre parfaitement l'entreprise. Les personnes chargées des opérations connaissent les données (des capteurs) et y ont accès. Cela leur permet d'analyser et de définir plus précisément les problèmes, les deux groupes s'appropriant ainsi le produit, les données et le service fourni.
Quelle méthodologie et quelle infrastructure logicielle sont utilisées pendant la recherche et le développement?
Une utilisation maximale est faite de tous les types de services en nuage afin de pouvoir se concentrer autant que possible sur le développement d'une logique d'entreprise spécifique, en particulier pour les aspects pour lesquels nous, en tant que startup, pouvons faire la différence. La plateforme technique choisie est Microsoft Windows Azure et offre une certification Safe-Harbor en standard dans ses contrats, ce qui permet de construire des solutions soumises à la législation belge et à la réglementation européenne sur la confidentialité et l’anonymat des données des patients. Les communications entre les différents modules fonctionnels et entre la solution et les prestataires de soins est cryptée. La plateforme es constituée en grande partie d’API (Web) et est gérée par le biais d'un système de gestion des API composée de quatre parties:
- API Gateway: est l’environnement technique qui est situé d’une part pour les API de nos partenaires stratégiques et d’autre part pour les API développées en interne , au moyen de microservices. Il agit comme un point d’accès unique pour un groupe défini de (micro) composants de produits. Étant donné qu’un protocole API Gateway gère les traductions, il s’agit également d’une valeur ajoutée pour les applications front-end créées avec plusieurs interfaces disparates (non-) API.
- Portail API : comble techniquement le fossé entre les fournisseurs d’API (produits logiciels Televitas) et les consommateurs d’API (utilisateurs finaux Televitas) qui fournissent des informations (techniques) sur les API à chaque étape du cycle de vie d’une API. Il permet également à Televitas d’ouvrir et de publier techniquement ses API, d’informer les développeurs tiers, d’accorder l’accès aux utilisateurs, de générer des certificats, etc. Pour les consommateurs d’API, le portail API est l’endroit idéal pour fournir des commentaires sur la qualité de l’API, signaler des bogues, lire la documentation utilisateur, etc.
- Catalogue d’API : un catalogue d’API se comporte comme une partie logique de l’API Gateway et de l’API Portal. L’URL de l’appel d’API et le portail API sont spécifiques à chaque catalogue. Pour chaque catalogue de produits (groupes) Televitas, il y aura un catalogue de développement pour tester les API en cours de développement et un catalogue de production pour héberger des API prêtes à être pleinement utilisées. Des tests unitaires automatiques seront effectués sur le catalogue de développement, des tests « smoke » sur le catalogue de tests d’intégration et des tests distincts pour les utilisateurs finaux sur le catalogue de production.
- Data Flow Manager : est une entité centrale du Televitas Data Hub. Il se compose de composants logiciels qui ingèrent, transforment et distribuent les données à l’intérieur et à l’extérieur du portail Televitas. Le Gestionnaire de flux de données rend les données transférables et permet également l’évolution des données entre les différentes couches, de sorte que les données brutes sont fiables et consommables en offrant des API de données (intelligentes artificielles) et en offrant des ensembles de données personnalisés (business intelligence) ), où les clients peuvent indiquer leur préférence en matière de technologie et de format de données souhaité. Sur les données fournies, les clients peuvent continuer à développer leurs activités.
Plan financier +4 mois
Dans le plan financier +4 ans, l’estimation est faite à partir d’une perception B2C avec les pénétrations suivantes du marché de consommation pour les personnes âgées de plus de 65 ans, sachant que cela représente 1/5 de la population belge, soit 2.202.684 personnes. Étant donné que Televitas est un pionnier, il est actuellement difficile d’estimer la part du marché B2B et B2C. Le potentiel du marché est clairement présent, comme décrit précédemment.
