<p id="b1ntz"><pre id="b1ntz"><output id="b1ntz"></output></pre></p>

<address id="b1ntz"><dfn id="b1ntz"></dfn></address><address id="b1ntz"><dfn id="b1ntz"><menuitem id="b1ntz"></menuitem></dfn></address>

<sub id="b1ntz"><dfn id="b1ntz"><ins id="b1ntz"></ins></dfn></sub>

<address id="b1ntz"><listing id="b1ntz"></listing></address>
<sub id="b1ntz"><var id="b1ntz"><mark id="b1ntz"></mark></var></sub>

<sub id="b1ntz"><dfn id="b1ntz"><menuitem id="b1ntz"></menuitem></dfn></sub>

    <address id="b1ntz"></address>

    <thead id="b1ntz"><var id="b1ntz"><mark id="b1ntz"></mark></var></thead>
    <sub id="b1ntz"><dfn id="b1ntz"><mark id="b1ntz"></mark></dfn></sub>

    <form id="b1ntz"><listing id="b1ntz"></listing></form>
    專業咨詢
    致力推進中國醫療衛生信息化

    【袁永福專欄】PDF+XML:歸檔病歷文件格式的能力互補

    來源:HIT專家網      作者: 南京都昌信息科技有限公司 袁永福

    HIT行業的有識之士呼吁:要建設20年不做顛覆性改變的新一代醫院信息系統。為了實現這個目標,需要高瞻遠矚的系統設計,同時在一些關鍵技術路線中需要慎重選擇,減少給未來帶來本可避免的損失。

    按照有關規定,門(急)診病歷的保存時間為自患者最后一次就診之日起不少于15年,住院病歷保存時間為自患者最后一次住院出院之日起不少于30年。因此,新一代醫院信息系統中的一個核心模塊:“病案歸檔”中的歸檔病歷文件采用什么存儲格式,就值得深入探討。

    PDFXML各有特點

    目前,很多系統采用PDF作為病歷歸檔的文件格式,原因很明確:PDF格式公開,是國際標準,能很好地展示排版格式,而且可以加上電子簽名,而且很多人以為PDF文件是不可修改的。更近一步的,軟件業界對PDF支持得很好,生態豐富,很多電子簽名產品就能直接操作PDF文件。

    但是落實到醫院行業,PDF文件格式無法“獨立”撐起業務系統20年不做顛覆性改變的重任,此時需要加入另一種XML格式的能力補充。筆者對這兩種技術進行了對比,如表1所示。

    對比領域PDFXML
    顯示和打印差一些
    人工閱讀支持支持
    機器閱讀(軟件自動分析)
    臨床業務有欠缺貼合
    文件類型二進制格式純文本格式
    數據恢復
    經濟動力
    敏感數據保護
    零信任安全不支持支持
    電子簽名支持支持
    表1 PDF與XML的技術能力對比(部分)

    以下是詳細說明:

    第一,功能需求方面。

    PDF是通用技術,不能很好地滿足很多醫院的特需功能。根據百度百科:PDF是Portable Document Format的簡稱,意為“可攜帶文檔格式”,是由Adobe Systems用于與應用程序、操作系統、硬件無關的方式進行文件交換所發展出的文件格式。PDF文件以PostScript語言圖像模型為基礎,無論在哪種打印機上都可保證精確的顏色和準確的打印效果,即PDF會忠實地再現原稿的每一個字符、顏色以及圖像。

    也就是說,PDF的初心是“顯示”和“打印”。醫療行業所特需的結構化文檔、質控規則、敏感數據保護等,都是需要深入二次開發的,難度未知甚至可能無法實現。這就為PDF未來在醫療行業中的深入發展帶來了不確定性。

    而XML格式具有很強的擴展性,全球IT界的大量成功案例證明了這點?;赬ML格式足以滿足醫院特需功能。

    第二,文件格式方面。

    目前一些醫院會使用光盤、磁帶機等低成本介質來存儲離線歸檔的病歷文件。從物理學上說,光盤和磁帶都是塑料制品,不是晶體,本質上是非常粘稠的液體,會緩慢發生不可逆的變形,這導致存儲數據有可能發生隨機變化。這里的數據變化包括在隨機位置處修改、插入或刪除字節。

    PDF是二進制文件,經不起長期低成本存儲的考驗。例如一個PDF文檔只包含有效內容“1111111111”,其文件內容在記事本中顯示如圖1所示:

    圖1

    對這樣的文件,隨機位置處的任何一個字節的隨機修改都會有很大概率對文件整體造成致命性的破壞,很難進行猜測式修復。如果保存在磁帶中的數據發生多處隨機錯誤,導致部分PDF文件無法讀取,這樣就無法合規保存病歷文件。

    當然我們可以采用三處異地備份的方式提高文件的保存質量和修復效果。但是長期離線存儲的病歷文檔再次被調閱的概率實在是太低了,從利用價值來說,這是一個巨大的稀疏矩陣,冗余存儲的性價比太差。

    相對而言,XML屬于具有自我描述的純文本文件,更能經得起時間的考驗,有可能做到快速猜測式修復破損的內容。XML雖然有一定的數據冗余,但就像當年的愛多VCD一樣具有較好修復能力。

    比如,對于結構化文檔內容“{吸煙史:煙齡[5]年,每天[10]根。}”,此時XML可以為“<field label=”吸煙史” ><field label=”煙齡” unit=”年”>5</field><text>undefined</text><field label=”每天” id=”每天吸煙數” unit=”根”>10</field><text>。</text></field>”。如果XML片段發生隨機的字節修改,比如變成“ <field label=”吸煙?” ><field label=”煙齡” unit=”年”>5</field><text>undefined</text>?ield label=”每天” id=”每天吸煙數” unit=”根”>10</fie?<text>。</text></field>”。對于這樣殘破的XML片段,人們仍然能輕松恢復出大部分信息,開發自動修復程序的難度也不大。

    再比如文本“袁永福的電子病歷”,若采用UTF8編碼,其16進制編碼為“81 88 38 6C 8F 79 84 76 35 75 50 5B C5 75 86 53”。若某些字節數據損壞,比如第一個字節丟失,其可辨認的16進制編碼變為“88 38 6C 8F 79 84 76 35 75 50 5B C5 75 86 53”,則以UTF8格式讀取的文本就變為“?轉葹?偵?虵”,這就是不可識別的亂碼了。

    而如果采用XML實體模式存儲這一文本,則保存為:

    若某些字節數據損壞,例如變成:

    這段受損的數據仍然可以準確辨認出文本“永福的電子病歷”,這樣就能實現數據的最大程度的恢復。

    第三,經濟因素。

    如果歸檔數據能參與大數據分析,持續創造價值,人們就能有足夠多的經濟動力來改善這些數據的存儲環境,提高生存質量。此時即使是二進制文件也能妥善處理。

    PDF更適用于人工肉眼閱讀,沒有自動化數據分析的能力;而XML能夠持續參與大數據分析而創造價值。如果以XML作為歸檔病歷文件格式之一,人們就有足夠的經濟動力,來妥善長期保存歸檔病歷。

    第四,合規性。

    病歷文檔包含了大量的敏感數據,包括患者姓名、電話、詳細住址等能精確匹配個人身份和位置的信息。敏感數據保護是新一代醫療信息系統必備的合規性要求,不可跳過。

    PDF文件目前缺乏可靠的敏感數據保護或者自動化脫敏機制,而XML具有很強的擴展能力。我們都昌公司基于XML開發了敏感數據透明加密技術,能加密病歷敏感數據,而普通數據則是明文存儲,這樣就能實現對病歷文檔的局部加密。

    在醫院內部等可信運行環境中,敏感數據在內存中實時解密顯示,用戶及開發商無感;而在醫院外部的低安全等級環境,敏感數據表現為不可逆的加密,此時數據使用方由于無法收集敏感數據反而能“避嫌”,從而獲得更大的發展機會。這樣XML格式能同時滿足醫院內部和外部的合規數據利用需求。

    第五,零信任安全

    據媒體報道,國家計算機病毒應急處理中心在2022年9月5日指出:“美國國家安全局對我國進行網絡攻擊,控制相關網絡設備,竊取了超過140GB的高價值數據”。為此,新一代醫院信息系統必須要貫徹“零信任”的安全理念。不法分子可以利用網絡攻擊,甚至人工滲透到系統內部,直接用移動硬盤拷貝數據庫文件來獲得高價值數據?!安慌沦\偷,就怕賊惦記”,PDF文件以明文包含醫患敏感數據而成為高價值數據,從而始終被不法分子“惦記”。而如果以XML作為病歷文件格式,利用其強大的擴展性,可以采用敏感字段透明加密等技術手段來實現“零信任”,降低數據離開醫院后的價值,可以減少黑客的攻擊動力和攻破后的損失。

    ,電子簽名。

    PDF的一大特點是可以實現電子簽名?;赬ML仍然可以實現電子簽名。電子簽名本質上是對一段二進制數據進行簽名,XML也是一種二進制文件,而且簽名驗證數據也可以嵌入在XML中隨身攜帶。

    另外要解釋PDF的一個誤解,很多人以為PDF文件不可修改。其實修改它并不難。目前有大量的軟件能方便修改PDF文件。PDF加上可靠電子簽名后,能形成法律上可靠的文檔數據,其功勞應歸功于電子簽名,和PDF沒有任何關系。

    PDFXML互補,滿足“機讀”和“人讀”的不同需求

    根據薛萬國主任在《醫療數據長期保存面臨挑戰,歸檔管理是解決之道》一文中的論述:從技術角度解讀醫療數據的使用需求,可以將其分為兩大類:一類是非結構化使用,也即“人讀”,以文檔記錄為單位,需保留數據內容及外觀;一類是結構化使用,也即“機讀”,以結構化元素為單位,不考慮數據的外觀,通過歸檔數據模型以純數據形式進行保存。

    PDF和XML各有優缺點,能形成互補,滿足“人讀”和“機讀”的不同需求。因此建議可以形成如下做法:

    第一,病案歸檔時可以PDF和XML兩種文件格式同時歸檔。

    第二,由于單個PDF被人工調閱的概率很低,而且為了防止數據有意無意的泄露,PDF文件需要高強度加密存儲,只有被調閱時才在內存中臨時解密。

    第三,XML采用敏感字段部分加密的方式存儲。在醫院內部的可信運行環境中,只有被調閱時才在內存中臨時解密敏感字段;脫離醫院可信環境,XML只能顯示普通數據,無法顯示敏感數據。

    第四,醫院對外發送病歷文件時,可以比較放心地發送XML文件,但發送PDF文件時需要非常謹慎小心,因為PDF文件中含有未加密的敏感數據。

    第五,由于XML文件能參與大數據分析而持續產生經濟價值,這樣人們有動力改善XML文件的存儲環境,順帶改善PDF文件的存儲環境,實現歸檔文件的長期可靠存儲。

    綜上,要開發出20年不做顛覆性改變的新一代醫院信息系統,就需要選擇能持續20年的技術路線。PDF雖然目前應用廣泛,但也有其固有缺陷。此時我們需要平衡短期利益和長期利益,在病案歸檔中考慮引入XML格式進行補充,雖然這會帶來不少工作量,但卻有助于HIT行業長期價值最大化。

    【作者簡介】

    袁永福,男,微軟MVP,80后,南京都昌信息科技有限公司聯合創始人,中國醫院信息化領域知名軟件技術專家,長期從事電子病歷編輯器等行業核心技術的研發和推廣,一直為整個醫信行業的價值最大化而努力。

    此圖片的alt屬性為空;文件名為HIT%E4%B8%93%E5%AE%B6%E7%BD%91%E8%AE%A2%E9%98%85%E5%8F%B7.png
    關注HIT專家網微信訂閱號
    精彩不容錯過!
    尋求“商務合作”請掃碼填寫需求
    我們將盡快與您聯系!

    【責任編輯:秦勉】

    贊(4)

    評論 1

    評論前必須登錄!

     

    1. #1

      病歷歸檔,是歸檔! 并不是為了為計算機處理信息提供保障,后者有數據管理系統支持。PDF格式是為了確保自然人視角確定,理解穩定一致。XML格式既不必要也不可行,因為病歷包括患者的所有信息,是多模態的,并非僅文本,XML也就是個架子,還不如PDF,國家目前還是推OFD。PDF也可以疊加簽名信息,但長時程數據的數據安全問題并沒有很好解決。

      hfrank4個月前 (09-07)


    未經允許不得轉載:HIT專家網 » 【袁永福專欄】PDF+XML:歸檔病歷文件格式的能力互補
    分享到: 更多 (0)
    黄色性交一级老太婆网站|欧美一区免费观看|黄色w网站免费|中国91区26黄片
    <p id="b1ntz"><pre id="b1ntz"><output id="b1ntz"></output></pre></p>

    <address id="b1ntz"><dfn id="b1ntz"></dfn></address><address id="b1ntz"><dfn id="b1ntz"><menuitem id="b1ntz"></menuitem></dfn></address>

    <sub id="b1ntz"><dfn id="b1ntz"><ins id="b1ntz"></ins></dfn></sub>

    <address id="b1ntz"><listing id="b1ntz"></listing></address>
    <sub id="b1ntz"><var id="b1ntz"><mark id="b1ntz"></mark></var></sub>

    <sub id="b1ntz"><dfn id="b1ntz"><menuitem id="b1ntz"></menuitem></dfn></sub>

      <address id="b1ntz"></address>

      <thead id="b1ntz"><var id="b1ntz"><mark id="b1ntz"></mark></var></thead>
      <sub id="b1ntz"><dfn id="b1ntz"><mark id="b1ntz"></mark></dfn></sub>

      <form id="b1ntz"><listing id="b1ntz"></listing></form>