聯(lián)系我們contact
電話:027-59760188-801
地址:武漢市東湖高新開發(fā)區(qū)光谷大道120號現(xiàn)代森林小鎮(zhèn)A座609室
發(fā)布時間:2024-02-04 瀏覽次數(shù):3675次
從電子表格誕生以來,其應用領(lǐng)域便不斷擴展,以至于如今任何需要用到計算機的職業(yè)和行業(yè)都離不開電子表格。制藥行業(yè)概莫能外,而且成為電子表格的重度使用者。雖然如今隨著各種大型軟件的興起和完善,不斷地蠶食Excel的用武之地,甚至在講述其軟件的優(yōu)勢時,必然時時列舉電子表格的劣勢做對比,給人的印象似乎還在大量使用Excel電子表格就是落后的表現(xiàn),但事實上國內(nèi)制藥企業(yè)在電子表格的使用方面整體上仍然處于十分基礎(chǔ)的水平,遠沒有發(fā)揮出Excel作為生產(chǎn)力工具的作用。相比而言,二十年前,當各種專業(yè)化大型軟件都缺乏或不成熟的時候,電子表格在歐美藥企的數(shù)據(jù)自動化處理以及信息化方面起了十分重要的作用。可以說歐美企業(yè)經(jīng)歷了一段以電子表格為重要手段的信息化時期。這段電子表格的階段并非如我們所認識的是走彎路,因為其廣泛的使用規(guī)范了數(shù)據(jù)和流程,為后來上一些大型軟件打下了堅實的基礎(chǔ)。如今,電子表格仍然作為十分重要的工具活躍在一線。
當然,制藥行業(yè)是受法規(guī)監(jiān)管的行業(yè),電子表格作為計算機化系統(tǒng)的一種,必然也需要符合相關(guān)的法規(guī)要求,本文將從電子表格的歷史,合規(guī)控制,驗證方面逐一進行探討。
世界上第一個稱得上電子表格軟件的是1978 年誕生于美國的VisiCalc。VisiCalc始于一名名叫丹尼爾·布萊克林(Daniel Bricklin)的哈佛商學院學生在其案例研究報告中有電子表格的類似需求。在其麻省理工學院(MIT)的熟人和另外一名創(chuàng)始人弗蘭克斯頓(Bob Frankston)的幫助下,第一個電子數(shù)據(jù)表軟件 VisiCalc 于 1978 年秋天誕生。盡管VisiCalc功能有限,但自1979年已經(jīng)銷售了一百多萬份。1983年,IBM推出了 Lotus 1-2-3 軟件包,并逐漸成為了電子數(shù)據(jù)表標準的領(lǐng)導者。Lotus 1-2-3 添加了完整的制圖、繪圖和數(shù)據(jù)庫功能,增強了電子表格的功能以及易用性。用戶也對軟件在處理復雜計算方面的能力非常滿意。最重要的是,Lotus 1-2-3 引入了命名單元格、單元格范圍和宏的概念,這不僅解決了重復性任務自動化執(zhí)行的問題,而且提供了一種拓展電子表格應用軟件功能的工具。
直到1984年微軟的 Excel在個人辦公軟件市場出現(xiàn),Lotus 1-2-3才開始有衰退的跡象。
微軟的Excel 是第一個使用下拉式菜單和通過鼠標點擊進行操作的圖形界面的電子表格軟件。1995年春末,Excel取代了Lotus 1-2-3成為電子表格軟件市場無可爭議的領(lǐng)導者。微軟一直通過增強 EXCEL 的功能來維護其優(yōu)勢地位,包括整合了 Visual Basic 程序語言的一個子集-Visual Basic for Application(VBA)到 EXCEL 平臺的核心。這一方式允許 EXCEL 中的數(shù)據(jù)被其他微軟應用軟件如 Access 或 Word 共享和處理。
隨著電子表格軟件功能的不斷增強,電子表格逐漸應用到藥物研發(fā),實驗室,生產(chǎn),臨床等各個領(lǐng)域。如今,一個Excel模板就相當于是一個獨立的應用程序,其中包含復雜函數(shù)嵌套,邏輯判斷、甚至包括采用高級語言和表單制作的用戶圖形化界面,用以實現(xiàn)數(shù)據(jù)計算,自動化報告,圖表展示等多種用途,由此也對驗證提出了更高的要求。
1997 年21CFR Part11“電子記錄和電子簽名”法規(guī)的發(fā)布,使得電子表格的驗證復雜性進一步增加。這部法規(guī)要求受控的電子記錄或用戶簽名的電子系統(tǒng)必須進行一些關(guān)鍵技術(shù)控制。電子系統(tǒng)的評估需要通過 4 個關(guān)鍵的要素:數(shù)據(jù)真實性,可靠性、機密性和不可篡改性?;趯@ 4 個關(guān)鍵屬性的要求,F(xiàn)DA 已經(jīng)發(fā)布了一些警告信。
警告信摘錄 |
在質(zhì)量控制實驗室中電子表格管控的計算數(shù)據(jù)的完整性存在控制不充分,例如: ● 沒有審計追蹤功能追溯電子表格計算模板的版本號; ● 訪問電子表格沒有密碼保護。 |
貴公司并沒有按照 21 CFR820.70(i)的要求對一些GMP相關(guān)的計算機應用進行驗證,包括貴公司 Access 數(shù)據(jù)庫和MS Excel 電子表格。 |
沒有適當?shù)尼槍τ糜谥锌睾统善贩治鲇嬎愕碾娮颖砀竦尿炞C程序。 |
電子表格在訪問控制方面存在固有的缺陷,即任何終端用戶都可以對電子表格進行訪問和編輯。不同于數(shù)據(jù)庫,電子表格缺少用戶水平的安全措施,這使得應用程序和支持性數(shù)據(jù)對獲得了電子表格文件的所有用戶都能輕易訪問。針對這個缺陷,一種解決方法是部署局域網(wǎng)或網(wǎng)絡(luò)服務器,將電子表格模板放入網(wǎng)絡(luò)共享路徑,公司就可以通過控制計算機中文件夾的訪問權(quán)限來控制對電子表格的訪問;這種方法同樣提供了關(guān)于用戶標識(ID)和密碼的技術(shù)性控制,這包括用戶 ID 的唯一性、密碼策略、用戶密碼的周期性、歷史密碼的預防使用等等。另一種解決方法是,用戶在Excel工作簿中自定義的訪問電子表格的密碼(包括工作表保護和工作簿保護),同樣可以限制訪問以保護電子表格的設(shè)置避免修改,包括單元格內(nèi)容、公式,宏和 VBA。密碼的維護必須由公司內(nèi)與之無相關(guān)利益的人員,并且密碼的修改應在嚴格的規(guī)程控制之下進行。 上述兩種方法在一定程度上做到了訪問控制,但能訪問模板則代表用戶必然能夠復制該文件。復制出來的文件不受限的傳播和使用又會產(chǎn)生新的問題。
電子表格另外一個關(guān)鍵的固有缺陷是沒有審計追蹤功能。這個缺點使得電子表格上輸入的數(shù)據(jù)無法追蹤和歸屬。其他缺點在 FDA 給各公司的警告信中均有體現(xiàn),包括無法區(qū)分不同人員保存的版本,無法確認打印出的紙質(zhì)文件和電子表格是否對應。根據(jù) FDA 對電子表格開出的警告信來看,缺乏追蹤審計是對電子表格數(shù)據(jù)的完整性產(chǎn)生質(zhì)疑的最大來源。
現(xiàn)有的解決方案是將必要的追蹤審計和數(shù)據(jù)完整不符合性降至最低。當前電子表格應用軟件提供的變更追蹤的機制,但并不十分安全,例如通過工作簿共享后,對所有人的編輯均可追蹤單元格的修改歷史,但工作簿共享能被其他用戶關(guān)閉(如禁用),關(guān)閉后修訂記錄會全部丟失。另外,用戶能在Excel應用程序中隨意修改自己的用戶名,從而導致修訂記錄的信息不真實。最后,由于修訂記錄與Excel文件本身放在一起,如果Excel文件丟失,修訂記錄同時也會丟失。為了彌補Excel本身的合規(guī)缺陷,有人使用 VBA來實現(xiàn)入門級的數(shù)據(jù)審計追蹤和訪問控制功能,即在打開Excel時要求用戶輸入用戶名和密碼,從而識別用戶身份。用戶登錄后,在單元格中的操作被捕獲后存儲到Excel隱藏的工作表中或遠端的數(shù)據(jù)庫中。這些審計記錄推薦存儲到遠端的數(shù)據(jù)庫中,從而避免審計追蹤記錄同文件一同丟失。
有些公司也嘗試把電子表格放到電子文檔管理系統(tǒng)中(EDMS),由EDMS負責管理電子表格以及其中所含數(shù)據(jù)的完整性。但這種管控方式很難追蹤到詳細的修訂記錄,一般只能做版本上的管理。當前市面上比較成熟的是直接針對Excel 開發(fā)的合規(guī)化插件,通過Add-in的方式進行了合規(guī)性的功能開發(fā)。eInfotree就是這種基于Excel的合規(guī)插件,為電子表格提供了訪問控制,審計追蹤,電子簽名等合規(guī)性功能。但囿于Excel桌面化軟件的特點,雖然合規(guī)性得到了質(zhì)的提升,但MS Office文件可編輯則必然可被刪除的特性,以及Excel文件出現(xiàn)崩潰后無法正常打開的情況時有發(fā)生,這兩點仍然無法改變,甚至造成極具嚴重的后果。
為了保證電子表格打印輸出是真實的,應在需要打印輸出的電子表格頁眉或頁腳打印出根據(jù)數(shù)據(jù)所生成的哈希函數(shù)。生成的哈希函數(shù)應基于表格中儲存的數(shù)據(jù)、電子表格保存的時間戳的組合。通過執(zhí)行 VBA 代碼將生成的哈希值插入打印件中。代碼構(gòu)建時應防止用戶繞過程序的執(zhí)行而無法產(chǎn)生哈希值,最后還要配合復核機制對打印件上的哈希函數(shù)進行確認。
盡管電子表格因為缺少技術(shù)控制手段導致其易于篡改,還是有很多解決方案可以使公司能夠滿足 21CFR Part 11要求。當這些解決方案能夠按照合適的規(guī)程和制度得到恰當?shù)膶嵤?,盡管不是非常完美,但可以在一定程度上保證數(shù)據(jù)的真實性,可靠性、機密性和不可篡改性。
用戶需求規(guī)范是定義系統(tǒng)功能需求的一份文件。此文件一般由用戶起草,闡述用戶對電子表格具體的功能要求,以提供系統(tǒng)測試和確認的基礎(chǔ)。電子表格的用戶需求一般包括:
? 數(shù)據(jù)輸入的類型(文本或數(shù)字)
? 數(shù)據(jù)輸入的范圍
? 計算
? 函數(shù)
? 報告
? 圖表
? 安全,包括工作表、安全和數(shù)據(jù)
? 系統(tǒng)性能、質(zhì)量、錯誤處理、啟動、關(guān)閉等等
輸入數(shù)據(jù)的類型和數(shù)據(jù)的有效范圍必須明確規(guī)定,這一點可以看作是滿足 21 CFR Part11 所要求的特定的控制,比如序列確認或裝置核查。下面舉幾例說明:
? 輸入的 pH 值在 1 到 14 之間
? 活性成分濃度(純度)在 0.0%到 100%之間
? 輸入的類型(文本 VS 數(shù)字)
? 數(shù)值是否真實或完整,只有正數(shù),沒有零等等
? 文本內(nèi)容包括日期,符合“MM/DD/YYYY”格式標準或者被限制到特定的字符數(shù)。
由電子表格自動進行的計算必須根據(jù)所使用的表達式,使用公式形式記錄,而不是Excel中的公式表達形式。如果輸入變量的界限已經(jīng)制定,則需要在用戶需求中詳細說明,因為界限將會幫助定義輸入數(shù)據(jù)的有效范圍。下面是一個數(shù)學表達式計算的例子:
其中,H 為正態(tài)曲線的高度(縱坐標),μ 為平均值,σ 為標準偏差,π 為常數(shù) 3.14159,e 為自然對數(shù)的底數(shù)等于 2.718282,x 可以在(-∞,+∞)中取任何數(shù)值。
現(xiàn)代化的電子表格應用軟件同樣可以使用內(nèi)置函數(shù)進行預定義的計算或操作。比如微軟的 EXCEL,一些廣泛使用的函數(shù)包括:
? sum -求和函數(shù)
? average-求算數(shù)平均值函數(shù)
? stdev-計算標準偏差函數(shù)
? count-計算單元格數(shù)函數(shù)
? if-條件判斷函數(shù)
? lookup-查詢函數(shù)
? round-四舍五入函數(shù)
? int.-向下取整函數(shù)
FDA 的軟件驗證原則指南規(guī)定:預設(shè)電子表格應用軟件的內(nèi)建函數(shù)能夠按預期的工作是不合適的。用戶需求必須詳細說明使用何種內(nèi)建函數(shù)以及在什么情況下使用。如果電子表格應用程序的提供者無法提供充足的文件以清晰的定義數(shù)學表達式和內(nèi)建函數(shù)的對應關(guān)系,用戶則需要詳細的說明內(nèi)建函數(shù)在數(shù)學上的形式,這是用戶理解函數(shù)是如何工作的基礎(chǔ),還可以用此檢查電子表格中的表達式是否與數(shù)學形式上的表達式對等。對于復雜的函數(shù),包括分支或返回各種結(jié)果或計算值,當它用于判斷時(ture 和 false 結(jié)果)用戶需求必須說明函數(shù)所有可能的結(jié)果。如果函數(shù)使用查詢值,查詢參考值、查詢向量和結(jié)果向量(統(tǒng)稱為數(shù)組值),標準的查詢結(jié)果應在用戶需求標準中說明。如果在數(shù)值中使用外推法,則方法應同樣清楚地詳細說明。
電子表格可能需要根據(jù)輸入的數(shù)據(jù)或自動計算出的數(shù)據(jù)以生成特定的報告和圖表。這些報告或圖表應在用戶需求中明確,至少包括需匯總的數(shù)據(jù)范圍、匯總計算的種類,報告或圖表的樣式 。
因為電子表格本身并不安全,所以用戶需求表中應說明計算、函數(shù)、報告、圖表或程序代碼(宏或 VBA)如何保護以防止修改。安全措施依賴物理和邏輯組合措施,一般分為四個層次以滿足 21CFR Part11 或相關(guān)法規(guī)的要求。這四層措施包括工廠、房間、用戶和功能。在工廠層次,進入公司現(xiàn)場必須只限于公司員工,參觀者必須有陪同或限制在一般的訪問區(qū)域。在房間層次,進入存儲主要電子表格的數(shù)據(jù)服務器的物理位置只限于指定的員工并且只能是特定的房間或區(qū)域。在工廠層面和房間層面,安全措施一般是通過鎖和鑰匙、保安和登記柜臺、ID 卡和電子門禁卡組合措施來實現(xiàn)的。在用戶水平,安全包括指定可以訪問電子表格,這包括使用或修改的特定用戶組。此安全層次涉及訪問控制列表和網(wǎng)絡(luò)安全管理的使用。功能級別包括應用程序中特定的安全功能,包括基于用戶角色而制定訪問不同級別的應用程序菜單。功能層次同樣可以通過自定義的格式、界面和 VBA 實現(xiàn)。
用戶需求標準由終端用戶負責起草,注意用戶需求中應盡量符合下面的要求:
● 獨特性
● 簡明性
● 明確性
● 完整性
● 可驗證性
● 一致性
● 易理解性
● 可追溯性
在開始電子表格的設(shè)計與開發(fā)之前,用戶需求必須盡可能的完整,因為這份文件是電子表格驗證的基礎(chǔ),該文件應受控并且須經(jīng)過相應人員的審核和批準,其中應包括終端用戶的代表。批準后,用戶需求規(guī)范須在變更控制管理程序下進行維護,以防止任何對項目和系統(tǒng)開發(fā)范圍未經(jīng)授權(quán)的更改。這種策略也能避免因為分歧和不斷地變更干擾系統(tǒng)開發(fā)人員的工作。
當有需求規(guī)范后,用戶下步可以要求開發(fā)者開發(fā)系統(tǒng)原型。一旦最終方案被用戶接受,開發(fā)者必須提交設(shè)計規(guī)范以說明如何滿足用戶需求規(guī)范中的要求。設(shè)計規(guī)范至少必須包括系統(tǒng)的描述、表格結(jié)構(gòu),公式設(shè)計、需求追蹤矩陣和具體的技術(shù)基礎(chǔ)環(huán)境(如客戶端和服務器、操作系統(tǒng)、電子表格版本、應用軟件版本等)。
判斷設(shè)計是否滿足需求,可以使用需求追蹤矩陣(見表 1)。一般而言,需求可以通過設(shè)計規(guī)范中一條或多條設(shè)計要素實現(xiàn)。
表 1: 設(shè)計標準中的需求可追蹤性矩陣 | |
用戶需求規(guī)范要素 | 設(shè)計規(guī)范要素 |
REQ #1–3.1 | 13.2.1, 13.3, 15.1–15.3 |
REQ #2–3.2 | 12.1–12.7 |
REQ #3–3.3 | 13.2.1, 14.1–14.3 |
與用戶需求規(guī)范相同,設(shè)計規(guī)范也必須受控。
電子表格應用程序的驗證
采用GAMP5指導原則中的軟件分類,電子表格根據(jù)復雜度可分為1,3,4,5類,不同分類對驗證交付物的要求亦有所不同。例如,對于4類,5類,根據(jù)GAMP5的要求,需要交付驗證計劃,功能規(guī)范,風險評估,設(shè)計配置規(guī)范,源代碼審核,設(shè)計確認,安裝確認,運行確認,需求追溯矩陣,驗證總結(jié)報告等。
下表匯總了 Excel模板依據(jù)GAMP5的分類方法。
一般來講,電子表格符合兩個GAMP類別。首先,電子表格應用本身被視為標準軟件包(OTS),因此屬于第3類。運行電子表格應用的操作系統(tǒng)(如Windows)屬于第1類。如果使用宏或VBA,則電子表格應用的自定義代碼部分屬于第5類。
軟件驗證相關(guān)指導原則的趨勢是根據(jù)風險的大小逐漸降低安裝、運行以及性能確認的工作量和復雜度。實際如何進行電子表格驗證取決于簽批的驗證方案,驗證方案需要包含測試描述,測試記錄和接受標準。驗證過程中,需要保留所有測試用例、輸入數(shù)據(jù)和測試結(jié)果以及其他文件化的測試證據(jù)。在用戶需求規(guī)范中定義的功能性需求均需要有測試用例進行測試。測試用例中需要包括系統(tǒng)硬件和軟件配置的確認。另外,測試用例撰寫和設(shè)計時,需要考慮針對關(guān)鍵的參數(shù)進行運行和性能測試或挑戰(zhàn)測試。測試用例的執(zhí)行結(jié)果應如實記錄,并給出該測試用例是否通過的最終結(jié)論。確認方案中通過需求追蹤矩陣(見表 3)將測試用例和用戶需求以及設(shè)計要素進行追溯,防止設(shè)計測試用例時,遺漏測試項目。
表 3: 確認方案中的需求追溯性矩陣 | ||
用戶需求編號 | 設(shè)計規(guī)范條目 | 測試編號 |
REQ #1–3.1 | 13.2.1, 13.3, 15.1–15.3 | TC #1, TC #2, TC #3 |
REQ #2–3.2 | 12.1–12.7 | TC #4, TC #5 |
REQ #3–3.3 | 13.2.1, 14.1–14.3 | TC #6, TC #7, TC #8, TC #9 |
電子表格驗證的范圍包括系統(tǒng)的靜態(tài)和動態(tài)屬性。技術(shù)性部分應從靜態(tài)的環(huán)境配置開始。需要記錄電子表格模板所在服務器硬件的配置和使用電子表格的客戶端硬件的配置,記錄的信息包括計算機型號、類型、制造商、序列號以及內(nèi)存、磁盤容量、用戶界面設(shè)施(鼠標、顯示器)、外圍設(shè)備(打印機、光驅(qū))等等。對于軟件配置,需要記錄服務器和客戶端的操作系統(tǒng)以及升級補丁包。對于客戶端,應記錄電子表格軟件的版本以及對應模板的版本,編號等信息。如涉使用第三方解決方案以符合 21 CFR Part11,第三方系統(tǒng)的硬件和軟件配置同樣需要記錄,并作為靜態(tài)確認的一部分。
靜態(tài)確認的下個階段是核實公式、宏和 VBA 無法被終端用戶修改。通過逐列逐行的對單元格中的公式進行檢查以確認符合設(shè)計規(guī)范。當電子表格比較復雜時,在測試數(shù)據(jù)的選擇上要考慮數(shù)量是否足夠,以及是否能與表格的復雜性相匹配。例如需要確認計算所引用的單元格區(qū)域是否正確,可以選擇引用開始、中間和結(jié)束點的單元格執(zhí)行確認,因為在電子表格設(shè)計過程中經(jīng)常應用到的復制操作容易導致出現(xiàn)引用偏差。
當靜態(tài)確認完成后,即可開始動態(tài)的確認,以確認電子表格是否符合預期用途。動態(tài)確認需要進行電子表格模板基本操作的確認,包括應用程序的啟動和關(guān)閉不存在錯誤。如果電子表格儲存在服務器上,則必須進行數(shù)據(jù)的備份和恢復確認。其他方面的操作,如報告打印、模板檢索和保存至網(wǎng)絡(luò)服務器操作,也需要確認。對于網(wǎng)絡(luò)化存儲的電子表格,如果存在多個客戶端,可以根據(jù)實際客戶端總數(shù)評估和選擇需要確認的客戶端的數(shù)量。
最后是運行和性能確認。在這個階段,應選擇預先確定的測試數(shù)據(jù),應用到電子表格中以獲得預期的結(jié)果。若因合規(guī)考量,電子表格集成第三方解決方案的,這個部分也需要進行測試。相同的測試場景,如對含量計算準確度的測試。至少需要有3組測試數(shù)據(jù)用于測試含量計算的準確性,以確保確認結(jié)果可靠,能夠始終如一的符合預期用途。
用于確認的測試數(shù)據(jù)不僅需要測試函數(shù)和計算公式有效范圍內(nèi)的值,還需要測試有效范圍限值(上限或下限)和稍微超過范圍限值(向上或向下)的值。對于條件分支函數(shù),如果函數(shù)分支復雜,其中所有的分支和組合都必須進行確認。對于嵌套函數(shù),應使用手動計算和獨立確認的測試數(shù)據(jù)確認最終公式計算的準確性。如果存在 VBA,那么通過VBA實現(xiàn)的,比如按鈕、下拉選擇列表、選項和文本框等等同樣需要進行功能實現(xiàn)層面的確認。
確認過程中的交付物同樣十分重要。測試過程中的測試證據(jù),如截屏、報告和打印輸出物等均需要作為支持性證據(jù)加以保留。實施確認的人員需要如實填寫確認記錄,并整理和歸納驗證過程中的測試證據(jù),測試證據(jù)需要和特定的測試步驟進行對應,以便于追溯。
確認執(zhí)行完畢后需要撰寫最終的驗證總結(jié)報告。報告中需要包含偏差和變更(若有)的處理方法,最終是否關(guān)閉。需要對電子表格驗證工作是否完成以及該電子表格是否符合預期使用給出明確的結(jié)論。
電子表格被廣泛應用于各個公司的不同部門。對于制藥企業(yè),電子表格的應用需要符合21 CFR Part 11 的要求。對計算機化電子表格應用進行規(guī)范化受控管理是十分必要的。但在實踐中,電子表格設(shè)計并未達到如其他計算機化應用程序所需要的用戶控制和數(shù)據(jù)追蹤的復雜水平,但是可以用補充性的技術(shù)解決方案來實現(xiàn)電子表格對 21 CFR Part 11 的符合性。
為能夠達到21 CFR Part 11的符合性,終端用戶需要很好的理解電子表格的應用場景,分析其局限性以及具體存在的合規(guī)差距。21 CFR Part 11 定義的策略和規(guī)程同樣可以很好回答對電子表格的使用,什么是必須做的以及需要做到何種程度。最后,當評價一個系統(tǒng)對 21 CFR Part 11 和其他相關(guān)法規(guī)的符合性時,檢查員只會關(guān)注系統(tǒng)是否進行了充分的測試和控制,以確保電子表格中數(shù)據(jù)的真實性,可靠性、機密性和不可篡改性。