Class: Clinical_document_header

Description of: Clinical_document_header

Class steward is Information Management (Medical Records)
Interested committees Orders/Observation
Documentation of a health related factor concerning a patient. See the class Document Header in the MDR 2300 model.

OpenIssue: This needs to be extended to be the state attribute of the class and to have all of its transition and code values identified. Needs to be reconciled with the other status codes that exist for this class. This should be just status_cd rather than completion_status_cd. - the other three fragments must be

OpenIssue: Expand definition. Header and "documentation" seem different. Remove reference to MDR 2300 and replace with explanatory material.

OpenIssue: The State transition diagram needs to be drawn. Information provided to RIM Harmonization 06/99 included: DI ---> AU | IN | LA | IP | PA DO ---> AU | PA | LA IP ---> IN | AU | LA | PA IN ---> AU | LA | PA PA ---> AU | LA AU ---> LA LA ---> <final state>

OpenIssue: The functionality of this class overlaps with the functionality of the service class with its associated actors and targets. We are currently working to enhance the service class to accommodate all of the functionality of this class, at which time we anticipate deleting this class from the RIM.

Attribute definitions for: Clinical_document_header

availability_status_cd ::

A code depicting the availability of the document.

OpenIssue: Please indicate how the different availability statuses are distinguished. Examples would be good.

change_reason_cd ::

A code depicting the reason for the latest change to the document.

OpenIssue: Include examples or other ways of indicating how change reasons are discriminated.

completion_status_cd ::

A code depicting the completion status of the document, e.g., incomplete, authenticated, legally authenticated.

OpenIssue: This needs to be extended to be the state attribute of the class, and to have all of its transition and code values identified. Needs to be reconciled with the other status codes that exist for this class. This should be just "status_cd" rather than "completion_status_cd" - the other three fragments must be incorproated into a single state machine. The class must also be identified as a Subject Class. There are also style guide issue here as well.

OpenIssue: Indicate typical completion status or describe what kind of states are designated with these statuses.

|TXA^17^00928^Document Completion Status|

confidentiality_status_cd ::

A code depicting the confidentiality status of the document.

OpenIssue: Indicate typical confidentiality statuses or describe what kind of states are designated with these statuses.

content_presentation_cd ::

A code indicating how the content of the document is to be presented.

OpenIssue: Indicate typical presentation codes or describe what kind of states are designated with these codes.

document_change_cd :: CV

Code classifying the document as an original or a replacement document. An original document is the first version of a document. An addendum is an appendage to an existing document that contains supplemental information. The appendage is itself a document, and acquires a new value for Clinical_document_header.id. The parent document being appended is referenced via the has_as_parent_document association. The parent document being appended remains in place and its content and authentication status are unaltered. A replacement document replaces an existing document. The replacement document has the same value for Clinical_document_header.id as the parent document being replaced. The parent document being replaced becomes obsolete, but is still retained in the system for historical reference.

document_creation_dttm :: TS

The specific date that the document was initiated.

file_nm :: ST

The name on an electronic file containing the document.

id :: II

A unique identifier assigned to the document.

last_edit_dttm ::

The date the document was last edited.

reporting_priority_cd ::

The reporting priority of the clinical result.

OpenIssue: Indicate typical priority codes or describe what kind of states are designated with these codes.

|OM1^26^00611^Reporting Priority|

results_report_dttm ::

The date and time the clinical observation results are issued.

Rationale: closer to language used in V2.3

|OBR^22^00255^Results Rpt/Status Chng - Date/Time|

storage_status_cd ::

A code depicting the storage status of the document.

OpenIssue: Indicate typical storage statuses or describe what kind of states are designated with these statuses.

transcription_dttm ::

The date the information in the document was transcribed.

type_cd :: CD

A code depicting the document type (e.g., discharge summary, progress note).

version_dttm :: TS

Represents the date/time of the current document version. A document versions when it replaces an existing document.

version_nbr :: INT

Version number is an integer starting at '1' and incrementing by 1. The first instance or original document should always be valued as '1'. The version number value must be incremented by one when a document is replaced. The value of Clinical_document_header.availability_status_cd of the prior version should become 'obsolete', explicitly via another message.

OpenIssue: May be a need for an instance ID that is unique for the document. This may remove the need for the version number; needs to be examined by the committee. There should probably be one or more recursive relationships here so that the relationship between documents is explicit. There may also be more than just 'append' and 'replace' for these type relationships.

Association definitions for: Clinical_document_header

has_originating_organization (0,1) :: Healthcare_provider_organization :: originates (0,n)

OpenIssue: There are at least three different ways to accomplish this, including handling the existing RIM through MIM rules and verbage. This should be examined jointly between the committees and MnM to resolve the best way to do this.

has_been_originated_by (1,n) :: Originator :: of (1,n)

has_as_a_parent_document (0,1) :: Clinical_document_header :: is_parent_document_for (0,n)

is_part_of (1,1) :: Clinical_document :: has_parts (1,1)

OpenIssue: There appears to be some problems with how this is modeled, and the committees should re-examine this. There must be either attributes or associations added to this class or a persuasive Rationale.

is_parent_document_for (0,n) :: Clinical_document_header :: has_as_a_parent_document (0,1)

is_authenticated_by (0,n) :: Authentication :: authenticates (1,1)

documents (0,n) :: Service :: is_documented_by (0,n)

OpenIssue: This many-to-many association should be resolved.

has_been_received_by (0,1) :: Document_recipient :: of (0,n)

OpenIssue: Review cardinality. Document recipient looks like a role class, perhaps requires relationship to the document header to exist.

contained_in (0,1) :: Health_chart :: contains (0,n)

is_transcribed_by (0,1) :: Transcriptionist :: transcribes (0,n)

OpenIssue: This association would appear to be mandatory from Transcriptionist to document header, since the transcriptionist instance (a role class) is not otherwise needed.

OpenIssue: Review cardinality.