2015-05-14 PA WGM Minutes
Patient Administration Work Group Minutes - Thursday May 14, 2014
Thursday Q1
| HL7 Patient Administration Meeting Minutes Location: Hyatt, Paris, France, Guest Room 2331 |
Date: 2015-05-14 Time: Thursday Q1 | ||
| Facilitator | Line Saele | Note taker | Alex de Leon |
| Attendee | Name | Affiliation | |
| X | Line Saele | Helse Vest IKT Norway | |
| X | << update attendee list >> | ||
| Quorum Requirements Met (Chair + 2 members): No/Yes | |||
Agenda
Agenda Topics
- <<update agenda topics>>
Supporting Documents
Minutes
Minutes/Conclusions Reached:
Introductions
Joint with PHER. The WGs discussed the current progress of this project. Although there was work done during the last WGM, it seems there has been no work since then. The WG discussed the viability of this project. The suggestion was made to send a message to both listserves letting people know that this project will be closed due to lack of interest in the project.
A motion was made by Irma, seconded by John, to send a message to both listserves letting people know that this project will be closed due to lack of interest in the project. If there is no feedback, the project will close in the October WGM.
Discussion:
Vote (for/against/abstain): 6/0/0
HAVE project.
OASIS and TEP standard.
There is an issue in difference in messaging paradigms. As an example, there is a mechanism within the OASIS specification that allows for building vocabulary ad hoc. PHER representatives showed the
TEP-HL7v2-Transforms_WorkfindDraft_Master_wbj.ods document
This is essentially a “mapping” of the elements of both the message structures.
Another example is the hl7 v2 observation segment which on the TEP side, sends a string of barriers, while HL7 sends a rich set set of objects.
PHER will be noted as an interested party of the HAVE specifications.
John suggested that Emergency Care be invited to the Q1 Thursday session within the next WGM. The WG discussed who should host and sponsor this.
The WG discussed the resources needed to move this work forward. It is clear that there is a need of emergency expertise to help map the data elements.
The PAWG Chairs will look into whether we are the main sponsors of the HAVE specification.
Meeting Outcomes
Actions (Include Owner, Action Item, and due date)
|
Next Meeting/Preliminary Agenda Items
|
Thursday Q2
| HL7 Patient Administration Meeting Minutes Location: Hyatt, Paris, France, Guest Room #2331 |
Date: 2015-05-14 Time: Thursday Q2 | ||
| Facilitator | Line Saele | Note taker | Alex de Leon |
| Attendee | Name | Affiliation | |
| X | Line Saele | Helse Vest IKT Norway | |
| X | <<update attendee list>> | Kaiser Permanente | |
| Quorum Requirements Met (Chair + 2 members): Yes | |||
Agenda
Agenda Topics
- << update agenda topics >>
Supporting Documents
Minutes
Minutes/Conclusions Reached:
Joint with FM.
The WGs reviewed the patient account created by Alex.
Considering an Account resource
FM
- Account/Billing
- Claims/Reimbursements
FM has been focused on Claims/Reimbursement, PA is looking at Account/Billing
Paul K: should have proposal for Account resource
Reviewed initial discussion of Account resource in Q? on Monday
Goal is to have Account in DSTU2.1
Paul K: process considerations - officially, new content needs to go into DSTU3 (rather than DSTU2.1), but Paul would support adding to DSTU2.1
Earlier discussion presented challenge of different view of "Account" throughout the world (e.g., Australia and The Netherlands versus United States).
In case of pure public pay, there is no need for an account, because there is no accumulation of costs.
NHS is example of public payer, but private payers DO have accounts
Alex: Account could be "bucket" for costs.
In The Netherlands, costs are not combined in formal "account". Rather Account can relate acivities surrounding episode of care (for example).
Challenge is to agree on what is not realm specific in modelling Account.
Alex focused on mapping from v2 financial concepts
Paul K advised against using v3 representations as they don't represent how it is used in real-world. In modelling claims, Paul did not use "phantom" concepts from v3.
Follow with review of model prepared by Alex.
Started with Insurance class. Taken from v2 IN-1 segment. IN-2 was omitted as it is U.S. specific.
Insured is patient. Patients coverage is insurance. Policy and coverage are currently combined in Insurance. v3 may provide some guidance for refining Insurance. Also, some administration information (e.g., ambulatory status of patient included in Insured - living arragements, employer information, etc, is also administrative)
Social service implications for much of the included data. Should social services be considered within seperate work group?
Need to coordinate efforts with individual in FM in developing resource. Mary Kay McDaniel from FM will liaison with PA.
Paul provided general guidance for revising original draft, including reducing codeable concepts to codes.
PatientAccount is at the heart of the model. Guarantor properly links to PatientAccount (not Patient resource itself)
Irma: FinancialClass should remain in PatientAccount. Paul suggested further investigation.
Where will final output of remodelling exercise land. Brian refered to the FHIR maturity model. Some resources, like this one, will start at FMM value of 0 (lowest maturity).
Group agreed to hold another joint session at next WG meeting in Atlanta.
After some review, the working groups agreed to add the following elements to PatientAccount:
- An identifier for the account
- A list of guarantor
- Linking to the patient
- Link to the coverages
- Array of balances
- Bad debt elements
- Charge elements
- Link to contract (profile for policy) (may be more elements)
- Financial Class (type)
- Delete
- Delete Date
- Delete Reason
- ActivePeriod
- Charges included in a subclass.
Resource will be added just after DSTU2.
Meeting Outcomes
Actions (Include Owner, Action Item, and due date)
|
Next Meeting/Preliminary Agenda Items
|
Thursday Q3
| HL7 Patient Administration Meeting Minutes Location: Hyatt, Paris, France, Guest Room #2331 |
Date: 2015-05-14 Time: Thursday Q3 | ||
| Facilitator | Line Saele | Note taker | Alex de Leon |
| Attendee | Name | Affiliation | |
| X | Line Saele | HL7 Netherlands | |
| X | << update attendee list >> | ||
| Quorum Requirements Met (Chair + 2 members): Yes | |||
Agenda
Agenda Topics
- <<update agenda topics>>
Minutes/Conclusions Reached:
Introductions.
FHIR Planning
The WG addressed the future meetings where FHIR work should be done. Currently this is done on Monday’s at noon PST. The WG proposed Tuesday at the same time. This will be brought up in the next quarter.
Nat asked how the WG is faring with the GForge for ballot reconciliation. The WG gave feedback that it seems more direct than the EXCEL spreadsheet.
- 7874 – Patient.CareProvider v2 mapping.
Proposed Wording: map careProvider to PD1-4
- 6931 - Distinguish primary contact On the Organization Resource – could we recommend adding an attribute in the corresponding Contact for indicating if this organization is the primary contact location? Helps to identify the role the individual is playing – local or enterprise, corporate office vs subsidiary kind of thing.
After some discussion, it was decided that it was common enough to be a standard extension, however not for the core specification. A Boolean standard extension will be defined on the organization.contact to indicate preferred contact (for a specific purpose).
The organization contact purpose valueset will also be changed from arequired to a recommended set.
- 7559 – After looking at discussions on the thread for Lloyd, the work group updated the resolution with no change to be applied as value sets can have an extension with a fixed binding.
- 6124 - Explain coverage of Patient + Practitioner + RelatedPerson
This will be worked on during conference calls.
- 7303 – There may be more than one diet restriction.
Existing Wording: hospitalization.dietPreference 0..1
Proposed Wording: hospitalization.dietPreference 0..*
The WG considers this reasonable. Agree to change the cardinality as noted above.
Non-Substantive
- 7304 – There may be more than one diagnosis on discharge.
Agree to change the cardinality on discharge.diagnosis. Also changed the model to constrain the discharge.diagnosis to Condition.
Pursuasive with mod.
- 7305 – admit diagnoses are important, particularly in the cases where the patient may have not be discharged yet.
Proposed Wording: hospitalization.admitDiagnosis 0..*
The WG discussed this at length and presented the structure of Encounter:
Encounter (suggested)
Reason (codeable concept) 0..1
Reason / Procedrue 0..*
Procedure 0..1
Procedure Role 0..1
Reason/Condition 0..*
Condition 0..1
Condition role 0..1 (http://hl7.org/fhir/vs/qicore-encounter.condition-role)
Hospitalization.admissionDiagnosis > Condition 0..* (cystic fibrosis)
The new property “admittingDiagnosis will be added to the hospitalization component of encounter, of type Reference (condition) with cardinality 0..*.
“The Admitting Diagnosis field is used to record the diagnosis codes as reported by the admitting practitioner. This could be different or in addition to the conditions reported as reason-condition(s) for the encounter”
Resolved change required
Pursuasive
- 7659 – Present to diagnosis
Refer to 7305
Meeting Outcomes
Actions (Include Owner, Action Item, and due date)
|
Next Meeting/Preliminary Agenda Items
|
Thursday Q4
| HL7 Patient Administration Meeting Minutes Location: Hyatt, Paris, France, Guest Room #2331 |
Date: 2015-05-14 Time: Thursday Q4 | ||
| Facilitator | Line Saele | Note taker | Alex de Leon |
| Attendee | Name | Affiliation | |
| X | Line Saele | Helse Vest IKT Norway | |
| X | <<update attendee list>> | ||
| Quorum Requirements Met (Chair + 2 members): Yes | |||
Agenda
Agenda Topics
- Wrap up
Supporting Documents
Minutes
Minutes/Conclusions Reached:
- 6929 – Need to sort out which healthcare providers are able to bill, vs those who can not.
On the Practitioner Resource – the definition of a practitioner is quite broad. Could we suggest relabeling it as Healthcare Employee and then have a sub-element for those providers who are allowed to provide medical care and are ‘billable’ and consider calling that individual a Healthcare Provider? When we are working on analytic projects, we are typically trying to assess the care that was provided by a physician (or NP, PT, OT) who bills for the service and compare their efforts(including costs associated with care) - with the patient outcomes to derive the value of the care. This definition is just too broad.
Graham. I don't see that changing the definition is going to help with this, and the concern is a particularly US centric one. I think this should be resolved by US realm profiles
The WG agrees with Graham’s comment regarding this being a jurisdictionally specific requirement that will need resolving based on local requirements. It is not part of the 80% for practitioner records. Suggest that this should be handled by a US realm entity. PA will refer to this to the US Realm task force
- 7115 – Duplicate of 6929
- 7116 – Similar to the comment posted on Patient regarding race and ethinicity.
Duplicate of 6928 and 6930.
- 7306 - 2015May core #496 - Add hospitalization.period
The encompassing encounter period may be different than the hospitalization period. The hospitalization would start on admission, but if the patient went to the ER or other department first, that may have not triggered an admission at that time.
The WG discussed the various ways that the current structures could be used to capture various implementations of the admission process that includes an encounter with a hospitalization. In the case where the ER encounter occurs prior to admission, a separate encounter could be used to capture this (with its own period) and then be linked into the admission encounter via the part-of property on the ER encounter.
- 7117 - 2015May core #176 - Distinguish contact primary type
Duplicate of 6931.
- 7307 – RelatedPerson - Consider adding birthDate dateTime to resource, just as it is in the Person resource. Ager of the individual involved in the care could be important .
WG agreed. This will be added to the relatedPerson resource.
- 7308 - gender should be renamed to administrative gender to distinguish it from a possible meaning of biological gender which for more in depth clinical uses could be a much greater set of potential value.This is done for other HL7 specifications
No change.
The valueset applied to the property is from the administrativeGender and the description of the property also highlights that this is only administrative.
From the context of a related person, there is no requirement for clinical gender representation.
- 7309 – Person - gender should be renamed to administrative gender to distinguish it from a possible meaning of biological gender which for more in depth clinical uses could be a much greater set of potential value.This is done for other HL7 specifications
No change.
The valueset applied to the property is from the administrativeGender and the description of the property also highlights that this is only administrative.
From the context of a related person, there is no requirement for clinical gender representation, as where a person is a patient, the patient is the context that applies into the clinical space.
- 7310 - - Practitioner. gender should be renamed to administrative gender to distinguish it from a possible meaning of biological gender which for more in depth clinical uses could be a much greater set of potential value.This is done for other HL7 specifications
No change.
The valueset applied to the property is from the administrativeGender and the description of the property also highlights that this is only administrative.
From the context of a practitioner, there is no requirement for clinical gender representations.
- 7311 - Practitioner- Keep birthDate data type consistent with the Person resource
The person resource will have the date of birth field changed to date (not datetime) for consistency with the other person type resources.
- 7511 - Make names consistent between Procedure and Encounter . Existing Wording:
Encounter.participant.individual vs Procedure.performer.person
After looking at the model, the individual element is set to be Practitioner or RelatedPerson. After discussion, it was decided that the Procedure.Performer.person resource field should be changed to Procedure. Performer.individual instead of applying changes to the encounter as the practitioner/related person (and patient for that matter) could be an animal, therefore individual fits better in these cases rather than person.
- 7626 - ContactPoint should provide a 'rank' attribute - ContactPoint should provide a 'rank' attribute in case different communication modalities should be attempted in a particular order. E.g., try my cell first, SMS second, followed by email or office phone.
The WG discussed this and saw value in the usage of this construct. However, after looking at it, it appears to be a change to the ContactPoint datatype, adding a positive integer element. We will need to check with the core team before applying/approving. Brian will take this to core FHIR team for further direction.
Waiting for input.
- 7607- Review example with group
Suggest re-reviewing whether structures with Element data types should be Resources or Data Types. Rule of thumb could be that if it is likely to be used in more than one resource, it should be a Resource. E.g., Patient.contact -- why is this an Element, when Patient.address is a Data Type? Couldn't Patient.contact be generalized when used in other settings, like for a Provider (e.g., escalation needed for sending alerts, etc.)? Also, profiling such structures requires profiling the entire containing Resource, which seems suboptimal.
The example as provided of Patient.contact is actually different to the contact that is on an organization, hencewould not be able to re-use the type, even though the concept is very close to the same.
Waiting for input.
The WG looked at the remaining ones. There are 52 remaining tracker items (ballot comments) for FHIR DSTU 1 which will be handled in the telecons.
The WG then discussed the telecom times. It was suggested to keep the Monday time until July 1 then switch to Tues for July and August then back to Monday from Sept 1st.
Based on times that key members would be on holiday, the best time for the first WGM is May 26 (Tuesday) then back to Mondays starting June 1st, and making the meetings 1.5 hours until the FHIR ballot reconciliations are complete.
Brian makes a motion to adjourn. Peter seconds
Vote: 3/0/0
Meeting Outcomes
Actions (Include Owner, Action Item, and due date)
|
Next Meeting/Preliminary Agenda Items
|
- Go To Monday Minutes
- Go To Tuesday Minutes
- Go To Wednesday Minutes
- Go To Thursday Minutes
- Return to PA May 2015 WGM
© 2007-2015 Health Level Seven® International. All rights reserved.
