HL-7 Medical Record/Information Management
Technical Committee Meeting
Cleveland, OH
May 23 &24, 2000
Attendees:
Tuesday Morning: Mike Ball, Harry Rhodes, Wayne Tracy, Eleanor Joseph, Karen Sieber, Rob Drewniak, Patrick Dolen, Wen-Shan Jian, Thanh-Thien Nguyen
Tuesday Afternoon JWG with Scheduling/Logistics TC: Harry Rhodes, Wayne Tracy, Mike Ball, Eleanor Joseph, Karen Sieber, Thanh-Thien Nguyen, Patrick Dolen, Rob Drewniak, John Hornsey, Edna Curtin, Jane Foard, Mickie Erickson, Yu-Chaun Li, Ron Gans, Tom de Jong, Irma Jangeneel, Anita Benson, Nancy Wilson-Ramon
Wednesday Morning JWG with Scheduling/Logistics TC: Harry Rhodes, Wayne Tracy, Mike Ball, Anita Benson, Thanh-Thien Nguyen, Rob Drewniak, John Hornsey, Tom de Jong, Irma Jangeneel, Carlos Sanroman, Greg Thomas, Tina Buckeye, Bernd Blobel
Wednesday Afternoon JWG with XML and Control Query: Attendance list and minutes were taken by XML TC, see XML TC Minutes
Highlights:
- Review of Patient Record Architecture Framework (PRAF) enhancements.
- Voted to revise Medical Record/Information Management Technical Committee title, mission statement, and scope statement to reflect changes in healthcare environment.
- Work toward development of new trigger events that would allow linkage of transcribed results back to the original order and documentation.
- Working jointly with the Scheduling and Logistics Technical Committee continued developmental work on the Scheduling Context Trigger Events, the Interaction Diagram, use case studies, as well as agreed upon terminology and definitions.
- Working jointly with XML TC and Control Query TC discussed status of RIM header document classifications. There was a discussion of the need for one vs. two headers in the XML document. The functionality of the header documentation classes was discussed. Discussion regarding the use of document date time stamps.
Tuesday: Wayne welcomed the committee and intrductions were made. The minutes were reviewed and approved.
Wayne opened a discussion of the meeting agenda. A suggestion was made to discuss recent changes in the Health Information environment. And how current environment changes will impact the development of the Patient Record Architecture (PRA). A status report on the progress of the consents messaging work in Order and Results TC will be given. A review of PRAF enchancements will also be performed. The committee concurred on the agenda changes.
Wayne opened a dicussion of the environmental shift from LAN’s and T1 telephones to use of the Web to connect disparate information management systems. There was a review of the HIPAA Transaction Standards and the use of X12-N and HL-7 standards for claims attachments. The government is holding back the release of the claims attachment standards pending the establishment of privacy and confidentiality standards.
There was a discussion of security and privacy advances in PKI and SSL. There was a discussion of a recent online breach involving a new product demo by Eagle Innovations. Eagle Inovations wishing to demo their new product R4D a online results reporting product for physicians, obtained without permission 14 medical records from a client Providence Health Care, and used the records the records in the demo. The breach was reported to the FBI and the healthcare provider and online company both face charges under HIPAA regulations.
There was a discussion of a recent Ohio court case Bittle Vs. Warren Hospital. In this case the hospital contracted without patient consent to send medial records to attorneys for use in Utilization Review. The patients won the case. As a result hospitals in Ohio must inform patients of all record access that will occur, upon admission to the facility.
Both of the above cases test the “business partners chain of trust” prinicple. In both of the cases the healthcare provider was held accountable for the actions of the business partners. These events are important to the TC in that they have an impact on the TC’s mission and scope.
The work done toward the Patient Record Architecture Framework (PRAF) was discussed. There was discussion of the methodology proposed in the PRAF to admend documents, flag document version number, i.e. original and updates, and mark documents as obsolete should the documnent be admended. The MR/IM TC wants methodology in place to allow for and track amendments. There will be a joint work group meeting between Medical Record/Information Management TC and the XML TC on Wednesday afternoon to discuss these issues. For the benefit of new members the documentation management guidelines in Chapter 9 of HL-7 Version 2.3 were reviewed and discussed.
Mike Ball opened a discussion of the current wording of the Medical Record/Information Management TC Mission Statement. Mike felt that the wording “information management” was inappropriate and should be updated to “health information management” The committee agreed to visit the current wording of the mission statement.
The proposed new wording follows:
Mission: The goal of the Medical Record/Health Information Management Technical Committee is to define transactions that support the functional messaging needs of the health information management/medical records department.
The list of participants was removed from the mission statement and placed in the body of the committee membership. (see wording below)
Committee Members: The committee is comprised of individuals representing vendors of information systems (computer based systems), health information management professionals, and other stakeholders, including other allied professionals, and physicians.
The scope statement was also reviewed and no changes were made in the wording of the scope statement other than grammatical.
Ballot: Motion was made to change the wording of the MR/IM TC Mission Statement to reflect the change in emphasis on health information management.6 - in Favor
1 - opposed
0 - abstained
Ballot: Motion to change the current title of the Technical Committee to Medical Record/Health Information Management.
4 – in Favor
3 - opposed
1 - abstained
Thanh-Thien Nguyen led a discussion of problems that Kaiser Permanente – Hawaii has experienced with current triggering events and segments found in the MDM message when sending unsolicted transcribed results. The recipient does not have access to the original order that would allow them to link transcribed results back to the order.. The committee concurred that they would set aside 30 minutes following the lunch break to address these issues.
Tuesday afternoon:
In the Medical Records/Information Management chapter 9, Section 9.4.2 MDM/ACK – Original document notification and content (event T02). Change T02 trigger event following the TXA document notification. Creating a new trigger event T02A to add a repeating optional ORC. Creating a informational non-normative state. This will create six new trigger events that show the segments.
9.4.4 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 / Document Status Change Notification & Content / ChapterMSH / Message Header / 2
EVN / Event Type / 3
PID / Patient Identification / 3
PV1 / Patient Visit / 3
TXA
[{ORC
OBR}] / Document Notification
Order Control
Order Detail / 9
{OBX} / Observation/Result (one or more required) / 7
ACK^T14 / General Acknowledgment / Chapter
MSH / Message Header / 2
MSA / Message Acknowledgment / 2
[ERR] / Error / 2
9.4.8MDM/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^T08 / Document Edit Notification & Content / ChapterMSH / Message Header / 2
EVN / Event Type / 3
PID / Patient Identification / 3
PV1 / Patient Visit / 3
TXA / Document Notification / 9
[{ORC
OBR}]
{OBX} / Order Control
Order Detail
Observation/Result (one or more required) / 7
ACK^T08 / General Acknowledgment / Chapter
MSH / Message Header / 2
MSA / Message Acknowledgment / 2
[ERR] / Error / 2
9.4.10MDM/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^T10 / Document Replacement Notification & Content / ChapterMSH / Message Header / 2
EVN / Event Type / 3
PID / Patient Identification / 3
PV1 / Patient Visit / 3
TXA / Document Notification / 9
[{ORC
OBR}]
{OBX} / Order Control
Order Detail
Observation/Result (one or more required) / 7
ACK^T10 / General Acknowledgment / Chapter
MSH / Message Header / 2
MSA / Message Acknowledgment / 2
[ERR] / Error / 2
9.4.12MDM/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 / Original Document Notification & Enhanced Content / ChapterMSH / Message Header / 2
EVN / Event Type / 3
PID / Patient Identification / 3
PV1 / Patient Visit / 3
TXA / Document Notification / 9
[{ORC
OBR}]
{OBX} / Order Control
Order Detail
Observation/Result (one or more required) / 7
Figure 9-1. TXA attributes
SEQ / LEN / DT / OPT / RP/# / TBL# / ITEM# / ELEMENT NAME1 / 4 / SI / R / 00914 / Set ID- TXA
2 / 30 / IS / R / 0270 / 00915 / Document Type
3 / 2 / ID / C / 0191 / 00916 / Document Content Presentation
4 / 26 / TS / O / 00917 / Activity Date/Time
5 / 60 / XCN / C / Y / 00918 / Primary Activity Provider Code/Name
6 / 26 / TS / O / 00919 / Origination Date/Time
7 / 26 / TS / C / 00920 / Transcription Date/Time
8 / 26 / TS / O / Y / 00921 / Edit Date/Time
9 / 60 / XCN / O / Y / 00922 / Originator Code/Name
10 / 60 / XCN / O / Y / 00923 / Assigned Document Authenticator
11 / 48 / XCN / C / Y / 00924 / Transcriptionist Code/Name
12 / 30 / EI / R / 00925 / Unique document Instance ID
13 / 30 / EI / C / 00926 / Parent unique document instance ID
14 / 22 / EI / O / Y / 00216 / Placer Order Number
15 / 22 / EI / O / 00217 / Filler Order Number
16 / 30 / ST / O / 00927 / Unique Document File Name
17 / 2 / ID / R / 0271 / 00928 / Document Completion Status
18 / 2 / ID / O / 0272 / 00929 / Document Confidentiality Status
19 / 2 / ID / O / 0273 / 00930 / Document Availability Status
20 / 2 / ID / O / 0275 / 00932 / Document Storage Status
21 / 30 / ST / C / 00933 / Document Change Reason
22 / 60 / PPN / C / Y / 00934 / Authentication Person, Time Stamp
23 / 60 / XCN / O / Y / 00935 / Distributed Copies (Code and Name of Recipients)
Straw Ballot: Motion made to address these changes to the MDM/ACK – Original document notification and content trigger events and message definitions at our next meeting with the intent to include the changes in the next HL-7 version ballot.
7 – approved
0 – opposed
0 - abstained
Following the ballot the Joint Work Group Meeting of Medical Records/Information Management TC and the Scheduling/Logistics TC was called to order. The minutes of the previous meeting were read.
There was a discussion of the goals of the JWG. It was agreed to use modeling techniques to advance work. Work will be advanced in both version 2 and version 3. New triggering events will need to be created in scheduling. There could possibly be two requests one making the request and another confirming that the request was responded to.
Ballot: The scheduling and Logistics TC and Medical Record/Information Management TC have decided to do the work jointing in development of chart reservation, tracking, and relocation messaging. The committees will utilize Version 3 methodology for use cases and interaction diagrams. With regard to documentation the MR/IM TC will advance the work in Version 2.5 messaging. The Sheduling/Logistics TC will update the RIM and advance the work in V 3. Documentation. Scheduling/Logististic will update Chapter 10 to address changes to segments, and create version 3 documentation. The MR/IM TC will update Version 2 documentation changes in chapter 9.14 – in favor
0 – opposed
2 - abstained
The JWG discussed the trigger event spawning multiple messages scenario again. If we need to implement using multiple messages, we will need to ask CQ to consider. On the other hand, the filler application may be able to take and answer the appt request with the Scheduling message and a MR request.
Scheduling Context Trigger Events development:
Changes to trigger events:
Scheduling:
CT01 - Chart (dossier) Transfer Request, unsolicited, request to move the chart. (is there a record? Who, Where, When?)
CT02 - Chart (dossier) Transfer Request Acknowledgement Response (response Yes or No and reason not filled). Responses to CT01, CT03, and CT04.
CT03 – Chart (dossier) Transfer – Transfer request Modification/Rescheduling Message from the originator of a CT01 modify either the location or the required by date/time.
CT04 – Delete/Cancel Chart (doosier) Transfer Request, From the originator of a CT01 or CT03
CT05 – Chart (dossier) Transfer – chart departing
CT06 - Chart (dossier) Transfer Request Modification - chart arriving
CT07 – Chart Home Location Change Notification (Used when a chart is created, possibly destroyed or when the home location is changed.)
Query:
CT20 – Chart (dossier) Current Location Request unsolicited (tell me where it is now)
CT21 – Chart (dossier) Home Location Request
CT22 – Chart (dossier) Components/instance(s)
There was a discussion of whether or not a trigger should be created to indicate records that are unavailable, archived, or destroyed. The WJC concurred not to create a new trigger event, instead use a the CT07 event trigger.
Global issues:
What is the definition of a chart? An enumerated list of the chart components, a logical list, but not a physical list
Requestable Component – There is a need to define the component of the chart that is being requested. i.e. Service event date range, volume, or chart subset, service dept, encounter types.
Redunancies: What is done with redunant record documents.
An issue for future meetings would to describe the compositional structure of the medical record. One key characteristic of the medical record would be the media type
The committee concurred not to create a new trigger event for the requestable component, instead create segments to request optional components of the chart.
Interaction Diagram Development
Wayne led a discussion of the Interaction Diagram Development. Anita Benson utilized the Rational Rose application to map-out the interaction diagram.
The interactions that were diagramed were between the Chart Requestor, Chart Holder,and Interested Party.
The uninformed requestor could send out a TC20 to determine the location of the chart.
The interactions between the Chart Requestor and the Chart Holder are:
CT01, CT02, CT06
OR
CT03, CT02
OR
CT04, CT02
The interactions between the Chart Holder and the Interested Party are:
CT05,
The interactions between the Chart Requestor, Chart Holder, and the Interested Party are:
CT06
OR
CT03, CT02
OR
CT04
The interaction between the Chart Holder and Interested Party are:
CT07
The interaction between the Querying role and the Responder Role:
CT20, CT23
The committee will support a generalized chart information request, that includes, current location, home location, conponent location. CT20, CT21, and CT22 will collapse into CT20.
There was a discussion of what is the definition and role of the “Chart Manager” The simplest interaction and model is the first diagram intrainstitutional interaction model. Where the chart manager addresses the issue of the chart location at the time of transfer knowing where the chart is, they will forward the copy of the tranfer request at the time of transfer, if the location is not theirs. Typically the chart manager is the Med Rec Department. The JWG concurred that the model shall be named the “Central Management Model”
Use Case Scenarios
Anita Benson developed a diagram of chart tracking use case in the Rational Rose application. The committee developed model diagrams for Appointment Requester, Scheduler, Patient, Chart Manager, Care Giver, and Medical Researcher.
Committee concurred that the should invite the new SIG Patient/Provider Messaging Special Interest Group to participate in the Use Case Scenario development.
On Wednesday morning the committee will address segments
Full day of JWG meetings with Scheduling/Logistics, half in the afternoon of the first day and the remainder in the following morning.
Wednesday Morning:
Waynebegan the day by reviewing Tuesday’s progress. The JWG reviewed each CT trigger event that were created previously. It was discovered that a use case conflict exists in the CT05 message. If we have a centralized record management system. The central manager would not be the one to issue this message. The actual chart holder would be different than the central chart manager.
A new role will need to be created for the status of the “Chart Holder”. This individual is not the same as a the “Chart Manager” The “Chart Holder” is the only person that can activate the CT05 request. The “Chart Manager” is a passive role that tracks the the current location of the chart. However, the “Chart Manager” can both be in the active chart holder role or the passive chart tracker role. The “Chart Holder” is in the active role in that this individual actually holds the chart.
A discussion of the need for a “Interested Party” role in the use case. Although, it was the agreement of the TWG that an “Individual Party” may exist in a use case model. It was decided that our goal is to present the simplest chart management model, therefore, it would be better to remove the “Interested Party” from the model.