Tema 4.3 — Interoperabilidad y estándares de datos

En la salud y la atención, la interoperabilidad no es un detalle técnico sino un requisito de seguridad clínica y equidad: cuando los sistemas no pueden compartir los datos correctos, en la forma correcta, con significado inequívoco, en el punto de atención, las personas resultan dañadas y la inequidad se amplifica.

Por qué esto importa en la salud y la atención#

La atención de una persona rara vez sucede en un solo lugar. Un único episodio puede tocar una consulta general, un servicio de ambulancia, un departamento de urgencias, una sala de hospital, una enfermera comunitaria, una farmacia, un equipo de atención social, y un cuidador en casa. Cada uno de estos posee parte del registro. Si esas partes no se pueden reunir de forma segura y rápida, los clínicos toman decisiones con información faltante: una alergia no vista, una medicación doblemente prescrita, una prueba innecesariamente repetida, una marca de salvaguarda invisible para el equipo que la necesita.

La interoperabilidad es lo que convierte un conjunto de sistemas desconectados en algo que se comporta, desde el punto de vista del paciente, como un servicio conectado. Es la fontanería debajo de la atención integrada. Cuando funciona, un clínico en una organización puede ver lo que ha registrado otra, y puede confiar en que significa lo que piensa que significa. Cuando falla, el fallo a menudo es silencioso hasta que alguien resulta dañado.

Esto también es una cuestión de equidad. Las personas con las necesidades más complejas —adultos mayores frágiles, aquellos con múltiples condiciones a largo plazo, personas moviéndose entre servicios— son exactamente las personas cuyos datos están más fragmentados. La mala interoperabilidad, por lo tanto, daña más a los más vulnerables. Y es una cuestión de confianza pública: las personas razonablemente asumen que el NHS ya comparte su información sensatamente, y se consternan al saber con qué frecuencia no lo hace.

Finalmente, la interoperabilidad protege el dinero público. Los sistemas propietarios que no pueden intercambiar datos bloquean a las organizaciones en contratos costosos y difíciles de reemplazar y fuerzan integraciones punto a punto costosas. Construir según estándares abiertos es cómo mantienes las opciones abiertas, mantienes a los proveedores honestos, y evitas pagar repetidamente para resolver el mismo problema.

Conceptos clave#

La interoperabilidad es la capacidad de diferentes sistemas de intercambiar información y usarla. Es útil separar dos capas. La interoperabilidad sintáctica o técnica significa que dos sistemas pueden intercambiar un mensaje y cada uno puede analizar su estructura —el sobre llega y se puede abrir. La interoperabilidad semántica significa que el sistema receptor entiende qué significa el contenido de la misma forma que lo entendió el emisor —que un código para "alergia a la penicilina" se interpreta idénticamente en ambos lados. La interoperabilidad técnica sin interoperabilidad semántica es peligrosa: los datos fluyen, pero el significado se pierde o distorsiona.

Los datos de salud se intercambian usando estándares. Health Level 7 (HL7) es la familia de estándares más usada en la salud. Su mensajería más antigua HL7 versión 2 (v2), usando texto delimitado por barras verticales y acentos circunflejos, todavía sustenta una vasta cantidad de mensajería hospitalaria y lo hará durante años. Su estándar moderno, HL7 Fast Healthcare Interoperability Resources (FHIR), modela la información clínica como "recursos" intercambiados a través de interfaces de programación de aplicaciones (API) al estilo web, lo que facilita mucho más a los desarrolladores modernos trabajar con ellos.

Los estándares para el mensaje no son suficientes; también necesitas vocabularios estándar para el contenido. SNOMED CT (Nomenclatura Sistematizada de Medicina — Términos Clínicos) es la terminología clínica obligatoria en toda la atención del NHS para registrar diagnósticos, síntomas, procedimientos y más. El NHS Dictionary of medicines and devices (dm+d) es el vocabulario estándar para medicamentos y dispositivos médicos, y sustenta la prescripción electrónica. La Clasificación Internacional de Enfermedades, 10ª y 11ª revisiones (CIE-10 y CIE-11), mantenida por la Organización Mundial de la Salud, se usa para clasificación, estadísticas, y reembolso en lugar de registro clínico del día a día. openEHR es una especificación abierta para estructurar el registro de salud mismo a través de "arquetipos" compartidos y gobernados clínicamente, y algunas organizaciones lo usan para mantener los modelos de datos clínicos independientes de cualquier proveedor único.

Dos ideas más son fundacionales. El NHS Number es el identificador común de paciente que permite vincular de forma confiable los registros sobre la misma persona a través de organizaciones; sin un identificador compartido, la coincidencia es una conjetura. Y Integrating the Healthcare Enterprise (IHE) publica "perfiles" que especifican exactamente cómo combinar estándares existentes para resolver problemas concretos como compartir documentos, para que diferentes proveedores los implementen de la misma forma.

Sustentando todo esto hay una elección estratégica. Construir según estándares abiertos con API publicadas y reutilizables mantiene un mercado competitivo y tus datos portátiles. Depender de interfaces propietarias crea bloqueo de proveedor, donde cambiar de proveedor se vuelve tan costoso que efectivamente no puedes hacerlo. Nada de esto entrega valor, sin embargo, sin calidad de datos: datos precisos, completos, oportunos, y codificados consistentemente son la precondición para la interoperabilidad, no una idea de último momento.

Buenas prácticas#

1. Distinguir la interoperabilidad semántica de la técnica, y diseñar para ambas. Es fácil celebrar que un mensaje ahora fluye entre dos sistemas y pasar por alto que el clínico receptor no puede confiar de forma segura en su significado. Siempre pregunta: ¿interpreta el otro lado estos códigos, unidades, y negaciones exactamente como nosotros? Invierte en terminologías compartidas (SNOMED CT, dm+d) y conjuntos de valores, no solo formatos de mensaje, porque una alergia correctamente transmitida pero malinterpretada es más peligrosa que ningún mensaje en absoluto.

2. Construir según estándares abiertos y reutilizar plataformas en lugar de reinventar. Adopta el principio ampliamente respaldado: construir según estándares abiertos, y reutilizar plataformas y servicios nacionales existentes antes de construir el tuyo propio. En el NHS esto significa preferir las API de HL7 FHIR, usar el NHS Number como identificador, y conectarse a servicios nacionales como el Spine, GP Connect, y registros de atención compartidos en lugar de crear enlaces punto a punto a medida. La reutilización reduce el coste, distribuye la carga de mantenimiento, y significa que tus datos pueden viajar.

3. Hacer del NHS Number un elemento no negociable en cada registro y mensaje. La vinculación confiable de registros depende de un identificador común confiable. Asegúrate de que el NHS Number se capture, verifique frente al servicio demográfico nacional, y se lleve en cada registro e interfaz relevante. Donde falte o no esté verificado, trata eso como un defecto de calidad de datos a resolver, porque hacer coincidir solo por nombre y fecha de nacimiento produce tanto coincidencias peligrosas erróneas como vínculos perdidos.

4. Tratar la calidad de datos como un entregable de primer nivel. La interoperabilidad exporta tus problemas de calidad de datos a todos aguas abajo. Perfila tus datos, mide la completitud y la consistencia de codificación, y establece una administración para que los errores se encuentren y arreglen en la fuente. La deriva de codificación, el texto libre donde se necesitan datos estructurados, y las unidades inconsistentes corromperán silenciosamente cada análisis y vista clínica aguas abajo, así que financia este trabajo explícitamente en lugar de asumir que sucede por sí solo.

5. Preferir arquitecturas API primero, débilmente acopladas, sobre integraciones estrechas. Diseña para que las capacidades se expongan a través de API bien documentadas y versionadas que otros puedan consumir sin negociación a medida. Esto es más lento al principio que un enlace directo de base de datos, pero es lo que te permite reemplazar un componente sin reconstruir todo a su alrededor. También se alinea con cómo los servicios nacionales y los proveedores modernos ahora esperan integrarse, y apoya los enfoques de entrega en el Tema 3.5 — Ciclos de vida de entrega.

6. Usar perfiles publicados y pruebas de conformidad, no interpretaciones locales. Los estándares son flexibles, y dos equipos pueden implementar "el mismo" recurso FHIR de forma incompatible. Adopta guías de implementación nacionales y perfiles IHE que fijen los detalles, y exige a los proveedores demostrar conformidad frente a ellos antes de la puesta en marcha. Las pruebas de conformidad convierten "apoyamos FHIR" —una afirmación que significa muy poco por sí sola— en un hecho verificable y contractual.

7. Escribir requisitos de interoperabilidad y estándares abiertos en la contratación y los contratos. El momento más barato para evitar el bloqueo es antes de firmar. Exige API abiertas y documentadas, el derecho a extraer tus propios datos en un formato estándar, adherencia a estándares nombrados, y sin cargos por integraciones estándar. Trabaja con tus colegas comerciales (véase el Tema 6.3 — Contratación y aspectos comerciales) para que estos se conviertan en criterios de evaluación obligatorios, no aspiraciones negociadas después.

8. Gobernar la interoperabilidad con la seguridad clínica y la gobernanza de la información en la sala. Cada nuevo flujo de datos cambia el riesgo clínico y el manejo de información confidencial. Trae a los oficiales de seguridad clínica y líderes de gobernanza de la información a las decisiones de diseño desde el principio, no como una aprobación final, para que los registros compartidos sean tanto seguros como legales. Esto se conecta directamente con el Tema 1.6 — Seguridad clínica y gestión de riesgos y el Tema 1.7 — Gobernanza de la información, protección de datos y ciberseguridad.

Preguntas para debatir con tu equipo#

1. ¿Dónde en nuestras vías de atención crean los datos faltantes o malinterpretados el mayor riesgo clínico hoy? La inversión en interoperabilidad debería seguir al daño y al valor, no a la moda arquitectónica. Mapea los recorridos que realmente toman tus pacientes más complejos y encuentra los traspasos donde la información se pierde, se retrasa, o llega sin significado confiable. Pregunta a los clínicos dónde trabajan rutinariamente a ciegas —los traslados, las brechas fuera de horario, el límite entre la salud y la atención social. Distingue los lugares donde los datos no fluyen en absoluto de los lugares donde fluyen pero no se puede confiar en ellos, porque estos necesitan arreglos diferentes. Considera qué poblaciones están más afectadas, ya que la fragmentación tiende a caer con más fuerza en las personas con las necesidades más complejas. La respuesta te dice por dónde empezar, y te da un caso de seguridad clínica que pesará más que cualquier argumento técnico.

2. ¿Qué tan expuestos estamos al bloqueo de proveedor, y qué nos costaría realmente cambiar nuestros sistemas clínicos principales? Muchas organizaciones descubren el precio real de un sistema cerrado solo cuando intentan salir de él. Trabaja a través de, concretamente, qué se necesitaría para extraer tus datos en una forma usable y estándar y moverte a otro proveedor. Examina tus contratos en busca de quién posee los datos, qué interfaces estándar existen, y si se te cobra por integraciones que deberían ser rutinarias. Identifica las interfaces propietarias y formatos de datos que tendrían que deshacerse. Sopesa esto frente a la apertura de alternativas y plataformas nacionales que podrías reutilizar en su lugar. Esto no se trata de cambiar de proveedor constantemente; se trata de entender tu influencia y reducir el riesgo de que la hoja de ruta de un único proveedor se convierta en tu única opción.

3. ¿Son nuestros datos suficientemente buenos para compartir de forma segura, y cómo lo sabríamos? Compartir datos pobres no solo te avergüenza —propaga errores hacia las decisiones de otros clínicos. Pregunta si realmente mides la completitud, precisión, oportunidad, y consistencia de codificación de los datos que pretendes exponer. Discute quién posee la calidad de datos en tu organización y si tienen el tiempo y mandato para arreglar problemas en la fuente. Considera qué proporción de registros lleva un NHS Number verificado y cuánta información clínicamente importante todavía se sitúa en texto libre en lugar de campos codificados. Piensa en cómo detectarías un error sistemático de codificación antes de que llegara a un registro de atención compartido. Si no puedes responder estas preguntas con evidencia, trata eso como un hallazgo en sí mismo, y financia el trabajo de calidad de datos antes de ampliar la tubería.

4. Cuando un proveedor dice "apoyamos FHIR", ¿cómo lo verificaríamos realmente antes de la puesta en marcha? Una etiqueta de estándares es una afirmación de marketing hasta que se prueba frente a una guía de implementación específica. Discute si tu organización tiene alguna capacidad de pruebas de conformidad propia, o si simplemente tomas la palabra de los proveedores. Dos sistemas pueden cada uno ser "conformes con FHIR" y aún así no poder intercambiar un mensaje usable, porque el estándar es deliberadamente flexible y el significado vive en los perfiles y conjuntos de valores que lo fijan. Pregunta qué guías de implementación nacionales y perfiles IHE aplican a la interfaz en cuestión, y quién de tu lado es competente para leerlos. Considera si la conformidad está escrita en el contrato como una condición para conectarse, o se descubre dolorosamente durante la integración. Una respuesta honesta nombra el perfil específico contra el que probarías, la persona o función que ejecutaría la prueba, y el punto en el calendario donde un proveedor que falla se rechaza en lugar de dejarse pasar.

5. ¿Quién posee los estándares, la terminología, y la conformidad en toda nuestra organización, y tienen el mandato de decir no? La interoperabilidad se degrada sin administración: los conjuntos de valores derivan, las guías locales divergen, y cada nuevo proyecto silenciosamente inventa su propia interpretación. Pregunta si hay una función nombrada responsable de los estándares, los subconjuntos de SNOMED CT y dm+d, y la conformidad, o si este conocimiento se sitúa en las cabezas de unos pocos individuos. Considera la tensión entre la consistencia central y la velocidad de entrega local —los equipos bajo presión construirán la cosa más rápida a menos que una función de estándares tenga autoridad real para exigir reutilización. Discute cómo se financia el mantenimiento de terminología, dado que es poco glamoroso, continuo, y beneficia a todos en lugar de a un único proyecto. Mira cómo mantienes las implementaciones alineadas a medida que evolucionan FHIR, SNOMED CT, y las guías nacionales, en lugar de congelarte en la versión que adoptaste primero. Una respuesta honesta identifica al propietario responsable, su financiación, y un ejemplo reciente donde aplicaron un estándar o no lo hicieron.

6. ¿Están informadas y contentas las personas cuyos registros estamos uniendo con cómo fluyen sus datos? La interoperabilidad no es solo un asunto técnico y clínico sino una cuestión de confianza pública y base legal. Las personas razonablemente asumen que el NHS ya comparte su información sensatamente, y se consternan tanto cuando no lo hace como cuando lo hace de formas que no esperaban. Discute si los pacientes entienden qué organizaciones pueden ver su registro compartido, cómo se respeta un National Data Opt-Out o modelo de consentimiento local a través del flujo, y cómo se registra y audita el acceso. Considera la dimensión de equidad: las personas cuyos datos están más fragmentados —aquellas con necesidades complejas— también son las menos capaces de navegar opt-outs y avisos de información. Trae a la gobernanza de la información y, donde sea relevante, a pacientes o sus representantes al diseño en lugar de tratar el consentimiento como una casilla marcada al final. Una respuesta honesta puede describir la base legal para cada flujo, cómo una persona descubriría quién ha visto su registro, y cómo se respetan sus elecciones de extremo a extremo.

En la práctica: un ejemplo de salud y atención#

Un sistema de atención integrada en el norte de Inglaterra se propone dar a los clínicos una única vista de medicamentos compartidos a través de la consulta general, el hospital, y la farmacia comunitaria, después de que una revisión de incidente grave encontró que a un paciente se le habían prescrito dos medicamentos interactuantes por equipos que no podían ver los registros del otro.

La tentación es comprar un "panel de medicamentos" de un proveedor y conectarlo directamente a la base de datos de cada sistema. El líder de interoperabilidad resiste esto. En su lugar, el programa adopta un enfoque de construir según estándares abiertos. Cada sistema fuente expone los datos de medicación como recursos HL7 FHIR; cada medicamento se codifica usando el dm+d para que "el mismo medicamento" signifique lo mismo en todas partes; y cada registro se indexa según un NHS Number verificado para que los medicamentos correctos se adjunten a la persona correcta. Los datos de médico de cabecera se extraen a través de GP Connect en lugar de un feed a medida, reutilizando una capacidad nacional en lugar de inventar una local.

El perfilado temprano de datos prueba su valor inmediatamente. El sistema de una consulta ha estado registrando ciertos medicamentos en texto libre en lugar de como entradas codificadas dm+d, lo que significa que habrían sido invisibles para cualquier verificación automatizada de interacciones. Esto se arregla en la fuente antes de la puesta en marcha. El equipo también encuentra un grupo de registros con NHS Numbers no verificados y los dirige a través del servicio demográfico nacional para hacer coincidir.

El oficial de seguridad clínica y el líder de gobernanza de la información son parte del grupo de diseño durante todo el proceso. Juntos definen exactamente qué datos se comparten, con quién, bajo qué base legal, y cómo se registra el acceso de un clínico —las preocupaciones del Tema 1.7 — Gobernanza de la información, protección de datos y ciberseguridad. Los proveedores deben pasar las pruebas de conformidad frente a la guía nacional de implementación FHIR antes de conectarse. Doce meses después, la vista de medicación unida está en vivo, ya se ha capturado una interacción que previamente se habría perdido, y —porque todo se construyó según interfaces abiertas— un segundo caso de uso, información de alergias compartida, reutiliza la mayor parte de la misma fontanería a una fracción del coste original.

Perspectivas sectoriales#

Startup#

Una startup de salud digital vive o muere por cuán fácilmente se conecta a los sistemas existentes, así que trata la interoperabilidad como una funcionalidad central, no una tarea de cumplimiento. Construir API FHIR y usar SNOMED CT y dm+d desde el principio te hace mucho más fácil de comprar e integrar, y señala madurez a los compradores cautelosos del NHS. Resiste el impulso de inventar tu propio modelo de datos cuando existe un estándar; tu diferenciación debería ser tu producto, no un formato propietario que se convierte en una responsabilidad. Acertar temprano con el manejo del NHS Number y la gobernanza de la información es lo que te permite pasar de piloto a contratación. Diseña para que un cliente pueda, en principio, extraer sus datos e irse —paradójicamente, esa apertura es lo que se gana la confianza para mantenerlos.

Pequeña empresa#

Un proveedor pequeño y establecido —una consulta de médico de cabecera, una farmacia comunitaria, una residencia de cuidados, o una clínica de un solo emplazamiento— carga con los mismos deberes de compartir datos de forma segura que el fideicomiso más grande, pero con una fracción de la capacidad técnica. Aquí la interoperabilidad es mayormente una disciplina de contratación y configuración en lugar de ingeniería: elige sistemas que ya hablen FHIR, conéctate a servicios nacionales como GP Connect y el Spine, y codifica con SNOMED CT y dm+d de fábrica, para que heredes estándares en lugar de construirlos. Haz de la captura verificada del NHS Number parte de la práctica cotidiana, porque sin un equipo de integración para reconciliar discrepancias después, acertar con el identificador en el punto de registro es tu salvaguarda más económica. Apóyate en programas de registro de atención compartido y la infraestructura compartida de tu sistema de atención integrada en lugar de encargar enlaces a medida que no puedes mantener. Cuando firmes o renueves un contrato de sistema, insiste en derechos de extracción de datos e interfaces abiertas en términos claros, porque una organización pequeña siente el bloqueo de proveedor de forma más aguda y tiene la menor influencia para escapar de él después del hecho.

Gran organización#

Un gran proveedor típicamente carga con décadas de legado: interfaces HL7 v2, múltiples sistemas de registro electrónico, y motores de integración que mantienen todo unido. La estrategia realista no es arrancar todo sino poner una capa API primero y basada en estándares frente al patrimonio, migrando flujos a FHIR incrementalmente mientras mantienes v2 funcionando donde debe. Protégete fuertemente contra el bloqueo en cada renovación, e insiste en pruebas de conformidad para que "conforme con estándares" se verifique en lugar de afirmarse. Establece una función interna de estándares y conformidad para que los proyectos individuales no inventen cada uno su propia interpretación. Esto está estrechamente relacionado con cómo gestionas las plataformas operativas centrales en el Tema 5.4 — Planificación de recursos empresariales (ERP), donde aplica la misma disciplina de reutilización e interfaz abierta.

Gobierno#

Los organismos nacionales y regionales establecen las reglas del mercado, así que sus elecciones sobre estándares se propagan a través de cada organización. Lo más valioso que puede hacer el gobierno es exigir estándares abiertos, publicar guías de implementación claras y requisitos de conformidad, y proporcionar plataformas nacionales reutilizables —el Spine, GP Connect, marcos de registro de atención compartido, el servicio NHS Number— para que las organizaciones locales construyan una vez y reutilicen. La consistencia importa más que la perfección: un estándar suficientemente bueno firmemente aplicado vence a uno teóricamente superior que todos implementan de forma diferente. El gobierno también debe financiar el trabajo poco glamoroso del mantenimiento de terminología y la mejora de la calidad de datos, porque estos son bienes públicos que ninguna organización individual financiará sola. Este rol de administración se conecta con el Tema 9.1 — Trabajo con los gobiernos locales y nacionales y con cómo colaboran los socios en el Tema 9.0 — Colaboración con organizaciones asociadas.

Modos de fallo comunes#

• Confundir la conexión técnica con la comprensión semántica. Declarar victoria cuando un mensaje fluye, sin confirmar que ambos lados interpretan sus códigos, unidades, y negaciones idénticamente. El resultado son datos que parecen integrados pero se malinterpretan silenciosamente.
• Compartir datos pobres más rápido. Ampliar la tubería antes de arreglar la calidad de datos, para que los errores de codificación, el texto libre, y los NHS Numbers faltantes se propaguen hacia las decisiones de otros clínicos y cada análisis aguas abajo.
• "Apoyamos FHIR" como afirmación vacía. Aceptar una etiqueta de estándares sin pruebas de conformidad frente a una guía de implementación específica, para que dos sistemas "conformes" todavía no puedan hablar entre sí.
• Integraciones punto a punto a medida. Construir enlaces directos entre cada par de sistemas, produciendo una red frágil que se vuelve exponencialmente más difícil y costosa de mantener a medida que crece.
• Bloqueo por defecto. Firmar contratos con interfaces propietarias y sin derechos de extracción de datos, descubriendo el coste de la trampa solo cuando intentas cambiar de proveedor.
• Tratar la gobernanza como una puerta final. Traer la seguridad clínica y la gobernanza de la información solo para aprobar, así que los problemas salen a la superficie tarde y costosamente, o se dejan pasar bajo presión de entrega.
• Estándares sin administración. Adoptar terminologías y perfiles pero sin financiar a nadie para mantener los conjuntos de valores, monitorear la conformidad, o mantener las implementaciones alineadas a medida que evolucionan los estándares.

Modelo de madurez#

Lista de verificación#

• Cada registro e interfaz relevante lleva un NHS Number verificado, con un proceso para resolver los faltantes o no coincidentes.
• Las nuevas interfaces usan HL7 FHIR y guías nacionales de implementación nombradas, con HL7 v2 retenido solo donde la migración aún no está justificada.
• El contenido clínico se codifica usando SNOMED CT, y los medicamentos usando dm+d, frente a conjuntos de valores acordados.
• La calidad de datos para cualquier cosa que pretendas compartir se perfila, mide, posee, y mejora en la fuente antes de ampliar la tubería.
• Los proveedores deben pasar pruebas de conformidad frente a un perfil específico antes de conectarse —"apoya FHIR" nunca se acepta por sí solo.
• Las plataformas nacionales (Spine, GP Connect, registros de atención compartidos) se reutilizan antes de construir cualquier integración a medida.
• Los contratos exigen API abiertas y documentadas, derechos de extracción de datos en un formato estándar, y sin cargos por integraciones estándar.
• Los líderes de seguridad clínica y gobernanza de la información están en el grupo de diseño desde el principio, no solo en la aprobación.
• La arquitectura es API primero y débilmente acoplada, para que un componente pueda reemplazarse sin reconstruir todo a su alrededor.
• Una función nombrada posee los estándares, la conformidad, y el mantenimiento de terminología en toda la organización.

Fuentes clave#

• NHS England — estándares de interoperabilidad, el Spine, GP Connect, y programas de registro de atención compartido.
• HL7 International — el estándar FHIR y las especificaciones HL7 v2.
• SNOMED International — terminología SNOMED CT y orientación de implementación.
• NHS Business Services Authority — el Dictionary of medicines and devices (dm+d).
• Integrating the Healthcare Enterprise (IHE) — perfiles de interoperabilidad.
• openEHR International — especificaciones abiertas para estructurar el registro de salud.
• Organización Mundial de la Salud — la Clasificación Internacional de Enfermedades (CIE-10 y CIE-11).

Referencias#

1. Interoperability — Wikipedia — https://en.wikipedia.org/wiki/Interoperability
2. Semantic interoperability — Wikipedia — https://en.wikipedia.org/wiki/Semantic_interoperability
3. Health Level 7 — Wikipedia — https://en.wikipedia.org/wiki/Health_Level_7
4. Fast Healthcare Interoperability Resources — Wikipedia — https://en.wikipedia.org/wiki/Fast_Healthcare_Interoperability_Resources
5. SNOMED CT — Wikipedia — https://en.wikipedia.org/wiki/SNOMED_CT
6. ICD-11 — Wikipedia — https://en.wikipedia.org/wiki/ICD-11
7. ICD-10 — Wikipedia — https://en.wikipedia.org/wiki/ICD-10
8. openEHR — Wikipedia — https://en.wikipedia.org/wiki/OpenEHR
9. NHS number — Wikipedia — https://en.wikipedia.org/wiki/NHS_number
10. Integrating the Healthcare Enterprise — Wikipedia — https://en.wikipedia.org/wiki/Integrating_the_Healthcare_Enterprise
11. Open standard — Wikipedia — https://en.wikipedia.org/wiki/Open_standard
12. Vendor lock-in — Wikipedia — https://en.wikipedia.org/wiki/Vendor_lock-in
13. API — Wikipedia — https://en.wikipedia.org/wiki/API
14. Data quality — Wikipedia — https://en.wikipedia.org/wiki/Data_quality
15. FHIR standard — HL7 International — https://www.hl7.org/fhir/
16. SNOMED CT — SNOMED International — https://www.snomed.org/
17. Dictionary of medicines and devices (dm+d) — NHS Business Services Authority — https://www.nhsbsa.nhs.uk/pharmacies-gp-practices-and-appliance-contractors/dictionary-medicines-and-devices-dmd
18. GP Connect — NHS England Digital — https://digital.nhs.uk/services/gp-connect
19. Spine — NHS England Digital — https://digital.nhs.uk/services/spine
20. International Classification of Diseases (ICD) — World Health Organization — https://www.who.int/standards/classifications/classification-of-diseases