OpenClinica 使用者手冊/CRFandOIDissues

避免規則 OID 出現問題

定義規則的 XML 檔案引用 OID，即系統為 CRF、事件和專案名稱分配的內部程式碼。如果您的研究設定導致這些 OID 在 CRF 上傳時隨機生成 (https://docs.openclinica.com/3.1/rules/oid-overview)，則會出現問題。如果您的即時伺服器上的 OID 與測試伺服器上的 OID 不同，您將需要為每個伺服器使用不同的規則 XML 檔案。您可以透過遵循確保研究中 OID 可預測的程式和命名約定，簡化研究中規則的建立。

上傳 CRF 時出現的問題

如果覆蓋資料庫中現有的 CRF 版本

不要將新版本 '0.3' 覆蓋 '0.3'，因為覆蓋的專案會生成隨機的 OID。您可以在上傳之前：

更改 CRF 選項卡中新 CRF 的版本號，或者
在上傳之前刪除當前上傳的版本（如果 CRF 被事件引用或已被用於資料錄入，請參閱下面的“在開發和測試期間解決問題”）。

新 CRF 的 OID 應該與當前上傳版本的 OID 相匹配。請注意，在規則中，您不需要指定特定版本的 CRF，您可以省略目標 CRF 結尾的 ' _V3'，例如，對 F_LIRAGLUTIDE_V3 的引用可以更改為 F_LIRAGLUTIDE。

如果重新排序專案

如果新 CRF 版本重新排序了現有專案，則專案可能會被分配隨機的 OID。

為了避免這個問題，理想情況下，您只需刪除資料庫中的當前版本，但有時無法刪除該版本，因為它被事件引用或資料錄入已開始使用它。請參閱下面的“在開發和測試期間解決問題”。

在開發和測試期間解決問題

在開發過程中，有時在將 CRF 上傳到資料庫時會出現問題，例如：

如果專案被重新排序（會導致 OID 出現問題），或者
如果專案發生重大變化，並且 OpenClinica 在上傳過程中顯示警告訊息，例如：

The item: xyz in your spreadsheet already exists in the DB with different response options/text. You cannot code an existing response option with a different text, or code an existing response text with a different option. Please check it and upload your spreadsheet again

在這些情況下，您可以：

刪除資料庫中當前的 CRF 版本（有時這不可行，因為該版本被事件引用或資料錄入已開始使用它）
更改發生重大更改的專案的專案名稱（這樣 OpenClinica 會將這些專案視為新專案）
將新版本的 CRF 上傳到資料庫，刪除所有衝突的專案。將任何事件指向新版本。刪除包含衝突專案的所有舊版本。然後上傳一個包含更新專案的版本。

如果首選的選項是從 CRF 的所有版本中刪除專案，您可以透過以下步驟進行操作：

建立一個沒有專案的版本，並使用臨時版本號上傳，例如 0.3a。此版本可以非常簡化，以允許進行最大數量的更改，例如，一個包含臨時唯一專案名稱的專案
修改引用舊版本的任何事件，以使用臨時版本（例如 0.3a）
刪除 CRF 舊版本的任何資料錄入。當您嘗試刪除舊版本時，OpenClinica 會顯示資料錄入已開始使用該版本 CRF 的 ID。使用此 ID 查詢計劃的事件，其中包含需要刪除的 CRF。使用該 CRF 版本的資料錄入應該在事件中列出，準備刪除。如果 CRF 的至少一個頁面已完成，則“刪除”按鈕將顯示（如果未完成，請使用虛擬資料完成至少一個頁面，以便顯示“刪除”按鈕）。
刪除舊的 CRF 版本（例如 0.1 和 0.2）
上傳替換版本（例如 0.3）
修改任何事件以使用替換版本（例如 0.3）
刪除臨時版本（例如 0.3a）

刪除 CRF 時出現的問題（OpenClinica 3.1 及更高版本）

注意：此問題僅適用於 OpenClinica 3.1.2 及更高版本（3.0.3 不存在此問題）。

在資料庫中沒有規則的情況下，刪除 CRF 應該不會出現任何問題。但是，在刪除被現有規則引用的 CRF 時，請注意這些規則可能會成為孤兒 (https://issuetracker.openclinica.com/view.php?id=16336)。您可能需要為規則分配新的 OID 並重新上傳它們（技術解釋：這是因為在資料庫中，rule_set 表的 item_id 列在引用 item 表時不會強制執行引用完整性）。

以下是一個用於識別受影響規則的 SQL 查詢

select distinct rule.id,rule.oc_oid,rule.rule_expression_id from rule_set,rule_set_rule,rule where 
rule_set_rule.rule_id = rule.id and
rule_set_rule.rule_set_id = rule_set.id and
not exists (select 1 from item where item.item_id=rule_set.item_id) order by rule.id;

命名約定以避免問題

伺服器託管多個試驗的 CRF 約定

為伺服器上的每個研究定義一個簡短的（2 個字元）、唯一的試驗程式碼，例如 'AA'。
CRF 名稱的前 2 個字元應該是簡短的試驗程式碼，因為來自多個試驗的 CRF 在檢視 CRF 時會分組在一起（這也有助於避免與來自其他試驗的 CRF 名稱發生重疊）。
規則 OID 的前 2 個字元應該是簡短的試驗程式碼，因為規則 OID 必須在伺服器中唯一（例如，AALXORLTICK 包含字首 'AA'）。這避免了類似事件（例如不良事件）中的規則 OID 重疊。
事件名稱必須在伺服器中唯一（例如，'AA 併發用藥'，否則 OID 會被分配隨機字尾。事件應該被賦予與 CRF 字首匹配的字首。這避免了常見事件（例如不良事件）的重疊。

事件、CRF 和專案的約定

CRF 的前 5 個字元（忽略空格）應該在伺服器中唯一。這些字元用於建立 CRF 中未分組的專案的組名稱，以及專案的複合專案名稱。如果您有一系列名為“訪問 1”、“訪問 2”等的 CRF，您可能希望透過在字串之前放置數字來命名它們，例如“1 訪問”和“2 訪問”等等。
如果試驗要在託管多個試驗的伺服器上進行，則一個名為“Visit 1”的 CRF，其試驗程式碼為“AA”，可能會被命名為“AA 1 Visit”（參見上面的“伺服器託管多個試驗時 CRF 的命名規範”）。
專案名稱的前 20 個字元應唯一。在實際操作中，這意味著專案名稱的前 13 個字元需要唯一（在 3.0.4 及更高版本中為 12 個字元），因為專案名稱的前 7 個字元基於 CRF 名稱，例如，專案名稱以“I_XXXX_”開頭，其中 XXXX 是 CRF 名稱的前四個字元（在 3.0.4 及更高版本中為五個字元）。
匯出到 XML 時，SASFormatName 包含長度截斷為 8 個字元的專案名稱（自 OpenClinica 3.0 起）。因此，如果您計劃將資料匯入 SAS，您可能希望將專案名稱限制為 8 個字元。
在命名用於計算的專案名稱時，您可能需要考慮使用使用者友好的名稱，因為當欄位為空時，專案名稱會顯示給使用者。