|DotNet Namespace HL7Connect.Cda|
The CDA Object Model
|Base||base class for all CDA types|
|BaseList1||base class for all CDA list types|
|Extension||Extensions on v3 classes|
|BaseList||a list of extensions|
|HXIT||Information about the history of this value: period of validity and a reference to an identified event that established this value as valid.|
Because of the way that the types are defined, a number of attributes of the datatypes have values with a type derived from HXIT. In these cases the HXIT attributes are constrained to null. The only case where the HXIT attributes are allowed within a datatype is on items in a collection (DSET, LIST, BAG, HIST).
The use of these attributes is generally subject to further constraints in the specifications that make use of these types
|ANY||Defines the basic properties of every data value. This is conceptually an abstract type, meaning that no proper value can be just a data value without belonging to any concrete type. Every public concrete type is a specialization of this general abstract DataValue type. |
However exceptional values (nullFlavored values) may be of type ANY, except for the exceptional values that imply the nullFlavor INV, since this requires a type to be meaningful. Note that not all nullFlavors may be used with the type ANY (see section 7.1.4 for more details
|BL||BL stands for the values of two-valued logic. A BL value can be either true or false, or may have a nullFlavor.|
|ED||Data that is primarily intended for human interpretation or for further machine processing outside the scope of this specification. This includes unformatted or formatted written language, multimedia data, or structured information as defined by a different standard (e.g., XML-signatures.) |
Encapsulated data can be present in two forms, inline or by reference. The content is the same whether it is located inline or remote.Inline data is communicated or moved as part of the encapsulated data value, whereas by-reference data may reside at a different location: a URL/URI that provides reference to the information required to locate the data. Inline data may be provided in one of 3 different ways:
Content SHALL be provided if the ED has no nullFlavor. The content may be provided in-line (using only one of value, data or xml), or it may be provided as a reference.Content may be provided in-line and a reference also may be given; in these cases, it is expected that the content of the reference will be exactly the same as the in-line content. Information Processing Entities are not required to check this, but may regard it as an error condition if the content does not matc
|ST||The character string datatype stands for text data, primarily intended for machine processing (e.g., sorting, querying, indexing, etc.) or direct display. Used for names, symbols, presentation and formal expressions.|
A ST SHALL have at least one character or else have a nullFlavo
|SC||A character string that optionally may have a code attached. The text must always be present if a code is present. |
The code is often a local code. SC is used in cases where coding is exceptional (e.g., user error messages are essentially text messages, and the text message is the important content. However sometimes messages come from a catalog of prepared messages, which SC allows to reference).
Any non-null SC value MAY have a code, however, a code SHALL NOT be given without the text.
The similarities and differences between SC and CD are discussed in Section 18.104.22.168, CD and S
|CD||A CD is a reference to a concept defined in an external code system, terminology, or ontology. A CD may contain a simple code - that is, a reference to a concept defined directly by the referenced code system, or it may contain an expression in some syntax defined by the referenced code system that can be meaningfully evaluated. e.g., the concept of a "left foot" as a postcoordinated term built from the primary code "FOOT" and the qualifier "LEFT". |
A CD may also contain an original text or phrase that served as the basis of the coding. This is preserved to allow for validation of the representation of the concept in various fashions.
A CD can contain one or more translations into multiple coding systems. The translations are all representations of the same concept in various code systems. There is only one concept, and only the first CD may contain an original text. It is possible to represent the translation chain - which CD was translated from which - if desired. Each CD may also carry a rationale to indicate why it is represented.
A CD with no nullFlavor attribute SHALL have a code attribute or nonNull originalText attribute. A CD that has a code, codeSystem or originalText attribute but does not meet external constraints of the applicable value set SHALL have a nullFlavor attribute with a value of "OTH".
Attributes with type CD are generally bound by externally specified constraints which constrain the coded concepts to which a CD may refer. These constraints may be qualified as "extensible" (CWE) or "not extensible" (CNE). If the constraint is not extensible (CNE), then a the CD that does not have a nullFlavor SHALL contain a code that conforms to the constraint. If the constraint is extensible (CWE) then a CD that does not have a nullFlavor SHALL contain either a code that exists in the domain with which the attribute is associated, a code from a locally defined code system, or just some originalText that describes the concept. If the code is taken from a locally defined code system, then the codeSystem property SHALL specify the local code system.
For both CNE and CWE constraint types, the translations may contain nonNull codes from any source unless otherwise specified by the constraining model.
For code systems that define expression syntaxes, CNE constraints may be used, providing that the code system definitions define the appropriate support to enable value sets to make useful statements about how to control the expression syntax, and that the value set machinery used also has the appropriate suppor
|CS||Coded data in its simplest form, where only the code is not predetermined. |
The code system and code system version are implied and fixed by the context in which the CS value occurs.
Due to its highly restricted functionality, CS SHALL only be used for simple structural attributes with highly controlled and stable terminologies where:
|TEL||A locatable resource that is identified by a URI, such as a web page, a telephone number (voice, fax or some other resource mediated by telecommunication equipment), an e-mail address, or any other locatable resource that can be specified by a URL.|
The address is specified as a Universal Resource Locator (URL) qualified by time specification and use codes that help in deciding which address to use for a given time and purpose.
The value attribute is constrained to be a uniform resource locator specified according to IETF RFCs 1738 and 2806 when used in this datatype.
Note: The intent of this datatype is to be a locator, not an identifier; this datatype is used to refer to a locatable resource using a URL, and knowing the URL allows one to locate the object. However some use cases have arisen where a URI is used to refer to a locatable resource. Though this datatype allows for URIs to be used, the resource identified SHOULD always be locatable. A common use of locatable URI's is to refer to SOAP attachments
|II||An identifier that uniquely identifies a thing or object. |
Examples are object identifier for HL7 RIM objects, medical record number, order id, service catalog item id, Vehicle Identification Number (VIN), etc. Instance identifiers are usually defined based on ISO object identifiers.
An identifier allows someone to select one record, object or thing from a set of candidates. Usually an identifier alone without any context is not usable. Identifiers are distinguished from concept descriptors as concept descriptors never identify an individual thing, although there may sometimes be an individual record or object that represents the concept.
Information Processing Entities claiming direct or indirect conformance SHALL never assume that receiving applications can infer the identity of issuing authority or the type of the identifier from the identifier or components thereof
|XP||A part of a name or address. Each part is a character string that may be coded, and that also may have a nullFlavor. The string content must always be provided whether a code is provided or not.|
|ADXP||A part that may have a type-tag signifying its role in the address. Typical parts that exist in about every address are street, house number, or post box, postal code, city, country but other roles may be defined regionally, nationally, or on an enterprise level (e.g. in military addresses). |
Addresses are usually broken up into lines, which may be indicated by special line-breaking delimiter elements (e.g., DEL).
|AD||Mailing and home or office addresses. |
AD is primarily used to communicate data that will allow printing mail labels, or that will allow a person to physically visit that address. The postal address datatype is not supposed to be a container for additional information that might be useful for finding geographic locations (e.g., GPS coordinates) or for performing epidemiological studies. Such additional information should be captured by other, more appropriate data structures.
Addresses are essentially sequences of address parts, but add a "use" code and a valid time range for information about if and when the address can be used for a given purpose
|ENXP||A part that may have a type code signifying the role of the part in the whole entity name, and qualifier codes for more detail about the name part type. (Typical name parts for person names are given names, and family names, titles, etc. ).|
|EN||A name for a person, organization, place or thing. |
Examples: "Jim Bob Walton, Jr.", "Health Level Seven, Inc.", "Lake Tahoe", etc. An entity name may be as simple as a character string or may consist of several entity name parts, such as, "Jim", "Bob", "Walton", and "Jr.", "Health Level Seven" and "Inc.".
Entity names are essentially sequences of entity name parts, but add a "use" code and a valid time range for information about when the name was used and how to choose between multiple aliases that may be valid at the same point in time
|QTY||The quantity datatype is an abstract generalization for all datatypes whose domain values has an order relation (less-or-equal) and where difference is defined in all of the datatype's totally ordered value subsets. |
The quantity type abstraction is needed in defining certain other types, such as the interval, and probability distributions
|INT||Integer numbers (-1,0,1,2, 100, 3398129, etc.) are precise numbers that are results of counting and enumerating. Integer numbers are discrete, the set of integers is infinite but countable. No arbitrary limit is imposed on the range of integer numbers.|
|CO||Represents data where coded values are associated with a specific order. |
Note: CO may be used for things that model rankings and scores, e.g. likert scales, pain, Apgar values, etc, where there is a) implied ordering, b) no implication that the distance between each value is constant, and c) the total number of values is finite. CO may also be used in the context of an ordered code system. In this case, it may not be appropriate or even possible to use the value attribute, but CO may still be used so that models that make use of such code systems may introduce model elements that involve statements about the order of the terms in a domain.
The relative order of values in a code system need not be independently obvious in the literal representation of the CO. It these circumstances, is expected that an application will look up the ordering of these values from some definition of the code system.
Some of the code systems will directly assign numerical value to the concepts that are suitable for some mathemetical operations.
Though it would generally make sense, applications SHOULD not assume that the translations of the code, if provided, will have the same ordering as the CO. Translations SHALL not be considered when the ordering of the code system is determined
|REAL||Fractional numbers. Typically used whenever quantities are measured, estimated, or computed from other real numbers. The typical representation is decimal, where the number of significant decimal digits is known as the precision.|
|RTO||A quantity constructed as the quotient of a numerator quantity divided by a denominator quantity. |
Common factors in the numerator and denominator are not automatically cancelled out.
The RTO datatype supports titers (e.g., "1:128") and other quantities produced by laboratories that truly represent ratios. Ratios are not simply "structured numerics", particularly blood pressure measurements (e.g. "120/60") are not ratios.
1. Ratios are different from rational numbers, i.e., in ratios common factors in the numerator and denominator never cancel out. A ratio of two real or integer numbers is not automatically reduced to a real number. This datatype is not defined to generally represent rational numbers. It is used only if common factors in numerator and denominator are not supposed to cancel out. This is only rarely the case. For observation values, ratios occur almost exclusively with titers. In most other cases, REAL should be used instead of the RTO.
2. Since many implementation technologies expect generics to be collections, or only have one parameter, RTO is not implemented as a generic in this specification. Constraints at the point where the RTO is used will define which form of QTY are used
|PQ||A dimensioned quantity expressing the result of measuring|
An extension of the coded value datatype representing a physical quantity using a unit from any code system. Used to show alternative representation for a physical quantity. The coded value represents the unit (usually in some other coding system than UCUM)
|MO||A MO is a quantity expressing the amount of money in some currency. |
Currencies are the units in which monetary amounts are denominated in different economic regions. While the monetary amount is a single kind of quantity (money) the exchange rates between the different units are variable. This is the principle difference between PQ and MO, and the reason why currency units are not physical units
|TS||A quantity specifying a point on the axis of natural time. A point in time is most often represented as a calendar expression.|
|QSET||Abstract; specializes ANY|
Parameter: T : QTY
An unordered set of distinct values which are quantities.
Any ordered type can be the basis of an QSET; it does not matter whether the base type is discrete or continuous. If the base datatype is only partially ordered, all elements of the QSET must be elements of a totally ordered subset of the partially ordered datatype (for example, PQ is only ordered when the units are consistent. Every value in a QSET(PQ) must have the same canonical unit).
QSET is an abstract type. A working QSET is specified as an expression tree built using a combination of operator (QSI, QSD, QSU, QSP) and component types (QSC, QSS and IVL; and, for TS, PIVL and EIVL).
QSETs SHALL not contain null or nullFlavored values as members of the set
|QSU||Specifies a QSET as a union of other sets|
Specifies a QSET as an intersection of other sets
Specifies a QSET as the difference between two sets
Specifies a QSET as the periodic hull between two sets.
A periodic hull may be generated by comparing two sets that interleave. For QSET values A and B to interleave, the occurrence intervals of both groups can be arranged in pairs of corresponding occurrence intervals. It must further hold that for all corresponding occurrence intervals a ⊆ A and b ⊆ B, a starts before b starts (or at the same time) and b ends after a ends (or at the same time).
The interleaves-relation holds when two schedules have the same average frequency, and when the second schedule never "outpaces" the first schedule. That is, no occurrence interval in the second schedule may start before its corresponding occurrence interval in the first schedule
Specifies a QSET as an enumeration of simple values. This is a shortcut form for specifying the same values as singleton interval
Specifies a QSET as an coded value that describes a predefined QSET(TS)
|IVL||A set of consecutive values of an ordered base datatype. |
Any ordered type can be the basis of an IVL; it does not matter whether the base type is discrete or continuous. If the base datatype is only partially ordered, all elements of the IVL must be elements of a totally ordered subset of the partially ordered datatype. For example, PQ is considered ordered. However the ordering of PQs is only partial; a total order is only defined among comparable quantities (quantities of the same physical dimension). While IVLs between 2 and 4 meter exists, there is no IVL between 2 meters and 4 second
|PIVL||An interval of time that recurs periodically. PIVL has two properties, phase and period/frequency. phase specifies the "interval prototype" that is repeated on the period/frequency.|
|EIVL||Specifies a periodic interval of time where the recurrence is based on activities of daily living or other important events that are time-related but not fully determined by time. |
Example: "one hour after breakfast" specifies the beginning of the interval at one hour after breakfast is finished. Breakfast is assumed to occur before lunch but is not determined to occur at any specific tim
Parameter: T : ANY
A generic datatype extension used to specify a probability expressing the information producer's belief that the given value holds
Parameter: T : ANY
A set of UVP with probabilities (also known as a histogram.) All the elements in the set are considered alternatives and are rated each with its probability expressing the belief (or frequency) that each given value holds.
NPPD<T> may be used where only one value for T may be true. The sum of the probabilities should be <= 1, but due to estimating and rounding inaccuracies, the total may actually exceed
|SNBase||Defines basic identification and styling attributes shared by many structured document elements|
|Br||A hard line break, like in XHTML.|
|CMInline||Content model that allows text, footnotes, links, and superscript and subscript text. The choice stereotype denotes that exactly one of the attributes (including inherited attributes) SHALL have a value. All the others must be null.|
|CMContent||Content model that allows text, footnotes, links, superscript and subscript text, line breaks, multimedia content, and nested Content items. The choice stereotype denotes that exactly one of the attributes (including inherited attributes) SHALL have a value. All the others must be null.|
|CMGeneral||Content model that allows text, footnotes, links, superscript and subscript text, line breaks, multimedia content, nested Content items, paragraphs, lists, and tables. The choice stereotype denotes that exactly one of the attributes (including inherited attributes) SHALL have a value. All the others must be null.|
|RenderMultiMedia||References multimedia content that is integral to the document, and serves to show where the referenced multimedia is to be rendered. The multi media content must be contained within the context of the document. |
There is an optional caption, and contains a required referencedObject attribute (of type XML IDREFS), the values of which must equal the XML ID value(s) of ObservationMedia or RegionOfInterest CDA entries within the document context.
|LinkHtml||A hypertext reference to another document. These links are generally shown as hyperlinks that a user may activate when viewing the document.|
The link functionality provides a generic referencing mechanism, similar, but not identical, to the HTML anchor tag. It can be used to reference identifiers that are either internal or external to the document or the document context.
Multimedia that is integral to a document must be referenced by the renderMultiMedia element (see below). Multimedia that is simply referenced by the document and not an integral part of the document can by provided by a link. There is no requirement that a receiver render an internal or external link, or the target of an external lin
|Footnote||Indicates a footnote. The content contained within the Footnote is the content of the footnote. When the document is rendered, a link to the footnote is displayed inline with the flow of text adjacent to the footnote.|
Note: Receivers are required to interpret these elements when rendering by visually distinguishing footnoted text. The exact rendition is at the discretion of the recipient, and might include a mark at the location of the footnote with a hyperlink to the footnoted text, a simple demarcation (such as "This is the text [this is the footnote] that is being footnoted"), et
|TitleFootnote||Same functionality as a normal footnote, but the content model in the parts is restricted to the kind of content that can appear in a title|
|FootnoteRef||A reference to an existing footnote within the document context. This may be used when the same footnote is being used multiple times. The value of the footnoteRef.IDREF must be an footnote.ID value in the same document|
|Caption||A label for a paragraph, list, list item, table, or table cell. It may also be used within RenderMultiMedia to indicate a label for referenced ObservationMedia and RegionOfInterest entries. A Caption contains plain text and may contain links and footnotes.|
If a caption is defined, it SHALL be rendered, and SHALL be presented before any the element with which it is associated
|Content||Used to wrap a string of text so that it can be explicitly referenced, or so that it can suggest rendering characteristics. Content can be nested recursively, which enables wrapping a string of plain text down to as small a chunk as desired. |
Content has an optional identifier that can serve as the target of a reference. This identifier, represented as an XML ID attribute, must be unique within the document context. The originalText attribute of a datatype defined in this specification may make explicit reference to the content using the identifier, thereby indicating the original text associated with the datatype.
|Captioned||An abstract ancestor for all types that have captions.|
If a caption is defined, it SHALL be rendered, and SHALL be presented before any the element with which it is associate
|Paragraph||Similar to the HTML paragraph, which allows blocks of narrative to be broken up into logically consistent structures|
|Item||An item in a list.|
|List||Similar to an HTML list. There is an optional caption, and one or more items. The list must be ordered or not ordered; this must always be known,|
|TableItem||An abstract container for table items that may specify table layout details such as alignment. |
Any attributes applied to the table item also apply to any other nested table items unless specifically overridden
|ColItem||Abstract ancestor for common properties of col and colgroup.|
|Col||Applies a consistent style to every cell in a column.|
|ColGroup||Applies a consistent style to every cell in a group of columns.|
|TCell||A cell in a table ? may be either a normal cell or a header cell|
|TRow||A Row in a table|
|TRowGroup||A grop of rows ? may be used to associate consistent styling across a group of rows.|
|Table||A table. May have a caption, and SHALL have at least one row. A table may have optional header and footer rows. All rows are defined in groups. A table may also have col and colgroup elements to define styles for columns.|
|CDABase||Base support for CDA structural elements|
|ClinicalStatement||Abstract Ancestor for Act, Encounter, Observation, ObservationMedia, Organizer, Procedure_, RegionOfInterest, SubstanceAdministration or Supply|
|Act||A derivative of the RIM Act class, to be used when the other more specific classes aren't appropriate|
|AssignedAuthor||A entity acting in the employ of or on behalf of an organization.|
|AssignedCustodian||a scoping organization in the role of an assigned custodian|
|InformantChoice||Abstract Ancestor for either AssignedEntity or Related Entity|
|AssignedEntity||An assigned entity is a person assigned to the role by the scoping organization.|
|AssociatedEntity||a person or organization in the role of a participating entity|
|Authenticator||Represents a participant who has attested to the accuracy of the document, but who does not have privileges to legally authenticate the document. An example would be a resident physician who sees a patient and dictates a note, then later signs it.|
|Author||Represents the humans and/or machines that authored the document.
In some cases, the role or function of the author is inherent in the ClinicalDocument.code, such as where ClinicalDocument.code is "Medical Student Progress Note". The role of the author can also be recorded in the Author.functionCode or AssignedAuthor.code attribute. If either of these attributes is included, they should be equivalent to or further specialize the role inherent in the ClinicalDocument.code (such as where the ClinicalDocument.code is simply "Physician Progress Note" and the value of Author.functionCode is "rounding physician"), and shall not conflict with the role inherent in the ClinicalDocument.code, as such a conflict would constitute an ambiguous situation.
|AuthorChoice||Abstract ancestor for either Person or AuthoringDevice|
|AuthoringDevice||Used when a device (application/machine/etc) authored the document or section|
|Authorization||references the consents associated with this document|
|Birthplace||A Patient's birthplace is represented as a relationship between a patient and a place|
|ClinicalDocument||The ClinicalDocument class is the entry point into the CDA R-MIM, and corresponds
to the <ClinicalDocument> XML element that is the root element of a CDA document
A CDA document is logically broken up into a CDA Header and a CDA Body. The CDA Header is comprised of ClinicalDocument attributes, participants, and act relationships. The CDA Body is the target of the ClinicalDocument component act relationship.
|Component1||the setting of the clinical encounter during which the documented act(s) or ServiceEvent occurred|
|Component2||The CDA body can be either an unstructured blob, or can be comprised of structured markup. Every CDA document has exactly one body, associated with the ClinicalDocument class through the component relationship.|
|ComponentSect||A StructuredBody or section class is associated with one or more Section classes through a component relationship|
|Component4||The components of an organizer|
|Consent||This class references the consents associated with this document. The type of consent (e.g. a consent to perform the related ServiceEvent, 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.|
|Consumable||used to bring in the LabeledDrug or Material entity that describes the administered substance|
|Criterion||a condition that must hold true before some over activity occurs|
|Custodian||Represents the organization 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.|
|CustodianOrganization||The steward organization is an entity scoping the role of AssignedCustodian, and has a required CustodianOrganization.id|
|DataEnterer||Represents the participant who has transformed a dictated note into text.|
|Device||An entity used in an activity, without being substantially changed through that activity.|
|DocumentationOf||represents the main Act, such as a colonoscopy or an appendectomy, being documented.|
|EncompassingEncounter||This optional class represents the setting of the clinical encounter during
which the documented act(s) or ServiceEvent occurred. Documents are not
necessarily generated during an encounter, such as when a clinician, in
response to an abnormal lab result, attempts to contact the patient but
can't, and writes a Progress Note.
In some cases, the setting of the encounter is inherent in the ClinicalDocument.code, such as where ClinicalDocument.code is "Diabetes Clinic Progress Note". The setting of an encounter can also be transmitted in the HealthCareFacility.code attribute. If HealthCareFacility.code is sent, it should be equivalent to or further specialize the value inherent in the ClinicalDocument.code (such as where the ClinicalDocument.code is simply "Clinic Progress Note" and the value of HealthCareFacility.code is "cardiology clinic"), and shall not conflict with the value inherent in the ClinicalDocument.code, as such a conflict would constitute an ambiguous situation.
EncompassingEncounter.dischargeDispositionCode can be used to depict the disposition of the patient at the time of hospital discharge (e.g., discharged to home, expired, against medical advice, etc.).
|Encounter||A derivative of the RIM PatientEncounter class, used to represent related encounters, such as follow-up visits or referenced past encounters|
|EncounterParticipant||The encounterParticipant participant represents clinicians directly associated with the encounter (e.g. by initiating, terminating, or overseeing it).|
|Entity||A physical thing, group of physical things or an organization capable of participating in Acts while in a role.|
|Entry||In terms of the relationship between a section and its entries, CDA defines a
default general case, and a more specific case that can be used when applicable.
The entry relationship is defaulted to "COMP" (component), for the general case where the only assertion is that the related entries are contained within the source section and no other semantics are implied. In this case, the narrative is the original authenticated content. The CDA entries are created by various techniques (e.g., natural language processing, a human coder, a structured data entry tool that outputs both entries and a text report). The method of entry creation may be indicated by the entry participants (e.g., by identifying the algorithm or person that generated them). Relationships between various entries (such as two Observations or an Observation and an ObservationMedia) are encoded using the relationship types defined in entryRelationship.
|EntryRelationship||CDA has identified and modeled various link and reference scenarios. These scenarios
enable CDA entries to be semantically linked to entries that exist within the same
document (by traversing the entryRelationship class) or to objects external to
it (by traversing the reference class).
NOTE: The CDA specification permits any CDA entry to relate to any CDA entry using any of the following relationship types. In many cases, this would result in nonsensical relationships. The following table is a guideline for reasonable relationships between CDA entries, and is not a conformance constraint.
|ExternalActChoice||ExternalDocument is a derivative of the RIM Document class, used for representing external documents. ExternalDocument.text is modeled as an ED data type - allowing for the expression of the MIME type of the external document|
|ExternalAct||ExternalAct is a derivative of the RIM Act class, to be used when the other more specific classes are not appropriate.|
|ExternalDocument||ExternalDocument is a derivative of the RIM Document class, used for representing external documents. ExternalDocument.text is modeled as an ED data type - allowing for the expression of the MIME type of the external document|
|ExternalObservation||ExternalObservation is a derivative of the RIM Observation class, used for representing external coded and other observations.|
|ExternalProcedure||ExternalProcedure is a derivative of the RIM Procedure class, used for representing external procedures|
|Guardian||A patient's guardian is a person or organization in the role of guardian|
|HealthCareFacility||The setting of an encounter (e.g. cardiology clinic, primary care clinic, rehabilitation hospital, skilled nursing facility) can be expressed in HealthCareFacility.code. Note that setting and physical location are not the same. There is a many-to-many relationship between setting and the physical location where care is delivered. Thus, a particular room can provide the location for cardiology clinic one day, and for primary care clinic another day; and cardiology clinic today might be held in one physical location, but in another physical location tomorrow.|
|Informant12||An informant (or source of information) is a person that provides relevant information, such as the parent of a comatose patient who describes the patient's behavior prior to the onset of coma.
An informant can be a person in one of two roles. The RelatedEntity role is used to represent an informant without a role.id (e.g. a parent or guy on the street). The informant in this case bears some formal or personal relationship to the patient. The role is unscoped, with the assumption that the patient is always the implied scoper. RelatedEntity.code can be used to specify the nature of the relationship. The AssignedEntity role is used for an identified informant, and is scoped by an Organization.
|InformationRecipient||Represents a recipient who should receive a copy of the document.
NOTE: The information recipient is an entity to whom a copy of a document is directed, at the time of document authorship. It is not the same as the cumulative set of persons to whom the document has subsequently been disclosed, over the life-time of the patient. Such a disclosure list would not be contained within the document, and it outside the scope of CDA.
|InFulfillmentOf||represents an order that is fulfilled by this document. For instance, a provider orders an X-Ray. The X-Ray is performed. A radiologist reads the X-Ray and generates a report. The X-Ray order identifier is transmitted in the Order class, the performed X-Ray procedure is transmitted in the ServiceEvent class, and the ClinicalDocument.code would be valued with "Diagnostic Imaging Report".|
|IntendedRecipient||Where a person is the intended recipient, the playing entity is a person, optionally scoped by an organization (Organization class).|
|LabeledDrug||The LabeledDrug class, which is an Entity class playing the Role of Manufactured Product, identifies the drug that is consumed in the substance administration|
|LanguageCommunication||A patient's language communication skills can be expressed in the associated LanguageCommunication class|
|EntityIdentifier||A patient's language communication skills can be expressed in the associated EntityIdentifier class|
|LegalAuthenticator||Represents a participant who has legally authenticated the document.
The CDA is a standard that specifies the structure of exchanged clinical documents. In the case where a local document is transformed into a CDA document for exchange, authentication occurs on the local document, and that fact is reflected in the exchanged CDA document. A CDA document can reflect the unauthenticated, authenticated, or legally authenticated state. The unauthenticated state exists when no authentication information has been recorded (i.e., it is the absence of being either authenticated or legally authenticated).
While electronic signatures are not captured in a CDA document, both authentication and legal authentication require that a document has been signed manually or electronically by the responsible individual. A legalAuthenticator has a required legalAuthenticator.time indicating the time of authentication, and a required legalAuthenticator.signatureCode, indicating that a signature has been obtained and is on file.
|Location||The location participant (location class) relates a healthcare facility (HealthCareFacility class)
to the encounter to indicate where the encounter took place. The entity playing the role of
HealthCareFacility is a place (Place class). The entity scoping the HealthCareFacility role
is an organization (Organization class).
The setting of an encounter (e.g. cardiology clinic, primary care clinic, rehabilitation hospital, skilled nursing facility) can be expressed in HealthCareFacility.code. Note that setting and physical location are not the same. There is a many-to-many relationship between setting and the physical location where care is delivered. Thus, a particular room can provide the location for cardiology clinic one day, and for primary care clinic another day; and cardiology clinic today might be held in one physical location, but in another physical location tomorrow.
When the location is an organization, this is indicated by the presence of a scoping Organization, without a playing Place.
|MaintainedEntity||In CDA, Release One, it was possible to specify those individuals responsible for the device. This functionality has been deprecated in CDA, Release Two. The MaintainedEntity class is present for backwards compatibility, and its use is discouraged, except where needed to support the transformation of CDA, Release One documents|
|ManufacturedProduct||used to bring in the LabeledDrug or Material entity that describes the administered substance|
|Material||used to identify non-drug administered substances such as vaccines and blood products|
|NonXMLBody||The NonXMLBody class represents a document body that is in some format other
than XML. NonXMLBody.text is used to reference data that is stored externally
to the CDA document or to encode the data directly inline.
Rendering a referenced non-XML body requires a software tool that recognizes the particular MIME media type of the blob.
|Observation||A derivative of the RIM Observation class, used for representing coded and other observations.|
|ObservationMedia||A derivative of the RIM Observation class that represents multimedia that is logically part of the current document. This class is only for multimedia that is logically part of the attested content of the document. Rendering a referenced ObservationMedia requires a software tool that recognizes the particular MIME media type.|
|ObservationRange||An Observation can have zero to many referenceRange relationships, which relate an Observation to the ObservationRange class, where the expected range of values for a particular observation can be specified.|
|Order||This class represents those orders that are fulfilled by this document. For instance, a provider orders an X-Ray. The X-Ray is performed. A radiologist reads the X-Ray and generates a report. The X-Ray order identifier is transmitted in the Order class, the performed X-Ray procedure is transmitted in the ServiceEvent class, and the ClinicalDocument.code would be valued with "Diagnostic Imaging Report".|
|Organization||A social or legal structure formed by human beings.|
|OrganizationPartOf||An organization can be part of a larger organization. Where there is a need to include whole-part relationships, the OrganizationPartOf role can be used. OrganizationPartOf.statusCode indicates the state of the whole-part relationship (e.g. "active", "terminated"). OrganizationPartOf.effectiveTime is an interval of time specifying the period during which the whole-part relationhship is in effect, if such time limit is applicable and known.|
|Organizer||A derivative of the RIM Act class, which can be used to create arbitrary groupings of other CDA entries that share a common context. An Organizer can contain other Organizers and/or other CDA entries, by traversing the component relationship. An Organizer can refer to external acts by traversing the reference relationship. An Organizer cannot be the source of an entryRelationship relationship.|
|ParentDocument||The ParentDocument represents the source of a document revision, addenda, or transformation. ParentDocument.text is modeled as an ED data type - allowing for the expression of the MIME type of the parent document. It is not to be used to embed the related document, and thus ParentDocument.text.BIN is precluded from use.|
|Participant1||Can be used to represent any other participant that cannot be represented with one of the more specific participants|
|Participant2||Can be used to represent any other participant that cannot be represented with one of the more specific participants|
|ParticipantRole||Describes how the entity is participating in the act.|
|Patient||A person that receives health care services from a provider.|
|PatientRole||A person that is a patient (receiving healthcare from a provider)|
|Performer1||The performer is a person who carries out or will carry out a particular act. The performer need not be the principal responsible participant, e.g. a surgery resident operating under supervision of attending surgeon is a performer.|
|Performer2||The performer is a person who carries out or will carry out a particular act. The performer need not be the principal responsible participant, e.g. a surgery resident operating under supervision of attending surgeon is a performer.|
|Person||An entity that is a person|
|Place||a location - identified by a name and/or address|
|PlayingEntity||A physical thing, group of physical things or an organization capable of participating in Acts while in a role by playing the role|
|Precondition||The precondition class, derived from the ActRelationship class, is used along with the Criterion class to express a condition that must hold true before some over activity occurs.|
|Procedure||A derivative of the RIM Procedure class, used for representing procedures.|
|Product||The dispensed product is associated with the Supply act via a product participant, which connects to the same ManufacturedProduct role used for SubstanceAdministration|
|RecordTarget||The recordTarget represents the medical record that this document belongs to.
A clinical document typically has exactly one recordTarget participant. In the uncommon case where a clinical document (such as a group encounter note) is placed into more than one patient chart, more than one recordTarget participants can be stated.
|Reference||CDA entries can reference external objects such as external images and prior
reports. These external objects are not part of the authenticated document
content. They contain sufficient attributes to enable an explicit reference
rather than duplicating the entire referenced object. The CDA entry that
wraps the external reference can be used to encode the specific portions
of the external reference that are addressed in the narrative block.
Each object allows for an identifier and a code, and contains the RIM Act.text attribute, which can be used to store the URL and MIME type of the object. External objects always have a fixed moodCode of "EVN".
|ReferenceRange||An Observation can have zero to many referenceRange relationships, which relate an Observation to the ObservationRange class, where the expected range of values for a particular observation can be specified.|
|RegionOfInterest_value||A value. The meaning of unsorted is presently unknown (!)|
|RegionOfInterest||A derivative of the RIM Observation class that represents a region of interest on an image, using an overlay shape. RegionOfInterest is used to make reference to specific regions in images, e.g., to specify the site of a physical finding by "circling" a region in a schematic picture of a human body. The units of the coordinate values in RegionOfInterest.value are in pixels, expressed as a list of integers. The origin is in the upper left hand corner, with positive X values going to the right and positive Y values going down. The relationship between a RegionOfInterest and its referenced ObservationMedia or ExternalObservation is specified by traversing the entryRelationship or reference class, respectively, where typeCode equals "SUBJ". A RegionOfInterest must reference exactly one ObservationMedia or one ExternalObservation. If the RegionOfInterest is the target of a <renderMultimedia> reference, then it shall only reference a ObservationMedia and not an ExternalObservation.|
|RelatedDocument||represents the source of a document revision, addenda, or transformation|
|RelatedEntity||The RelatedEntity role is used to represent an informant without a role.id (e.g. a parent or guy on the street). The informant in this case bears some formal or personal relationship to the patient. The role is unscoped, with the assumption that the patient is always the implied scoper.|
|RelatedSubject||represents the primary target of the entries recorded in the document or section|
|ResponsibleParty||The responsibleParty participant represents the participant having primary legal responsibility for the encounter. This differs from the legalAuthenticator participant in that the legalAuthenticator may or may not be the responsible party, and is serving a medical records function by signing off on the document, moving it into a completed state.|
|Section||Sections can nest, can override context propagated from the
header, and can contain narrative and CDA entries.
The section has an ID attribute. This attribute serves as the target of a linkHtml reference in narrative. All values of attributes of type XML ID must be unique within the document (per the W3C XML specification).
|ServiceEvent||This class represents the main Act, such as a colonoscopy or an
appendectomy, being documented.
In some cases, the ServiceEvent is inherent in the ClinicalDocument.code, such as where ClinicalDocument.code is "History and Physical Report" and the procedure being documented is a "History and Physical" act. A ServiceEvent can further specialize the act inherent in the ClinicalDocument.code, such as where the ClinicalDocument.code is simply "Procedure Report" and the procedure was a "colonoscopy". If ServiceEvent is included, it must be equivalent to or further specialize the value inherent in the ClinicalDocument.code, and shall not conflict with the value inherent in the ClinicalDocument.code, as such a conflict would constitute an ambiguous situation.
ServiceEvent.effectiveTime can be used to indicate the time the actual event (as opposed to the encounter surrounding the event) took place.
|Specimen||A specimen is a part of some entity, typically the subject, that is the target of focused laboratory, radiology or other observations. In many clinical observations, such as physical examination of a patient, the patient is the subject of the observation, and there is no specimen. The specimen participant is only used when observations are made against some substance or object that is taken or derived from the subject.|
|SpecimenRole||A specimen is a part of some entity, typically the subject, that is the target of focused laboratory, radiology or other observations. In many clinical observations, such as physical examination of a patient, the patient is the subject of the observation, and there is no specimen. The specimen participant is only used when observations are made against some substance or object that is taken or derived from the subject.|
|StructuredBody||The StructuredBody class represents a CDA document body that is comprised of one or more document sections, optionally with sections|
|Subject||The subject participant represents the primary target of the entries recorded
in the document. Most of the time the subject is the same as the recordTarget
but need not be, for instance when the subject is a fetus observed in an
The subject participant can be ascribed to a CDA section or a CDA entry. It propagates to nested components, unless overridden. The subject of a document is presumed to be the patient.
|SubjectPerson||A person who is a subject|
|SubstanceAdministration||A derivative of the RIM SubstanceAdministration class, used for representing medication-related events such as medication history or planned medication administration orders.|
|Supply||A derivative of the RIM Supply class, used for representing the
provision of a material by one entity to another.
The Supply class represents dispensing, whereas the SubstanceAdministration class represents administration. Prescriptions are complex activities that involve both an administration request to the patient (e.g. take digoxin 0.125mg by mouth once per day) and a supply request to the pharmacy (e.g. dispense 30 tablets, with 5 refills). This should be represented in CDA by a SubstanceAdministration entry that has a component Supply entry. The nested Supply entry can have Supply.independentInd set to "false" to signal that the Supply cannot stand alone, without it's containing SubstanceAdministration.
|Factory||Used to build new instances of CDA related classes|
|Attachment||An attachment to a CDA document - usually with it in some kind of Zip package (i.e. XDM).|
|AttachmentList||A list of CDA Attachments|
|Document||Base CDA Document|