Tópico 4.3 — Interoperabilidade e padrões de dados

Na saúde e nos cuidados, a interoperabilidade não é um refinamento técnico, mas uma exigência de segurança clínica e de equidade: quando os sistemas não conseguem compartilhar os dados certos, na forma certa, com significado inequívoco, no ponto de cuidado, as pessoas são prejudicadas e a iniquidade é amplificada.

Por que isso importa na saúde e nos cuidados#

O cuidado de uma pessoa raramente acontece num só lugar. Um único episódio pode tocar uma clínica geral, um serviço de ambulância, um pronto-socorro, uma enfermaria hospitalar, uma enfermeira comunitária, uma farmácia, uma equipe de cuidados sociais e um cuidador em casa. Cada um deles detém parte do prontuário. Se essas partes não podem ser reunidas com segurança e rapidez, os clínicos tomam decisões com informações faltando: uma alergia não vista, um medicamento prescrito em duplicidade, um exame repetido sem necessidade, uma sinalização de proteção invisível à equipe que precisa dela.

A interoperabilidade é o que transforma um conjunto de sistemas desconectados em algo que se comporta, do ponto de vista do paciente, como um serviço integrado. É a infraestrutura por baixo do cuidado integrado. Quando funciona, um clínico de uma organização pode ver o que outra registrou e confiar que significa o que ele pensa que significa. Quando falha, a falha costuma ser silenciosa até que alguém seja prejudicado.

É também uma questão de equidade. As pessoas com as necessidades mais complexas — idosos frágeis, os com múltiplas condições crônicas, pessoas que circulam entre serviços — são exatamente aquelas cujos dados são mais fragmentados. A má interoperabilidade prejudica, portanto, mais os mais vulneráveis. E é uma questão de confiança pública: as pessoas supõem, com razão, que o NHS já compartilha suas informações de forma sensata e ficam consternadas ao saber com que frequência não o faz.

Por fim, a interoperabilidade protege o dinheiro público. Sistemas proprietários que não trocam dados prendem as organizações em contratos caros e difíceis de substituir e forçam integrações ponto a ponto custosas. Construir sobre padrões abertos é como se mantêm as opções abertas, os fornecedores honestos e se evita pagar repetidamente para resolver o mesmo problema.

Conceitos centrais#

A interoperabilidade é a capacidade de sistemas diferentes de trocar informações e usá-las. É útil separar duas camadas. A interoperabilidade sintática ou técnica significa que dois sistemas conseguem trocar uma mensagem e cada um consegue interpretar sua estrutura — o envelope chega e pode ser aberto. A interoperabilidade semântica significa que o sistema receptor entende o que o conteúdo significa do mesmo modo que o emissor — que um código para "alergia à penicilina" é interpretado de forma idêntica nos dois lados. A interoperabilidade técnica sem a semântica é perigosa: os dados fluem, mas o significado se perde ou se distorce.

Os dados de saúde são trocados por meio de padrões. O Health Level 7 (HL7) é a família de padrões mais usada na saúde. Sua mensagem mais antiga, a HL7 versão 2 (v2), em texto delimitado por barras verticais e acentos circunflexos, ainda sustenta uma enorme quantidade de mensagens hospitalares e assim continuará por anos. Seu padrão moderno, o HL7 Fast Healthcare Interoperability Resources (FHIR), modela a informação clínica como "recursos" trocados por interfaces de programação de aplicações (APIs) ao estilo da web, o que torna o trabalho muito mais fácil para os desenvolvedores modernos.

Padrões para a mensagem não bastam; também são necessários vocabulários padronizados para o conteúdo. A SNOMED CT (Systematized Nomenclature of Medicine — Clinical Terms) é a terminologia clínica obrigatória em todo o cuidado do NHS para registrar diagnósticos, sintomas, procedimentos e mais. O NHS Dictionary of medicines and devices (dm+d) é o vocabulário padrão para medicamentos e dispositivos médicos e sustenta a prescrição eletrônica. As Classificações Internacionais de Doenças, 10ª e 11ª revisões (CID-10 e CID-11), mantidas pela Organização Mundial da Saúde, são usadas para classificação, estatística e reembolso, e não para o registro clínico cotidiano. O openEHR é uma especificação aberta para estruturar o próprio prontuário por meio de "arquétipos" compartilhados e clinicamente governados, e é usado por algumas organizações para manter os modelos de dados clínicos independentes de qualquer fornecedor.

Duas outras ideias são fundamentais. O NHS Number é o identificador comum do paciente que permite vincular de forma confiável os registros sobre a mesma pessoa entre organizações; sem um identificador compartilhado, a correspondência é adivinhação. E o Integrating the Healthcare Enterprise (IHE) publica "perfis" que especificam exatamente como combinar padrões existentes para resolver problemas concretos, como o compartilhamento de documentos, para que fornecedores diferentes os implementem da mesma forma.

Sustentando tudo isso está uma escolha estratégica. Construir sobre padrões abertos, com APIs publicadas e reutilizáveis, mantém o mercado competitivo e seus dados portáteis. Apoiar-se em interfaces proprietárias cria dependência de fornecedor (vendor lock-in), em que trocar de fornecedor se torna tão custoso que na prática não se pode. Nada disso, porém, entrega valor sem qualidade de dados: dados exatos, completos, oportunos e codificados de forma consistente são a pré-condição da interoperabilidade, e não uma reflexão tardia.

Boas práticas#

1. Distinga a interoperabilidade semântica da técnica e projete para ambas. É fácil celebrar que uma mensagem agora flui entre dois sistemas e deixar de perceber que o clínico receptor não consegue confiar com segurança em seu significado. Pergunte sempre: o outro lado interpreta estes códigos, unidades e negações exatamente como nós? Invistam em terminologias compartilhadas (SNOMED CT, dm+d) e conjuntos de valores, e não apenas em formatos de mensagem, porque uma alergia corretamente transmitida, mas mal compreendida, é mais perigosa do que nenhuma mensagem.

2. Construa sobre padrões abertos e reutilize plataformas em vez de reinventá-las. Adote o princípio amplamente endossado: construir sobre padrões abertos e reutilizar as plataformas e serviços nacionais existentes antes de construir os seus. No NHS, isso significa preferir as APIs HL7 FHIR, usar o NHS Number como identificador e conectar-se a serviços nacionais como a Spine, o GP Connect e os prontuários de cuidados compartilhados em vez de criar ligações ponto a ponto sob medida. A reutilização reduz o custo, distribui o fardo da manutenção e significa que os seus dados podem viajar.

3. Faça do NHS Number um requisito inegociável em todo registro e mensagem. A vinculação confiável de registros depende de um identificador comum digno de confiança. Garantam que o NHS Number seja captado, verificado frente ao serviço demográfico nacional e levado em todo registro e interface relevantes. Onde estiver ausente ou não verificado, tratem isso como um defeito de qualidade de dados a resolver, porque corresponder apenas por nome e data de nascimento produz tanto correspondências perigosamente erradas quanto vínculos perdidos.

4. Trate a qualidade de dados como uma entrega de primeira ordem. A interoperabilidade exporta os seus problemas de qualidade de dados para todos a jusante. Perfilem seus dados, meçam a completude e a consistência da codificação e implantem uma curadoria para que os erros sejam encontrados e corrigidos na origem. A deriva de codificação, o texto livre onde se precisa de dados estruturados e as unidades inconsistentes corromperão em silêncio toda análise e visão clínica a jusante; financiem, portanto, esse trabalho explicitamente, em vez de supor que ele acontece sozinho.

5. Prefira arquiteturas orientadas a API e fracamente acopladas a integrações rígidas. Projetem de modo que as capacidades sejam expostas por APIs bem documentadas e versionadas, que outros possam consumir sem negociação sob medida. No início isso é mais lento do que uma ligação direta com o banco de dados, mas é o que permite substituir um componente sem reconstruir tudo em torno dele. Também se alinha à forma como os serviços nacionais e os fornecedores modernos hoje esperam se integrar e apoia as abordagens de entrega do Tópico 3.5 — Ciclos de vida de entrega.

6. Use perfis publicados e testes de conformidade, e não interpretações locais. Os padrões são flexíveis, e duas equipes podem implementar "o mesmo" recurso FHIR de modo incompatível. Adotem guias nacionais de implementação e perfis IHE que fixem os detalhes e exijam que os fornecedores demonstrem conformidade frente a eles antes da entrada em produção. O teste de conformidade transforma "damos suporte a FHIR" — uma alegação que por si só significa muito pouco — num fato verificável e contratual.

7. Escreva exigências de interoperabilidade e de padrões abertos nas aquisições e nos contratos. O momento mais barato de evitar a dependência é antes de assinar. Exijam APIs abertas e documentadas, o direito de extrair seus próprios dados num formato padrão, adesão a padrões nomeados e nenhuma cobrança por integrações padrão. Trabalhem com seus colegas comerciais (ver Tópico 6.3 — Aquisições e contratações) para que isso se torne critério obrigatório de avaliação, e não aspirações negociadas depois.

8. Governe a interoperabilidade com a segurança clínica e a governança da informação na sala. Todo novo fluxo de dados muda o risco clínico e o tratamento de informações confidenciais. Tragam os responsáveis pela segurança clínica e pela governança da informação para as decisões de projeto desde o início, e não como aprovação final, para que os prontuários compartilhados sejam, ao mesmo tempo, seguros e lícitos. Isso se liga diretamente ao Tópico 1.6 — Segurança clínica e gestão de riscos e ao Tópico 1.7 — Governança da informação, proteção de dados e cibersegurança.

Perguntas para discutir com a sua equipe#

1. Onde, nas nossas vias de cuidado, dados ausentes ou mal compreendidos criam hoje o maior risco clínico? O investimento em interoperabilidade deve seguir o dano e o valor, e não a moda arquitetural. Mapeiem as jornadas que seus pacientes mais complexos de fato percorrem e encontrem as passagens em que a informação se perde, atrasa ou chega sem significado confiável. Perguntem aos clínicos onde rotineiramente trabalham às cegas — as transferências, as lacunas fora do horário, a fronteira entre saúde e cuidados sociais. Distingam os lugares onde os dados não fluem de modo algum daqueles onde fluem, mas não são confiáveis, porque exigem correções diferentes. Considerem quais populações são mais afetadas, já que a fragmentação tende a cair com mais força sobre as pessoas de necessidades mais complexas. A resposta diz por onde começar e dá a vocês um caso de segurança clínica que terá mais peso do que qualquer argumento técnico.

2. Quão expostos estamos à dependência de fornecedor, e quanto realmente nos custaria trocar nossos principais sistemas clínicos? Muitas organizações descobrem o verdadeiro preço de um sistema fechado apenas quando tentam deixá-lo. Percorram, de forma concreta, o que seria preciso para extrair seus dados num formato utilizável e padrão e passar a outro fornecedor. Examinem seus contratos quanto a quem é dono dos dados, que interfaces padrão existem e se vocês são cobrados por integrações que deveriam ser rotineiras. Identifiquem as interfaces e formatos de dados proprietários que teriam de ser desfeitos. Pesem isso frente à abertura das alternativas e às plataformas nacionais que vocês poderiam reutilizar. Não se trata de trocar de fornecedor a toda hora; trata-se de entender sua alavancagem e reduzir o risco de que o roteiro de um único fornecedor vire sua única opção.

3. Os nossos dados são bons o bastante para serem compartilhados com segurança, e como saberíamos? Compartilhar dados ruins não apenas o constrange — propaga erros para as decisões de outros clínicos. Perguntem se vocês de fato medem a completude, a exatidão, a oportunidade e a consistência de codificação dos dados que pretendem expor. Discutam quem é dono da qualidade de dados na sua organização e se tem tempo e mandato para corrigir os problemas na origem. Considerem que proporção dos registros carrega um NHS Number verificado e quanta informação clinicamente importante ainda está em texto livre, e não em campos codificados. Pensem em como detectariam um erro sistemático de codificação antes de ele chegar a um prontuário de cuidados compartilhado. Se não conseguem responder a essas perguntas com evidências, tratem isso como um achado em si e financiem o trabalho de qualidade de dados antes de alargar o cano.

4. Quando um fornecedor diz "damos suporte a FHIR", como de fato verificaríamos isso antes da entrada em produção? Um rótulo de padrão é uma alegação de marketing até ser testado frente a um guia de implementação específico. Discutam se a sua organização tem alguma capacidade própria de teste de conformidade ou se simplesmente toma os fornecedores pela palavra. Dois sistemas podem ser, cada um, "compatíveis com FHIR" e ainda assim incapazes de trocar uma mensagem utilizável, porque o padrão é deliberadamente flexível e o significado vive nos perfis e conjuntos de valores que o fixam. Perguntem que guias nacionais de implementação e perfis IHE se aplicam à interface em questão e quem do seu lado é competente para lê-los. Considerem se a conformidade está escrita no contrato como condição de conexão ou é descoberta dolorosamente durante a integração. Uma resposta honesta nomeia o perfil específico frente ao qual testariam, a pessoa ou função que executaria o teste e o ponto do cronograma em que um fornecedor reprovado é barrado em vez de deixado passar.

5. Quem é dono dos padrões, da terminologia e da conformidade na nossa organização, e tem mandato para dizer não? A interoperabilidade decai sem curadoria: os conjuntos de valores derivam, os guias locais divergem e cada novo projeto inventa em silêncio a sua interpretação. Perguntem se existe uma função nomeada responsável por padrões, subconjuntos de SNOMED CT e dm+d e conformidade ou se esse conhecimento mora na cabeça de poucas pessoas. Considerem a tensão entre a consistência central e a velocidade de entrega local — as equipes sob pressão construirão a coisa mais rápida, a menos que uma função de padrões tenha autoridade real para exigir a reutilização. Discutam como a manutenção da terminologia é financiada, dado que é pouco glamorosa, contínua e beneficia a todos, e não a um projeto isolado. Olhem como vocês mantêm as implementações alinhadas à medida que FHIR, SNOMED CT e os guias nacionais evoluem, em vez de congelar na versão que adotaram primeiro. Uma resposta honesta identifica o responsável, seu financiamento e um exemplo recente em que ele impôs um padrão ou falhou em fazê-lo.

6. As pessoas cujos prontuários estamos unindo estão informadas e à vontade com o modo como seus dados fluem? A interoperabilidade não é apenas uma questão técnica e clínica, mas de confiança pública e de base legal. As pessoas supõem, com razão, que o NHS já compartilha suas informações de forma sensata e ficam consternadas tanto quando não o faz quanto quando o faz de modos que não esperavam. Discutam se os pacientes entendem quais organizações podem ver seu prontuário compartilhado, como a Recusa Nacional de Uso de Dados (National Data Opt-Out) ou o modelo local de consentimento é respeitado ao longo do fluxo e como o acesso é registrado e auditável. Considerem a dimensão da equidade: as pessoas cujos dados são mais fragmentados — as de necessidades complexas — são também as menos capazes de navegar por recusas e avisos de informação. Tragam a governança da informação e, quando relevante, pacientes ou seus representantes para o projeto, em vez de tratar o consentimento como uma caixa marcada no final. Uma resposta honesta consegue descrever a base legal de cada fluxo, como uma pessoa descobriria quem viu seu prontuário e como suas escolhas são respeitadas de ponta a ponta.

Na prática: um exemplo de saúde e cuidados#

Um sistema de cuidados integrados no norte da Inglaterra se propõe a dar aos clínicos uma visão única dos medicamentos compartilhados entre clínica geral, hospital e farmácia comunitária, depois que uma revisão de incidente grave constatou que um paciente havia recebido a prescrição de dois medicamentos que interagem, por equipes que não enxergavam os registros umas das outras.

A tentação é comprar um "painel de medicamentos" de um fornecedor e ligá-lo diretamente ao banco de dados de cada sistema. O líder de interoperabilidade resiste. Em vez disso, o programa adota uma abordagem de construir sobre padrões abertos. Cada sistema de origem expõe os dados de medicação como recursos HL7 FHIR; cada medicamento é codificado com o dm+d, de modo que "o mesmo medicamento" signifique o mesmo em toda parte; e cada registro é chaveado por um NHS Number verificado, para que os medicamentos certos se liguem à pessoa certa. Os dados da clínica geral são obtidos pelo GP Connect, e não por uma alimentação sob medida, reutilizando uma capacidade nacional em vez de inventar uma local.

A perfilagem inicial dos dados se paga de imediato. O sistema de uma clínica vinha registrando certos medicamentos em texto livre, e não como entradas codificadas do dm+d, o que os tornaria invisíveis a qualquer verificação automática de interações. Isso é corrigido na origem antes da entrada em produção. A equipe também encontra um conjunto de registros com NHS Numbers não verificados e os encaminha ao serviço demográfico nacional para correspondência.

O responsável pela segurança clínica e o líder de governança da informação fazem parte do grupo de projeto o tempo todo. Juntos, definem exatamente que dados são compartilhados, com quem, sob que base legal e como o acesso de um clínico é registrado — as preocupações do Tópico 1.7 — Governança da informação, proteção de dados e cibersegurança. Os fornecedores precisam passar por teste de conformidade frente ao guia nacional de implementação FHIR antes de se conectar. Doze meses depois, a visão integrada de medicamentos está no ar, uma interação que antes teria passado despercebida já foi pega e — porque tudo foi construído sobre interfaces abertas — um segundo caso de uso, a informação compartilhada de alergias, reutiliza a maior parte da mesma infraestrutura por uma fração do custo original.

Perspectivas setoriais#

Startup#

Uma startup de saúde digital vive ou morre pela facilidade com que se encaixa nos sistemas existentes; trate, portanto, a interoperabilidade como funcionalidade central, e não como tarefa de conformidade. Construir APIs FHIR e usar SNOMED CT e dm+d desde o início a torna muito mais fácil de comprar e integrar e sinaliza maturidade a compradores cautelosos do NHS. Resista ao impulso de inventar o seu próprio modelo de dados quando existe um padrão; a sua diferenciação deve ser o seu produto, e não um formato proprietário que vira passivo. Acertar cedo o tratamento do NHS Number e a governança da informação é o que lhe permite passar do piloto à aquisição. Projete de modo que um cliente possa, em princípio, extrair seus dados e ir embora — paradoxalmente, essa abertura é o que conquista a confiança para mantê-lo.

Pequena empresa#

Um pequeno prestador estabelecido — um consultório de clínica geral, uma farmácia comunitária, uma casa de repouso ou uma clínica de unidade única — carrega os mesmos deveres de compartilhar dados com segurança que o maior hospital, mas com uma fração da capacidade técnica. Aqui a interoperabilidade é sobretudo uma disciplina de aquisição e de configuração, e não de engenharia: escolha sistemas que já falam FHIR, conecte-se a serviços nacionais como o GP Connect e a Spine e codifique com SNOMED CT e dm+d de fábrica, para herdar padrões em vez de construí-los. Faça da captação verificada do NHS Number parte da prática cotidiana, porque, sem equipe de integração para conciliar as discrepâncias depois, acertar o identificador no momento do cadastro é a sua salvaguarda mais barata. Apoie-se nos programas de prontuários de cuidados compartilhados e na infraestrutura compartilhada do seu sistema de cuidados integrados, em vez de encomendar ligações sob medida que não consegue manter. Ao assinar ou renovar um contrato de sistema, insista em termos claros em direitos de extração de dados e em interfaces abertas, porque uma organização pequena sente a dependência de fornecedor da forma mais aguda e tem a menor alavancagem para escapar depois do fato.

Grande organização#

Um grande prestador ou fornecedor normalmente carrega décadas de legado: interfaces HL7 v2, vários sistemas de prontuário eletrônico e motores de integração mantendo tudo junto. A estratégia realista não é arrancar tudo, mas pôr uma camada orientada a API e baseada em padrões na frente do parque, migrando os fluxos para FHIR de modo incremental e mantendo a v2 onde precisa. Proteja-se com firmeza da dependência em cada renovação e insista em testes de conformidade, para que "em conformidade com os padrões" seja verificado e não afirmado. Estabeleça uma função interna de padrões e conformidade, para que os projetos individuais não inventem, cada um, a sua interpretação. Isso se liga de perto ao modo como você gere as plataformas operacionais centrais do Tópico 5.4 — Planejamento de recursos empresariais (ERP), em que a mesma disciplina de reutilização e de interface aberta se aplica.

Governo#

Os órgãos nacionais e regionais definem as regras do mercado, de modo que suas escolhas sobre padrões se propagam por todas as organizações. A coisa mais valiosa que o governo pode fazer é tornar obrigatórios os padrões abertos, publicar guias claros de implementação e exigências de conformidade e oferecer plataformas nacionais reutilizáveis — a Spine, o GP Connect, os arcabouços de prontuários de cuidados compartilhados, o serviço do NHS Number — para que as organizações locais construam uma vez e reutilizem. A consistência importa mais do que a perfeição: um padrão bom o bastante, firmemente imposto, vence um teoricamente superior que todos implementam de modo diferente. O governo também deve financiar o trabalho pouco glamoroso de manutenção da terminologia e de melhoria da qualidade de dados, porque são bens públicos que nenhuma organização isolada financiará sozinha. Esse papel de zelo se liga ao Tópico 9.1 — Trabalho com governos locais e nacionais e a como os parceiros colaboram no Tópico 9.0 — Colaboração com organizações parceiras.

Modos de falha comuns#

• Confundir conexão técnica com compreensão semântica. Declarar vitória quando uma mensagem flui, sem confirmar que os dois lados interpretam seus códigos, unidades e negações de forma idêntica. O resultado são dados que parecem integrados, mas são lidos errado em silêncio.
• Compartilhar dados ruins mais depressa. Alargar o cano antes de corrigir a qualidade dos dados, de modo que erros de codificação, texto livre e NHS Numbers ausentes se propagam para as decisões de outros clínicos e para toda análise a jusante.
• "Damos suporte a FHIR" como alegação vazia. Aceitar um rótulo de padrão sem teste de conformidade frente a um guia de implementação específico, de modo que dois sistemas "compatíveis" ainda não conseguem conversar.
• Integrações ponto a ponto sob medida. Construir ligações diretas entre cada par de sistemas, produzindo uma teia frágil que se torna exponencialmente mais difícil e cara de manter à medida que cresce.
• Prender-se por omissão. Assinar contratos com interfaces proprietárias e sem direitos de extração de dados, descobrindo o custo da armadilha só quando se tenta trocar de fornecedor.
• Tratar a governança como barreira final. Trazer a segurança clínica e a governança da informação só para aprovar, de modo que os problemas surgem tarde e de forma cara, ou são deixados passar sob pressão de entrega.
• Padrões sem curadoria. Adotar terminologias e perfis, mas não financiar ninguém para manter os conjuntos de valores, monitorar a conformidade ou manter as implementações alinhadas à medida que os padrões evoluem.

Modelo de maturidade#

Lista de verificação#

• Todo registro e interface relevantes carregam um NHS Number verificado, com um processo para resolver os ausentes ou sem correspondência.
• As novas interfaces usam HL7 FHIR e guias nacionais de implementação nomeados, com a HL7 v2 mantida apenas onde a migração ainda não se justifica.
• O conteúdo clínico é codificado com SNOMED CT e os medicamentos com dm+d, frente a conjuntos de valores acordados.
• A qualidade de dados de tudo o que se pretende compartilhar é perfilada, medida, tem responsável e é melhorada na origem antes de o cano ser alargado.
• Os fornecedores precisam passar por teste de conformidade frente a um perfil específico antes de se conectar — "dá suporte a FHIR" nunca é aceito por si só.
• As plataformas nacionais (Spine, GP Connect, prontuários de cuidados compartilhados) são reutilizadas antes de qualquer integração sob medida ser construída.
• Os contratos tornam obrigatórios APIs abertas e documentadas, direitos de extração de dados em formato padrão e nenhuma cobrança por integrações padrão.
• Os responsáveis pela segurança clínica e pela governança da informação estão no grupo de projeto desde o início, e não apenas na aprovação.
• A arquitetura é orientada a API e fracamente acoplada, de modo que um componente pode ser substituído sem reconstruir tudo em torno dele.
• Uma função nomeada responde por padrões, conformidade e manutenção da terminologia em toda a organização.

Fontes-chave#

• NHS England — padrões de interoperabilidade, a Spine, o GP Connect e os programas de prontuários de cuidados compartilhados.
• HL7 International — o padrão FHIR e as especificações HL7 v2.
• SNOMED International — a terminologia SNOMED CT e orientações de implementação.
• NHS Business Services Authority — o Dictionary of medicines and devices (dm+d).
• Integrating the Healthcare Enterprise (IHE) — perfis de interoperabilidade.
• openEHR International — especificações abertas para estruturar o prontuário.
• Organização Mundial da Saúde — a Classificação Internacional de Doenças (CID-10 e CID-11).

Referências#

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