Medical Record Technical Committee Meeting
San Diego, CA
25 –26 January 2000
Attendees:
Tuesday: Mike Ball, Art Bechtel, Jacob Stern, Wayne Tracy, Harry Rhodes, Anne Shanney, Robert Martin, Rory O’Connor, Thanh-Thien Nguyen, Ming Rutar
Wednesday Morning JWG with Scheduling/Logistics TC: Mike Ball, Wayne Tracy, Harry Rhodes, Irma Jongeneel, Art Bechtel, Anita Benson, David Means, Joseph Baptist, Robin Zimmerman, Carbs Sanroman, David Rowed, Klaus Veil, John Hornsey
Wednesday Afternoon JWG with XML TC: It was decided to have the XML TC keep minutes. Harry Rhodes, Debbie Stillman, Mike Ball, Bob Anders, Tom Lincoln, Kelly Nebours, Jeremy Smith, Dave Feinburg, Eileen Koski, Ron DiMireli, Bob Moe, Rachael Sokolowski, Paul Biron, Wayne Tracy, Sandy Boyer, Anne Shanney, Craig Luce, Calvin Beebe, Andrew Hinchley, Gerard Freriks, Leo Fogarty, Tony Seeger, Ken Rubin, Joe Foster, John Leslie, Bill Drummond, Carl Adler, Art Bechthel
Highlights:
- Reviewed current state of Medical Consents messaging model. Action taken to advance development of Medical Consents messaging working jointing with Orders/Observations Technical Committee.
- Working jointly with the Scheduling and Logistics Technical Committee began modeling, scenarios, and survey work on the Chart Reservation and Relocation messaging.
- Working jointly with the XML Technical Committee the Medical Record Technical Committee took significant steps to resolve PRA ballot issues. With progress toward solutions on the following issues: Use of document availability status, use of Chapter 9 messaging guidelines, issues surrounding the imbedding of non-XML data in the internal document, and format for assigning the unique document ID.
Tuesday Morning:
Wayne welcomed committee and introductions were made. The minutes were reviewed and approved.
Wayne Conducted a Discussion of the vote from last meeting to take the suggestion to make a change to the document version identification standard from V2.3.1 to the RIM Harmonization Committee. The vote was to change the standard by requiring the flagging each new version of a base document as such. The original document Identification the base document number of document will remain the same. The version number and the date would change with every revision/amendment. Adding a version number to the original document number. This vote was sent through the XML SIG to the RIM Harmonization Committee, nothing has been heard on further action.
It was noted and discussed that Fred Behlen, Co-chair of the Image Management SIG has negatively balloted the PRA ballot objecting to the version ID methodology and would like the methodology changed to allow the each document to be updated and issued a new independent unique document ID. Discussion of the fact that a diagnostic image number can be unique each time a diagnostic image is reviewed and interpreted; however because the Medical record is a legal document any content changes need to be tracked back to the original. Also discussed was the fact that allowing for multiple simultaneous changes to a medical record document would cause integrity issues. There can be only one legal medical record in the repository and changes to the document must be controlled. Random changes to the record would create a legal risk. A discussion of situations where two different Radiologists give two different opinions and how those opposing opinions would presented in a document; as two documents or an addendum to an original document. Consensus was reached that the MRC would support the compound document theory where two independent addenda would be created. Each document would be linked back to the base study which protects the integrity of the original document, and allows each of the three documents to progress though additional corrects individually while preserving a linkage that allows the proper association to the latest version of each.
Wayne led a discussion of a proposed action item. Is there a need to consider putting another field in the header named Original Indicator; the two values being Original or Replacement.
Example of the proposed header:
Document ID 4441, version ID 1, Date Stamp 20000125,
Document Availability Status: OB (AV, CA OB, or UN from Table 0273 in
Chapter 9) Original ID original
Proposed header content In the new version or the document:
Document ID 4441, version ID 2, Date Stamp 20000126,
Document Availability Status: change the new version to AV and the original to OB. (table 0273 from chapter 9) Original ID replacement
Only one trigger event to change new version to available and original to obsolete.
In every new instance a message would be sent indicating that previous document is now obsolete.
The sender would be the responsible for initiating the change and not the receiver to ensure a control exists over changes. This would ensure that the business record rule of the Rules of Evidence is followed. Allowing for and audit trail of changes and the responsible party.
The committee identified a need for a statement in the chapter that the legal integrity of the chart document should be protected and that only one valid version of a document be available. The available version will be marked as available the previous versions must then be marked as obsolete. The original document number will be retained. The sender will hold responsibility for making the change and not the receiver.
Discussion of a proposal to carry a motion to the JWG XML /MRC meeting on January 26th. Calling for the establishment of an Original ID field that would indicate either original or replacement, and an additional field flagging the document availability status using the model found in chapter 9 table 0273.
Ballot - Motionmade to add a data attribute to the document header object in the RIM to contain a field called Original Document Indicator. (original, replacement)4 – in favor
2 - opposed
1 - abstained
Ballot - Motion made for the establishment of a compound trigger event that would generate two messages, the first for the replacement document and second for a header change to the antecedent document to make it obsolete.
7– In Favor
0 – opposed
0 - abstained
Discussion of the XML PRA Ballot; in the ballot scope statement and the introduction of the “Further Refinements to the Clinical Document Header Class” document the recommend is made that once the document is legally authenticated it will be immutable
Ballot- Motion made to change the recommendation made in the Scope statement of the PRA Ballot and the “Further Refinements to the Clinical Document Header Class” document in the introduction recommending that once the document is legally authenticated it cannot be altered, that it is immutable. A mechanism should be available to allow the document to be changed.7 – In Favor
0 - Opposed
0 - Abstained
Following the break, there was a discussion of what constitutes an authenticated document. Consensus was gained that an authenticated document is one that has been reviewed and approved. That the concept of non-repudiation is different for healthcare documents because unlike other legal documents a certain percentage of authenticated medical records are corrected. This modification of authenticated documents is unique to the healthcare environment, and differs from the concept of non-repudiation in banking and other business environments.
Tuesday Afternoon:
Following the lunch break, There was a discussion of the status of the consents messaging. The prepared segments: CFM – Pre-defined Consent Form (Repository) Segment, MPC- Medical Procedure specific Consent Segment, PPS –Person Signature Segment, ROI- Release of Information Segment, and PAS – Person Authorization Segment were reviewed.
Historically the work on the consents model has been advanced by the Medical Record TC, the momentum on the development of the model in Medical Records TC has stalled.
In response to the stalled interest in development of the model, Wayne proposed the option to forwarding the data definitions for consent to the Order and Observations Technical Committee.
Discussion of the future direction of the Medical Record TC on development of the medical consents model. There was a committee discussion of a proposal that both the Order and Results TC and Medical Record TC have a shared interest in the class.
Many of committee members were new to the committee and asked to be updated on the Consents messaging model. In order to update the MRC on the status of the medical consents messaging model. After a brief update, Wayne opened a discussion of the ROI – release of information segment, in particular the “expiration of release date” and the “restriction of use description” optional fields. The addition of these two fields was found to be appropriate and in line with the recommendations found in the Health & Human Services security proposed rules. There was also a review of the fields “Individual Release Recipient Name”, “Individual Recipient Address”, and “Individual Release Phone” and the corresponding “organizational release” optional fields. It was noted that the HHS proposed rules recommend that the provider track all record releases.
There was also a discussion of the tracking of the existence of “level of trust agreements” and the placement of an optional field in the HL-7 messaging model. The presence of “level of trust agreement” may need to be tracked as part of HIPAA compliance.
Discussion of a proposal to form a SIG under Order and Results TC to advance the work on the Consents.
Ballot- Motion was made to endorse that the MRC present an incomplete contribution of the Consents 1C spread sheet for inclusion in the consent object being developed in the Order and Results TC. And to collaborate with the Order and Results TC on its’ refinement5 – in Favor
0 – opposed
1 – abstained
After the break, there was a discussion of the inability to amend a legally authenticated in the recommendations made in the PRA ballot. The consensus of the MRC was that the ability to amend a legally authenticated must be present.
There was also a discussion of the inability to imbed non-XML data in the internal document. There is an issue with the fact that this release of the PRA defines links to non-XML data that are integral to the document, but stored separately. There was a discussion of the incompleteness of the PRA architecture, It was noted that as it currently exists the content is consistent with a framework and needs further refinement. XML currently cannot imbed a non-text data, a solution is being advanced in the W3C packet workgroup. It was suggested that a statement be added that once the solution is available it will be added.
The remainder of the negative ballot comments were reviewed and discussed.
The committee adjourned for the day at 5 PM.
Wednesday Morning:
The MRC and Scheduling/Logistics TC’s have come together to collaborate on the development of Chart Tracking and Appointments survey messaging. One of the JWG’s goals will be to survey current chart tracking process and development scenarios.
Harry Rhodes distributed a Chart Location and Tracking Model & a Chart Location and Tracking Model Necessary Data Fields that he complied from AHIMA library resources. He also distributed Policies and Procedures contributed by Northwestern Memorial Hospital and Illinois Masonic Medical Center. These are both Medsoft applications, prior to the meeting Harry did contact the Chicago Medsoft representatives who agreed to allow the committee to use the Policies and Procedures for the committees’ work.
Wayne asked for some from someone from either of the two groups to volunteer to take ownership for progressing the work in a version 2.X style or Version 3 style, ultimately producing an HMD. Wayne proposed that the MRC progress content in chart tracking requests and queries in Version 2.X context, while in parallel the Scheduling/Logistics TC would advance the modeling work in Version 3. And when Scheduling/Logistics is ready to create a new RIM Class MRC will be registered as the interest committee. Also it was suggested that all the work would be would be advanced in joint sessions. There was agreement around the room to follow Wayne’s proposal.
It was agreed to develop trigger events, and a series of segments and data fields that would be used both in a query request, unsolicited requests for chart location, and notifications that chart location would be changed. Any other system could query the Integrated or central system as to the location of a record.
JWG goal: to develop a model for the chart tracking process. The messages are intended to be use for electronic, paper, and “hybrid” medical records. In consideration of our international members the chart will also referred to as a “dossier”.
Wayne led a discussion of the development of scheduling context trigger events, segments, and data fields.
Scheduling Context Trigger Events development:
CT01 – Chart (dossier)Transfer Request, unsolicited, request to move the chart as a result of a appointment (is there a record? Who, Where, When?)
CT02 – Chart (dossier)Transfer Request Acknowledgement a response, (response Yes or No)
CT03 – Chart (dossier)Transfer Request a response, (Completed Acknowledgement)
CT04 – Chart (dossier) Transfer Request Completion a response
Departing
Arriving
CT05 – Chart (dossier) Transfer Request Modification/Rescheduling
Query
CT20 Chart (dossier) Location Request unsolicited (tell me where it is?) precursor to a Chart (dossier) Transfer Request
CT21 Chart (dossier) Components/instance(s)
The idea was presented that an appointment request would be a compound trigger event and it would spawn more than one action i.e. chart location and appointment. There was a discussion of whether it is possible for a single trigger event to spawn multiple messages. It will need to determined what is possible from the perspective of mapping messages. There appears to be a good deal of functional overlap.
Joseph Baptist presented a model example of a Dutch chart (dossier) tracking model in order to demonstrate differences in the Dutch systems.
- After four years records (dossier) in archives are put on microfilm so records (dossier) can exist in paper and microfilm.
- There exists one central inpatient chart (dossier) and charts for every individual clinic.
- One patient number exists for the entire system assigned by the hospital. There is also a notation made following the unique number for each clinical specialty.
- Clinic providers that want information other than what’s in the individual clinic record can go to an online resource connected to lab, radiology or other ancillary services.
- Requests for information are sent between clinical providers and copies of the records and correspondence exists in multiple clinic charts. Information from other clinics is put in each individual clinic chart.
- In the Netherlands the charts are held (owned) by the individual clinicians in their office files.
After the break, the committee as joined by the Australian HL-7 community health SIG members. Many of the ideas presented in the discussion represent chart management systems in Australia. A discussion of Chart Tracking Messaging was begun
What addition information would the receiver what to know beyond the chart location? Information such as insurance, billing, utilization review.
Wayne led a discussion of the development of the chart (dossier) tracking message.
Chart Tracking Message development
MSH
{PID
[{PV1 - optional
New Segment - - service event DT range, Volume, or chart subset define, Service Dept. encounter types
New Segment – Transfer to location, return location (home), home location or owner of the chart, needed by, requesting party, location, service et al, person,
Chart Status: Electronic, Paper, Both (hybrid), destroyed, packaging*, beginning service date, ending service date, medical specialty
Chart Movement Depart
Chart Movement Arrival
* “Packaging” defined this is the physical container or media for the record (paper, electronic, film, CD ROM)
The PID would request the whole longitudinal record. However the encounter record is sometimes required and the PV1 message segment would be needed. Another possible message would be to request charts across date ranges. If the date ranges crossed volumes of charts the requester & sender would determine which volumes need to be released. The request could also be to request the current active volume. In addition to the chart there could also be a “bag” for films.
From a Dutch perspective it is alright to have an a PID and PV1 for an encounter but it may also be necessary to have an episode record
The PID would identify the longitudinal record, however the PV1 would identify individual encounters and episodes.
We need to consider that a chart query is for the whole longitudinal record. But there needs to be the ability to perform a chart query at the encounter or episode level.
There was a suggestion to have PV1 become optional for encounters/episodes and to create a New Segment for the chart subset definitions.
The chart subsets definitions identify the “parts” of the chart but the “parts” of the chart could in reality be included in a larger chart. In responding to a date range request the sender would send all volumes of charts that are included in the requested date range.