トピック4.3 — 相互運用性とデータ標準

医療・ケアにおいて、相互運用性は技術上の小ぎれいさではなく、臨床安全と公平性の要件です。システムが、適切なデータを、適切な形で、曖昧さのない意味で、ケアの現場に共有できないとき、人は害を受け、不公平は増幅されます。

医療・ケアにおいてなぜ重要か#

人のケアが一か所で行われることはまれです。一つのエピソードが、一般診療、救急サービス、救急部門、病棟、地域看護師、薬局、社会的ケアチーム、そして自宅の介護者に及ぶことがあります。それぞれが記録の一部を保持しています。それらの部分を安全かつ迅速に集められなければ、臨床家は情報が欠けたまま判断を下します。見落とされたアレルギー、二重に処方された薬、不必要に繰り返された検査、必要とするチームには見えないセーフガーディングのフラグ。

相互運用性は、切り離されたシステムの集まりを、患者の視点から見て、つながったサービスのように振る舞うものに変えます。統合ケアの下にある配管です。それが機能しているとき、ある組織の臨床家は、別の組織が記録したものを見ることができ、それが自分の思うとおりの意味だと信頼できます。失敗すれば、その失敗は、誰かが害を受けるまで、しばしば静かなままです。

これは公平性の問題でもあります。最も複雑なニーズを持つ人々、つまり虚弱な高齢者、複数の長期疾患を持つ人、サービス間を移動する人こそ、データが最も分断されている人々です。したがって、相互運用性の不備は、最も脆弱な人々を最も傷つけます。そして、それは国民の信頼の問題でもあります。人々は、NHSがすでに自分の情報を適切に共有していると当然に想定しており、それがどれほど頻繁にそうでないかを知って落胆します。

最後に、相互運用性は公金を守ります。データを交換できない独自仕様のシステムは、組織を高額で置き換えにくい契約に縛りつけ、費用のかかるポイントツーポイントの連携を強います。オープン標準に基づいて構築することは、選択肢を開いたままにし、サプライヤーに誠実さを保たせ、同じ問題を解決するために繰り返し支払うことを避ける方法です。

中核概念#

相互運用性とは、異なるシステムが情報を交換し、それを使用できる能力です。二つの層を区別すると役に立ちます。構文的または技術的な相互運用性は、二つのシステムがメッセージを交換し、それぞれがその構造を解析できることを意味します。封筒が届き、開けられるのです。意味的相互運用性は、受信側のシステムが、送信側と同じ方法で内容の意味を理解することを意味します。「ペニシリンアレルギー」のコードが、双方で同一に解釈されるということです。意味的相互運用性のない技術的相互運用性は危険です。データは流れますが、意味は失われたり歪められたりします。

医療データは標準を使って交換されます。Health Level 7（HL7）は、医療で最も使われている標準のファミリーです。パイプとキャレットで区切られたテキストを使う、より古いHL7バージョン2（v2）のメッセージングは、いまも膨大な量の病院のメッセージングを支えており、今後何年もそうでしょう。その現代的な標準であるHL7 Fast Healthcare Interoperability Resources（FHIR）は、臨床情報を、ウェブ形式のアプリケーションプログラミングインターフェース（API）を介して交換される「リソース」としてモデル化し、現代の開発者にとって、はるかに扱いやすくします。

メッセージの標準だけでは十分ではありません。内容のための標準の語彙も必要です。SNOMED CT（Systematized Nomenclature of Medicine — Clinical Terms）は、診断、症状、処置などを記録するために、NHSのケア全体で義務づけられている臨床用語体系です。NHS Dictionary of medicines and devices（dm+d）は、医薬品と医療機器の標準の語彙であり、電子処方を支えています。世界保健機関が維持する国際疾病分類第10版と第11版（ICD-10とICD-11）は、日々の臨床記録ではなく、分類、統計、償還のために使われます。openEHRは、共有され臨床的に統治された「アーキタイプ」を通じて、健康記録そのものを構造化するためのオープンな仕様であり、臨床データモデルを単一のサプライヤーから独立させておくために、一部の組織で使われています。

さらに二つの考え方が基礎となります。NHS番号は、同じ人に関する記録を、組織をまたいで確実に結びつけられる、共通の患者識別子です。共有の識別子がなければ、照合は当て推量になります。そしてIntegrating the Healthcare Enterprise（IHE）は、文書の共有のような具体的な問題を解決するために、既存の標準をどう組み合わせるかを正確に規定する「プロファイル」を公開しており、異なるサプライヤーが同じやり方で実装できるようにします。

これらすべての下には、戦略的な選択があります。公開された再利用可能なAPIを伴うオープン標準に基づいて構築することは、市場の競争を保ち、データを可搬なままにします。独自仕様のインターフェースに頼ると、ベンダーロックインが生じ、サプライヤーの切り替えが、事実上できないほど高額になります。しかしどれも、データ品質なしには価値を生みません。正確で、完全で、適時で、一貫してコード化されたデータは、相互運用性の前提条件であり、後付けではありません。

ベストプラクティス#

1. 意味的な相互運用性と技術的な相互運用性を区別し、両方のために設計する。 二つのシステムの間でメッセージが流れるようになったことを祝い、受け取る臨床家がその意味に安全に頼れないことを見落とすのは簡単です。常に問いましょう。相手側は、これらのコード、単位、否定を、私たちとまったく同じように解釈するか。メッセージ形式だけでなく、共有の用語体系（SNOMED CT、dm+d）とバリューセットに投資してください。正しく送信されたが誤解されたアレルギーは、メッセージがないより危険だからです。

2. オープン標準に基づいて構築し、作り直さずにプラットフォームを再利用する。 広く支持されている原則を採用します。オープン標準に基づいて構築し、自前で構築する前に、既存の国のプラットフォームとサービスを再利用する。NHSでは、これは、HL7 FHIR APIを優先し、NHS番号を識別子として使い、個別のポイントツーポイントのリンクを作るのではなく、Spine、GP Connect、共有ケア記録などの国のサービスに接続することを意味します。再利用はコストを下げ、保守の負担を分散し、データが移動できることを意味します。

3. NHS番号を、あらゆる記録とメッセージで譲れないものにする。 信頼できる記録の紐づけは、信頼できる共通の識別子に依存します。NHS番号が取得され、国の人口統計サービスに照らして検証され、関連するあらゆる記録とインターフェースで運ばれるようにします。欠けている、または未検証の場合は、それを解決すべきデータ品質の欠陥として扱ってください。氏名と生年月日だけでの照合は、危険な取り違えと、見逃された紐づけの両方を生むからです。

4. データ品質を、第一級の成果物として扱う。 相互運用性は、あなたのデータ品質の問題を、下流のすべての人にエクスポートします。データをプロファイリングし、完全性とコーディングの一貫性を測定し、誤りが発生源で見つかり修正されるよう、スチュワードシップを整えます。コーディングのドリフト、構造化データが必要なところの自由記述、一貫しない単位は、あらゆる下流の分析と臨床のビューを静かに損ないます。したがって、ひとりでに起きると想定せず、この作業に明示的に資金を割り当ててください。

5. 密結合の連携よりも、APIファーストで疎結合のアーキテクチャを好む。 機能が、十分に文書化され、バージョン管理されたAPIを通じて公開され、特注の交渉なしに他者が利用できるよう設計します。これは、データベースへの直接リンクより最初は遅いですが、周囲のすべてを作り直さずに一つのコンポーネントを置き換えられるようにするものです。また、国のサービスや現代のサプライヤーがいま連携に期待するやり方とも整合し、トピック3.5 — デリバリーのライフサイクルのデリバリーのアプローチを支えます。

6. ローカルな解釈ではなく、公開されたプロファイルと適合性テストを使う。 標準は柔軟で、二つのチームが「同じ」FHIRリソースを、互換性のない形で実装することがあります。細部を固定する国の実装ガイドとIHEプロファイルを採用し、サプライヤーに、稼働前にそれらへの適合を実証するよう求めます。適合性テストは、それだけではほとんど意味のない主張である「FHIRをサポートしています」を、検証可能で契約上の事実に変えます。

7. 相互運用性とオープン標準の要件を、調達と契約に書き込む。 ロックインを避ける最も安価な時期は、署名する前です。オープンで文書化されたAPI、自分のデータを標準の形式で取り出す権利、名指しされた標準の遵守、標準の連携に対する課金なしを求めます。商務の同僚（トピック6.3 — 調達と商務参照）と協力し、これらを、あとで交渉で消される願望ではなく、必須の評価基準にしてください。

8. 臨床安全と情報ガバナンスを同席させて、相互運用性を統治する。 新しいデータフローはそれぞれ、臨床リスクと、機密情報の取り扱いを変えます。共有記録が安全かつ適法であるよう、臨床安全責任者と情報ガバナンスの責任者を、最終承認としてではなく、最初から設計上の判断に巻き込みます。これは、トピック1.6 — 臨床安全とリスクマネジメント、およびトピック1.7 — 情報ガバナンス、データ保護、サイバーセキュリティに直接つながります。

チームで話し合うための問い#

1. 私たちのケアパスのどこで、欠けている、または誤解されたデータが、現在最大の臨床リスクを生んでいるか。 相互運用性への投資は、アーキテクチャの流行ではなく、害と価値に従うべきです。最も複雑な患者が実際にたどる旅路を描き出し、情報が失われ、遅れ、または信頼できる意味なしに届く引き継ぎを見つけます。臨床家に、日常的に手探りで働いている場所、つまり転院、時間外の空白、医療と社会的ケアの境界を尋ねます。データがまったく流れない場所と、流れても信頼できない場所を区別してください。必要な対処が異なるからです。どの集団が最も影響を受けているかを考えます。分断は、最も複雑なニーズを持つ人々に、最も重くのしかかる傾向があるからです。答えは、どこから始めるかを教えてくれ、どんな技術的議論よりも重みを持つ、臨床安全のケースを与えてくれます。

2. 私たちはベンダーロックインにどれだけさらされており、主要な臨床システムを切り替えるには、実際にいくらかかるか。 多くの組織は、閉じたシステムの本当の代償を、離れようとして初めて知ります。自分のデータを使える標準の形で取り出し、別のサプライヤーに移るには何が必要か、具体的に検討してください。契約を調べ、誰がデータを所有し、どんな標準のインターフェースがあり、日常的であるべき連携に課金されていないかを確認します。ほどかなければならない独自仕様のインターフェースとデータ形式を特定します。これを、代わりに再利用できる代替品と国のプラットフォームの開放性と比較します。これはサプライヤーを頻繁に替えることではありません。自分の交渉力を理解し、一社のロードマップが唯一の選択肢になるリスクを減らすことです。

3. 私たちのデータは安全に共有できるほど良いか。そして、どうやってそれがわかるのか。 質の悪いデータを共有することは、恥ずかしいだけではありません。誤りを、他の臨床家の判断に広げます。公開しようとしているデータの完全性、正確性、適時性、コーディングの一貫性を、実際に測定しているかを問います。組織でデータ品質を誰が所有し、発生源で問題を直す時間と権限があるかを話し合います。検証済みのNHS番号を持つ記録の割合と、重要な臨床情報が、コード化された項目ではなく、自由記述にどれだけ残っているかを考えます。体系的なコーディングの誤りが、共有ケア記録に届く前に、どう検知するかを思い描きます。これらの問いにエビデンスで答えられないなら、それ自体を所見として扱い、パイプを広げる前に、データ品質の作業に資金を割り当ててください。

4. サプライヤーが「FHIRをサポートしています」と言うとき、稼働前に実際にどう検証するか。 標準というラベルは、特定の実装ガイドに対してテストされるまでは、マーケティング上の主張です。組織が、自前の適合性テストの能力を持っているのか、単にサプライヤーの言葉を信じているのかを話し合います。二つのシステムがそれぞれ「FHIR準拠」でも、使えるメッセージを交換できないことがあります。標準が意図的に柔軟で、意味は、それを固定するプロファイルとバリューセットにあるからです。問題のインターフェースにどの国の実装ガイドとIHEプロファイルが適用されるか、こちら側で誰がそれを読む能力があるかを問います。適合性が、接続の条件として契約に書かれているのか、連携中に痛い思いをして発見されるのかを考えます。誠実な答えは、テストする具体的なプロファイル、テストを実行する人または部署、そして不合格のサプライヤーが、通過させられるのではなく追い返される、タイムライン上の時点を挙げます。

5. 組織全体で、標準、用語体系、適合性を誰が所有しているか。そしてその人に「ノー」と言う権限はあるか。 相互運用性は、スチュワードシップがなければ劣化します。バリューセットはドリフトし、ローカルのガイドは乖離し、新しいプロジェクトごとに、静かに独自の解釈が発明されます。標準、SNOMED CTとdm+dのサブセット、適合性に責任を持つ、名前のある部署があるのか、この知識が数人の頭の中にあるのかを問います。中央の一貫性とローカルのデリバリーの速さの間の緊張を考えます。圧力下のチームは、標準の部署が、再利用を求める本物の権限を持たない限り、最も速いものを作るでしょう。用語体系の保守が、地味で継続的で、単一のプロジェクトではなく全員の利益になることを考え、どう資金を割り当てているかを話し合います。FHIR、SNOMED CT、国のガイドが進化するなかで、最初に採用したバージョンで凍結せず、実装の整合をどう保つかを見ます。誠実な答えは、責任を負う所有者、その資金、そしてその人が標準を徹底した、または徹底できなかった最近の例を挙げます。

6. 私たちが記録を結びつけている人々は、自分のデータの流れ方について、説明を受け、納得しているか。 相互運用性は、技術と臨床の問題であるだけでなく、国民の信頼と適法な根拠の問題です。人々は、NHSがすでに自分の情報を適切に共有していると当然に想定しており、そうでないときも、予想外の形で共有されたときも落胆します。患者が、どの組織が自分の共有記録を見られるかを理解しているか、National Data Opt-Outやローカルの同意モデルが、フロー全体でどう尊重されるか、アクセスがどう記録され監査可能かを話し合います。公平性の側面を考えます。データが最も分断されている人々、つまり複雑なニーズを持つ人々は、オプトアウトや情報の通知をたどる力が最も弱い人々でもあります。同意を最後に印をつける欄として扱わず、情報ガバナンスと、関連する場合は患者またはその代表者を設計に巻き込みます。誠実な答えは、各フローの適法な根拠、誰が自分の記録を見たかを本人がどう知れるか、そして本人の選択が端から端までどう尊重されるかを説明できます。

実践例：医療・ケアの事例#

イングランド北部のある統合ケアシステムは、重大インシデントのレビューで、互いの記録を見られないチームによって、患者が、相互作用する二つの薬を処方されていたことがわかったのを受けて、一般診療、病院、地域薬局にまたがる共有の薬について、臨床家に一つのビューを提供しようとします。

誘惑は、あるサプライヤーから「薬のダッシュボード」を買い、各システムのデータベースに直接配線することです。相互運用性のリードは、これに抵抗します。代わりに、プログラムは、オープン標準に基づいて構築するアプローチを採用します。各ソースシステムは薬のデータをHL7 FHIRリソースとして公開し、あらゆる薬はdm+dを使ってコード化され、「同じ薬」がどこでも同じ意味になり、あらゆる記録は検証済みのNHS番号をキーにして、適切な薬が適切な人に結びつくようにします。GPのデータは、特注のフィードではなく、GP Connectを通じて引き出され、地域の能力を発明するのではなく、国の能力を再利用します。

初期のデータプロファイリングは、すぐに真価を発揮します。ある診療所のシステムが、特定の薬を、コード化されたdm+dの項目ではなく、自由記述で記録しており、自動の相互作用チェックには見えなかったであろうことがわかります。これは稼働前に発生源で修正されます。チームはまた、未検証のNHS番号を持つ一群の記録を見つけ、照合のために国の人口統計サービスに回します。

臨床安全責任者と情報ガバナンスの責任者は、設計グループに最初から加わっています。彼らは共同で、どのデータが、誰と、どんな適法な根拠で共有され、臨床家のアクセスがどう記録されるかを正確に定義します。これは、トピック1.7 — 情報ガバナンス、データ保護、サイバーセキュリティの関心事です。サプライヤーは、接続する前に、国のFHIR実装ガイドに対する適合性テストに合格しなければなりません。12か月後、つながった薬のビューは稼働し、以前なら見逃されていたであろう相互作用がすでに捕捉され、すべてがオープンなインターフェースに基づいて構築されたため、二つ目のユースケースである共有のアレルギー情報が、配管のほとんどを、元のコストのほんの一部で再利用しています。

セクター別の視点#

スタートアップ#

デジタルヘルスのスタートアップは、既存のシステムにどれだけ容易につながるかで生き死にが決まるため、相互運用性を、コンプライアンス上の雑務ではなく、中核の機能として扱ってください。最初からFHIR APIを構築し、SNOMED CTとdm+dを使うことで、購入と連携がはるかに容易になり、慎重なNHSの購入者に成熟を示します。標準があるときに、独自のデータモデルを発明したい衝動に抵抗してください。差別化は、負債になる独自形式ではなく、プロダクトであるべきです。NHS番号の取り扱いと情報ガバナンスを早期に正しく行うことが、パイロットから調達へ進めるものです。顧客が、原則として、データを取り出して去れるように設計してください。逆説的ですが、その開放性こそが、彼らをつなぎとめる信頼を勝ち取ります。

小規模事業者#

確立した小規模の提供者、つまり一般診療所、地域薬局、介護施設、単独拠点のクリニックは、最大のトラストと同じ、安全にデータを共有する義務を負いますが、技術力はそのほんの一部です。ここでの相互運用性は、主にエンジニアリングではなく、調達と設定の規律です。すでにFHIRを話せるシステムを選び、GP ConnectやSpineなどの国のサービスに接続し、SNOMED CTとdm+dで、そのままコード化して、標準を構築するのではなく継承します。検証済みのNHS番号の取得を日々の実践の一部にします。あとで不一致を調整する連携チームがない以上、登録時に識別子を正しくすることが、最も安価な防御だからです。維持できない特注のリンクを委託するのではなく、共有ケア記録のプログラムと、統合ケアシステムの共有インフラに頼ってください。システムの契約に署名または更新するときは、データ抽出の権利とオープンなインターフェースを、平易な言葉で主張します。小規模な組織は、ベンダーロックインを最も鋭く感じ、あとから逃れる交渉力が最も乏しいからです。

大企業#

大規模な提供者やサプライヤーは、通常、数十年分のレガシーを抱えています。HL7 v2のインターフェース、複数の電子記録システム、そのすべてを束ねる連携エンジン。現実的な戦略は、すべてを引き剥がすことではなく、APIファーストで標準に基づく層を環境の前面に置き、必要なところではv2を動かし続けながら、フローを段階的にFHIRへ移行することです。あらゆる更新でロックインに強く警戒し、「標準準拠」が主張されるだけでなく検証されるよう、適合性テストを主張します。個々のプロジェクトが、それぞれ独自の解釈を発明しないよう、社内の標準と適合性の部署を設けます。これは、トピック5.4 — エンタープライズ・リソース・プランニング（ERP）で中核の業務プラットフォームをどう管理するかと密接に関係し、同じ再利用とオープンなインターフェースの規律が適用されます。

政府#

国や地域の機関は、市場のルールを定めるため、標準に関する選択は、あらゆる組織に波及します。政府にできる最も価値あることは、オープン標準を義務づけ、明確な実装ガイドと適合性の要件を公表し、再利用可能な国のプラットフォーム、つまりSpine、GP Connect、共有ケア記録のフレームワーク、NHS番号サービスを提供して、地域の組織が一度構築して再利用できるようにすることです。完璧さより一貫性が重要です。厳格に徹底された十分に良い標準は、理論上優れていても、全員がばらばらに実装するものに勝ります。政府はまた、用語体系の保守とデータ品質の改善という地味な作業にも資金を割り当てなければなりません。これらは、単一の組織が単独で賄わない公共財だからです。このスチュワードシップの役割は、トピック9.1 — 地方政府・中央政府との協働、そしてトピック9.0 — パートナー組織との協働でのパートナーの協力のしかたにつながります。

よくある失敗パターン#

• 技術的な接続を、意味的な理解と取り違える。 メッセージが流れたところで勝利を宣言し、双方がそのコード、単位、否定を同一に解釈していることを確認しない。結果は、統合されたように見えるが、静かに誤読されるデータ。
• 質の悪いデータを、より速く共有する。 データ品質を直す前にパイプを広げ、コーディングの誤り、自由記述、欠けたNHS番号が、他の臨床家の判断とあらゆる下流の分析に広がる。
• 空虚な主張としての「FHIRをサポートしています」。 特定の実装ガイドに対する適合性テストなしに標準というラベルを受け入れ、二つの「準拠」システムが、それでも互いに話せない。
• 特注のポイントツーポイントの連携。 システムの各ペアの間に直接のリンクを構築し、脆い網を作り、成長するにつれて、保守が指数関数的に難しく、高価になる。
• 既定でのロックイン。 独自仕様のインターフェースでデータ抽出の権利のない契約に署名し、サプライヤーを変えようとして初めて、罠の代償を知る。
• ガバナンスを最終ゲートとして扱う。 臨床安全と情報ガバナンスを承認のためだけに巻き込むため、問題が遅く高くついて表面化するか、デリバリーの圧力のもとで見逃される。
• スチュワードシップのない標準。 用語体系とプロファイルを採用しながら、バリューセットの保守、適合性の監視、標準の進化に合わせた実装の整合を担う人に、資金を割り当てない。

成熟度モデル#

チェックリスト#

• 関連するあらゆる記録とインターフェースが検証済みのNHS番号を持ち、欠けているか未照合のものを解決するプロセスがある。
• 新しいインターフェースはHL7 FHIRと名指しされた国の実装ガイドを使い、HL7 v2は、移行がまだ正当化されないところにのみ残されている。
• 臨床内容はSNOMED CTで、薬はdm+dで、合意されたバリューセットに対してコード化されている。
• 共有しようとするあらゆるもののデータ品質が、パイプを広げる前に、プロファイリングされ、測定され、所有され、発生源で改善されている。
• サプライヤーは、接続する前に特定のプロファイルに対する適合性テストに合格しなければならず、「FHIRをサポートしています」だけは決して受け入れられない。
• 国のプラットフォーム（Spine、GP Connect、共有ケア記録）が、特注の連携を構築する前に再利用されている。
• 契約が、オープンで文書化されたAPI、標準形式でのデータ抽出の権利、標準の連携への課金なしを義務づけている。
• 臨床安全と情報ガバナンスの責任者が、承認の時点だけでなく、最初から設計グループに入っている。
• アーキテクチャはAPIファーストで疎結合であり、周囲のすべてを作り直さずにコンポーネントを置き換えられる。
• 名前のある部署が、組織全体の標準、適合性、用語体系の保守を所有している。

主要な情報源#

• NHS England — 相互運用性の標準、Spine、GP Connect、共有ケア記録のプログラム。
• HL7 International — FHIR標準とHL7 v2の仕様。
• SNOMED International — SNOMED CT用語体系と実装ガイダンス。
• NHS Business Services Authority — Dictionary of medicines and devices（dm+d）。
• Integrating the Healthcare Enterprise（IHE） — 相互運用性のプロファイル。
• openEHR International — 健康記録を構造化するためのオープンな仕様。
• 世界保健機関 — 国際疾病分類（ICD-10とICD-11）。

参考文献#

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