Intersection of http://hl7.org/cda/us/ccda/StructureDefinition/USRealmHeaderforPatientGeneratedDocument and http://hl7.org/cda/us/ccda/StructureDefinition/USRealmHeaderforPatientGeneratedDocument
This is the set of resources that conform to both US Realm Header for Patient Generated Document (http://hl7.org/cda/us/ccda/StructureDefinition/USRealmHeaderforPatientGeneratedDocument) and US Realm Header for Patient Generated Document (http://hl7.org/cda/us/ccda/StructureDefinition/USRealmHeaderforPatientGeneratedDocument).
**SHALL** specify the particular kind of document (e.g., History and Physical, Discharge Summary, Progress Note) (CONF:4537-9992). Binding: ?? (example)
The recordTarget records the patient whose health information is described by the clinical document; each recordTarget must contain at least one patientRole element.
If the document receiver is interested in setting up a translator for the encounter with the patient, the receiver of the document will have to infer the need for a translator, based upon the language skills identified for the patient, the patient's language of preference and the predominant language used by the organization receiving the CDA.
HL7 Vocabulary simply describes guardian as a relationship to a ward. This need not be a formal legal relationship. When a guardian relationship exists for the patient, it can be represented, regardless of who is present at the time the document is generated. This need not be a formal legal relationship. A child's parent can be represented in the guardian role. In this case, the guardian/code element would encode the personal relationship of "mother" for the child's mom or "father" for the child's dad. An elderly person's child can be represented in the guardian role. In this case, the guardian/code element would encode the personal relationship of "daughter" or "son", or if a legal relationship existed, the relationship of "legal guardian" could be encoded.
left: (USCDI) Date of Birth - **MAY** be precise to the minute (CONF:4537-32418) (For cases where information about newborn's time of birth needs to be captured); right: 𝗨𝗦𝗖𝗗𝗜: Date of Birth - **MAY** be precise to the minute (CONF:4537-32418) (For cases where information about newborn's time of birth needs to be captured) Constraints: ts-shall-year, ts-should-day
left: (USCDI) Race - The sdtc:raceCode is only used to record additional values when the patient has indicated multiple races or additional race detail beyond the five categories required for Meaningful Use Stage 2. The prefix sdtc: SHALL be bound to the namespace “urn:hl7-org:sdtc”. The use of the namespace provides a necessary extension to CDA R2 for the use of the additional raceCode elements.; right: 𝗨𝗦𝗖𝗗𝗜: Race - The sdtc:raceCode is only used to record additional values when the patient has indicated multiple races or additional race detail beyond the five categories required for Meaningful Use Stage 2. The prefix sdtc: SHALL be bound to the namespace “urn:hl7-org:sdtc”. The use of the namespace provides a necessary extension to CDA R2 for the use of the additional raceCode elements. Binding: ?? (required)
Base for all types and resources Constraints: shall-city, shall-streetAddressLine, should-use, should-country, 81-7296, 81-10024, 81-10025, shall-max-ad-parts
Indicates a preference for information about care delivery and treatments be communicated (or translated if needed) into this language.
If more than one languageCommunication is present, only one languageCommunication element SHALL have a preferenceInd with a value of 1.
Base for all types and resources Constraints: shall-city, shall-streetAddressLine, should-use, should-country, 81-7296, 81-10024, 81-10025, shall-max-ad-parts
The author element represents the creator of the clinical document. The author may be a device, or a person. The person is the patient or the patient's advocate.
When the author is a person who is not acting in the role of a clinician, this code encodes the personal or legal relationship between author and the patient. Binding: ?? (example)
Base for all types and resources Constraints: shall-city, shall-streetAddressLine, should-use, should-country, 81-7296, 81-10024, 81-10025, shall-max-ad-parts
The dataEnterer element represents the person who transferred the content, written or dictated by someone else, into the clinical document. The guiding rule of thumb is that an author provides the content found within the header or body of the document, subject to their own interpretation, and the dataEnterer adds that information to the electronic system. In other words, a dataEnterer transfers information from one source to another (e.g., transcription from paper form to electronic system). If the dataEnterer is missing, this role is assumed to be played by the author.
Base for all types and resources Constraints: shall-city, shall-streetAddressLine, should-use, should-country, 81-7296, 81-10024, 81-10025, shall-max-ad-parts
The custodian element represents the organization or person that is in charge of maintaining the document. The custodian is the steward that is entrusted with the care of the document. Every CDA document has exactly one custodian. The custodian participation satisfies the CDA definition of Stewardship. Because CDA is an exchange standard and may not represent the original form of the authenticated document (e.g., CDA could include scanned copy of original), the custodian represents the steward of the original source document. The custodian may be the document originator, a health information exchange, or other responsible party. Also, the custodian may be the patient or an organization acting on behalf of the patient, such as a PHR organization.
Base for all types and resources Constraints: shall-city, shall-streetAddressLine, should-use, should-country, 81-7296, 81-10024, 81-10025, shall-max-ad-parts
The informationRecipient element records the intended recipient of the information at the time the document is created. For example, in cases where the intended recipient of the document is the patient's health chart, set the receivedOrganization to be the scoping organization for that chart.
In a patient authored document, the legalAuthenticator identifies the single person legally responsible for the document and must be present if the document has been legally authenticated. (Note that per the following section, there may also be one or more document authenticators.)
Based on local practice, patient authored documents may be provided without legal authentication. This implies that a patient authored document that does not contain this element has not been legally authenticated.
The act of legal authentication requires a certain privilege be granted to the legal authenticator depending upon local policy. All patient documents have the potential for legal authentication, given the appropriate legal authority.
Local policies MAY choose to delegate the function of legal authentication to a device or system that generates the document. In these cases, the legal authenticator is the person accepting responsibility for the document, not the generating device or system.
Note that the legal authenticator, if present, must be a person.
The signature can be represented either inline or by reference according to the ED data type. Typical cases for CDA are:
1) Electronic signature: this attribute can represent virtually any electronic signature scheme.
2) Digital signature: this attribute can represent digital signatures by reference to a signature data block that is constructed in accordance to a digital signature standard, such as XML-DSIG, PKCS#7, PGP, etc.
The sdtc:signatureText extension provides a location in CDA for a textual or multimedia depiction of the signature by which the participant endorses and accepts responsibility for his or her participation in the Act as specified in the Participation.typeCode. Details of what goes in the field are described in the HL7 CDA Digital Signature Standard balloted in Fall 2013.
Base for all types and resources Constraints: shall-city, shall-streetAddressLine, should-use, should-country, 81-7296, 81-10024, 81-10025, shall-max-ad-parts
The signature can be represented either inline or by reference according to the ED data type. Typical cases for CDA are:
1) Electronic signature: this attribute can represent virtually any electronic signature scheme.
2) Digital signature: this attribute can represent digital signatures by reference to a signature data block that is constructed in accordance to a digital signature standard, such as XML-DSIG, PKCS#7, PGP, etc.
The sdtc:signatureText extension provides a location in CDA for a textual or multimedia depiction of the signature by which the participant endorses and accepts responsibility for his or her participation in the Act as specified in the Participation.typeCode. Details of what goes in the field are described in the HL7 CDA Digital Signature Standard balloted in Fall of 2013.
Base for all types and resources Constraints: shall-city, shall-streetAddressLine, should-use, should-country, 81-7296, 81-10024, 81-10025, shall-max-ad-parts
The participant element identifies other supporting participants, including parents, relatives, caregivers, insurance policyholders, guarantors, and other participants related in some way to the patient.
A supporting person or organization is an individual or an organization with a relationship to the patient. A supporting person who is playing multiple roles would be recorded in multiple participants (e.g., emergency contact and next-of-kin) Constraints: 4537-10006, 4537-10007
Unless otherwise specified by the document specific header constraints, when participant/@typeCode is IND, associatedEntity/@classCode SHALL be selected from ValueSet 2.16.840.1.113883.11.20.9.33 INDRoleclassCodes STATIC 2011-09-30 Binding: ?? (required)
A serviceEvent represents the main act being documented, such as a colonoscopy or a cardiac stress study. In a provision of healthcare serviceEvent, the care providers, PCP, or other longitudinal providers, are recorded within the serviceEvent. If the document is about a single encounter, the providers associated can be recorded in the componentOf/encompassingEncounter template. Constraints: should-us-performer, should-code, should-performer
The performer participant represents clinicians who actually and principally carry out the serviceEvent. In a transfer of care this represents the healthcare providers involved in the current or pertinent historical care of the patient. Preferably, the patient's key healthcare care team members would be listed, particularly their primary physician and any active consulting physicians, therapists, and counselors.
If the assignedEntity is an individual, the code SHOULD be selected from value set PersonalandLegalRelationshipRoleType value set Binding: ?? (preferred)
The authorization element represents information about the patient's consent. The type of consent is conveyed in consent/code. Consents in the header have been finalized (consent/statusCode must equal Completed) and should be on file. This specification does not address how 'Privacy Consent' is represented, but does not preclude the inclusion of 'Privacy Consent'. The authorization consent is used for referring to consents that are documented elsewhere in the EHR or medical record for a health condition and/or treatment that is described in the CDA document.
The encompassing encounter represents the setting of the clinical encounter during which the document act(s) or ServiceEvent(s) occurred. In order to represent providers associated with a specific encounter, they are recorded within the encompassingEncounter as participants. In a CCD, the encompassingEncounter may be used when documenting a specific encounter and its participants. All relevant encounters in a CCD may be listed in the encounters section.
ClinicalDocument 
nullFlavor 
realmCode 
useablePeriod 
useablePeriod
