StructureDefinition-2.16.840.1.113883.10.20.29.1

Sourcehl7.cda.us.ccdar2dot2#current:Consolidated CDA Release 2.1 StructureDefinition Publication (v5.0.0)
resourceTypeStructureDefinition
id2.16.840.1.113883.10.20.29.1
canonicalhttp://hl7.org/fhir/cda/ccda/StructureDefinition/2.16.840.1.113883.10.20.29.1
version2.2
statusactive
publisherHealth Level Seven
nameUSRealmHeaderforPatientGeneratedDocument
titleUS Realm Header for Patient Generated Document
date2021-11-24T17:43:01+00:00
descriptionThis template is designed to be used in conjunction with the US Realm Header (V2). It includes additional conformances which further constrain the US Realm Header (V2). The Patient Generated Document Header template is not a separate document type. The document body may contain any structured or unstructured content from C-CDA.
jurisdictionsus
fhirVersion4.0.1
kindresource
abstractfalse
sdTtypeClinicalDocument
derivationconstraint
basehttp://hl7.org/fhir/cda/ccda/StructureDefinition/2.16.840.1.113883.10.20.22.1.1
Usages(none)
Name Flags Card. Type Description & Constraints doco
. . ClinicalDocument USRealmHeader
. . . Slices for templateId Slice: Unordered, Open by value:root, value:extension
. . . . templateId:secondary C 1..1 1198-32945: When asserting this templateId, all C-CDA 2.1 section and entry templates that had a previous version in C-CDA R1.1 **SHALL** include both the C-CDA 2.1 templateId and the C-CDA R1.1 templateId root without an extension. See C-CDA R2.1 Volume 1 - Design Considerations for additional detail (CONF:1198-32945).
. . . . . root 1..1 Required Pattern: 2.16.840.1.113883.10.20.29.1
. . . . . extension 1..1 Required Pattern: 2015-08-01
. . . recordTarget 1..1 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.
. . . . patientRole 1..1
. . . . . id 1..*
. . . . . patient 1..1
. . . . . . guardian 0..*
. . . . . . . id 0..*
. . . . . . . code 0..1 Binding: Personal And Legal Relationship Role Type ( required )
. . . . . . languageCommunication 0..*
. . . . . . . preferenceInd 0..1 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.
. . . . . providerOrganization 0..1 If present, this organization represents the provider organization where the person is claiming to be a patient. undefined
. . . author 1..* 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.
. . . . assignedAuthor 1..1
. . . . . id 1..*
. . . . . code 0..1 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.
. . . . . . code 1..1 Binding: Personal And Legal Relationship Role Type ( preferred )
. . . dataEnterer 0..1 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.
. . . . assignedEntity 1..1
. . . . . code 0..1 Binding: Personal And Legal Relationship Role Type ( preferred )
. . . Slices for informant The informant element describes the source of the information in a medical document. Assigned health care providers may be a source of information when a document is created. (e.g., a nurse's aide who provides information about a recent significant health care event that occurred within an acute care facility.) In these cases, the assignedEntity element is used. When the informant is a personal relation, that informant is represented in the relatedEntity element, even if the personal relation is a medical professional. The code element of the relatedEntity describes the relationship between the informant and the patient. The relationship between the informant and the patient needs to be described to help the receiver of the clinical document understand the information in the document. Each informant can be either an assignedEntity (a clinician serving the patient) OR a relatedEntity (a person with a personal or legal relationship with the patient). The constraints here apply to relatedEntity.
Slice: Unordered, Open by value:relatedEntity
. . . . informant:informant1 0..*
. . . . . relatedEntity 1..1
. . . . . . code 0..1
. . . . . . . code 0..1 Binding: Personal And Legal Relationship Role Type ( preferred )
. . . custodian 1..1 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.
. . . . assignedCustodian 1..1
. . . . . representedCustodianOrganization 1..1 The representedCustodianOrganization may be the person when the document is not maintained by an organization.
. . . . . . id 1..* The combined @root and @extension attributes record the custodian organization?s identity in a secure, trusted, and unique way.
. . . informationRecipient 0..* 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.
. . . . intendedRecipient 1..1
. . . . . id 0..* The combined @root and @extension attributes to record the information recipient?s identity in a secure, trusted, and unique way.
. . . . . . root 0..1 For a provider, the id/@root ="2.16.840.1.113883.4.6" indicates the National Provider Identifier where id/@extension is the NPI number for the provider. The ids MAY reference the id of a person or organization entity specified elsewhere in the document.
. . . legalAuthenticator 0..1 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.
. . . . assignedEntity 1..1
. . . . . id 1..* The combined @root and @extension attributes to record the information recipient?s identity in a secure, trusted, and unique way.
. . . . . code 0..1
. . . . . . code 0..1 Binding: Personal And Legal Relationship Role Type ( preferred )
. . . authenticator 0..*
. . . . assignedEntity 1..1
. . . . . id 1..* The combined @root and @extension attributes to record the authenticator?s identity in a secure, trusted, and unique way.
. . . . . code 0..1 Binding: Personal And Legal Relationship Role Type ( preferred )
. . . participant 0..* 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)
. . . . typeCode 1..1 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
. . . . associatedEntity 1..1
. . . . . code 0..1 Binding: Personal And Legal Relationship Role Type ( preferred )
. . . inFulfillmentOf 0..*
. . . . order 1..1
. . . . . id 1..* A scheduled appointment or service event in a practice management system may be represented using this id element.
. . . documentationOf 0..*
. . . . serviceEvent 1..1
. . . . . code 0..1 The code should be selected from a value set established by the document-level template for a specific type of Patient Generated Document.
. . . . . performer 0..*
. . . . . . functionCode 0..1 The functionCode SHALL be selected from value set ParticipationType 2.16.840.1.113883.1.11.10901 When indicating the performer was the primary care physician the functionCode shall be =?PCP?
. . . . . . assignedEntity 1..1
. . . . . . . id 1..* The combined @root and @extension attributes record the performer?s identity in a secure, trusted, and unique way.
. . . . . . . code 0..1 If the assignedEntity is an individual, the code SHOULD be selected from value set PersonalandLegalRelationshipRoleType value set
Binding: Personal And Legal Relationship Role Type ( preferred )

doco Documentation for this format

Produced 08 Sep 2023