 ANSI/HL7 V3 MRDACM, R1-2008 HL7 Version 3 Standard: Medical Records; Data Access Consent, Release 1 11/10/2008 |
Content Last Edited: 2008-04-30T11:54:50
3.2 Storyboards
3.3 Application Roles
3.4 Trigger Events
3.5 Refined Message Information Models
3.6 Hierarchical Message Descriptions
3.7 Interactions
This topic interactions related to patient consent and information access permission, including:
- Recording patient consents and overrides
- Recording or changing a Shared Secret associated with all or part of a patient's records
Most of these interactions are crafted to support a 'request-based' architecture in which messages are sent from a point of service (POS) such as a clinic, pharmacy, etc. to a central information system (CIS), e.g., a patient registry or drug information system. These messages are phrased as requests because the CIS reserves the right to refuse all requests. Reasons might include the refusal of patient consent for access, collection, use, e.g., for research, or the lack of a recorded patient consent, etc.
NOTE: The Act classCode "consent" within HL7 may include informed consents and all similar medico-legal transactions between the patient (or the patient's delegate) and the provider for surgical procedures, informed consent for clinical trials, advanced beneficiary notice, against medical advice decline from service, release of information agreement, etc. Within the context of the Consent Topic RMIMs, the classCode "consent" refers only to consent related to the access, collection, use, and disclosure of patient information. However, this pattern could be reused with modification to support other types of consent.
|
||||||||
|
For details on the interpretation of this section, see the storyboard discussion in the Version 3 Guide.
Adam Everyperson has decided to exert greater control over his health and health care. As part of his self-reliant approach, Mr. Everyperson decides that he will maintain his own Personal Health Record. After examining various options, Mr. Everyperson decides to use the web-based Personal Health Record available from WebExcellent (WebPHR).
As part of opening an account for a PHR on the WebPHR website, Mr. Everyperson is asked to fill out an online eConsent Directive. The website presents him with an online survey that asks questions and provides guidance about how his answers may affect care delivery and health outcomes. WebPHR will require those to whom Adam Everyperson authorizes access to electronically agree to adhere to the terms of Mr. Everyperson's consent directive.
The online consent directive portal provides Adam with an overview of his privacy rights within one or more jurisdictions in which he has or may receive health care. Using an FAQ format, the online portal includes guidance about the range and potential consequences of decisions he is permitted to make by law. The portal would assist Adam's decision-making process by presenting a sequence of choices that will result in the establishment of his consent directives. The choices would include:
-
The manner in which he can control access to his information. For example, he may be permitted to consent or dissent to access based on user identification, role, context, or by use of a privacy password or "shared secret" that he can give to a person, organization, or device requesting access to his information that he has not previously authorized. This guidance would include an explanation about his options to restrict access to categories or instances of demographic or health information at the level of granularity supported by WebPHR and/or permitted by jurisdictional law.
-
Restricted access or "masking" may be applied to a category of health information, e.g., all HIV related information, or it may be on a particular data element, e.g., all instances of a provider's name. The granularity will require filtering mechanisms and algorithms that link associated information revealing of the masked topic.
-
Depending on whether the information is structured or unstructured, masking may be applied at the record or document level, or on subsections. Structured information, which is encoded data, can be masked at the data element level. Unstructured information, which is unencoded data that may be transmitted, e.g., as an image or bit map, can only be masked at the document or document section level.
-
If Adam Everyperson decides to mask certain information, he may have the option of deciding whether he will permit WebPHR to send a flag to an authorized party alerting the requester that masked information is available upon Adam's consent or by "breaking the glass" in an emergency. "Breaking the glass" occurs when a provider who is authorized by organizational policy or jurisdictional law overrides a consent directive. Typically, all masked information, whether flagged or not, will be accessible to a provider who overrides a consent directive.
-
The manner in which he can control the purposes for which his health information may be accesses, collected, used, or disclosed, e.g., only for purposes of treatment, payment, and operations.
-
The manner in which he can control the permissions he grant to those with access, which may include time-limited permission to read only, to collect, or to use; whether disclosure will be permitted, and if so, any constraints he may wish to apply, e.g., disclosure only with his explicit consent, or minimum necessary disclosure for payment and operations to entities with which he has an established health care relationship.
Using the portal consent directive survey, Mr. Everyperson consents to the following:
-
To provide basic demographic information to WebPHR only for the purpose of establishing an account. Adam explicitly opts out of WebPHR's offer to share his demographic information with affiliated companies for marketing purposes; and he dissents from the use of his demographic information by anyone to whom he authorizes PHR access for purposes other than for treatment, payment, and operations.
-
To authorize his primary physician, Dr. Doctor
-
To access, collect, use, and disclose unmasked health information for treatment, operations, and payment purposes.
-
However, Adam only consents to disclosure of the minimum necessary unmasked health information for operations and payment, and only if this information is conveyed along with his consent directives.
-
Entities to whom Dr. Doctor disclose Adam's unmasked health information will also receive notification that they are not to disclose that information to entities with whom they do not have a business associate agreement. The agreement must contractually constrain grantees' further use or disclosure of Adam's personally identifiable information use for payment or operations, e.g., if they transform his claims data into pseudo-clinical information, they may only disclose it to entities with which Adam has established a health care relationship, and only if those parties are likewise bound by Adam's consent directives.
-
Dr. Doctor may access, collect, and use masked information for treatment purposes only, and may only disclose with Mr. Everyperson's consent.
-
To authorize any emergency provider access to all unmasked health information, and to receive a flag that masked information may be accessed based on Mr. Everyperson's consent. However, emergency provider's access to masked information is limited to read only for a limited time, after which the privacy password will expire. Adam stipulates that masked information may only be used for treatment purposes, and may only be indirectly used for payment and operations, i.e., the services provided in an emergency situation may be billed, but without information related to masked conditions.
-
To authorize providers with whom Adam has an established relationship, e.g., specialists or care team members meeting role and context based criteria to access only unmasked health information with the same parameters Adam set for Dr. Doctor.
-
To delegate power of attorney for health care and consent directives to his spouse, Eva Everyperson should he be deemed incompetent in accordance with jurisdictional law.
To facilitate these choices, WebPHR employs electronic techniques to restrict what recipients are able to do with information accessed in Mr. Everyperson's PHR in accordance with the permissions that he has set in his consent directives. An example of such a mechanism would be the following scenario: A requester with "read only" access to masked information based on the requester's role, context, identity, or ad hoc consent by Mr. Everyperson would access that information by logging in to WebPHR with the requester's password. Upon submitting a request and being authorized, the requester would receive a response instructing the requester to use the privacy password or "shared secret" sent to the requester's email address in order to open the requested information. Upon inserting the key into the response page key field, the requester would have "read only" access to a document in portable document format for which print, print screen, forward as email, and save have been disabled. If Mr. Everyperson wishes to limit the time period in which this document is available to the recipient, he is able to select an expiry date for the keyword.
Upon completion of the WebPHR consent directive survey, Mr. Everyperson accepts WebPHR terms for establishing an account, and validates his decisions by submitting a credit card number to pay for the account, and his health plan identifiers for the coverage information with which WebPHR will populate his registration summary. To finalize the account set up, WebPHR requires Mr. Everyperson to respond to a confirmation email that will be sent to his email address.
Mr. Everyperson confirms his account by responding to an email sent to him by WebPHR, which results in the recording his consent directive in the WebPHR consent registry.
Mr. Everyperson develops a bad cough, and thinks he has pneumonia. Mrs. Eva Everyperson gives him some of her prescription codeine cough medicine, after which he begins to vomit and complains of being light-headed. Eva drives him to the Good Health Hospital emergency room (GHH ER).
Eva Everyperson gives the attending emergency room nurse, Nurse Nancy Nightingale, access to Adam's WebPHR account. Nurse Nancy requests his summary health information, which is loaded into the emergency room EHRS. She enters information about Mr. Everyperson's condition, and notes that he has taken codeine cough medicine. The GHH ER EHRS decision support system alerts Nurse Nancy that there is a probable adverse interaction related to masked information. Because Mr. Everyperson is very ill and somewhat incoherent, Nurse Nancy asks Mrs. Everyperson to consent to disclosure of the masked information as there are indications that it is pertinent to Mr. Everyperson's condition. Mrs. Everyperson agrees to disclose relevant masked information to Nurse Nancy by providing her with the privacy password to the records in Adam's PHR. Nurse Nancy sends the privacy password to WebPHR and receives the records. She notes that Mr. Everyperson's substance use medication list includes antabuse. Nurse Nancy concludes that the alcohol in the codeine cough medicine is what is causing him to vomit violently.
While she is explaining this to Mrs. Everyperson, Adam drifts in and out of consciousness. Nurse Nancy alerts the ER physician, Dr. Aaron Attend. After reviewing the information provided by WebPHR, and hearing that there is masked information related to substance use, Dr. Attend is concerned that there is other unflagged mask information that may be of critical importance. He transmits an override on Mr. Everyperson's consent directive to WebPHR, as permitted by jurisdictional law. WebPHR sends Dr. Attend the all of Mr. Everyperson's health information, including information about Mr. Everyperson's methadone medication, which was masked but not flagged. Dr. Attend's override directive includes the reason for the override as a potentially life threatening drug-drug interaction, and the GHH ER EHRS logs the override for review by the GHH privacy officer. Dr. Attend suspects that Mr. Everyperson has overdosed on the mixture of codeine and methadone, and treats him accordingly.
Since Mr. Everyperson's masked health information was accessible from his PHR as "read only" for a limited time and his directive limits use to treatment only, Dr. Attend and Nurse Nancy will generate health service charges for payment and operations purposes that detail only the minimum necessary information relating solely to the services provided and a high-level diagnosis that does not disclose the masked condition.
|
||||||||||
|
For details on the interpretation of this section, see the discussion of application roles and their relationships in the Version 3 Guide.
An application role that captures an initial or revised consumer data consent or dissent, and/or shared secret; or an authorized entity's override of a consumer data consent or dissent. This application role transmits this information and status changes to other applications, typically a Consent Manager.
An application role that receives notification of an initial or revised consumer data consent or dissent, and/or shared secret; or an authorized entity's override of a consumer's data consent or dissent. This application role may act as a Registry, maintaining a directory of completed consent information held by contributing Consent Managers, and provide access to this information to other applications in response to queries.
An application role that maintains a record of an initial or revised consumer data consent or dissent, and/or shared secret; or an authorized entity's override of a consumer data consent or dissent. This application role acts as a repository by maintaining current consent and shared secret information; by responding to authorized queries for this information; and by notifying other applications about this information and status changes to other applications , typically a Consent Tracker or another Consent Manager.
|
||||||||||||||||||||||||||||||||||||
|
For details on the interpretation of this section, see the discussion of trigger events in the Version 3 Guide.
| Type: | User request |
| Type: | User request |
| Type: |
| Type: | Interaction based |
| Type: |
| Type: |
| Type: |
| Type: | User request |
| Type: | Interaction based |
| Type: | Interaction based |
| Type: |
| Type: |
| Type: |
| Type: | User request |
| Type: |
| Type: | Interaction based |
|
||||||||
|
For details on the interpretation of this section, see the description of RMIMs in the Version 3 Guide.
| Parent: | Medical Records (RCMR_DM000050UV) |
The Shared Secret RMIM captures the data and associations needed to record a patient's shared secret, also known as keyword or password, that is used by the patient to unlock masked health information.
The Attributes of the Focal Class SharedSecretEvent
The SharedSecretEvent classCodeCONS: The act type "consent" refers in this context to consent related to the collection, access, use, and disclosure of patient information.
The SharedSecretEvent moodCode event ENV indicates that the shared secret event actually happened.
The SharedSecretEvent id optionally conveys one or more unique identifiers of a shared secret.
The SharedSecretEvent code must be selected from the ActConsentType: The type of consent being granted to access, collect, use or disclose health information.
The SharedSecretEvent statusCode: A statusCode set to completed must be sent.
The SharedSecretEvent shall be linked with the subject participation typeCodeSBJ to the R_Patient (universal) CMET indicating that one and only one patient shall be the subject of the SharedSecretEvent.
The subject participation contextControlCodeOP indicates that any party participating as a subject in the SharedSecretEvent overrides all subjects from any ancestral subject participations and propagate to all descendant acts reached by conducting ActRelationships.
The author participation typeCodeAUT shall link the SharedSecretEvent to one and only one consenting party, which may be either a Patient of roleClassPAT or a responsible party conveyed by the R_ResponsibleParty (universal) CMET.
The SharedSecretEvent author participation contextControlCodeON indicates that any consenting party participating as an author in the ConsentEvent overrides all authors from any ancestral author participations, and does not propagate to any descendant acts reached by conducting ActRelationships.
The SharedSecretEvent author participation with one and only one required signatureText of datatype ED is a textual or multimedia depiction of the signature by which the consentor endorses his or her participation in the consent, e.g., a biometric image, a digital or electronic signature, a scanned image of a paper-based signature, or a textual shared secret, keyword, or password.
The SharedSecretEvent shall have a relationship typeCodeSUBJ with one to many subject RecordType acts.
The SharedSecretEvent subject participation contextControlCodeON indicates that the Shared Secret applies only to the target RecordType, and overrides any propagating ancestor acts to which it is subject, e.g., a previous consent act, but will not propagate further. The contextConductInd is a Boolean set to "true" meaning that the target RecordType may have the SharedSecretEven as a subject.
Attributes of RecordType
The RecordType classCodeACT: This act type indicates that any act in definition mood DEF may be the subject of a permitted release of information.
The RecordType code shall be specified with a code from the ActInformationAccessTypeCode domain to provide more precise description of the type of information within the RecordType that is the subject of the permitted disclosure.
Click <loc href="notes\RCMR_RM010002UV.htm">here</loc> for detailed HTML business walkthrough
| Shared Secret | RCMR_HD010002UV01 |
| Parent: | Medical Records (RCMR_DM000050UV) |
The Data Consent RMIM captures the data and associations needed to (1) record or report a consumer's consent or dissent to authorize the access, collection, use, or disclosure of personally identifiable information; (2) convey a provider's request or intent to override a patient's recorded consent or dissent; (3) report a provider's actual override of a patient's recorded consent or dissent for audit purposes; (4) convey a type of consent directive associated with a privacy policy; or (5) to record or report a consumer's consent directive, which is to be applied to future access, collection, use or disclosure of personally identifiable information. Note that a consumer may or may not be a patient and the information to which the consent directive applies may or may not be health information. It must be personally identifiable information. For the purposes of this walk through, "consumer" means both an actual and a potential consumer of services such as health care.
The subject of a consumer's consent directive include specific instances or categories of information, including orders and results for lab, medications, diagnostic imaging; allergy and intolerance, medical condition, observations, demographics, immunizations, providers, and encounters.
The currently supported interactions are: (1) Requests to record, revise, or remove (a) a consumer's consent directive event or criterion, which may include one or more consents or dissents (which may be a specific refusal to consent or a revocation of a previous consent) to the collection, access, use, or disclosure of all or a portion of the consumer's personally identifiable information for specified purposes; or (b) a service provider's intented, requested, or actual override of a consumer's consent directives, (2) Confirmations or rejections of these requests; and (3) notifications relating to the recording or revision of consent directives or provider overrides.
The Attributes of the Focal Class ConsentDirective
The ConsentDirective classCodeCONS: The act type "consent" refers in this context to consent related to the access, collection, use, and disclosure of consumer ation.
The ConsentDirective moodCodex_ActMoodCompletionCriterion may be used (1) in the event mood EVN to indicate that a consumer has consented or dissented to authorize the collection, access, use, or disclosure of personally identifiable ation; and to report a provider's actual override of a patient's recorded consent or dissent, which may be used for audit purposes; (2) in the intent INT or request RQO mood to convey a provider's intent or request to override a patient's recorded consent or dissent; (3) in the definition mood DEF to convey a type of consent directive associated with a privacy policy; or (4) in the criterion mood CRIT to record or report a consumer's consent directive, which is to be applied to future collection, access, use or disclosure of the consumer's personally identifiable information.
The ConsentDirective id: A consent directive identifier is required to be sent if known. This uniquely identifies a consent directive or consent directive override instance.
The ConsentDirectivecodeActConsentType: The type of consent being granted, refused, revoked, or overridden shall be specified by a code from the ActConsentType domain, e.g., consent to collect, access, use, or disclose, e.g., for research purposes.
The ConsentDirectivenegationInd with default set to "false": The presence of the negation indicator set to "false" indicates that the consumer consents to grant the permission indicated by the ActConsentType. A negation indicator is set to "true" indicates a consumer's dissent. If a consumer had previously consented to access, that permission may be revoked by sending a second Data Consent message with the same Consent Directive, as indicated by an identical consent directive identifier, and setting the negationIND to "true". Note that the negationInd must either be non-null or not sent, the later case may be an indication that the consumer's consent was deemed or implied, i.e., the consumer did not have or is not provided an opportunity to actively consent or dissent to any or all permissions: collection, access, use, and disclosure. If the negationInd is "false", then the PermissionToInform is mandatory. Note that this is a constraint.
The ConsentDirective statusCode: A statusCode from the specializable ActStatusNormal value set must be sent.
The ConsentDirective effectiveTime: The Consent Effective and End Time must be sent if known.
The ConsentDirective reasonCode: If the ConsentDirective author is a provider or other authorized assigned entity, then a code from the ActConsentInformationAccessOverrideReason domain must be sent if known to indicate the provider's reason for overriding a patient's consent directive. Note that this is a constraint.
The ConsentDirective shall be linked with the subject participation typeCodeSBJ to the choice of either the R_ResponsibleParty (universal) or R_Patient (universal) CMET indicating that one and only one consumer or patient shall be the subject of the ConsentDirective.
The subject participation contextControlCodeOP indicates that any party participating as a subject in the ConsentDirective overrides all subjects from any ancestral subject participations and propagate to all descendant acts reached by conducting ActRelationships.
Constraint: The ConsentDirective must be linked by an AUT participation to one and only one type of authoring role, either a consenting party or an assigned entity.
The author2 participation typeCodeAUT is required to link the ConsentDirective to zero to 3 consenting party, which may be either a Patient of roleClassPAT who is the same person entity referenced in the R_Patient CMET; or a consumer or delegate of a consumer or patient as represented by the R_ResponsibleParty CMET. Note that the R_ResponsibleParty is used here rather than the more constrained R_AssignedParty, because the former does not specify the type of scoping organization, if any, while the latter may only be scoped by an organization, thereby implying that an organization is to some extent accountable for the functions undertaken by a player of an AssignedParty role.
The author2 participation functionCode may be sent using codes from the AuthorizedParticipationFunction value set to indicate the function served by the a R_ResponsibleParty participation in the authoring of a consent directive, e.g., as a legal guardian.
The mandatory author2 participation contextControlCodeOP indicates that any consenting party participating as an author in the ConsentDirective overrides all authors from any ancestral author participations and propagate to all descendant acts reached by conducting ActRelationships.
The author2 participation time may be sent to indicate the interval of time during which the consenting party authored the consent directive.
The author2 participation modeCode must be sent if available to indicate the modality by which the consenter participated in authoring the consent directive, using codes from the ParticipationMode domain to specifies whether the consent was provided e.g., in person, over the telephone; or verbally, electronically, or on paper .
The author2 participation signatureCode must be sent if available to specify whether and how the participant has attested to his or her participation through a signature, and whether a signature is required.
The author2 participation signatureText may be sent used to send a textual or multimedia depiction of the signature by which the participant endorses his or her participation in the Act as specified an author, and that he or she agrees to assume the associated accountability.
The author1 participation typeCodeAUT is required to link the ConsentDirective to zero or one assignedEntity, which is conveyed by the R_AssignedEntity (universal) CMET.
The author1 participation functionCode may be sent using codes from the AuthorizedParticipationFunction value set to indicate the function served by the a R_AssignedParty in the authoring of a consent directive override, e.g., as an emergency provider authorized to "break the glass" to access critical health information.
The mandatory author1 participation contextControlCodeOP indicates that any assigned entity participating as an author in the ConsentDirective overrides all authors from any ancestral author participations and propagate to all descendant acts reached by conducting ActRelationships.
The author1 participation time may be sent to indicate the interval of time during which the AssignedEntity authored the consent directive override.
The author1 participation signatureCode must be sent if available to specify whether and how the participant has attested to his or her participation through a signature, and whether a signature is required.
The author1 participation signatureText may be sent used to send a textual or multimedia depiction of the signature by which the participant endorses his or her participation in the Act as specified an author, and that he or she agrees to assume the associated accountability.
The ConsentDirective is required to have a component relationship typeCodeCOMP of zero or one PermissionToTransfer: If the negationInd is "false", then the ConsentDirective must be comprised of at least one permission to inform zero to many recipients. This ActRelationship is not set to mandatory because a dissent from any disclosure of health information may not require the conveyance of any more specific information about who is not permitted to receive this information or the type of information that may not be disclosed. Note that this is a constraint.
Attributes of PermissionToTransfer
The PermissionToTransfer classCode: This class has an act type of TRFR or "transfer", which is defined as "The act of transferring or providing access to information about a topic to a subject".
The PermissionToTransfer moodCode: The mood of this act is permission PERM, indicating that informing recipients about the subject act is authorized by the ConsentDirective author.
The PermissionToTransfer code may be specified from the ActInformationAccessContextCode domain to provide information about the context in which the information transfer or access is permitted.
The PermissionToTransfer shall have a subject of relationship typeCodeSUBJ with one to many RecordType acts. The contextControlCodeOP indicates that the permitted release of information applies only to the target RecordType and overrides any propagating ancestor acts to which it is subject, e.g., a previous refusal to permit release of information, but will not propagate further. The contextConductInd is a Boolean set to "false" meaning that the target RecordType may not have the PermissionToTransfer as a subject.
Attributes of RecordType
The RecordType classCodeACT: This act type indicates that any act in definition mood DEF may be the subject of a permitted release of information.
The RecordType code shall be specified with a code from the ActInformationAccessCode domain to provide more precise description of the type of information within the RecordType that is the subject of the permitted disclosure.
The receiver participation typeCodeRCV is required to link the PermissionToTransfer to zero or more recipients being granted permission, which may be either an assigned person conveyed by the R_AssignedPerson (universal) CMET or a service delivery location conveyed by the R_ServiceDeliveryLocation (universal) CMET.
The receiver participation contextControlCodeOP indicates that any recipients receiving permission to be informed override all recipients from any ancestral receiver participation and propagate to all descendant acts reached by conducting ActRelationships. Note: Where a user may gain access to a patient's record due to the user's role based access rights, there would be no need to link the permission to release information to that user as a recipient.
The ConsentDirective may have a "documents" relationship typeCodeDOC of zero to many instances of a ConsentDirectiveDocument:
Attributes of ConsentDirectiveDocument
The ConsentDirectiveDocument classCodeDOC: This act type indicates that any document in event mood EVN may be referenced by a ConsentDirective.
The ConsentDirectiveDocument id: A consent directive document identifier must be sent if known. This uniquely identifies a consent directive document.
The ConsentDirectiveDocument statusCode: A statusCode of completed value set may be sent.
The ConsentDirectiveDocument text: One or more text, such as an image or URI with datatype of ED must be sent.
The ConsentDirectiveDocument effectiveTime: The ConsentDirectiveDocument Effective and End Time may be sent.
The ConsentDirectiveDocument languageCode: A code from the HumanLanguage value set indicating the language used in the ConsentDirectiveDocument may be sent.
The ConsentDirective may have a "complies" relationship typeCodeCOMPLY of zero to many instances of a PrivacyPolicyChoice consisting of PrivacyPolicy and PrivacyPolicyDocument:
The PrivacyPolicy classCodePOLICY: This act type indicates zero to many privacy policies in the event mood EVN may be complied with by a ConsentDirective.
The PrivacyPolicy code may be specified with a code from the ActPolicyTypeCode domain to specify the type of privacy policy, e.g., a policy relating to grounds for overriding a consent directive.
The PrivacyPolicytext: Zero to one text, such as a URI, with a datatype of ED.REF may be sent.
The PrivacyPolicy statusCode: A statusCode of completed may be sent.
The PrivacyPolicyDocument classCodeDOC: This act type indicates that any document in event mood EVN may be complied with by a ConsentDirective.
The PrivacyPolicy code may be specified with a code from the ActPolicyTypeCode domain to specify the type of privacy policy, e.g., a policy relating to grounds for overriding a consent directive.
The PrivacyPolicytext: One or more text, such as an image, document, or URI with datatype of ED must be sent.
The PrivacyPolicy statusCode: A statusCode of completed may be sent.
Click <loc href="notes\RCMR_RM010001UV.htm">here</loc> for detailed HTML business walkthrough
| Data Consent | RCMR_HD010001UV01 |
|
||||||||
|
For details on the interpretation of this section, see the description of HMDs in the Version 3 Guide.
Used to record patient consent for information access
| R_ResponsibleParty | COCT_MT040200UV01 |
| R_Patient | COCT_MT050000UV01 |
| R_AssignedEntity | COCT_MT090000UV01 |
| R_AssignedPerson | COCT_MT090100UV01 |
| R_ServiceDeliveryLocation | COCT_MT240000UV01 |
| Consent | RCMR_MT010001UV01 |  |
| R_ResponsibleParty | COCT_MT040200UV01 |
| R_Patient | COCT_MT050000UV01 |
| Shared Secret | RCMR_MT010002UV01 | |
|
||||||||||||||||||||||||||||||||||||
|
For details on the interpretation of this section, see the definition of Interactions in the Version 3 Guide.
Notification that a data consent, dissent, or override has been recorded.
| Trigger Event | Notify about consent, dissent or override record | RCMR_TE010007UV01 |
| Transmission Wrapper | Send Message Payload | MCCI_MT000100UV01 |
| Control Act Wrapper | Trigger Event Control Act | MCAI_MT700201UV01 |
| Message Type | Consent | RCMR_MT010001UV01 |
| Sender | Data Consent Repository | RCMR_AR010003UV01 |
| Receiver | Data Consent Tracker | RCMR_AR010002UV01 |
| Receiver | Data Consent Repository | RCMR_AR010003UV01 |
Notification that a shared secret has been recorded.
| Trigger Event | Notify about recording of a shared secret | RCMR_TE010016UV01 |
| Transmission Wrapper | Send Message Payload | MCCI_MT000100UV01 |
| Control Act Wrapper | Trigger Event Control Act | MCAI_MT700201UV01 |
| Message Type | Shared Secret | RCMR_MT010002UV01 |
| Sender | Data Consent Repository | RCMR_AR010003UV01 |
| Receiver | Data Consent Tracker | RCMR_AR010002UV01 |
| Receiver | Data Consent Repository | RCMR_AR010003UV01 |
Requests that a data consent, dissent, or override be recorded.
| Trigger Event | Request to record consent, dissent, or override | RCMR_TE010003UV01 |
| Transmission Wrapper | Send Message Payload | MCCI_MT000100UV01 |
| Control Act Wrapper | Trigger Event Control Act | MCAI_MT700201UV01 |
| Message Type | Consent | RCMR_MT010001UV01 |
| Reason | Trigger Event | Interaction |
| Consent or override not accepted | RCMR_TE010002UV01 | RCMR_IN010002UV01 |
| Consent or override accepted | RCMR_TE010001UV01 | RCMR_IN010003UV01 |
| Sender | Data Consent Maintainer | RCMR_AR010001UV01 |
| Receiver | Data Consent Maintainer | RCMR_AR010001UV01 |
| Receiver | Data Consent Repository | RCMR_AR010003UV01 |
Requests that a shared secret be recorded.
| Trigger Event | Request recording of a shared secret | RCMR_TE010013UV01 |
| Transmission Wrapper | Send Message Payload | MCCI_MT000100UV01 |
| Control Act Wrapper | Trigger Event Control Act | MCAI_MT700201UV01 |
| Message Type | Shared Secret | RCMR_MT010002UV01 |
| Sender | Data Consent Maintainer | RCMR_AR010001UV01 |
| Receiver | Data Consent Maintainer | RCMR_AR010001UV01 |
| Receiver | Data Consent Repository | RCMR_AR010003UV01 |
Confirms recording of a data consent, dissent, or override.
| Trigger Event | Confirm recording of consent, dissent, or override | RCMR_TE010001UV01 |
| Transmission Wrapper | Application Level Acknowledgement | MCCI_MT000300UV01 |
| Control Act Wrapper | Trigger Event Control Act | MCAI_MT700201UV01 |
| Message Type | Consent | RCMR_MT010001UV01 |
| Sender | Data Consent Repository | RCMR_AR010003UV01 |
| Receiver | Data Consent Repository | RCMR_AR010003UV01 |
| Receiver | Data Consent Maintainer | RCMR_AR010001UV01 |
Confirms recording of a shared secret.
| Trigger Event | Confirm recording of a shared secret | RCMR_TE010014UV01 |
| Transmission Wrapper | Application Level Acknowledgement | MCCI_MT000300UV01 |
| Control Act Wrapper | Trigger Event Control Act | MCAI_MT700201UV01 |
| Message Type | Shared Secret | RCMR_MT010002UV01 |
| Sender | Data Consent Repository | RCMR_AR010003UV01 |
| Receiver | Data Consent Repository | RCMR_AR010003UV01 |
| Receiver | Data Consent Maintainer | RCMR_AR010001UV01 |
Refusal to record a data consent, dissent, or override. Note: There is no response message associated with a refusal because there is no identifier specifying a record, only the control act is specified.
| Trigger Event | Reject recording of consent, dissent, or override | RCMR_TE010002UV01 |
| Transmission Wrapper | Application Level Acknowledgement | MCCI_MT000300UV01 |
| Control Act Wrapper | Trigger Event Control Act | MCAI_MT700201UV01 |
| Sender | Data Consent Repository | RCMR_AR010003UV01 |
| Receiver | Data Consent Maintainer | RCMR_AR010001UV01 |
| Receiver | Data Consent Repository | RCMR_AR010003UV01 |
Refusal to record a shared secret.
| Trigger Event | Reject recording of a shared secret | RCMR_TE010015UV01 |
| Transmission Wrapper | Application Level Acknowledgement | MCCI_MT000300UV01 |
| Control Act Wrapper | Trigger Event Control Act | MCAI_MT700201UV01 |
| Sender | Data Consent Repository | RCMR_AR010003UV01 |
| Receiver | Data Consent Repository | RCMR_AR010003UV01 |
| Receiver | Data Consent Maintainer | RCMR_AR010001UV01 |
Notification that a shared secret has been revised.
| Trigger Event | Notify about shared secret revision | RCMR_TE010012UV01 |
| Transmission Wrapper | Send Message Payload | MCCI_MT000100UV01 |
| Control Act Wrapper | Trigger Event Control Act | MCAI_MT700201UV01 |
| Message Type | Shared Secret | RCMR_MT010002UV01 |
| Sender | Data Consent Repository | RCMR_AR010003UV01 |
| Receiver | Data Consent Tracker | RCMR_AR010002UV01 |
| Receiver | Data Consent Repository | RCMR_AR010003UV01 |
Notification that a data consent, dissent, or override has been revised.
| Trigger Event | Notify about consent, dissent or override revision | RCMR_TE010011UV01 |
| Transmission Wrapper | Send Message Payload | MCCI_MT000100UV01 |
| Control Act Wrapper | Trigger Event Control Act | MCAI_MT700201UV01 |
| Message Type | Consent | RCMR_MT010001UV01 |
| Sender | Data Consent Repository | RCMR_AR010003UV01 |
| Receiver | Data Consent Tracker | RCMR_AR010002UV01 |
Requests that a shared secret be revised.
| Trigger Event | Request shared secret revision | RCMR_TE010006UV01 |
| Transmission Wrapper | Send Message Payload | MCCI_MT000100UV01 |
| Control Act Wrapper | Trigger Event Control Act | MCAI_MT700201UV01 |
| Message Type | Shared Secret | RCMR_MT010002UV01 |
| Reason | Trigger Event | Interaction |
| Keyword updated | RCMR_TE010004UV01 | RCMR_IN010004UV01 |
| Keyword not accepted | RCMR_TE010005UV01 | RCMR_IN010005UV01 |
| RCMR_IN010006UV01 |
| Sender | Data Consent Maintainer | RCMR_AR010001UV01 |
| Receiver | Data Consent Maintainer | RCMR_AR010001UV01 |
| Receiver | Data Consent Repository | RCMR_AR010003UV01 |
Request data consent, dissent, or override revision
| Trigger Event | Request consent, dissent, or override revision | RCMR_TE010008UV01 |
| Transmission Wrapper | Send Message Payload | MCCI_MT000100UV01 |
| Control Act Wrapper | Trigger Event Control Act | MCAI_MT700201UV01 |
| Message Type | Consent | RCMR_MT010001UV01 |
| Sender | Data Consent Maintainer | RCMR_AR010001UV01 |
| Receiver | Data Consent Repository | RCMR_AR010003UV01 |
| Receiver | Data Consent Maintainer | RCMR_AR010001UV01 |
Confirms revision of a shared secret.
| Trigger Event | Confirm shared secret revision | RCMR_TE010004UV01 |
| Transmission Wrapper | Application Level Acknowledgement | MCCI_MT000300UV01 |
| Control Act Wrapper | Trigger Event Control Act | MCAI_MT700201UV01 |
| Message Type | Shared Secret | RCMR_MT010002UV01 |
| Sender | Data Consent Repository | RCMR_AR010003UV01 |
| Receiver | Data Consent Maintainer | RCMR_AR010001UV01 |
| Receiver | Data Consent Repository | RCMR_AR010003UV01 |
Confirms revision of a data consent, dissent, or override revision
| Trigger Event | Confirm consent, dissent, or override revision | RCMR_TE010009UV01 |
| Transmission Wrapper | Application Level Acknowledgement | MCCI_MT000300UV01 |
| Control Act Wrapper | Trigger Event Control Act | MCAI_MT700201UV01 |
| Message Type | Consent | RCMR_MT010001UV01 |
| Sender | Data Consent Repository | RCMR_AR010003UV01 |
| Receiver | Data Consent Repository | RCMR_AR010003UV01 |
| Receiver | Data Consent Maintainer | RCMR_AR010001UV01 |
Refusal to revise a shared secret.
| Trigger Event | Reject shared secret revision | RCMR_TE010005UV01 |
| Transmission Wrapper | Application Level Acknowledgement | MCCI_MT000300UV01 |
| Control Act Wrapper | Trigger Event Control Act | MCAI_MT700201UV01 |
| Message Type | Consent | RCMR_MT010001UV01 |
| Sender | Data Consent Repository | RCMR_AR010003UV01 |
| Receiver | Data Consent Maintainer | RCMR_AR010001UV01 |
| Receiver | Data Consent Repository | RCMR_AR010003UV01 |
Refusal to revise a data consent, dissent, or override
| Trigger Event | Reject consent, dissent, or override revision | RCMR_TE010010UV01 |
| Transmission Wrapper | Application Level Acknowledgement | MCCI_MT000300UV01 |
| Control Act Wrapper | Trigger Event Control Act | MCAI_MT700201UV01 |
| Message Type | Consent | RCMR_MT010001UV01 |
| Sender | Data Consent Repository | RCMR_AR010003UV01 |
| Receiver | Data Consent Repository | RCMR_AR010003UV01 |
| Receiver | Data Consent Maintainer | RCMR_AR010001UV01 |
| Return to top of page |