Patient Administration Meeting Minutes
September 11 through 14 2006
Attendees:
Name / Affiliation / HL7 MbrY/N / MQ3 / MQ4 / TQ1 / TQ2 / TQ3 / TQ4 / WQ1 / WQ2 / WQ3 / WQ4 / TQ1 / TQ2 / TQ3 / TQ4 /
Gregg Seppala / VA / Y / X / X / X / X / X / X / X / X / X / X / X / X
Klaus Veil / HL7 Australia / Y / X / X / X / X / X / X
Yongjian Bao / GE Healthcare / Y / X / X / X / X / X / X / X / X / X / X / X / X / X / X
Christine Bester / HL7 Canada / Y / X
Bob Davis / NAHDO/NCHS / Y / X
Bob Grant / Infoway / Y / X
Alexander Henket / HL7 Netherlands / Y / X / X / X / X / X / X / X / X / X / X
Alan Honey / Kaiser / Y / X
Jeff Jacobs / Oracle / Y / X / X / X / X / X / X / X / X / X / X / X / X
Jeri Jones / VA / Y / X
Maryann Juurlink / HL7 Canada / Y / X
Richard Kavanagh / NHS CFH(UK) / X
Karim Keshavjee / GP Informatics / X / X / X / X
John Kufuor-Boakye / HL7 Canada / X
Lloyd McKenzie / HL7 Canada / Y / X / X
Hugh Morgan / Athens Regional Health Services / Y
Tom Oniki / Intermountain Healthcare / Y / X / X
Nancy Orvis / DoD Health / Y / X
Mike Ostter / MediServe / X / X
Amit Popat / Epic Systems / Y / X / X / X / X / X / X / X / X / X / X / X / X / X
Jay Price / Athens Regional Health Services / Y / X
June Rosplach / Kaiser / Y / X
Ken Rubin / EDS / Y / X
Monday 2006-09-11 Q3 (1:30 – 3:00)
I. Welcome and introductions
II. Review mission, charter and decision making practice
· Mission and charter are still ok but the mission statement for Patient Administration in printed agenda and on-line are both wrong and need to be updated. Action: Klaus will follow-up with HQ.
· Decision Making Practice, including use of proxy votes, still ok.
III. Determine quorum adjustment
Motion was made by June Rosploch and seconded by Klaus Veil to adjust quorum to presiding chair plus three members with the proviso that the chair monitor for preponderance of influence. Motion passed 5-0-0.
IV. Review/adjust agenda
· Monday Q4 changed from "V3 ballot resolution" to "V3 pending discharge notification proposal." This agenda change was made to accommodate Bob Grant's schedule. The TC agreed that it would hear the proposal from HL7 Canada but due to the short notice the formal decision to ballot the content would be deferred until the topic could be discussed on the list server.
· Tuesday Q4 changed from "Harmonizing the UK PDS Proposal messages" to "V3 ballot resolution" because the scheduled presenter will not be available.
· Thursday Q3 changed from "V3 Work" to "Consider post-ballot comments from HL7 Netherlands." Action: Gregg will post notice of agenda change on notice board.
Monday 2006-09-11 Q4 (3:30 – 5:00)
V. V3 Pending Discharge Notification Proposal
Robert Grant presented a new requirement identified by Infoway to support public health surveillance in Canada. The Canadian Public Health Surveillance project has a requirement for two HL7 V3 interactions to support notification of a pending inpatient discharge. Applicable trigger events are already described in v.2x, however at present there are no V3 messages.
Following discussion it was proposed that the need could be met by using the existing "Revised Inpatient Encounter" R-MIM with new trigger events and interactions for “pending inpatient discharge notification” and a matching “cancel pending inpatient discharge notification.”
The inpatient encounter topic was last published in the September 2005 ballot. The following artifact identifiers are reserved for the new content:
a) Storyboards
· PRPA_ST402012 – pending inpatient discharge notification
· PRPA_ST402013 – cancel pending inpatient discharge notification
b) Trigger events
· PRPA_TE402012 – pending inpatient discharge notification
· PRPA_TE402013 – cancel pending inpatient discharge notification
c) Interactions
· PRPA_IN402012 – pending inpatient discharge notification
· PRPA_IN402013 – cancel pending inpatient discharge notification
The requirements and proposed response will be posted to the Patient Administration document library for review and discussion. A decision to approve the content will occur the week of October 16. Action: Gregg will post document and send notice to PA list server by September 22.
Tuesday 2006-09-12 Q1 (9:00 – 10:30)
VI. V3 Ballot Resolution
The Patient Administration V3 Release 2 committee ballot 2 passed in the 2006 Sep ballot cycle. Details below:
Member Type / Affirmative / Negative / Abstain / No VoteAffiliate / 0 / 0 / 6 / 1
Consultant / 1 / 0 / 0 / 2
General Int. / 1 / 0 / 1 / 1
Payor / 0 / 0 / 0 / 0
Pharmaceutical / 0 / 0 / 0 / 0
Provider / 24 / 1 / 0 / 0
Vendor / 15 / 0 / 2 / 2
Totals / 41 / 1 / 9 / 6
% of Votes / 71.93% / 1.75% / 15.79% / 10.53%
Quorum / 89.47%
Approval / 28
Four voters submitted comments that categorize as follows:
Comment Type / CountNeg Minor / 0
Neg Major / 1
Aff Suggestion / 5
Aff Typo / 2
Aff Question / 4
Total / 12
The TC reviewed the Affirmative-Typo comments:
· Item #1 is a typographical error and will be corrected
· Item #11 addresses the form a structured sort name that is automatically generated by the publishing tools. This item will be referred to the Publishing TC for consideration.
The TC reviewed the Affirmative-Question comments:
· Item #6 states that "In May 2006, it was discussed in INM that an organization cannot be a player ever." Response: The TC could not find any reference to this discussion. We will ask the submitter to provide additional information.
· Item #7 asks why does the Transportation act in the PA DMIM include a Subject participation since the DMIM walk-through states that in the TransportedBy act relationship between Patient Encounter and Transportation the "contextConductionInd is set to 'true' because the encounter and the transportation have the same subject (patient)?" Response: The PA DMIM is also the source for the A_Transportation CMET that conveys information about the transportation of any subject from one location to another.
· Item #8 asks what is the use of the NonPersonLivingSubject.quantityCode attribute in the PA DMIM? Response: NonPersonLivingSubject in the DMIM can take on a determiner code of "kind," "quantified kind," or "instance" to support certain CMETs. Only where determiner code is "quantified kind" can quantity be greater than 1. In that case a quantity of 5 implies a pack of 5 dogs. If there is an id it identifies the pack not any individual dogs. All other attributes also apply to the pack.
· Item #10 asks why, at the head of the DMIM walk-through there is link labeled "Patient and Person Registries" that leads to text that states "The Patient Administration D-MIM defines content for two types of registries for living subjects -- patient and identified entity." Response: The TC agrees that using the text "patient and person" in the link that connects to PatientRole and IdentifiedEntity is confusing. The TC will change the link text to "PatientRole and Identified Entity" to be consistent with the model. Note also that the DMIM defines the entire scope of the Patient Administration domain including content that has not been balloted yet.
Tuesday 2006-09-12 Q2 11:00 – 12:30
VII. V3 Ballot Resolution (continued)
The TC discussed the one major negative ballot comment:
#12: There appears to be an overlap between the functionality of PA registry messages and EIS SOA. Please clarify how these are related.
A representative of the Healthcare Services Specification Project who co-authored the EIS specification joined our TC for the discussion of this ballot item.
Entity Identification Service is a specification for an interface that can be provided by a registry application. The interface specification can implement different "profiles" devoted to different entities / roles (Person, Patient, etc.). A profile can be based on the HL7 v3 RIM. Other profiles can be defined for other reference standards such as OpenEHR. Rather than returning a structure of classes as defined in an R-MIM, EIS service returns a list of parameters (name-value pairs)
The EIS meta-model is a computing service model rather than an information model such as the RIM. EIS does not make use of RIM, though its classes / parameters may be mapped to RIM classes. EIS "Entity" is not RIM "Entity."
In the case of EIS patient profile, the EIS and the V3 standard are not addressing the same thing (application service vs. messaging), no overlap occurred.
This is a misconception that these two efforts are addressing the same problem.
To promote HL7 V2 message use, EIS needs to define map between the service traits and the V2 message fields.
Side discussion: A deprecated ID can be used to reference an entity but a search using other traits of the entities (name, birth date, etc.) should not return deprecated IDs of the matched entities.
Action: Jeff will draft a response to the ballot negative.
The TC will vote on the disposition of this negative after it reviews the draft response on Wednesday Q4.
Tuesday 2006-09-12 Q3 1:30 – 3:00
VIII. V3 Location Registry Proposal
Lloyd McKenzie presented new requirements identified by Infoway for service delivery location registries to support the Canadian iEHR project.
Infoway identified six use cases:
a) Incident Location (e.g., where person had heart attack)
b) Clinical Action Location
c) Data Entry/Access Location
d) Privilege Location (clinician has practice privileges at specific hospital)
e) Physical Storage Location – who is custodian of stored record (facility)
f) EHRi Location
Issues raised during discussion:
a) What role code represents a place play where no services are delivered? Example: patient has heart attack in church.
b) Is there a need to represent a relationship between service delivery location roles regardless of place and/or organization relationships? Currently relationships are modeled only among Places (playing entity) and Organizations (scoping entity).
c) Need to add Place.mobileIndicator for places such as ambulances.
d) Need to be able to capture alternate identifiers used for the same service delivery location by different organizations.
e) Does every SDLOC require binding to an organization?
f) Need to represent the services that can be performed at a location.
g) Need to represent set of contact points for a service delivery location for different purposes (e.g., scheduling, normal, emergency, nights) “yellow pages.”
h) Need to represent territorial authority that has authority over the service delivery location.
i) Need to represent repository that holds this data (expect this to be in wrapper for registry).
Action: Lloyd will provide requirements document for posting to the Patient Administration document library.
Tuesday 2006-09-12 Q4 3:30 – 5:00
IX. V3 Ballot Resolution (continued)
The TC reviewed the Affirmative-Suggestion comments:
· Item #2: The Publication Database only allows selecting Send Message Payload transmission wrapper MCCI_MT000100 but the Transmission Infrastructure ballot states that MCCI_MT000100UV01 "is for backwards compatibility only. The use of this artifact is discouraged. It will be removed from the standard at some point in the future" and advises use of MCCI_MT002100. Response: Refer to Publishing TC
· Item #3: The Publication Database only allows selecting Application Level Acknowledgement transmission wrapper MCCI_MT000300 but the Transmission Infrastructure ballot states that MCCI_MT000300UV01 "is for backwards compatibility only. The use of this artifact is discouraged. It will be removed from the standard at some point in the future" and advises use of MCCI_MT002300. Response: Refer to Publishing TC
· Item #4: Proposes a more inclusive definition for Person.desc attribute than just text. Response: Persuasive with mod. TC agrees that description should agree with RIM description (suggested wording does not match current RIM description). TC also forwards a request to Publishing for Table View and Excel View to default to description from parent model where a TC has not entered a revised description. Vote: 4-0-0.
· Item #5: Proposes a revised description for PatientEncounter.dischargeDispositionCode in the DMIM walk-through to make clear the attribute does not apply only to inpatient encounters. Response: Persuasive. TC agrees that the proposed wording better reflects committee intent. Vote: 5-0-0
· Item #9: Duplicate item #10 in the form of a suggestion. Response: The TC agrees that using the text "patient and person" in the link that connects to PatientRole and IdentifiedEntity is confusing. The TC will change the link text to "PatientRole and Identified Entity" to be consistent with the model. Note also that the DMIM defines the entire scope of the Patient Administration domain including content that has not been balloted yet. Vote: 5-0-0
Wednesday 2006-09-13 Q1 9:00 – 10:30
X. V2.6 Review and Reconciliation
· Line item #8 Frank's comments - Neg-Mj - found persuasive - but what about other CWE fields?
· Line #43 - Frank's comments - Neg-Mi - NOT persuasive - table 0354 NOT in Chapter 3