Medical Records
 ANSI/HL7 V3 RCMR, R1-2006 (2011) HL7 Version 3 Standard: Medical Records/Information Management, Release 1 (reaffirmation of ANSI/HL7 V3 RCMR, R1-2006) 11/3/2006 |
ANSI/HL7 V3 MRDACM, R1-2008 HL7 Version 3 Standard: Medical Records; Data Access Consent, Release 1 11/10/2008 |
| Responsible Group | Medical Records/Information Management Work Group HL7 |
| Community Based Collaborative Care SIG Modeling and Vocabulary Facilitator | Kathleen Connor Fox Systems, Inc |
| Primary Contributor | Bob Dolin, MD Kaiser Permanente |
| Primary Contributor | Matthew Greene U.S. Department of Veterans Affairs |
| Community Based Collaborative Care Publishing Facilitator | Francine Kitchen GE Healthcare |
| Medical Records Co-Chair | Nancy LeRoy, BS, CCS, CCP U.S. Department of Veterans Affairs |
| Medical Records Past Co-Chair | Michelle Dougherty American Health Information Management Association |
| Medical Records Past Co-Chair | Wayne Tracy Health Patterns, LLC |
| Medical Records Co-Chair | John Travis Cerner Corporation |
HTML Generated: 2012-08-31T12:09:42
Content Last Edited: 2008-04-30T11:54:50
HL7® Version 3 Standard, © 2006, 2008 Health Level Seven® International All Rights Reserved.
HL7 and Health Level Seven are registered trademarks of Health Level Seven International. Reg. U.S. Pat & TM Off.
Use of these materials is governed by HL7 International's IP Compliance Policy.
Table of Contents
Preface
i Message Design Element Navigation
1 Overview
1.1 Introduction & Scope
1.2 Domain Information Models
2 Document Management Topic
2.1 Introduction
2.2 Storyboards
2.3 Application Roles
2.4 Trigger Events
2.5 Refined Message Information Models
2.6 Hierarchical Message Descriptions
2.7 Interactions
3 Data Consent Topic
3.1 Introduction
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
4 Quality Analysis Report Topic
5 CMETs Defined by this Domain
6 CMETs Used by this Domain
7 Interactions Annex
7.1 By Application Role
7.2 By Trigger Event
7.3 By Message Type
8 Glossary
|
||||||||
|
The Medical Records domain currently supports clinical document management, and document querying. In the future, it is intended also to support the data exchange needs of applications supporting other medical record functions, including chart location and tracking, deficiency analysis, consents, and release of information. The main purpose of the medical record is to produce an accurate, legal, and legible clinical document that serves as a comprehensive account of healthcare services provided to a patient, and which has the following characteristics:
-
Persistence: A clinical document continues to exist in an unaltered state, for a time period defined by local and regulatory requirements.
-
Stewardship: A clinical document is maintained by an organization entrusted with its care.
-
Potential for authentication: A clinical document is an assemblage of information that is intended to be legally authenticated.
-
Wholeness: Authentication of a clinical document applies to the whole and does not apply to portions of the document without the full context of the document.
-
Human readability: A clinical document is human readable.
These interactions are mainly associated with documents that will be or have been transcribed. The types and appearance of the transcribed documents can vary greatly within a healthcare organization and between organizations. However, the main purpose of the transcription process is to document patient care or diagnostic results in a legible manner; these documents then become part of the legal medical record.
Both Observation Reporting and Document Management messages can convey clinical observations including (but not limited to) clinical laboratory results, measures of patient status and condition, vital signs, intake and output, severity and/or frequency of symptoms.
If the observation being reported meets one or more of the following criteria, then the content would qualify as a medical document management message rather than an observation message.
-
Documents/reports that require succession management to reflect the evolution of both document addenda and replacement documents.
-
Documents/reports where the Sender wants to indicate the availability of the report for use in patient care.
-
Documents/reports where document storage status is useful for archival and purging purposes.
Additional considerations that may affect the appropriateness of using the messages defined in this chapter include:
-
Documents/reports where the whole requires a signature as part of the message.
-
Documents/reports where the whole requires authentication as part of the message.
Using these criteria, the following examples would typically qualify as reports transmitted via medical document management messages:
-
History and Physical
-
Consultation reports
-
Discharge summaries
-
Surgical/anatomic pathology reports
-
Diagnostic imaging reports
-
Cardio-diagnostic reports
-
Operative reports
-
As an international example, microbiology reports may include clinical interpretation and require authentication. This may not be the case in all jurisdictions, but is an example that the use or requirement of the messages defined in this chapter may be influenced by local considerations.
NOTE: Transcription is not a defining quality for the selection of a document management or observation reporting message. In a document management message, the document/report is typically dictated or transcribed, but not always. Machine-generated or automated output is an example of a document/report that may be appropriately sent via a document management message but is not transcribed.
Application systems sending and receiving clinical documents are responsible for meeting all legal requirements for document authentication, confidentiality, and retention. For communications over public media, cryptographic techniques for source/recipient authentication and secure transport of encapsulated documents may be required, and should be addressed with commercially available tools outside the scope of this standard.
Confidentiality status information is provided in medical records messages to aid application systems in managing access to sensitive data. Confidentiality status may apply to the entire document or to specified segments of the document.
Privacy and Security Prerequisites for Document Queries
There are a number of privacy and security considerations the reader or implementer of document query messaging should consider in any given implementation use case for support of cross enterprise, cross application document queries. These concerns are especially important to help guard against unauthorized re-disclosure of information, and help build confidence that patient privacy and confidentiality can be upheld. These concerns include how evidence of a requestor's authorization may be provided or made available to provide validation to the recipient of the request that the requestor is making a valid request for release of information, how the recipient of the request has an appropriate level of trust (contractually, technically or legally) with the requestor and how patient rights to know of disclosures of personal health information may be enabled through auditing of such disclosures. There may be additional functional requirements and implementation requirements at the realm level.
The prerequisites for privacy and security interests to be appropriately served in document query transacting are as follows:
-
Security context/Trust relationship exists between participants for each communication instance: These prerequisites outline the security requirements that should be in place to assure the trust relationship exists, and that the communication is done in a secure manner. They include: [1] Support for the confidentiality and integrity of the message itself through the use of appropriate security measures (e.g. encryption) [2] That the transmission is done in a secure manner [3] That the sender and receiver of the message perform mutual authentication to ensure the transmission is directed to the appropriate recipient.
-
Patient Rights protected/upheld: These prerequisites enable a patient to be confident that disclosures of personal health information are properly authorized, and that such authorization is verifiable. The identity of the requesting party is specifically known, and is not anonymous from verification. Users of systems that facilitate making a request for release of information are subject to authorization enabled by access control policies to assure proper access to personal health information. Prerequisites in this area include: [1]That user identities are known and authenticated for requestors of releases of information; [2] That user access permissions are established by access control policies enabled within the systems from which document query requests are made; [3] That positive identification is possible and specific to the initiator of the query whether a person, an organization (location) or a trusted identified application recipient representing the user (or proxied to by the user); [4] That the requestor commits to abide by terms of any applicable patient consent/authorization for release of information; [5] That the user/intended recipient is authorized (and validated) to be the recipient in accordance with patient consent or written authorization, a court order, as permitted by law or regulation, as supported by a manually validated request (such as for a release for law enforcement purposes); [6] That evidence of the authorization exists and can be validated programmatically (through evidence of the authorization provided within the context of the request) or through human procedural verification with identification of the method and responsibility for validation
These measures help assure that the request for documents is authorized under proper authority, and that the identity and accountability of the requestor is established and verifiable by the recipient of the request for release of information.
-
Audit trails of disclosures to be enabled: Patients have the right to request an accounting of disclosures of to whom their personal health information has been disclosed. Different types of disclosures may be included in that accounting based on the requirements of prevailing law/regulation and policy. All disclosures need to be made auditable on that basis. The audit trail should incorporate, but not necessarily be limited to, information that identifies the party to whom the disclosure was made, who made the disclosure, when the disclosure occurred, what was the subject matter disclosed and why the disclosure occurred.
The above prerequisites are seen as elemental to providing the supporting infrastructure for solicited document query processing to occur in a secure manner that upholds patient privacy and the confidentiality of personal health information.
Within the document query message structure itself, there are also several prerequisite requirements that should be in place for a normative document query standard to be successful. These must be contained within the query message structure, and must exist prior to the fulfillment of a query. These include: [1] If the release requires patient permission, then the appropriate means of assuring support for non-repudiation (e.g. through electronic signature or through in person identity verification) and unique identification is required for all participants in the release of information for authentication of patients/legal representatives, witnesses and providers as signatories that may be incorporated on consent forms; [2] Standard identifiers must be included for reference to intended recipients (e.g. such as the National Provider Identifier (NPI) in the US or as appropriate for the use of other external references); [3] Inclusion of the automated release of information up to and including the electronically signed (non-repudiated) release of information itself or, if not fully automatable, then the message structure should include the identity of the individual performing the external validation of the appropriateness of the release and the date/time of the external validation.
Implementers should be aware of the significance of ensuring satisfaction of these prerequisites prior to attempting to use the document query messages for support of release of information activities for solicited queries.
A clinical document can be replaced by a new document and/or appended with an addendum.
A replacement document is a new version of the parent document. The parent document is considered superseded, but a system may retain it for historical or auditing purposes. The parent document being replaced is referenced via act relationship relatedDocument, where relatedDocument.typeCode is set to equal "RPLC" (for "replaces"). An example is a report found to contain an error that is subsequently replaced by the corrected report.
An addendum is a separate document that references the parent document, and may extend or alter the observations in the prior document. The parent document remains a current component of the patient record, and the addendum and its parent are both read by report recipients. The parent report (represented by the ParentDocument class) being appended is referenced via act relationship relatedDocument, where relatedDocument.typeCode is set to equal "APND" (for "appends").
Every clinical document must have a unique ClinicalDocument.id, and thus the replacement or addendum documents each have ClinicalDocument.id that is different from that of the parent document. Clinical documents may also contain a ClinicalDocument.setId and a ClinicalDocument.versionNumber, which together support a document identification and versioning scheme used in some document management systems. In this scheme, all documents in a chain of replacements have the same ClinicalDocument.setId and are distinguished by an incrementing ClinicalDocument.versionNumber. The initial version of a document gets a new unique value for ClinicalDocument.id, a new value for ClinicalDocument.setId, and has the value of ClinicalDocument.versionNumber set to equal "1". A replacement document gets a new globally unique ClinicalDocument.id value, and uses the same value for ClinicalDocument.setId as the parent report being replaced, and increments the value of ClinicalDocument.versionNumber by 1. (Note that version number must be incremented by one when a report is replaced, but can also be incremented more often to meet local requirements.)
These relationships are summarized in the following illustration:
Documents only assume a subset of the states that other Acts can take on. A newly created document that has not yet been released is "new". Because it has not yet been released, it can be "cancelled". In this case, there are no requirements to save a copy of the document. When a document is released, its status becomes "active". An active" document that has been legally authenticated is "completed". Documents that are "active" or "completed" are rendered "obsolete" when they are replaced with a revision.
These document statuses are summarized in the following illustration:
To maintain consistency with the statuses defined in HL7 V2.x, Chapter 9 "Medical Records / Information Management (Document Management)", the value of ClinicalDocument.statusCode constrains the allowable values for ClinicalDocument.completionCode, ClinicalDocument.confidentialityCode, ClinicalDocument.storageCode, and ClinicalDocument.availabilityTime, as shown in the following table:
| Status Code | Completion Code | Confidentiality Code | Storage Code | Availability Time | Description |
| New | Any value | Any value | NULL | NULL | This is a new document. It has not been made available for viewing. It can have any confidentiality status. It's document storage status and availability time are undefined, since it has not yet been made active. |
| Active | Anything other than Legally Authenticated | Any value | Active; Active & Archived | Availability Time = time the document was made available | This document is active, and is available. It has not yet been legally authenticated. It can have any confidentiality status. |
| Completed | Legally Authenticated | Any value | Active; Active & Archived | Availability Time = time the document was made available | This document is active, and is available. It has been legally authenticated. It can have any confidentiality status. |
| Canceled | Any value | Any value | NULL | NULL | This document was abandoned before being released. It may or may not have been authenticated. |
| Obsolete | Any value | Any value | Archived; Purged | Availability Time = time the document was made available | This document was superseded by a replacement document and is now obsolete. It is no longer available. |
| Nullified | Nullified (proposed new value for V2.7) | Any value | Archived | Availability Time = time the document was made available | This document was created in error or was placed in the wrong chart. It is no longer available. |
Diagram
The purpose of the transmitted data is to enable clinical document exchange, notification and retrieval across and within institutions; facilitate clinical document management; and facilitate compilation of an individual patient's clinical documents into a lifetime electronic patient record.
The main components of the model include information about the document, such as encounter data, various participants, related documents; and the document itself. When sending a document encapsulated inside a medical records message, the strong preference is to send one that conforms to the ANSI HL7 Clinical Document Architecture (CDA) specification.
NOTE: The HL7 Reference Information Model is the definitive source of definitions for classes and definitions. What follows are special considerations for the referenced RIM components as they are used in this model. Note that at no time do the comments presented here conflict with the RIM, but instead further constrain the RIM definitions.
Document Attributes
This section describes attributes of the root ClinicalDocument class.
-
ClinicalDocument.id: Represents the globally unique instance identifier of this version of a clinical document. (See section Document Identification, Revisions, and Addenda in Introduction and Scope above).
-
ClinicalDocument.code: The code specifying the particular kind of document (e.g. History and Physical, Discharge Summary, Progress Note). Values are preferably drawn from LOINC. (Within the LOINC database, beginning with version 2.09, May 2003, document type codes are those that have a value of "DOC" in the Scale component).
-
ClinicalDocument.title: Represents the title of the document. It's commonly the case that clinical documents do not have a title, and are collectively referred to by the display name of ClinicalDocument.code (e.g. a "consultation" or "progress note").
-
ClinicalDocument.text: The ClinicalDocument.text attribute uses an encapsulated data (ED) type. The components of this data type can be used to transmit a document file name and/or URL (ED.reference), and document format or media type (ED.type). If message type is RCMR_MT000002 then ClinicalDocument.text shall include exactly 1 clinical document, with all its authenticated content (with or without associated stylesheet(s)) in ED.BIN. The mechanism for packaging an HL7 Clinical Document Architecture (CDA) document in ClinicalDocument.text is described in the CDA specification.
NOTE: Message RCMR_MT000002 is to be used when including the document itself. The ED.BIN component cannot be used in RCMR_MT000001.
-
ClinicalDocument.statusCode: A code specifying the state of the document. See the Introduction and Scope section above for a complete discussion of allowable states and state transitions.
-
ClinicalDocument.effectiveTime: Signifies the document creation time, when the document first came into being.
-
ClinicalDocument.availabilityTime: Signifies the time a document was made available for patient care. This value is NULL when statusCode is "NEW", and is required when statusCode is "ACTIVE" or "COMPLETED".
-
ClinicalDocument.confidentialityCode: It is customary, but not required, that the value of confidentialityCode be set equal to the most restrictive confidentialityCode of any of the document parts.
-
ClinicalDocument.reasonCode: A code specifying the motivation, cause, or rationale for replacing or nullifying a clinical document.
-
ClinicalDocument.languageCode: Specifies the human language of character data (whether they be in contents or attribute values).
-
ClinicalDocument.setId: Represents the identifier that remains constant across all revisions of a clinical document. (See section Document Identification, Revisions, and Addenda in Introduction and Scope above).
-
ClinicalDocument.versionNumber: Represents the version number for this version of a clinical document. (See section Document Identification, Revisions, and Addenda in Introduction and Scope above).
-
ClinicalDocument.completionCode: A code depicting the completion status of a report (e.g., incomplete, authenticated, legally authenticated).
-
ClinicalDocument.storageCode: A code depicting the storage status (e.g., active, archived, purged) of a report.
-
ClinicalDocument.copyTime: Time a document is released (i.e., copied or sent to a display device) from a document management system that maintains revision control over the document. Once valued, cannot be changed. Intent of this attribute is to give the viewer of the document some notion as to how long the document has been out of the safe context of its document management system.
Document Relationships
This section describes clones related to the root ClinicalDocument class via an ActRelationship.
-
ParentDocument: This class represents the target of a document relationship. The target is either being appended, revised, or transformed by the source document. See section "Document Identification, Revisions, and Addenda" in Introduction and Scope above for further details. See the discussion of ClinicalDocument for attribute level descriptions. ParentDocument.text can be used to indicate the MIME type of the related document. It is not to be used to embed the related document, and thus ParentDocument.text.BIN is precluded from use.
-
ServiceEvent: This class represents the main Act, such as a colonoscopy or an appendectomy, being documented.
In some cases, the ServiceEvent is inherent in the ClinicalDocument.code, such as where ClinicalDocument.code is "History and Physical Report" and the procedure being documented is a "History and Physical" act. A ServiceEvent can further specialize the act inherent in the ClinicalDocument.code, such as where the ClinicalDocument.code is simply "Procedure Report" and the procedure was a "colonoscopy". If ServiceEvent is included, it must be equivalent to or further specialize the value inherent in the ClinicalDocument.code, and shall not conflict with the value inherent in the ClinicalDocument.code, as such a conflict would constitute an ambiguous situation.
ServiceEvent.effectiveTime can be used to indicate the time the actual event (as opposed to the encounter surrounding the event) took place.
The performer participant represents clinicians who actually and principally carry out the ServiceEvent. Performer.time can be used to specify the time during which the performer is involved in the activity. Performer.functionCode can be used to specify addition detail about the function of the performer (e.g. scrub nurse, third assistant).
-
Order: This class enables the representation of those orders being addressed by this document. For instance, a provider orders an X-Ray. The X-Ray is performed. A radiologist reads the X-Ray and generates a report. The X-Ray order identifier is transmitted in the Order class (Order.id), the performed X-Ray procedure is transmitted in the ServiceEvent clone, and the ClinicalDocument.code would be valued with "Diagnostic Imaging Report".
-
Consent: This class references the consents associated with this document. The type of consent (e.g. a consent to perform the related ServiceEvent, a consent for the information contained in the document to be released to a third party) is conveyed in Consent.code. Referenced consents are those that have been finalized (Consent.statusCode must equal "completed") and should be on file. The authorization.typeCode can be either "AUTH" (authorized by) or "REFR" (refers to). Use "AUTH" when the referenced consent is an authorization for the procedure or other act being documented. Use "REFR" for any other referenced consent.
-
EncompassingEncounter: This class represents the clinical encounter during which the documented act occurred. Documents are not necessarily generated during an encounter, such as when a clinician, in response to an abnormal lab result, attempts to contact the patient but can't, and writes a Progress Note.
In some cases, the setting of the encounter is inherent in the ClinicalDocument.code, such as where ClinicalDocument.code is "Diabetes Clinic Progress Note". The setting of an encounter can also be transmitted in the EncompassingEncounter.code or HealthCareFacility.code attribute. If either are sent, they should be equivalent to or further specialize the value inherent in the ClinicalDocument.code (such as where the ClinicalDocument.code is simply "Clinic Progress Note" and the value of HealthCareFacility.code is "cardiology clinic"), and shall not conflict with the value inherent in the ClinicalDocument.code, as such a conflict would constitute an ambiguous situation.
EncompassingEncounter.effectiveTime represents the time of the encounter. EncompassingEncounter.dischargeDispositionCode can be used to depict the disposition of the patient at the time of hospital discharge (e.g., discharged to home, expired, against medical advice, etc.).
The location participant (location class) relates a healthcare facility (HealthCareFacility class) to the encounter to indicate where the encounter took place. The entity playing the role of HealthCareFacility is a place (Place class). The entity scoping the HealthCareFacility role is an organization (Organization class).
The setting of an encounter (e.g. cardiology clinic, primary care clinic, rehabilitation hospital, skilled nursing facility) can be expressed in HealthCareFacility.code. Note that setting (HealthCareFacility.code) and physical location (Place) are not the same. There is a many-to-many relationship between setting and the physical location where care is delivered. For instance, a particular place such as a room can provide the location for the cardiology clinic setting one day, and for the primary care clinic setting another day; and cardiology clinic today might be held in one place, but in another place tomorrow.
The encounterParticipant participant represents clinicians directly associated with the encounter (e.g. by initiating, terminating, or overseeing it).
Document Participants
This section describes classes related to the root ClinicalDocument class via Participation.
-
authenticator: Represents a participant who has attested to the accuracy of the document, but who does not have privileges to legally authenticate the document. An example would be a resident physician who sees a patient and dictates a note, then later signs it. Authenticator.time reflects the time of authentication. Authenticator.signatureCode specifies whether and how the participant has attested his/her participation through a signature and or whether such a signature is needed.
-
author: Represents the humans and/or machines that authored the document. Author.time reflects the time of authorhip.
In some cases, the role or function of the author is inherent in the ClinicalDocument.code, such as where ClinicalDocument.code is "Medical Student Progress Note". The role of the author can also be recorded in the Author.functionCode or AssignedAuthor.code attribute. If either of these attributes is included, they should be equivalent to or further specialize the role inherent in the ClinicalDocument.code (such as where the ClinicalDocument.code is simply "Physician Progress Note" and the value of Author.functionCode is "rounding physician"), and shall not conflict with the role inherent in the ClinicalDocument.code, as such a conflict would constitute an ambiguous situation.
-
custodian: Represents the organization that is in charge of maintaining the document. The custodian is the steward that is entrusted with the care of the document. Every clinical document has exactly one custodian.
-
dataEnterer (e.g. transcriptionist): Represents the participant who has transformed a dictated note into text. DataEnterer.time reflects the time of data entering.
-
encounterParticipant: See the discussion on EncompassingEncounter for a description of the encounterParticipant participant.
-
informationRecipient: Represents a recipient who should receive or has received a copy of the document. When the intended recipient is an organization, the value for IntendedRecipient.classCode is "ASSIGNED", and the recipient is reflected by the presence of a scoping Organization, without a playing entity.
NOTE: The information recipient is an entity to whom a copy of a document is directed, at the time of document authorship. It is not the same as the cumulative set of persons to whom the document has subsequently been disclosed, over the life-time of the patient. Such a disclosure list would not be contained within the document, and is outside the scope of CDA.
-
legalAuthenticator: Represents a participant who has legally authenticated the document. LegalAuthenticator.time reflects the time of legal authentication. LegalAuthenticator.signatureCode specifies whether and how the participant has attested his/her participation through a signature and or whether such a signature is needed.
-
participant: Used to represent other participants not explicitly mentioned by other classes, that played a role in the documented act. When the participating entity is an organization, this is reflected by the presence of a scoping Organization, without a playing entity.
-
performer: See the discussion on ServiceEvent for a description of the performer participant.
-
recordTarget: The recordTarget represents the medical record that this document belongs to. A clinical document typically has exactly one recordTarget participant. In the uncommon case where a clinical document (such as a group encounter note) is placed into more than one patient chart, more than one recordTarget participants can be stated.
The subject participant represents the primary target of the observations recorded in the document. Most of the time the subject is the recordTarget, but need not be, for instance when the subject is a fetus observed in an obstetrical ultrasound. Therefore, there is both a recordTarget and a subject. To be explicit, both recordTarget and subject should be valued, even when redundant. When the subject is not included, it can be assumed that the subject is the recordTarget.
-
subject: See discussion of recordTarget above.
Several participations can be played by the same person. In such cases, the person should be identified as the player for each appropriate participation. For instance, if a person is both the author and the authenticator of a document, the message should identify that person as both the author participant and the authenticator participant.
On other occasions, participants are played by different people. The following table shows a number of scenarios and the values for various participants.
| 1. StaffPhysicianOne sees a patient as a consultant, dictates a note, and later signs it. |
|---|
|
| 2. StaffPhysicianOne sees a patient and dictates a note. StaffPhysicianTwo later signs the note. * |
|
| 3. ResidentOne sees a patient with StaffPhysicianOne. ResidentOne dictates a note and later signs it. The note is co-signed by StaffPhysicianOne. * |
|
| 4. ResidentOne sees a patient with StaffPhysicianOne. ResidentOne dictates a note and later signs it. The note is co-signed by StaffPhysicianTwo. * |
|
| 5. ResidentOne sees a patient with StaffPhysicianOne. ResidentOne dictates a note, and goes off on vacation. The note is signed by ResidentTwo and by StaffPhysicianOne. * |
|
| 6. ResidentOne sees a patient with StaffPhysicianOne. ResidentOne dictates a note, which is later signed by ResidentTwo and StaffPhysicianTwo. * |
|
| 7. StaffPhysicianOne receives an abnormal lab result, attempts to contact patient but can't, and writes and signs a progress note. |
|
| 8. ResidentSurgeonOne is operating on a patient with StaffSurgeonOne. StaffSurgeonOne dictates an operative report and later signs it. |
|
* Note that the ability of one clinician to co-sign or to sign on behalf of another clinician is subject to regulatory and local practice constraints.
| Return to top of page |