CDA+-+actRelationship+Proposals

These proposals were drawn from the analysis in the following file: toc

**clinicalDocument/serviceEvent**
A serviceEvent further specializes the act inherent in the ClinicalDocument/code. The serviceEvent represents what is being documented (e.g. coloncopsy) SHOULD [0..*] contain a serviceEvent element SHOULD [0..*] have one or more serviceEvent/id elements. SHOULD [0..1] include serviceEvent/effectiveTime element. CONF-: The serviceEvent/effectiveTime element SHOULD be present with effectiveTime/low element and SHALL include effectiveTime/high element if a width element is not present. The serviceEvent/effectiveTime element SHALL be accurate to the day, and MAY be accurate to the second.

**clinicalDocument/inFulfillmentOf**
The inFulfillmentOf element represents orders that are fulfilled by this document. In an imaging note, the inFulfillmentOf element represents the Placer Order that was fulfilled by the imaging procedure(s) covered by a report document. CONF-: One or more inFullfillmentOf elements MAY be present.

**clinicalDocument/authorization**
The authorization/consent authorizes or certifies the action specified in the document. The type of consent (e.g., a consent to perform the related serviceEvent or a consent for the information contained in the document to be released to a third party) is conveyed in consent/code. Consents referenced in the CDA Header have been finalized (consent/statusCode must equal Completed) and should be on file. The following conformance statement does not represent an additional constraint over base CDA; it calls out CDA’s construct for handling consent as consents are usually required prior to a procedure. The CDA Body may also record information about the patient’s consent. CONF-: Patient consent, if present, SHALL be represented as ClinicalDocument/authorization/consent.

**clinicalDocument/relatedDocument**
A relatedDocument element is used to relate one document to another. The relatedDocument element allows three types of parent document: CONF-: One or more relatedDocument elements MAY be present.
 * A superseded version that the present document wholly replaces (typeCode = RPLC). For example, Diagnostic Imaging Reports may go through stages of revision prior to being legally authenticated. Such early stages may be drafts from transcription, those created by residents, or other preliminary versions. Policies not covered by this specification may govern requirements for retention of such earlier versions. Except for forensic purposes, the latest version in a chain of revisions represents the complete and current report.
 * An original version that the present document appends (typeCode = APND). When a report t is legally authenticated, it can be amended by a separate addendum document that references the original.
 * A source document from which the present document is transformed (typeCode = XFRM). For example, a Diagnostic Imaging Report may be created by transformation from a DICOM SR document or from another Diagnostic Imaging Report. An example of the latter case is the creation of a derived document for inclusion of imaging results in a clinical document

**clinicalDocument/componentOf**
CONF-: The componentOf SHOULD be present. CONF-: The encompassingEncounter element SHALL have an id element. In the case of transformed DICOM SR documents, an appropriate null flavor can be used if the id is unavailable. CONF-: The encompassingEncounter element SHALL have an effectiveTime element. CONF-: The effectiveTime element SHALL include a low element. CONF-: The encounterParticipant elements MAY be present. If present, the encounterParticipant/assignedEntity element SHALL have at least one assignedPerson or representedOrganization element present. CONF-: The responsibleParty element MAY be present. If present, the responsibleParty/assignedEntity element SHALL have at least one assignedPerson or representedOrganization element present.