- Financial Management Technical Committee Meeting Minutes
- HL7 Working Group Meeting
January 8 – 13, 2006
Phoenix, Arizona
Co-Chairs:
For more information on the Financial Management Technical Committee, please contact one of the co-chairs listed below:
Francine KitchenIDX Systems Corporation
925 4th Avenue
Suite 400
Seattle, WA 981014
(360) 592-8001
/ Kathleen Connor
Fox Systems Inc.
6263 N. Scottsdale Road
Suite 200
Scottsdale, AZ 85250
Phone: 360.357.3536
Fax: 480.423.8108
Susan Lepping
Siemens Medical Solutions
51 Valley Stream Parkway
Malvern, PA19355
Phone: 610.219.8673
Fax: 610.219.5849
Editors:
Gaby Jewell, Editor Chapter 6
/ Beat Hegglii, Editor, Chapter 16Project Leads:
Francine KitchenMapping Project
/ Beat Hegglii, FM International Affiliate Liaison
Version 3 Faciliators:
Shubhda Royv.3 Publishing Facilitator
/ Kathleen Connor
Vocabulary and Modeling Faciliator
Table of Contents
Monday Q1
Monday Q2 – Joint with PA and PM
Monday Q3 – Joint with PA and PM
Monday Q4
Tuesday Q1
FT1 performing facility and ordering facility
Presentation of Oracle’s Eligibility Model
Missing Elements in Artifact Inventory
Tuesday Q2
Eligibility Mapping HIPAA to FICO
FICO
Tuesday Q3
Tuesday Q4
Wednesday Q1
Wednesday Q2
Wednesday Q3 – Joint with PA
Species
Patient Query Proposal from Germany and Netherlands
Patient Query Proposal from GE Healthcare
Wednesday Q4
Thursday Q1-Q4 Joint with PA and PM
Friday Q1
Report from Facilitators Forum Thursday Night:
FM Interim Meeting
Friday Q2
Friday Q3
Friday Q4
Attendence
Appendix A: Map HIPAA 271 to V3 FICO
Appendix B: UK PDS Qurey Proposal
Appendix C: Cross-Domain DAM Requirements
Monday Q1
Welcome/Introductions
Review Agenda: Kathleen won’t be in this committee every session and it’s unpredictable when she’ll be here. So when she’s here, we’ll use her time to talk about the new/interim V3 developments. The agenda was modified to reflect what we’ll be doing when Kathleen is not with us. Patient demographics query proposal added to Monday Q4 agenda. Mapping tool discussion added to Tuesday Q4 discussion. Presentation of Oracle’s eligibility RIMadded to Tuesday Q1 agenda.
Review Mission, Charter, Decision Making Practice
Review Interim Work: Francine and Shuby described an overview of interim work for new attendees.
Vocabulary Updates: Brief overview of actCoverageType vocabulary proposal. Dave Remmer questioned what’s the use case for breaking down coverage types into a complex hierarchy rather than something simpler. The provider won’t know the coverage types. But this R_covered_party CMET is for enrollment and eligibility messages from payers to payers, sponsors, etc.
Monday Q2 – Joint with PA and PM
Charlie Mead of Oracle presentation about HDF and the need for requirements. The HL7 Development Framework (HDF) addresses the problem of capturing requirements from domain experts and translating them to RIM-derived data exchange structures. Chapter 2 about requirements.
Most software engineering fails because of inadequate requirements definition. Domain experts shouldn’t have to learn the RIM modeling in order to help build messages. Separate the How from the What. HL7 has lots of tools for specifying the How, not the What. We need to capture the concepts in the minds of domain experts. We need a view of the world that domain experts can validate, a domain map. Domain Analysis Model (DAM) is an implementation-independent representation of the problem space.
UML class diagram (like the RIM) for the static view: need UML modeler and domain expert. Don’t need knowledge of HL7. It will be mapped later to the RIM, but after it’s validated by domain experts. Use instance diagrams for examples
Also need a dynamic view consisting of storyboards as UML activity diagrams. The static view comes out of the dynamic view.
Need BOTH the class diagram and the activity diagrams.
HL7 standards are design documents. We shouldn’t ballot design documents until it’s been implemented 3 times, because once it’s been implemented the ANSI standards process slows things down and requires backward compatibility.
The BRIDG model is a DAM developed by CDISC to harmonize different technical committee bottom-up projects which originally started with XML. It uses some V3 data types structures.
Need tooling to move from DAM to DMIM: a semantic web construction tool. Currently using Excel, which is combersome, but way easier than forcing domain experts to speak RIM-speak. Domain experts who have been through analysis modeling have converted from being very skeptical to very much in favor. Models should be built by a few (5 or less plus UML modeller & scribe to draw out questions) and vetted by many.
DAMs will overlap with other DAMs, so harmonize the semantics when try to represent them in HL7 RIM. HL7 will require committees to put everything into a DAM for new content to be balloted. Companies, similarly, would want to build an enterprise model.
UML Enterprise Architect s/w is affordable at $300 per copy. UML 2.
This presentation will be posted with PA minutes. Or contact Jean Ferraro.
Monday Q3 – Joint with PA and PM
Listed and prioritized agenda items and preliminary discussion of some. Further discussion of these items will occur in Thursday’s joint meetings. Following were the high priority agenda items:
need an understanding of the appropriate use of undifferentiated role class; it’s being implemented differently per PM. Use case: People in a registry with multiple IDs used for other organizations also need to be stored and with the scoping organization and whose using it (not just who issued/scoped it, which is in OID). Action Item: Continued discussion will take place with a smaller group: Gregg Seppala/PA, Leon Salvail/PM, Bob Grant/PM, Irma J./PA, Norman/PA. Tues 5pm, Casita 2
Use of Role.name vs Entity.name: when is it appropriate to use one or the other, e.g., person name vs patientRole name or providerRole.name? This is more than a modeling issue; need domain experts. Confusion about a person vs their role. Attributes (name, telecom, address) should be in one or the other, not both (would need a harmonization proposal)? Action Item: Clarify the use cases for the use of these attributes in the entity vs the role…taken by Leon S., Bob. See negative ballots on PA when they had the attributes only in Role. June will collect use cases.
Insurance: how do we manage insurance information? Will be discussed on Thursday when Kathleen can attend.
Person Occupation (vs job code): person employee attributes relate to jobs scoped by an employer; how to add an occupation not tied to an employer. Difference between job and occupation: there is no scoper for the occupation. Occupation code should not be in employee attributes. For environmental exposure, may need to know occupation, not necessarily job; also used in Netherlands to help with social setting. Tom
How to represent related person data
Response to request messages on rejects: dynamic model may need to be changed. There’s no methodology in the current dynamic model for responses to request messages.
For the rest of the (non-high priority) issues, see PA minutes, but we think we won’t have time to address the other in our PA/FM/PM joint meetings.
We will continue to have joint PA/FM/PM meetings at future WGMs as follows: Monday Q2 about agenda, Monday Q3 joint PA and FM, and Thursday all day joint PA/FM/PM.
Monday Q4
Was going to be a discussion with someone from Patient Care, but that didn’t happen. Dave led a discussion of use of OIDs with multiple IDs.
Walk through of first half of FT1 segment V2-V3 mapping. Dave volunteered to review the entire V2-V3 mapping and then join the weekly mapping call to discuss issues identified.
Tuesday Q1
Several miscellaneous orders of business were handled.
V2.7 Proposal: FT1 performing facility and ordering facility
Discussion of Shubda Roy’s, Siemens, FT1 modification proposal to add performing facility and ordering facility. Motion was made and passed: (Joe Estrada /Barry Gunnin/) 7-0-1
Short Description:
Add 2 new field to FT1 segment. The Performing Facility Name is repeating, because a service can be performed in two places. For example, a service can be performed in Lab1, and Lab2.
Justification:
Currently HL7 explicitly defines FT1- 20 and FT1-21 for the performing and ordering staff. These fields are sometimes misused for performing facility and Ordering Facility. There is need to explicitly define name of the place/facility where the service is performed and ordered. This will ensure that both the staff and the facility is interfaced on the charge simultaneously.
Proposed Solution
Add two new fields 32, 33to FT1 segment containing the Performing and the Ordering facility name respectively.
6.5 MESSAGE SEGMENTS
6.5.1 FT1 Financial Transaction Segment
HL7 Attribute Table - FT1 - Financial Transaction
SEQ / LEN / DT / OPT / RP/# / TBL# / ITEM# / ELEMENT NAME32 / 550 / XON / 0 / Y / XXXX / Performing Facility Name
33 / 550250 / XON / 0 / XXXX / Ordering Facility Name
6.5.1.0FT1 Field Definitions
6.5.1.32 Performing Facility Name (XON) XXXXX
Definition: This field contains the name of the Facility where the service is performed by Provider Person/Group identified in FT1-20.00.00.
6.5.1.32 Performing Facility Name (XX) XXXXX
6.5.1.33 Ordering Facility Name (XON) XXXXX
Definition: This field contains the name of the Facility where the service is ordered by the Ordering Provider/Group identified in FT1-21.00.00.
Presentation of Oracle’s Eligibility Model
Presented by Pauline Troiana and Valerie Kirk of Oracle requested by Kathleen. Pauline handed out a printed RMIM model and walked through it. The graphic was not submitted in soft copy. The diagram contains parenthetical notes with references to data in the 270/271 HIPAA transactions. Therefore, this model will be VERY helpful in starting to map 270/271 to V3. Many thanks to Oracle.
Missing Elements in Artifact Inventory
Francine explained how as a result of creating the artifact inventory, some missing elements were identified. Francine showed examples of types of missing elements found. The biggest area of effort is that there are 78 storyboards that need to be created. We discussed how to address these. Shuby volunteered to start working on these. She’ll report back about the level of effort.
Tuesday Q2
Eligibility Mapping HIPAA to FICO
We started the mappingeffort for the 271 transaction. The current normative V3 Eligibility query and response are much simpler than the 270/271. We accept the Oracle model as a complete HIPAA-mapped model which needs to be harmonized with the new FICO DMIM that is under development.
Dave Remmer argued that the loops in HIPAA for batching requests should not be replicated in V3. In V3, each message would be from one requestor to one information source about one patient.
Committee also decided to bring this discussion to Thursday’s Q2 joint meeting with PA and PM.
FICO
Kathleen briefly presented the current state of the new FICO DMIM.
Tuesday Q3
Began the actual spreadsheet mapping of HIPAA 271 to FICO. Identified gaps in FICO. See separate mapping spreadsheet in Appendix A.
Tuesday Q4
Demo and discussion of Robert Worden’s V2-V3 mapping tool. The objective was to collect what mapping work has already been done: FM, PM, CDA, Oracle early version of RIM. Also to standardize the format of mappings in order to better share them. The tool will read and write Excel formats. Validates that your V3 fields match actual V3 fields. Can export to Excel or XML. See attached user’s manual for this tool.
The tool currently can:
Update the V3 message with a new version while retaining the mappings
Able to map one field in V2 to a field in two messages in V3 by map to a root class that maps, not to the top of the message
be able to pull a generid data type mapping into a specific segment and the specific path names are expanded
There are mappings, e.g., PA, in the Rim also that are in RoseTree published but informative only which are not in spreadsheet format.
We discussed what the tool would need to be able to do in order to replace our use of Excel:
be able to map one field in V2 to two fields in V3 with out V2 error message
explanation of tool’s use of Xpath notation that makes valid V3 class name & whether to include CMET name (no) or choice structures (every choice is a separate path)
helpful error messages for invalid fields: hover over field to see error reason
be able to import from Excel, edit in the tool, and export to Excel without loss of information; currently a deleted tool will reappear in Excel…unless we don’t need Excel anymore
(check mapping tool requirement document from FM a year ago)
Francine and Shubby said that when we get the next version of this tool, we will use the tool.
Wednesday Q1
Continued mapping HIPAA 271 to FICO. See separate mapping spreadsheet in Appendix A.
Wednesday Q2
Continued mapping HIPAA 271 to FICO. See separate mapping spreadsheet in Appendix.
Wednesday Q3 – Joint with PA
Species
Jim Class: entityCode attribute in non-patientLivingSubject class is where species is coded, so to support animals, need entityCode in any relevant DMIMs. PA will consider and vote to add entityCode to nonPersonLivingSubject in the DMIM. Motion was made and passed by PA and will be in next release.
Patient Query Proposal from Germany and Netherlands
Discussion of two patient demographics query proposals from Rene Spronk, representing HL7 Germany and HL7 Netherlands, and from Francine Kitchen, representing GE Healthcare.
Rene Spronk explained that the first part (1 query/response messages) of his proposal (proposal 926) already was passed by PA during the last WGM. Discussion of the second part of his proposal (1.1.2 “Phonetic” Parameters) led to passing the motion for PA to work with any relevant other committees to establish how the phonetic search parameter use case as described in proposal 926 can be dealt with.
The third part of proposal 926 is development of an encounter query topic. A motion was made and passed that the committee recognized that thisis a valid requirement and will entertain a detailed proposal (from Rene). The work will be derived from the Dutch national infrastructure development.
The fourth part of proposal 926 is to add confidentialityCode attribute to the next release of the Person class. (The UK MIM and HL7 V3 has this on the PatientRole class.) Motion was made and passed.
Patient Query Proposal from GE Healthcare
There is a request with 6 proposals from the UK that was presented by Francine Kitchen. See attachment titled UK PDS V3 Proposal v3.doc in Appendix B. We have already committed to define patient queries and responses.
What is PDS – it is Patient Demographic Service
There are some parts that fall outside of the PA domain. We need someone verify the assumptions and verify the terms into terms that PA is familiar with.
The proposal included the following proposals:
A simple trace query for demographics based on name, sex, date of birth, date of death, postal code. A successful response returns one and only one patient that meets the criteria.
An advanced trace query allows refinement of the search by additional criteria (address, PCP) and can return multiple canditates.
A tracematch is the response message to both the simple and advanced trace. The patient data returned consists only of patient ID, phone, confidentiality code and the data elements that are in the query.
A retrieval query is used to request all patient demographic data after the patient ID is known.
A Successful retrieval contains all patient demographic data.
A confirm repository ID number query is similar to the trace query with addition of the patient ID. This is used to confirm that the correct ID number is used. It is used only when the repository ID is already stored on the local system.
The Repository ID number confirmation is the response to the confirm Repository ID number query.
The allocate Repository ID number requests asks for a new Repository ID number to be assigned to a patient.
The allocate Repository ID number response is the reply to the allocate Repository ID number request.
The general update request asks that repository data be updated.
The general update response is the response to the general update request
Individuals related to the patient could come back as data – this might require a change to the DMIM.
We need to have a PA work item to define the patient registry query and responses required for this. The payloads will be different. If there are people committed to conference calls – this could be done in work groups via conference calls.
Gregg will compare information requirements. Francine will verify that the requirements are mapped correctly. Highlight difference to what exists at the RMIM level. Francine is responsible for providing the artifacts required for this to be included in the ballot.
A motion was made and passed (9-0-3)for the Committee to actively pursue developing this for committee ballot release 2 for May 2006.
Two representatives of UK NHS volunteered to help Francine with the work: Richard Kavanagh () and Jeffrey Shields ().
Wednesday Q4
Mapping HIPAA 271 to FICO was completed. See separate mapping spreadsheet in Appendix A. The next step will be to remediate the gaps. An FM interim meeting is being planned in Seattle to remediate the data gaps known so far.
Thursday Q1-Q4 Joint with PA and PM
PA/FM/PM will developing a cross-domain domain analysis model (DAM). Each committee presented an overview of relevant existing artifacts.
Development of the cross-domain DAM will proceed by going through the follow steps with the indicated participants:
write a giant storyboard that includes the business process of all 3 domains
domain experts for business process
facilitator
Create a UML activity diagram
domain experts for business process
facilitator
modeler
scribe
write message requirements
domain experts for data content
facilitator
create the DAM
domain experts for data content
modeler
scribe
The joint committees decided to use the wiki site for collaboration on these work products. Bob Grant will start out the wiki for our use.
After working on these artifacts when each committee thinks their domain is well represented, then we should have a cross-domain review.
The joint committees edited the first administrative storyboard together. See attached administrative DAM requirements first draft in Appendix C.