PCDVD數位科技討論區
PCDVD數位科技討論區   註冊 常見問題 標記討論區為已讀

回到   PCDVD數位科技討論區 > 其他群組 > 七嘴八舌異言堂
帳戶
密碼
 

  回應
 
主題工具
R2-D2
*停權中*
 

加入日期: Mar 2008
文章: 52
引用:
作者loveless.
所以寫一份讓病患看得懂的病歷是天經地義的事。

口語溝通上讓病患聽得懂是天經地義的事.

但病歷不是寫給病人看的, 至少目前不是. 讀者不同, 寫法就不同. 寫給自己或同行看, 自然以精準為原則, 盡量減慢病歷變厚的速度. 若要寫到病患看得懂, 那就是完全不同的寫法. 我不知道專業作者通常是花多少時間幫人寫自傳, 但我想若醫院有提供足夠人力資源, 醫生當然是不介意坐下來喝杯咖啡, 一天花幾個小時寫一個病歷啦. 哈哈這個制度其實還蠻爽的, 應該推廣到各行各業, 大家就每天寫自己的業務筆記給顧客看吧.
     
      
舊 2009-07-20, 10:02 AM #41
回應時引用此文章
R2-D2離線中  
KNT
*停權中*
 
KNT的大頭照
 

加入日期: Aug 2004
文章: 89
我可不願意隨身攜帶病歷...
光想到牙醫的就診記錄,從小到大,有多少頁?

中文化的議題反而適合拿出來討論
 
舊 2009-07-20, 10:17 AM #42
回應時引用此文章
KNT離線中  
Lisa Hsu
*停權中*
 
Lisa Hsu的大頭照
 

加入日期: Jul 2000
您的住址: 台北縣
文章: 1,455
引用:
作者李麥科
之前健保卡就想要放病歷資料
後來有醫院認為有隱私性的問題,然後法規也沒有配套,所以一開始發健保卡的時候
上面只有記錄健保記錄簡單的次數而已(印象中)
後來修法,放了在哪邊就醫的紀錄
之後是規劃可以放簡單的病歷資料,還是病歷索引檔我忘了
說真的健保卡容量也沒多大,但是如果可以儲存索引檔真的會有很大的用處
不過現在是不是做到了?這我就不知道了

其實參考銀行存摺就好

每家銀行電腦系統都不一樣,但都會印存摺本給客戶.客戶想查匯款資料,翻翻本子就可以了.因為本子是給客戶自己保存,也無隱私問題.

病人上醫院時,帶這些本子給醫生參考就行了.其實這還滿重要地.比如說藥物過敏,病人只能模糊回答某次感冒吃藥過敏,看病歷本才能確定過敏藥名.
舊 2009-07-20, 10:23 AM #43
回應時引用此文章
Lisa Hsu離線中  
李麥科
*停權中*
 

加入日期: Jul 2008
文章: 51
引用:
作者KNT
我可不願意隨身攜帶病歷...
光想到牙醫的就診記錄,從小到大,有多少頁?

中文化的議題反而適合拿出來討論

其實要不要讓病患攜帶病歷,這背後的意義就是在討論:

如何讓病歷在適當的地點、讓適當的人、在適當的時間可以取得?

除了資訊化我還真的想不到還有甚麼更好的方法

中文化的問題,我則是認為到底要不要中文化只是表面

這背後的意思則是如何建立適當的病歷內容?

從寫到讀,有沒有一個解決方案讓製做的人不用費心,讀的人也容易了解?

我也認為,資訊化在這個裡面也扮演重要的角色(當然不是全部,因為還有很多層面要配合)
舊 2009-07-20, 10:25 AM #44
回應時引用此文章
李麥科離線中  
VF-19
Major Member
 

加入日期: Jan 2008
文章: 156
引用:
作者TRG-pro
病人自存病歷,也許正反映出缺乏穩定的醫療機構來負責保管紀錄,出院門就銀貨兩訖。


這點我相信!
光是我從小到大看過的醫院就數都超過20家

可是一旦病歷給病人拿著.....
而且相對於醫學中心擁有的人力物力,現在一般診所根本比不上
很多基層診所基本上只有2~3隻貓,人一多就忙不完
我家這邊光是診所就倒了3家過,1家是真的倒閉,2家是醫生不開業了

問題是這3家都是社區診所,2家開業都15年以上
光是儲存的病歷資料就跟多到爆炸

其中一位歇業的醫生我跟他很熟,它是我社區每個人都敬重的老醫生
雖然是軍醫,可是真的對這個社區的人盡心盡力,它的病歷數不多從開業到歇業
大概3萬份而已吧!(它也沒精算過!因為它不會用電腦)
但是那是人頭數!裡面的頁數更多更多.......

老醫生的太太曾經抱怨過,當初它們一直不敢結束診所就是在想這堆病歷要怎麼辦
這很多很多都是有些社區內小朋友從小看到大的病歷資料
真要丟掉也覺得可惜,不丟又沒辦法.......最後.........全數送專業處理廠水銷破壞

各位現在說的電子病歷或是病歷中文化
有沒有想過基層診所要怎樣作業!現有的資料轉換要花多少時間.....
而健保局或是衛生署的就醫政策是從低>高(診所→地區醫院→區域醫院→.......)

試問!全台灣診所或自行開業的小型醫院的病歷量會輸大型醫院嘛?
怎麼樣讓小型醫院都能做到,才是重點吧!
舊 2009-07-20, 10:27 AM #45
回應時引用此文章
VF-19離線中  
李麥科
*停權中*
 

加入日期: Jul 2008
文章: 51
引用:
作者Lisa Hsu
其實參考銀行存摺就好

每家銀行電腦系統都不一樣,但都會印存摺本給客戶.客戶想查匯款資料,翻翻本子就可以了.因為本子是給客戶自己保存,也無隱私問題.

病人上醫院時,帶這些本子給醫生參考就行了.其實這還滿重要地.比如說藥物過敏,病人只能模糊回答某次感冒吃藥過敏,看病歷本才能確定過敏藥名.

就算是銀行存摺也是有隱私問題嘍

至少我就不喜歡給別人看我的存摺

其實健保卡的最初設計,就是像你說的,如果你隨身帶健保卡,就算是去一家你沒有去過的醫院

醫院都能夠知道你的基本資料、過敏史等等

健保卡還比存摺來的安全(相對來說),因為通常沒有醫師卡是不能讀健保卡的
舊 2009-07-20, 10:29 AM #46
回應時引用此文章
李麥科離線中  
李麥科
*停權中*
 

加入日期: Jul 2008
文章: 51
引用:
作者VF-19
各位現在說的電子病歷或是病歷中文化
有沒有想過基層診所要怎樣作業!現有的資料轉換要花多少時間.....
而健保局或是衛生署的就醫政策是從低>高(診所→地區醫院→區域醫院→.......)

試問!全台灣診所或自行開業的小型醫院的病歷量會輸大型醫院嘛?
怎麼樣讓小型醫院都能做到,才是重點吧!

我覺得你問的很好

其實目前台灣病歷電子化(要說明一下,病歷電子化和電子病歷是兩個有關係,但是不同的議題)目前還是著重於醫院
按照過去醫院分級的方法,也就是地區級以上的醫院

診所要搞病歷電子化,我是覺得相對來說比較不重視
原因是因為大醫院都搞不定的話,只有診所電子化那效益不高

解決方案我是看過幾種
比如說直接掃描進去,只要建立索引就可以,或是優先把幾個重要的病歷資訊先電子化等等
不過這都是要成本,不可能全叫診所們買單的
所以至少目前是無解

有點吊詭的是,其實你這個小小問題我之前查閱學術研究
說真的很少見
也就是怎麼從一堆紙本變成電子化,這種很累的問題
也許是我沒有特別去找吧,或者業界早有解決方案,但是我覺得你這個小問題說真的很重要
舊 2009-07-20, 10:37 AM #47
回應時引用此文章
李麥科離線中  
Lisa Hsu
*停權中*
 
Lisa Hsu的大頭照
 

加入日期: Jul 2000
您的住址: 台北縣
文章: 1,455
引用:
作者李麥科
...健保卡比存摺來的安全(相對來說),因為通常沒有醫師卡是不能讀健保卡的

這樣說起來,只要開放讓病人讀健保卡就好啦!自然人憑證現在也用得很多沒問題.

為何只有醫生才能讀,病人自己不能讀是很奇怪地.畢竟醫生醫療結果,是由病人承擔,他絕對應該有權看才對!
舊 2009-07-20, 10:46 AM #48
回應時引用此文章
Lisa Hsu離線中  
李麥科
*停權中*
 

加入日期: Jul 2008
文章: 51
引用:
作者Lisa Hsu
這樣說起來,只要開放讓病人讀健保卡就好啦!自然人憑證現在也用得很多沒問題.

為何只有醫生才能讀,病人自己不能讀是很奇怪地.畢竟醫生醫療結果,是由病人承擔,他絕對應該有權看才對!

病患可以自讀健保卡

不過你要到醫療院所或是健保局相關單位去讀卡

我所說需要醫師卡那是一般的狀況,不是一定需要醫師卡,只是一般情形下(比如說你去看診),除了你的健保卡,也需要醫師卡

因為醫師要讀你的資料,他一定要有他的卡做為紀錄與證明

此外健保卡這個東西以後的用途並沒有綁死,以後還會再變化,現在也是第二階段而已(可以上網看看)

也許你會問為什麼不用自然人憑證

我在想啦,衛生署應該會想到你這個方法,只是這樣也不能保證資料不會被別人亂用(當然醫院不見得不會亂用,不然也不會有騙健保費用的問題)

能夠少一事的情況下,我想衛生署大概也不會輕易開放,除非有更好管理的方式
舊 2009-07-20, 11:09 AM #49
回應時引用此文章
李麥科離線中  
sunnywalker
*停權中*
 
sunnywalker的大頭照
 

加入日期: Jul 2003
您的住址: 雅閣裡(Ugly)
文章: 255
有沒有醫界的朋友,出來現身說法...

否則,我覺得有些瞎子摸象...
舊 2009-07-20, 11:21 AM #50
回應時引用此文章
sunnywalker離線中  


    回應


POPIN
主題工具

發表文章規則
不可以發起新主題
不可以回應主題
不可以上傳附加檔案
不可以編輯您的文章

vB 代碼打開
[IMG]代碼打開
HTML代碼關閉



所有的時間均為GMT +8。 現在的時間是05:50 PM.


vBulletin Version 3.0.1
powered_by_vbulletin 2025。