|
||||||||
|
| Parent: | Medical Records (RCMR_DM000050UV) |
A consent where one or more parties (the Consenters) agree to the subject as described in the A_Consent.text. The performer of the consent is considered the person who obtains the consent from the consenter(s). The consent CMET is usually linked to an Act that is the topic of the consent (for example, a surgical procedure, or another health care service). The link is made using an Act relationship from A_Consent to the Act being the topic of the consent, where the ActRelationship type is PERT (pertains-to) or a specialization thereof.
| R_ResponsiblePartyUniversal | COCT_MT040200UV09 |
| R_AssignedEntityUniversal | COCT_MT090000UV01 |
| A_Consent universal | COCT_MT470000UV |  |
| Parent: | Medical Records (RCMR_DM000050UV) |
Usage Notes: This CMET conveys a Consent Directive that may authorize or prohibit one or more information transfers or "access" by recipients to perform system operations for specified purposed under certain conditions with certain obligations on types or instances of information artifacts over which the authoring party has control. The CMET may be sent in conjunction with the transmission of an information artifact, a query, a query response, and may reference the content of one or more prior Consent Directive instances in whole or part. In future ballots, CMET variants may be developed to reference a Consent Directive instance rather than convey details that a receiving system does not need to receive because it can directly access the consent directive details.
The Data Consent CMET captures the data and associations needed to (1) record or report a consumer's consent or dissent to authorize the collection, access, 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. This CMET may be attached to a message or used in association with the transmission of a clinical document to specify the consent directives of the subject of personal health information therein conveyed. 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 healthcare.
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. Note that categories of information may relate to a particular structuring of information, such medication lists or summary health record, or it may relate to groupings of value sets and particular classes and attributes that may be indicative of a category of information or from which a category of information may be inferred. As stated in the HL7 Reference Information Model at 3.1.1.14 Act.confidentialityCode: "Inference means that filtered sensitive information can still be assumed given the other information that was not filtered. The simplest form of inference is that even the existence of a test order for an HIV Western Blot test or a T4/T8 lymphocyte count is a strong indication for an existing HIV infection, even if the results are not known. Very often, diagnoses can be inferred from medication, such as Zidovudin for treatment of HIV infections."
The Attributes of the Focal Class ConsentDirective
The ConsentDirective classCode CONS: The act class consent refers in this context to consent related to the collection, access, use, or disclosure of a consumer's personally identifiable information. The type of consent is specified at a high level by the ActConsentType code. If the ConsentDirective type authorizes the transfer of one or more InformationArtifacts, then further detail is required to be conveyed if known such as the recipients of subject InformationArtifacts; operations permitted to be performed on those InformationArtifacts; the purposes for which an operation may be performed; the roles permitted to perform the operations, as well as any preconditions or resulting obligations. NOTE Constraint: If ActConsentType is INFA, then the PermissionToTransfer must be present. This is required regardless of whether the negationInd is null, true or false. In the case where consent to access is not granted, the PermissionToTransfer and its associated classes are used to specify the details of a masking directive.
The ConsentDirective moodCode x_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 information; 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 II BUS_VER: A consent directive identifier is required to be sent if known. This uniquely identifies a consent directive or consent directive override instance as a business object and as a version of that business object as it exists at a given point in time. Note that this is a Release 2 Data Type that supports a scope attribute on the Instance Identifier. In the Data Types - Abstract Specification, Release 2 at 4.13.4, a Business Identifier is defined as: "An identifier that is associated with the object due to the business practices associated with the object. The scope of the use of the id may not be restricted to a single object, but may be reused for other objects closely associated with the object due to business practice." A Version Identifier is defined as: "An identifier that references a particular object as it existed at a given point in time. The identifier can be considered an identifier of a static snapshot of the object. The identifier changes with each state transition on the object. I.e. the version identifier of an object prior to a 'suspend' state transition is distinct from the identifier of the object after the state transition. Each version identifier can be tied to exactly one ControlAct event which brought that version into being (though the control act may never be instantiated). NOTE: Applications that do not support versioning of objects must ignore and not persist these ids to avoid confusion resulting from leaving the same identifier on an object that undergoes changes."
The ConsentDirective code ActConsentType: The type of consent being granted, refused, revoked, or overridden shall be specified by a code from the ActConsentType concept domain, e.g., consent to collect, access, use, or disclose, e.g., for research.
The ConsentDirective negationInd 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/CMET with the same Consent Directive, as indicated by an identical consent directive Business Identifier and a new Version 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 relating to collection, access, use, and disclosure of personally identifiable information. NOTE Constraint: If the negationInd is "false", then the PermissionToInform is mandatory.
The ConsentDirective statusCode: A statusCode from the specializable ActStatusNormal concept domain must be sent.
The ConsentDirective effectiveTime: The Consent effective and end time is required to be sent if known.
The ConsentDirective reasonCode: If a provider or other authorized assigned entity is participating in the ConsentDirective as author1, then a code from the ActConsentInformationAccessOverrideReason concept domain must be sent if known to indicate the provider's reason for overriding a patient's consent directive. Otherwise, the ActConsentInformationAccessOverrideReason must not be used. Note that this is a constraint.
The ConsentDirective shall be linked with the subject participation typeCode SBJ 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 contextControlCode OP 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.
NOTE Constraints: The ConsentDirective must be linked by an AUT participation to one and only one type of authoring role, either "author2" the consenter role, which may be the patient and/or one or more responsible parties; or "author1", which may be zero to one assigned entity. If author1 then there must be a responsibleParty who is ultimately responsible for author1.
The author2 participation typeCode AUT is required to link the ConsentDirective to zero to many 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 one or more delegates 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 ConsenterParticipationFunction concept domain to indicate the function served by the a R_ResponsibleParty participation in the authoring of a consent directive, e.g., as a legal guardian or a representative with powers of attorney.
The mandatory author2 participation contextControlCode OP 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 must be sent to indicate the time at 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.
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 the author, and that he or she agrees to assume the associated accountability.
The author1 participation typeCode AUT 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 OverrideParticipationFunction concept domain to indicate the function served by the a R_AssignedParty in the authoring of a consent directive override, e.g., as an authorized clerical staff charged with creating a default consent directive or updating an existing consent directive based on changed privacy policy; a resident authoring an override for a a responsible party to mask information from the consumer; or a provider that is authorized to "break the glass" to access critical health information.
The mandatory author1 participation contextControlCode OP 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 time at 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.
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 responsibleParty typeCode RESP is required to link the ConsentDirective to zero or one assignedEntity, which is conveyed by the R_AssignedEntity (universal) CMET.
The ConsentDirective may have a predecessor relationship typeCode SUCC as the source act to zero to many PriorConsentDirective(s) target acts in circumstances where one or more prior consent directive types such as a notice of privacy practices, an opt-in to collection, a restriction on disclosure for non-treatment purposes, and a delegation to a healthcare representative, typically a paper or online form is replaced or succeeded by the focal coded ConsentDirective that is substantially equivalent to and fully specifies the content expressed by one or more PriorConsentDirectives types.
The ConsentDirective may have a reference relationship typeCode REFR as a source act of zero to many PriorConsentDirective(s) target acts in circumstances where the prior consent directive artifacts are captured and maintained in hard-copy as validation of the focal coded ConsentDirective especially in circumstances where the healthcare consumer's digital signature may not be legally accepted or technically supported for purposes of attestation of the ConsentDirective.
Attributes of PriorConsentDirective: One or more consent directives may be predecessors of the focal consent directive. A predecessor consent directives may be captured as an Xform; an electronic text image; or hard copy unstructured text . If a 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 or text image file with a wet signature may satisfy the business requirement.
The PriorConsentDirective classCode: This class has an act type of CONS or "consent", which is the legal transaction between a healthcare consumer and an actual or potential custodian of the consumer's information conveying grants or denials of permission to collect, access, use or disclose this information.
The PriorConsentDirective moodCode: The mood of this act is event EVN, indicating that the prior consent directive has occurred or is in the process of occurring.
The PriorConsentDirective id: A set of zero to many identifiers is required to be sent if known to identify a prior consent directive.
The PriorConsentDirective code ActConsentDirectiveType may be used to convey the type of prior consent directive types that may be singly or combined into the focal fully specified, structured Consent Directive, e.g. a notice of privacy practices, an opt-in to collection, a restriction on disclosure for non-treatment purposes, of a delegation to a healthcare representative. NOTE: This ActCode was approved during the Fall 2007 Harmonization Meeting, and is defined as the type of consent directive indicated by an ActClassPolicy e.g., a 3rd party authorization to disclose or a consent for a substitute decision maker (SDM) or a notice of privacy policy. It is a sibling to ActPrivacyPolicyType and a child of ActPolicyType.
The PriorConsentDirective text of type ED: A PriorConsentDirective text image may be attached. Where a consent directive is substantially equivalent predecessor of the focal consent directive, and the prior 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 e.g., a scanned consent directive with a wet signature and/or referencing the PriorConsentDirective identifier may be legally sufficient proof of attestation as long as the association to the signed directive is maintained.
The PriorConsentDirective statusCode: A statusCode with the default of "complete" may be sent.
The PriorConsentDirective effectiveTime: The Consent effective 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.
The PriorConsentDirective languageCode HumanLanguage: The language used in the PriorConsentDirective may be sent.
The ConsentDirective may have a reference relationship typeCode COMPLY to the PrivacyPolicy meaning that the source act, the focal ConsentDirective complies with, adheres to, conforms to, or is permissible under (in whole or in part) the policy, contract, agreement, law, conformance criteria, certification guidelines or requirement conveyed by the PrivacyPolicy as the target act. NOTE: This ActRelationshipType was approved during the Fall 2007 Harmonization meeting, and means that the source act complies with, adheres to, conforms to, or is permissible under the target act, either in whole or in part. Example act types include policies, contracts, agreements, laws, conformance criteria, certification guidelines, and requirements.
Attributes of PrivacyPolicy
The PrivacyPolicy classCode: This class has an act type of POLICY, which is defined as a mandate, regulation, obligation, requirement, rule, or expectation unilaterally imposed by one party on the activity or behavior of another party, or on the manner in which an act is executed. In this context, the policy relates to a jurisdictional or organizational policy relating to the healthcare consumer's right of privacy in personal information and any confidentiality requirements related to its use.
The PrivacyPolicy moodCode: The mood of this act is permission EVN, indicating that the PrivacyPolicy is or has been in effect.
The PrivacyPolicy id: A set of zero to many identifiers is required be used to identify this policy if known.
The PrivacyPolicy code is required be specified if known from the ActPrivacyPolicyType concept domain to identify the type of privacy policy governing the ConsentDirective, e.g., privacy policy about the consent requirements for disclosure of health information related to treatment in a substance abuse program. NOTE: This ActCode was approved during the Fall 2007 Harmonization Meeting, and is defined as the type of privacy policy indicated by an ActClassPolicy, e.g., privacy policy about the consent requirements for disclosure of health information related to treatment in a substance abuse program covered by 42 CFR Part 2. It is a sibling to ActConsentDirectiveType.
The ConsentDirective may have an authorization relationship typeCode AUTH of zero to many PermissionToTransfer acts.
The authorization relationship is required have one contextControlCode set to ON to indicate that the author may override but not propagate authorship to the child Acts, i.e., if author1 overrides a consent directive with certain permissions, then the overriding author does not author those permissions.
The authorization relationship contextConductionInd is set to true to indicate that the context marked as conducting will conducts to child acts.
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 id: A set of zero to many identifiers may be used to identify this act.
The PermissionToTransfer code may be specified from the ActInformationTransferCode concept domain to provide information about the protocols by which the information transfer is permitted, e.g., in accordance with legal or regulatory requirements. NOTE: This ActCode was approved during the Fall 2007 Harmonization Meeting.
The receiver participation typeCode RCV 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 contextControlCode OP 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.
The receiver participation participationFunction may be sent using codes from the AuthorizedReceiverParticipationFunction concept domain to indicate the receiver functions of the R_AssignedEntity or the R_ServiceDeliveryLocation roles, such as information custodian, care team, or work area.
The PermissionToTransfer shall have as subjects one or more InformationArtifact(s) via the subject relationship typeCode SUBJ. The contextControlCode ON indicates that the permitted release of information applies only to the target InformationArtifact 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 InformationArtifact may not have the PermissionToTransfer as a subject where the author is not granting consent to collect, access, use, or disclose subject information.
Attributes of InformationArtifact
The InformationArtifact classCode ACT: This act type indicates that any act in definition or event mood ActMoodDefEvn may be the subject of an information transfer, e.g., an act that may meet the definition or any act instance.
The InformationArtifact id: A set of zero to many identifiers may be used to identify this InformationArtifact.
The InformationArtifact code shall be specified with a code from the ActInformationAccessCode concept domain to provide more precise description of the type of information within the InformationArtifact that is the subject of the permitted disclosure. The ActInformationAccessCode is defined as the type of personal health information to which the subject of the information or the subject's delegate consents or dissents to authorize access. Examples of the type of information include: allergy, adverse drug, demographic, immunization, lab results, mediation, medical condition, observations, policy or program, provider, or services.
The InformationArtifact may reference zero to many InformationArtifactChoice via the reference relationship typeCode REFR to permit the InformationArtifact to reference the A_Coverage (universal) CMET, which may convey demographic and coverage information; the A_Appointment CMET, which may convey information related to an appointment scheduling healthcare services; the A_Billable CMET (universal), which may convey encounter information including diagnoses, procedures, service locations, and providers; the A_SupportingClinicalStatement (universal), which may convey any type of clinical encounter or healthcare services in great detail; and the A_Transportation CMET, which may convey confidential information about transportation for health services, including locations.
The PermissionToTransfer is required to have a component relationship typeCode COMP of zero to many ConsentPermission acts.
Attributes of ConsentPermisson
The ConsentPermission classCode: This class has an act type of CACT or "control act", which is defined as: "An act representing a system action such as the change of state of another act or the initiation of a query. All control acts represent trigger events in the HL7 context. ControlActs may occur in different moods.
The ConsentPermission moodCode: The mood of this act is permission PERM, indicating that specified acts or operations on one or more information artifacts, which are the subject of the PermissionToTransfer are permitted.
The ConsentPermission id A set of zero to many identifiers may be used to identify this act.
The ConsentPermission code must be specified from the HL7TriggerEventCode concept domain to indicate the available trigger events used in the release of HL7 identified by the versionCode that are permitted acts or operations.
The ConsentPermission reasonCode may be specified from the PatientProfileQueryReasonCode concept domain to indicate the purposes for which permission to perform the acts or operations indicated by the HL7TriggerEventCode is granted, e.g., for treatment, payment, operations, disclosure to third parties, marketing, public health surveillance or reporting, or research.
The ConsentPermission may have a precondition relationship typeCode PRCN of zero to many ConsentPermissionCondition acts.
The precondition sequenceNumber indicates the relative order in which the associated ConsentPermissionCondition is considered and may associate enumerated condition(s) with one or more ConsentPermissionObligations with the same sequence number to indicate that if the condition for the ConsentPermission is met, the associated ConsentPermissionObligation is a required post condition.
The precondition checkpointCode indicates when in the course of a permitted 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).
The precondition conjunctionCode specifies the logical conjunction of the criteria among all the precondition-links of permitted acts (e.g., and, or, exclusive-or).
Attributes of ConsentPermissonCondition
The ConsentPermissionCondition classCode: This class has an act type of COND or "condition": 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.
The ConsentPermissionCondition moodCode: The mood of this act is permission CRT, indicating a condition criterion that must obtain in order for an act or operation is permitted to be performed on an information artifact.
The ConsentPermissionCondition id: A set of zero to many identifiers may be used to identify a condition, which may be used when evaluating the status of one or more conditions.
The ConsentPermissionCondition code must be specified from the ActPrivilegeCategorizationType concept domain to indicate the observations used to characterize a privilege, under which this additional permission condition information is classified. Examples include security or privacy policy requirements, e.g., the manner, time, and location in which an act or operation is permitted on an information artifact.
The ConsentPermissionCondition statusCode indicates the state of the act, e.g., active vs. completed.
The ConsentPermissionCondition negationInd indicates whether the negation of the specified condition is required for the act or operation to be permitted.
The ConsentPermissionCondition effectiveTime indicates the focal or operative time of the condition necessary for the permitted act or operation.
The ConsentPermissionCondition value indicates the condition value assigned to the ActPrivilegeCategorizationType.
The ConsentPermission may have a precondition relationship typeCode TRIG of zero to many ConsentPermissionObligation acts in criterion mood indicating that the ConsentPermission triggers a ConsentPermissionObligation as a post-condition.
The trigger sequenceNumber indicates the relative order in which the associated ConsentPermissionObligation is considered and may associate enumerated obligation(s) with one or more ConsentPermissionConditions with the same sequence number to indicate that if the condition(s) for the ConsentPermission is met, the associated ConsentPermissionObligation is a required post condition.
The trigger splitCode indicates how multiple ConsentPermissionObligations with the same sequence numbers are to be evaluated exclusively or inclusively.
The trigger conjunctionCodespecifies the logical conjunction of the criteria among all the post-conditions of permitted acts (e.g., and, or, exclusive-or).
Attributes of ConsentPermissonObligation
The ConsentPermissionObligation classCode: This class has an act type of POLICY or "policy", which is an obligation under a privacy or security policy that is triggered by the permitted act or operation on an information artifact. For example, a typical security policy is the obligation to log and audit an operation performed on a protected information artifact
The ConsentPermissionObligation moodCode: The mood of this act is permission CRT, indicating an obligation that is the required post-condition of a permitted act or operation.
The ConsentPermissionObligation id: A set of zero to many identifiers may be used to identify this obligation, which may be used when evaluating the status of one or more obligations.
The ConsentPermissionObligation code must be specified from the ActPolicyType concept domain to further specify an obligation that results from a permitted act or operation on an information artifact, e.g., the obligation to log and audit.
The ConsentPermissionObligation effectiveTime indicates the focal or operative time of the obligation necessary for the permitted act or operation.
The ConsentPermissionObligation activityTime specifies the time in which the obligation is ordered or scheduled to happen as a post-condition for the permitted act or operation.
The ConsentPermission shall be linked with the performer participation typeCode PRF to the OperationPerformer role indicating that one to many performers shall perform the act or operation condoned by the ConsentPermission.
The mandatory performer participation contextControlCode ON indicates that any role participating as performing operator in the ConsentPermission overrides all roles from any ancestral participations but does not propagate to all descendant acts reached by conducting ActRelationships. That is, the operation performer does not have an authoring relationship to the consent authorizing the transfer of specified information, but is not the same role as the authoring role. However, the entities playing these roles could be the same, e.g., the representative of the healthcare consumer may be the performer of an operation, the permission for which was granted by the consumer to the consumer as a recipient of the transferred information, e.g., query the consumer's health information. This requirement is further specified by the following constraint: The OperationPerformer identifier must match a recipient identifier on its parent PermissionToTransfer.
| A_AppointmentUniversal | COCT_MT020000UV01 |
| R_ResponsibleUniversal | COCT_MT040000UV09 |
| R_ResponsiblePartyUniversal | COCT_MT040200UV09 |
| R_PatientUniversal | COCT_MT050000UV01 |
| A_TransportationUniversal | COCT_MT060000UV01 |
| R_AssignedEntityUniversal | COCT_MT090000UV01 |
| R_AssignedEntityUniversal | COCT_MT090000UV01 |
| R_ServiceDeliveryLocationUniversal | COCT_MT240000UV01 |
| A_BillableUniversal | COCT_MT280000UV04 |
| A_CoverageUniversal | COCT_MT510000UV06 |
| A_SupportingClinicalStatementUniversal | COCT_MT530000UV |
| A_DataConsent universal | COCT_MT580000UV07 | |
| Return to top of page |