以前晚餐時間都會看型男大主廚的阿基師煮菜,幻想著老婆的手藝加以時日一定也可以跟阿基師一樣。而阿基師在節目中常說:「這XXX是在地的、對時(台語)」,主要想是說的是菜要好吃,食材的新鮮度和是不是符合時令季節很重要。如下圖一,我的老家在高雄的路竹,以前只知道路竹有三寶,剛剛 Google 了一下,才發現現在路竹變成有四寶 [1] :番茄、花椰菜、雞蛋和虱目魚。番茄就是要等到冬天採收的才對時,也難怪從小到大只要一聞到雞屎或雞飼料的味道,腦中瞬間浮現老家的場景。
前言
本文是延續下面這篇文章,若還沒看過,麻煩請先行閱讀後再接續本文,謝謝。
每個醫生就像阿基師,而病歷系統上的所有資料就是可以使用食材,手術開刀或吃藥治療就是醫生炒出來的一盤菜。然而,每位病人就像來自五湖四海的客人,同樣一盤菜,對有些人覺得好吃、有些人覺得太鹹、有人覺得沒味道。同樣的,同樣的治療方式,有些人就癒後良好、有些人就癒後不佳,甚至有些病情更為嚴重。
本文想要探討的主題是醫生可以使用的食材,因為有一種特殊的醬汁是很多醫生想要但不太會使用的食材 — 「基因體資料」。這個醬汁就像許多日本燒烤名店也會打著自家「祖傳醬汁」招攬客戶,這類老店的醬汁據說歷經數十年都只是不斷添加,從來沒有整罐換新過,至於為什麼「過期的醬汁」為什麼不會壞掉的問題可以參考 [2]。而基因體資料就像老店的這鍋「祖傳醬汁」,每家醫學中心的所有病人的基因檢測資料就像是新的醬汁不停地加到原本這鍋「祖傳醬汁」中。若想多了解為什麼用「醬汁」來形容「基因體資料」,請參考我這篇三年前試著討論的一個議題:
也就是當基因檢測變成終身保固時,這鍋「祖傳醬汁」才能將它的威力發揮到極限。不過,己經超出本篇想論述的範圍,之後有機會再為大家說明。
所以,我們不是就將基因體資料直接加到 FHIR 所定義的 Genomic 相關Resources,這樣問題不就解決了嗎?接下來為大家仔細說明當前遇到的困境。
目前挑戰
James Mcclay 在 「A Deep Dive into FHIR 」為主題的報告 [3] 中提到:
The FHIR resources represent self contained computable healthcare knowledge artifacts.
所以醫療病歷系統內儲存的資料,重點應該是「可被電腦計算的」(Computable),如某位高血壓患者在吃藥後的血壓是否持續降至正常值,或統計所有高血壓患者的體重平均是不是比高尿酸的患者重。這些數據在傳統的病歷系統中都己實現「可被電腦計算」的能力,然而基因體資料相對複雜與多元,所以如何將基因體資料有效地儲存成「可被電腦計算」的格式是首重目標,也是想撰寫本文的初衷。
今年初, Association for Molecular Pathology (AMP) 的 The Electronic Health Record Interoperability for Clinical Genomics Data Working Group of the Informatics Subdivision 發表在 Journal of Molecular Diagnostics 的「Electronic Health Records and Genomics」論文 [4] 中提出所謂的 Genomics-Ready EHR 的完整流程應該要包含圖三中提到的五大模組:
- Genomics Pipelines:依照臨床需求所提供基因體變異資訊的分析流程,技術平台可以用 Array、Sanger Sequencing 或 Next-Generation Sequencing (NGS),就 NGS資料來源可以是 WGS、WES or Focus Panel等;依據不同資料會有不同的分析流程,如:Somatic SNV/INDEL pipeline、Germline CNV pipeline、NIPT pipeline with micro deletion、Gene Fusion pipeline、BRCA panel、、、等。
- LIS/API Interface:依照臨床需求所提供基因檢測的技術規格,並由 Genomics Pipelines 的結果產生 Genomics-Ready EHR 所需要的數據與檔案(理想上)。
- Genomics-Ready EHR:將Genomics Pipelines 的結果整合進來,供醫生參考。
- Bridge Resources: 提供 Interfaces 來整合 Genomics-Ready EHR 所需的資料,如 Family History、Third-party Annotation Databases 等。
- Data Residing in Other Systems:其它資料來源或提供服務商的糸統,如委外第三方基因檢測公司的系統、公開基因資料庫或自建基因資料庫等。
符合臨床需求的 Genomics-Ready EHR 必須考量以上五大模組,並採取合適的介面來整合其流程。那這跟原本的 EHR 系統有何不同呢?
單就資料面來說,沒什麼不同,只要多採取基因檢測所需相關的 FHIR Resources 即可(注意:這邊也有一個大坑,下一段再跟大家說明)。最大的不同在第一個模組 — Genomics Pipelines。因為原本的 EHR 系統只注重資料的存取,簡單地說就是一台 SQL Server +一個 Web Service 即可。然而,Gneomics Pipelines 通常需要大量的運算資源和讀取大量的參考檔案或資料庫,所以在上述的架構中才特別被獨立出來,也因此發現台灣很多醫療院所因資源有限,所以將這部分完全委外,由第三方基因檢測公司提供。
基於此架構下,論文還有整理出目前大家面臨的挑戰:
在此,我想提出不同的看法供大家參考:
質疑一:缺乏相關基因體資訊的標準?
HL7 標準的開發組織 CEO 在今年初提到Precision Medicine 的主要阻礙是缺少足夠的 Genomic Data Standards [5],但實際上真的是如此嗎?
EMBL-EBI 提供 Ontology Lookup Service (OLS) 服務 [6],收集了 200 多個不同的生醫資料正規表示法的標準,目前有關「Disease Ontology」就有 20 個(如圖五所示)。曾在某一場介紹 MONDO 這個標準的 Webinar 中聽到主講人說到為什麼提出 MONDO 的動機:
因為目前市面上有太多標準,大家不知道那一個才是比較合適的標準可以採用,所以我們在此提出另一個標準 — MONDO給大家。
這時她突然停頓約 5 秒鐘,之後又不好意思地說到:
咦,所以好像市面上又多了一個標準囉!!!
害我當場嘴裡的茶都噴出來了!
再者,實際參與了幾家台灣醫學中心的糸統開發後發現,大家在基因體資訊這邊採用的 Ontology 都不盡相同,都有自己的喜好。當問他們為什麼採用 Ontology A 而不是 Ontology B 時,他們都會提出一些情境說明為什麼他們會這樣選擇。所以,我才會覺得實際上的問題不是缺相關的標準,而是大家採用的都不盡相同的標準。然而,更深層的問題應該是:
Q1: 我們真的有能力提出一個一體適用、符合所有應用場景的 Ontology 嗎?
或者是
Q2: 我們是否要統一規定大家使用的 Ontologies 嗎?
我的看法是:
Ans1: 不可能,或者應該說不需要。
Ans2: 不需要。
質疑二:只要採用 FHIR 標準,就可以解決所有問題?
FHIR 重點是在病歷資料可交換性,所以使用相關的 Resource 來定義資料格式,並運用 API 來統一資料存取的方式。
然而,基因體變異點相關的正規表示法千奇百怪,如同圖五提到的疾病名稱表示法一樣多,例如 BRCA1 上有一個 nonsense Mutation chr17:43045711G>C (GRCh38.p13) 是 Pathongenic [7],而以下的表示法都是在說同一個變異點:
還可以用 dbSNP ID:rs80357336 [8] 來表示。也就是說光有 FHIR 標準,並沒有解決基因檢測上資料「Computable」的需求,還得決定使用那種基因資料的表示法才行。
然而,不同的臨床應用場景會有不同的需求, FHIR 的 Genomic Resource 也不該為了能簡單關連資料而規定只能使用某種 Ontology 而己,所以真正的問題是:
如何有效地將各式各樣的基因資料關連起來?
接下來,我們就來看看 HL7 組織和相關國際基因體組織如何提出他們認為最好的方案吧!
枱面上的解決方案
或者應該說我熟悉的解決方案,以下為大家說明我之前研究過的解決方案還有遇到的問題:
FHIR v4.3.0:R4B — STU
那時, 最新 FHIR 的版本是 v4.3.0, 所以我就以這版為主來研究基因體資料該怎麼存放。
根據其 Genomics Implementer Guidance [9] 的說明提到有兩種方法,首先是 Global Alliance for Genomics and Health (GA4GH) 組織所採用的方法,這將在下節為大家說明;另一種方法是用 MolecularSequence 這個 Resource 來定義基因體資訊 (如圖七所示),包含存放參考基因組的 referenceSeq、SNP/Indel 的variant、 結構型變異的 structureVariant 和儲存原始資料的 repository。
然而,我發現一件非常奇怪的部分,就是在 variant 中可以存放 cigar string 的資訊,若對 cigar string 不熟的可以參考 [10]。
簡單地說,variant 的單位是一個變異點,而 cigar string 的單位是一條 read。一個變異點可能由數百條 reads 所組成,如何在變異點這邊填出合適的 cigar string 呢?
看到這邊,這一版 FHIR 的 MolecularSequence 就被我打入冷宮了。接著,我只好繼續研究另一個 GA4GH 所提出的方案了。
GA4GH Phenopacket v2
GA4GH 是國際基因體資料分享與定訂規範的組織,在基因檢測資料如何有效整合進 FHIR 標準中,在今年初提出了 Phenopacket v2 [11]。如圖八所示,一個 Phenopacket 就是一個病人,而 Top Level 還有 Family 和 Cohort 這兩種 Elements 來統整家族和族群的資訊 [12]。用 Biosample來記錄樣本的資訊,用 Measurement 來記錄檢測的結果,用 Interpreatation 來記錄變異點資訊。重點是在 MetaData 中定義所使用的 ontologies,而不是規定只能使用某一個 ontology。在 ID 的欄位建議使用 CURIE [13]表示法,這樣就可以清楚知道是使用那一種 ontology。同時,設計 OntologyClass 這個 building block來記錄其它欄位的正規化表示。
除了完整性比 FHIR 的 MolecularSequence 高,更令人興奮的是 Phenopacket 在上個月通過成為 ISO 組織的標準了(如圖九所示),這對 GA4GH 組織努力將其制定的 Standards 推向臨床應用打了一劑強心針,對基因檢測的資訊整合到 EMR/EHR 提供了一條捷徑。
然而,在我實作的過程中遇到一個大問題,下面是 Phenopacket 定義的 building blocks 階層圖,就是一個 Phenopacket 可以存放 0 到多個 Interpretations,而每個 Interpretation 可以存放 0 或 1 個 Diagnosis 資訊, 而一個 Diagnosis 可以存放 0 到多個 GenomicInterpretation,而基因變異的資訊就只能放到 GenomicInterpretation 中 [14]。
Phenopacket
。。。|__ Interpretations [0..*]
。。。。。。|__Diagnosis [0..1]
。。。。。。。。。|__Disease [1..1]
。。。。。。。。。|__GenomicInterpretation [0..*]
但面對這樣的設計,問題會出在那呢?
原因是:「變異點資訊只能放在 Diagnosis 中,而每個 Diagnosis一定要填上 Disease 資訊。」
就我來看,這是個非常大的問題,原因有二:
- Phenopacket 要求在存放變異點資訊時,一定要附上一個對應的 Disease;在單基因疾病或針對某種癌症的檢測來說,這樣設計沒問題;但就 WES/WGS/Pan Cancer Panel 等,若強制要加一個 Disease name,這會導致最後只放對治療和用藥有明確關連的變異點資訊,其它有用的資訊及可疑的變異點就無法放了。而且,只能放一個也很奇怪,若覺得重要一定要放,可以設計成 [1 .. *] 的樣式,但在 Phenopacket v2 又只定義成 [1..1],這就講不通了。
- 很多醫療院所的基因檢測都是委外由第三方基因檢測公司執行,在委外的過程中,第三方基因檢測公司根本拿不到 Disease name 的資訊,或者是說應該還不知道患者得了什麼病,所以才要去做基因檢測。也應該只有醫生才比較合適認定病人的 Disease Type,若想透過 Phenopacket 將第三方基因檢測公司直接和 FHIR 介接起來,這個必要欄位根本無法填寫,最後導致很多基因變異點資訊根本放不進 Phenopacket 中。
當發現這個重大設計缺失時,我馬上跟 Phenopacket 組織聯絡,試圖說明這樣設計在臨床場景並不合適,並引導他們往兩個方向修正:
方案一:Disease 樣式改成 [0..1] 或 [0..*] 即可。
方案二:Disease 這個欄位名稱改成 Assay or Phenotype。
但我最後放棄了,原因就請自行閱讀我跟 Phenopacket 的負責人在討論區的內容吧 [15]!(真的無言~~~,至少我努力過了)
雖然 Phenopacket 仍有些不足的地方,但還算可用,所以還是推薦給大家,畢竟它也正式成為 ISO 的標準了。
只是,心中覺得應該還有更好的選擇,所以一直持續關注各組織的動態,終於讓我看到一線曙光,也就是接下來為大家介紹的 FHIR v5 。
FHIR Release 5 Draft Ballot
為什麼會注意到這個版本,主要是 CodeX 組織在今年初成立了 GenomeX 來加速 FHIR and Genomics [16]。如圖十所示,GenomeX 主要針對目前 non-computable genomic information 試著加速轉換成 machine-readable format,也是撰寫本文想傳遞的主要訊息。
撰寫本文時,最新 FHIR Release 5 的版本雖然還在 Draft 階段 [17],但目前看起來,GenomeX 組織成員不只是來自學術界,更多是來自生技界廠商,所以有對的人參與其中是首要之務;再者,前一版 MolecularSequence 的缺失也己改正,照目前的設計會將基因變異資訊由 MolecularSequence 轉移到 Genomics Reporting 來。目前 MolecularSequence 仍存在一些與 Genomics Reporting 的重覆欄位,但相信這版完成後,這些小問題應該可以順利解決,值得大家一起期待或加入一起討論。
放眼未來
老實說,基因體資訊並不複雜、也跟其它的病歷資料沒什麼不同,只是之前大家的作法錯了(根本原因是基因檢測只是一次性服務的商業模式),導致最後在整合資料時才會遇到一堆問題。
所謂「上樑不正、下樑歪」,解決問題的最好方法就是從源頭開始導正,也就是從定序服務商以及基因檢測公司/實驗室就需要採用 FHIR 標準進行資料整合。同時,醫療機構得要求委外的基因檢測公司提供 FHIR compatible 的介面進行 EHR 系統的對接。所有基因檢測廠商應將目標放遠、把餅做大,所謂「團結就是力量」,一個人的基因體資料並沒什麼用,一群人的基因體資料才能發揮效益,更不用說全體人類的基因資料若能共享,相信所有疾病問題都能迎刃而解。當然,可惜的是總會有些業者 [18] 因為商業策略而不提供原始資料或完整的資訊,這時,若醫療機構建構起 Genomics-Ready EHR 系統,應該就會選擇其它可以提供原始資料並支援 FHIR 進行資料整合的廠商。當然,如何整合多家醫療機構的基因體資料就得要有如衛福部這樣高度的單位來啟動囉。
最重要的,醫療機構應該可以主導基因體資料如何整合進 EHR 系統並要求第三方檢測服務廠商配合,應該從原始資料、分析流程、變異點資訊以及最後檢測報告都要盡量提供完整的資訊,例如 VUS 應該也都提供,這樣整合進每家醫療院所的 EHR 之後才能稱為是 Genomics-Ready EHR 系統。
所謂「天時、地利、人和」,相信只要人對、方法對,就沒有解決不了的事。如同美國最大 EHR 廠商 Epic Systems 和著名基因檢測廠商 Myriad Genetics 合作將基因檢測資料整合到 EHR 系統中 [19]。
兩年前曾寫過以下這份建言給衛福部阿中部長,因為這個 LDTs 法案打從一開始就因各方角力而歪掉了,造成很多政策常常都無法符合其初衷。
相信今年在衛福部射出的兩把好的箭(「EMR 走 FHIR 標準」和「EMR可上雲」)應該可以帶動國內相關 ICT 廠商及醫療院所一起動起來,除了將基因體資訊有效地整合進 EMR 系統中,大家可以從資料中創造出更多、更精準的治療方式,吸引更多 AI 公司一起進來創造更多的價值,讓全民健保的每分錢都花在有效的治療上,往基因體優先的精準醫療(Genotype-First Precision Medicine)又大跨一步。
最後,分享 2019 年這篇發表在 World Economic Forum 標題為「Why precision medicine is the future of healthcare」文章 [20] 中提到完整生態系,以人為本體,連結各方的人才、資源,各司其職,缺一不可,才能達成精準醫療的目標。
這條路的確不好走,但又非走不可。大家一起加油吧!共勉之~~~
參考資料
[1] https://lujhu-dist.kcg.gov.tw/cp.aspx?n=5762F41C60B42701
[2] https://vitomag.com/culture/twolh.html
[3] https://confluence.hl7.org/download/attachments/111123970/FHIR%20Deep%20Dive_GPInterop.pdf?version=1&modificationDate=1620771376199&api=v2
[4] https://www.jmdjournal.org/article/S1525-1578(21)00327-5/fulltext
[5] https://www.genomeweb.com/informatics/lack-adequate-genomic-data-standards-presents-major-hurdle-precision-medicine#.YilVuxNBw-T
[6] https://www.ebi.ac.uk/ols/ontologies
[7] https://www.ncbi.nlm.nih.gov/clinvar/variation/55630/?new_evidence=false
[8] https://www.ncbi.nlm.nih.gov/snp/rs80357336
[9] http://hl7.org/fhir/genomics.html
[10] https://genome.sph.umich.edu/wiki/SAM#What_is_a_CIGAR.3F
[11] https://www.ga4gh.org/news/phenopackets-v2-expands-utility-to-provide-a-more-complete-medical-picture/
[12] https://phenopacket-schema.readthedocs.io/en/latest/schema.html#version-2-0
[13] https://standards.iteh.ai/catalog/standards/iso/ad6a117b-0a90-4ef4-a1fa-bfcab8280266/iso-4454-2022
[14] https://phenopacket-schema.readthedocs.io/en/latest/resource.html#rstcurie
[15] https://groups.io/g/phenopackets/topic/may_i_know_how_to_represent/92080453?p=,,,20,0,0,0::recentpostdate/sticky,,,20,2,0,92080453,previd%3D1660730745434217141,nextid%3D1652311668300128681&previd=1660730745434217141&nextid=1652311668300128681
[16] https://confluence.hl7.org/display/COD/CodeX+One-Pagers?preview=/104574127/90363624/CodeX-One-Page-GenomeX.pdf
[17] https://build.fhir.org/genomics.html
[18] https://tw.news.yahoo.com/news/dna%E5%A4%96%E6%B4%A91-%E5%9F%BA%E5%9B%A0%E8%B3%87%E6%96%99%E5%BA%AB%E9%81%AD%E7%88%86%E5%8E%9F%E5%A7%8B%E8%B3%87%E6%96%99%E6%9C%AA%E6%A0%B9%E7%95%99%E5%8F%B0%E7%81%A3-%E9%A6%96%E4%BB%B6%E8%B7%A8%E5%9C%8B%E5%90%88%E4%BD%9C%E6%A1%88%E6%83%B9%E8%AD%B0-220000411.html
[19] https://www.healthcareitnews.com/news/epic-myriad-genetics-collaborate-ehr-integration-genetic-testing
[20] https://europeansting.com/2019/02/15/why-precision-medicine-is-the-future-of-healthcare/