注意：参照 HL7 V3 改进及本地化完整地讨论 V3 的一致性。
一致性的CDA文档是一种在最小程度中验证CDA 架构，在特定的词汇域限制它对代码词汇到值的使用。然而，计算机并不能验证所有方面的一致性。这方面的重点是突出CDA不能被计算机验证的方面——特别是与CDA人类能看懂的需求相关的方面。
一个文档起源于一个系统角色创建了一个CDA文档。CDA文档能够通过从其它格式转换而创建，作为应用程序的直接输出等。与永久存储位置通信通常是文档的来源，通常使用
HL7 V2 MDM 或者 HL7 V3 病历消息。文档的起因保证生成的CDA文档对这个规范具有很高的一致性。
文档的接收也是一个系统角色，它从一个文档生成器或者文档管理系统接收状态更新和文档。文档接收者负责保证接收到的文档依据此规范解析出来。
由于CDA是一个交换标准，可能不代表文档的原来形式，在此规范中对CDA文档没有永久存储需求。然而，就像之前提到的，文档管理与CDA规范有很强的互相依赖关系。在CDA头部定义的保管人参与承担维护原文档的责任，这个原文档可能是CDA之外的其它格式。
1.3.1接收方职责
假设在此规范中定义的缺省值，以及实例不包含值的地方：在CDA定义缺省值的地方，接收方必须假定在事件中的这些值没有包含任何值。（注意，缺省值在此文档中标记为“[default]”）
解析并说明完整的CDA头部：CDA文档的接收者必须能够解析并说明整个头部。因为应用程序可能选择性的显示从一个中心主目录中提取的人口信息学以及其它的CDA头信息, CDA文档头的描述由接收者决定。此外，头信息的描述可能依赖于本地的业务逻辑和应用上下文（如电子健康档案，无标识的情况）。在一个源文档希望建议一个描述的地方，可以包含一个或多个XML样式表。如何使用这些XML样式表取决于CDA文档的接收者。
解析和描述CDA正文足够译出CDA文档：CDA文档的接收方必须能够充分解析和描述CDA文档的主体，使用以下的规则：
（1）如果CDA主体不是 XML形式的，需要用一个能够识别特殊MIME媒体类型的软件工具来解析它；
（2）如果CDA主体是结构化的，一个节的标签，节的标题，必须被解析。Section.title
的缺失表示了一个无标签的节。
（3）如果CDA主体是结构化的，Section.text 域的内容必须遵守在“描述性节”中定义的规则。
并不要求CDA文档的接收者解析和描述CDA主体中的所有的CDA 条目。在本地实现范围内，商业合作伙伴可能要求接收者解析描述各种各样的条目