Medical Record / Information Management
Technical Committee Meeting Minutes
January 26 -27, 1999
Meeting Highlights
1. Joint Working Group session with the SGML SIG was conducted, issues for reconciliation identified, and action items determined for the April meeting. Bob Dolin and Wayne Tracy will serve as liaisons for the SIG and TC.
2. Gary Dickinson of the Accountability and Quality Control SIG requested participation of that SIG in the JWG and will join in the joint session at the next meeting.
3. Initial work was done on Abstract Message Definition for Consent segments
4. European requirements for granular signatures for segments of content within a document was presented. The need for a broader signature component/object was also identified with the stewardship most likely being PA/FM.
Materials distributed:
1. Minutes
2, Consent data element work sheet (Consent1c.xls)
Tuesday, January 26
Attendees:
Rami Kandel, Harry Rhodes, Al Figler, Bernd Blobel, Anne Shanney, Wayne Tracy
MORNING SESSION
The agenda was reviewed and accepted.
Minutes were reviewed, a single amendment proposed, and a vote for acceptance of the amended minutes.
For: 5
Against: 0
Abstaining: 0
Informal survey of TXA segments in use
SoftMed’s ChartLink product is engaged in joint development projects with
McKessonHBOC
Compucare
IDX Systems
Document index interfaces for scanned data using TXA
Following the review of the minutes, a review of the Medical Record Technical Committee scope and mission statement was conducted, followed by a discussion of on-going related work in the HL7 community. The PAFM technical committee has on-going work in defining abstracting segments, and the HIPAA development of a claims attachment was mentioned.
North American Association of Cancer Registries (NAACCR) is developing an HL7 Implementation Guide for cancer registry information.
RIM harmonization meeting report from Wayne: While there were no distinct changes to our chapter directly, some changes were made to objects, such as person, used by Medical Record messaging. None were considered substantive for this committee, although the committee was urged to review the work on the HL7 website.
Review of consents work was conducted. Review of data elements. Requested group review data types. Work then turned to constructing a version 2.3 Abstract Message Definition.
PROCEDURE CONSENT NOTIFICATION MESSAGE
MSH
PID
[PV1
CFM Consent Form Repository Segment
MPCMedical Procedure Consent Segment
{PSS}Person Signature Segment
Issue: NOK content belongs in an NK1 segment
A discussion of signature followed.
Signature obtained verification is different from witnessing.
authenticator ^ role ^ timestamp
A Use Case was developed , incorporating the use of DPOAFHCA (Durable Power of Attorney for Health Care Affairs)
USE CASE:
WHOTRIGGERACTION
Clinicianorder/schedule procedurequery for consent form
which requires consent
Clinician clinician receives consentinsert patient/procedure
form (CFM)“specializations/personalizations”
to the form (MPC)
Clinician orConsent ready for Signature present for Pt Signature
surrogate
Patient or Consent presented1. Pt. signs
surrogate2. Surrogate signs
DPOAFHCA, parent, parent, NOK,
legal guardian, “the State” MDs
WitnessObserve signed consentH1 or H2 +3
Concern was expressed about the hierarchical relationship of the CFM segment as prior to the MPC. The issue was clarified as understanding the relationship of patient-specific specialized information was a relationship to the patient, not to the consent form as stored prior to patient usage.
We are not specifying the granularity of the consent form. The consent form may be as general as an Omnibus Surgical Consent form the other end of he spectrum is as granular as a Laparoscopic hysterectomy surgical consent form, which contains risks specific t o the introduction of the Trocar and risks of laser cauterization.
The committee the reviewed the request to publish excerpts of the HL7 Standard as part of an ASTM document addressing the interfacing of data from a digital dictating system.
E31.xxx Proposed Standard (Revised)
The document was reviewed, and specific concern was expressed in the ASTM representation of the HL7 Standard 9 TXA segment. TXA, 3 is specifically removed as a cited HL7 field, and the content which belongs in TXA,3 is placed into a Z-segment, ZBO
Vote to accept ASTM request to publish a representation of the TXA segment.
For: 0
Against: 4
Abstaining: 0
The motion failed, with a recommendation being made in the committee that we recommend to the Technical Steering Committee that an invitation be extended to representatives of the ASTM E31 committee to discuss their intentions with this technical committee.
The committee then returned to working on the consent data elements. Concern was expressed that a different data type for the various authenticator elements would provide a more organized structure. It was agreed that review of the data types would occur as out-of-cycle work.
Discussion was then held of joint working group meeting with SGML/XML working group on Wednesday. There is concern that the PRA message created by the SGML does not sufficiently reference the content of the HL7 standard for document headers.
There was concern expressed for multiple groups within the HL7 membership doing the same work. Initial request had been to establish SGML/XML SIG with a relationship to the Medical Record committee. SGML/XML was established as a independent SIG, and has proceeded to develop its document header in parallel with the TC’s document header.
WEDNESDAY, January 27
JOINT MEETING GROUP WITH THE SGML/XML SIG
In attendance: Wayne Tracy, Anne Shanney, Harry Rhodes, Wyndham Gary, David Puccirillo, Steve Kordik, Rob Eder, Mike Cassidy, Tom Lincoln, Stewart Haight, Sandy Boyer, Robert Knight, John Majerus, David L. Riley, Steven Disted, Tim Ticknell, Jimmy Lowery, Ann Tsao, Fran Turisco, Joe Kessel, Dennis Jeremias, Carla Robelli, Jan Root, Gary Dickinson, Rami Kandel, Mike Ostler, Angelo Rossi Mori, Rachael Sokolowski, John Mattison, Bob Dolin, Liora Alschuler, Bernd Blobel, Gerald E. Kirchner
Wayne proposed that the agenda be for each group to introduce its work, to further understanding of the work of each group. Rachel Sokolowski agreed to be spokesperson for SGML/XML, and the agenda was approved.
Wayne then introduced the history of the Medical Record Technical Committee since its founding in 1988. He reviewed the domain of MR, focusing on the subject of committee work. He described a medical record document as an organized encapsulation of a discrete collection of data. In the course of its work, the committee’s review of medical practice showed a subset of documents which are about ordered items, but the larger number of documents were unrelated to any order. The Chapter was formed to address messaging of these documents which are unrelated to orders by means of the creation of a header to be used for a document.
Wayne reviewed the statement in Chapter 9.2 regarding the committee’s position on the content of the document for which the header was developed. Briefly, it was considered that the TC had neither moral nor clinical competence to develop the content of the medical record documents: that work, in the view of the Medical Record Technical Committee, is to be left to clinical experts. The Document Header Segment and Document Trigger Events were then discussed.
Wayne reviewed the Trigger Events which are related to document security considerations; specifically, security, confidentiality, and availability status designations. These were developed to permit the flexibility required by local business rules across the industry.
We discussed the Document Type user defined table 0270, as Document Type has been a large part of the SGML/XML SIG’s discussion. The Standard table was developed to be extensible, never intending to be an exhaustive list of documents. Indeed, it was considered that it could not be in a dynamic industry.
Table 0191, Data Types, was reviewed, as intended as gross descriptors of data media, and the table’s extensibility was discussed. Mention was made of the agreement that the Vocabulary Committee will coordinate and maintain tables, which will allow for table updates to be published more frequently than the publication of the Standard itself.
Succession document (Versioning) was discussed, along with the legal issue involved with the removal of one report when it is replaced by another. It was stated that parent-child relationships were incorporated to manage such a succession of documents. Addenda were then discussed as different from succession: e.g., an initial report on a pathology specimen may be followed with a report on an electronmicroscopy (EM) examination of the specimen, the report of which is addended to the original without replacing the original.
Review was conducted of completion, confidentiality, availability, and storage status.
John Mattison responded that the question was not whether we should collaborate, but how.
John then presented a list of outstanding issues, and expressed concern for how to proceed. It was suggested that a working document be prepared out of cycle, to be presented at our April JWG meeting .
Current work of the SGML/XML SIG includes:
1. Message syntax, which is embraced by Control/Query
2. Coordinated architecture mapped to RIM
3. Coordination of document content with message content
4. Proposed coordination of architecture with Modeling and Methodology TC.
SGML/XML SIG current document issues include:
Succession
Attestation
Lineage
Addenda
Presentation information relative to formats
Compound document, include. compound attestations
Bi-directional succession of documents
Bob Dolin then presented a description of work to date. He described five considerations in development of the SGML/XML SIG PRA header:
1. PRA header is intended as a draft, or exercise in method.
The Standard TXA segment was used as a starting place, but some segments were not included. TXA,14, PLACER ORDER, as an example, partially because it was not understood, partly because the SIG wanted an example
2. Method used to initially develop the PRA included
Review of Chapter 9 Document categories
Creation of SGML SIG categories for harmonization with RIM:
Document
Patient
Event
The SIG plans the development for real, as opposed to an example, PRA.
In its process of reviewing the RIM, followed by developing a MIM, then an HMD and subsequent DTD, the SGML SIG developed ~30 objects not included in RIM
The SIG recognizes that differences in agreement with RIM are to be reconciled with the Object owners, in this case, the Medical Record Technical Committee, ex.: if PRA wants to include “filename” which means something different from TXA, this will be reconciled.
3. SIG discussion of message vs. document
In creating an SGML structure, the SIG distinguished data stored in a document management system versus data stored in a document:
The issue was then raised regarding an organization’s ownership of document availability, which inheres in the PRA object attribute, Availibility_status_cd: available, deleted, obsolete
Originators of documents are stakeholders in its availability status, leading to a concern about separating the content of the document from content of document management.
John stated SIG in 100% agreement with operational issue.
This issue is agreed to be the most urgent for joint discussion.
Clinical _document_header.change_reason_cd given as an example of an element believed missing from the RIM.
4. Attestation vs. authorship
Discussion of US use of “attestation” as description of financial definition, unrelated to authentication .
John agreed that we need a common way of describing activity
Gary Dickinson has requested that the Vocabulary group be included in the discussion. He stated n accountability issue in relation to documents in the delivery of healthcare. Maintaining from point of origin to use the accountability of a document. ACCT group is in process of gathering its requirements, trying to bring in recognized leaders in SOD and industry
Wayne requested a vote from MART and SGML/XML SIG to vote on participation of Accountability. Gary suggested there would be additional future interested parties
For: 19
Against: 0
Abstain: 1
The motion passed.
Discussed was held of the time required for JWG next meeting. We agreed on a full morning session on Wednesday of the April meeting. Three agenda items were agreed upon:
1. incremental SIG documents will be submitted to MRTC
2. resolution of issues re attestation vs. authentication
3. review notion of header vs. headers, with refinement of concepts of document management different from document content
Angelo remarked that the CEN documents are out for comment, with the comment period closing in the first week of March. Wayne remarked that, although individuals will be able to respond in that timeframe, the TC will not be able to respond before the April meeting of the committee membership. Angelo answered that he would be able to take committee response to the CEN meeting in May.
There will be targeted messages interim with posting to a concatenated list from all three groups’ listserver.
It was requested that these documents be largely and formally labeled as DRAFT
The JWG will include Accountability and Quality Assurance SIG, SGML/XML SIG, and Medical Record Technical Committee.
John suggested that we have a brief PRA demo at our next JWG.
Angelo suggested that we may be working with CEN document category taxonomy rather than a lexicon.
Comment was made that if an industry standard such as SNOMED has created a standard for a data type, another SDO should not undertake development of them.
It was not agreed that we are talking about a taxonomy instead of a lexicon, as was proposed by Angelo, rather, this is a point of discussion for our next meeting
It was proposed that Table 0191 values be represented as ED data types, to permit versioning.
5. Expansion of table 0270. Document Types.
Wayne expressed concern that there be a formal way of SIG informing TC of its work. John suggested a formal designated liaison represent SIG. John suggested Bob Dolin serve in that role on an interim basis. Wayne offered to serve as MRTC liaison role.
Wayne requested we start with SIG providing the TC with documentation of incremental content. John suggested that a coalesced list distribution would be more efficient. Agreed that Bob and Wayne would work out the mechanics of the exchange of information.
We adjourned for lunch.
WEDNESDAY AFTERNOON SESSION
Report from TSC meeting regarding resolution of the copyright release request from ASTM. The Board will respond to ASTM.
In a follow-up discussion based upon discussion with Angelo Rossi Mori of the SGML/XML group, it was recognized that the current chapter 9 structure doesn’t support the CEN table of document types. Since CEN document types represent a taxonomy, and the Chapter 9 types do not, it has been proposed that the CE data type be used, which will permit retention of existing as well as referencing an external table. Agreed that we should request that CEN create a table of its values, in order to incorporate a specific reference to it in Chapter 9.
If 2.3.1 will be re-balloted, it is desirable to include this change in 2.3.1. Failing that, it should be included in 2.3.2
Objection was raised, citing that the current local extensibility of the table would be lost by the change to CE, if it were to be an HL7-specified table of values.
The compromise was to specify the default as the HL7 table, but permit local extensions.
Vote was taken on the proposed change.
For: 6
Against: 0
Abstain: 1
The motion passed.
Discussion was conducted of the Social Security Administration need for consent documentation. It was suggested that this may fall under the category of governmental projects, or that we may need query using an ORU with a LOINC code to request .
We are concerned that the content of the Service Catalog object include a “Consent required” attribute. The committee chairs will review the Service Catalog attributes with the PAFM committee, the object steward, to determine the presence or to request the creation of the attribute.
Two European issues with consent data elements were presented by Bernd Blobel:
1. need to explain multiple roles held by a provider when explaining a procedure to a patient. e.g., patient care provider may also have an organizational role as a departmental chair, and have legal responsibilities attached to that role.
CEN is attempting to catalog the different healthcare roles. In Germany, there are 12 categories defined; France has its own list. A CE data type may be needed to handle multiple lists, some of which are taxonomic,
2. In the European view, the object relationship of signature in a document which cannot be separated from other content. There is a further case of granular content, each instance of which may contain a signature. When the system assigns a signature value to a document, it does not capture that granularity. The existing Chapter 9 does not have the ability to capture more granular signatures.
We need to think of signature as a separate with additional
Wayne suggested that this is being addressed in the ORU segment in the Orders committee.
Bernd suggested a different solution. If system verifies intermediate signatures, applies a numeric value for the signature, the overall signature assignment then captures the intermediate. Consent transaction is useless without the signature as part of the transaction. It requires a “notification of signature on file” transaction if we cannot ensure the signature attachment. The digital certificate needs to be carried in the message. We agreed that the issue includes additional issues of content security on the application side
We have a signature object in the RIM, and, as stated in the last minutes, that there will be additional attributes developed through industry practice. This may be later than the actual passage of legislation mandating such granular attributes, as in the case of the HIPAA legislation. Our intention is to be able to do medical records intra- and inter-organizations, and current legislation appears to represent security occurring a MSH level, not more granularly, based upon the encryption model creating an encapsulated encryption of the entire message.
Two locations were cited for locating the HIPAA rules for security implementation:
or the HCFA website. Final Rules November 12, 1998.
Wayne requested that we discuss security implementation tactics and needs at our next meeting. Requests that the committee members read the HIPAA Final Rules