HL-7 Medical Record/Health Information Management



HL-7 Medical Record/Health Information Management

Technical Committee Meeting

St. Louis, MO

September 12 & 13, 2000

Attendees:

Tuesday Morning, Joint Meeting with Orders and Observations Subcommittee: Joann Larson, Sean Sudduth, Harry Rhodes, Wayne Tracy

Tuesday Afternoon, Joint Meeting with Scheduling and Logistics: Joann Larson, Sean Sudduth, Harry Rhodes, Wayne Tracy, Anita Benson, Robert Morgan, Jane Foard

Wednesday Morning, Joint Meeting with Scheduling and Logistics: Harry Rhodes, Wayne Tracy, Anita Benson, Jane Foard, John Hornsey, Sean Sudduth, Serafina Versaggi

Wednesday Afternoon, Joint Meeting with Orders and Observations Subcommittee: Harry Rhodes, Wayne Tracy, Joann Larson, Thanos Tsioli, Thanh-Le Nguyen

Highlights:

• Working jointly with the Orders and Observations Subcommittee advanced work toward the proper use of Medical Document Management (MDM) vs. Order Results Update (ORU) for transcribed results. And advanced work on issues surrounding the document availability status TXA segment.

• Working jointly with Orders/Observations, Patient Care, and XML SIG discussed differences and similarities between HL-7 and CDA Level Three document and message content.

• Working jointly with the Scheduling and Logistics Technical Committee continue developmental work on the Scheduling Context Trigger Events, the Interaction Diagram, use case studies, as well as agreed upon terminology and definitions.

Tuesday, Morning MR/HIM TC: Wayne welcomed the committee members and introductions were made.

The first agenda item was a discussion of the confusion surrounding the use of a MDM vs. ORU for transcribed reports. Consensus was quickly achieved that there should not be two different message methodologies.

The Orders and Observations TC submitted four proposed solutions to address the confusion over whether a transcribed report should be sent with a MDM vs. ORU message.

After a brief discussion, the committee reached consensus on the four proposed solutions.

Proposed Solutions: The following solutions were agreed upon by the committee:

1. Add explanatory language to the ORU explaining if and when it should be used as opposed to the MDM. And conversely explanatory language will be added MDM explaining when it should be used as opposed to the ORU.

2. In the next balloting cycle, the Medical Records TC will propose the inclusion of the ORC/OBR along with new trigger events to accommodate sending Results associated with explicit orders using MDM message. Orders/Observations suggest the removal of the EVN segment from the MDM message requirements. The MR TC pointed out that the EVN serves a purpose, but would be willing to entertain a proposal as to alternatives to the using the EVN.

3. If the ORU is retained as a legitimate transcription message, assign a unique trigger event so that appropriate segment optionality can be defined. This issue out of the scope of the MR TC

4. If the ORU is retained as a legitimate transcription message, modify the grammar to include the TXA and deprecate the OBR-35. This is out of scope for the Medical Record TC. But the recommendation from the Medical Record TC is that the ORU not include the TXA, because of the resulting confusion that this approach would cause.

1 PURPOSES

This chapter currently supports document management. 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 document that serves as a comprehensive account of healthcare services provided to a patient.

Insert ORU exceptions to transcription here or in 9.2.

This chapter defines the transactions at the seventh level, i.e., the abstract messages. Various schemes may be used to generate the actual characters that comprise the messages according to the communications environment. The HL7 Encoding Rules will be used where there is not a complete Presentation Layer. This is described in Chapter 1, “Relationship to Other Protocols.” The examples in this chapter were constructed using the HL7 Encoding Rules.

2 DOCUMENT MANAGEMENT SECTION

This section defines the Medical Document Management (MDM) transaction set. It supports transmission of new or updated documents or information about their status(es). The trigger events and messages may be divided into two broad categories, one which describes the statuses of documents, and one which both describes the statuses and contains the document content itself.

The document management section is concerned primarily with the management of those documents and entries which are created as a result of a transcription process. These documents are created in two distinct contexts, one of which is related to an order and describes the procedures or activities associated with that order, and another which occurs independent of the order process. The scope of this section also includes any document that contains data derived from orders or results but which must be treated as aggregate display data due to system limitations. This is a transition strategy to support integration of data across the continuum of care.

The content of a document can be represented with one or more observation segments (OBX). Where headings or separations naturally exist within the text, it is preferred that each of these blocks be represented as a separate OBX record. Where systems are able to decompose the text into separate medical concepts, the most atomic level of granularity of content should be represented, ideally with each medical concept being represented in its own OBX segment. Many of these concepts can be represented as coded entities.

Insert ORU exceptions to transcription here or in 9.1.

Tuesday, Morning 11:00 a.m. – 12:30 a.m. Joint Meeting with Orders/Observations, CDA: An attendance list and minutes were taken by Orders/Observation, see Orders/Observations minutes.

A Clinical Document Architecture (CDA) – O/O Differentiation proposal document was distributed to the joint committee. (see attachment) Wayne Tracy raised an objection to the first bullet of the CDA document characteristics, “Persistence” the statement “A clinical document continues to exist in an unaltered state, for a time period defined by local and regulatory requirements. Clinical documents cannot exist in an unaltered state, because they may need to be updated or amended. This proposal appears to be written to allow reports to written to a WORM format. An individual organization may make a business decision to store health information in a WORM format. However, these standards should not be dictated by one organization’s business actions. Wayne also pointed out the clear distinction between authentication to identify the author of the document, and legal authentication, where the responsible practitioner validates the authenticity of the document. There was a discussion of the need for standardization of the document and message content vs. the need for unique message packaging for observations formats. There was a discussion of the differences in the use of the meta-data about the document.

Wayne Tracy pointed out that meta-data messages are not always linked to a document.

The committee reviewed the use cases for packaging observations in “documents” vs. “messages” included in the CDA proposal document. The JWG came to the following conclusions and set of actions:

• Within the RIM there needs to be massaging for the CDA. Some RIM harmonization work will need to be done.

• The committee will look at the different use cases to determine whether the various proposed use cases for documents and messages are unique. And, to determine if there are real differences in the messages and documents.

• The use cases should be reviewed against existing HL-7 interactions.

Tuesday Afternoon, Joint Meeting with Scheduling and Logistics:

Wayne welcomed the committee members and introductions were made. The minutes of the last meeting were reviewed and approved.

The JWG attendees present were concerned about advancing the work of the last meeting, considering the absence of the Australia and Dutch members that were key to the development of the use case model and trigger events at the last meeting.

It was decided that the JWG members present would attempt to make the addition refinements to the use case model.

Anita was approached by a member of Data Warehousing TC, The Data Warehousing TC would like to develop a specimen tracking model for clinical pathology. The Data Warehouse group will write and submit a proposal. A discussion followed as to where or not the chart-tracking model being by this committee was generic enough to allow it’s a application to the tracking of any object. Anita suggested that we consider a reusable paradigm for the tracking and management of any item.

The discussion moved to the definition and role of the chart manager and the chart owner. Are these individuals the same entity? The JWG agreed that the chart owner could be a different than the chart manager. The chart manager is the individual/entity that tracks the location of the charts. There was a discussion of ownership of the record. There was a comparison made between the European, Australian, and American ownership model.

The JWG voted to defer the decision on collapsing chart manager, chart owner into the chart custodian. It was decided to dialogue on the on the issue.

Wayne proposed a solution to the issue of creating a chart custodian role and a chart owner role. If the role cannot be demonstrated on the use case diagram, then the chart owner role should be eliminated.

Wayne introduced the idea of Passive Chart Management System where there is not a chart manager or chart custodian, rather, a chart tracking application that simply tracks that current location of the chart. In this model the chart owner would need to update the Passive Chart Management System each time the location changes.

There was a discussion of the last two trigger events that were created at the last meeting. These trigger events would allow the end users to track the creation of a new chart and to track the Home location of the chart.

The following change was suggested by Wayne to further clarify the trigger as indicating the creation of a new chart “New-Chart Location Notification” the placement of a hyphen between new and chart.

New use case: An appointment has made for a patient to be seen in a clinic. The request for the chart has been made. However, the chart is located outside the clinic at another location. Does our current case use network work? If this outside location is another organization, a release of information would need to be submitted. This use case would be outside the scope of this JWG.

The use case model that has been development so far by this JWG would best work within the scope of the organization or network.

A discussion was begun about tracking copies of the medical record that have been forwarded to another provider. It was decided that this scenario was outside the scope of this JWG. The release of information function is how copies are sent to another provider. Once the records are received they become part of the providers medical record.

Wednesday Morning; Joint Working Group Meeting with Scheduling and Logistics:

Wayne welcomed everyone and introductions were made.

Wayne began the discussion of the various models advanced by the committee to date.

Central Management Model – One central chart manager with control over scheduling and delivery of requested charts. A message was created that would allow the delivery of the chart at a later time “proximal to need” a just in time delivery model. In the active chart management model the manager knows where every chart is and actively controls the location and the access to the health information.

Passive Chart Management Model - No active chart management model, end users would management the distribution of requested charts. In the passive model there is tracking of the chart location, but no one entity is responsible for the over-site of the chart location and protection.

Custodian/Manager Model: The owner of the chart is the holder and manager of the chart distribution. This is a decentralized model.

CT03 – This was created to send a message as to the chart availability or non-availability of the chart. There would also be a response that would inform the requester of the availability of the chart.

CT04 – Delete Chart Transfer Request this message would cancel the request for a chart.

CT07 – New-Chart Location Notification would inform all interested parties that a new chart has been created. The owner/holder of the chart is also identified.

CT08 – Chart Home Location Change Notification would send a message to all system users regarding who is the owner of the record.

U.S. Ownership Behavior: the facility owns the record. Controls access with in the organization. Seeks patient authorization for release outside the organization.

U.S. Managed Care/HMO Ownership Behavior: The managed care organization region owns the record. The ownership is the HMO network. The record can move freely with in the network without securing patient authorization.

U.K. Ownership Behavior: Individual physicians own and hold the records. The facility receives the record from the physician and returns the record once service is completed.

Australian Ownership Behavior: In New South Wales for example there are 17 health service areas (regions) each of the facility keeps their own records. Each of the facilities acts as an autonomous facility and the patient authorization is need to send and abstract the record. The original record is never leaves the creating facility. If the patient goes to another service area a new record is created at the new facility. There can be more that one copy of the patient record. This is a passive management model

Dutch Model Ownership Behavior: Each department owns their own records, i.e. Internal Medicine owns is own record. The record is decentralized and if compiled it is a composite of all of these decentralized records. The departments creating these records never surrender their original records.

Committee Action Item: the committee needs to obtain a medical record structure models from the U.K., Australia, and Dutch. The committee will also need to obtain a use case model for record distribution, chart tracking, to include information on the granularity of the record management system in each of these countries.

U.S. chart request models: Many models exist that are based on individual entity policies and procedures. Many times the requestor will ask for the entire record because not being familiar with the content of the record will ask for all of the record in order to ensure that no information is overlooked. Another method would be to request traditional reports i.e. History and Physical, Operative Note, Pathology report…

A discussion followed surrounding the issues related to privacy and organization operations that block the transfer of the entire chart upon request. Privacy advocates have raised concerns over the automatic release of the entire record upon request. From the organizational operations point of view, the majority of facilities are still using paper records and copies would have to be made to transfer record to a requesting. Requests for the entire chart require a large amount of resources to comply with. Even departments with electronic records are unable to electronically sent records to requests because of interface issues. The copies of the electronic record must be printed and sent to any requestor. There is a global need for standardization, and uniformity of medical record content and definition. Such standardization would serve the ready transfer of health information, as well as allowing for better control over health information access. Eliminating the current need to send the entire chart to a requestor.

New trigger event was created TC09 - New Chart Request: From a chart requestor to a chart manager requesting the record of a new patient. This scenario would apply to a central registration model where the registration department has to assign a chart number and register the patient. This would allow a department to request a chart on a patient not yet registered. The return response would contain the registration information and chart number.

[pic]

Wednesday afternoon, Joint Meeting with Orders and Observations Subcommittee:

Wayne welcomed everyone and introductions were made.

A discussion was begun of the Orders and Observation proposal.

* This proposal was accepted by the Medical Record TC contingent upon approval by Orders and Observation TC

MDM vs ORU Proposal

There is considerable difficulty in interpreting the HL7 Standard when implementing transcription messages. For example, if the reader is looking for direction on what message to use for a transcribed lab pathology report the standard is ambiguous. After reading the Document Management (MDM) messages as described in section 9.4 of chapter 9, it would appear that the MDM message is appropriate, although lab pathology is not a suggested value in user-defined table 0270 Document Type as used in TXA-2 Document Type. Section 7.1 of chapter 7 speaks broadly and vaguely about structured reports. The reader is not referred elsewhere, such as chapter 9, for transcribed reports. Indeed, the presence of a Transcriptionist field in the OBR segment, specifically OBR-35 suggests that the ORU is a valid mechanism for transmitting transcription reports.

We believe that HL7 should clearly and unambiguously designate which message is to be used for transcription; there should not be 2 applicable to the same function.

proposed solution

1. Add explanatory language to the ORU explaining if and when it should be used as opposed to the MDM. Conversely, add explanatory language to the MDM explaining when it should be used as opposed to the ORU.

2. Deprecate OBR-35 from OBR segment in both Chapters 4 and 7

3. Remove transcription examples from Chapter 7. Note that the review of Chapter 7 to identify and remove transcription examples is not complete in this proposal.

1 PURPOSE

This chapter describes the transaction set required for sending structured patient-oriented clinical data from one computer system to another. A common use of these transaction sets will be to transmit observations and results of diagnostic studies from the producing system (e.g., clinical laboratory system, EKG system) (the filler), to the ordering system (e.g., HIS order entry, physician’s office system) (the placer). However, the transaction set is not limited to such transactions. Observations can be sent from producing systems to archival medical record clinical information systems (not necessarily the order placer) and from such medical record systems to other systems that were not part of the ordering loop, e.g., an office practice system of the referring physician for inpatient test results ordered by an inpatient surgeon. This chapter also provides mechanisms for registering clinical trials and methods for linking orders and results to clinical trials and for reporting experiences with drugs and devices.

These transaction sets permit the transmission of any kind of clinical observations including (but not limited to) clinical laboratory results, the results of imaging studies (excluding the image), EKG pulmonary function studies, measures of patient status and condition, vital signs, intake and output, severity and/or frequency of symptoms, drug allergies, problem lists, diagnostic lists, physician and nursing history, physicals, progress notes, operative notes and so on.

These transaction sets permit the transmission of 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, ?drug allergies?, ?problem lists?, ?diagnostic lists?.

If the observation being reported meets any of the following criteria, then the content would qualify as a medical document management message rather than an observation message. The reader is referred to the MDM message type in Chapter 9.

• Documents containing observations where the whole requires a signature

• Documents containing observations where the whole requires authentication

• Dictated and/or Transcribed reports

• Documents requiring succession management (of both document addenda and replacement documents).

1 OBR - observation request segment

In the reporting of clinical data, the OBR serves as the report header. It identifies the observation set represented by the following atomic observations. It includes the relevant ordering information when that applies. It contains many of the attributes that usually apply to all of the included observations.

When a set of observations is ordered, the order message contains an OBR segment. However, observations can be collected and reported without an antecedent order. When observations are reported, the report message also includes one or more OBR segments. So, the OBR segment is like a turn-around document. Some fields in the OBR segment apply only to the ordering message and some to the reporting message. To those familiar with healthcare procedures, these should be obvious from their names (e.g., transcriptionist or principal result interpreter could only apply to the reporting phase). However, we have also flagged them in Figure 7-4 to indicate whether placer, filler, or both may send data in a given field.

HL7 Attribute Table - OBR

|SEQ |LEN |DT |OPT |RP/# |TBL# |ITEM # |ELEMENT NAME |

| | | | | | | | |

|35 |200 |CM |O B |Y | |00267 |Transcriptionist + |

| | | | | | | | |

Note: The complete description of these fields is provided below as well as in Chapter 4.

1 OBR-35 Transcriptionist (CM) 00267

Components: ^ ^ ^ ^ ^ ^ ^ ^ ^ ^

Subcomponents of name: & & & & & & & &

Subcomponents of facility: & &

Definition: This field identifies the report transcriber.

This field is retained for backward compatibility only. Use of this field implies that the message content is a transcription in nature and thus is not supported in the ORU message construct. The reader is referred to the MDM messages in Chapter 9.

2

1 7.3.2.4 OBX-4 Observation sub-ID (ST) 00572

Definition: This field is used to distinguish between multiple OBX segments with the same observation ID organized under one OBR. For example, a chest X-ray report might include three separate diagnostic impressions. The standard requires three OBX segments, one for each impression. By putting a 1 in the Sub-ID of the first of these OBX segments, 2 in the second, and 3 in the third, we can uniquely identify each OBX segment for editing or replacement.

The sub-identifier is also used to group related components in reports such as surgical pathology. It is traditional for surgical pathology reports to include all the tissues taken from one surgical procedure in one report. Consider, for example, a single surgical pathology report that describes the examination of gallbladder and appendix tissue. This report would be transmitted roughly as shown in Figure 7-2. Replace this example with urine analysis microscopic crystals example, or a CBC, differential/mylocytes example.

The following example should be moved to Chapter 9 and replaced here with an example that does not appear to be so document oriented

Figure 7-2. Example of sub-identifier usage

MSH||||||||MDM^T02^MDM_T02|...

OBR|1|||88304&SURG PATH REPORT...

OBX|1|CE|88304&ANT|1|T57000^GALLBLADDER^SNM...

OBX|2|TX|88304&GDT|1|THIS IS A NORMAL GALLBLADDER...

OBX|3|TX|88304&MDT|1|MICROSCOPIC EXAM SHOWS HISTOLOGICALLY

NORMAL GALLBLADDER TISSUE...

OBX|4|CE|88304&IMP|1|M-00100^NML^SNM...

OBX|5|CE|88304&ANT|2|T66000^APPENDIX^SNM...

OBX|6|TX|88304&GDT|2|THIS IS A RED, INFLAMED, SWOLLEN, BOGGY APPENDIX...

OBX|7|TX|88304&MDT|2|INFILTRATION WITH MANY PMN's - INDICATING INFLAMATORY CHANGE...

OBX|8|CE|88304&IMP|2|M-40000^INFLAMMATION NOS^SNM...

The example in Figure 7-2 has two segments for each component of the report, one for each of the two tissues. Thus, there are two 88304&ANT segments; there are two 88304&GDT segments, and there are two 88304&MDT segments. Segments that apply to the gallbladder all have the sub-identifier 1. Segments that apply to the appendix all have sub-identifier 2.

The observation sub ID has other grouping uses. It can be used to organize the reporting of some kinds of fluid intakes and outputs. For example, when intake occurs through multiple intravenous lines, a number of separate observations (OBX segments), the intake volume, the type of intake (Blood, D5W, Plasma, etc.), the site of the IV line, etc. may be needed for each intravenous line, each requiring a separate OBX segment. If more than one IV line is running, we can logically link all of the OBX segments that pertain to the first IV line by assigning them an observation sub ID of 1. We can do the same with the second IV line by assigning them a sub ID 2 and so on. The same would apply to the outputs of surgical drains when there are multiple such drains.

The use of the sub ID to distinguish repeating OBXs for the same observation ID is really a special case of using the sub ID to group, as can be seen if we picture the OBX segments in Figure 7-6 as part of a table where the rows correspond to a particular species of observation and the cells correspond to the sub ID numbers that would be associated with each corresponding OBX.

|Distinct Observations |88304&ANT |88304&GDT |80304&MDT |80304&IMP |

|Sub ID 1st Group |1 |1 |1 |1 |

|Sub ID 2nd Group |2 |2 |2 |2 |

The use of Sub IDs to group results is equivalent to defining a table, and the use of sub IDs to distinguish repeats is just a special case, represented by one column in this table.

However, this approach introduces ambiguities if we have a set of repeating observations within a group, e.g., if the appendix observations include two impressions as in the 8th and 9th OBXs shown in Figure 7-7. This really represents the existence of a row nested within a single cell of the table given above.

Figure 7-3. Example of sub-identifier usage

OBX|1|CE|880304&ANT|1|T57000^GALLBLADDER^SNM...

OBX|2|TX|880304&GDT|1|THIS IS A NORMAL GALL BLADDER...

OBX|3|TX|880304&MDT|1|MICROSCOPIC EXAMINATION SHOWS HISTOLOGICALLY

NORMAL GALLBLADDER TISSUE...

OBX|4|CE|880304&IMP|1|M-00100^NML^SNM...

OBX|5|CE|880304&ANT|2|T57000^APPENDIX^SNM...

OBX|6|TX|880304&GDT|2|THIS IS A RED, INFLAMED APPENDIX...

OBX|7|TX|880304&MDT|2|INFLAMMATION WITH MANY PUS CELLS-ACUTE INFLAMMATION...

OBX|8|CE|880304&IMP|2|M-40000^INFLAMMATION NOS^SNM...

OBX|9|CE|880304&IMP|2|M-30280^FECALITH^SNM...

The text under OBX-5-observation value provides guidance about dealing with two OBXs with the same observation ID and observation sub IDs. They are sent and replaced as a unit. However, some systems will take this to mean that the set of OBXs is to be combined into one composite observation in the receiving system. We suggest the use of a dot and a string (similar to the Dewey Decimal system) when users wish to distinguish each of the repeats within one type, or results within a cell for editing and correction purposes. Using this system, Figure 7-3 would become 7-4. If there are cases where such nesting occurs at even deeper levels, this approach could be extended.

Figure 7-4. Example of sub-identifier usage

OBX|1|CE|880304&ANT|1|T57000^GALLBLADDER^SNM...

OBX|2|TX|880304&GDT|1|THIS IS A NORMAL GALL BLADDER...

OBX|3|TX|880304&MDT|1|MICROSCOPIC EXAMINATION SHOWS HISTOLOGICALLY

NORMAL GALLBLADDER TISSUE...

OBX|4|CE|880304&IMP|1|M-00100^NML^SNM...

OBX|5|CE|880304&ANT|2|T57000^APPENDIX^SNM...

OBX|6|TX|880304&GDT|2|THIS IS A RED, INFLAMED APPENDIX...

OBX|7|TX|880304&MDT|2|INFLAMMATION WITH MANY PUS CELLS-ACUTE INFLAMMATION...

OBX|8|CE|880304&IMP|2.1|M-40000^INFLAMMATION NOS^SNM...

OBX|9|CE|880304&IMP|2.2|M-30280^FECALITH^SNM...

Use a null or 1 when there is no need for multiples.

If the observation includes a number of OBXs with the same value for the observation ID OBX-3, then one must use different values for the sub-ID. This is in fact the case of the repeats depicted in Figure 7-8, but without any need to group sets of OBXs. Three such OBXs could be distinguished by using sub-IDs 1, 2 etc. alternatively, sub-IDs 1.1, 1.2, 1.3 could be used, as shown in Figure 7-8. Figure 7-9 shows and example of an electrocardiograph chest radiograph report with three diagnostic impressions, using 1,2,3 in the sub-ID field to distinguish the three separate results.

Figure 7-5. Example of Sub-ID used to distinguish three independent results with the same observation ID

OBX|1|CE|8601-7^EKG IMPRESSION ^LN|1|^atrial fibrillation|. . .

OBX|2|CE|8601-7^EKG IMPRESSION ^LN|2|^OLD SEPTAL MYOCARDIAL INFARCT| . . .

OBX|3|CE|8601-7^EKG IMPRESSION ^LN|3|^poor R wave progression|. . .

1 PURPOSES

This chapter currently supports document management. 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 document that serves as a comprehensive account of healthcare services provided to a patient.

Documents supported in this chapter will meet one or more of the following criteria. The reader is referred to the ORU message framework in Chapter 7 for messages that do not meet any of the following criteria.

• Documents containing observations where the whole requires a signature

• Documents containing observations where the whole requires authentication

• Dictated and/or Transcribed reports

• Documents requiring succession management (of both document addenda and replacement documents).

• Documents where the content requires a security status applying to the whole.

Within the context of the above criteria, these transaction sets permit the transmission of a wide range of clinical reports and/or observations. These documents include (but are not limited to) pathology reports, diagnostic imaging interpreted reports, EKG interpretations, pulmonary function studies, measures of patient status and condition, severity and/or frequency of symptoms, history & physical, nursing history, progress notes, operative notes, and reporting experiences with drugs or devices.

This chapter defines the transactions at the seventh level, i.e., the abstract messages. Various schemes may be used to generate the actual characters that comprise the messages according to the communications environment. The HL7 Encoding Rules will be used where there is not a complete Presentation Layer. This is described in Chapter 1, “Relationship to Other Protocols.” The examples in this chapter were constructed using the HL7 Encoding Rules.

2 DOCUMENT MANAGEMENT SECTION

This section defines the Medical Document Management (MDM) transaction set. It supports transmission of new or updated documents or information about their status(es). The trigger events and messages may be divided into two broad categories, one which describes the statuses of documents, and one which both describes the statuses and contains the document content itself.

The document management section is concerned primarily with the management of those documents and entries, which are created as a result of a transcription process. These documents are created in two distinct contexts, one of which is related to an order and describes the procedures or activities associated with that order, and another which occurs independent of the order process. The scope of this section also includes any document that contains data derived from orders or results but which must be treated as aggregate display data due to system limitations. This is a transition strategy to support integration of data across the continuum of care.

The content of a document can be represented with one or more observation segments (OBX). Where headings or separations naturally exist within the text, it is preferred that each of these blocks be represented as a separate OBX record. Where systems are able to decompose the text into separate medical concepts, the most atomic level of granularity of content should be represented, ideally with each medical concept being represented in its own OBX segment. Many of these concepts can be represented as coded entities.

MDM Change Proposal

Problem statement:

1. The MDM (Medical Document Management) message contains the EVN segment that we have found to be non-relevant to a Transcription message. The EVN-2 Recorded date/time is a required field defined as: “Most systems will default to the system date/time when the transaction was entered, but they should also permit an override.” This would appear to be redundant with TXA-7 Transcription date/time that is defined as: “This field contains the date and time the input was actually transcribed”.

It would also appear to be redundant with the TXA-6 Origination date/time that is defined as: “ This field contains the date and time the document was created (i.e., dictated, recorded, etc.)”. Our users are balking at having to populate the field; some have simply changed its optionality to optional in their specs.

2. The MDM messages containing content do not have a NTE segment. Consequently there is no place to transmit notes.

3. The new MDM messages as described in the May minutes from Cleveland are missing the message structure component; some show the wrong trigger; some show the wrong text for the name.

4. Event T12 was missing its ACK in the minutes.

5. There is no event T16 corresponding to an enhanced T06 in the minutes.

proposed solution

1. Delete the EVN segment from the proposed new trigger events: T12, T14, T18, and T20.

2. Add a NTE segment to the MDM messages containing content.

3. Add the message structure to the new messages; correct any trigger and name errors.

4. Display ACK for the T12.

5. Add event T16

1 TRIGGER EVENTS AND MESSAGE DEFINITIONS

1 MDM/ACK-original document notification and enhanced content (event T12)

This is a notification of the creation of a document with ordering context, and the accompanying content.

When this trigger event is used the TXA-14 & TXA-15 fields should not be valued.

Scenario A: Dictation is transcribed and the chart tracking system is notified that the document exists and requires authentication. The content of the document is transmitted along with the notification.

Scenario B: A provider orders a series of three X-rays. The radiologist’s dictation is transcribed in a single document, which covers all three orders. Multiple placer numbers are used to identify each of the orders within the single document message. The notification and document content are transmitted.

|MDM^T12^MDM_T12 |Original Document Notification & Enhanced Content |Chapter |

|MSH |Message Header |2 |

|EVN |Event Type |3 |

|PID |Patient Identification |3 |

|PV1 |Patient Visit |3 |

|TXA |Document Notification |9 |

|[{ORC |Common order segment |4 |

| OBR}] |Observation request segment |4 |

|{OBX} |Observation/Result segment (one or more required) |7 |

| {[NTE]} |Notes and comments |2 |

|ACK^T12^ACK |General Acknowledgment |Chapter |

|MSH |Message Header |2 |

|MSA |Message Acknowledgment |2 |

|[ERR] |Error |2 |

2 MDM/ACK - document status change notification and enhanced content (event T14)

This is a notification of a change in a status of a document with the accompanying content. It should be used for the communication of documents that respond to an order and in the case of Radiology or surgical pathology reports that originated out of an order for these services contained in the report

Scenario: A document is authenticated. Notification is sent to the chart tracking system and is used to update the document status from pre-authenticated to authenticated or legally authenticated. The document content is also transmitted.

|MDM^T14^MDM_T12 |Document Status Change Notification & Enhanced Content |Chapter |

|MSH |Message Header |2 |

|EVN |Event Type |3 |

|PID |Patient Identification |3 |

|PV1 |Patient Visit |3 |

|TXA |Document Notification |9 |

|[{ORC |Common order segment |4 |

| OBR}] |Observation request segment |4 |

|{OBX} |Observation/Result segment (one or more required) |7 |

| {[NTE]} |Notes and comments |2 |

|ACK^T14^ACK |General Acknowledgment |Chapter |

|MSH |Message Header |2 |

|MSA |Message Acknowledgment |2 |

|[ERR] |Error |2 |

3 MDM/ACK - document addendum notification and enhanced content (event T16)

This is a notification of an addendum to a document with the accompanying content.

Scenario: Author dictates additional information as an addendum to a previously transcribed document. A new document is transcribed. This addendum has its own new unique document ID that is linked to the original document via the parent ID. Addendum document notification is transmitted, along with the document content. This creates a composite document.

|MDM^T16^MDM_T12 |Document Addendum Notification & Enhanced Content |Chapter |

|MSH |Message Header |2 |

|EVN |Event Type |3 |

|PID |Patient Identification |3 |

|PV1 |Patient Visit |3 |

|TXA |Document Notification |9 |

|[{ORC |Common order segment |4 |

| OBR}] |Observation request segment |4 |

|{OBX} |Observation/Result segment (one or more required) |7 |

| {[NTE]} |Notes and comments |2 |

|ACK^T16^ACK |General Acknowledgment |Chapter |

|MSH |Message Header |2 |

|MSA |Message Acknowledgment |2 |

|[ERR] |Error |2 |

4 MDM/ACK - document edit notification and enhanced content (event T18)

Note: The only valid use of this trigger event is for documents whose availability status is "Unavailable," i.e., the document has not been made available for patient care.

This is a notification of an edit to a document with the accompanying content.

Scenario: Errors, which need to be corrected, are discovered in a document. The original document is edited, and an edit notification and document content are sent.

|MDM^T08T18^MDM_T12 |Document Edit Notification & Enhanced Content |Chapter |

|MSH |Message Header |2 |

|EVN |Event Type |3 |

|PID |Patient Identification |3 |

|PV1 |Patient Visit |3 |

|TXA |Document Notification |9 |

|[{ORC |Common order segment |4 |

| OBR}] |Observation request segment |4 |

|{OBX} |Observation/Result segment (one or more required) |7 |

| {[NTE]} |Notes and comments |2 |

|ACK^T08T18^ACK |General Acknowledgment |Chapter |

|MSH |Message Header |2 |

|MSA |Message Acknowledgment |2 |

|[ERR] |Error |2 |

5 MDM/ACK - document replacement notification and enhanced content (event T20)

Scenario: Errors discovered in a document are corrected. The original document is replaced with the revised document. The replacement document has its own new unique document ID that is linked to the original document via the parent ID. The availability status of the original document is changed to “Obsolete” but the original document should be retained in the system for historical reference. Document replacement notification and document content are sent.

|MDM^T10T20^MDM_T12 |Document Replacement Notification & Enhanced Content |Chapter |

|MSH |Message Header |2 |

|EVN |Event Type |3 |

|PID |Patient Identification |3 |

|PV1 |Patient Visit |3 |

|TXA |Document Notification |9 |

|[{ORC |Common order segment |4 |

| OBR}] |Observation request segment |4 |

|{OBX} |Observation/Result segment (one or more required) |7 |

| {[NTE]} |Notes and comments |2 |

|ACK^T10T20^ACK |General Acknowledgment |Chapter |

|MSH |Message Header |2 |

|MSA |Message Acknowledgment |2 |

|[ERR] |Error |2 |

|BALLOT: The MR TC agrees to the proposed changes to chapter 9 contingent upon the approval of Orders and Observations TC. |

|Unanimous |

|BALLOT: For T12-T20, eliminate all EVN segments in the message. This differs from other triggers in that it does not contain an EVN|

|segment. An OBR was previously added. To qualify the ORC, the existence of an appropriate use case must be provided by September |

|21, 2000 and approved by the chairs |

|Unanimous |

There was a discussion as to whether or not to add the OBR to the existing triggering events in the correct places without violating backward compatibility. J. Larson will check with CQ. The ORC/OBR placements must follow the TXA and precede all the OBX segments.

|BALLOT: To rescind previous commitment from May 2000 meeting to create new trigger events that exclusively remove the event |

|segment. |

|Unanimous |

|BALLOT: We agree to add new triggers if we are not permitted to add the ORC/OBR segments immediately following the TXA segment . |

|Unanimous |

Agenda for the HL-7 Meeting in Orlando, FL, January 8-12, 2001

Tuesday a.m.

• General discussion and work on Version 2.X issues. Work to gain consensus as to the proper use of Medical Document Management (MDM) vs. Order Results Update (ORU) for transcribed results. Advance work on new trigger events to address results reporting.

Tuesday p.m.

• Working jointly with the Scheduling and Logistics Technical Committee continue developmental work on the Scheduling Context Trigger Events, the Interaction Diagram, use case studies, as well as agreed upon terminology and definitions.

Wednesday a.m.

• Working jointly with the Scheduling and Logistics Technical Committee continue developmental work on the Scheduling Context Trigger Events, the Interaction Diagram, use case studies, as well as agreed upon terminology and definitions.

Wednesday p.m.

• Additional data modeling and RIM harmonization issue review.

................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download