Question I am trying to understand CCD document Problem List Entry:
* What does the typeCode mean? * What does DRIV ("derived") mean? * What are other enums for this typeCode attribute? ** Answer** CCD and CCDA are profiles on CDA – rules about how CDA should be used in a particular way. CDA itself is a profile – a set of rules about how the basic v3 information structures are used to make clinical documents. (Yes, it’s kind of like [turtles all the way down](http://en.wikipedia.org/wiki/Turtles_all_the_way_down)). CDA actually uses a backbone of v3 "acts", where each Act is linked together by an ActRelationship the defines how they are related to each other. the RIM defines a structure that behaves rather like this: [](/media/2012/10/acts1.png) Acts have a set of attributes that express their base properties (more than just what is shown). Acts can also compose other acts, and each relationship between Act objects has a set of properties that includes the typeCode, that specifies the nature of the relationship between the acts. CDA is built out of these act relationships, where the kinds of relationships are limited to those that are useful for describing clinical documents: [](/media/2012/10/cda2.png) A clinical document is an act (aside: "act" is a bit misleading - that suggests a deliberate action, a person doing something, but it's better to think of 'acts' as something that might happen, and it's the thing that happens, not the process of it happening - so a clinical document is something that happened, someone wrote it). A clinical document act has a component ('a part of') which is the body, and that has one or more sections which are acts that are components ('part of') of the act that is the body. Note that because the typeCodes of these relationships are hard coded to "COMP", they don't appear in the CDA document - everyone knows what they are. A section may contain clinical statement entries (actual structured data) - these are also acts that have a relationship to Section Act that contains them. However in this case, there are two possible types of relationship: |COMP (component) [**default**]|The associated entry is a component of the section. No semantic relationship is implied. |DRIV (is derived from)|The narrative was rendered from the CDA Entries, and contains no clinical content not derived from the entries. So either we have a bunch of structured data that are part of the section, or we have something extra: the narrative is entirely derived from the entries. Aside: Strictly, this is an odd use of the typeCode of a relationship, because it's actually a statement about the relationship between the source section and *all* it's entries, but it's contained on each entry .This means that it's super confusing if only one entry has a typeCode of DRIV. So you should always ensure that all sibling entries have the same typeCode. When CCD(A) sets the typeCode to DRIV, then there is an implicit assertion here: the narrative content of the CDA Section that contains the problems must be generated from the data - so you couldn't build this by taking some existing narrative that may contain additional information not found in the entries - or (as is commonly done) adding additional information in the narrative that is not in the data to save figuring out how to represent it in the data. (fortunately CCDA mostly allows extra additional data to be added, [though this has it's downsides](/2012/10/30/interpreting-rim-objects-safely-exclusion-statements.html)). The final significant use of typeCode is to describe the relationships inside the clinical statement, where the type of the relationship can be one of these: |CAUS (is etiology for)|Used to show that the source caused the target observation (for instance, source "diabetes mellitus" is the cause of target "kidney disease"). |COMP (has component)|Used to show that the target is a component of the source (for instance "hemoglobin measurement" is a component of a "complete blood count"). |GEVL (evaluates (goal))|Used to link an observation (intent or actual) to a goal to indicate that the observation evaluates the goal (for instance, a source observation of "walking distance" evaluates a target goal of "adequate walking distance"). |MFST (is manifestation of)|Used to say that the source is a manifestation of the target (for instance, source "hives" is a manifestation of target "penicillin allergy"). |REFR (refers to)|Used to show a general relationship between the source and the target, when the more specific semantics of the relationship isn't known. |RSON (has reason)|Used to show the reason or rational for a service (for instance source "treadmill test" has reason "chest pain"). |SAS (starts after start)|The source Act starts after the start of the target Act (for instance source "diaphoresis" starts after the start of target "chest pain"). |SPRT (has support)|Used to show that the target provides supporting evidence for the source (for instance source "possible lung tumor" has support target "mass seen on chest-x-ray"). |SUBJ (has subject)|Used to relate a source region of interest to a target image, or to relate an observation to its subject observation (for instance, source "moderate severity" has subject target "chest pain"). |XCRPT (is excerpt of)|Used to show that the source is excerpted from the target (for instance source "hemoglobin value of 12" is an excerpt of target "complete blood count").