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.
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.
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).
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)