Inbrain Neuroelectronics

Inbrain Neuroelectronics és una startup amb seu a Barcelona, classificada al corpus com a empresa de programari i SaaS i registrada com a activa. La font disponible és l'entrada d'Inbrain Neuroelectronics a la Viquipèdia en castellà.

Segons aquesta font, l'empresa treballa en el desenvolupament de tecnologies d'interfície cervell-ordinador basades en el grafè. Aquesta és l'única font que consta al corpus, de manera que les dades sobre la seva activitat, estructura i fites es limiten al que recull aquesta entrada.

La informació del corpus no permet detallar la història de la fundació: no consta la data de constitució, ni els socis inicials, ni el procés de creació de l'empresa més enllà del que pugui recollir la font citada. Per completar aquest apartat caldria consultar el registre mercantil (BORME) i les fonts primàries de l'empresa.

D'acord amb la font disponible, Inbrain Neuroelectronics desenvolupa implants neuronals i tecnologies d'interfície cervell-ordinador que fan servir el grafè com a material. L'orientació és la neurotecnologia mèdica, és a dir, aplicacions clíniques relacionades amb el sistema nerviós.

El corpus no detalla quins productes concrets comercialitza, quins clients o socis té ni en quina fase de desenvolupament es troben les seves tecnologies. Aquests aspectes no consten.

No consta al corpus cap informació sobre l'evolució financera, el creixement, les rondes de finançament o les fites comercials de l'empresa. La font disponible és una entrada enciclopèdica i no aporta dades econòmiques verificables.

L'empresa no ha tancat. D'acord amb el corpus, Inbrain Neuroelectronics consta com a activa. Aquest informe no descriu cap procés de tancament ni de transformació perquè no n'hi ha constància a les fonts disponibles.

Atès que l'empresa continua activa, no es pot parlar d'herència en el sentit de llegat d'una activitat acabada. El que consta és la seva línia de treball en neurotecnologia amb grafè, recollida a la font citada.

El corpus no identifica les persones fundadores d'Inbrain Neuroelectronics ni recull informació sobre la seva situació actual. Aquestes dades no consten. Per obtenir-les caldria consultar el registre mercantil, les notes de premsa de l'empresa i les fonts periodístiques especialitzades en biotecnologia i neurotecnologia.

• En un sector com la neurotecnologia mèdica, la informació pública útil acostuma a estar en fonts primàries (registre mercantil, comunicacions de l'empresa, publicacions científiques) més que en entrades enciclopèdiques, que sovint no recullen dades financeres ni de govern corporatiu.
• Per avaluar una startup de tecnologia mèdica cal distingir entre la fase de recerca, la de desenvolupament clínic i la de comercialització; el corpus disponible no permet situar Inbrain en cap d'aquestes fases.
• Quan l'única font és una enciclopèdia, l'informe ha de limitar-se a allò que aquesta afirma i marcar explícitament els buits, en lloc de completar-los amb suposicions.

Inbrain Neuroelectronics és una startup de Barcelona que, segons la informació disponible a Wikipedia, desenvolupa tecnologies de neurointerfície basades en grafè. La seva essència és la confluència de neurociència, materials avançats i tractament de senyals.

Reconstruir avui el negoci del maquinari neuroelectrònic exigiria capital, equips de recerca i anys d'assajos clínics. Però la part de software i SaaS —que és el sector que consta a les dades de l'empresa— es pot reconstruir de manera molt més àgil: una plataforma d'adquisició, processament i anàlisi de senyals neuronals, orientada a hospitals, grups de recerca i fabricants de dispositius.

La proposta, doncs, és una empresa de programari mèdic especialitzada en analítica de senyals neuronals i gestió de dades d'assaigs, amb la mateixa essència tècnica d'Inbrain però sense la càrrega del maquinari.

El mercat rellevant és el de programari per a neurociència i neurologia clínica: plataformes d'anàlisi de senyals (EEG, electrofisiologia intracraniana), gestió de dades d'estudis i assajos, i eines de suport a la decisió clínica.

No disposo de xifres verificades sobre la mida d'aquest mercat a partir de les fonts disponibles; qualsevol quantificació seria una estimació a validar amb informes sectorials. El que sí que és verificable és que existeix un ecosistema actiu d'hospitals universitaris, centres de recerca i empreses de neurotecnologia a Barcelona i Catalunya que podria constituir la primera base de clients.

Proposta (a validar):

• Subscripció SaaS per a plataformes d'anàlisi de senyals neuronals, amb preus per seient o per volum de dades.
• Llicències a fabricants de dispositius que vulguin incorporar capa d'analítica al seu producte.
• Serveis de desplegament i suport a hospitals i grups de recerca (ingressos inicials no recurrents).
• Col·laboracions de recerca amb centres que necessitin infraestructura de dades.

El model encaixa amb el sector "Software i SaaS" que consta a les dades de l'empresa.

Fases proposades (estimació, a validar):

1. Mesos 0-6: definir el producte mínim (anàlisi de senyals + gestió de dades), validar amb 2-3 grups de recerca col·laboradors.
2. Mesos 6-12: primer pilot amb un hospital o centre de recerca; iteració del producte.
3. Mesos 12-24: primers contractes de subscripció i una llicència a un fabricant de dispositius.
4. Mesos 24+: expansió a altres centres i possible certificació com a producte sanitari si el producte ho requereix.

Estimació (rang, a validar):

• Equip inicial de 4-6 persones (enginyeria de programari, ciència de dades, domini neurocientífic): 300.000-500.000 €/any.
• Infraestructura cloud i eines: 20.000-50.000 €/any.
• Assessoria legal i reguladora (protecció de dades de salut, possible marc de producte sanitari): 30.000-80.000 €.
• Màrqueting i desenvolupament de negoci: 50.000-100.000 €/any.

Total orientatiu per als primers 18 mesos: rang de 600.000 € a 1,2 M€, a validar segons l'abast real del producte i el règim regulatori aplicable.

• Regulació de dades de salut: tractar senyals neuronals implica compliment estricte (RGPD i normativa de producte sanitari). Risc alt si no es dimensiona bé des del principi.
• Cicle de venda llarg: hospitals i centres de recerca compren lentament.
• Dependència de col·laboradors: sense accés a dades reals, el producte no es pot validar.
• Competència: el camp de la neurotecnologia atrau molts actors; cal un nínxol clar.
• Risc de confondre's amb el negoci original: si el mercat espera maquinari, un producte només de programari pot no encaixar en les expectatives.

Les lliçons de l'experiència d'Inbrain apunten a un perfil concret: un equip fundador amb coneixement profund de neurociència i tractament de senyals, capacitat d'enginyeria de programari sòlida, i disposició a col·laborar estretament amb hospitals i centres de recerca des del primer dia. La clau no és replicar el maquinari, sinó aprofitar la capa de dades i analítica on el coneixement del domini marca la diferència, i fer-ho amb un soci clínic que validi el producte des de l'inici.

Inbrain Neuroelectronics treballa en neurotecnologia basada en grafè, segons la informació pública disponible a [Wikipedia]. El coll d'ampolla tècnic en aquest domini no és el maquinari sinó el programari que ha de llegir senyals neuronals sorollosos, decidir una resposta en mil·lisegons i deixar constància exacta del que ha passat perquè un comitè ètic o un regulador ho pugui revisar.

Avui, els equips de recerca solen treballar amb scripts ad-hoc, MATLAB i fitxers CSV que no són reproduïbles ni auditables. Això fa que cada assaig sigui difícil de replicar i que la transició cap a un producte regulat sigui costosa. La plataforma que es proposa resol tres coses alhora: latència determinista en el bucle de control, traçabilitat completa de cada decisió terapèutica, i separació estricta entre el codi de recerca i el codi que pot tocar un pacient.

L'arquitectura s'organitza en quatre plans amb fronteres clares, perquè el codi que decideix estimulació no pot dependre de res que no sigui determinista.

``` [Implant / hardware] --(BLE/UART)--> [Edge Gateway (Rust)] | (gRPC streaming) v [Realtime Core (Rust)] | | (Kafka) | | (gRPC) v v [Signal Store] [Therapy Engine] (TimescaleDB) (Rust, sandbox) | (event log) v [Audit Ledger (append-only)] | v [Clinical API (Go)] --> [Web UI (React)] ```

Per què aquestes decisions:

• Rust al camí crític: el bucle de control ha de tenir latència acotada i absència de garbage collector. Un pic de GC de 50 ms en un bucle d'estimulació és inacceptable.
• Edge Gateway separat: el processament de senyal brut (filtratge, artefactes) es fa a prop del maquinari per reduir amplada de banda i latència; el núvol només rep senyals ja condicionats i metadades.
• Therapy Engine en sandbox: les regles terapèutiques s'executen en un entorn aïllat amb límits de CPU i memòria, de manera que una regla defectuosa no pot bloquejar el bucle de seguretat.
• Kafka com a bus: permet reproduir un assaig sencer rejugant el stream, cosa imprescindible per a validació regulatòria.
• Audit Ledger append-only: cada decisió d'estimulació s'escriu amb hash encadenat; no es pot esborrar ni modificar retroactivament.

El model és deliberadament petit i estable; les dades de senyal viuen en un magatzem de sèries temporals, no en una base relacional.

```sql -- Postgres: entitats clíniques CREATE TABLE patient ( id UUID PRIMARY KEY, pseudonym TEXT UNIQUE NOT NULL, -- mai el nom real al nucli consent_version TEXT NOT NULL, created_at TIMESTAMPTZ NOT NULL );

CREATE TABLE session ( id UUID PRIMARY KEY, patient_id UUID REFERENCES patient(id), protocol_id UUID NOT NULL, started_at TIMESTAMPTZ NOT NULL, ended_at TIMESTAMPTZ, device_serial TEXT NOT NULL );

CREATE TABLE therapy_rule ( id UUID PRIMARY KEY, version INT NOT NULL, code_hash TEXT NOT NULL, -- hash del WASM desplegat params JSONB NOT NULL, approved_by TEXT, UNIQUE (id, version) ); ```

```sql -- TimescaleDB: hypertable de senyal CREATE TABLE neural_sample ( session_id UUID NOT NULL, ts TIMESTAMPTZ NOT NULL, channel SMALLINT NOT NULL, voltage_uv REAL NOT NULL, quality SMALLINT NOT NULL ); SELECT create_hypertable('neural_sample', 'ts'); ```

```sql -- Audit ledger: encadenat per hash CREATE TABLE decision_event ( seq BIGSERIAL PRIMARY KEY, session_id UUID NOT NULL, ts TIMESTAMPTZ NOT NULL, rule_id UUID NOT NULL, rule_version INT NOT NULL, input_digest TEXT NOT NULL, -- hash de la finestra de senyal output_action JSONB NOT NULL, prev_hash TEXT NOT NULL, hash TEXT NOT NULL ); ```

Motiu: separar senyal (volum alt, retenció curta) de decisions (volum baix, retenció llarga) permet complir requisits de conservació sense inflar costos d'emmagatzematge.

• gRPC `SignalIngest` (streaming bidireccional): l'Edge Gateway envia mostres i rep comandes de configuració. Protobuf perquè l'overhead de serialització ha de ser mínim.
• gRPC `TherapyControl`: el Realtime Core consulta el Therapy Engine amb un deadline explícit de 5 ms; si no respon, s'aplica la política de seguretat per defecte (aturada d'estimulació).
• REST `Clinical API` (OpenAPI 3.1): gestió de pacients, sessions, protocols i consulta de l'audit ledger. REST perquè és consumida per la UI i per integracions hospitalàries que ja parlen HTTP.
• Integració HL7 FHIR R4: exportació de sessions i esdeveniments com a `Observation` i `Procedure` per encaixar amb sistemes hospitalaris existents.
• Webhooks signats per notificar esdeveniments de seguretat a sistemes de monitoratge.

Motiu: el streaming intern va per gRPC per latència; la frontera externa va per REST/FHIR per interoperabilitat. No es barregen.

1. Edge Gateway + SignalIngest: sense captació fiable no hi ha res. Prioritat màxima.
2. Signal Store amb rejoc: poder reproduir una sessió gravada és el prerequisit per desenvolupar la resta sense maquinari.
3. Audit Ledger: s'ha de construir abans que qualsevol lògica terapèutica, perquè retroactivament no es pot afegir traçabilitat a decisions ja preses.
4. Therapy Engine en mode simulació (sense actuador): validar regles contra senyals gravats.
5. Clinical API i UI mínima: només lectura de sessions i auditoria al principi.

Motiu de l'ordre: cada peça habilita la validació de la següent; l'auditoria va abans que la teràpia perquè és el que fa possible demostrar que la teràpia és correcta.

• Latència del bucle: objectiu p99 < 10 ms des de mostra fins a comanda. Risc: el Therapy Engine en sandbox pot introduir jitter; mitigació amb deadlines i fallback determinista.
• Volum de senyal: 256 canals a 2 kHz són ~2 MB/s per sessió; amb 20 sessions simultànies cal dimensionar TimescaleDB i la retenció (proposat: 30 dies calent, arxiu fred).
• Risc regulatori: el programari pot esdevenir SaMD (Software as a Medical Device); cal dissenyar amb IEC 62304 des del primer dia, cosa que encareix el procés però evita refactoritzacions.
• Risc de seguretat: un implant connectat és superfície d'atac; cal xifrat extrem a extrem i autenticació mútua de dispositius.
• Risc d'equip: l'stack Rust + WASM és potent però limita el nombre de desenvolupadors disponibles; cal planificar formació.

• Tests de latència: benchmark continu al CI que mesura p99 del bucle amb senyals sintètics; es bloqueja el merge si supera el llindar.
• Rejoc determinista: cada sessió gravada s'ha de poder reproduir i obtenir exactament el mateix audit ledger; qualsevol divergència és un bug.
• Verificació de la cadena de hash: un job diari recorre l'audit ledger i comprova la integritat.
• Simulació clínica: protocols validats primer contra conjunts de senyals anotats per neuròlegs, amb mètriques de sensibilitat/especificitat acordades abans de tocar cap actuador.
• Auditoria externa: revisió per part d'un organisme notificat abans de qualsevol ús en pacient, amb la documentació generada automàticament a partir del codi i dels registres.