找回密码
 欢迎注册
搜索
热搜: 活动 交友 discuz
查看: 1802|回复: 0

[转贴]临床文档结构(CDA)~2

[复制链接]
发表于 2007-9-19 10:01:12 | 显示全部楼层 |阅读模式
2.4 安全、保密、数据完整
接收和发送CDA文档的应用程序负责所有合法性要求的处理,包括:文档鉴定、机密性、保持
力。在公网上通迅,必须使用密码技术进行发送源和接受者之间的认证并保护压缩的文档内容
;并且可用存在的商业性加密工具来实现,本标准在此范围以外。
CDA确实提供机密状态信息来附助应用系统管理敏感数据的访问。机密性状态应在整个文档或
指定的文档段全部应用。

2.5 CDA与HL7消息标准的关系
一个CDA文档是一个已定义的可以存于在消息内容以外或在HL7消息中以MIME编码程载的完整
信息对象。因此,CDA是HL7消息规范的补充。

2.5.1 CDA文档和文档管理
临床文档是可以补修改的,并且可以追加到一个已经存在的文档之上。理想地,更新一个文
档将声明其自己已陈旧了,并明确包含一个指向更新版本的指针。这样可减少健康医疗提供者
在大量错误或不完整数据上作治疗决定的可能性。
然而,事实上保证每个旧版中直接包含一个向前指向新版的指针是不可能的。没有一个程序
可以跟踪所有已保存的临床文档和它们的所有拷贝的联接链。因为没有办法保证一个文档被查
看后没有被修改过。
为使看到过期信息的风险最小,文档和文档管理器必须是相互依赖的。如果一个CDA文档在文
档管理器之外被查看,就不能确定它是否已修改过了。程载CDA文档的HL7消息可以用于传达内
容鉴定信息,以保证正确的临床数据察视。

2.5.2 在V2.x消息中发送CDA文档
2.5.3 在V3.x消息中发送CDA文档

3 CDA技术规范
3.1 简介
从以上描述可知,CDA水平一是通过CDA水平一框架来指定的。它包括了定义为XML实体的CDA
头框架。CDA头框架还包括了同样定义为XML实体的HL7 V3数据类型第一版框架。CDA水平一文
档参考CDA水平一框架。
技术上,CDA水平一由三部分组成。
一、CDA头,CDA头是由CDA头框架指定的,它沿用了开发V3消息框架方法,继承了分等级描述
的特点。
二、CDA水平一文档体,它由CDA水平一框架指定,它是从用标准的文档标记建模来进行文档
分析和创建方法中继承过来的。
三、HL7 V3数据类型第一版框架,它是同时由CDA和HL7 V3消息规范使用的抽象数据类型规范
的XML实现。
CDA元素<levelone>是CDA水平一文档的根元素。CDA水平一框架中定义的<levelone>元素包含
了<clinical_document_header>和<body>两个元素。<clinical_document_header>元素的详细
解释见(3.2 CDA头),再接下去是<body>的详细内容(3.3 CDA水平一文档体)。
词汇域是编码化的CDA成份的值集。这些域可以包含HL7定义的概念,并可以从HL7公认的译码
系统(如LOINC或SNOMED)中提取。词汇域有一个编码强度,它可以是"Coded,No Extensions
"(CNE),编码的,没扩展,这种情况下,CDA成份的允许值只能在词汇域这内;它也可以是"C
oded,With Extensions"(CWE),编码的,有扩展,这种情况下,词汇域以外的值(如局部代码
)必要时也可以使用。每一个词汇域都有一个HL7分配的准一标识,每一个概念在词汇域中都
有一个准一的代码。一个编码的CDA成份可以限制其使用一个相关的词汇域,以规定一个值集

当编码的CDA成份与HL7定义的词汇域关联后,标准的编码强度、可用概念值列表、显示名称
、概念定义等如下示例:
当编码的CDA成份与外部已定义的词汇域关联后,标准的编码强度和域内可用概念的定义如下
例:

3.2 CDA头
3.2.1 概述
CDA头的目的是使临床文档可以在公共机构之间交换;简化临床文档管理;方便将个人医疗文
档编辑到终生健康档案中去。
CDA头共有四个逻辑成份:
一、文档信息
二、受访数据
三、服务提供者
四、服务接受者
文档信息标识了文档,定义了机密性状态,描述了与其它文档或单据间的关系。受访数据描
述了文档受访的开始。服务提供者包括了谁鉴别这个文档,谁要获取这个方档的拷贝,谁是文
档的生成者和录入者,谁是参与健康医疗的提供者等,这些都被记录在内。服务接受者包括患
者,其它有意义的参与者(如家人),和那些可能产生部分内容的设备。

3.2.2 技术细结
3.2.2.1 公共的XML属性
3.2.2.1.1 XML元素鉴别
每一个CDA中的XML元素都有一个可选的标识符,它在整个文档中必须准一。标识符的数据类
型是XML“ID”。“IDREF”或“IDREFS”类型的XML属性的值必须与该文档中相同元素的ID属
性的值相匹配。

3.2.2.2 文档信息
3.2.2.2.1 文档鉴别
每一个文档都有一个必须的,全局唯一的实例标识<id>;一个可选的保存所有文档是从哪个
公共的原始文档修改而来的常量标识<set_id>;一个可选的版本号<Version_nbr>;这些标识
在管理文档附加和复盖时是非常有用的(3.2.2.2.4中将有描述)。一份原始的报告是一个报告
的第一版,它获取一个全局的唯一标识<id>,一个原始的报告还获得一个<set_id>的新值,而
<version_nbr>值设为“1”。
每一个文档都必有一个类型码。下面这个外部定义的词汇域是从LOINC中提取的。

3.2.2.2.2 文档时间戳
CDA文档创建和验证时有很多时间因素参与。有些相关的时间是文档信息的一部分,而另一些
与受访数据和不同的提供者与接受者的角色扮演时间相关。有些时间因素可以表示为一个特殊
的时间点(在XML元素名后加"_dttm"来指示,使用"point in time"数据类型),有些时间因
素包括多个时间点或时间间隔(在XML元素名后加"_tmr"来表示,使用"interval of time"或
"general time specification"数据类型)。
<service_tmr>表示服务被文档化开始的时间。如果没有受访关联,就要一定要用到它;而有
受访关联时,必须用到<encounter_tmr>,<service_tmr>就不用了。<service_tmr>和<encou
nter_tmr>两者都既可以用时间点或时间间隔。
<origination_dttm>表示了原始文档初始(如口述或录入软件界面)的时间。如果一个文档
后业被修改了,<origination_dttm>的值将不变。
<copy_dttm>表示了一个文档从文档管理系统(管理控制所有文档修改)发放(如拷贝或发送
到显示设备)的时间。一旦设定了值,将不能再修改。<copy_dttm>的意图是检查文档离开保
证内容安全的文档管理系统的时间有多长。
其它在文档生存期内的时间戳是通过与文档关联的服务提供者和服务接受者来记录的。因此
,文档鉴定、发源、抄写、提供者和其它参与的参与者及患者和其它接受者中都包含时间。

3.2.2.2.3 文档机密性
CDA头指示了文档的机密性。实施者可以在应用到整个文档的文档头中包含单个机密状态。要
在文档的不同部分指定不同的机密状态,实施者可以在文档头中指定多个机密状态。不同部分
文档可以通过参考获得其中一个机密状态码。机密状态码应该在服务机密词汇域中提取。

3.2.2.2.4 文档关系
3.2.2.2.4.1 文档之间的关系
CDA头可以清楚地表示文档之间的关系。这种关系依赖于前面描述的文档标识(见3.2.2.2.1
文档标识)。一个原始报告是报告的第一个版本,它获取一个全局唯一的<id>值,和一个新
的<set_id>值,并设置<version_nbr>为“1”。
附录可以附加到一个存在的报告中以提供补充信息。附录的自己是一个原始报告,由前一段
描述。被附加的父报告通过<document_relationship>来参考,并反<document_relationship
.type_cd>设为"APND"(意为:附加)。这个被附加的父报告保持原样,其内容和状态不变。
复盖是把一个存在的报告替换掉。替换的报告获得一个全局唯一<id>值,它的<set_id>使用
被复盖的报告的<set_id>值,<version_nbr>值加1。(注:<version_nbr>在报告被替换时必
须只被一个人增加,而为了局部需要,可以加大增量)。父报告被认为是过期了,但实际上它
仍保持在系统中作为历史参考。被替换的父报告是通过<document_relationship>和将<docum
ent_relationship.type_cd>设为"RPLC"(意为:替换)来参考的。
一个转换的文档是从一个存在的CDA文档中转换过来的。转换过来的文档获得一个新的全局唯
一标识<id>值,它的<set_id>值使用被转换的父报告的<set_id>值,<version_nbr>值加1。(
注:<version_nbr>在报告被替换时必须只被一个人增加,而为了局部需要,可以加大增量)
。父报告被认为是过期了,但实际上它仍保持在系统中作为历史参考。被替换的父报告是通过
<document_relationship>和将<document_relationship.type_cd>设为"XFRM"(意为:转换)来
参考的。
3.2.2.2.4.2 与单据的关系
文档肯定是同一个或多单据产生的。CDA头中的<fulfills_order>成份可以清楚表示与实际单
据之间的关系,这些单据用一个全局唯一标识来指定。下表是<fulfills_order.type_cd>的充
许值。

3.2.2.3 受访数据
受访数据包括一个可选的全局唯一标识,一个必须的受访时间戳;一个可选的受访地点,它
包括一个全局唯一的地址标识和地址信息。
<service_tmr>表示了服务被文档化发生的时间。如果一个服务与受访关联,<encounter_tm
r>是必须的,<service_tmr>不用记录。两者都即可以使用时间点又可以使用进间间隔。
一个受访还包括一个可选的实践设置码<practice_setting_cd>,它是一个提交的治疗中的临
床分类设置(如:心脏科,内科,康复医院,疗养院)。(注:实践设置和提供医疗的物理场
所之间是多对多关系。因此,一个特殊的房间今天可以作为心脏科,明天却可变为内科;而心
脏科,今天可能一这间房间,而明天就可能在另一个房间了)。
<practice_setting_cd>值应该从实践设置词汇域中提取。

3.2.2.4 服务发动者
所有CDA文档涉及的人或物与CDA文档的关系既可以是服务提供者又可以是服务接受者。服务
提供者包括:谁鉴定文档,谁有意获取文档,文档的创作者或录入者,在文档化的服务中是健
康医疗服务的参与者。服务提供者有能力和责任作出独立的决定。

3.2.2.4.1 一个文档的责任者
在CDA头中,有好几个成份可以表示人或组织在文档或文档化的服务中扮演一个角色。虽然这
些成份可以表示不同的人,但经常有一个人在多个这样的成份的值中出现(如:一个人既是文
档的创作者又是文档的鉴定者)。这种情况下,一个人应当作为每一个适当成份的值。
一个人所扮演的角色由type_cd表示(如:<authenticator.type_cd>,<service_actor.type
_cd>)。虽然角色可以通过XML元素名称来批示,但type_cd是最权威的批示。
每一个人都有一个必须的全局唯一的标识,一个可选的物理地址和通迅地址,还有一个可选
的姓名。一个人名有一个有效期<effective_tmr>,和一个从人名词汇域中提取的代码,它可
以指示人名的类型。下表总结了<person_name.type_cd>的有效值。

3.2.2.4.2 认证者
CDA指定了交换的临床文档的结构。当一个局部文档形成可交换的CDA文档时,局部文档认证
就产生了,事实上是从交换的文档反馈来的。CDA文档可以反应未认证、已认证或法律鉴定等
状态。当没有鉴定信息记录时产生未认证(既没有认证又没有法律鉴定)。
当一个提供者验证过文档的正确性以后一个文档就是已认证的。一个文档可以被零或多个人
认证。下表提取自服务提供者词汇域,总结了<authenticator.type_cd>的充许值。
当一个人已经验证文档的正确性并对此负有法律责任时,这个文档就是合法认证的。下表提
取自服务提供者词汇域,总结了<legal_authenticator.type_cd>的充许值。
<participation_tmr>元素用来表示认证或法律认证的时间。
认证和法律都要求文档被当事人以手工或电子方式亲自负责。虽然签名不是CDA头的一部分,
但CDA头却实需要通过<signature_cd>来获取被签属的签名。下表提取自服务提供者签名词汇
域,总结了<signature_cd>的充许值。
<signature_cd>可以区别有意的或实际的认证者。“S”值指签名是直接获得的,在文件中的
。而“X”指提供者是有意签名的或是法律认证。

3.2.2.4.3 有意的接受者
有意接受者指那些文档已被发送方。CDA头可以指定一个或多个有意接受者。下表提取自服务
提供者词汇域,总结了<intended_recipient.type_cd>的充许值。

3.2.2.4.4 创作者
3.2.2.4.4.1 起源人
CDA文档可以是起源于人或机器。<originator>元素用来指定起源人,<originating_device
>元素指定起源设备。CDA头要求详述一个或多个文档起源者,但并不要求一定有起源人。<pa
rticipation_tmr>指示起源时间。下表提取自服务提供者词汇域,总结了<originator.type_
cd>的充许值。

3.2.2.4.4.2 起源组织
CDA头可以指明主管和起源此文档的管理组织。下表提取自服务提供者词汇域,总结了<orig
inating_orgnization.type_cd>的充许值。

3.2.2.4.5 记录者
CDA头可以指示一个文档的录入者或记录者。<participation_tmr>元素用来提示记录时间或
录入时间。下表提取自服务提供者词汇域,总结了<transcriptionist.type_cd>的充许值。

3.2.2.4.6 健康医疗提供者
CDA头需要指定一个或多个参与健康医疗的提供者。<participation_tmr>元素用于提示参与
时间。下表提取自服务提供者词汇域,总结了<provider.type_cd>的充许值。
可选的<function_cd>描述了供者更详细的提商业职责。下表提取自服务提供者功能词汇域,
总结了<function_cd>的充许值。
注意:<function_cd>成份指明了实记录下来的实际执行的职责。它不同于一个与角色关联的
人的专业或职业。例如:麻醉师职责不一定要由麻醉学者来担当。

3.2.2.4.7 其它发动者
除了以上描述的服务提供者,有时候在一定的环境或某一类型文档中会有其它一些人扮演一
个角色。CDA头可以通过<service_actor>成份指定一个或从个这样的人。<participation_tm
r>指示参与时间。上面已描述过的<signature_cd>指示了是实际还是有意图要参与。作为提供
者人或组织的身份必须指明。下表指取自服务提供者词汇域,提示了<service_actor.type_c
d>的可用值。
您需要登录后才可以回帖 登录 | 欢迎注册

本版积分规则

快速回复 返回顶部 返回列表