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

CDA R2CDA R2 應用於簽章簡介應用於簽章簡介

HL7 Taiwan 協會秘書長 范士展

[email protected]

HL7 Taiwan Google 論壇 :http://groups.google.com/group/hl7-taiwan

教育訓練委員會Education Technical Committees

版權所有：台灣健康資訊交換第七層協定協會

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

HL7 v3 背景說明

RIM 2.20

靜態模型結構

RIM 類別關係

Act

Act_Relationship

Entity Role

Participation

Role_Link

Non CoreNon CoreNon Core

particip

ates in

playshas

scopes has targethas

sourcehas

targethas

source

Roles 與 Entities 之關聯 “ Played and Scoped”

Doctor Patient

DowntownHospital

Uptown Hospital

Joe Smith

Plays Plays

ScopedBy

ScopedBy

Acts 與 Roles 之關聯 Relations and Participants

Acts are related to other acts via

ActRelationShips.

Entities in Roles participate in acts via Participations.

Role

RIM 之編碼概念

RIM 之限制式概念

以 UML 表達

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

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

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

CDA R2 背景說明

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

平面結構平面結構

巢狀結構巢狀結構

讀懂 R-MIM類別是複製與顏色編碼

Acts:EncounterEvent

A_EncounterValuablesLocation

A_ConsentA_ObservationDx

A_AccountAccomodationEvent

PatientTransportation

Entities:E_Organization

E_Place

Roles:

R_NotificationParty

R_AssignedPerson

R_AssignedEntity

R_Patient

ServiceDeliveryLocation

R_AssignedOrganization

Participations:notificationContact

attenderconsultant

referrersubjectlocation

responsiblePartyadmitter

ActRelationships:componentOf

pertinentInformation2Authorization

pertinentInformation1ReferencesequelTo

arrivedBy

CDA R-MIM

CDA Header CDA Body,Section, andNarrative Block

Ext'l Refs CDA Entries

R-MIM 轉換成 XML Schema

一個 CDA 的 XML Schema 檔，應用於任何臨床文件。

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

Header Body

Readable: required Computable: optional

Sample CDA

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

CDA Header: Metadata

Identify Patient Provider Document type...

Sufficient for Medical records management Document management Registry/repositoryg Record locator service Store, query, retrieve

required

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

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

CDA Body: Machine Processible Model-based computable semantics:

Observation Procedure Organizer Supply Encounter Substance Administration Observation Media Region Of Interest Act

Optional

Non-XML body

CDA R2 文件版本控管說明

id ：文件流水號setId ：文件序列號

CDA R2 簽章說明

臨床文件的參與者

簽證者簽證者

法定簽證者法定簽證者

副本接收者副本接收者

文件作者文件作者

資料輸入者資料輸入者

文件標的 ( 病患 )文件標的 ( 病患 )

文件保管者文件保管者

情報提供者情報提供者

其他文件參與者其他文件參與者

服務執行者服務執行者

由情境決定角色如何參與（範例）

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

由情境決定角色如何參與（範例）

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任何情境下，一定要有一個 Legal Authenticator

套用於國內時之考量 服務類別

門診急診住院

單張類別（參考台北醫學大學 劉立教授）一人一次 / 一人多次 / 多人一次 / 多人多次一寫一讀 / 一寫多讀 / 多寫一讀 / 多寫多讀

支援之欄位

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 者，皆為未完成病歷。

Participation.signatureText 其資料型態為 ED (Encapsulated Data) ，且

ED 繼承於 BIN(Binary Data) ，故可存放二元碼，也可存放類似 XML-signatures 的資料。

只要於 mediaType 宣告清楚即可。

code name status definition

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, 1972. 

audio/mpeg  MPEG audio layer 3  required MPEG-1 Audio layer-3 is an audio compression algorithm and file format defined in ISO 11172-3 and ISO 13818-3. 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) 

CDA R2 對執行簽章說法 簽章應由文件（病歷）管理系統負責處理。 CDA R2 是臨床文件，不是資訊系統，是被簽章的對象，因此不應處理簽章作業。

臨床文件是某一個時間的下，醫療行為之資訊彙整。文件內容是指當下與流程無關，但簽章是與流程有密切關係。

XML Signature

Schema 解析 - Signature

根元素

SignedInfo: 簽章相關資訊。

KeyInfo: 私密金鑰。用來驗證簽章。

Object: 任意資料，可能是 MIME Type 資料。

SignatureValue: 密文資料，以base64 方式編碼。

Schema 解析 - SignedInfo

簽章相關資訊

CanonicalizationMethod: 摘要處理方法

SignatureMethod: 簽章處理方法Reference: 簽章參考位置，可重複多次。

Schema 解析 - KeyInfo

私密金鑰

最簡結構<Signature ID?>

<SignedInfo><CanonicalizationMethod/><SignatureMethod/>(<Reference URI? >

(<Transforms>)?<DigestMethod><DigestValue>

</Reference>)+</SignedInfo><SignatureValue> (<KeyInfo>)?(<Object ID?>)*

</Signature> ? : zero or one+ : one or more* : zero or more

? : zero or one+ : one or more* : zero or more

注意：三種簽章類型，會用到不同的 Tag 。注意：三種簽章類型，會用到不同的 Tag 。

範例

XML Signature 三種類型 Detached

簽章在文件之外。 Enveloped

XML 簽章在文件之內。 可只簽文件的部分。 一份文件可以有好幾個簽章

Enveloping 被簽的文件在 XML 簽章中。

<ClinicalDocument> <signatureText <signature>….</signature> </signatureText></ClinicalDocument>

<ClinicalDocument> <signatureText <signature>….</signature> </signatureText></ClinicalDocument>

<signature> <ObjectID> <ClinicalDocument>….</ClinicalDocument> </ObjectID></signature>

<signature> <ObjectID> <ClinicalDocument>….</ClinicalDocument> </ObjectID></signature>

<signature> <Reference>…</Reference></signature>

<ClinicalDocument>…</ClinicalDocument>

與 CDA R2 之配合 Detached

在簽章 XML 檔中，透過 <Reference> 指向外部的 CDA R2 臨床文件。

因 <Reference> 可重複，適用於批次臨床文件簽章。如健保上傳。 Enveloped

簽章資料放在 CDA R2 臨床文件中。 適合一份文件許多人簽。 但 CDA R2 並不建議如此做。

Enveloping 是將 CAD R2 的 XML 資料放在 <Object> 中。 <Object> 可重複，故可同時簽多份臨床文件。