HL& Medical Record/Information Management
Technical Committee Meeting
Salt Lake City, UT
October 2 & 3, 2001
Attendees:
Tuesday Morning: Joint meeting between Medical Records/Health Information and Structured Documents. Wayne Tracy, Harry Rhodes, Robert Dolin, Liora Alschuler, Pavla Fraizer, Calvin Beebe, Bonnie Bakal, Thomson Kuhn, Mike Cassidy, Zijun Zhou,
http://www.medical-record.blogspot.com/
Jean Spohn, Sarah Ryan, Paul Biron, Kendza Yen, Holly Walker, Peter Kress, Nancy Orvis
Tuesday Afternoon: Joint meeting between Medical Records/Health Information and Scheduling and Logistics. Harry Rhodes, Anita Benson, Jane Foard, Dave McDowell, Geoffry Roberts, Holly Walker, Jean Spohn
Wednesday Morning: Joint meeting between Medical Records/Health Information and Structured Documents. Steve Wagner, Wayne Tracy, Harry Rhodes, Bonnie Bakal, Holly Walker, Igor Gavoyushkin, Calvin Beebe, Paul Biron, Micheal Dauguet, Zijum Zkou
Wednesday Afternoon: HIPAA privacy, meeting requests, domain, and analysis.
Reviewed Domain RMIM for Ballot. Reviewed negative ballot comments. Review and “fix” problem with message model. Respond to individuals that cast negative ballot. Robert Dolin will record the dispositions that will be submitted
The work that will need to be done today regarding the negative ballots: Address minor suggestions to fix little problems, a couple of major issues, and a major issue addressing the CMETs
First negative ballot issue: Section 2.3.1 – No vote- minor: Medical Records has chosen to rename some of the attributes used within their cloned classes. In A_Order_fulfillment (an Act that fulfills an order) the id attribute has been renamed id_filler. In A- Order, the id attribute has been renamed to id placer. These attribute names should not be renamed, otherwise it will cause confusion when trying to relate these attributes to those used in orders and observations, where they have not been renamed.
There is a concern that users will become confused between the id attributes id-filler and id_placer. Solution: after the attribute id place “filler” or “placement” in parenthesis” The goal is clarity.
Disposition Statement: The notion of “placer ID” and “filler ID” are widely understood and accepted. We note the O/O uses “id; (filler id) in their VISIO representation, although not in their HMD or messages.
We should continue to have these attributes named as they currently are (id filler) and disagree with the ballot comments.
Disposition Ballot:
In favor of - 9,
Opposed - 0,
Abstain – 5
Addendum: A subsequent discussion with O/O committee reached the following consensus:
· Will change our “id filler” and “id placer” back to just “id”;
· Will add “(placer)” and “(filler id)”after the id attribute in the VISIO diagram.
· Will add a new column to the HMD that signals the relationship between the “id” field and the previously know “filler id” and “placer id” fields of V2.x
Second negative ballot issue: medical records should use the CMETs developed for patients, providers, encounters, devices, etc. instead of coming up with constructs of their own for these information structures.
Disposition Statement: It’s important to note that the information structures used by medical records were those also used by ANSI/HL7 CDA R1.0 2000, and therefore existed long before these CMETs existed.
We have reviewed the existing CMETs and have not found them to accommodate our requirement. We support the recent decision by the TSC to form a M&M subcommittee to harmonize on CMETs, and we are committed to working with that group to ensure our requirements are met.
We (Bob Dolin) will take our information structures and convert them into CMETs to help the M&M harmonization process. In addition, committee members (Calvin, Wayne, Paul, Pavla)) will review the existing CMETs and offer our comments. We anticipate ultimately using CMETs, once this harmonization has taken place.
Disposition Ballot:
In favor: 11
Opposed: 0
Abstain: 1
Third affirmative vote with comment: RIMS comments, Confidentiality Codes: which are valid for documents? Or are all? Found under CWE (Coded With Exception) Usual, Sensitive, and Highly Sensitive. This discussion surrounded complying with HIPAA mandate to allow the patient to restrict access to Protected Health Information.
Disposition Statement: Unclear why the vocabulary constraints expressed in Rose Tree don’t show up in the published package. We’ll need to investigate this. Seems to be an M& M issue.
We do limit the confidentiality codes use for documents to Normal (usual) restricted, very restricted. Confidentiality can be applied to a document and /or to individual sections within a document.
Ballot:
In favor: 13
Opposed: 0
Abstained: 1
MORNING BREAK.
Pavla Frazier, Student at University of Utah Health Care Informatics Program gave an outline of Clinical Document Ontology Task Force work to date. The overview is presented to the joint committee today to demonstrate work that is being done to standardize document names.
There is not a consistency in Document Names. Which makes the exchange of documents difficult. There is a need for a model for document names.
To facilitate;
Indexing and retrieve
Organizing and Sorting
Content Indexing
How were the document names developed?
From: Document names utilized at: VA hospitals, Mayo Clinic, 3M Intermountain Health Care.
Initial document names: (only include narrative documents such as)
Radiology reports
Pathology reports
Discharge Summaries
Progress notes.
Consultation notes
Wayne: The document names will need to be exhaustive.
Axis development:
The initial axis names came out of the Task Forces initial meeting.
What makes a document name what it is?
Axis 1
- Event type focus temporal context, service
- .Focus, subject focus, or object of the note
- Temporal relationship to care.
Axis 2
Property - always finding
Axis 3
Time aspect – encounter or point in time
Axis 4
Practice Setting – type of environment
Axis 5
Kind of narrative -document
Axis 6
Role of documentor – in relationship to patient or family, i.e. physician.
There was a discussion of the axis methodology and its development. Concerns were raised about the axis names and their use. There was discussion about the need for standardized document names so that confidentiality levels could be assigned by document name. As a standards group HL7 normally addresses current practices. In developing standards to address HIPAA mandates we will be working in an unknown area. Should we leave these issues to the individual facilities to develop their own policies and procedures. HIPAA describes behaviors not data content issues, HL7 should not begin to write standards for these behaviors. We should wait for the implementation guides from HIPAA before beginning any standards work.
Comments on the Ballot - Issue: Consent messages: Should this be done by the Patient Care Committee
Act.cd values for consents: USAM questions.
Disposition Statement: the current ballot does not include consents. If this functionality is desired, we would welcome a proposal. We would address this proposal via listserver and teleconference, with hopes of bringing it forward during the January meeting to include in the ballot.
Medical Records TC has discussed consents in prior sessions (see their prior minutes for details). We would expect these minutes would be reviewed as part of a new proposal.
Disposition Ballot:
In Favor: 15
Opposed: 0
Abstained: 0
Comments on the Ballot –Issue Review: Consent messages: Should this be done by the Patient Care Committee
Act.cd values for consents: USAM questions.
Disposition Statement: the current ballot does not include consents. If this functionality is desired, we would welcome a proposal. We would address this proposal via listserver and teleconference, with hopes of bringing it forward during the January meeting to include in the ballot.
Medical Records TC has discussed consents in prior sessions (see their prior minutes for details). We would expect these minutes would be reviewed as part of a new proposal.
Disposition Ballot:
In Favor: 15
Opposed: 0
Abstained: 0
Comments on the Ballot – Issue Review: Document completion codes should be mapped to the status codes (i.e. the act state transitions) and status coded should be mapped to the events (i.e. which status codes are valid for which events)
Disposition Statement: Document completion codes are orthogonal to status codes. We had this discussion at the July Harmonization (present were Wayne, Bob Dolin, Gunther, and others) and this was the decision reached.
We also specifically discussed the relationship of the MDF triggers to the version 2 triggers in chapter 9 during the July Harmonization meeting with Abdul-Malik. We recognize that a single state transition can result in two of the described Version 3 triggers for our chapters, and we were given clearance by the M&M to proceed with this – largely to ensure that the same set of triggers would exist in version 3 that had been present in Version 2.
Therefore, we find these comments non-persuasive.
Disposition Ballot:
In Favor: 7
Opposed: 0
Abstained: 8
Tuesday Afternoon: Joint meeting between Medical Records/Health Information and Scheduling and Logistics.
The JWG reviewed the minutes of the St. Louis meeting from September 12 & 13, 2001. Anita reviewed the Chart Tracking Model as it currently exists. All current trigger events were reviewed and discussed.
The role of the chart custodian/owner was discussed. Does the Chart Custodian/Owner hold the chart in storage? What has been done to date is define interactions in the chart request model.
There was a discussion of the rational for creating the Trigger Events 07, 08, & 09. These trigger events were created to track the location of new charts. Anita reviewed the rational for forming the JWG. (see past meeting minutes)
JWG Committee discussed next steps: JWG needs to write textual use case models (story board) for each chart request scenario.
In Version 3 use case models have been replaced by Storyboards. A storyboard is the narrative description of how the messaging standards would be applied to a real life situation.
The committee has storyboards for the Australian and Dutch models.
The JWG is in agreement; data definitions still need to be written.
The JWG began an exercise to list all of the data definitions that need to be written.
Data Definitions:
· Patient Name
· Chart defined – A chart is a group of components
· List of Chart Components
· Requestable Components (the part of the record to be requested)
· Date Range – Volumes can be grouped by date. Each component will have a date.
· Physical Volume
· Patient ID
· Requester Location
· Encounter Type
· Service Department
· Document Type
Anita: The JWG needs to be concerned with the categorization of the document and the location of the document. Anita: Suggested that we find out what was done in Structured Documents with regard to document type.
The committee discussed the requesting of charts by service location:
· Radiology
· Laboratory
· Occupational Therapy
· Physical Therapy
· Speech Therapy
· Respiratory Therapy
Each of these service locations would have chart content listings. Which is a listing of the components that make up a service location chart.
The JWG is seeking a means to classify documents for chart tracking. Does a classification of documents already exist within HL7? JWG will ask Bob Dolin what is the intended use of the Practice Settings vocabulary categories. The JWG must ask the question can the Practice Settings be used to classify documents for chart tracking. With in the RIM is there a classification of documents? A review of the RIM vocabulary revealed a Document Type domain definition category. This document type does not seem to be populated with values.
Anita opened a discussion of the possible chart location categories. Are there any absolutes? Do we have to create data definitions for locations? Should we allow each facility to establish unique internal location categories?
Wednesday Morning – Joint Meeting MR/IM and Structured Documents
Ballot comment review: Medical Records, 2.1.1.1.1 Trigger Original Document Notification: Description. “There are multiple approaches by which systems become aware of documents.” What doe it mean?
Disposition Statement: will move to a higher level and clarify
Ballot comment review: Records 2.1.1.2.1 page 8 “and indicates in the document management system that the findings have been authenticated by him.”
Proposed Wording: “and indicates in the document management system that the findings have been authenticated by him.” Or “and indicates in the document management system that the finding has been authenticated by him.”
Disposition Statement: Correct the grammar. Change to “finding(s) has been”
Ballot comment review: 2.1.1.2.1 Comment: Awkward sentence structure, not entirely sure what is the main point(s) of the sentence.
Disposition Statement: agree and will correct.
Ballot comment review: 2.1.1.2.1. In no cases where a document was made available for the patient care will this interaction occur. Awkward sentence, seems like odd use of negatives. Not sure if my correction still conveys the same meaning.
Disposition Statement: we are not sure either, so we prefer to leave is as worded.
Original wording seems to be more prescriptive.
Ballot comment review: Records 2.1.1.2.1 It would be useful if the erroneous document id was supplied and the date and time range when this document was previously available for patient care.
Disposition Statement: Correct grammar. Change to: It would be useful if the erroneous document id was supplied, along with the date and time range when this document was previously available for patient care.
Ballot Comment Review: Records: 2.1.1.3 Question regarding the Document Manager. In the interaction diagram it shows the document manager sending and receiving to itself. I thought the story board said that a document manager from a lab was talking to document manager in the hospital.
Disposition Statement: If there are two instances of the same application role, are we supposed to include two applications communicating or one application with a recursive communications?
We’ll ask the UML experts and do whatever M& M recommends here.
Ballot: Does anyone object to grouping the ballot comments together for a single vote.
In Favor: 10
Opposed: 0
Abstained: 0
Ballot comment review: Records 2.3.1 Revamp R-MIM to use newest stencils, and ensure that it is validatable against the RIM. (some missing mandatory fields, convention for handling alias names, etc.) Also suggest re-organizing the R-MIM to avoid crossing lines (flipping the Roles may help this).
Disposition Statement: Will follow the M&M recommendations.
Ballot:
In Favor: 10
Opposed: 0
Abstained: 0
Addendum: During the M&M wrap-up meeting 10/4, it was clear that the new expectation is to use the latest VISIO stencil just as Lloyd has requested us to do.
Ballot comment review: Records 2.3.1 R. originating device should have a class_cd of DEV. It should also have a name or id (consider using the CMET)
Disposition Statement: See response below on our approach to CMETs. We will include the device CMET in those we submit to the CMET task group.
In the current RIM and current Rose Tree, there is no value of “DEV” for role class codes. We do use the value of “DEV” in the Device clone. So, unless the vocabulary has changed and isn’t properly reflected in Rose Tree, we’d leave the class ed values as they currently stand. Also, R_originating device does have an id attribute, so we’re not sure we understand the comment.
Ballot:
In Favor: 10
Opposed: 0
Abstained: 0
Ballot Comment Review: records 2.3.1 R individual healthcare provider under the P_ structure_originator should have a name and/or id (Consider using Ident provider CMET)
Disposition Statement: The comment is unclear. Clone R Individual healthcare provider has an id attribute , and clone Person named person has a “nm” attribute. So, no change for now.
Ballot:
In Favor: 10
Opposed 0
Abstained: 0
Ballot comment Review: Records 2.3.1 Observation as Multimedia _document_content should have a ‘cd’ attribute to specify the type of document. The value attribute should be identified as datatype ED.
Disposition Statement: This clone represents a multimedia object in a document. It is always part of a document. (represented by the AC Clinical document class.) We will add clarifying narrative to this effect. There is no need for a ‘cd’ attribute.
The value is ED, and we’ll follow M&M recommendations as to how to reflect this in the VISIO diagram.
Ballot:
In Favor: 10
Opposed: 0
Abstained: 0
Ballot comment review: records 2.3.1, What is the reason for distinguishing between narrative and multimedia documents? Both can be easily handled by the ED datatype of the txt attribute.
Disposition Statement: Will add clarifying text. These are both components of documents – one for narrative, one for multimedia. We will add clarifying narrative to this effect. Will change the datatype of A_Narrative_document_ content txt to “ST”
Ballot:
In Favor: 10
Opposed: 0
Abstained: 0
Ballot Comment Review: Records 2.31, the inclusion of P_Participant seems a little open ended. Consider restricting it to a more specific list of “other” participation types.
Disposition Statement: Will exclude those type _cd values that are not applicable.
Will add the function_cd attribute to the P_participant clone. In particular: will add “CON” to P_Provider, and will the type _cd of P_participant to “REF”, “BBY”, “MTH”, “ServiceActor”, “ServiceTargetType”.
Ballot:
In Favor: 9
Opposed: 0
Abstained: 0
MORNING BREAK
Vocabulary Word in response to the comments on the class entitled Participation Type. The work of the JWG is to eliminate unnecessary person type code classes. There was a group discussion of the code for ‘witness’ Coded as: witness (WIT). A reason for controlling the person that is coded is the medical legal requirement to protect the content of the medical record document. This information on participant would be in the header of the document. Bob Dolin to post suggested exclusion list on the HL7 Listserv for comment.
Exclusion List:
· Consenter, Coded as Consenter (CNS)
· Reviewer, Coded as Reviewer (REV)
· Witness, Coded as Witness (WIT)
· Call Back Contact, Coded as Call Back Contact (CBC)
· Data Entry Person, Coded as data entry person (ENT)
· Informant, Coded as Informant (INF)
· Tracker, Coded as Tracker
· Escort, Coded as Escort
· Origination Device, Coded as Origination Device (ODV)
· Product, code as product (PRD)
· Donor, code as donor (DON)
· Proxy, code as proxy (NOK)
· Patient Subject
Leave on the list:
· Supervisor, Coded as Supervisor (SPV)
· Verifier, Coded as Verifier (VRF)
· Consultant, Coded as Consultant (CON) – this should be a function code and nor a type code.
· Referrer
· Receiver, Code as Receiver (RCV)
· Baby , Code as Baby (BBY)
· Mother, Code as Mother (MTH)
· Service Actor,
Wednesday Afternoon: HIPAA privacy, meeting requests, domain, and analysis.
Agenda for the HL7 Medical Record/information Management Technical Committee Meeting in San Diego, CA, January 8 & 9, 2002
Agenda Items:
Tuesday AM:
Joint Work Group meeting MR/IM TC and Structured Documents. V3 Ballot 2 preparation.
Tuesday PM:
Joint meeting between Medical Records/Health Information and Scheduling and Logistics. Advance work in chart tracking model, develop story boards and data definition.
Wednesday AM:
Joint Work Group meeting MR/IM TC and Structured Documents. V3 Ballot 2 preparation.
Wednesday PM:
Joint meeting between Medical Records/Health Information and Scheduling and Logistics. Advance work in chart tracking model, develop story board and data definitions.
Comments (0)
Posting Komentar