WEBVTT
Kind: captions
Language: es

1
00:00:00.000 --> 00:00:06.429
Uno de vosotros dos tiene una entrada en Wikipedia. Supongo que esa persona lo sabe.

2
00:00:06.429 --> 00:00:09.150
Sí.

3
00:00:09.150 --> 00:00:13.470
Lo que leí allí me pareció fascinante.

4
00:00:13.470 --> 00:00:21.500
Por eso me gustaría preguntarte: ¿qué significa la Cruz Federal al Mérito y cómo se consigue?

5
00:00:21.500 --> 00:00:30.940
La Cruz Federal al Mérito es una condecoración, totalmente clásica, como en los viejos tiempos.

6
00:00:30.940 --> 00:00:36.700
Es la orden alemana al mérito, la única condecoración realmente civil que se otorga.

7
00:00:36.700 --> 00:00:46.780
La Cruz Federal al Mérito es el equivalente a una OBE de los británicos, es decir, la Order of the British Empire.

8
00:00:46.780 --> 00:00:49.539
Si fuera británico, ahora me podrían llamar Sir.

9
00:00:49.539 --> 00:00:53.979
Antes habrían dicho cruz de caballero, pero eso tiene connotaciones.

10
00:00:53.979 --> 00:01:00.899
Así que es una distinción bastante elevada. La recibí por mi trabajo.

11
00:01:00.899 --> 00:01:10.900
En el ámbito de la soberanía digital: estándares abiertos, software libre, Open Source, creación de la FSFE y otras iniciativas.

12
00:01:10.900 --> 00:01:17.700
¿FSF cuál? Exacto, la Free Software Foundation Europe. Free Software Foundation Europe.

13
00:01:17.700 --> 00:01:22.900
Es una organización no gubernamental que trabaja por la soberanía digital.

14
00:01:22.900 --> 00:01:29.030
Entonces, lo que ahora aparece constantemente en los medios sobre soberanía digital, ¿tú lo empezaste hace muchos años?

15
00:01:29.030 --> 00:01:31.030
Sí, es prácticamente el tema de mi vida.

16
00:01:31.030 --> 00:01:37.030
Lo descubrí hace muchos años, a principios o mediados de los noventa.

17
00:01:37.030 --> 00:01:40.030
Y de alguna manera me atrapó y no me soltó.

18
00:01:40.030 --> 00:01:46.030
Así que el Sir, el caballero que tengo enfrente, es Georg Greve de la empresa Vereign.

19
00:01:46.030 --> 00:01:52.450
Muy brevemente, estamos aquí en el pódcast de HIN, HIN — sistema sanitario.

20
00:01:52.450 --> 00:01:57.450
¿Qué relación tiene Vereign con el sistema sanitario? Brevemente, luego seguro que oiremos más.

21
00:01:57.450 --> 00:02:00.730
Vereign trabaja desde...

22
00:02:00.730 --> 00:02:05.730
Vereign trabaja desde hace tres años muy intensamente con HIN.

23
00:02:05.730 --> 00:02:10.729
Somos socios muy, muy estrechos. Llevamos más tiempo trabajando con el sistema sanitario.

24
00:02:10.729 --> 00:02:17.729
En el marco de proyectos europeos también hemos trabajado con otras instituciones sanitarias.

25
00:02:17.729 --> 00:02:20.729
A mí personalmente este tema me acompaña desde hace mucho tiempo.

26
00:02:20.729 --> 00:02:26.729
Bien, y junto a Georg está Peer Hostettler, miembro de la dirección de HIN.

27
00:02:26.729 --> 00:02:29.729
Peer es CCO en HIN.

28
00:02:29.729 --> 00:02:33.729
¿Sabes exactamente qué es eso? ¿Qué hace un CCO? ¿Es Chief Customer Officer?

29
00:02:33.729 --> 00:02:36.729
No, Chief Commercial Officer, pero Customer me gusta mucho.

30
00:02:36.729 --> 00:02:40.729
Y también se podría decir Chief Community Officer. Eso también mola.

31
00:02:40.729 --> 00:02:44.729
Entonces, ¿no le das mucha importancia al título? No.

32
00:02:44.729 --> 00:02:48.729
Peer, no encontré ninguna entrada de Wikipedia cuando te busqué en Google.

33
00:02:48.729 --> 00:02:52.729
Pero sí un currículum, algo antiguo, eso sí.

34
00:02:52.729 --> 00:02:58.729
No está todo, pero al menos vi que llevas en el sistema sanitario desde 2010. Ya es bastante tiempo.

35
00:02:58.729 --> 00:03:05.729
Y entonces me pregunté: ¿cuál es realmente tu pasión?

36
00:03:05.729 --> 00:03:09.729
¿Qué te impulsa a llevar tanto tiempo en HIN?

37
00:03:09.729 --> 00:03:21.419
Cuando hago balance, me mueven tres motores.

38
00:03:21.419 --> 00:03:24.419
Uno es la búsqueda de sentido.

39
00:03:24.419 --> 00:03:29.969
Otro es que quiero descubrir algo. Quiero...

40
00:03:29.969 --> 00:03:34.969
Tiene que ser emocionante. Descubrir al estilo Colón.

41
00:03:34.969 --> 00:03:41.219
Y lo tercero es la socialidad. Trabajar con personas agradables...

42
00:03:41.219 --> 00:03:47.259
No siempre se consigue, pero... Descubrir algo con personas agradables.

43
00:03:47.259 --> 00:03:53.750
Insight. En camino por el sistema sanitario digital.

44
00:03:53.750 --> 00:04:00.750
El pódcast de HIN para conversaciones con expertos de TI, sistema sanitario y política.

45
00:04:00.750 --> 00:04:12.020
Para mí, por supuesto...

46
00:04:13.020 --> 00:04:16.019
Estupendo, tengo aquí a dos expertos conmigo.

47
00:04:16.019 --> 00:04:22.019
Uno casi un caballero, un Sir del mundo de las TI y la digitalización.

48
00:04:22.019 --> 00:04:27.019
Y otro es Peer, que lleva realmente mucho tiempo en el sistema sanitario.

49
00:04:27.019 --> 00:04:29.019
Y eso es muy importante para el tema de hoy.

50
00:04:29.019 --> 00:04:37.019
Porque se trata de los desafíos en el sistema sanitario y de las soluciones digitales que se pueden ofrecer.

51
00:04:37.019 --> 00:04:42.019
En el sistema sanitario muchas personas están al límite de sus fuerzas.

52
00:04:42.019 --> 00:04:46.019
El presupuesto es escaso y también faltan muchos profesionales cualificados.

53
00:04:46.019 --> 00:04:52.019
Y la carga administrativa es cada vez mayor. De eso queremos hablar exactamente.

54
00:04:52.019 --> 00:04:57.019
¿Dónde aprieta el zapato en el sistema sanitario, con los profesionales, en los hospitales, en las consultas?

55
00:04:57.019 --> 00:04:59.019
¿Cuáles son los desafíos?

56
00:04:59.019 --> 00:05:04.019
Pero sobre todo hablaremos de las soluciones que HIN y sus socios ofrecen mediante la digitalización.

57
00:05:04.019 --> 00:05:10.019
Me alegro de que estéis aquí. Me llamo David Umiker y este es el segundo episodio del pódcast de HIN.

58
00:05:17.269 --> 00:05:19.300
Mi palabra clave es escasez de profesionales cualificados.

59
00:05:19.300 --> 00:05:23.300
Esto no significa solo que no tengamos suficientes personas formadas,

60
00:05:23.300 --> 00:05:30.399
sino también que profesionales con formación excelente abandonan la profesión después de sus estudios.

61
00:05:30.399 --> 00:05:34.399
Encuestas y estudios que han investigado el tema lo confirman,

62
00:05:34.399 --> 00:05:40.399
que incluso médicos jóvenes ya abandonan su profesión. Las razones son diversas.

63
00:05:40.399 --> 00:05:45.399
Pero una razón que sin duda influye es la creciente carga administrativa.

64
00:05:45.399 --> 00:05:51.399
Debido a la burocracia. Tú hablas mucho con clientes.

65
00:05:51.399 --> 00:05:55.399
¿Qué puedes contarnos, quizá una o dos razones principales

66
00:05:55.399 --> 00:06:00.399
que ves una y otra vez — cuáles son los principales desafíos para los profesionales sanitarios en su día a día?

67
00:06:00.399 --> 00:06:05.939
Sí, quizá como complemento. No afecta solo a los médicos,

68
00:06:05.939 --> 00:06:11.939
sino a todo el espectro: enfermeros, terapeutas, profesionales de TI.

69
00:06:11.939 --> 00:06:15.939
En todas partes existe esta escasez de profesionales. Como es así en todas partes, casi se puede decir

70
00:06:15.939 --> 00:06:19.939
que es la normalidad, así que simplemente tenemos que aceptarlo.

71
00:06:19.939 --> 00:06:25.939
Eso como complemento. Cuando me lo preguntas y reflexiono sobre ello,

72
00:06:25.939 --> 00:06:31.259
una y otra vez sale a la luz

73
00:06:31.259 --> 00:06:37.259
que evidentemente hay problemas de remuneración.

74
00:06:37.259 --> 00:06:42.259
El tema del pago de los servicios prestados es altamente problemático.

75
00:06:42.259 --> 00:06:46.259
Y el espectro organizativo en el sistema sanitario es extremadamente amplio.

76
00:06:46.259 --> 00:06:50.259
Por un lado tienes profesiones liberales, autónomos.

77
00:06:50.259 --> 00:06:54.259
Son actividades de una sola persona.

78
00:06:54.259 --> 00:07:00.259
Y luego tienes hospitales universitarios enormes. Hay que tenerlo siempre presente.

79
00:07:00.259 --> 00:07:06.259
Pero cuando miras estos extremos, el tema de las tarifas, el tema de la facturación,

80
00:07:06.259 --> 00:07:10.259
es un gran tema, un tema que agobia.

81
00:07:10.259 --> 00:07:15.259
Sobre todo cuando se trata de nuevas exigencias, por ejemplo,

82
00:07:15.259 --> 00:07:19.259
nuevas regulaciones o tendencias y demás.

83
00:07:19.259 --> 00:07:24.259
Hay una incapacidad masiva de inversión.

84
00:07:24.259 --> 00:07:31.259
Los actores, también cuando se enfrentan a nuestros temas,

85
00:07:31.259 --> 00:07:34.259
dicen una y otra vez: Dios mío, ahora también queréis,

86
00:07:34.259 --> 00:07:39.259
ahora esto cuesta más dinero, ahora necesitamos aún más. Es difícil.

87
00:07:39.259 --> 00:07:44.259
La burocracia exige cambios en los procesos o más esfuerzo,

88
00:07:44.259 --> 00:07:49.259
porque hay que indicar algo más a una aseguradora o a una autoridad o donde sea.

89
00:07:49.259 --> 00:07:54.259
Y eso se podría simplificar con ciertas inversiones en digitalización. Eso es lo que quiero decir.

90
00:07:54.259 --> 00:08:00.259
Y al mismo tiempo no pueden facturar el esfuerzo que los profesionales sanitarios dedican a ello.

91
00:08:00.259 --> 00:08:05.420
¿Lo he entendido correctamente? Sí, va en esa dirección.

92
00:08:05.420 --> 00:08:09.420
Pero quizá hay un pequeño malentendido. La digitalización no está pensada de por sí

93
00:08:09.420 --> 00:08:15.420
para reducir la carga burocrática. Yo lo recuerdo de otra manera.

94
00:08:15.420 --> 00:08:18.420
Cuando el tema se convirtió en un tema relevante,

95
00:08:18.420 --> 00:08:22.420
se descubrió que mediante los bits y bytes

96
00:08:22.420 --> 00:08:27.420
la secuencia de los flujos de trabajo, es decir los procesos, podía rediseñarse completamente

97
00:08:27.420 --> 00:08:30.420
y se podían hacer cosas completamente nuevas.

98
00:08:30.420 --> 00:08:37.419
Y hay muchos casos publicados al respecto.

99
00:08:37.419 --> 00:08:42.419
En algún momento todo el tema llegó al sistema sanitario. Se empezó a registrar pacientes

100
00:08:42.419 --> 00:08:48.419
en sistemas electrónicos, para poder facturar electrónicamente, por ejemplo. Luego se empezó en algún momento

101
00:08:48.419 --> 00:08:53.419
a documentar electrónicamente. Y así surgieron un montón de silos informáticos. Eso es lo que tenemos ahora.

102
00:08:53.419 --> 00:08:57.419
Y las exigencias son cada vez mayores.

103
00:08:57.419 --> 00:09:02.419
Y eso significa que hay que invertir en estos sistemas. Así que tu resumen era correcto.

104
00:09:02.419 --> 00:09:06.419
Y para poder invertir, necesitas ingresos.

105
00:09:06.419 --> 00:09:12.419
Porque sin ingresos no hay posibilidad de inversión y sin inversión tampoco hay ingresos.

106
00:09:12.419 --> 00:09:19.289
Entonces no hay innovación. Sí. Ahí está realmente la trampa. Es una trampa.

107
00:09:19.289 --> 00:09:25.289
Sí. Y de las más grandes. Y cuando un profesional sanitario

108
00:09:25.289 --> 00:09:31.700
quiere invertir en digitalización, puede preguntarse: ¿dónde puedo facturar esto? Pues en ningún sitio.

109
00:09:31.700 --> 00:09:36.700
No puedes facturarlo. En absoluto. Existe un sistema tarifario para el sector hospitalario,

110
00:09:36.700 --> 00:09:42.700
para cuidados, para atención ambulatoria, atención ambulatoria médica.

111
00:09:43.700 --> 00:09:45.700
Y ahí existe una tarifa.

112
00:09:45.700 --> 00:09:50.700
Y el mensaje político es siempre el mismo:

113
00:09:50.700 --> 00:09:55.950
eso ya está incluido en la tarifa. Y eso es un argumento demoledor.

114
00:09:55.950 --> 00:09:59.950
Porque cuando tienes un sistema informático

115
00:09:59.950 --> 00:10:05.950
que probablemente está basado en un gran sistema heredado,

116
00:10:05.950 --> 00:10:09.950
alojado localmente, en las instalaciones, debajo del escritorio,

117
00:10:09.950 --> 00:10:13.950
y quieres abrirlo como herramienta colaborativa

118
00:10:13.950 --> 00:10:19.950
para nuevas vías de comunicación,

119
00:10:19.950 --> 00:10:25.950
tienes que modificar todo el sistema. Y modificarlo cuesta mucho dinero.

120
00:10:25.950 --> 00:10:29.950
Y eso nunca podría estar cubierto en la tarifa — hubo un cambio tarifario,

121
00:10:29.950 --> 00:10:34.950
en la tarifa anterior ni se contemplaba, porque viene del año dos mil y algo.

122
00:10:34.950 --> 00:10:38.950
Y en la nueva tarifa no ha cambiado mucho, palabra clave: neutralidad de costes.

123
00:10:38.950 --> 00:10:44.950
Simplemente no hay dinero en el sistema. ¿Pero hay soluciones? ¿Cuáles son las soluciones

124
00:10:44.950 --> 00:10:46.980
si no hay presupuesto en el sistema sanitario?

125
00:10:46.980 --> 00:10:49.980
¿Cómo pueden los profesionales sanitarios utilizar herramientas digitalmente soberanas,

126
00:10:49.980 --> 00:10:53.980
seguras, modernas o incluso infraestructuras?

127
00:10:53.980 --> 00:10:58.980
¿Cómo va a funcionar si nadie tiene dinero? Creo que estoy bastante seguro

128
00:10:58.980 --> 00:11:04.980
de que ya pagan por las herramientas que utilizan actualmente.

129
00:11:04.980 --> 00:11:10.980
Incluyendo pagos a Estados Unidos. Así que el dinero simplemente desaparece

130
00:11:10.980 --> 00:11:15.980
cuando se ha pagado. Podría utilizarse de otra forma, quizá de manera más sensata.

131
00:11:15.980 --> 00:11:20.980
Así que es una cuestión de redirigir el presupuesto. El presupuesto existe en parte.

132
00:11:20.980 --> 00:11:23.980
Y por otro lado es también una cuestión de eficiencia.

133
00:11:23.980 --> 00:11:27.980
Si cada médico empieza por su cuenta

134
00:11:27.980 --> 00:11:32.980
a hacer las cosas por sí solo, eso es totalmente ineficiente.

135
00:11:32.980 --> 00:11:38.980
Pero a menudo tienen exactamente las mismas necesidades. No es que una consulta médica necesite

136
00:11:38.980 --> 00:11:41.980
un sistema de correo completamente diferente al de otra consulta.

137
00:11:41.980 --> 00:11:47.980
Y creo que estamos exactamente en el lugar adecuado para ello. Porque precisamente de esa idea nació HIN.

138
00:11:47.980 --> 00:11:52.980
La idea es resolver estos problemas para todos nosotros,

139
00:11:52.980 --> 00:11:57.980
porque no es el centro de nuestra actividad. Tampoco es donde nos diferenciamos.

140
00:11:57.980 --> 00:12:01.980
Es simplemente algo que debemos resolver limpiamente entre todos.

141
00:12:01.980 --> 00:12:06.210
Podemos ganar eficiencia agrupando esfuerzos.

142
00:12:06.210 --> 00:12:10.210
Y HIN, desde mi punto de vista, es increíblemente valiosa

143
00:12:10.210 --> 00:12:16.210
porque viene del propio sector. Pertenece a la FMH.

144
00:12:16.210 --> 00:12:23.210
La FMH es la asociación profesional de los médicos.

145
00:12:23.210 --> 00:12:30.340
Y en última instancia, HIN tiene una misión de servicio

146
00:12:30.340 --> 00:12:34.340
y no una misión de generar beneficios. Es tremendamente importante entenderlo,

147
00:12:34.340 --> 00:12:38.340
porque cuando HIN genera beneficios,

148
00:12:38.340 --> 00:12:44.460
estos vuelven a los médicos. Es decir, a las personas que utilizan el software.

149
00:12:44.460 --> 00:12:50.460
Entonces es un ciclo. Sería un ciclo con un calentador. Eso no tiene sentido, nadie lo necesita.

150
00:12:50.460 --> 00:12:56.460
Se trata de que HIN sea capaz de emplear su presupuesto eficientemente en aquello

151
00:12:56.460 --> 00:13:01.460
que los médicos realmente necesitan. Y esta idea existe también en otros sectores.

152
00:13:01.460 --> 00:13:07.460
En Alemania está DATEV, por ejemplo. Hace lo mismo para asesores fiscales y abogados. Aquí en Suiza...

153
00:13:07.460 --> 00:13:10.460
HIN es única en el mundo, por lo que veo.

154
00:13:10.460 --> 00:13:14.460
No he visto un modelo semejante en ningún otro lugar.

155
00:13:14.460 --> 00:13:19.460
Al contrario, cuando cuento en el extranjero que en Suiza tenemos HIN,

156
00:13:19.460 --> 00:13:26.230
la primera pregunta suele ser: ¿no deberíamos crear algo parecido? ¿Y por qué no lo hacen?

157
00:13:26.230 --> 00:13:29.230
La razón es que en otros sistemas sanitarios

158
00:13:29.230 --> 00:13:35.230
suele haber grandes actores comerciales con muy buenas conexiones,

159
00:13:35.230 --> 00:13:40.230
que no tienen interés en ser desplazados de ese sector,

160
00:13:40.230 --> 00:13:44.230
porque ganan mucho dinero con él. Son empresas con ánimo de lucro

161
00:13:44.230 --> 00:13:47.230
e intentan extraer el máximo beneficio del sector.

162
00:13:47.230 --> 00:13:51.230
HIN en Suiza es única en ese sentido.

163
00:13:51.230 --> 00:13:55.230
Y por eso, cuando me di cuenta de ello, me pregunté:

164
00:13:55.230 --> 00:14:01.230
¿por qué Suiza no aprovecha esta ventaja competitiva de forma mucho más decidida? Porque tenemos el vehículo,

165
00:14:01.230 --> 00:14:06.230
tenemos la organización, tenemos las estructuras profesionales

166
00:14:06.230 --> 00:14:08.230
para abordar todos estos problemas

167
00:14:08.230 --> 00:14:13.299
y resolverlos realmente desde la base para Suiza.

168
00:14:13.299 --> 00:14:22.669
Georg acaba de contar mucho sobre HIN,

169
00:14:22.669 --> 00:14:28.669
casi se ha entusiasmado, lo cual es algo único, lo que Suiza tiene con HIN.

170
00:14:28.669 --> 00:14:34.669
Y de eso queremos hablar ahora. ¿Qué tiene que ver HIN con toda esta discusión de la que acabamos de hablar?

171
00:14:34.669 --> 00:14:40.669
¿Y qué tiene que ver la empresa de Georg, Vereign? Me gustaría saber ahora, en primer lugar,

172
00:14:40.669 --> 00:14:45.669
¿cómo surgió la colaboración entre estas dos empresas, Peer? Y rápidamente, Georg,

173
00:14:45.669 --> 00:14:50.669
muchas gracias por tu alegato a favor de HIN, yo no lo habría hecho mejor.

174
00:14:50.669 --> 00:14:54.669
Encontramos a Georg y su equipo, o Georg y su equipo nos encontraron a nosotros,

175
00:14:54.669 --> 00:14:58.669
cuando nos enfrentábamos a la tarea de que tenemos un servicio que se llama HIN Mail,

176
00:14:58.669 --> 00:15:04.669
y este servicio HIN Mail llega también a personas fuera de la red HIN,

177
00:15:04.669 --> 00:15:09.669
por ejemplo, a pacientes. Os podéis imaginar, cuando un paciente ha ido al médico y recibe un informe,

178
00:15:09.669 --> 00:15:15.669
y el paciente quiere recibir ese informe por correo electrónico, entonces el médico tiene que enviarlo cifrado.

179
00:15:15.669 --> 00:15:21.669
Había una función para eso, que teníamos, pero era bastante difícil de usar.

180
00:15:21.669 --> 00:15:26.669
Con el equipo de Georg discutimos: ¿hay alternativas? Y sí, las había.

181
00:15:26.669 --> 00:15:30.669
Y eso nos convenció enormemente, cuando llegó,

182
00:15:30.669 --> 00:15:36.669
antes de que acordásemos nada contractualmente, vino con un POC y nos mostró:

183
00:15:36.669 --> 00:15:41.669
mirad, así podría funcionar la entrega cifrada de correo

184
00:15:41.669 --> 00:15:46.669
a personas fuera de la red HIN. POC es Proof of Concept. Correcto. Así es.

185
00:15:46.669 --> 00:15:49.669
Y ese Proof of Concept nos convenció enormemente,

186
00:15:49.669 --> 00:15:55.669
porque respondía a algo absolutamente esencial que nos preocupa,

187
00:15:55.669 --> 00:15:58.669
que es la minimización de datos,

188
00:15:58.669 --> 00:16:02.669
no desempeñar un papel central

189
00:16:02.669 --> 00:16:08.669
en el manejo de información tan sensible. Y Georg y su equipo eligieron un concepto,

190
00:16:08.669 --> 00:16:11.669
un camino, que nos mostró,

191
00:16:11.669 --> 00:16:17.669
que existen ideas completamente nuevas

192
00:16:17.669 --> 00:16:22.669
sobre cómo diseñar e implementar sistemas

193
00:16:22.669 --> 00:16:26.669
que nos elevan a un nivel de protección de datos completamente nuevo,

194
00:16:26.669 --> 00:16:31.669
a un nuevo nivel de soberanía, por un lado. Y por otro lado

195
00:16:31.669 --> 00:16:37.669
incluso resultan más amigables en el uso. Georg, ¿qué es mejor ahora

196
00:16:37.669 --> 00:16:44.019
en el HIN Mail que habéis construido? El nuevo HIN Mail para la comunicación

197
00:16:44.019 --> 00:16:50.019
entre profesionales sanitarios y pacientes es una aplicación llamada edge,

198
00:16:50.019 --> 00:16:55.019
es decir, una aplicación de punto final. Esto significa que el mensaje,

199
00:16:55.019 --> 00:17:01.019
cuando se envía, se cifra de manera muy potente, se trocea en muchas partes pequeñas

200
00:17:01.019 --> 00:17:07.019
y luego entra en un gran enjambre, donde simplemente muchas partes pequeñas revolotean, y nadie puede decir

201
00:17:07.019 --> 00:17:12.019
qué parte pertenece a quién. Y solo en el dispositivo del usuario,

202
00:17:12.019 --> 00:17:17.019
del paciente en este caso, todo se vuelve a unir. El usuario tiene una aplicación

203
00:17:17.019 --> 00:17:22.019
que se inicia automáticamente a través de una dirección web, la cual reúne todo de nuevo

204
00:17:22.019 --> 00:17:28.019
y sabe cómo encontrar las partes correctas y cómo reensamblarlas, cómo descifrarlas

205
00:17:28.019 --> 00:17:33.019
y se las muestra al paciente. Y todo esto sucede a la velocidad con la que carga una página web normal.

206
00:17:33.019 --> 00:17:38.019
Es decir, para el usuario se siente como si estuviera abriendo una página web,

207
00:17:38.019 --> 00:17:41.019
pero de hecho ocurren muchísimas cosas en segundo plano

208
00:17:41.019 --> 00:17:47.019
y en este sistema ya no hay un lugar central donde se puedan interceptar los datos,

209
00:17:47.019 --> 00:17:53.019
ni siquiera cifrados. HIN no puede, nosotros no podemos y nadie más puede,

210
00:17:53.019 --> 00:17:59.019
porque los datos simplemente no existen en un lugar central. ¿Y habría que tener todas las partes de ese enjambre

211
00:17:59.019 --> 00:18:05.019
para entender el mensaje? Exacto, es como un puzle enorme, pero no es un puzle de 1.000 piezas,

212
00:18:05.019 --> 00:18:09.019
sino que actualmente es un puzle de 800.000 piezas,

213
00:18:09.019 --> 00:18:14.019
que se envían cada mes y buscar entre todas esas piezas del puzle

214
00:18:14.019 --> 00:18:18.019
es bastante laborioso. O sea, se ha vuelto mucho más seguro

215
00:18:18.019 --> 00:18:23.019
y sí, creo que especialmente ahora con la guerra en Irán,

216
00:18:23.019 --> 00:18:27.019
donde se lee constantemente también sobre ciberataques en los medios,

217
00:18:27.019 --> 00:18:33.410
que van en aumento, etc., es extremadamente importante en el sistema sanitario

218
00:18:33.410 --> 00:18:38.410
invertir también en seguridad. Sí, claro, pero lo importante es pensar esta seguridad de forma que,

219
00:18:38.410 --> 00:18:43.410
incluso si algo sale mal, la resiliencia, es decir, la capacidad flexible del sistema

220
00:18:43.410 --> 00:18:48.410
para reaccionar ante problemas, la resiliencia,

221
00:18:48.410 --> 00:18:53.410
debe estar contemplada. Eso significa también que, incluso si HIN fuera hackeada —

222
00:18:53.410 --> 00:18:58.410
lo cual no preveo, HIN hace todo bien — pero incluso si eso sucediera,

223
00:18:58.410 --> 00:19:04.410
un atacante no podría leer esos mensajes, porque ni siquiera existen allí. Porque no están ahí.

224
00:19:05.410 --> 00:19:12.529
Bien, HIN Mail fue el comienzo

225
00:19:12.529 --> 00:19:18.529
de algo grande, por lo que he percibido. ¿Qué viene después? Ahora abordamos el tema

226
00:19:18.529 --> 00:19:24.529
de los problemas de interoperabilidad. Problemas de interoperabilidad.

227
00:19:24.529 --> 00:19:30.529
Menudo trabalenguas. Un tema enorme. Llegaremos a eso, pero antes esto:

228
00:19:30.529 --> 00:19:35.529
El problema de la interoperabilidad no es un problema de datos en sí, y mucho menos uno

229
00:19:35.529 --> 00:19:39.529
por falta de estándares. Casi tenemos demasiados estándares.

230
00:19:39.529 --> 00:19:45.529
Es un problema de confianza. Interoperabilidad significa

231
00:19:45.529 --> 00:19:52.130
que la comunicación funciona entre distintos sistemas. Correcto.

232
00:19:52.130 --> 00:19:57.309
Es un problema de confianza. Disculpa, te he interrumpido. No pasa nada.

233
00:19:57.309 --> 00:20:02.309
Me preguntaste ¿cuál es el próximo gran paso? Vamos a abordar ese tema.

234
00:20:02.309 --> 00:20:04.309
¿Y qué significa eso, Georg?

235
00:20:04.309 --> 00:20:09.910
Significa la capacidad de colaboración

236
00:20:09.910 --> 00:20:12.910
entre los distintos sistemas al fin y al cabo.

237
00:20:12.910 --> 00:20:18.910
Hoy en día cada consulta existe como una isla por sí sola.

238
00:20:18.910 --> 00:20:24.910
Cada hospital como una isla por sí solo. Ahora estas islas tienen que comunicarse entre sí. Para ello

239
00:20:24.910 --> 00:20:30.910
necesitamos caminos seguros entre las islas. Eso necesitamos.

240
00:20:30.910 --> 00:20:36.910
De lo contrario, los datos sanitarios volarían sin protección por ahí. No se sabría qué pasa con ellos.

241
00:20:36.910 --> 00:20:41.940
Así que necesitamos una capa de conexión segura entre los distintos sistemas.

242
00:20:41.940 --> 00:20:45.940
Y exactamente en eso estamos trabajando ahora. Para ser capaces en el futuro

243
00:20:45.940 --> 00:20:49.940
de intercambiar datos entre hospital y hospital, pero también entre hospital y consulta de medicina general

244
00:20:49.940 --> 00:20:55.940
u hospital y laboratorio, de manera que fluyan de forma estructurada, es decir, con inteligencia.

245
00:20:55.940 --> 00:21:01.940
Porque lo que se ha hecho hasta ahora eran procesos de papel digitalizados. Dicho crudamente, el PDF.

246
00:21:01.940 --> 00:21:07.940
Los datos que teníamos en aquella época, en aquel tiempo,

247
00:21:07.940 --> 00:21:13.940
eran... dicho crudamente, el PDF. Hablé de un cementerio de PDF,

248
00:21:13.940 --> 00:21:19.940
faxes — todos los conocemos. Y en principio en ese nivel es donde nos hemos quedado.

249
00:21:19.940 --> 00:21:25.940
Y para ser capaces de aprovechar el potencial de la digitalización para la salud,

250
00:21:25.940 --> 00:21:31.940
los sistemas tienen que empezar a intercambiar datos entre sí de forma que esos datos también tengan significado.

251
00:21:31.940 --> 00:21:37.940
Tengo una pregunta, porque el fax ya es realmente antiguo. Y supongo que

252
00:21:37.940 --> 00:21:43.940
simplemente asumo que ya se han probado distintos enfoques para lograr precisamente la interoperabilidad.

253
00:21:43.940 --> 00:21:50.359
¿Por qué debería funcionar ahora? ¿O por qué funciona la infraestructura actual?

254
00:21:50.359 --> 00:21:56.359
Todo el tema es algo que encaja perfectamente en HIN,

255
00:21:56.359 --> 00:22:02.359
porque es un problema de confianza. Hay que crear un espacio de datos basado en la confianza.

256
00:22:02.359 --> 00:22:08.359
Y ese espacio de datos debe estar protegido. Y antes solo se podía intentar con tecnologías centralizadas.

257
00:22:08.359 --> 00:22:14.359
Pero cuando utilizo tecnologías centralizadas, entonces siempre tengo un punto central

258
00:22:14.359 --> 00:22:20.359
donde está el control, de donde depende la seguridad, de donde depende cada decisión.

259
00:22:20.359 --> 00:22:26.359
Ese punto puede bloquearlo todo si no funciona. Y para las instituciones es difícil

260
00:22:26.359 --> 00:22:32.359
ponerse de acuerdo en tener un solo punto de confianza, que de hecho tiene el control

261
00:22:32.359 --> 00:22:38.359
sobre sus propios sistemas internos. Ese punto central interviene en los sistemas locales.

262
00:22:38.359 --> 00:22:44.359
Y eso es desde la lógica organizativa y desde la perspectiva de la confianza

263
00:22:44.359 --> 00:22:50.359
problemático. Por eso necesitamos una nueva estructura. Y nuevos sistemas

264
00:22:50.359 --> 00:22:56.359
y una nueva forma de pensar. Y justamente me llama la atención, Georg, cuando explicaste esto,

265
00:22:56.359 --> 00:23:02.359
el tema de la identidad electrónica adquiere un significado completamente nuevo. E-ID.

266
00:23:02.359 --> 00:23:06.359
Quizá también la E-ID, pero quedémonos primero con la identidad HIN.

267
00:23:06.359 --> 00:23:10.359
Médicos de familia, enfermeros, hospitales la conocen, todos conocen esta identidad HIN.

268
00:23:10.359 --> 00:23:16.359
Y es una prueba de identidad electrónica con algunos atributos adicionales. Muy importante, ¿verdad?

269
00:23:16.359 --> 00:23:22.359
Eso lo hacemos con éxito desde hace varias décadas. Y entonces uno se identifica o es como una llave

270
00:23:22.359 --> 00:23:28.359
y entonces puede abrir aplicaciones. Esa es la identidad HIN. Pero para abordar el tema que Georg esbozó,

271
00:23:28.359 --> 00:23:34.359
a saber, hacer que los datos estructurados sean intercambiables,

272
00:23:34.359 --> 00:23:40.359
se necesita una nueva forma de identificación del objeto.

273
00:23:40.359 --> 00:23:46.359
Y ahí nuestras identidades actuales no sirven en absoluto. Y ahí hemos desarrollado

274
00:23:46.359 --> 00:23:52.359
soluciones para abordar de forma novedosa el problema de confianza

275
00:23:52.359 --> 00:23:56.359
en el intercambio de datos estructurados.

276
00:23:56.359 --> 00:24:01.930
¿Y es alguna tecnología especial la que

277
00:24:01.930 --> 00:24:08.539
utilizáis? ¿O qué es lo nuevo? Todo se basa

278
00:24:08.539 --> 00:24:14.539
en el principio de la gestión descentralizada de claves o Self-Sovereign Identity,

279
00:24:14.539 --> 00:24:20.539
es decir, SSI. Y la E-ID suiza se basa exactamente en este mismo principio.

280
00:24:20.539 --> 00:24:26.539
Y al final se trata de que cada dispositivo y cada persona reciba

281
00:24:26.539 --> 00:24:32.539
una identidad. Es decir, tengo identidades de servicios individuales

282
00:24:32.539 --> 00:24:38.539
en el hospital, pero también de agentes, cuando pienso en temas de agentic AI y demás. En principio

283
00:24:38.539 --> 00:24:44.539
cada interacción debe existir entre dos identidades

284
00:24:44.539 --> 00:24:50.539
identificadas. ¿He entendido bien? ¿Utilizáis la misma tecnología que la Confederación

285
00:24:50.539 --> 00:24:56.539
para la E-ID? El mismo principio arquitectónico está en la base.

286
00:24:56.539 --> 00:25:02.539
Lo que nosotros construimos va incluso un nivel más profundo, porque necesita ser aún más descentralizado

287
00:25:02.539 --> 00:25:08.539
que lo que la Confederación construye actualmente. Porque la Confederación está sola. La Confederación emite la E-ID.

288
00:25:08.539 --> 00:25:12.539
No puedo obtener un pasaporte suizo de nadie más que del gobierno suizo.

289
00:25:12.539 --> 00:25:18.539
Por eso es mucho más centralizado que lo que nosotros construimos. Porque se ajusta al caso de uso.

290
00:25:18.539 --> 00:25:24.539
Pero en nuestro caso cada hospital es por supuesto casi su propio mundo,

291
00:25:24.539 --> 00:25:30.539
con muchísimos sistemas, muchísimas personas, muchísimos servicios, y en el futuro también

292
00:25:30.539 --> 00:25:36.539
soluciones de agentic AI y demás. Y eso ya es una federación en sí misma.

293
00:25:36.539 --> 00:25:42.539
Y esta federación tiene que poder interactuar con otras federaciones igualmente complejas.

294
00:25:42.539 --> 00:25:48.539
Y deben poder identificarse mutuamente para saber: esta solicitud viene

295
00:25:48.539 --> 00:25:54.539
de este sistema automatizado, de este hospital, y realmente está autorizado por el hospital

296
00:25:54.539 --> 00:26:00.539
para hacer esta solicitud, para poder decir a mi sistema local: sí, este sistema está

297
00:26:00.539 --> 00:26:06.539
autorizado para hacerlo. Todo esto se vuelve bastante rápido bastante complejo si quieres resolverlo

298
00:26:06.539 --> 00:26:12.539
bien. Pero tenemos que resolverlo bien, porque si no simplemente tendremos un vago

299
00:26:12.539 --> 00:26:18.539
"viene de ese hospital, ya estará bien". Y después no puedo demostrar en absoluto de qué

300
00:26:18.539 --> 00:26:24.539
se trataba, quién era, qué sistema preguntó, ¿entregué los datos correctos? Todos los

301
00:26:24.539 --> 00:26:30.539
sistemas — no puedo demostrarlo después. Y si algo sale mal, eso sería por supuesto un riesgo enorme. No te lo puedes

302
00:26:30.539 --> 00:26:36.539
permitir. Por eso necesitamos este grado de seguridad y trazabilidad y

303
00:26:36.539 --> 00:26:42.539
auditabilidad. ¿Por qué podemos hacerlo? Porque de hecho ya tenemos una infraestructura base

304
00:26:42.539 --> 00:26:48.539
hoy. Ya existe. Ya la hay, exacto. Ahora se está renovando.

305
00:26:48.539 --> 00:26:54.539
Y luego seguirá existiendo, ¿verdad? Y esa nueva infraestructura base será

306
00:26:54.539 --> 00:27:00.539
el fundamento para exactamente lo que Georg explicó. Y esta infraestructura base existe para toda

307
00:27:00.539 --> 00:27:06.569
Suiza. ¿Lo entiendo correctamente? Quizá deba preguntar, hemos oído

308
00:27:06.569 --> 00:27:12.569
cuántos millones quiere invertir la Confederación en los próximos años en el sistema sanitario,

309
00:27:12.569 --> 00:27:18.569
para construir, por ejemplo, un Swiss Health Data Space. ¿Qué relación tiene? ¿O no la tiene?

310
00:27:18.569 --> 00:27:24.730
¿Estáis construyendo en realidad ya aquello que la Confederación apenas

311
00:27:24.730 --> 00:27:30.730
quiere empezar? Pregunta interesante. HIN renueva

312
00:27:30.730 --> 00:27:36.730
su infraestructura base. HIN renueva la forma de prestación de servicios. Y

313
00:27:36.730 --> 00:27:42.730
HIN trabaja en que en última instancia el tema de la soberanía digital para cada

314
00:27:42.730 --> 00:27:48.730
miembro individual — desde una persona hasta una organización — se pueda realizar. Eso es lo que hacemos.

315
00:27:48.730 --> 00:27:54.730
Lo hacemos independientemente de la Confederación. En paralelo existe de hecho el programa DigiSanté. Lo observamos.

316
00:27:54.730 --> 00:28:00.730
Lo observamos. Estamos en contacto con DigiSanté. Constatamos,

317
00:28:00.730 --> 00:28:06.730
al menos así lo entiendo yo, que DigiSanté se ocupa sobre todo de que se definan

318
00:28:06.730 --> 00:28:12.730
determinadas reglas, determinados parámetros marco, para que un espacio de datos así

319
00:28:12.730 --> 00:28:18.730
pueda surgir. Y si ese espacio de datos sustituirá algún día el espacio de confianza de HIN,

320
00:28:18.730 --> 00:28:24.730
que de hecho ya existe que de hecho ya existe desde hace casi 20 años,

321
00:28:24.730 --> 00:28:30.730
o si habrá conexiones entre ambos, eso todavía está completamente abierto.

322
00:28:30.730 --> 00:28:36.789
Exacto. Exacto. Y si puedo añadir brevemente. Quiero decir,

323
00:28:36.789 --> 00:28:42.789
nosotros, es decir, Vereign, también hemos construido para el proyecto europeo de espacio de datos Gaia-X

324
00:28:42.789 --> 00:28:48.789
la capa base. Exactamente esa capa de gestión de claves e identidades es

325
00:28:48.789 --> 00:28:54.789
nuestra. Y hemos acompañado todos los proyectos de espacios de datos sanitarios, los llamados Lighthouses.

326
00:28:54.789 --> 00:29:00.789
Hemos trabajado con la Charité de Berlín y con otros para analizar exactamente estos temas. Y esa es

327
00:29:00.789 --> 00:29:06.789
la realidad técnica. Es decir, por un lado está la realidad semántica y administrativa superior.

328
00:29:06.789 --> 00:29:12.789
¿Qué debe reflejar? Pero debajo está la realidad técnica. Y eso es lo que tanto valoro de nuestra

329
00:29:12.789 --> 00:29:16.789
colaboración, porque HIN es pragmática. Empieza allí donde puede crear valor

330
00:29:18.789 --> 00:29:24.789
nivel técnico. Y resolvemos el problema técnicamente de forma tan limpia que creamos la base

331
00:29:24.789 --> 00:29:30.789
para implementar estos temas en el futuro de forma sólida en Suiza. Y déjame desgranar el valor en este contexto.

332
00:29:30.789 --> 00:29:36.789
Valor para nosotros significa, si hacemos zoom a una consulta, allí cada uno tiene un buen

333
00:29:36.789 --> 00:29:42.789
sistema de información de consulta. Unos están en la nube, otros están instalados localmente,

334
00:29:42.789 --> 00:29:48.789
como sea. Trabajan de forma altamente moderna y digital. Cuando un paciente, por ejemplo,

335
00:29:48.789 --> 00:29:54.789
es derivado a un hospital, hay procesos de trabajo

336
00:29:54.789 --> 00:30:00.789
y los sistemas los apoyan. Pero al final es igual de laborioso. Igual de

337
00:30:00.789 --> 00:30:06.789
laborioso, porque es un silo informático y no hay conexiones automáticas. Valor

338
00:30:06.789 --> 00:30:12.789
para nosotros significa que en el futuro, cuando un médico haga una derivación desde su sistema primario,

339
00:30:12.789 --> 00:30:18.789
que no tenga que lidiar con dobles entradas e intrusiones y actividades manuales que interrumpen el proceso

340
00:30:18.789 --> 00:30:24.789
para sacar finalmente la cosa de su consulta. Ahí volvemos a la carga administrativa. Ahí es donde intervenimos.

341
00:30:24.789 --> 00:30:30.789
Exacto, buen punto, David. Lo que sucede entonces es que la carga administrativa

342
00:30:30.789 --> 00:30:36.789
efectivamente se reduce. La carga administrativa en la mayoría de los casos

343
00:30:36.789 --> 00:30:42.859
no se puede facturar. No se puede facturar. Es tiempo muerto.

344
00:30:42.859 --> 00:30:48.859
Es innecesario. Desde el punto de vista del médico eso es lastre.

345
00:30:48.859 --> 00:30:54.859
Y ahí es donde intervenimos, para hacer todo al final mucho más sencillo y soberano.

346
00:30:54.859 --> 00:31:03.859
Para mí ha sido sin duda

347
00:31:03.859 --> 00:31:09.859
mucha información la que hemos escuchado hoy. Y voy a intentar resumir en unos pocos

348
00:31:09.859 --> 00:31:15.859
puntos. Me llevo que al principio hablamos de los desafíos que existen en el sistema sanitario.

349
00:31:17.859 --> 00:31:23.859
me llevo que HIN con socios y proveedores de servicios — Vereign es uno de ellos — intenta crear algo

350
00:31:23.859 --> 00:31:29.900
que facilite la comunicación entre todos

351
00:31:29.900 --> 00:31:35.900
estos actores. Entre hospital, consulta, clínica, residencia, lo que sea.

352
00:31:35.900 --> 00:31:41.900
Quien sea. Y que la renovación de la plataforma está en plena marcha.

353
00:31:41.900 --> 00:31:47.900
Es un viaje. Se trata de nuevas tecnologías. Hemos oído hablar de SSI, que también la Confederación

354
00:31:47.900 --> 00:31:53.900
utiliza. Es decir, para mí suena a que, si la Confederación usa una tecnología que HIN

355
00:31:53.900 --> 00:31:59.900
ya utilizaba incluso antes, eso es como una confirmación de que funciona.

356
00:31:59.900 --> 00:32:06.500
Así me suena a mí. Y sí, viene mucho más. ¿Podéis

357
00:32:06.500 --> 00:32:13.049
confirmar rápidamente si mi resumen es más o menos correcto?

358
00:32:13.049 --> 00:32:19.049
Me parece acertado. Exacto. Estupendo. Y ahora déjame daros la palabra de nuevo.

359
00:32:19.049 --> 00:32:25.049
Si pudierais expresar un deseo dirigido a la política o a quien sea,

360
00:32:25.049 --> 00:32:31.049
¿qué tendría que pasar para que quizá las cosas avancen más rápido, para que los profesionales

361
00:32:31.049 --> 00:32:37.880
en su día a día tengan una vida más fácil? Georg. ¿Empiezo yo? Sí.

362
00:32:37.880 --> 00:32:44.650
Sí, para mí está claro, creo que sería extremadamente útil

363
00:32:44.650 --> 00:32:50.650
entender los datos como valor y como ventaja competitiva para

364
00:32:50.650 --> 00:32:56.650
Suiza. Y desearía que la Confederación aprovechara mucho más esta ventaja,

365
00:32:56.650 --> 00:33:02.650
realmente como — en inglés se dice Force Multiplier. Es decir, tengo una organización con la que

366
00:33:02.650 --> 00:33:08.650
puedo implementar la realidad técnica de forma muy eficiente y ya está haciéndolo. Por eso desearía que

367
00:33:08.650 --> 00:33:14.650
la Confederación se implicara mucho más, participara activamente y apoyara e impulsara activamente.

368
00:33:14.650 --> 00:33:21.099
Colaborara. Colaborara. Deseo enviado, diría yo.

369
00:33:21.099 --> 00:33:27.099
¿Peer? Eres un socio simpático. Nunca había oído algo así. Luego recibirás un premio

370
00:33:27.099 --> 00:33:33.099
para la caja. Exacto. No me parece malo.

371
00:33:33.099 --> 00:33:39.099
Tengo otro deseo. Tengo un deseo muy modesto. El suyo ha sido muy bonito.

372
00:33:39.099 --> 00:33:43.099
El mío es mucho más pequeño. Deseo menos

373
00:33:43.099 --> 00:33:48.819
regulación. Eso da para un pódcast propio para gente que

374
00:33:48.819 --> 00:33:54.819
se dedica a regular. Con mucho gusto, me apunto. Así que menos regulación.

375
00:33:54.819 --> 00:34:01.049
Regulación, porque entonces menos burocracia. ¿O por qué menos regulación?

376
00:34:01.049 --> 00:34:07.049
Sí, eso me gusta. Porque la regulación lleva a, es una forma de burocracia.

377
00:34:09.050 --> 00:34:15.050
Por supuesto, quiero decir, no queremos tener un salvaje oeste, anarquía.

378
00:34:15.050 --> 00:34:21.050
De ninguna manera. Pero constato que somos una estructura estatal única.

379
00:34:21.050 --> 00:34:27.050
No tenemos un solo sistema sanitario. Es una responsabilidad cantonal. Todo eso está bien.

380
00:34:27.050 --> 00:34:33.050
Y creo que es uno de los logros más increíbles. Pero, pero, pero, pero, cuando

381
00:34:33.050 --> 00:34:39.050
efectivamente, así lo percibo, desde mi modesta perspectiva, hay una cierta realidad cotidiana.

382
00:34:39.050 --> 00:34:45.050
Hay una realidad cotidiana en el sistema de salud y asistencia social. Y ya es bastante complicada.

383
00:34:45.050 --> 00:34:51.050
Y cuando permanentemente nuestros parlamentarios plantean cada vez más

384
00:34:51.050 --> 00:34:57.050
exigencias, a las que la administración tiene que reaccionar, lo cual es lógico.

385
00:34:57.050 --> 00:35:03.050
Pero esa oleada de esa...

386
00:35:03.050 --> 00:35:09.050
no la ira, la fuerza, el poder de estas exigencias

387
00:35:09.050 --> 00:35:15.050
regulatorias crece de tal manera que nadie puede seguir el ritmo.

388
00:35:15.050 --> 00:35:21.050
Y a veces tengo la impresión de que evidentemente también internamente hay ciertos

389
00:35:21.050 --> 00:35:27.050
retos de coordinación. Y eso bloquea. Lo que realmente me importa es, menos regulación, sí, menos burocracia,

390
00:35:27.050 --> 00:35:33.050
pero no, mi principal preocupación es que si viene otra ley más y

391
00:35:33.050 --> 00:35:39.050
aquí otro reglamento y allí otro anexo, eso nos lleva a la parálisis. Porque todos

392
00:35:39.050 --> 00:35:45.050
dicen: vale, primero tengo que esperar, ¿no? Esperemos a ese espacio de datos, a esa ley y aquello.

393
00:35:45.050 --> 00:35:51.050
Y entonces ya estamos en 2035, ¿no? Y los problemas fundamentales — palabras clave: beneficio, desarrollo,

394
00:35:51.050 --> 00:35:57.460
sencillez — simplemente se quedan en el camino. Realmente sería un tema para un pódcast aparte.

395
00:35:57.460 --> 00:36:03.460
Muchas gracias, Peer, por haber estado aquí hoy. Ha sido un placer. Muchas gracias, gracias también a Georg,

396
00:36:03.460 --> 00:36:09.940
a ti. Gracias por la invitación. Este ha sido el segundo episodio del pódcast de HIN «En camino

397
00:36:09.940 --> 00:36:15.940
por el sistema sanitario digital». Si tenéis preguntas o comentarios, consultad nuestras notas del programa.

398
00:36:15.940 --> 00:36:21.940
Ahí están todos los datos de contacto que necesitáis. Y si ahora habéis escuchado el pódcast solo en audio,

399
00:36:21.940 --> 00:36:27.940
me gustaría señalaros que también lo podéis ver en vídeo, por ejemplo en YouTube o

400
00:36:27.940 --> 00:36:33.940
en Spotify. Gracias por haber estado aquí hoy, queridos oyentes. O queridos espectadores.

401
00:36:33.940 --> 00:36:39.940
Y hasta el final, eso lo aprecio mucho. Volvemos en junio y entonces será «¡Feliz cumpleaños,

402
00:36:39.940 --> 00:36:45.940
querida HIN!» HIN cumple 30. Hablaremos entonces de cómo HIN pasó del correo electrónico

403
00:36:45.940 --> 00:36:51.940
a, sí, lo hemos oído hoy, la renovación de plataforma, a donde está hoy.

404
00:36:51.940 --> 00:36:53.940
Y me hace mucha ilusión.

405
00:36:53.940 --> 00:37:04.550
¡Hasta entonces, cuidaos mucho!

406
00:37:04.550 --> 00:37:08.550
Encantados de que hayas estado. Hasta la próxima «En camino por el sistema sanitario digital».