臨床試驗.gov - 美國政府的FDA臨床試驗登記處 - 發布480,000+項研究作為公共資料，每日更新。它是醫療保健領域最寶貴的數據集之一。製藥公司、合同研究組織、健康科技新創公司和學術研究人員都需要這些數據進行程式化處理。
但官方的 ClinicalTrials.gov API v2？它基本上是為人類研究員建立的搜尋引擎的 REST 包裝。沒有結構化的資格篩選。沒有地理位置半徑搜尋。沒有 webhook 訊息提醒。分頁功能在更改分頁參數中途會失效。如果你想要建立超出基本關鍵字搜尋的任何東西，你終究得爬取網站、下載 2GB 的文本文件匯出，或支付企業供應商每月 500 美元以上的費用。
所以我建立了臨床試驗API——一個在ClinicalTrials.gov之上的合適REST層，包含結構化的資格條件、地區搜尋和webhook警報。這就是它實施的過程。
技術堆疊
- 運行時: Python Workers (Pyodide, Redux記憶快照)
- 部署: Wrangler CLI -> 全球330多個邊緣位置
- 後端數據： ClinicalTrials.gov API v2 (公共領域，無需授權)
- 市場& 收費： RapidAPI
- 定價： 免費 / $49/月 (Pro) / $199/月 (Ultra)
- 平均響應： 350-500毫秒暖機，約1秒冷啟動
我所建構的內容
10 個終點點分佈在 4 個功能組別：
| 終點 | 描述 | 層級 |
|---|---|---|
| GET /v1/trials/search | 全文 + 按欄位搜尋，游標分頁 | 免費 |
| GET /v1/trials/{nct_id} | 完整試驗詳情，包含結果、地點、參考資料 | 免費 |
| GET /v1/trials/nearby | 以緯度/經度進行地理半徑搜尋，按距離排序 | 免費 |
| GET /v1/stats | 按階段、狀態、贊助者、研究類型進行統計資料匯總 | 免費 |
| GET /v1/conditions | 醫療狀況自動完成瀏覽器 | 免費 |
| GET /v1/health | 健康檢查，無需授權 | 免費 |
| GET /v1/trials/{nct_id}/eligibility | 結構化資格標準解析 | Pro |
| GET /v1/alerts | 列出活動的 webhook 警報 | Pro |
| POST /v1/alerts | 為新試驗創建 webhook 警報 | Pro |
| 刪除 /v1/alerts/{alert_id} | 刪除 webhook 警報 | 進階 |
艱難的部分
挑戰 1：解析自由文本資格標準
這是最困難的技術問題。ClinicalTrials.gov 將資格標準儲存為自由文本 - 通常是一個單一段落或項目符號列表，完全沒有結構：
"纳入標準：組織學確認的三阴性乳癌。年齡>= 18 歲。ECOG表現狀態0或1。血液學及器官功能良好。未接受過遠程轉移性乳癌的系統治療。排除標準：先前接受過乳癌免疫治療。活躍的自體免疫性疾病需要系統治療。未治療或症狀性腦部轉移。懷孕或哺乳期。"
我需要將這些解析成結構化的、機器可讀的標準物件，以便病患匹配算法實際可以使用：
{
"inclusion_criteria": [
{"category": "Age", "text": "Age >= 18 years", "criterion": "18 years and older"},
{"category": "Condition", "text": "Histologically confirmed triple-negative breast cancer", "criterion": "Triple-negative breast cancer confirmed by histology"},
{"category": "Performance Status", "text": "ECOG performance status 0 or 1", "criterion": "ECOG 0-1"}
],
"exclusion_criteria": [
{"category": "Prior Treatment", "text": "Prior immunotherapy for breast cancer", "criterion": "No prior checkpoint inhibitor therapy"}
]
}
我的方法：一個启发式的NLP流程。首先，使用匹配項目符號、編號列表、換行符和句子邊界的正則表達式模式將原始文本分割成候選標準。接著，使用關鍵字匹配和基於規則的邏輯將每個候選標準分類到8個類別之一（年齡、性別、狀況、實驗室值、既往治療、表現狀態、器官功能、其他）。最後，生成一個標準化的簡潔形式。
準確度約為80-85%。剩下的15-20%歸類為"其他"，並保留原始文本。一個完善的機器學習模型會做得更好，但我想要發布v1版本，並根據回饋進行迭代。結構化解析是專業級服務（$49/每月），因為它是證明付費計劃價值的核心理由。
挑戰2：無預算的地理搜索
ClinicalTrials.gov 列出機構地址（名稱、城市、州、國家），但沒有提供緯度/經度坐標。要建立地理半徑搜尋，我需要對每個機構進行地理編碼。
問題在於：資料庫中有約500,000個獨特的機構地址。商業地理編碼API按每1,000次查詢收費。免費地理編碼API有嚴格的速率限制（約每秒1次請求）。
我的方法：使用預先建立的查詢表。我運行了一個 Python 腳本，花了三天時間，使用帶有請求速率限制的免費地理編碼 API 對所有地址進行地理編碼。結果表格將設施地址映射到緯度/經度，並載入到工作者的模塊級別記憶體中。當您查詢 /v1/trials/nearby 時，工作者：
- 在 ClinicalTrials.gov 上搜索符合您篩選條件的試驗
- 從記憶體表檢索每個設施的坐標
- 計算從您的搜尋中心到目的地的哈維辛距離
- 按距離排序並返回結果
這個表格在記憶體中佔用約20MB，但只包含有活躍試用的設施。附近搜尋的反應時間為400-600毫秒，包括上遊API呼叫和距離計算。不是即時的，但遠比即時地進行地理編碼快得多。
挑戰3：定價 - 真正實用的免費方案與收入
永恆的獨立開發者困境。你該如何讓免費版本對用戶有足夠的吸引力，同時又夠限制以推動轉化？
我的方法：免費提供數據訪問，收費提供增值處理。
免費方案包含10個端點中的7個。您可以搜尋試驗、獲取詳情、進行地區搜尋、瀏覽條件、拉取綜合統計數據——這一切都足以建立一個真實的原型。每天100個請求，3個儲存的 webhook 警報。無需信用卡，無有效期。免費方案應該帶來「啊哈時刻」：『我的天，我剛在單次 API 請求中查詢了480K個試驗。』
Pro tier (每月49美元) 解鎖可節省實際工程時間的功能：結構化資格判斷解析 (而不是您建立正則表達式解析器) 和擴展的 webhook 警報 (25個而不是3個，檢查頻率為每6小時而不是每日)。
Ultra (每月199美元) 供臨床試驗數據對公司而言任務至關重要的情況。更高的請求限制、無限警報、優先支持、專屬 SLA。
轉換假說：免費使用者觸及每日100請求的限制或需要資格判斷，$49/每月比一個小時的開發者時間便宜.
我會做不同的改變
地理位置編碼策略。 花費三天對免費的地理位置編碼API進行速率限制是愚蠢的。我應該花50美元購買商業地理位置編碼服務，然後在兩小時內完成。獨立開發者中「我這樣做可以省錢」的本能很強，但你的時間更值錢。
API設計 - 分離資格端點與內嵌。 我選擇了分離的端點
/v1/trials/{nct_id}/eligibility) 因為解析增加了約 200 毫秒的處理時間，而且免費使用者不應該為他們無法使用的功能支付延遲成本。回顧來說，在試用詳情端點中直接返回解析的資格資訊會更乾淨。開發者期望一次請求，而不是兩次。我可能會在 v2 中合併這些。
數據（至今）
剛推出。實際數據即將推出。
| 指標 | 值 |
|---|---|
| 訂閱者 | 0 (第1天) |
| API呼叫處理量 | 0 (第1天) |
| 收入 (月營收) | $0 (第1天) |
| 服務可用性 | 99.9% (目標) |
| 平均響應時間 | 350-500毫秒 |
| 基礎設施成本 | $0 (CF Workers免費方案) |
我會在30天內更新這裡的真實數據
試試看
https://rapidapi.com/capifactory-capifactory-default/api/clinical-trials-api - 免費方案，無需信用卡。只需30秒即可獲取API金鑰並進行第一次調用。
如果你正在開發一個健康科技產品，需要臨床試驗數據，我很想聽聽哪些終點會讓這個對你有真正的幫助。我發布得很快 - 如果你需要某個目前不存在的东西，告訴我，我很可能在48小時內讓它上線。