COCT_HD580000UV07 A_DataConsent |
(Link to Excel View) Derived from RMIM: COCT_RM580000UV07 |
||||||||
ConsentDirective | |||||||||
classCode [1..1] (M) Act (CS) {CNE:C:ActClass:CONS, fixed value= "CONS"} |
|||||||||
moodCode [1..1] (M) Act (CS) {CNE:V:x_ActMoodCompletionCriterion} |
|||||||||
id [0..1] Act (II.BUS_AND_VER) |
|||||||||
code [1..1] (M) Act (CV) {CWE:D:ActConsentType} |
|||||||||
negationInd [0..1] Act (BL){default= "false"} |
|||||||||
statusCode [1..1] (M) Act (CS) {CNE:V:ActStatus} |
|||||||||
effectiveTime [0..1] Act (IVL<TS.DATE.FULL>) |
|||||||||
reasonCode [0..1] Act (CV) {CWE:D:ActConsentInformationAccessOverrideReason} |
|||||||||
subject [1..1] (Subject) | |||||||||
responsibleParty [0..1] (ResponsibleParty) |
Design Comments: This is used to indicate the party responsible for authorizing an override. |
||||||||
author1 [0..1] (Author2) | |||||||||
author2 [0..*] (Author) | |||||||||
predecessor [0..*] (Predecessor) |
Design Comments: transformation Used when the target Act is a transformation of the source Act. (For instance, used to show that a CDA document is a transformation of a DICOM SR document). |
||||||||
compliance [0..*] (SourceOf) | |||||||||
reference [0..*] (Reference2) |
Design Comments: Used when one or more text CD is electronically captured in coded form where the content of the predecessor(s) is being succeeded by the coded CD but may not be an exact replica |
||||||||
authorizationOf [0..*] (Authorization) | |||||||||
Subject | |||||||||
typeCode [1..1] (M) Participation (CS) {CNE:C:ParticipationType:SBJ, fixed value= "SBJ"} |
|||||||||
contextControlCode [1..1] (M) Participation (CS) {CNE:C:ContextControl:OP, fixed value= "OP"} |
|||||||||
consentDirectiveSubjectChoice [1..1] (ConsentDirectiveSubjectChoice) | |||||||||
ConsentDirectiveSubjectChoice | |||||||||
choice of R_PatientUniversal | |||||||||
or R_ResponsibleUniversal | |||||||||
ResponsibleParty |
Design Comments: This is used to indicate the party responsible for authorizing an override. |
||||||||
typeCode [1..1] (M) Participation (CS) {CNE:V:ParticipationResponsibleParty, root= "RESP"} |
|||||||||
contextControlCode [1..1] (M) Participation (CS) {CNE:C:ContextControl:OP, fixed value= "OP"} |
|||||||||
assignedEntity [1..1] (R_AssignedEntityUniversal) | |||||||||
Author2 | |||||||||
typeCode [1..1] (M) Participation (CS) {CNE:C:ParticipationType:AUT, fixed value= "AUT"} |
|||||||||
functionCode [0..1] Participation (CD) {CWE:D:OverriderParticipationFunction} |
Design Comments: This code is used to specify the exact function an actor is authorized to have in authoring a consent override. Could be a staff person authorized by the responsible overriding authority. A provider may exercise perogative and prevent a subject of care from accessing health information in order to protect the patient or others; or to ensure that a provider is able to inform the subject of care directly. This might also be used to indicate that a clerical staff is authorized to enter hard copy prior consent directive into a structured consent based on document’s attestation of the subject. |
||||||||
contextControlCode [1..1] (M) Participation (CS) {CNE:C:ContextControl:OP, fixed value= "OP"} |
|||||||||
time [0..1] Participation (TS) |
|||||||||
signatureCode [0..1] Participation (CD) {CNE:D:ParticipationSignature} |
|||||||||
signatureText [0..1] Participation (ED) |
|||||||||
assignedEntity [1..1] (R_AssignedEntityUniversal) | |||||||||
Author | |||||||||
typeCode [1..1] (M) Participation (CS) {CNE:C:ParticipationType:AUT, fixed value= "AUT"} |
|||||||||
functionCode [0..1] Participation (CD) {CWE:D:ConsenterParticipationFunction} |
Design Comments: Used to specify the exact function an actor is authorized to have in authoring a consent directive. This would not be use for the default roles, e.g., where the consent is authored by the subject of consent or for the R_ResponsibleParty acting as a substitute decision maker on behalf of the subject whose manner of participation does not need further specification. However, where the way in which a designated substitute decision maker participates requires more detail, the ConsenterParticipationFunction can be used to indicate that the role is participating as a legal guardian of the subject of consent, a personal representative of the subject of consent, or a a person with healthcare power of attorney for the subject of consent. |
||||||||
contextControlCode [1..1] (M) Participation (CS) {CNE:C:ContextControl:OP, fixed value= "OP"} |
|||||||||
time [0..1] Participation (TS) |
|||||||||
modeCode [0..1] Participation (CV) {CWE:D:ParticipationMode} |
|||||||||
signatureCode [0..1] Participation (CD) {CNE:D:ParticipationSignature} |
|||||||||
signatureText [0..1] Participation (ED) |
|||||||||
consenter [1..1] (Consenter) | |||||||||
Consenter | |||||||||
choice of Patient | |||||||||
or R_ResponsiblePartyUniversal | |||||||||
Patient | |||||||||
classCode [1..1] (M) Patient (CS) {CNE:C:RoleClass:PAT, fixed value= "PAT"} |
|||||||||
Predecessor |
Design Comments: transformation Used when the target Act is a transformation of the source Act. (For instance, used to show that a CDA document is a transformation of a DICOM SR document). |
||||||||
typeCode [1..1] (M) ActRelationship (CS) {CNE:V:ActRelationshipSucceeds, root= "SUCC"} |
|||||||||
priorConsentDirective [1..1] (PriorConsentDirective) |
Design Comments: One or more consent directives may be predecessors of the focal consent directive. These may be unstructured text. If the hard-copy consent directive is used as evidence of the consenter's attestation to the focal ConsentDirective, e.g., in situations where legally, a signature is required but digital signatures is not technically supported or not legally binding, then attaching a scanned consent directive with a wet signature may satisfy the business requirement. |
||||||||
PriorConsentDirective |
Design Comments: One or more consent directives may be predecessors of the focal consent directive. These may be unstructured text. If the hard-copy consent directive is used as evidence of the consenter's attestation to the focal ConsentDirective, e.g., in situations where legally, a signature is required but digital signatures is not technically supported or not legally binding, then attaching a scanned consent directive with a wet signature may satisfy the business requirement. |
||||||||
classCode [1..1] (M) Act (CS) {CNE:V:ActClassConsent, root= "CONS"} |
|||||||||
moodCode [1..1] (M) Act (CS) {CNE:V:ActMoodEventOccurrence, root= "EVN"} |
|||||||||
id [0..*] Act (DSET<II>) |
|||||||||
code [0..1] Act (CD) {CWE:D:ActConsentDirectiveType} |
|||||||||
text [1..1] Act (ED) |
Design Comments: The text form of the PriorConsentDirective may be scanned and attached. |
||||||||
statusCode [0..1] Act (CS) {CNE:V:ActStatus, default= "completed"} |
|||||||||
effectiveTime [0..1] Act (IVL<TS>) |
Design Comments: The PriorConsentDirective effectiveTime and end time must be sent if known. This is of importance where the signature on the PriorConsentDirective is the legal basis for attestation of the focal ConsentDirective. |
||||||||
languageCode [0..1] Act (CD) {CWE:D:HumanLanguage} |
|||||||||
SourceOf | |||||||||
typeCode [1..1] (M) ActRelationship (CS) {CNE:V:ActRelationshipUpdate, root= "COMPLY"} |
|||||||||
privacyPolicy [1..1] (PrivacyPolicy) | |||||||||
PrivacyPolicy | |||||||||
classCode [1..1] (M) Act (CS) {CNE:V:ActClassPolicy, root= "POLICY"} |
|||||||||
moodCode [1..1] (M) Act (CS) {CNE:V:ActMoodEventOccurrence, root= "EVN"} |
|||||||||
id [0..*] Act (DSET<II>) |
|||||||||
code [0..1] Act (CD) {CWE:D:ActPrivacyPolicyType} |
|||||||||
text [0..1] Act (ED) |
|||||||||
statusCode [1..1] (M) Act (CS) {CNE:V:ActStatus, default= "completed"} |
|||||||||
Reference2 |
Design Comments: Used when one or more text CD is electronically captured in coded form where the content of the predecessor(s) is being succeeded by the coded CD but may not be an exact replica |
||||||||
typeCode [1..1] (M) ActRelationship (CS) {CNE:V:ActRelationshipRefersTo, root= "REFR"} |
Design Comments: Coded CD succeeds the prior text CD: Structured consent directive succeeds the prior text consent directive. SUCC df= new order that adds to, but does not completely replace its predecessor. |
||||||||
priorConsentDirective [1..1] (PriorConsentDirective) | |||||||||
Authorization | |||||||||
typeCode [1..1] (M) ActRelationship (CS) {CNE:V:ActRelationshipAuthorizedBy, root= "AUTH"} |
Design Comments: AUHT A relationship in which the target act authorizes or certifies the source act. |
||||||||
contextControlCode [1..1] ActRelationship (CS) {CNE:C:ContextControl:ON, fixed value= "ON"} |
|||||||||
contextConductionInd [1..1] ActRelationship (BL){default= "true"} |
|||||||||
permissionToTransfer [1..1] (PermissionToTransfer) | |||||||||
PermissionToTransfer | |||||||||
classCode [1..1] (M) Act (CS) {CNE:C:ActClass:TRFR, fixed value= "TRFR"} |
|||||||||
moodCode [1..1] (M) Act (CS) {CNE:C:ActMood:PERM, fixed value= "PERM"} |
|||||||||
id [0..*] Act (DSET<II>) |
|||||||||
code [0..1] Act (CD) {CWE:D:ActInformationTransferCode} |
|||||||||
receiver [0..*] (Receiver) | |||||||||
subject [1..*] (Subject2) | |||||||||
component [0..*] (Component2) | |||||||||
Receiver | |||||||||
typeCode [1..1] (M) Participation (CS) {CNE:C:ParticipationType:RCV, fixed value= "RCV"} |
|||||||||
functionCode [0..1] Participation (CD) {CWE:D:AuthorizedReceiverParticipationFunction} |
Design Comments: This code is used to specify the exact function an actor is authorized to have as a receiver of information that is the subject of a consent directive or consent override. This is used to indicate that the recipient is an authorized intermediary of the information, e.g., a Health Bank or PHRS, or a recipient system’s security service management service that will enforce the consent directive rules within the receiving organization. |
||||||||
contextControlCode [1..1] (M) Participation (CS) {CNE:C:ContextControl:OP, fixed value= "OP"} |
|||||||||
recipient [1..1] (Recipient) | |||||||||
Recipient | |||||||||
choice of R_AssignedEntityUniversal | |||||||||
or R_ServiceDeliveryLocationUniversal | |||||||||
Subject2 | |||||||||
typeCode [1..1] (M) ActRelationship (CS) {CNE:C:ActRelationshipType:SUBJ, fixed value= "SUBJ"} |
|||||||||
contextControlCode [1..1] (M) ActRelationship (CS) {CNE:C:ContextControl:ON, fixed value= "ON"} |
|||||||||
contextConductionInd [1..1] (M) ActRelationship (BL){default= "false"} |
|||||||||
informationArtifact [1..1] (InformationArtifact) | |||||||||
InformationArtifact | |||||||||
classCode [1..1] (M) Act (CS) {CNE:C:ActClass:ACT, fixed value= "ACT"} |
|||||||||
moodCode [1..1] (M) Act (CS) {CNE:V:x_ActMoodDefEvn} |
|||||||||
id [0..*] Act (DSET<II>) |
|||||||||
code [1..1] Act (CV) {CWE:D:ActInformationAccessCode} |
Design Comments: May be used to specify types of health information rather than an instance |
||||||||
reference [0..*] (Reference) | |||||||||
Reference | |||||||||
typeCode [1..1] (M) ActRelationship (CS) {CNE:V:ActRelationshipRefersTo, root= "REFR"} |
|||||||||
informationArtifactChoice [1..1] (InformationArtifactChoice) | |||||||||
InformationArtifactChoice | |||||||||
choice of A_CoverageUniversal | |||||||||
or A_AppointmentUniversal | |||||||||
or A_BillableUniversal | |||||||||
or A_SupportingClinicalStatementUniversal | |||||||||
or A_TransportationUniversal | |||||||||
Component2 | |||||||||
typeCode [1..1] (M) ActRelationship (CS) {CNE:V:ActRelationshipHasComponent, root= "COMP"} |
|||||||||
consentPermission [1..1] (ConsentPermission) | |||||||||
ConsentPermission | |||||||||
classCode [1..1] (M) ControlAct (CS) {CNE:V:ActClassControlAct, root= "CACT"} |
|||||||||
moodCode [1..1] (M) ControlAct (CS) {CNE:V:ActMoodPermission, root= "PERM"} |
|||||||||
id [0..*] ControlAct (DSET<II>) |
|||||||||
code [0..1] ControlAct (CD) {CWE:D:HL7TriggerEventCode} |
Design Comments: The trigger event referenced by the Consent Privilege |
||||||||
reasonCode [0..*] ControlAct (DSET<CD>) {CWE:D:PatientProfileQueryReasonCode} |
Design Comments: Purpose for a permitted operation on an information artifact, e.g., permission to access may be for the purposes of treatment, payment, operations, or research |
||||||||
performer [1..*] (Performer) | |||||||||
trigger [0..*] (Trigger) | |||||||||
precondition [0..*] (Precondition) | |||||||||
Performer | |||||||||
typeCode [1..1] (M) Participation (CS) {CNE:C:ParticipationType:PRF, fixed value= "PRF"} |
|||||||||
contextControlCode [1..1] Participation (CS) {CNE:V:ContextControl, default= "ON"} |
|||||||||
operationPerformer [1..1] (OperationPerformer) | |||||||||
OperationPerformer | |||||||||
classCode [1..1] (M) Role (CS) {CNE:C:RoleClass:ROL, fixed value= "ROL"} |
|||||||||
id [1..1] (M) Role (II) |
|||||||||
Trigger | |||||||||
typeCode [1..1] (M) ActRelationship (CS) {CNE:V:ActRelationshipHasTrigger, root= "TRIG"} |
|||||||||
sequenceNumber [0..1] ActRelationship (INT.NONNEG) |
|||||||||
splitCode [0..1] ActRelationship (CS) {CNE:V:ActRelationshipSplit} |
Design Comments: Attribute description: A code specifying how branches in an action plan are selected among other branches. Discussion: This attribute is part of the workflow control suite of attributes. An action plan is a composite Act with component Acts. In a sequential plan, each component has a sequenceNumber that specifies the ordering of the plan steps. Branches exist when multiple components have the same sequenceNumber. The splitCode specifies whether a branch is executed exclusively (case-switch) or inclusively, i.e., in parallel with other branches. In addition to exclusive and inclusive split the splitCode specifies how the pre-condition (also known as "guard conditions" on the branch) are evaluated. A guard condition may be evaluated once when the branching step is entered and if the conditions do not hold at that time, the branch is abandoned. Conversely execution of a branch may wait until the guard condition turns true. In exclusive wait branches, the first branch whose guard conditions turn true will be executed and all other branches abandoned. In inclusive wait branches some branches may already be executed while other branches still wait for their guard conditions to turn true. |
||||||||
conjunctionCode [0..1] ActRelationship (CS) {CNE:V:RelationshipConjunction} |
|||||||||
consentPermissionObligation [1..1] (ConsentPermissionObligation) |
Design Comments: Obligations, that is, actions to be performed after an action has been executed on data objects, are necessary for some cases. For example, the OECD Accountability Principle states that “A data controller should be accountable for complying with measures which give effect to the principles stated above”. A common approach to implement this principle in operating systems or DBMS is to log each data access as an event. Executing logging actions could be an obligation for the majority of privacy policies. |
||||||||
ConsentPermissionObligation |
Design Comments: Obligations, that is, actions to be performed after an action has been executed on data objects, are necessary for some cases. For example, the OECD Accountability Principle states that “A data controller should be accountable for complying with measures which give effect to the principles stated above”. A common approach to implement this principle in operating systems or DBMS is to log each data access as an event. Executing logging actions could be an obligation for the majority of privacy policies. |
||||||||
classCode [1..1] (M) Act (CS) {CNE:V:ActClassPolicy, root= "POLICY"} |
Design Comments: An obligation expectation unilaterally imposed by one party on the activity of another party; the behavior of another party; or the manner in which an act is executed as a result of a permitted act or operation. |
||||||||
moodCode [1..1] (M) Act (CS) {CNE:V:ActMoodCriterion, root= "CRT"} |
|||||||||
id [0..*] Act (DSET<II>) |
|||||||||
code [0..1] Act (CD) {CWE:D:ActPolicyType} |
Design Comments: A code further specifying an obligation that a that results from a permitted act or operation on an information artifact, e.g., the obligation to log and audit. |
||||||||
statusCode [0..1] Act (CS) {CNE:V:ActStatus} |
|||||||||
effectiveTime [0..1] Act (IVL<TS>) |
|||||||||
activityTime [0..1] Act (IVL<TS>) |
|||||||||
Precondition | |||||||||
typeCode [1..1] (M) ActRelationship (CS) {CNE:V:ActRelationshipHasPre-condition, root= "PRCN"} |
|||||||||
sequenceNumber [0..1] ActRelationship (INT.NONNEG) |
|||||||||
checkpointCode [0..1] ActRelationship (CS) {CNE:V:ActRelationshipCheckpoint} |
Design Comments: Attribute description: A code specifying when in the course of an Act a precondition for the Act is evaluated (e.g., before the Act starts for the first time, before every repetition, after each repetition but not before the first, or throughout the entire time of the Act). Discussion: This attribute is part of the workflow control suite of attributes. An action plan is a composite Act with component Acts. In a sequential plan, each component has a sequenceNumber that specifies the ordering of the plan steps. Before each step is executed, those with preconditions have their conditions tested; where the test is positive, the Act has clearance for execution. The repeatNumber may indicate that an Act may be repeatedly executed. The checkpointCode is specifies when the precondition is checked and is analogous to the various conditional statements and loop constructs in programming languages "while-do" vs. "do-while" or "repeat-until" vs. "loop-exit". For all checkpointCodes, except "end", preconditions are being checked at the time when the preceding step of the plan has terminated and this step would be next in the sequence established by the sequenceNumber attribute. When the checkpointCode for a criterion of a repeatable Act is "end", the criterion is tested only at the When the checkpointCode is "entry" the criterion is checked at the beginning of each repetition (if any) whereas "beginning" means the criterion is checked only once before the repetition "loop" starts. The checkpointCode "through" is special in that it requires the condition to hold throughout the execution of the Act, even throughout a single execution. As soon as the condition turns false, the Act should receive an interrupt event (see Act.interruptibleInd) and will eventually terminate. The checkpointCode "exit" is only used on a special plan step that represents a loop exit step. This allows an action plan to exit due to a condition tested inside the execution of this plan. Such exit criteria are sequenced with the other plan components using the ActRelationship.sequenceNumber |
||||||||
conjunctionCode [0..1] ActRelationship (CS) {CNE:V:RelationshipConjunction} |
Design Comments: Vocabulary domain: RelationshipConjunction (CNE) Attribute description: A code specifying the logical conjunction of the criteria among all the condition-links of Acts (e.g., and, or, exclusive-or). Constraints: All AND criteria must be true. If OR and AND criteria occur together, one criterion out of the OR-group must be true and all AND criteria must be true also. If XOR criteria occur together with OR and AND criteria, exactly one of the XOR criteria must be true, and at least one of the OR criteria and all AND criteria must be true. In other words, the sets of AND, OR, and XOR criteria are in turn combined by a logical AND operator (all AND criteria and at least one OR criterion and exactly one XOR criterion). To overcome this ordering, Act criteria can be nested in any way necessary. |
||||||||
consentPermissionCondition [1..1] (ConsentPermissionCondition) |
Design Comments: A ConsentPermissionCondition is a prerequisite to be met before any permitted action can be executed |
||||||||
ConsentPermissionCondition |
Design Comments: A ConsentPermissionCondition is a prerequisite to be met before any permitted action can be executed |
||||||||
classCode [1..1] (M) Observation (CS) {CNE:V:ActClassCondition, root= "COND"} |
Design Comments: An observable finding or state that persists over time and tends to require intervention or management, and, therefore, distinguished from an Observation made at a point in time; may exist before an Observation of the Condition is made or after interventions to manage the Condition are undertaken. |
||||||||
moodCode [1..1] (M) Observation (CS) {CNE:V:ActMoodCriterion, root= "CRT"} |
Design Comments: A criterion or condition over actual and potential services that must apply for an associated service to be considered. |
||||||||
id [0..*] Observation (DSET<II>) |
|||||||||
code [0..1] Observation (CD) {CWE:D:ActPrivilegeCategorizationType} |
Design Comments: This domain includes observations used to characterize a privilege such as the conditions that must obtain for the privilege to be exercised or the permitted action to be executed. |
||||||||
negationInd [0..1] Observation (BL) |
|||||||||
statusCode [0..1] Observation (CS) {CNE:V:ActStatus} |
|||||||||
effectiveTime [0..1] Observation (TS) |
Design Comments: Attribute description: A time expression specifying the focal or operative time of the Act, the primary time for which the Act holds, the time of interest from the perspective of the Act's intention. |
||||||||
value [0..1] Observation (ANY) {CWE:D:ObservationValue} |