TW201721573A - 用於管理電子健康護理資訊的系統和方法 - Google Patents

Abstract

本發明涉及用於在高度可縮放和可客製的軟體和硬體架構上管理電子健康護理資訊的系統和方法，所述架構強調可擕式設備以及升級和縮放期間的最少停機時間。本發明還涉及高效地訪問和客製用於以電子形式生成和管理患者資訊的表單的系統和方法。在本發明的一個方面中，本發明的電子健康記錄系統(EHR)也可以被稱作電子醫療記錄系統(EMR)，其可以被部署並且運行在多台伺服器上，其中可以按照非集中方式在所述多台伺服器上分配計算和/或存儲負荷，從而使得總體系統即使在被縮放、升級和/或通過其他方式修改時仍然可以保持運轉和操作。

Description

用於管理電子健康護理資訊的系統和方法

本發明涉及用於管理電子健康護理資訊的系統和方法，特別涉及用於電子健康護理資訊的高度可縮放和可客製的創建和管理的系統和方法。

醫療專業人員保持關於患者的記錄。這樣的記錄在患者拜訪醫療專業人員時(例如在最初住院或登記時)、在住院期間以及在出院時生成。住院或登記過程通常包括由患者或納入人員填寫表單，並且所捕獲的資訊過去是通過手寫或鍵入的。更近以來，醫院已經包括了在電腦螢幕上顯示的表單上輸入這樣的納入資訊。該表單通常預先填寫有對應於一般資訊的類目，比如患者的姓名、出生日期等等，其後是用於輸入此類資訊的空間。如果所述空間不夠用於輸入資訊，通常推薦使用單獨的頁面並且把附加頁面附加到記錄。最後，一些醫院仍然把這樣的記錄保持在紙質表單中。除了收集一般資訊之外，許多醫院還收集可能與該醫院的專長領域有關或者與醫院工作人員所開展的特定最佳業務有關的特定類型的資訊。此類資訊也是利用專門的表單從患者收集的。

當在電腦上生成記錄時，其還可以通過電子方式被保存在伺服器上，並且具有與紙質表單相同的存儲格式。與紙質表單一樣，所創建的資訊越多，需要存儲的記錄也越多。當伺服器超負荷時，必須安裝 更大並且能力更強的伺服器來應對增加的負荷，這類似於把檔轉移到更大的存儲空間或建築物，並且通常涉及用於升級和安裝的停機時間(down time)。停機時間也意味著資訊是不可訪問的。

本發明涉及例如用於在高度可縮放和可客製的軟體和硬體架構上管理具有按需資訊收集的需求的各種行業中的電子資訊(或者電子記錄管理或ERM)的系統和方法，所述行業包括而不限於健康護理、顧客關係管理、人力資源、會計、專案管理、政治/慈善活動管理以及類似的行業，所述架構例如可操作在包括固定式或臺式設備、移動設備、可擕式設備或其組合的設備上，並且操作為在升級和縮放期間具有最少停機時間。本發明還涉及高效地訪問和客製例如用於以電子形式記錄和管理患者資訊的表單的系統和方法。

在一個實施例中，本發明涉及用於在高度可縮放和可客製的軟體和硬體架構上管理健康護理行業中的電子健康護理資訊的系統和方法，所述架構例如可操作在包括固定式或臺式設備、移動設備、可擕式設備或其組合的設備上，並且操作為在升級和縮放期間具有最少停機時間。本發明還涉及高效地訪問和客製例如用於以電子形式記錄和管理患者資訊的表單的系統和方法。

本發明例如利用了分層結構資料(HSD)文檔(比如JSON文檔)的靈活性，以及HSD文檔(比如JSON文檔)可以在前面提到的任何適當設備上被動態處理的獨有方式。例如在健康護理領域中，本發明允許基於例如被編碼在存儲於至少一台電腦伺服器上的分層結構資料(HSD)文檔(其被稱作“系統物件”)中的規範集合來創建完整的電子健康記錄系統。健康護理領域中的用戶可以包括醫師、護士、放射科技 術人員、藥劑師、記帳專業人員、醫院管理人員以及甚至患者本身。其可以通過設備(例如可擕式或移動設備)與電子健康記錄系統進行交互，所述設備從至少一台電腦伺服器取回情境相關的系統物件，並且遵循這裡所定義的特定處理集合來實現用於查詢、查看、與之交互以及編輯例如存儲在至少一台電腦伺服器上的包含健康護理相關資料的HSD文檔(其被稱作“健康記錄文檔”)的使用者介面。這裡所使用的“健康記錄文檔”被寬泛地定義成包括可以由健康護理專業人員使用來為患者提供處理的臨床和非臨床、患者特定和非患者特定資料。為患者提供護理的實例可以包括而不限於手術規程指示單(臨床)、保險記帳資訊(非臨床)、藥劑目錄(非患者特定)以及在醫師與護士之間發送的消息(患者特定)。能夠被即時創建的使用者介面可以支援簡單的操作，比如列出/查看健康記錄文檔(比如過敏症列表和藥物列表)或者多份健康記錄文檔當中的統計量(比如每日急診室住院率)，並且還可以支援更加複雜的多步驟操作，比如允許醫師撰寫處方指示單並且簽名以便由藥劑師配藥以及由護士施藥。基於在系統物件中規定的內容，所述設備(例如移動設備)還可以基於當前登錄到系統中的使用者的類別來限制對於特定使用者介面單元的可見性，從而例如向放射科技術人員呈現將要實施的x射線指示單的清單而不會使其看到記帳資訊，或者使得藥劑師不會看到由患者向其醫師發送的消息。一般來說，由於客製僅僅影響系統物件定義而不影響運行在移動設備或電腦伺服器上的軟體代碼，因此可以在任何時間以最少的系統停機時間轉出(roll out)、更新和維護對於電子健康記錄系統的客製，並且不需要移動設備軟體或電腦伺服器軟體的新的版本。

在本發明的一個方面中，本發明的電子健康記錄系統(EHR)也可以被稱作電子醫療記錄系統(EMR)，其可以被部署並且運行在多 台伺服器上，其中可以按照非集中方式在所述多台伺服器上分配計算和/或存儲負荷，從而使得總體系統即使在被縮放、升級和/或通過其他方式修改時仍然可以保持運轉和操作。

在一些示例性實施例中，本發明的EHR系統可以是軟體系統，其通常可以包括被部署並且運行在伺服器共用集合(pool)中的多台伺服器上的多個基本上相同地配置的工作節點(worker node)。在本發明中，EHR系統可以在伺服器共用集合中的各台伺服器上分配其工作負荷和/或存儲負荷，例如在伺服器共用集合中的可用伺服器上基本上均勻地分配。由於EHR系統可以包括多個基本上相同地配置的工作節點，因此各個單獨的工作節點可以被取下、故障和/或被修改，而不會影響其他工作節點和/或嚴重影響EHR系統的總體可操作性。這可能是符合期望的，因為EHR系統一般可以被用來運行任何健康護理設施的操作，並且在這樣的醫療設置中，訪問患者資訊的需求例如常常是時間敏感的並且對於適當的患者治療是至關重要的。因此，一旦部署之後，EHR系統經歷最少停機時間或者沒有停機時間可以確保平滑的操作而不會有不必要的中斷。通過這種方式，例如伺服器共用集合可以在幾乎任何給定時間添加附加的伺服器和/或取下伺服器以用於替換、升級、修復或其他用途從而修改伺服器共用集合的容量和/或功能，而不會使得EHR系統由於伺服器修改而經歷停機時間，從而最低程度地影響總體系統的可用性。

在一些實施例中，本發明的EHR系統可以被建立在高度自動化的安裝平臺上，其中系統的各個單獨的元件可以被包裝到分開的鏡像中，所述鏡像可以包括特定元件的配置。所述系統可以從鏡像創建並且運行元件的實例，同時把應當是永久性的任何所生成的資料與鏡像分開存儲在永久性存儲中。因此，所述系統可以任意創建和丟棄元件的實例， 而既不會丟失存儲在鏡像中的配置資訊，也不會丟失存儲在永久性存儲中的永久性資料。分開的EHR系統元件可以被取下以用於升級、修復和/或其他修改而不會影響其他組件。

在一個實施例中，本發明的EHR系統可以被建立在自動化安裝平臺上，例如“Docker”。“Docker”通常可以利用Linux Container(Linux容器)，一種嵌入到Linux中的比傳統虛擬化方法更加輕量型的技術。本發明的EHR系統的元件隨後可以被包裝到“Docker”鏡像中。隨後可以在“Docker”內啟動鏡像，以便產生元件的運行實例。在傳統的環境中，例如這些實例可以類似於運行在中介軟體以及在配置方面需要為之投入大量時間和能量的其他元件的堆疊上的已安裝的軟體。與此相對，該實施例中的EHR元件的實例通常可以易於創建，並且例如可以在希望或者必須對EHR系統進行修復、升級和/或修改時丟棄。“Docker”通常還可以允許把針對每一個元件的配置資料(其可以被存儲在“Docker”鏡像中)與永久性資料(其可以被存儲在永久性存儲中)分開。因此可以在任何時間丟棄每一個元件的實例，這是因為例如在任何時間都可以通過基於相同的原始鏡像啟動新的實例來重新創建所述實例的配置，同時由所述實例管理的永久性資料不被存儲在實例本身中而是被存儲在例如後端之類的永久性存儲中，比如網路附屬存儲(NAS)。

在一些實施例中，永久性資料可以利用可縮放後端資料庫系統來存儲，所述資料庫系統通常可以利用非關聯式資料庫結構，但是也可以利用分立文檔為中心的結構，所述結構還可以利用伺服器或存儲共用集合上的可縮放性、文檔複製和/或負荷分配。作為另外的實例，所述資料庫系統還可以利用文檔鎖定系統，其中文檔對所有被允許的用戶都保持可查看，但是每次只有一個用戶可以通過將其檢出資料庫來修改文 檔。這對於例如防止可能引入相矛盾的資訊的文檔的同時修改可能是合乎期望的。這在健康護理領域中是特別合乎期望的，其中相矛盾的資訊可能是生死攸關的。

在一個示例性實施例中，所述可縮放後端資料庫系統可以採用NoSQL資料庫，例如“MongoDB”。

在本發明的另一個方面中，EHR系統可以被設計成幾乎完全從可擕式或移動設備進行主要的訪問、保持和利用，其中只有特定功能需要直接訪問伺服器和/或固定式電腦。這不同於一般大多數的EHR系統，後者被設計成用於固定式電腦，其中任何移動訪問或功能都是後來的考慮。這總體反映了用以保持健康記錄的更加傳統或者過時的方式，其更加類似於沒有大量利用允許用以保持資訊的不同方式的任何技術進步的紙張和檔案室系統。

一般來說，在醫療領域中可當責性(accountability)和可稽核性(auditability)是重要的概念。由於作出明智的臨床決定非常依賴於準確的患者記錄，因此本發明的EHR系統可以被設計成例如通過日期、時間、用戶和/或任何其他適當的方式來跟蹤對於患者記錄所發生的所有改變。EHR系統通常還可以把過去文檔版本的全部和/或所期望的選擇部分存儲在資料庫中以便於稽核。EHR系統的使用者還可以通過使用在EHR系統中可用的檢入(解鎖)和檢出(鎖定)動作來促進可稽核性，這是因為這些動作通常例如還可以防止多個用戶對任何給定文檔作出潛在地相矛盾的修改。

在一些實施例中，本發明的EHR系統的所有主要使用者可以利用可擕式或移動設備來進行其對EHR系統的訪問和利用。在一個實施例中，通常可以利用iPad®、Android®、Windows®平板設備和/或其他 類似的平板計算設備。一般來說，可能希望從受歡迎的、普及的和/或熟悉的計算平臺利用本發明的EHR系統，因為這樣例如可以允許用戶專注於其實際的任務而不是嘗試搞清楚不熟悉的和/或過於複雜的軟體介面。此外，受歡迎的和/或普及的計算平臺通常可以受益於勤勉的技術支持、問題熟悉性、更新以及/或者替換的可用性。本發明的EHR系統通常可以被利用在任何適當的設備上，其中可以包括而不限於智慧型電話、平板電腦、個人電腦以及/或者任何其他適當的計算設備。一般來說，本發明的EHR系統可以採用圖形化使用者介面(GUI)，並且取決於設備，所述圖形化使用者介面可以通過任何可能是適當的觸控式螢幕介面和/或鍵盤/滑鼠介面來訪問。本發明的EHR系統還可以採用其他形式的介面，比如針對存在視覺和/或聽覺缺陷的用戶的使用所設計的介面，以及/或者替換的介面，其中例如可以包括語音辨識和/或重放、盲文(Braille)電腦介面、觸覺介面以及/或者任何其他適當的介面。

在本發明的另一個方面中，本發明的EHR系統可以利用高度可客製的架構，其通常可以允許對EHR系統進行客製以適應(多個)用戶的任何特定需求，而無需對EHR系統的底層功能和/或設計作出任何重大改變。在一些示例性實施例中，本發明的EHR系統架構可以是基於使得系統的大多數方面的配置以系統物件的形式暴露於管理員，其中例如包括而不限於向表單添加欄位以創建用於應對實驗室指示單的新的工作流程之類的改變都可以在不改變本發明的底層EHR系統的情況下實現。系統物件通常可以利用YAML句法來定義並且例如可以作為分層結構資料(HSD)文檔(其中的一個實例是JavaScript物件標記(JSON)文檔)存在，其方式類似於由EHR系統管理的所有其他文檔(比如患者記錄)。

在本發明的另一個方面中，本發明的EHR系統可以被高效地並且容易地客製以便安裝在工作地點處，例如醫院、醫生辦公室和/或其他健康護理機構，而不需要對於EHR系統的大量“後端”客製以實現能夠工作的實現方式。一般來說，針對一個醫療專業人員群組將EHR帶上線的其中一項最大的開銷就是在系統內實施機構的現有工作流程和處理所花費的時間。雖然大多數機構共用會面(encounter)、患者帳戶、指示單、實驗室結果、協議和/或其他相同的基本概念，但是將這些概念縫合在一起以便從住院到出院驅動患者護理的確切方式對於不同的機構可以大為不同。在許多情況下，在典型的EHR實施期間使用逐步處理，以便識別和區分機構的不同工作流程和處理之間的相互聯繫。有效的EHR系統通常被設計成適應對於系統組態的小的、漸進的、潛在地頻繁的改變，以便適當地實施EHR系統從而使其將與機構一起工作。系統的表單、工作流程以及其他方面的定義有時常常被硬編碼到EHR本身中，由於所需的改變是在“後端”進行的，因此這常常需要分配具有高度技術水準的開發人員的時間來實施。此外一般來說，一旦機構客製開始涉及底層EHR產品中的改變，頻繁漸進改變的想法可能就變得不切實際。

在本發明的一個示例性實施例中，本發明涉及一種在無需創建電子健康記錄系統軟體的多個版本的情況下定義電子健康記錄系統中的定製表單的方法。通過本發明實現了針對前述挑戰的一種解決方案，並且允許多個機構對於其電子健康記錄系統具有不同的客製而無需創建移動設備和/或伺服器軟體的多個版本。這是通過利用以標準化句法或格式存儲資料的文檔(比如JSON文檔之類的HSD文檔)的靈活性以及此類文檔(比如JSON文檔)在前面提到的任何適當設備上被動態處理的獨有方式而實現的，而不管所述設備是否是移動設備。舉例來說，健康 記錄可以作為一系列HSD文檔(比如JSON文檔)被存儲在至少一台電腦伺服器上。這樣可以允許不是具有高度技術水準的軟體發展人員的軟體安裝或服務技術人員把表單佈局(例如人口統計資訊表單、過敏症表單等等)定義成存儲在至少一台電腦伺服器上的一系列HSD文檔(比如JSON文檔)，而不存在改變底層軟體的複雜性或技術難度。(由前面提到的技術人員定義的)表單佈局可以規定一系列表單層級小部件(widget)，其中包括“節段(sections)”、“列表”、“附注(notes)”以及“節段劃分選項卡”或其他小部件。節段還可以規定一系列節段層級小部件，其中包括文本欄位元、代碼挑選器、日期/時間挑選器、簽名欄位、單選/多選挑選器、是/否按鈕、日曆、核取方塊、客製HTML小部件、目錄使用者/群組挑選器、重量/長度/高度/血壓欄位、條碼欄位、照片欄位元、數位標度挑選器、房間挑選器、文檔挑選器等等。

不同於紙質文檔，移動設備軟體實施特定處理以便組合健康記錄HSD文檔(比如JSON文檔)和表單佈局HSD文檔或JSON文檔(二者都取回自至少其中一台電腦伺服器)，從而得到允許用戶讀取和/或改變電子健康記錄中的資料的最終呈現：移動設備軟體在螢幕上垂直排布表單層級小部件，並且在小部件中填寫來自健康記錄HSD文檔(比如JSON文檔)的資訊，從而使得使用者可以很容易地使用觸覺、鍵盤驅動或語音驅動的範例，例如通過移動設備螢幕與資料進行交互。

表單佈局可以規定屬性“映射”，其例如告知移動設備軟體哪些小部件可以被用來操縱健康記錄HSD文檔(比如JSON文檔)的哪些部分。屬性映射可以定義用於取回和/或記錄將通過設備螢幕上的小部件顯示和/或從使用者收集的HSD文檔(比如JSON文檔)內部的資料的分級操作的序列(例如取回/修改特定索引處的陣列單元，基於特定關鍵 字取回/修改關鍵字-值對表的值)。

表單佈局還可以規定例如用JavaSqript編寫的自動標題/子標題生成器演算法，以便允許基於健康記錄HSD文檔(比如JSON文檔)的屬性來計算標題和/或子標題。這樣就可以在無需例如修改移動設備和/或伺服器軟體的情況下客製健康記錄文檔的命名方式。每當例如在移動設備軟體中修改健康記錄文檔時，設備(比如移動設備軟體)可以例如只需要執行JavaScript標題/子標題生成器。

此外，例如還可以由移動設備軟體把清單小部件渲染成具有行和列的表。各行可以對應於健康記錄HSD文檔(比如JSON文檔)的陣列中的條目，並且各列可以包括將要在對應於健康記錄HSD文檔(比如JSON文檔)中的給定陣列條目的該行的各個儲存格中顯示節段層級小部件的規範。列表小部件定義還可以規定嵌入式表單佈局，以便顯示出針對當使用者在給定行的末端渲染的“資訊(info)”按鈕上敲擊時出現的該行的HSD物件的一部分或全部剩餘資料；這在利用基於列的機制沒有足夠的空間來顯示一行的所有資訊的情況下是有用的。

對於代碼挑選器小部件可以實施另一個處理步驟，比如：至少其中一台電腦伺服器可以被用來存儲表示標準化治療概念的“代碼”集合(例如，諸如乳房X射線照片的放射科規程，諸如左臂的解剖單元，諸如膽固醇測試的實驗室規程，諸如亞裔或基督教之類的可能的人口統計資訊屬性等等)。代碼挑選器小部件規範可以定義能夠向使用者顯示並且作為來自使用者的可能值而接受的可能代碼的受限制子集(例如僅有宗教；僅有放射科規程；僅有非品牌藥品；等等)。移動軟體向至少其中一台電腦伺服器查詢可以與所規定的限制相匹配的代碼，並且將其呈現在使用者在移動設備上所看到的視覺表單上以便從中進行“挑選”。

移動設備軟體可以允許使用者利用來自具有相關目的或類似佈局的健康記錄文檔的值自動填寫健康記錄文檔。這在第二次就醫時更新例如人口統計資訊之類的資訊的情形中可能是有用的，從而使得醫生或其他使用者不再需要重新輸入從前一次就醫以來可能未發生改變的資料。移動設備軟體例如可以在移動設備螢幕上顯示功能表，該功能表允許使用者挑選另一個健康記錄文檔以從中進行“自動填寫”。移動設備軟體例如可以利用來自所述另一個文檔的值自動填寫小部件，並且用黃色高亮顯示這些小部件。表單佈局可以被配置成規定該自動填寫處理每當在至少其中一台電腦伺服器上已經存在適當的文檔時自動發生，以便自動從中進行填寫。

這方面的一種變型或替換方案可以是“調和(reconciliation)”，其主要在基於列表的表單上工作(表單佈局規定將要調和的表單上的列表的性質以及調和處理可以針對其工作的文檔的特性)。當用戶正在特定表單上工作時，移動設備軟體例如可以向使用者呈現功能表以便選擇相關的文檔。移動設備軟體從至少其中一台電腦伺服器取回由使用者選擇的(多個)文檔，並且把來自不同相關文檔的“行”一起合併到表單上，其中用黃色顯示來自其他文檔的行。用戶隨後可以被允許接受或去除黃色的行。在調和結束時，移動設備軟體把仍然存在的各行一起合併到單個文檔中，並且把該文檔保存在至少其中一台電腦伺服器上。這方面的一個實例可以如下：外科醫生正在準備對由患者的主要護理醫師轉交給他/她的該患者動手術。外科醫生在表單上填寫患者當前正在服用的藥物。所述表單並不是技術上冗餘的，這是因為外科醫生想要在對患者動手術之前親自雙重確認他/她正在服用的藥物。除了外科醫生所填寫的表單之外，還有來自患者的主要護理醫師的表單，其中也列出了患者當前正在 服用的藥物，至少是由主要護理醫師在填寫表單時所記錄的藥物。在這種情形中，例如移動設備向外科醫生呈現存儲在至少其中一台電腦伺服器上的其他藥物清單的功能表以便與之進行調和，並且一個此類藥物列表是來自主要護理醫師的藥物列表。在外科醫生從功能表中選擇了主要護理醫師的藥物清單之後，移動設備從外科醫生所填寫的列表和主要護理醫師所提供的列表創建合併藥物列表。所述列表被呈現使得包含從主要護理醫師的列表併入的藥物的行用黃色高亮顯示，並且隨後提示外科醫生保留或者去除這些黃色高亮顯示的行，以作為關於確認或拒絕主要護理醫師所表明的在填寫主要護理醫師的表單時由患者服用的藥物的指示。在外科醫生對所有黃色高亮顯示的行採取動作之後，移動設備隨後把最終的文檔保存到電腦伺服器。

電腦伺服器可以利用存儲在永久性存儲中的搜尋引擎資料庫存儲所有可能的代碼(可能有數十萬的這些代碼)。當使用者基於特定標準(例如文本搜索項、比如放射科規程之類的代碼類型等等)尋找特定代碼時，電腦伺服器遍歷(iterate through)存儲以便找到與所規定的標準相匹配的代碼，其中可能使用索引或分散式搜索(其中代碼被分佈在用來分治搜索的多台電腦伺服器上)來優化這一處理。

電腦伺服器存儲HSD文檔(比如JSON文檔)，其方式在兩個方面不同於標準紙質表單。首先，創建不僅自動記錄對於每一個HSD表單(比如JSON表單)的改變(什麼以及由誰)而且還記錄內容何時被查看、查詢或列印(什麼以及由誰)的稽核蹤跡。其次，可以由單個用戶“鎖定”HSD文檔(比如JSON文檔)以便防止其他用戶對於相同文檔的同時改變。

稽核蹤跡存在於至少其中一台電腦伺服器上的不同存儲部分 中，並且每當實施改變、查看、列印或查詢活動時被修改。

所述鎖定也可以被存儲在至少其中一台電腦伺服器上的不同存儲部分中。對於每個HSD文檔(比如JSON文檔)可以自動創建一個鎖定，並且其具有以下屬性：(a)底層JSON文檔的ID；(b)鎖定JSON文檔的人的用戶ID(如果該文檔當前被鎖定的話)；(c)用戶在其中鎖定文檔的用戶登錄會話的安全性權杖；(d)鎖定被建立時的時問戳記。

當使用者想要在設備(比如移動設備)上修改HsD文檔(比如JSON文檔)時，移動設備軟體首先確認沒有其他使用者在至少其中一台電腦伺服器上的所述文檔上設置鎖定。

一般來說，可以獨立於健康記錄JSON文檔並且獨立於例如移動設備和/或伺服器軟體的版本來更新表單佈局，只要表單佈局定義所依賴的能力(而不是具體客製本身)受到移動設備和/或伺服器軟體版本的支援即可。

健康記錄表單HSD文檔(比如JSON文檔)的片段也可以被存儲在至少一台電腦伺服器上，以便支援其中用戶具有被例行輸入到健康記錄表單中的資訊的情形；前面的移動設備軟體的自動填寫功能表還可以顯示適用的健康記錄表單片段，並且當用戶在對應於此類片段的功能表項目目上敲擊時，移動設備軟體可以利用已被存儲在該片段中的那些欄位自動填寫表單。

為了促進一次創建多個健康記錄表單文檔的處理，移動設備軟體例如可以允許特別標記的清單小部件利用“批次處理模式”收集用於多個文檔的資訊。舉例來說，為了允許用戶一次輸入多項用藥指示單，可以規定特別標記的清單小部件，其中表中的每一行實際上是單獨的用藥指示單。在用戶完成輸入用於批次處理文檔創建的所有資訊之後，移 動設備軟體例如創建剛剛所創建的健康記錄文檔的一份單獨的拷貝，其不同之處在於，關聯到所創建的每一份單獨的健康記錄文檔拷貝中的特別標記的清單小部件的屬性包含原始陣列的單行而不是整個陣列。

一些醫療表單可能需要圖像、掃描文檔或者其他圖形單元。至少一台電腦伺服器可以存儲可以與每一個健康記錄表單相關聯的圖形附件。表單佈局可以規定用以顯示圖形附件的螢幕區域。

在本發明的另一個示例性實施例中，本發明包括一種在無需創建電子健康記錄系統軟體的多個版本的情況下定義電子健康記錄系統中的客製工作流程的方法。這裡的挑戰在於如何客製電子健康記錄系統，以便允許特定使用者類別在對應於醫院或其他健康護理機構中所存在的處理的步驟序列中創建、檢視、許可或拒絕健康記錄表單(例如登記新的患者，允許藥劑師檢視由護士代表醫生撰寫的處方，記錄為患者給出的用藥劑量等等)-而不需要移動設備/伺服器軟體的多個版本。本發明通過利用HSD文檔(比如JSON文檔)的靈活性以及HSD文檔(比如JSON文檔)在前面提到的任何適當設備上被動態處理的獨有方式實現了這一點，從而例如提供了一種可以允許技術人員把“模式化處理”定義成存儲在至少一台電腦伺服器上的HSD文檔(比如JSON文檔)的解決方案。所述模式化處理是利用例如JavaScript代碼之類的腳本代碼定義的(當然這可以被推廣到使用某種其他程式設計語言)。所述代碼例如可以運行在移動設備上，並且可以與至少一台電腦伺服器動態交互，從而實施諸如前面所定義的查詢、文檔創建、文檔鎖定/解鎖以及文檔刪除之類的操作。為模式化處理代碼給出對於操作“情境”的訪問(例如如果代碼在使用者查看特定患者記錄時被調用，則向模式化處理傳遞參數從而向其通知該患者的ID)。模式化處理代碼還可以被允許利用“堆疊 (stack)”隱喻在螢幕上顯示表單。所述表單可以類似於由技術人員創建的前面所描述的健康記錄表單，其不同之處在於，模式化處理中的表單可以基於情境、從其他健康記錄文檔收集的資訊等等被即時動態地生成。這些表單可以顯示/捕獲特定於正被實施的人工處理的資料。堆疊隱喻與web流覽器的隱喻的類似之處在於，當顯示新的表單時，其具有被“堆疊”在先前顯示的表單之上的選項，從而使得使用者可以在“返回”按鈕上敲擊並且回到先前的表單。

本發明還可以允許技術人員把工作流程許可步驟定義成表單佈局HSD文檔(比如JSON文檔)的一部分(作為前面的#1的一部分進行了描述)。工作流程可以被定義成需要從已定義的使用者類別集合(工作流程的“步驟”)收集的一系列數位簽章以便達到最終的“狀態”(例如“被許可”狀態)。在向使用者顯示健康記錄表單時，移動設備軟體可以在螢幕上顯示出按鈕，以允許使用者進行“提交”、“許可”、“拒絕”或“確認”-這些動作(除了“拒絕”之外)可以得到數位簽章(利用例如SHA-256之類的標準數位簽章演算法)，所述數位簽章是基於當前使用者的私有金鑰對於顯示在表單上的資料計算的，並且被添加到保存在至少一台電腦伺服器上的健康記錄文檔。此外，隨著文檔經歷工作流程中的各個步驟而收集到必要的數位簽章並且變得需要另外的數位簽章，至少其中一台電腦伺服器可以被用來把例如指向醫生的指標存儲在伺服器的專用於特定用戶或者專用於特定使用者類別的存儲部分中，其被稱作“佇列(queue)”。移動設備軟體例如可以呈現對應於已登入用戶或者該用戶所屬的使用者類別的佇列，以便提醒使用者有文檔等待他/她簽名。“拒絕”的工作方式略有不同-例如移動設備軟體去除至此為止所收集到的數位簽章，並且把文檔返回到原始提交者(第一簽名人)的佇列。“確 認”是被支援以允許對於特定步驟充當實際經過授權的用戶或者實際經過授權的使用者類別的代理的使用者作為代理對文檔簽名的動作。隨後可以把指向文檔的指標存儲在用於代理使用者代表其進行簽名的經過授權的使用者或使用者類別的佇列中，從而為經過授權的用戶提供“確認”所述代理確實作為其代表採取行動的機會。

在本發明的另一個示例性實施例中，包括一種在無需創建電子健康記錄系統軟體的多個版本的情況下定義電子健康記錄系統中的客製視圖的方法。通過利用HSD文檔(比如JSON文檔)的靈活性以及HSD文檔(比如JSON文檔)在前面提到的任何適當設備上被動態處理的獨有方式，解決了關於如何客製電子健康記錄系統的挑戰，以便允許使用者例如使用移動設備軟體來查看可以從多個健康記錄表單匯出並且可以被核對/重新安排/對應/交叉參考的資訊，從而使得更容易支援決策制定處理而無需改變健康記錄表單被存儲在至少一台電腦伺服器上的方式(例如對於所有住院患者顯示出即將配藥的用藥指示單的清單，作為曲線圖顯示出過去2小時的特定患者的血壓和心率等等)。舉例來說，健康記錄可以作為一系列HSD文檔(比如JSON文檔)被存儲在至少一台電腦伺服器上。本發明的解決方案包括允許技術人員把“客製小部件”定義成存儲在至少一台電腦伺服器上的HSD文檔(比如JSON文檔)。所述客製小部件例如可以利用存儲在HSD文檔(比如JSON文檔)內部的HTML與例如JavaScript之類的腳本的混合來定義(當然也可以選擇其他語言)。代碼可以運行在設備(例如移動設備)上，並且可以與至少其中一台電腦伺服器動態交互，從而實施例如前面所提到的查詢、文檔創建、文檔鎖定/解鎖以及同樣如前面所提到的文檔刪除之類的操作。可以為客製小部件代碼給出對於顯示請求的“情境”的訪問(例如，如果 代碼在使用者查看特定患者記錄時被用來顯示資訊，則向客製小部件傳遞參數從而向其通知該患者的ID)。由於標準web技術可以被用來把客製小部件託管在設備(例如移動設備)上，因此可以很容易地合併協力廠商庫(例如用於顯示圖表、計算體質指數等等)。此外，本發明可以允許把多門戶元件(multi-portlet)“報告”定義成存儲在至少一台電腦伺服器上的HSD文檔(比如JSON文檔)。所述報告規定將由移動設備軟體同時顯示的小部件集合(其中包括前面所描述的客製小部件，而且還包括模式化處理)，以便在單個螢幕上為特定使用者類別提供到相關資訊的可見性。定義報告的HSD文檔(比如JSON文檔)提供將要顯示的小部件清單以及例如寬度/高度之類的幾何約束，以便允許移動設備軟體按照具有視覺吸引力的方式在螢幕上排布各個小部件。

在本發明的另一個示例性實施例中，一種方法在無需創建電子健康記錄系統軟體的多個版本的情況下定義電子健康記錄系統中的客製導覽功能表。通過利用HSD文檔(比如JSON文檔)的靈活性以及JSON文檔在前面提到的任何適當設備上被動態處理的獨有方式，解決了關於如何客製向一個或多個使用者類別顯示的使用者介面功能表從而使得很容易訪問相關資訊的挑戰，這是根據以下事實：(a)任何給定用戶可以同時是不止一個而是多個類別的成員；(b)被認為對於某一使用者類別是相關的資訊可能由於新的治療協定的發展而快速改變，其中一部分在極端情況下可能無法等待移動設備/伺服器軟體的新版本。舉例來說，健康記錄可以作為一系列HSD文檔(比如JSON文檔)被存儲在至少一台電腦伺服器上。本發明所給出的解決方案允許技術人員把“內容層級表”和“內容層級貢獻表”定義成存儲在至少一台電腦伺服器上的HSD文檔(比如JSON文檔)。當患者記錄由移動設備軟體顯示時，例如移動設 備軟體向至少其中一台電腦伺服器查詢對應於情境中的物件(其通常最初是包含患者的基本/人口統計資訊的健康記錄表單)的內容層級表和內容層級貢獻表。內容層級表HSD文檔(比如JSON文檔)可以通過唯一識別碼來標識(存儲在至少一台電腦伺服器上的所有HSD文檔(比如JSON文檔)都是如此)，並且可以包含例如關於如何計算將為對應於該層級的功能表顯示出的標題以及如何向至少其中一台電腦伺服器查詢適合在該功能表層級顯示的資訊和/或健康記錄文檔的資訊。內容層級貢獻表HSD文檔(比如JSON文檔)可以列出所述貢獻對其相關的用戶類別，並且包含到用於為之作出“貢獻”的內容層級表HSD文檔(比如JSON文檔)的唯一識別碼的參考。當在設備(例如移動設備軟體)中顯示功能表時，對於已登入使用者相關的內容層級貢獻表(由於該用戶在例如醫師、護士、實驗室技術人員等特定用戶類別中的成員關係)被聚合並且顯示成功能表。每一個內容層級貢獻表可以包括一系列節段；每一個節段包括功能表項目目規範序列。各個節段可以依次被垂直地順序顯示，並且在每一個節段內，各個功能表項目目可以根據功能表項目目規範依次被垂直地順序顯示。存在幾種類型的功能表項目目規範，其中包括：(a)到表單佈局HSD文檔(比如JSON文檔)的參考-其表明作為如在內容層級表JSON文檔中規定的針對至少其中一台電腦伺服器的查詢的結果集合的一部分並且是利用所參考的表單佈局HSD文檔(比如JSON文檔)創建的健康記錄文檔應當具有顯示在功能表的該部分處的相關聯的按鈕，所述按鈕在被敲擊時使得文檔被打開以進行編輯；或者可以顯示出按鈕以允許使用者利用所參考的表單佈局創建健康記錄文檔；(b)到客製小部件、多門戶元件報告或者模式化處理的參考，以便允許用戶在所得到的功能表項目目上敲擊從而帶出功能表的情境中的相應的 使用者介面單元；(c)到內建命令(比如“列印”或者“添加患者門戶訪客帳戶”)的參考，以便為用戶提供對於內建到移動設備軟體中的功能的訪問；(d)健康記錄表單片段，其提示移動設備軟體顯示允許使用者基於來自所述片段的預先填寫的值創建新的健康記錄的功能表項目目。還可以利用編號對內容層級貢獻表的各個節段進行優先順序排序(具有較低優先順序編號的節段被排序成在功能表中更早顯示)並且還為其指派超馳關鍵字(override key)-這樣允許定義具有相同超馳關鍵字的節段的多項貢獻僅顯示具有最高(或最低)優先順序的一個節段而不是所有此類節段。最後，當對應於特定文檔類型或文檔的功能表項目目被敲擊時，移動設備軟體可以顯示子功能表(也就是內容層級表-內容層級貢獻表的從屬集合)，而不是打開文檔以進行編輯。

在本發明的另一個示例性實施例中，一種方法通過一系列測試環境向生產系統轉出客製(表單、工作流程、客製視圖、導覽菜單)。通過利用JSON文檔的靈活性以及HSD文檔(比如JSON文檔)在前面提到的任何適當設備上被動態處理的獨有方式，解決了關於如何通過各種方式在類比由機構職員使用的電腦伺服器的替換電腦伺服器上驗證客製的挑戰，並且最終以最低程度的中斷把更新後的客製部署到至少其中一台生產電腦伺服器。舉例來說，健康記錄可以作為一系列HSD文檔(比如JSON文檔)被存儲在至少一台電腦伺服器上。除了至少其中一台生產電腦伺服器之外，所述解決方案假設具有被配置成用於測試使用的多台電腦伺服器(例如一台具有被用於簡單測試的測試患者記錄，一台具有被用於相容性測試的真實患者記錄的拷貝，一台具有由職員創建的虛構患者記錄以用於訓練目的等等)的環境。移動設備軟體支援通過“同步(sync)”處理來傳播客製，也就是說，使用者使用移動設備軟體同時登 錄到兩台電腦伺服器，並且把兩台伺服器上的客製(即，不是患者記錄)HSD文檔(比如JSON文檔)進行比較。所述比較處理可以在設備(例如移動設備)上實施並且工作如下：(a)利用唯一識別碼(例如128比特UUID)來標記HSD文檔(比如JSON文檔)，其允許標識出兩台伺服器上的哪些HSD文檔(比如JSON文檔)被認為是相同文檔的不同版本；(b)計算HSD文檔(比如JSON文檔)的正規化(canonicalize)版本並且進行比較；如果其相同，則認為文檔沒有發生改變；(c)如果存在差異，則比較兩個文檔上的最近一次更新或最近一次同步的時間戳記，並且如果存在差異，則移動設備軟體向使用者表明二者當中的哪一項被認為是日期更近的；(d)對於僅存在於其中一台伺服器或另一台伺服器上的HSD文檔(比如JSON文檔)(也就是說在另一台伺服器上不存在具有相同的唯一識別碼的文檔)，移動設備軟體向使用者表明該文檔是新的；(e)移動設備軟體允許使用者選擇哪些文檔版本要保持以及哪些版本要在任一個方向上傳播，並且可以通過自動建議可以安全地傳播僅存在於一台伺服器上而不存在於另一台伺服器上的文檔或者其中一台服務器具有根據存在於另一台伺服器上的版本而被修改的文檔(也就是說並非存在於任一台伺服器上的一對文檔被同時修改的情況)簡化這一處理；(f)通過直接把文檔添加到另一台伺服器(如果文檔是新的話)，或者首先鎖定目標伺服器上的文檔，把新的版本寫入到目標伺服器，並且最後解鎖文檔(類似於較早前描述的鎖定/解鎖概念)，移動設備軟體隨後在每一個所選擇的文檔上實施傳播。

不同於通常需要使得系統離線或關停一段時間以便替換軟體二進位的軟體改變，本發明中的客製被存儲為配置資料而不是表現在二進位碼中，因此不需要對移動設備/伺服器軟體作出改變，從而減少了停 機時間。此外，不同於特別因為HSD(比如JSON)非常資訊密集並且難以通過視覺方式挑選出改變而易於出錯的人工同步處理，由移動設備軟體實施的自動化處理能夠利用散列非常精確並且準確地比較大量的客製。此外，由於HSD文檔(比如JSON文檔)總是“可用於”由其他使用者使用移動設備取回，即使當新的版本被寫入到給定的電腦伺服器(採用被稱作原子性的資料庫的基本屬性)時也是如此，並且還因為通過僅允許相容的小部件改變(例如用是/否選擇替換核取方塊)、通過添加新的小部件(從而不會影響讀取/編輯由已經存在的小部件顯示的值的能力)或者通過添加全新的健康記錄表單範本可以使得客製HSD文檔(比如JSON文檔)“後向和前向相容”，因此不需要停機時間來對包括生產電腦伺服器在內的任何電腦伺服器實施這些更新；這與許多基於傳統關聯式資料庫(或者甚至基於二進位碼)的客製模型不同，在這些客製模型中，用以支援新的客製的模式改變可能需要電腦伺服器並且從而還有總體電子健康記錄系統的停機時間。

在本發明的另一個示例性實施例中，本發明包括一種按照多模式方式輸入健康記錄資料的方法。由於例如在移動設備上導覽大量功能表和表單以找到特定資訊已被/應被記錄的位置可能較為困難，因此特別對於習慣了紙質記錄的醫生來說，即使在單個機構內，在無需移動設備/伺服器軟體的客製版本的情況下支援使用者的各種使用樣式/要求的需求仍然可能是很大的挑戰，而本發明通過利用HSD文檔(比如JSON文檔)的靈活性以及HSD文檔(比如JSON文檔)在前面提到的任何適當設備上被動態處理的獨有方式實現了這一點。

使用者可以通過多種模態(例如語音、觸摸、鍵入等等)的組合向給定動作(例如撰寫出院證明、開藥等等)提供參數，並且安裝 技術人員可以通過存儲在至少一台電腦伺服器上的HSD文檔(比如JSON文檔)的形式規定可能的命令。舉例來說，技術人員可以定義命令集合，每一項命令定義可以包括以下部分：(a)被允許使用該命令的使用者類別的集合；(b)調用該命令的話語，其中可以包括語言的變型(例如“給我看過敏症(show me allergies)”相對於“顯示過敏症(display allergies)”)，並且可以使用自然語言處理技術來描述可能的變型(例如BNF語法)；(c)參數集合，其中每一個參數可以包括(i)名稱、(ii)語義類型(例如日期、患者ID等等)、(iii)表明其是否可選的標誌、(iv)表明該參數所表示的物件是否需要被“打開以進行編輯”的標誌(例如為了執行命令“把這個記下來以作為患者的症狀(take this down as the patient’s symptoms)”，“症狀(symptoms)”健康記錄文檔例如需要在移動設備上實際被打開而不僅僅是被識別)；(d)每當由於用戶動作而例如由移動設備收集參數時所執行的代碼，其在收集到所有所需要的參數時執行命令；(e)可選地可以向用戶輸出以進行確認和/或消除歧義的消息(例如對於操作“給我看在兩次就醫之間增加了多少體重(show how much weight was gained between visits)”，在規定了其中一次就醫之後，可能需要提示使用者“規定與哪一次就醫進行比較(specify which visit to compare against)”，這是因為例如“規定就醫#2(specify visit #2)”之類的一般語言可能不夠使用者友好)。在用戶登入時或者在話音辨識會話啟動時，設備(例如移動設備)軟體可以從至少一台電腦伺服器載入適用於該用戶所屬的用戶類別的具有話音命令規範的所有HSD文檔(比如JSON文檔)。當例如由移動設備軟體捕獲自然語言命令時(使用話音辨識元件/技術，其可以由平臺提供、由語音辨識庫提供或者由某種其他自然語言輸入機制提供，其中包括鍵盤)，將其與可能的命 令話語進行比較以便找到匹配的命令。如果找到匹配，則啟動“會話”以通過下面的重複處理收集參數：(a)查看可能由用戶的當前情境所滿足的參數(例如剛剛通過用戶的觸摸動作而在移動設備上打開的患者記錄可以有資格作為針對正被執行的命令的患者參數)；(b)提示用戶找到或識別滿足給定參數的需求的物件(例如“你想要顯示患者的過敏症。請識別患者。(you want to display a patient’s allergies.please identify a patien.)”)，這可能是通過口頭消息或者通過顯示在設備上的事物；(c)調用命令定義內部的代碼以便考慮從用戶處收集或者從情境識別的作為可能參數值的新的物件，並且如果所有參數都被滿足，則執行命令-例如JavaScript(或其他語言)之類的腳本代碼隨後將與移動設備/伺服器軟體進行交互，以便添加/查詢/去除健康記錄文檔、在螢幕上對其進行顯示或者對於命令所適當的其他動作。

在命令的參數已被滿足並且準備好執行命令之後可以發生的一項可能的動作(由命令定義內部的代碼規定)是例如把移動設備的操作模式改變成聽寫(dictation)模式。在該模式下，除了在通過聽寫收集到的文本上進行操作(例如拷貝/粘貼、刪除)的固定話語以及表明聽寫模式的結束的話語之外，所捕獲的話音被收集作為用於由命令定義規定的某個欄位的值(例如“針對處方配藥的特殊指令(special instructions for prescription dispensation)”)。這樣可以在例如“開具一天兩次撲熱息痛的處方(prescribe acetaminophen twice a day)”之類的話語意圖作為文本被捕獲並且直接記錄到健康記錄文檔中時防止其被混淆成針對系統的命令。

在參數捕獲期間以及在參數捕獲結束時可以發生(可能多次發生)的另一項可能的動作(由命令定義內部的代碼規定)是語音提示。 在對話中的特定點處對使用者說出的口頭消息可以說明引導使用者提供用於執行命令的必要參數。

舉例來說，一條內建命令可以是“別管了(never mind)”或其變型，其在由例如移動設備軟體聽到時表明使用者想要取消執行命令和捕獲任何所需的參數。

可以通過多種方式“嵌套”多條命令，並且會話機制允許解析可能在參數捕獲期間出現的歧義。舉例來說，如果使用者最初聲明希望“記錄出院證明(record a discharge note)”，例如移動設備隨後提示使用者指定“哪一位患者？(which patient？)”，隨後用戶聲明命令“給我看上星期的患者(show patients from last week)”，系統可以提示使用者指定“上星期(last week)”所指的是什麼-住院日期還是出院日期，並且針對該問題的回答可以被消除歧義以指代對於“給我看上星期的患者(show patientsfrom last week)”開始的第二會話，這是因為所述回答匹配第二命令/會話所需的參數的語義類型，並且不匹配任何第一命令/會話所需的參數的語義類型(如果這樣的歧義存在，則移動設備將提示使用者消除歧義)，此外，一旦顯示出上星期的患者列表並且選擇了一位患者，由於患者是第一命令/會話最初所要求的資訊類型，因此其可以被用作針對第一命令/會話的參數。換句話說，多個命令會話可以同時活躍，由移動設備通過提示或者情境捕獲的物件可以被用來滿足用於這些命令會話當中的任一個的參數，並且如果存在歧義，則移動設備可以提示使用者消除歧義。

雖然可能已經設想到用於多模式交互的其他系統，但是例如通過移動設備軟體和至少其中一台電腦伺服器實施的該機制允許在無需改變底層移動設備/伺服器軟體的情況下對話音樣式和命令定義進行客 製。

在本發明的另一個示例性實施例中，本發明涉及隨著時間演進從而改進處理、對規章改變作出回應以及/或者修正錯誤的健康護理表單，並且當需要把關於原始表單佈局集合所記錄的健康記錄遷移到具有新的表單佈局的較新表單的集合上時，沒有不必要的停機時間也不需要移動設備/伺服器軟體的新的版本。

當今在大多數其他EHR中，通常不鼓勵表單範本改變，這不僅是因為更新硬編碼的範本以產生新版本所需的工作量，而且還因為需要把資料移轉到新的範本版本，正如前面所提到的那樣。用於應對更新的通用方法非常少，因此在升級到主要的新版本已完成時，常常開發客製工具以進行遷移。由於可能的停機時間以及在升級期間出錯的可能性，這樣的升級不會頻繁進行。

本發明通過允許技術人員定義駐留在至少一台電腦伺服器上的轉換映射HSD文檔(比如JSON文檔)而滿足了前述挑戰，轉換映射HSD文檔把存在於原始表單佈局集合上的資料欄位元映射到更新後的/新的表單佈局集合上的欄位元上。

由技術人員定義的轉換映射可以包括直接映射(例如屬性“dob”需要被映射到屬性“dateOfBirth(出生日期)”)以及可以利用JavaScript代碼之類的腳本代碼定義的更加複雜的映射的組合。

設備(例如移動設備軟體)隨後可以利用登錄到負責保持患者記錄的系統的使用者的身份通過以下方式實施所需的變換：移動設備軟體開始於識別和鎖定至少一台電腦伺服器上的所有相關的(也就是使用所表明的原始和/或新的表單佈局的那些)健康記錄HSD文檔(比如JSON文檔)； 移動設備軟體遍歷在轉換映射的變換前側中所參考的每一個資料欄位元，並且對於具有該欄位元的每一個健康記錄文檔：(a)移動設備軟體識別與該欄位元被映射到的變換後資料欄位元相關聯的表單佈局；(b)如果對應於該相同患者的健康記錄文檔(並且可能還有相同的會面ID或者其他相關的分組機制)尚不存在，則將一個健康記錄文檔添加在電腦伺服器上並且鎖定；(c)把資料映射過去並且寫入到目標健康記錄文檔(其或者已經存在並且是在(b)中創建，或者實際上是與源健康記錄文檔相同的文檔)上的相應的變換後資料欄位元中；(d)將改變保存到電腦伺服器；在所述處理結束時，移動設備軟體釋放至少一台電腦伺服器上的所有觸及的健康記錄JSON文檔；以及移動設備軟體隨後向使用者呈現發生了映射的報告。如果其中一些映射由於以下原因未能發生：(a)另外的某人鎖定了所需的文檔；(b)資料被不正確地格式化；(c)在轉換中檢測到不一致-則移動設備向使用者報告這些問題。

前面剛剛描述的處理可以被重複所需要的次數，每一次運行都把健康記錄系統朝向目標轉換“狀態”遞進地移動。通過這種方式，所述系統與GPS導航設備具有相同的屬性，也就是說不管在中途遇到什麼問題，重複嘗試運行所述處理都導致更加接近目標目的地狀態。

另一個重要的好處在於，即使在轉換期間仍然可以由系統中的其他使用者參考並且看到鎖定的文檔，並且僅僅短暫地禁止對於例如正由移動設備軟體的轉換所處理的特定文檔作出進一步改變。

在一些示例性實施例中，本發明的EHR系統可以基於使得系統的大多數方面的配置以系統物件的形式暴露於管理員，所述系統物件 例如可以利用YAML句法來定義，並且例如作為HSD文檔(比如JSON文檔)存在於系統中，正如前面所討論的那樣。通過這種方式，可以在無需改動底層EHR系統“後端”的情況下實現對於EHR系統的所暴露出的“前端”的各種改變和/或修改。改變和/或修改可以包括而不限於修改表單、創建新的工作流程。

在一些實施例中，本發明的EHR系統可以採用例如表單佈局之類的基本系統物件，其可以定義如何向使用者呈現資訊和/或資訊的總集，比如在表單之類的視覺表示中呈現，以及/或者如何在EHR系統中結構化和/或記錄所輸入的資訊。

在一些實施例中，範本可以被用來作為表單向使用者顯示和/或組織一系列單獨的資訊呈現和/或收集元件，所述表單在視覺上可以類似於在健康護理環境中通常所採用的電子和/或紙質表單。舉例來說，各個單獨的資訊呈現和/或收集元件可以是表單小部件(例如HTML小部件)，其隨後可以被使用者利用作為設備上的介面以用於輸入和/或取回資訊。表單小部件本身可以被嵌入到正顯示在本發明的EHR系統的使用者介面上的表單和/或報告中。資訊和資訊結構隨後可以被存儲在例如至少一台電腦伺服器上的本發明的EHR系統的永久性存儲中的HSD文檔(比如JSON文檔)內。

多種小部件可以被利用來例如簡化對於不同種類的資訊的收集，其中可以包括而不限於文本輸入、日期和時間、血壓讀數、基於標準詞彙表的代碼、從設備取得的圖片和/或照片以及/或者任何其他適當的小部件。小部件還可以被劃分成各個節段和表以便於導覽。在從使用者收集資料時，可以通過小部件記錄用於資訊的值，其可以進一步被記錄在通過範本定義的關鍵字之下，並且被放置到HSD文檔(比如JSON 文檔)中。通過這種方式，表單的使用者介面可以被利用來按照所利用的範本呈現底層HSD文檔(比如JSON文檔)，以便由用戶按照用戶友好的管理員定義的方式進行檢查和修改。

在一些實施例中，巨集集合可以被用來規定當在使用者介面中操縱資訊時出現在本發明的EHR系統中的巨集集合。舉例來說，當按下巨集按鈕時，對應於該巨集按鈕的文本可以被插入到活躍文本欄位元中。所述文本可以由定義在巨集集合中的腳本動態地生成，所述巨集集合在由移動設備運行時從至少一台電腦伺服器獲得潛在地情境相關資料，比如患者的過敏症或人口統計資訊，以便包括在所插入的文本中。巨集集合的目標可以被設定在表單上的特定欄位、特定用戶和/或特定群組。通過這種方式，需要快速鍵入常用的文本片斷和/或其他資訊的使用者可以具有被客製成適合其需求的介面，從而可以允許其更加高效地輸入資訊。

一般來說，當EHR系統中的任何給定記錄(比如患者記錄)隨著時間增長時，特定資訊項可能會不可避免地被反復收集，比如過敏症和當前用藥。舉例來說，可能存在臨床和/或可稽核性要求，其可能要求多次收集資訊，從而可能導致最新的資訊潛在地被分散在多個文檔中。舉例來說，患者可能在一次會面期間聲明特定過敏症，但是在下一次會面中則忘記提起。

在一些示例性實施例中，本發明的EHR系統可以提供調和能力，以便允許將收集自多個文檔上的相同和/或相關的表單範本的資訊一起呈現，並且允許用戶選擇保留哪些(如果有的話)重複的和/或相矛盾的條目以及丟棄哪些條目。不同於紙質記錄，EHR系統中的資訊可以由EHR系統結構化和/或可識別，比如通過前面所討論的關鍵文書處理，從 而使得搜索可以允許很容易聚集相同和/或相關的資訊，而不是像紙質記錄那樣，使用者必須人工篩檢所有適用的表單以取回資訊。此外，在紙質記錄中，可能無法像EHR系統那樣很容易地把資訊從分散的紙質文檔中拉取到單個文檔上，或者當匆忙檢視或時間緊迫時，在檢視紙質文檔的過程中可能會錯失資訊。

此外，不同於紙質文檔，其中用於組織和/或重新組織的僅有手段通常是對頁面重新排序、插入封面/分隔頁面以及/或者附著帶狀標誌等等，電子記錄通常可以被基本上暫態地重新整理，以便滿足當時正在進行的工作的需求。舉例來說，實驗室技術人員感興趣的患者記錄中的文檔子集可能在某種程度上不同於例如辦理患者住院的接待員所感興趣的子集。在紙質表單中，除了按照不同順序具有相同記錄的多份拷貝之外，無法對於一個用戶按照不同於另一個使用者的方式重新組織頁面，這在患者護理中可能會導致問題，本發明則允許一個用戶群組(例如實驗室技術人員)感興趣的患者記錄中的文檔子集可以在某種程度上不同於例如辦理患者住院的接待員所感興趣的子集。多份拷貝的存在還可能在稽核過程中導致問題和過度的開銷，對於本發明的EHR系統則不會產生這些問題和開銷。

在本發明的一個示例性方面中，本發明的EHR系統可以利用內容表(TOC)系統物件來定義用於患者記錄中的文檔的動態組織。在一些實施例中，可以通過TOC把文檔動態地組織到樹結構中，所述樹結構可以類似於大多數臺式電腦使用者所熟悉的標準“資料夾範例”。舉例來說，不同於紙質書之類的內容表，本發明的EHR系統能夠利用可以不是靜態的TOC定義，從而可以例如基於情況需求和/或基於用戶的(多個)角色(例如醫生、實驗室技術人員等等)在每個用戶的基礎上對其 進行適配。因此可以針對特定使用者和/或特定情況需求來客製TOC，以便提供用以導覽經過文檔中的資訊的高效和/或直觀的組織方案。此外，不同於常見的資料夾分級結構類型的檔案系統，EHR系統TOC可以作為導覽工具操作，而不是實際控制資訊本身被存儲在系統內的方式。

在一些實施例中，根部TOC層級可以定義呈現給使用者的選擇功能表。所述選擇功能表還可以包含文檔的混合，比如基本患者資訊文檔、報告(例如“隨著時間的血壓(Blood Pressure Over Time)”)以及/或者到其他TOC層級的連結，其在外觀和/或用途方面可以類似於典型桌面系統中的子功能表。所述功能表通常可以被定義成針對本發明的EHR系統的資料庫的一系列查詢，並且所述查詢可以非常具體(例如“給我看患者唯一的基本患者資訊文檔(show the patient’s one and only Basic Patient Information document)”)、寬泛(例如“給我看該患者的所有放射圖像(show all radiology images for this patient)”)以及/或者具有任何介於中間的具體性。功能表通常還可以被劃分成多個節段以易於導覽，並且還可以包括可以允許添加新的文檔和/或組織層級的按鈕和/或其他控制特徵件。舉例來說，功能表可以包括列出針對特定患者的所有放射圖像的節段，並且按鈕和/或其他控制特徵件可以被配置成出現在該節段中以便為使用者給出添加資訊(例如新的圖像)的選項。

在一些實施例中，TOC層級可以包含到其他TOC層級的連結，從而使用者可以根據具體任務和/或情況選擇沿著不同的軸來查看文檔。這種靈活性與紙質系統完全不同，在紙質系統中只能按照一種方式或另一種方式對物理紙張進行排序，並且對其重新排序是非常耗時的。舉例來說，通過在本發明的EHR系統中定義例如用於患者會面的TOC子層級並且把到患者的不同會面的連結放置在根部TOC層級中，門診醫 師可以通過會面來查看關於患者所收集的資訊。與此同時，作為另外的實例還可以定義用於記帳帳戶的不同TOC子層級，並且把到這些帳戶的連結放置在根部TOC層級中。這些連結隨後例如可以為會計部門的記帳專業人員提供到完全相同的患者記錄文檔中的不同視圖，所述視圖按照對於單個紙質記錄所不可能的方式更加適合於記帳專業人員的需求。

在本發明的另一個方面中，由本發明的EHR系統利用的系統物件通常可以由機構按照類似於其他機構知識的方式來對待，並且因此可以被備份、版本處理、根據已定義的改變處理更新以及/或者在其他方面按照與受到管理的其他機構知識類似的方式來對待。

在一些示例性實施例中，系統物件通常可以定義關於使用者如何與其機構處的本發明的EHR系統進行交互的幾乎每一個方面。因此，系統物件的整個總集可以被備份、版本處理、根據已定義的改變處理更新等等。舉例來說，在EHR系統轉出的開頭，可以基於各種專案的通用定義的組合來產生初始版本，比如內容表、患者表單佈局、針對患者住院的特定於機構的客製以及/或者實驗室處理。隨後可以按照多種方式引入系統物件總集的下一個版本和/或後續版本，以便最小化對於機構處的EHR系統的持續操作的干擾。可能希望在可以被專用於開發和測試的本發明的EHR系統的拷貝或實例上對這些系統物件實施更新，並且從而與正由機構使用的主要操作實例分開。因此，當設計工作和/或其他更新完成和/或被許可時，新的系統物件總集可以被拷貝到同樣可以與主要操作實例分開的本發明的EHR系統的訓練實例，以便在不影響機構處的本發明的EHR系統的主要操作實例的持續操作的情況下允許職員和/或其他用戶熟悉新的改變。在充分的訓練、調試和/或其他定型之後，所述系統物件總集隨後可以被推送到生產伺服器，從而使其可以在本發明的EHR 系統的主要操作實例中成為機構中的主流使用的一部分。

在一些實施例中，本發明的EHR系統可以通過利用同步工具來提供對於系統物件總集的版本管理，所述同步工具可以促進本發明的EHR系統的實例之間的系統物件定義的傳遞，比如開發和測試實例、訓練實例以及主要操作實例之間的傳遞。在一個實施例中，同步工具可以利用識別系統物件的各個版本的方法，從而可以把同步發生時的歧義降到最低程度。舉例來說，同步工具可以識別不同的版本，並且為用戶給出例如單獨地、全體地或者分批地把系統物件的更新後的版本從一個實例拷貝到另一個實例的選項。

在其他實施例中，本發明的EHR系統可以通過利用標準軟體發展源控制實踐來提供對於系統物件總集的版本管理，所述實踐通常可以把每一個系統物件作為可以從源控制儲存庫檢出和更新的原始檔案來對待。舉例來說，本發明的EHR系統例如對於系統物件的原始檔案可以利用git儲存庫。源控制通常例如可以允許更大的人員集合同時工作於更新，並且/或者以更加系統性的方式管理由每個人引入的改變。作為另外的實例，標準軟體發展源控制實踐還可以採用廣為接受的用於備份和保持存儲庫的最佳實踐，比如git，其可以被實施來保護由機構所利用的系統物件。

在一些示例性實施例中，本發明的EHR系統還可以包括能夠從設備上的使用者介面直接訪問的用於修改和/或客製系統物件的特徵件。這可能是符合期望的，因為本發明的EHR系統的表單、範本和/或其他系統物件元件可以被即時修改和/或客製，而不是完全依賴於存在延時的開發和/或客製。舉例來說，客製因此可以在現場發生以及/或者在使用本發明的EHR系統的過程中發生，而不是等待很長的開發/更新週 期才能發生。在一些實施例中，可以直接從本發明的EHR系統的使用者介面內利用YAML句法的子集來創建和/或編輯系統物件。

在本發明的另一個方面中，本發明的EHR系統可以利用工作流程來促進和/或實施使用者集合對於文檔的檢視和/或許可。

在一些實施例中，可以利用工作隊列並且其可以包括已被張貼以供接收方使用、檢視和/或許可的文檔清單，其方式類似於電子郵件系統的收件箱。一般來說，本發明的EHR系統可以為每一個使用者提供工作隊列，並且/或者為每一個用戶群組提供單個工作隊列。EHR系統使用者介面還可以包括儀錶盤(dashboard)，其中用戶可以查看已被張貼到其自身的工作隊列以及/或者其所屬的任何群組的工作隊列的文檔列表。

一般來說，把文檔張貼到工作隊列不會將其從本發明的EHR系統中的任何其他位置處移除(比如從患者記錄和/或其他可訪問的位置移除)，相反工作隊列可以僅包含到已被張貼到其中的文檔的連結。作為另外的實例，當文檔被從工作隊列中移除時，一般可以僅從佇列中刪除連結，底層文檔則不受影響或者不被刪除。通過這種方式，本發明的EHR系統可以利用電子系統，比如利用文檔檢入和檢出特徵，其可以允許本發明的EHR系統把底層文檔保留在中央存儲中，同時允許其被連結、可見和/或通過其他方式從本發明的EHR系統的各個部分訪問而不會產生矛盾。

在一些實施例中，工作隊列和/或工作流程中的文檔例如在所述文檔可以在工作流程中前進之前可能需要由特定使用者檢視和/或許可。在一個實施例中，工作流程中的文檔可以由適當的使用者簽名以便繼續工作流程。在一個實施例中，如果收集到來自所有必要用戶和/或參 與方的簽名，則可以說文檔已完成其工作流程。可以基於工作流程步驟來確定必要使用者和/或參與方的列表。

一般來說，簽名可以是數位簽章或人工簽名。例如可以通過使用公共/私有金鑰對來創建數位簽章，所述金鑰對可以在每一個用戶第一次對表單簽名時為他/她生成並且還可以受到口令或其他加密金鑰的保護，所述口令或其他加密金鑰可以被用作該用戶的簽名口令。本發明的EHR系統中的數位簽章例如可以使用在表單上對於用戶可見的HSD(比如JSON)屬性值的散列，這對於允許稽核員確認簽名是真實的以及/或者簽名對應於簽名時顯示在螢幕上的資料來說可能是符合期望的。

還可以利用人工簽名，所述人工簽名可以實質上是通常可以採取傳統手寫簽名的形式的人類可讀證據，還可以在本發明的EHR系統的使用者介面中為其給出視覺表示。人工簽名例如可以被存儲在文檔的屬性中，所述屬性被利用用於文檔的範本的屬性向工作流程系統聲明。不同於數位簽章，人工簽名通常不可由EHR系統本身認證，因此EHR系統例如可以要求使用者證明人工簽名是代表經過授權的提交者正確地捕獲的，以作為例如可稽核性的一部分。

工作流程中的文檔提交者通常可以是發起特定工作流程處理的使用者；但是所述提交者可以不一定是在工作流程中的某一步驟結束時提交文檔的同一人。舉例來說，許多機構允許電話指示單以及/或者通過傳真或者其他基於紙張的手段接收到的指示單，因此提交文檔的人可能是在代表文檔的實際提交者採取行動，所述實際提交者例如是醫師，其在指示單的情況下可能是被授權合法地提交指示單的唯一用戶類型。

在一些實施例中，可以在本發明的EHR系統中限制工作流程 中的提交，從而使得僅有經過授權的和/或正確的用戶可以進行提交。舉例來說，如果用戶不屬於在本發明的EHR系統中規定的其中一個使用者類別，則EHR系統可以提示使用者表明正在代表哪一個用戶提交表單和/或其他工作流程專案。通過這種方式，例如使用者可以輸入電話、傳真和/或其他遠端指示單，其可以使得本發明的EHR系統如同經過授權的使用者已經簽名的情況那樣開始工作流程，並且/或者還並行地(也就是說不妨礙正常工作流程)把文檔放置到經過授權的使用者的佇列中以進行最終簽核。在使用人工簽名的實施例中，EHR系統可以例如基於實際輸入提交的用戶的公共/私有金鑰對來創建數位簽章，同時還合併實際代表其進行提交的使用者的標識資訊。

一般來說，工作流程的各個步驟可以規定簽名和/或其他授權將被收集的順序。步驟可以規定表明完成步驟可能所需要的簽名種類的特定用戶和/或用戶群組。舉例來說，如果步驟規定特定使用者，那麼如果文檔已經收集了該用戶的簽名，則認為該步驟完成。作為另外的實例，對於規定使用者群組的步驟，來自該群組中的任何用戶的簽名可能就是足夠的。因此，在工作流程中進行提交時，本發明的EHR系統可以順序地檢查各個工作流程步驟，以便找到尚未完成的第一個步驟。該步驟的特定使用者和/或用戶群組還可以決定將把文檔放置到其中的特定工作隊列。從而當所有步驟都完成時，可以把文檔放置在例如可以通過文檔的範本定義的已完成佇列中。還可以把附注合併到工作流程的各個步驟中，以便例如允許使用者隨著工作流程的進展作出注釋和/或評注。可以通過範本把附注小部件包括在表單中，從而使得可以很容易地從EHR系統的使用者介面添加附注。

此外，在本發明中，電子健康記錄不僅是供單個機構使用而 且還供多個機構使用，並且可能的用戶不僅是健康護理專業人員而且還有患者或者例如監護人之類的患者代表人。前面描述的客製能力還可以被利用來提供對於健康記錄表單的簡化和/或唯讀訪問。此外，可以基於通過患者自身的可擕式設備捕獲的健康資料自動填寫或者自動創建健康記錄表單，比如心率、鍛煉樣式、體重等等。因此患者受益於能夠看到所有其健康資料，而不僅僅是可以被拷貝到現有技術的(可能是不可客製的)個人健康記錄(PHR)系統的健康資料，並且如果需要患者同意來實施特定動作的話(比如通過網際網路把資訊傳送到其他提供商)，患者還可以成為工作流程許可處理的一部分。從主記錄暴露以及/或者從個人設備捕獲的個人健康資料都可以通過駐留在至少一台電腦伺服器上的系統物件來配置，因此不需要用於每一種客製配置的移動設備/伺服器軟體的不同版本。

正如前面所提到的那樣，還可以把來自多個機構的健康護理專業人員包括在可能用戶的列表中。舉例來說，有可能在大得多的計畫中使用EHR，其中涵蓋醫院/診所的系統，或者甚至整個保險人口(這在例如“人口健康”或“當責護理組織”的名稱下是已知的)。由於可以在細微性層級進行客製，因此不同診所中的醫生可能具有不同的需求，但是利用在每位醫生、每個診所/機構或者每項政策的層級客製的表單和處理，不同診所中的醫生可以共用相同的電子健康記錄系統而都不需要移動設備/伺服器軟體的專門版本。後端電腦伺服器的可縮放性質使得有可能支援數量極大的用戶。這種方法的好處在於，患者能夠從多家提供商獲得護理，而在過去由於不相容的系統，所述提供商將必須使用傳真機或快遞來交換健康記錄表單的列印版本。利用本發明的方法，這些提供商正在使用考慮到相同環境內的表單佈局中的差異的系統。

此外，本發明包括消息傳送以作為用於健康護理表單的應用列表當中的一項。表單機制可以允許支援患者以及健康護理專業人員之間的雙向或n向消息傳送。

在其他行業中，本發明類似地涉及用於在高度可縮放和可客製的軟體和硬體架構上管理其對應的相關資訊的系統和方法，所述架構例如可操作在包括可擕式設備的設備上，並且操作為在升級和縮放期間具有最少停機時間。本發明還涉及高效地訪問和客製例如用於以電子形式生成和管理資訊的表單的系統和方法。前面所提到的適用於健康護理的所有實施例和方面同樣適用於這些其他行業。

例如在顧客關係管理中，取代患者的是顧客；並且取代健康記錄表單的是顧客交互的記錄。在人力資源中，取代患者的是雇員；並且取代健康記錄表單的是例如表現評估、福利選擇(benefit election)等等。在會計中，取代患者的是收款人/銷售商/供應商；並且取代健康記錄表單的是用於可以被記錄的不同交易類型的表單。在專案管理中，取代患者的是專案；並且取代健康記錄表單的是用於將要完成的任務、工作指派以及來自利益相關者(stakeholder)的回饋的表單。在現場志願者的領域(例如政治運動)中，取代患者的是潛在的選民；並且取代健康記錄表單的是用於將要記錄的不同政治議題的表單。

通過後面對於如在附圖中示出的本發明的實施例的詳細描述，可以最佳地理解本發明以及前述和其他優點。

100‧‧‧儀錶盤視圖

102‧‧‧使用者登錄指示標

103‧‧‧退出登錄按鈕

104‧‧‧患者指示標

110‧‧‧導覽欄

111‧‧‧按鈕

112‧‧‧按鈕

113‧‧‧按鈕

114‧‧‧按鈕

116‧‧‧按鈕

118‧‧‧預約排程按鈕

120‧‧‧患者列表

120'‧‧‧活躍患者清單

121‧‧‧患者列表

121'‧‧‧患者

130‧‧‧預約排程

130'‧‧‧規程列表

131

140‧‧‧條碼掃描器

150‧‧‧管理員控制項

414‧‧‧報告連結

420‧‧‧文檔

422‧‧‧照片小部件

424‧‧‧標籤小部件

426‧‧‧顯示生命體征記錄的小部件

428‧‧‧顯示心率/脈搏的小部件

500‧‧‧表單

502‧‧‧文本欄位元

503‧‧‧文本

504‧‧‧選項巨集集合

505‧‧‧選項

600‧‧‧TOC子層級

600'‧‧‧TOC子層級

610‧‧‧TOC子層級項

610'‧‧‧TOC子層級項

612‧‧‧返回按鈕

612'‧‧‧返回按鈕

620‧‧‧選項

620'‧‧‧選項

700‧‧‧系統物件編輯器

160‧‧‧許可佇列

200‧‧‧工作隊列視圖

210‧‧‧列表

211

220‧‧‧所選專案

222‧‧‧控制項

224‧‧‧簽名

226‧‧‧附注

300‧‧‧預約排程

400‧‧‧患者的報告

410‧‧‧TOC

411‧‧‧命令按鈕

413‧‧‧表單連結

710‧‧‧系統物件清單

711‧‧‧系統物件

720‧‧‧編輯小部件

721‧‧‧系統物件定義

730‧‧‧特定的句法按鈕

800‧‧‧表單

801‧‧‧簡單文本內容

802‧‧‧詞彙表搜索小部件

804‧‧‧單項選擇小部件

806‧‧‧日期輸入小部件

808‧‧‧二元小部件

502a‧‧‧按鈕

504a‧‧‧選項巨集集合

圖1和1a示出了本發明的EHR系統的使用者介面的儀錶盤視圖。

圖2示出了本發明的EHR系統的使用者介面的工作隊列視圖。

圖3示出了本發明的EHR系統的使用者介面的視圖中的預約和排程小部件的集合。

圖4和4a示出了本發明的EHR系統的使用者介面的視圖中的患者資訊小部件和TOC的集合。

圖5和5a示出了表單中的小部件的特定輸入欄位中的自動填寫行為。

圖6和6a示出了本發明的EHR系統的使用者介面中的TOC子層級行為。

圖7和7a示出了可以從本發明的EHR系統的使用者介面訪問的系統物件編輯器。

圖8示出了本發明的EHR系統的視圖中的具有多種小部件的表單的實例。

下面闡述的詳細描述意圖作為關於根據本發明的各個方面提供的當前例示的系統、設備、方法和材料的描述，並且不意圖表示可以在其中實踐或利用本發明的僅有的形式。但是應當理解的是，通過同樣意圖被涵蓋在本發明的精神和範圍內的不同實施例可以實現相同的或等效的功能和元件。

除非另行定義，否則這裡所使用的所有技術和科學術語都具有與本發明所屬領域的普通技術人員通常所理解的相同含義。雖然在本發明的實踐或測試中可以使用與這裡所描述的類似或等效的任何系統、方法、設備和材料，但是現在將描述所例示的系統、方法、設備和材料。

這裡出現在說明書或附圖中的人名意圖是完全虛構的，並且 不表示任何在世或去世的真人。對於真人的姓名或特性的任何相似性都是完全非刻意的、巧合的、意圖明顯是虛構的並且/或者僅僅用於說明性目的。這裡的內容都不應當構成或者被解釋成專業意見或處理。

正如前面所提到的那樣，針對醫療專業人員群組將任何EHR帶上線的其中一項最大的開銷就是在系統內實施機構的現有工作流程和處理所花費的時間。雖然大多數機構共用會面、患者帳戶、指示單、實驗室結果以及協議的相同基本概念，但是將這些概念縫合在一起以便從住院到出院驅動患者護理的確切方式對於不同的醫院可以顯著不同。常常採取逐步處理來識別和區分機構的不同工作流程和處理之間的相互聯繫。為了持續這一過程，EHR系統需要適應對於系統組態的小的、漸進的、潛在地頻繁的改變，以便“正確實施(get it right)”。與這一需求相矛盾的是，系統的表單、工作流程和其他方面的定義有時被硬編碼到EHR本身中，從而需要分配具有高度技術水準的開發人員的時間來實施。一旦機構客製開始涉及底層EHR產品中的改變，頻繁漸進改變的想法就可能變得不切實際。對於需要停機時間來實現任何改變或升級的EHR特別是如此。

先前的生成系統還常常被設計成在單個伺服器上運行。當所述單個伺服器變得超負荷時，解決方案常常是用更大、能力更強的伺服器來替換該伺服器。通過想盡一切辦法使得該單個伺服器不發生故障並且具有備用的相同的備份伺服器實現了高可用性。最後，通過對於伺服器安排停用日程、升級軟體以及盡可能快地進行發煙測試(smoke test)來實施升級，以便最小化停機時間。

本發明涉及用於通過電子方式輸入資訊並且把此類資訊存儲在多台伺服器(其中可以包括雲端伺服器)上的系統和方法，以便易於 訪問、管理、共用和組織此類資訊並且在縮放和升級期間具有最少停機時間。不同於現有的系統，本發明被設計成在多台伺服器上運行，並且在這些伺服器上均勻地分配工作負荷。由於每一層應用包括基本上相同地配置的工作節點，因此各個單獨的節點可以發生故障並且/或者被取下以進行維護和升級，同時最低程度地影響總體系統的可用性。為了支援數量更大的使用者或記錄，簡單地把更多伺服器添加到這些共用集合。

除了用以在升級和縮放期間最小化停機時間的高度可縮放和可客製的軟體和硬體架構之外，本發明還強調了可擕式設備。

在本發明的一個方面中，本發明的電子健康記錄系統(EHR)(其也可以被稱作電子醫療記錄系統(EMR))可以被部署並且運行在多台伺服器上，可以按照非集中方式在所述多台伺服器上分配計算和/或存儲負荷，從而使得總體系統即使在被縮放、升級和/或通過其他方式修改時仍然可以保持運轉和操作。在一些示例性實施例中，本發明的EHR系統可以是軟體應用，其通常可以包括被部署並且運行在伺服器共用集合中的多台伺服器上的多個基本上相同地配置的工作節點。在本發明中，EHR系統可以在伺服器共用集合中的各台伺服器上分配其工作負荷和/或存儲負荷，例如在伺服器共用集合中的可用伺服器上基本上均勻地分配。由於EHR系統可以包括多個基本上相同地配置的工作節點，因此各個單獨的工作節點可以被取下、故障和/或被修改，而不會影響其他工作節點和/或嚴重影響EHR系統的總體可操作性。這可能是符合期望的，因為EHR系統運行任何健康護理設施的操作，並且在這樣的醫療環境中，訪問患者資訊的需求例如常常是時間敏感的並且對於適當的患者治療是至關重要的，因此一旦部署之後經歷最少停機時間或者沒有停機時間可以確保平滑的操作而不會有不必要的中斷。通過這種方式，例如 伺服器共用集合可以在幾乎任何給定時間添加附加的伺服器和/或取下伺服器以用於替換、升級、修復或其他用途以便修改由於伺服器修改而經歷停機時間的系統，從而最低程度地影響總體系統的可用性。

在一些實施例中，本發明的EHR系統可以被建立在高度自動化的安裝平臺上，其中系統的各個單獨的元件可以被包裝到分開的鏡像中，所述鏡像可以包括特定元件的配置。所述系統可以從鏡像創建並且運行元件的實例，同時把應當是永久性的任何所生成的資料與鏡像分開存儲在永久性存儲中。因此，所述系統可以任意地創建和丟棄元件的實例，而既不會丟失存儲在鏡像中的配置資訊，也不會丟失存儲在永久性存儲中的永久性資料。分開的EHR系統元件於是可以被取下以用於升級、修復和/或其他修改而不會影響其他組件。

在一個實施例中，本發明的EHR系統可以被建立在自動化安裝平臺上，例如“Dockcr”。“Docker”通常可以利用Linux Container(Linux容器)，一種建立到Linux中的比傳統虛擬化方法更加輕量型的技術。本發明的EHR系統的元件隨後可以被包裝到“Docker”鏡像中。隨後可以在“Docker”內啟動鏡像，以便產生元件的運行實例。在傳統的環境中，例如這些實例可以類似於運行在中介軟體以及在配置方面需要為之投入大量時間和能量的其他元件的堆疊上的已安裝的軟體。與此相對，該實施例中的EHR元件的實例通常可以易於創建，並且例如可以在希望或者必須對EHR系統進行修復、升級和/或修改時丟棄。“Docker”通常還可以允許把用於每一個元件的配置資料(其可以被存儲在“Docker”鏡像中)與永久性資料(其可以被存儲在永久性存儲中)分開。因此可以在任何時間處理每一個元件的實例，這是因為例如在任何時間都可以例如通過基於相同的原始鏡像啟動新的實例來重新創建所述實例的配置，同時由 所述實例管理的永久性資料不被存儲在實例本身中而是被存儲在例如後端之類的永久性存儲中，比如網路附屬存儲(NAS)。

在一些實施例中，永久性資料可以利用可縮放後端資料庫系統來存儲，所述資料庫系統通常可以利用非關聯式資料庫結構，但是也可以利用分立文檔為中心的結構，所述結構還可以利用伺服器或存儲共用集合上的可縮放性、文檔複製和/或負荷分配。作為另外的實例，所述資料庫系統還可以利用文檔檢出系統，其中文檔對所有被允許的用戶都保持可查看，但是每次只有一個用戶可以通過將其檢出資料庫來修改文檔。這對於例如防止可能引入相矛盾的資訊的文檔的同時修改可能是合乎期望的。這在健康護理領域中是特別合乎期望的，其中相矛盾的資訊可能是生死攸關的。

在一個示例性實施例中，所述可縮放後端資料庫系統可以採用NoSQL資料庫，例如“MongoDB”。一些資料庫(比如“MongoDB”)可以特別被設計成按照可縮放的方式管理和存儲數量極大的HSD文檔(比如JSON文檔)。

在本發明的另一個方面中，EHR系統可以被設計成幾乎完全從可擕式或移動設備進行主要的訪問、保持和利用，其中只有特定功能需要直接訪問伺服器和/或固定式電腦。這不同於一般大多數的EHR系統，後者被設計成用於固定式電腦，其中任何移動訪問或功能都是後來的考慮。這總體反映了用以保持健康記錄的更加傳統或者過時的方式，其更加類似於沒有大量利用允許用以保持資訊的不同方式的任何技術進步的紙張和檔案室系統。在這方面，本發明的EHR系統通常可以在與患者接觸時以及/或者在需要輸入和/或取回資訊的實際事件期間被立即利用，而不是在事後利用。這例如可以說明提高效率和/或資訊保真度，這 是因為事後記錄保存由於後來無法訪問資訊來源而可能會固有地引入錯誤和/或不完整性。

一般來說，在醫療領域中可當責性和可稽核性是重要的概念。由於作出明智的臨床決定非常依賴於準確的患者記錄，因此本發明的EHR系統可以被設計成例如通過日期、時間、用戶和/或任何其他適當的方式來跟蹤對於患者記錄所發生的所有改變。EHR系統通常還可以把過去文檔版本的全部和/或所期望的選擇部分存儲在資料庫中以便於稽核。EHR系統的使用者還可以通過使用在EHR系統中可用的檢入和檢出動作來促進可稽核性，這是因為這些動作通常例如還可以防止多個用戶對任何給定文檔作出潛在地相矛盾的修改。

在一些實施例中，本發明的EHR系統的所有主要使用者可以利用可擕式或移動設備來進行其對EHR系統的訪問和利用。在一個實施例中，通常可以利用iPad®、Android®、Windows®平板設備和/或其他類似的平板計算設備。一般來說，可能希望從受歡迎的、普及的和/或熟悉的計算平臺利用本發明的EHR系統，因為這樣例如可以允許用戶專注於其實際的任務而不是嘗試搞清楚不熟悉的和/或過於複雜的軟體介面。此外，受歡迎的和/或普及的計算平臺通常可以受益於勤勉的技術支持、問題熟悉性、更新以及/或者替換的可用性。本發明的EHR系統通常可以被利用在任何適當的設備上，其中可以包括而不限於智慧型電話、平板電腦、個人電腦以及/或者任何其他適當的計算設備。一般來說，本發明的EHR系統可以採用圖形化使用者介面(GUI)，並且取決於設備，所述圖形化使用者介面可以通過任何可能是適當的觸控式螢幕介面和/或鍵盤/滑鼠介面來訪問。本發明的EHR系統還可以採用其他形式的介面，比如針對存在視覺和/或聽覺缺陷的用戶的使用所設計的介面，以及 /或者替換的介面，其中例如可以包括語音辨識和/或重放、Braille電腦介面、觸覺介面以及/或者任何其他適當的介面。

在本發明的另一個方面中，本發明的EHR系統可以利用高度可客製的架構，其通常可以允許對EHR系統進行客製以適應(多個)用戶的任何特定需求，而無需對EHR系統的底層功能和/或設計作出任何重大改變。在一些示例性實施例中，本發明的EHR系統架構可以基於使得系統的大多數方面的配置以系統物件的形式暴露於管理員，其中例如包括而不限於向表單添加欄位以創建用於應對實驗室指示單的新的工作流程之類的改變都可以在不改變本發明的底層EHR系統的情況下實現。系統物件通常可以利用YAML句法來定義並且例如可以作為HSD文檔(比如JavaScript物件標記(JSON)文檔)存在，其方式類似於由EHR系統管理的所有其他文檔(比如患者記錄)。

對於大多數現有的EHR存在一個共同的問題：表單和處理需要客製以滿足各個單獨的機構(例如醫院)的需求。為了解決這一問題，這些EHR當中的大多數採用代碼中的硬編碼表單和處理定義，這需要附加的時間和技術水準更高的開發人員來創建產品的多個客製版本。這意味著或者需要創建電子健康記錄系統軟體的多個版本並且存儲在至少一台伺服器上；或者技術水準更高的開發人員可能要花時間來創建即席(ad hoc)客製版本，從而妨礙機構的操作。此外，當多個機構希望具有針對其電子健康記錄系統的不同客製時，如果沒有事先創建設備和/或伺服器軟體的多個版本，則針對技術水準更高的開發人員和時間的這些需求可能會倍增。

通過利用按照標準化句法或格式存儲資料的文檔(比如JSON文檔之類的HSD文檔)的靈活性以及比如JSON文檔之類的HSD文檔 在前面提到的任何適當設備上被動態處理的獨有方式，本發明解決了前面提到的缺陷並且在需要即席定製表單時消除了對於技術水準更高的開發人員的需求，而無需創建電子健康記錄系統軟體的多個版本。舉例來說，可以把健康記錄作為一系列HSD文檔(比如JSON文檔)存儲在至少一台電腦伺服器上。

本發明可以利用表單引擎，其例如可以從作為設定檔提供給產品的表單定義進行工作。通過這種方式，只需要較低的技術水準來客製用於特定醫院的EHR，並且可以在設定檔中定義定製錶單和處理，所述設定檔可以被更新而不需要基礎產品的客製版本。

舉例來說，所述表單引擎可以如下工作：當要在EHR中向使用者顯示文檔時，表單引擎從資料庫取回文檔。文檔可以在HSD(比如JSON)格式中被編碼成一系列關鍵字-值對。其中一個關鍵字-值對可以表明文檔所基於的表單範本。EHR隨後可以從資料庫取回表單範本，所述表單範本本身也可以在HSD(比如JSON)格式中被規定為一系列關鍵字-值對。表單範本規定可以在螢幕上顯示哪些欄位元(例如針對性別或年齡的欄位)，使用何種“小部件”捕獲來自用戶的輸入(例如選擇小部件或者用於查找代碼的搜索小部件)，以及如何把使用者輸入的值存儲在文檔中(通常在HSD文檔(比如JSON文檔)中給出針對關鍵字-值對的“關鍵字”名稱)。在最後的步驟中，EHR的表單引擎可以每次一個小部件地在使用者設備(比如iPad)的螢幕上依次創建實際的表單呈現，從而反映出當時的最新客製，並且隨後利用來自文檔的資料填充所述小部件。

除了更加高效以及節省時間之外，本發明還不同於普通紙質表單或者其他應用中的表單。首先，表單沒有被硬編碼，因此可以只需 要配置改變來更新/定製表單。對於實施改變的人員不需要開發方面的技術，並且不需要生產產品的新版本以及/或者列印和/或提交主表單。此外，由於表單沒有被硬編碼，因此在iPad上向使用者顯示出的確切呈現可以由表單引擎在執行時間優化。舉例來說，對於硬編碼的表單，例如字體以及在螢幕上的定位之類的佈局特性是明確地設定的。對於本發明，利用表單引擎，可以根據螢幕上的可用空間使用一項抽象表單佈局規範在風景模式、人像模式下以及甚至對於web流覽器中的使用為使用者設備(比如iPad)產生表單使用者介面。此外，表單輸入螢幕總是反映出由系統管理員準備的最新版本。將不對iPad、伺服器或者(在許多情況下)甚至已經利用表單的早前版本填寫的資料進行升級。這與紙質表單明顯不同，其中對於表單範本本身的更新將不會傳播回已經被填寫的表單的拷貝。此外，更容易在每個表單的基礎上控制版本處理。舉例來說，有可能使得多個機構共用表單範本並且知曉各個單獨的表單範本被更新的日期。給定的醫院可以選擇轉出新的人口統計資訊表單，同時延遲轉出被用來捕獲重要器官(vital)的表單。這在具有硬編碼表單的系統中可能是無法實現的並且明顯與之不同，在具有硬編碼表單的系統中，不同表單範本版本的每一種排列都需要產品本身的不同版本，其組合的激增可能導致EHR銷售商無法跟蹤以及保持最新的無法管理的版本數量。因此，除了不需要具有高度技術水準的開發人員之外，本發明不僅進一步簡化了處理，而且還使得將要跟蹤的版本數目最小化，從而最小化發生混淆的幾率並且節省時間和工作量。

在本發明的另一個方面中，本發明的EHR系統可以被高效地並且容易地客製以便安裝在工作地點處，例如醫院、醫生辦公室和/或其他健康護理機構，而不需要對於EHR系統的大量“後端”客製以實現能夠 工作的實現方式。一般來說，針對醫療專業人員群組將EHR帶上線的其中一項最大的開銷就是在系統內實施機構的現有工作流程和處理所花費的時間。雖然大多數機構共用會面、患者帳戶、指示單、實驗室結果、協議和/或其他相同的基本概念，但是將這些概念縫合在一起以便從住院到出院驅動患者護理的確切方式對於不同的機構可以大為不同。在許多情況下，在典型的EHR實施期間使用逐步處理，以便識別和區分機構的不同工作流程和處理之間的相互聯繫。有效的EHR系統通常被設計成適應對於系統組態的小的、漸進的、潛在地頻繁的改變，以便適當地實施EHR系統從而使其將與機構一起工作。系統的表單、工作流程以及其他方面的定義有時常常被硬編碼到EHR本身中，由於所需的改變是在“後端”進行的，因此這常常需要分配具有高度技術水準的開發人員的時間來實施。此外一般來說，一旦機構客製開始涉及底層EHR產品中的改變，頻繁漸進改變的想法可能就變得不切實際。

在一些示例性實施例中，本發明的EHR系統可以基於使得系統的大多數方面的配置以系統物件的形式暴露於管理員，所述系統物件例如可以利用YAML句法來定義，並且例如作為HSD文檔(比如JSON文檔)存在於系統中，正如前面所討論的那樣。通過這種方式，可以在無需改動底層EHR系統“後端”的情況下實現對於EHR系統的所暴露出的“前端”的各種改變和/或修改。改變和/或修改可以包括而不限於修改表單、創建新的工作流程、客製報告、創建和/或修改資訊輸入和/或顯示特徵件以及/或者任何其他適當的改變或修改。

在一些實施例中，本發明的EHR系統可以採用例如範本之類的基本系統物件，其可以定義如何向使用者呈現資訊和/或資訊的總集，比如在表單之類的視覺表示中呈現，以及/或者如何在EHR系統中結構 化和/或記錄所輸入的資訊。

在一些實施例中，範本可以被用來作為表單向使用者顯示和/或組織一系列單獨的資訊呈現和/或收集元件，所述表單在視覺上可以類似於在健康護理環境中通常所採用的電子和/或紙質表單。舉例來說，各個單獨的資訊呈現和/或收集元件可以是表單小部件(例如HTML小部件)，其隨後可以被使用者利用作為設備上的介面以用於輸入和/或取回資訊。表單小部件本身可以被嵌入到正顯示在本發明的EHR系統的使用者介面上的表單和/或報告中。資訊和資訊結構隨後可以被存儲在本發明的EHR系統的永久性存儲中的HSD文檔(例如JSON文檔)內。

圖1和1a示出了本發明的一些實施例中的針對使用者的EHR系統的儀錶盤視圖100的實例。EHR系統使用者介面通常可以利用使用者登錄指示標102表明哪一個用戶已登錄(如果有的話)，並且通常還可以提供退出登錄按鈕103。在EHR系統使用者介面中顯示的資訊通常可以安排在各列中，其可以針對用戶的優選項以及/或者針對任務和/或情況的具體需求而被客製，比如通過圖1中的列A、B和C所示出的那樣。

多種小部件可以被利用來例如簡化對於不同種類的資訊的收集，其中可以包括而不限於文本輸入、日期和時間、血壓讀數、基於標準詞彙表的代碼、從設備取得的圖片和/或照片以及/或者任何其他適當的小部件。小部件還可以被劃分成各個節段和表以便於導覽。在從使用者收集資料時，可以通過小部件記錄用於資訊的值，其可以進一步被記錄在通過範本定義的關鍵字之下，並且被放置到HSD文檔(例如JSON文檔)中。通過這種方式，表單的使用者介面可以被利用來按照所利用的範本呈現底層HSD文檔(例如JSON文檔)，以便由用戶按照用戶友 好的管理員定義的方式進行檢查和修改。

在一些實施例中，如圖1中所示，儀錶盤視圖100例如可以包含多種小部件，其可以通過控制儀錶盤視圖100的範本來定義。如圖所示，作為另外的實例，小部件可以包括用於示出EHR系統的不同視圖的導覽欄110，比如在儀錶盤視圖100中示出的總覽視圖，通過按鈕112示出使用者的工作隊列視圖，通過按鈕114示出報告，通過按鈕116示出檢出文檔並且通過按鈕118示出預約，用戶可訪問和/或被指派的患者列表121(比如在患者列表120中)，預約排程130，以及/或者其他適當的小部件，作為另外的實例比如有條碼掃描器140和管理員控制項150。如圖所示，圖1a示出了具有替換的安排以及不同的小部件和控制項的實例的儀錶盤視圖100，正如通過導覽欄110所示出的那樣，其中具有用於特定專業人員(例如醫師)、總覽視圖以及檢出文檔的按鈕111、113、116，即將到來的規程列表130’，具有患者121’的活躍患者清單120’，以及許可佇列160。

圖3示出了可以從預約排程按鈕118訪問的EHR系統中的預約排程300的視圖。預約排程300可以包括用於顯示現有預約的小部件並且/或者允許將預約輸入/修改到用戶的日曆中。

在一些實施例中，巨集集合可以被用來規定當在使用者介面中操縱資訊時出現在本發明的EHR系統中的巨集集合。舉例來說，當按下巨集按鈕時，對應於該巨集按鈕的文本可以被插入到活躍文本欄位元中。所述文本可以由定義在巨集集合中的腳本動態地生成，所述巨集集合在由移動設備運行時從至少一台電腦伺服器獲得潛在地情境相關資料，比如患者的過敏症或人口統計資訊，以便包括在所插入的文本中。巨集集合的目標可以被設定在表單上的特定欄位、特定用戶和/或特定群組。 通過這種方式，需要快速鍵入常用的文本片斷和/或其他資訊的使用者可以具有被客製成適合其需求的介面，從而可以允許其更加高效地輸入資訊。文本欄位元和/或其他輸入項還可以包括標準詞彙表集合和/或預設選項，其還可以是可搜索的。

圖5示出了顯示選項巨集集合504的表單500中的文本欄位元502的實例，其中在一些文本503的初始輸入之後具有可插入項的選項505。圖5a示出了表單500中的按鈕502a的實例，其在按鈕502a被按下時顯示選項巨集集合504a，而不是需要一些資訊輸入(比如圖5中的文本503)。

一般來說，當EHR系統中的任何給定記錄(比如患者記錄)隨著時間增長時，特定資訊項可能會不可避免地被反復收集，比如過敏症和當前用藥。舉例來說，可能存在臨床和/或可稽核性要求，其可能要求多次收集資訊，從而可能導致最新的資訊潛在地被分散在多個文檔中。舉例來說，患者可能在一次會面期間聲明特定過敏症，但是在下一次會面中則忘記提起。

在一些示例性實施例中，本發明的EHR系統可以提供調和能力，以便允許將收集自多個文檔上的相同和/或相關的表單範本的資訊一起呈現，並且允許用戶選擇保留哪些(如果有的話)重複的和/或相矛盾的條目以及丟棄哪些條目。不同於紙質記錄，EHR系統中的資訊可以由EHR系統結構化和/或可識別，比如通過前面所討論的關鍵文書處理，從而使得搜索可以允許很容易聚集相同和/或相關的資訊，而不是像紙質記錄那樣，使用者必須人工篩檢所有適用的表單以取回資訊。此外，在紙質記錄中，可能無法像EHR系統那樣很容易地把資訊從分散的紙質文檔中拉取到單個文檔上，或者當匆忙檢視或時間緊迫時，在檢視紙質文檔 的過程中可能會錯失資訊。

此外，不同於紙質文檔，其中用於組織和/或重新組織的僅有手段通常是對頁面重新排序、插入封面/分隔頁面以及/或者附著帶狀標誌等等，電子記錄通常可以被基本上暫態地重新整理，以便滿足當時正在進行的工作的需求。舉例來說，實驗室技術人員感興趣的患者記錄中的文檔子集可能在某種程度上不同於例如辦理患者住院的接待員所感興趣的子集。在紙質表單中，除了按照不同順序具有相同記錄的多份拷貝之外，無法對於一個用戶按照不同於另一個使用者的方式重新組織頁面，這在患者護理中可能會導致問題，本發明則允許一個用戶群組(例如實驗室技術人員)感興趣的患者記錄中的文檔子集可以在某種程度上不同於例如辦理患者住院的接待員所感興趣的子集。

在本發明的一個示例性方面中，本發明的EHR系統可以利用內容表(TOC)系統物件來定義用於患者記錄中的文檔的動態組織。在一些實施例中，可以通過TOC把文檔動態地組織到樹結構中，所述樹結構可以類似於大多數臺式電腦使用者所熟悉的標準“資料夾範例”。舉例來說，不同於紙質書之類的內容表，本發明的EHR系統能夠利用可以不是靜態的TOC定義，從而可以例如基於情況需求和/或基於用戶的(多個)角色(例如醫生、實驗室技術人員等等)在每個用戶的基礎上對其進行適配。因此可以針對特定使用者和/或特定情況需求來客製TOC，以便提供用以導覽經過文檔中的資訊的高效和/或直觀的組織方案。此外，不同於常見的資料夾分級結構類型的檔案系統，EHR系統TOC可以作為導覽工具操作，而不是實際控制資訊本身被存儲在系統內的方式。

在一些實施例中，根部TOC層級可以定義呈現給使用者的選擇功能表。所述選擇功能表還可以包含文檔的混合，比如基本患者資訊 文檔、報告(例如“隨著時間的血壓(Blood Pressure Over Time)”)以及/或者到其他TOC層級的連結，其在外觀和/或用途方面可以類似於典型桌面應用中的子功能表。所述功能表通常可以被定義成針對本發明的EHR系統的資料庫的一系列查詢，並且所述查詢可以非常具體(例如“給我看患者唯一的基本患者資訊文檔(show the patient’s one and only Basic Patient Information document)”)、寬泛(例如“給我看該患者的所有放射圖像(show all radiology images for this patient)”)以及/或者具有任何介於中間的具體性。功能表通常還可以被劃分成多個節段以易於導覽，並且還可以包括可以允許添加新的文檔和/或組織層級的按鈕和/或其他控制特徵件。舉例來說，功能表可以包括列出用於特定患者的所有放射圖像的節段，並且按鈕和/或其他控制特徵件可以被配置成出現在該節段中以便為使用者給出添加資訊(例如新的圖像)的選項。

圖4和4a示出了EHR系統中的關於患者的報告400的視圖，其中例如可以包括顯示對於該患者可用的文檔分級結構的TOC 410，以及用於顯示來自文檔420的特定資訊的(多個)小部件，作為另外的實例比如有示出患者的圖片的照片小部件422以及具有用於患者的QR代碼的標籤小部件424。還可以利用其他小部件，比如HTML小部件，例如圖4a中所示的可以分別被利用來顯示生命體徵記錄和心率/脈搏的小部件426、428。在TOC內還可以訪問例如表單和報告之類的不同專案，如圖4a中所示的表單連結413和報告連結414。TOC還可以包含命令項，如命令按鈕411所示。圖8還示出了具有多種小部件的表單800的實例，比如簡單文本內容801，用於從所提供的選項清單中進行選擇的詞彙表搜索小部件802，用於從幾個選項按鈕當中進行選擇的單項選擇小部件804，日期輸入小部件806，以及二元(例如是/否)小部件808。還可以 顯示關於正在查看哪位元患者的指示標，比如患者指示標104。

在一些實例中，TOC層級可以包含到其他TOC層級的連結，從而使用者可以根據具體任務和/或情況選擇沿著不同的軸來查看文檔。圖4a示出了可以打開TOC子層級的嵌套TOC層級指示標412的實例。這種靈活性與紙質系統完全不同，在紙質系統中只能按照一種方式或另一種方式對物理紙張進行排序，並且對其重新排序是非常耗時的。舉例來說，通過在本發明的EHR系統中定義例如用於患者會面的TOC子層級並且把到患者的不同會面的連結放置在根部TOC層級中，門診醫師可以通過會面來查看關於患者所收集的資訊。與此同時，作為另外的實例還可以定義對應於記帳帳戶的不同TOC子層級，並且把到這些帳戶的連結放置在根部TOC層級中。這些連結隨後例如可以為會計部門的記帳專業人員提供到相同的患者記錄文檔中的不同視圖，所述視圖按照對於單個紙質文檔所不可能的方式更加適合於記帳專業人員的需求。

圖6示出了從圖4中的TOC 410訪問的TOC子層級600的實例。TOC子層級600可以基於TOC 410中的發源TOC項進一步顯示針對可能是有用的附加文檔/表單的連結，正如通過另外的TOC子層級項610和/或所選項620所示出的那樣。還可以包括返回按鈕612以便將使用者返回到更高的TOC層級。圖6a還可以顯示可以從圖6中的TOC子層級600訪問的TOC子層級600’以便顯示附加的文檔/表單，比如通過附加的另外的TOC子層級項610’和/或所選項620’所示出的那樣。類似地，還可以包括返回按鈕612’以便將使用者返回到更高的TOC層級。正如前面所討論的那樣，TOC層級和/或子層級通常可以顯示到文檔/表單的連結而不會影響文檔的底層存儲。

在本發明的另一個方面中，由本發明的EHR系統利用的系統 物件通常可以由機構按照類似於其他機構知識的方式來對待，並且因此可以被備份、版本處理、根據已定義的改變處理更新以及/或者在其他方面按照與受到管理的其他機構知識類似的方式來對待。

在一些示例性實施例中，系統物件通常可以定義關於使用者如何與其機構處的本發明的EHR系統進行交互的幾乎每一個方面。因此，系統物件的整個總集可以被備份、版本處理、根據已定義的改變處理更新等等。舉例來說，在EHR系統轉出的開頭，可以基於各種專案的通用定義的組合來產生初始版本，比如內容表、患者表單、針對患者住院的特定於機構的客製以及/或者實驗室處理。隨後可以按照多種方式引入系統物件總集的下一個版本和/或後續版本，以便最小化對於機構處的EHR系統的持續操作的干擾。可能希望在可以被專用於開發和測試的本發明的EHR系統的拷貝或實例上對這些系統物件實施更新，並且從而與正由機構使用的主要操作實例分開。因此，當設計工作和/或其他更新完成和/或被許可時，新的系統物件總集可以被拷貝到同樣可以與主要操作實例分開的本發明的EHR系統的訓練實例，以便在不影響機構處的本發明的EHR系統的主要操作實例的持續操作的情況下允許職員和/或其他用戶熟悉新的改變。在充分的訓練、調試和/或其他定型之後，所述系統物件總集隨後可以被推送到生產伺服器，從而使其可以在本發明的EHR系統的主要操作實例中成為機構中的主流使用的一部分。

在一些實施例中，本發明的EHR系統可以通過利用同步工具來提供對於系統物件總集的版本管理，所述同步工具可以促進本發明的EHR系統的實例之間的系統物件定義的傳遞，比如開發和測試實例、訓練實例以及主要操作實例之間的傳遞。在一個實施例中，同步工具可以利用識別系統物件的各個版本的方法，從而可以把同步發生時的歧義降 到最低程度。舉例來說，同步工具可以識別不同的版本，並且為用戶給出例如單獨地、全體地或者分批地把系統物件的更新後的版本從一個實例拷貝到另一個實例的選項。

在其他實施例中，本發明的EHR系統可以通過利用標準軟體發展源控制實踐來提供對於系統物件總集的版本管理，所述實踐通常可以把每一個系統物件作為可以從源控制儲存庫檢出和更新的原始檔案來對待。舉例來說，本發明的EHR系統例如對於系統物件的原始檔案可以利用git儲存庫。源控制通常例如可以允許更大的人員集合同時工作於更新，並且/或者以更加系統性的方式管理由每個人引入的改變。作為另外的實例，標準軟體發展源控制實踐還可以採用廣為接受的用於備份和保持存儲庫的最佳實踐，比如git，其可以被實施來保護由機構所利用的系統物件。

在一些示例性實施例中，本發明的EHR系統還可以包括能夠從設備上的使用者介面直接訪問的用於修改和/或客製系統物件的特徵件。這可能是符合期望的，因為本發明的EHR系統的表單、範本和/或其他系統物件元件可以被即時修改和/或客製，而不是完全依賴於存在延時的開發和/或客製。舉例來說，客製因此可以在現場發生以及或者在使用本發明的EHR系統的過程中發生，而不是等待很長的開發/更新週期才能發生。在一些實施例中，可以直接從本發明的EHR系統的使用者介面內利用YAML句法的子集來創建和/或編輯系統物件。

圖7和7a示出了可以從本發明的EHR系統的使用者介面訪問的系統物件編輯器700的實例，其作為另外的實例可以包括可供選擇以進行編輯的現有系統物件清單710，比如通過顯示在編輯小部件720中的所選系統物件711所示出的那樣。使用者隨後可以編輯定義，比如 通過系統物件定義721所示出的YAML句法，其中例如示出了用於圖7中的基本患者資訊範本的定義以及用於圖7a中的吸煙/酒精狀態範本的定義。還可以提供附加的編輯工具，比如特定的句法按鈕730。

在本發明的另一個方面中，本發明的EHR系統可以利用工作流程來促進和/或實施使用者集合對於文檔的檢視和/或許可。

在一些實施例中，可以利用工作隊列並且工作隊列可以包括已被張貼以供接收方使用、檢視和/或許可的文檔清單，其方式類似於電子郵件應用的收件箱。一般來說，本發明的EHR系統可以為每一個使用者提供工作隊列，並且/或者為每一個用戶群組提供單個工作隊列，正如通過圖1a中的許可佇列160所示出的那樣。EHR系統使用者介面還可以包括儀錶盤，其中用戶可以查看已被張貼到其自身的工作隊列以及/或者其所屬的任何群組的工作隊列的文檔列表。

圖2示出了可以從工作隊列按鈕112訪問的工作隊列視圖200。工作隊列視圖200通常可以顯示用於由使用者檢視和/或許可的項目的列表210，並且可以通過進行選擇來查看每一個單獨的項目，比如通過所選專案220所示出的那樣。如圖所示，所選項目220還可以包括附加的控制項222，比如用以提交指示單、查看工作流程中的指示單的狀態以及/或者顯示出附加選項的按鈕。

一般來說，把文檔張貼到工作隊列不會將其從本發明的EHR系統中的任何其他位置處移除(比如從患者記錄和/或其他可訪問的位置移除)，相反工作隊列可以僅包含到已被張貼到其中的文檔的連結。作為另外的實例，當文檔被從工作隊列中移除時，一般可以僅從佇列中刪除連結，底層文檔則不受影響或者不被刪除。通過這種方式，本發明的EHR系統可以利用電子系統，比如利用文檔檢入和檢出特徵，其可以允 許本發明的EHR系統把底層文檔保留在中央存儲中，同時允許其被連結、可見和/或通過其他方式從本發明的EHR系統的各個部分訪問而不會產生矛盾。

在一些實施例中，工作隊列和/或工作流程中的文檔例如在所述文檔可以在工作流程中前進之前可能需要由特定使用者檢視和/或許可。在一個實施例中，工作流程中的文檔可以由適當的使用者簽名以便繼續工作流程。在一個實施例中，如果收集到來自所有必要用戶和/或參與方的簽名，則可以說文檔已完成其工作流程。可以基於工作流程步驟來確定必要使用者和/或參與方的列表。圖2示出了針對工作流程專案220中的指示單的必要簽名224的顯示。

一般來說，簽名可以是數位簽章或人工簽名。例如可以通過使用公共/私有金鑰對來創建數位簽章，所述金鑰對可以在每一個用戶第一次對表單簽名時為他/她生成並且還可以受到口令或其他加密金鑰的保護，所述口令或其他加密金鑰可以被用作該用戶的簽名口令。本發明的EHR系統中的數位簽章例如可以使用在表單上對於用戶可見的HSD(比如JSON)屬性值的散列，這對於允許稽核員確認簽名是真實的以及/或者簽名對應於簽名時顯示在螢幕上的資料來說可能是符合期望的。

還可以利用人工簽名，所述人工簽名可以實質上是通常可以採取傳統手寫簽名的形式的人類可讀證據，還可以在本發明的EHR系統的使用者介面中為其給出視覺表示。人工簽名例如可以被存儲在文檔的屬性中，所述屬性被利用用於文檔的範本的屬性向工作流程系統聲明。不同於數位簽章，人工簽名通常不可由EHR系統本身認證，因此EHR系統例如可以要求使用者證明人工簽名是代表經過授權的提交者正確地 捕獲的，以作為例如可稽核性的一部分。

工作流程中的文檔提交者通常可以是發起特定工作流程處理的使用者；但是所述提交者可以不一定是在工作流程中的某一步驟結束時提交文檔的同一人。舉例來說，許多機構允許電話指示單以及/或者通過傳真或者其他基於紙張的手段接收到的指示單，因此提交文檔的人可能是在代表文檔的實際提交者採取行動，所述實際提交者例如是醫師，其在指示單的情況下可能是被授權合法地提交指示單的唯一用戶類型。

在一些實施例中，可以在本發明的EHR系統中限制工作流程中的提交，從而使得僅有經過授權的和/或正確的用戶可以進行提交。舉例來說，如果用戶不屬於在本發明的EHR系統中規定的其中一個使用者類別，則EHR系統可以提示使用者表明正在代表哪一個用戶提交表單和/或其他工作流程專案。通過這種方式，例如使用者可以輸入電話、傳真和/或其他遠端指示單，其可以使得本發明的EHR系統如同經過授權的使用者已經簽名的情況那樣開始工作流程，並且/或者還並行地(也就是說不妨礙正常工作流程)把文檔放置到經過授權的使用者的佇列中以進行最終簽核。在使用人工簽名的實施例中，EHR系統可以例如基於實際輸入提交的用戶的公共/私有金鑰對來創建數位簽章，同時還合併實際代表其進行提交的使用者的標識資訊。

一般來說，工作流程的各個步驟可以規定簽名和/或其他授權將被收集的順序。步驟可以規定表明完成步驟可能所需要的簽名種類的特定用戶和/或用戶群組。舉例來說，如果步驟規定特定使用者，那麼如果文檔已經收集了該用戶的簽名，則認為該步驟完成。作為另外的實例，對於規定使用者群組的步驟，來自該群組中的任何用戶的簽名可能就是足夠的。因此，在工作流程中進行提交時，本發明的EHR系統可以順序 地檢查各個工作流程步驟，以便找到尚未完成的第一個步驟。該步驟的特定使用者和/或用戶群組還可以決定將把文檔放置到其中的特定工作隊列。從而當所有步驟都完成時，可以把文檔放置在例如可以通過文檔的範本定義的已完成佇列中。

還可以把附注合併到工作流程的各個步驟中，以便例如允許使用者隨著工作流程的進展作出注釋和/或評注。可以通過範本把附注小部件包括在表單中，從而使得可以很容易地從EHR系統的使用者介面添加附注。如圖2中所示，可以對於工作流程專案220顯示附注226。

TOC功能的實例

在一個實例中，當使用者第一次打開患者記錄時，在EHR系統的左側呈現TOC層級。每一個TOC層級按照基本上相同的方式動作：TOC層級聚焦在單個文檔上(在本例中是患者文檔)，並且顯示從通過tocLevel文檔(queryExpression(查詢表達法)屬性)定義的資料庫查詢得到的文檔列表。用於該清單的UI被分解成通過配置(config)文檔定義的節段。可以有多個配置文檔，並且這些配置文檔的子集將適用於當前的情況，這是因為其包含對應於活躍TOC層級的tocLevelID屬性以及可以與當前使用者的群組成員關係相匹配的targetGroupIDs屬性下的群組清單。當TOC層級被載入時，UI自動查詢所有匹配的配置文檔，並且把其中所定義的節段組成到單個列表中。配置文檔中的節段(在sections(節段)屬性下列出)用來過濾通過前面提到的資料庫查詢所返回的文檔。

查詢文檔以便出現在TOC層級中的實例

tocLevel文檔可以包含queryExpression屬性，其字串值預期是JavaScript表達法，其在被評估時應當產生將被傳遞到“MongoDB”的 JSON物件以便實施資料庫查詢。在該JavaScript表達法內，一些常用的表達法包括：

1)context.document指的是該TOC層級所聚焦的文檔

2)context.document._id指的是該TOC層級所聚焦的文檔的ID通常還如下結構化queryExpression：

使得表達法開始於jsonExpression=的原因是要利用內建到JavaScript中的JSON句法來構造查詢物件，其僅對於賦值(=)運算子右側的表達法可用。

當用戶選擇了在TOC層級下的節段中列出的文檔時，可以定義發生幾項動作的其中之一。如果文檔被設置成觸發到更深TOC層級的導覽，則UI把當前TOC層級“壓棧(push)”到導覽堆疊上，並且顯示新的TOC層級。(“壓棧”指的是“返回”按鈕出現以允許“彈棧(pop)”回到早前的TOC層級。)該新的TOC層級的聚焦文檔將由到TOC層級的導覽觸發如何被設置來決定。如果文檔沒有被設置成觸發TOC層級導覽，則其將在右側窗格中被打開。

TOC層級還允許用戶創建新的文檔。與文檔選擇一樣，文檔創建也可以被設置成不在右側窗格上創建用戶可編輯的文檔本身，而是創建其主要目的是充當用於其他文檔的容器並且觸發到更深TOC層級的導覽的文檔。“會面”和“記帳帳戶”是此類容器文檔的實例。

定義TOC中的節段的實例

正如前面所提到的那樣，通過配置文檔的節段屬性來定義節段。節段陣列中的單獨的節段具有專案屬性，其規定在該節段下出現的 功能表專案的順序。假設項目陣列中的每一個項目是文檔ID。相應文檔的類型決定所顯示的(多個)相應功能表專案的行為：

1)範本文檔的ID指示UI顯示從該範本創建的文檔。

2)tocLevel文檔的ID指示UI顯示到該TOC層級的參考，其在被按下時觸發到該TOC層級的導覽，但是與當前TOC層級具有相同的聚焦文檔。如果子TOC層級是要顯示來自當前TOC層級的文檔的子集，則這一選項是有用的。

3)報告文檔的ID指示UI顯示到該報告的參考，其在被按下時在右側窗格上顯示具有與當前TOC層級相同的聚焦文檔的報告。

工作流程的實例：

在一個方面中，僅具有健康護理領域內的工作流程步驟的示例性工作流程的實例可以是如下的針對X射線指示單的工作流程：

1、醫生填寫X射線指示單表單

2、醫生對X射線指示單表單簽名(在內建到X射線指示單表單佈局中的工作流程步驟中定義了對醫生簽名的需求)

3、X射線指示單被傳送到放射科技術人員佇列，以通知技術人員準備實施對於患者所需的指示單(在內建到X射線指示單表單佈局中的工作流程步驟中定義了針對表單的最終目的地-放射科)。

在另一個方面中，僅具有健康護理領域內的模式化處理的工作流程的實例可以是如下的用於為患者登記實驗室訪問的工作流程：

1、登記台值班人員詢問患者的ID

2、值班人員基於姓氏和出生日期在EHR中找到患者的記錄

3、值班人員敲擊移動設備上的按鈕，以帶出動態地生成用以確認患者的實驗室預約細節(時間、實驗室的具體種類等等)的表單並且 生成將要列印的條碼標籤腕帶的模式化處理。

在另一個方面中，包括健康護理領域內的模式化處理和工作流程步驟兩者的工作流程的實例可以是如下的針對處方指示單的工作流程：

1、醫生填寫用藥指示單表單

2、醫生對用藥指示單表單簽名(在內建到用藥指示單表單佈局中的工作流程步驟中定義了對醫生簽名的需求)

3、用藥指示單被傳送到藥劑師的佇列(在內建到用藥指示單表單佈局中的工作流程步驟中定義了第二許可人-藥房)

4、藥劑師使用模式化處理，其特別被設計成在由所述模式化處理動態地生成的表單上在患者的當前用藥和過敏症旁邊向他/她顯示出用藥指示單

5、隨後，藥劑師使用特別被設計成動態地生成顯示出即將需要被配藥的劑量的表單(其被稱作“配藥列表”)的模式化處理，並且他/她配製所需的用藥劑量

6、護士隨後取得該用藥劑量並且使用另一模式化處理，該另一模式化處理特別被設計成顯示出提示護士確認日期、時間、數量、路線和藥品的表單，並且隨後在所述劑量已被施藥時要求護士的簽名。

本領域普通技術人員將認識到，在不背離其精神或實質特徵的情況下可以通過其他具體形式具體實現本發明。因此，本發明的描述在所有方面被認為是說明性而非限制性的。本發明的範圍由所附申請專利範圍表明，並且落在其等效表述的含義和範圍內的所有改變都意圖被涵蓋在其中。

100‧‧‧儀錶盤視圖

102‧‧‧使用者登錄指示標

103‧‧‧退出登錄按鈕

110‧‧‧導覽欄

112‧‧‧按鈕

114‧‧‧按鈕

116‧‧‧按鈕

118‧‧‧預約排程按鈕

120‧‧‧患者列表

121‧‧‧患者列表

130‧‧‧預約排程

131

140‧‧‧條碼掃描器

150‧‧‧管理員控制項

Claims (44)

1. 一種用於在健康護理機構處實施和客製電子健康記錄(EHR)系統的方法，包括：在至少一台伺服器上向機構提供EHR系統的伺服器元件，所述EHR系統包括用於配置所述至少一台伺服器與託管所述EHR系統的用戶端元件的多個使用者訪問設備進行介面的軟體，並且包括用於應對資訊的底層資料應對特徵件，其能夠創建存儲在存放裝置中的與所述軟體分開的檔集合中的分層結構資料(HSD)文檔、向所述分層結構資料文檔添加資訊以及從中取回資訊；創建定義多個系統物件的一系列系統物件HSD文檔，所述系統物件定義在所述EHR系統的所述用戶端元件上向使用者顯示資訊以及從使用者收集資訊的方式，並且還定義將被插入到HSD文檔中以供保存和存儲的所述資訊的資料結構；以及通過修改至少其中一個所述系統物件HSD文檔來客製所述系統物件的輸入和輸出配置以便創建符合所述機構的機構實踐的客製系統物件，在所述至少一台伺服器上客製所述EHR系統，其中所述客製不改動所述軟體或其他HSD文檔；其中所述客製創建所述EHR系統的生產版本以供活躍使用。
2. 如申請專利範圍第1項所述的方法，其中所述至少一台伺服器包括測試伺服器和生產伺服器，所述測試伺服器在所述客製期間存儲並且運行所述EHR系統，並且被適配成把所述EHR系統的所述生產版本推送到所述生產伺服器以供活躍使用。
3. 如申請專利範圍第1或2項所述的方法，進一步包括：通過利用與所述至少一台伺服器介面的所述EHR系統的所述用戶端元件，在所述 EHR系統的所述客製之後訓練所述使用者操作所述系統物件。
4. 如申請專利範圍第1至3項當中任一項所述的方法，其中所述EHR系統通過創建、訪問或修改所述HSD文檔存儲和取回健康護理資訊，並且不修改所述系統物件HSD文檔或所述軟體。
5. 如申請專利範圍第1至3項當中任一項所述的方法，進一步包括：通過定義所述系統物件HSD文檔的集合創建客製使用者介面，所述系統物件HSD文檔由所述多個使用者訪問設備利用來生成用於顯示和收集健康護理資訊的圖形化使用者介面。
6. 一種無需在至少一台電腦伺服器上創建電子健康記錄系統(EHR)軟體的多個版本的情況下定義電子健康記錄系統中的定製表單的方法，包括：將健康記錄作為一系列分層結構資料(HSD)文檔存儲在所述至少一台電腦伺服器上；把表單佈局作為一系列HSD文檔存儲在所述至少一台電腦伺服器上，所述表單佈局規定一系列表單層級小部件；利用來自健康記錄HSD文檔的資訊填寫所述表單層級小部件，並且使用觸覺、鍵盤驅動或語音驅動的範例以使得使用者能夠通過至少一個設備上的顯示表面與資料進行交互，其中所述表單佈局規定將使用哪一個小部件來操縱將使用健康記錄HSD文檔的哪些部分，而無需修改駐留在所述至少一個設備和/或伺服器上的軟體；以及取回所述健康記錄HSD文檔和表單佈局(HSD)文檔並且將其組合以在所述至少一個設備上產生針對使用者的呈現，以便讀取和/或改變電子健康記錄中的資料。
7. 如申請專利範圍第6項所述的方法，其中所述HSD文檔包括JSON 文檔。
8. 如申請專利範圍第6或7項所述的方法，其中所述表單層級小部件包括節段、列表、附注或者節段分割選項卡。
9. 如申請專利範圍第6或7項所述的方法，進一步包括：把表示標準化治療概念的代碼集合存儲在所述至少一台伺服器上；以及利用至少其中一種所述表單佈局定義至少一個代碼挑選器小部件，每一個所述代碼挑選器小部件定義所述代碼集合的受限制子集；其中，所述設備向所述至少一台電腦伺服器查詢與由所述代碼挑選器小部件規定的限制相匹配的所述代碼子集，並且將其呈現在視覺表單中以供用戶選擇。
10. 如申請專利範圍第6至9項當中任一項所述的方法，其中所述表單佈局利用屬性映射來規定將使用哪一個小部件來操縱所述健康記錄HSD文檔的哪些部分。
11. 如申請專利範圍第6至10項當中任一項所述的方法，其中所述設備允許使用者利用來自具有相關目的或類似佈局的至少一個健康記錄文檔的值自動填寫新的或現有的健康記錄文檔表單。
12. 如申請專利範圍第6至10項當中任一項所述的方法，其中基於用戶的個人移動、可穿戴或健康監測設備上所存在的健康資訊自動填寫所述健康資訊HSD文檔。
13. 如申請專利範圍第6至12項當中任一項所述的方法，其中所述設備：顯示具有相關文檔的功能表以供使用者從中選擇；從所述至少一台電腦伺服器取回使用者選擇的文檔和用戶選擇的相 關文檔；把來自所有用戶選擇的文檔的所有行合併在一起；在使用者選擇的文檔中用黃色顯示來自使用者選擇的相關文檔的所述所有行，以便允許用戶接受或去除任何黃色的行從而把剩下的各行一起合併到單個文檔中；以及把單個文檔保存在所述至少一台電腦伺服器上。
14. 如申請專利範圍第13項所述的方法，進一步包括：把健康記錄表單的片段作為HSD文檔存儲在所述至少一台電腦伺服器上，所述健康記錄表單的片段包括被例行地輸入到健康記錄表單中的資訊。
15. 如申請專利範圍第6至14項當中任一項所述的方法，進一步包括：規定特別標記的清單小部件的集合以用於收集用於陣列表單中的多個文檔的資訊，每一個所述特別標記的小部件利用批次處理模式輸入用於所述多個文檔中的每一個文檔的所有資訊；以及利用所述特別標記的清單小部件一次創建多個健康記錄表單文檔；其中，所述設備創建所述健康記錄文檔的單獨拷貝，每一份所述單獨拷貝包括來自原始陣列的單個行的屬性。
16. 如申請專利範圍第7至13項當中任一項所述的方法，其中所述HSD文檔能夠利用腳本化句法進行編輯，以用於創建文檔片段和所述表單佈局而無需改動所述軟體。
17. 一種無需在至少一台電腦伺服器上創建電子健康記錄(EHR)系統軟體的多個版本的情況下定義EHR系統中的客製工作流程的方法，包括：把工作流程定義成一系列漸進的許可步驟，所述許可步驟包括需要 按照規定順序從已定義的使用者類別集合收集的簽名，並且把所述工作流程存儲在所述至少一台電腦伺服器上的表單佈局分層結構資料(HSD)文檔內部；其中，所述EHR系統在使用者設備上至少顯示從所述表單佈局HSD文檔生成的表單，所述表單向適當的使用者類別顯示所述許可步驟，以便按照所述規定順序從來自每一個所述適當用戶類別的至少一個使用者收集所述需要的簽名。
18. 如申請專利範圍第17項所述的方法，進一步包括：基於在所述表單中存在所述用戶類別有權為之提供數位簽章的所述許可步驟，利用所述表單填充用於所述其中一個所述用戶類別的至少一個使用者的使用者佇列。
19. 如申請專利範圍第17或18項所述的方法，進一步包括：在獲得先前的數位簽章之後，基於所述表單中的後續許可步驟把所述表單移動到後續的使用者佇列。
20. 如申請專利範圍第17至19項當中任一項所述的方法，進一步包括：在至少一台伺服器的專用於特定使用者或使用者類別的存儲部分中把指標存儲在佇列中；允許對於實際經過授權的用戶或者實際經過授權的使用者類別充當代理的使用者對於特定步驟作為代理對文檔簽名；以及把指向文檔的不同指標存儲在用於代理使用者代表其進行簽名的經過授權的使用者或使用者類別的佇列中，從而為經過授權的使用者提供確認所述代理確實作為其代表採取行動的機會。
21. 如申請專利範圍第17至20項當中任一項所述的方法，其中所 述設備包括臺式設備、移動設備、可擕式設備或者其組合。
22. 一種在電子健康記錄系統(EHR)中創建客製的基於參數的資料登錄介面的方法，包括：利用一系列分層結構資料(HSD)文檔提供EHR，以便定義存儲在存放裝置上並且能被至少一台伺服器和至少一個使用者介面設備訪問的多種資料登錄情況，所述EHR包括用於應對所述HSD文檔以及來自所述至少一個使用者介面設備的使用者輸入的軟體；提供接受來自所述使用者介面設備的使用者輸入並且訪問所述HSD文檔的辨識引擎；通過為所述辨識引擎提供能夠存在於所述用戶輸入中的與所期望的資料登錄任務相關的啟動資訊，在所述HSD文檔中定義對應於所期望的資料登錄任務集合的命令觸發的集合，每一項所述命令觸發包括被用於在所述EHR中執行命令的將要收集的參數集合；當在所述用戶輸入中檢測到用於一項所述命令觸發的所述啟動資訊時，基於一項所述命令觸發而觸發第一命令輸入會話，所述第一命令輸入會話載入用於一項所述命令觸發的所述參數集合；定義至少一項嵌套查詢以用於在所述第一命令輸入會話內提示來自所述使用者介面設備的使用者輸入，以便選擇用於所載入的所述參數集合的值或選項；其中，當對於所述參數集合選擇了所有所述值或選項時，所述EHR執行或提示所述命令的執行。
23. 如申請專利範圍第22項所述的方法，其中所述辨識引擎包括自然語言解譯器，其在考慮到自然語言輸入中的變型和情境的情況下將所述使用者輸入與所述啟動資訊進行比較，以便在所述用戶輸入與所述啟 動資訊之間生成可能的匹配。
24. 如申請專利範圍第22或23項所述的方法，其中所述命令輸入會話包括一系列反覆運算的所述嵌套查詢，其引導所述用戶輸入以便為所述EHR提供用於所述參數集合的完整並且無歧義的值以執行所述命令。
25. 如申請專利範圍第22至24項當中任一項所述的方法，其中所述EHR還包括情境辨識以便提供用於所述參數集合的所述值或選項。
26. 如申請專利範圍第22至25項當中任一項所述的方法，其中所述命令觸發包括為所述辨識引擎提供所述第一命令輸入會話內的所述參數、所述第一命令輸入會話的所述嵌套查詢以及第二命令輸入會話的觸發之間的區分的語義類型。
27. 如申請專利範圍第22至26項當中任一項所述的方法，其中所述辨識引擎駐留在從包括伺服器、使用者介面設備及其組合的組當中選擇的設備上。
28. 如申請專利範圍第26項所述的方法，其中所述辨識引擎被配置成從所述使用者輸入接受用於單獨命令觸發的單獨啟動資訊，以便在所述第一命令輸入會話活躍的同時生成所述第二命令輸入會話以作為並行的命令輸入會話。
29. 如申請專利範圍第25項所述的方法，其中在所述第一命令輸入會話活躍的同時，所述情境辨識從在所述使用者介面設備上查看到的資訊辨識出用於所述命令觸發的可能的參數值或選項。
30. 如申請專利範圍第22至29項當中任一項所述的方法，其中所述HSD文檔能夠利用腳本化句法進行編輯，以用於通過所述使用者介面設備創建所述命令觸發而無需改動所述軟體。
31. 一種無需在至少一台電腦伺服器上創建電子健康記錄(EHR)系統軟體的多個版本的情況下定義電子健康記錄系統中的客製工作流程的方法，包括：將模式化處理作為包括分層結構資料(HSD)文檔的模式化處理定義文檔存儲在所述至少一台電腦伺服器上以用於實施操作，所述模式化處理是利用與至少一台電腦伺服器動態地交互的腳本代碼來定義的，而無需改動所述EHR系統軟體；利用所述模式化處理定義文檔，基於從存儲在所述至少一台電腦伺服器上的其他健康記錄文檔以及從來自所述設備的使用者輸入收集的情境和資訊在設備上即時動態地生成漸進的表單集合；其中，隨著所述用戶與其中一項所述模式化處理進行交互，所述設備以動態序列或組合向使用者顯示所述漸進表單集合。
32. 一種無需在至少一台伺服器上創建電子健康記錄系統軟體的多個版本的情況下定義電子健康記錄系統中的客製視圖的方法，包括：把客製視圖作為包括分層結構資料(HSD)文檔的小部件定義文檔存儲在所述至少一台電腦伺服器上以用於實施操作，所述客製視圖是利用與至少一台電腦伺服器動態地交互的呈現語言和腳本代碼來定義的，而無需改動所述EHR系統軟體
33. 如申請專利範圍第32項所述的方法，其中所述呈現語言是HTML。
34. 如申請專利範圍第32或33項所述的方法，其中所述腳本代碼語言是JavaScript。
35. 一種把健康護理資料從電子健康記錄(EHR)系統中的早前表單佈局版本遷移到新版本的方法，包括： 採集存儲在分層結構資料(HSD)文檔中的健康護理資料集的集合，所述健康護理資料集關於存儲在第一表單佈局HSD文檔中的第一表單佈局版本被結構化；定義映射HSD文檔，其把關於所述第一表單佈局版本結構化的所述健康護理資料集的單元映射到第二表單佈局版本的單元；以及通過利用所述映射HSD文檔對關於第一表單佈局版本結構化的所述健康護理資料集進行變換，生成關於所述第二表單佈局版本結構化的變換後的健康護理資料集；其中，所述變換後的健康護理資料集的所述映射和生成不改動應對所述HSD文檔的所述EHR系統的軟體。
36. 如申請專利範圍第35項所述的方法，進一步包括：生成關於所述變換後的健康護理資料集的所述生成的報告，其包括映射關於所述第一表單佈局版本在何處發生。
37. 如申請專利範圍第35或36項所述的方法，其中所述EHR系統識別並且鎖定與生成所述變換後的健康護理資料集相關的所有HSD文檔從而使其無法被編輯，同時允許由所述EHR系統的使用者在所述生成期間查看所述HSD文檔。
38. 一種用於把具有關於原始表單佈局集合記錄的健康記錄的健康護理表單遷移到具有新表單佈局的較新表單集合上而無需不必要的停機時間或者對移動設備/伺服器軟體的新版本的需求的方法，包括：定義駐留在至少一台電腦伺服器上的轉換映射HSD文檔，其把存在於原始表單佈局集合上的資料欄位元映射到更新後的/新的表單佈局集合上的欄位元上；使用設備識別並且鎖定至少一台電腦伺服器上的所有相關的健康記 錄HSD文檔，以便遍歷在轉換映射的變換前側所參考的每一個資料欄位元，並且對於具有該欄位元的每一個健康記錄文檔，識別出與變換後資料欄位元相關聯的表單佈局，使得轉換映射該資料欄位元，並且把改變保存到至少一台電腦伺服器；釋放至少一台電腦伺服器上的所有觸及的健康記錄HSD文檔上的鎖定；以及為用戶呈現關於所發生的轉換映射的報告。
39. 如申請專利範圍第38項所述的方法，其中所述轉換映射包括直接映射與利用腳本代碼定義的更加複雜的映射的組合。
40. 如申請專利範圍第38或39項所述的方法，其中通過暫時禁止對正由轉換處理的特定文檔作出進一步改變，在轉換期間能夠由系統中的其他使用者參考並且看到所述被鎖定的文檔。
41. 如申請專利範圍第38至40項當中任一項所述的方法，其中所述HSD文檔能夠利用腳本化句法進行編輯，以用於通過所述使用者介面設備創建所述命令觸發而無需改動所述軟體。
42. 一種用於在機構處實施和客製電子記錄管理(ERM)系統的方法，包括：在至少一台伺服器上向機構提供ERM系統的伺服器版本，所述ERM系統包括用於配置所述至少一台伺服器與託管所述ERM系統的用戶端版本的多個使用者訪問設備進行介面的軟體，並且包括用於應對資訊的底層資料應對特徵件，其能夠創建作為與所述軟體分開的檔被存儲在存放裝置上的分層結構資料(HSD)文檔、向所述分層結構資料文檔添加資訊以及從中取回資訊；創建定義多個系統物件的一系列系統物件HSD文檔，所述系統物件 定義在所述ERM系統的所述用戶端版本上向使用者顯示機構資訊以及從使用者收集機構資訊的方式，並且還定義將被插入到HSD文檔中以供保存和存儲的所述機構資訊的資料結構；以及通過修改至少其中一個所述系統物件HSD文檔來客製所述系統物件的輸入和輸出配置以便創建符合所述機構的機構實踐的客製系統物件，在所述至少一台伺服器上客製所述ERM系統，其中所述客製不改動所述軟體或其他HSD文檔；其中所述客製創建所述ERM系統的生產版本以供活躍使用。
43. 一種無需在至少一台電腦伺服器上創建電子記錄管理(ERM)系統軟體的多個版本的情況下定義ERM系統中的定製表單的方法，包括：將機構資訊作為一系列機構記錄分層結構資料(HSD)文檔存儲在所述至少一台電腦伺服器上；把表單佈局作為一系列表單佈局HSD文檔存儲在至少一台電腦伺服器上，所述表單佈局規定一系列表單層級小部件；利用來自機構記錄HSD文檔的資訊填寫所述表單層級小部件，並且使用觸覺、鍵盤驅動或語音驅動的範例以使得使用者能夠通過至少一個設備上的顯示表面與資料進行交互，其中所述表單佈局規定將使用哪一個小部件來操縱將使用機構記錄HSD文檔的哪些部分，而無需修改駐留在至少一個設備和/或伺服器上的軟體；以及取回所述機構記錄HSD文檔和表單佈局HSD文檔並且將其組合以便在所述設備上產生針對使用者的呈現，以便讀取和/或改變所述機構記錄中的資料。
44. 如申請專利範圍第42或43項所述的方法，其中所述機構資訊 是從包括以下各項的組當中選擇的：電子健康護理資訊、人力資源管理資訊、會計資訊、專案管理資訊、顧客關係資訊以及活動管理資訊。