Presentation is loading. Please wait.

Presentation is loading. Please wait.

CDA R2 應用於簽章簡介 HL7 Taiwan 協會 秘書長 范士展 HL7 Taiwan Google 論壇 : 教育訓練委員會 Education Technical Committees.

Similar presentations


Presentation on theme: "CDA R2 應用於簽章簡介 HL7 Taiwan 協會 秘書長 范士展 HL7 Taiwan Google 論壇 : 教育訓練委員會 Education Technical Committees."— Presentation transcript:

1 CDA R2 應用於簽章簡介 HL7 Taiwan 協會 秘書長 范士展 HL7 Taiwan Google 論壇 : 教育訓練委員會 Education Technical Committees 版權所有:台灣健康資訊交換第七層協定協會

2 大綱 HL7 v3 背景說明 CDA R2 背景說明 CDA R2 簽章說明 XML Signature

3 HL7 v3 背景說明

4 RIM 2.20

5 靜態模型結構

6 RIM 類別關係 Act Act_Relationship Entity Role Participation Role_Link Non Core participates in plays has scopes has target has source has target has source

7 Roles 與 Entities 之關聯 “Played and Scoped” Doctor Patient Downtown Hospital Uptown Hospital Joe Smith Plays Scoped By Scoped By

8 Acts 與 Roles 之關聯 Relations and Participants Acts are related to other acts via ActRelationShips. Entities in Roles participate in acts via Participations. Role

9 RIM 之編碼概念

10 RIM 之限制式概念

11 以 UML 表達

12 與文字及多媒體有關的資料型態

13 與唯一辨識碼有關的資料型態

14 與臨床編碼有關的資料型態

15 CDA R2 背景說明

16 How the CDA is developed and maintained: just enough HL7 Development Framework Reference Information Model RMIM Hierarchical Description XML Schema linearization additional constraints algorithm subset of RIM tighten constraints 平面結構 巢狀結構

17 讀懂 R-MIM 類別是複製與顏色編碼 Acts: EncounterEvent A_Encounter ValuablesLocation A_Consent A_ObservationDx A_Account AccomodationEvent PatientTransportation Entities: E_Organization E_Place Roles: R_NotificationParty R_AssignedPerson R_AssignedEntity R_Patient ServiceDeliveryLocation R_AssignedOrganization Participations: notificationContact attender consultant referrer subject location responsibleParty admitter ActRelationships: componentOf pertinentInformation2 Authorization pertinentInformation1 Reference sequelTo arrivedBy

18 CDA R-MIM CDA Header CDA Body, Section, and Narrative Block Ext'l Refs CDA Entries

19 R-MIM 轉換成 XML Schema 一個 CDA 的 XML Schema 檔,應用於任何臨床文件。

20 CDA = header + body CDA Header  Metadata required for document discovery, management, retrieval CDA Body  Clinical report Discharge Summary Care Record Summary Progress Note H&P Public health report  … any content that carries a signature

21 Header Body  Readable: required  Computable: optional Sample CDA

22 CDA Header The header describes:  The document itself (unique ID, document type classification, version)  Participants (providers, authors, patients…)  Document relationships (to orders, other documents…) Metadata sufficient for document management

23 CDA Header: Metadata Identify  Patient  Provider  Document type... Sufficient for  Medical records management  Document management  Registry/repositoryg  Record locator service  Store, query, retrieve required

24 XML Body: two types of markup Human-readable “narrative block”, all that is required to reproduce the legal, clinical content Optional machine-readable CDA Entries, which drive automated processes

25 CDA Body: Human-readable report Any type of clinical document  H&P  Consult  Op note  Discharge Summary... Format: tif, PDF, HTML, XML:  Paragraph  List  Table  Caption  Link  Content  Presentation required

26 CDA Body: Machine Processible  Model-based computable semantics: Observation Procedure Organizer Supply Encounter Substance Administration Observation Media Region Of Interest Act Optional

27 Non-XML body

28 CDA R2 文件版本控管說明 id :文件流水號 setId :文件序列號

29 CDA R2 簽章說明

30 臨床文件的參與者 簽證者 法定簽證者 副本接收者 文件作者 資料輸入者 文件標的 ( 病患 ) 文件保管者 情報提供者 其他文件參與者 服務執行者

31 由情境決定角色如何參與(範例) 1. StaffPhysicianOne 負責照護病患為會診者、病歷書寫與簽章者。 Author — StaffPhysicianOne Encounter Participant — StaffPhysicianOne (typeCode="CONS") Legal Authenticator — StaffPhysicianOne 2. StaffPhysicianOne 照護病患與病歷書寫; StaffPhysicianTwo 負責簽章。 Author — StaffPhysicianOne Legal Authenticator — StaffPhysicianTwo 3. ResidentOne 與 StaffPhysicianOne 共同照護病患。 ResidentOne 負責書寫病歷並簽章, StaffPhysicianOne 負責 共同簽章。 Author — ResidentOne Authenticator — ResidentOne Encounter Participant — StaffPhysicianOne (typeCode="ATND") Legal Authenticator — StaffPhysicianOne 4. ResidentOne 與 StaffPhysicianOne 共同照護病患。 ResidentOne 負責書寫病歷並簽章。由 StaffPhysicianTwo 負 責共同簽章。 Author — ResidentOne Authenticator — ResidentOne Encounter Participant — StaffPhysicianOne (typeCode="ATND") Legal Authenticator — StaffPhysicianTwo

32 由情境決定角色如何參與(範例) 5. ResidentOne 與 StaffPhysicianOne 共同照護病患。 ResidentOne 負責書寫病歷,但休假。其病歷由 ResidentTwo 與 StaffPhysicianOne 簽章。 Author — ResidentOne Authenticator — ResidentTwo Encounter Participant — StaffPhysicianOne (typeCode="ATND") Legal Authenticator — StaffPhysicianOne 6. ResidentOne 與 StaffPhysicianOne 共同照護病患。 ResidentOne 負責書寫病歷。之後由 ResidentTwo 由 StaffPhysicianTwo 負責簽章。 Author — ResidentOne Authenticator — ResidentTwo Encounter Participant — StaffPhysicianOne (typeCode="ATND") Legal Authenticator — StaffPhysicianTwo 7. StaffPhysicianOne 收到不正常檢驗報告,試聯絡病患未果。但他仍書寫與簽一份 progress note 。 Author — StaffPhysicianOne Legal Authenticator — StaffPhysicianOne 8. ResidentSurgeonOne 與 StaffSurgeonOne 共同執行一項手術。 StaffSurgeonOne 寫手術記錄並簽章之。 Author — StaffSurgeonOne Authenticator — null (need not be included) Legal Authenticator — StaffSurgeonOne Performer — StaffSurgeonOne (typeCode="PPRF") Performer — ResidentSurgeonOne (typeCode="SPRF") 任何情境下,一定要有一個 Legal Authenticator

33 套用於國內時之考量 服務類別  門診  急診  住院 單張類別(參考台北醫學大學 劉立教授)  一人一次 / 一人多次 / 多人一次 / 多人多次  一寫一讀 / 一寫多讀 / 多寫一讀 / 多寫多讀

34 支援之欄位

35 Participation.signatureCode Cocpet domain 為 ParticipationSignature ,其 Value Set :  I (intended) :參與者應提供簽章。  S ( signed ):參與者已簽章。其簽章的可能附加形式,寫在檔案 中或附於 Participation.signatureText 內。  X ( required ): A signature for the service is required of this actor. 此 角色在此服務是需要簽章的。 若需存入一份未完成病歷時,參與者應標 記為 I 。 也就是說,未標記為 S 者,皆為未完成病歷。

36 Participation.signatureText 其資料型態為 ED (Encapsulated Data) ,且 ED 繼承於 BIN(Binary Data) ,故可存放二元 碼,也可存放類似 XML-signatures 的資料。 只要於 mediaType 宣告清楚即可。

37 codenamestatusdefinition text/plain Plain Text required For any plain text. This is the default and is equivalent to a character string (ST) data type. text/x-hl7-ft HL7 Text recommended For compatibility, this represents the HL7 v2.x FT data type. Its use is recommended only for backward compatibility with HL7 v2.x systems. text/html HTML Text recommended For marked-up text according to the Hypertext Mark-up Language. HTML markup is sufficient for typographically marking-up most written-text documents. HTML is platform independent and widely deployed. application/pdf PDF recommended The Portable Document Format is recommended for written text that is completely laid out and read-only. PDF is a platform independent, widely deployed, and open specification with freely available creation and rendering tools. text/xml XML Text indifferent For structured character based data. There is a risk that general SGML/XML is too powerful to allow a sharing of general SGML/XML documents between different applications. text/rtf RTF Text indifferent The Rich Text Format is widely used to share word-processor documents. However, RTF does have compatibility problems, as it is quite dependent on the word processor. May be useful if word processor edit-able text should be shared. application/msword MSWORD deprecated This format is very prone to compatibility problems. If sharing of edit-able text is required, text/plain, text/html or text/rtf should be used instead. audio/basic Basic Audio required This is a format for single channel audio, encoded using 8bit ISDN mu-law [PCM] at a sample rate of 8000 Hz. This format is standardized by: CCITT, Fascicle III.4 -Recommendation G.711. Pulse Code Modulation (PCM) of Voice Frequencies. Geneva, audio/mpeg MPEG audio layer 3 required MPEG-1 Audio layer-3 is an audio compression algorithm and file format defined in ISO and ISO MP3 has an adjustable sampling frequency for highly compressed telephone to CD quality audio. audio/k32adpcm K32ADPCM Audio indifferent ADPCM allows compressing audio data. It is defined in the Internet specification RFC 2421 [ftp://ftp.isi.edu/in- notes/rfc2421.txt]. Its implementation base is unclear. image/png PNG Image required Portable Network Graphics (PNG) [http://www.cdrom.com/pub/png] is a widely supported lossless image compression standard with open source code available. image/gif GIF Image indifferent GIF is a popular format that is universally well supported. However GIF is patent encumbered and should therefore be used with caution. image/jpeg JPEG Image required This format is required for high compression of high color photographs. It is a "lossy" compression, but the difference to lossless compression is almost unnoticeable to the human vision. application/dicom DICOM recommended Digital Imaging and Communications in Medicine (DICOM) MIME type defined in RFC3240 [http://ietf.org/rfc/rfc3240.txt]. image/g3fax G3Fax Image recommended This is recommended only for fax applications. image/tiff TIFF Image indifferent Although TIFF (Tag Image File Format) is an international standard it has many interoperability problems in practice. Too many different versions that are not handled by all software alike. video/mpeg MPEG Video required MPEG is an international standard, widely deployed, highly efficient for high color video; open source code exists; highly interoperable. video/x-avi X-AVI Video deprecated The AVI file format is just a wrapper for many different codecs; it is a source of many interoperability problems. model/vrml VRML Model recommended This is an openly standardized format for 3D models that can be useful for virtual reality applications such as anatomy or biochemical research (visualization of the steric structure of macromolecules)

38 CDA R2 對執行簽章說法 簽章應由文件(病歷)管理系統負責處理。 CDA R2 是臨床文件,不是資訊系統,是被 簽章的對象,因此不應處理簽章作業。 臨床文件是某一個時間的下,醫療行為之 資訊彙整。文件內容是指當下與流程無關, 但簽章是與流程有密切關係。

39 XML Signature

40 Schema 解析 - Signature 根元素 SignedInfo: 簽章相關資訊。 KeyInfo: 私密金鑰。用來驗證簽章。 Object: 任意資料,可能是 MIME Type 資料。 SignatureValue: 密文資料,以 base64 方式編碼。

41 Schema 解析 - SignedInfo 簽章相關資訊 CanonicalizationMethod : 摘要處理方法 SignatureMethod : 簽章處理方法 Reference : 簽章參考位置,可重複多 次。

42 Schema 解析 - KeyInfo 私密金鑰

43 最簡結構 ( ( )? )+ ( )? ( )* ? : zero or one + : one or more * : zero or more ? : zero or one + : one or more * : zero or more 注意:三種簽章類型,會用到不同的 Tag 。

44 範例

45 XML Signature 三種類型 Detached  簽章在文件之外。 Enveloped  XML 簽章在文件之內。  可只簽文件的部分。  一份文件可以有好幾個簽章 Enveloping  被簽的文件在 XML 簽章中。

46 與 CDA R2 之配合 Detached  在簽章 XML 檔中,透過 指向外部的 CDA R2 臨床文件。  因 可重複,適用於批次臨床文件簽章。如健保上傳。 Enveloped  簽章資料放在 CDA R2 臨床文件中。  適合一份文件許多人簽。  但 CDA R2 並不建議如此做。 Enveloping  是將 CAD R2 的 XML 資料放在 中。  可重複,故可同時簽多份臨床文件。


Download ppt "CDA R2 應用於簽章簡介 HL7 Taiwan 協會 秘書長 范士展 HL7 Taiwan Google 論壇 : 教育訓練委員會 Education Technical Committees."

Similar presentations


Ads by Google