Convert your FHIR JSON -> XML and back here. The CDA Book is sometimes listed for Kindle here and it is also SHIPPING from Amazon! See here for Errata.

Friday, May 20, 2011

Dynamic Behaviors Associated with Static Documents

One of the topics of discussions today in SDWG was issues around processing the CDA header. The discussion revolved around the complexity of the header and the requirements to understand the header. But this is not about static document content. Instead it is about application dynamic behavior, or more specifically application functional requirements.

Having identified the reality, and being able to point to four examples: Senders, Recievers, Displayers and Processors, we will now start looking at the responsibilities of each. This will be relatively easy becaue we've described sender and reciever responsibilities in the same way in more than a dozen guides, as well as display requirements. We also came up with two different processing examples that show that there is NOT a set of common requirements on the processing side.

Here are some examples of requirements that have been adopted in the past.

Originator Responsibilities
An originator can apply a template identifier (templateId) to assert conformance with a particular template. In the most general forms of CDA exchange, an originator need not apply a templateId for every template that an object in an instance document conforms to. This implementation guide asserts when templateIds are required for conformance.

Recipient Responsibilities
A recipient may reject an instance that does not contain a particular templateId (e.g., a recipient looking to receive only CCD documents can reject an instance without the appropriate templateId). A recipient may process objects in an instance document that do not contain a templateId (e.g., a recipient can process entries that contain Observation acts within a Problems section, even if the entries do not have templateIds).

Display Requirements
Good practice would recommend that the following be present whenever the document is viewed:
• Document title and document dates
• Service and encounter types, and date ranges as appropriate
• Names of all persons along with their roles, participations, participation date ranges, identifiers, address, and telecommunications information
• Names of selected organizations along with their roles, participations, participation date ranges, identifiers, address, and telecommunications information
• Date of birth for recordTarget(s)


  1. Regarding Recipients, persistent documents do not have all recipients known at the time of document origination. The initial recipients may store the documents for subsequent use by additional recipients. Documents as constituents of EHRs have this and an intended property. Multiple recipients may have multiple instance requirements, so firm accept/reject criteria are also unknown at origination. This is especially true when it comes to disclosure of PHI and the associated privacy and security requirements.

    Similar logic applies to Display requirements, not all of which are known at the times of origination nor receipt. In some cases the display must be anonymized or pseudonomized, and the data listed are not good practice in those instance.

  2. I've always wondered why the CDA Header display requirements (at least a minimum set) are not definitively specified but are only "best practices" whereas there are strict requirements to always display the narrative block of all Sections. Why is that?