2015-07-14 PA Call Minutes
Contents
Patient Administration Call
Meeting Information
| PA Work Group Meeting
Minutes |
Date: Tuesday, July 14, 2015
| ||
| Facilitator | Irma Jongeneel | Scribe | Alex de Leon |
| Attendee | Name | Affiliation | |
| X | Irma Jongeneel | HL7 The Netherlands | |
| X | Alexander de Leon | Kaiser Permanente, USA | |
| X | Iryna Roy | Gevity, Canada | |
| X | Brian Postlethwaite | Health Connex, Australia | |
| X | Peter Bernhardt | Relay Health, USA | |
Agenda
Agenda Topics
- Review FHIR DSTU2 Ballot Items
- Encounter v3 DSU ballot. May have to reballot again. Send NIB by this Sunday.
- Secondary diagnosis left over from last call. May handle this call depending on the time. Otherwise postpone
Supporting Documents
Minutes
FHIR DSTU2 Ballot Items
The WG continued working on the DSTU2 ballot items as entered into the GForge repository:
- 5986 - Patient.gender should be CodeableConcept . It would be better for Patient.gender to be a CodeableConcept, rather than a code. The CodeableConcept allows for translation and mapping to other value sets.
The WG reviewed the structure. Male/Female/Other/Unknown. Administrative Gender. After review the WG suggested a vote to keep the code for the core standard since this is administrative gender (as opposed to clinical gender) with the idea that this can be extended if needed by a specific implementation.
Brian moved to keep this as a code. Peter seconded.
Discussion: none
Vote (for/against/abstain): 4/0/0
- 8206 - Person.gender Paitent.gender (administrative gender coding).
The WG considered this similar to the above item, with the exception of the description of the codes. The WG considered this and decided to leave the text as it is more descriptive and clear (e.g. “unknown” rather than “u”).
Brian moved to keep this as a code. Peter seconded.
Discussion: none
Vote (for/against/abstain): 4/0/0
- 6168 - change Organization.partOf cardinality to 0..* . what `s the idea behind setting Practitioner.practitionerRole.managingOrganization carnality to 0..1, would core spec supposed to be as loose as enough, how to represent polyhierarchy relationship?
The WG reviewed this and decided that for these cases the practitioner will just have more role values.
The period and the healthcare service that are also linked in this sub-component indicate when the practitioner is linked to the various organizations.
The wg voted on this answer.
Brian moved to keep this as a code. Peter seconded.
Discussion: none
Vote (for/against/abstain): 4/0/0
- 6249 - Why do encounters point to episoide of care instead of episode of care pointng to encounter. "The primary difference between the EpisodeOfCare and the Encounter is that the Encounter records the details of an activity directly relating to the patient, while the EpisodeOfCare is the container that can link a series of Encounters together for problems/issues." Container to me implies that this resource is pointing to 1 or more other resources. See how is used when defining "contained resources""Internal "contained references" "references - references to other resources packaged inside the source resource" I Propose either changing the language to "... a series of Encounters together for problems/issues are related to each other by there common link to an Episode of care. (search episode with a reverse include to list them all) or.. keep the text and reverse the linkage make the encounter the leaf node.
The WG considered this and came to the following conclusion:
Resources typically point to the thing that exists first, and in this case, the EpizodeOfCare is oin-going and therefore created first. Ecnounters are created, which point to the existing episode. You don’t want to have to update the pisode every time an enw encounter is created.
In a case where an encounter is in progress, and a new EpisodeOfCare is identified, then this will be saved and the encounter recorded aggaist this, as will al future enounters (if the link was the other way, every time a new encounter is created, the EpisodeOfCare would need to be updated too)
Brian moved to keep this as a code. Peter seconded.
Discussion: none
Vote (for/against/abstain): 4/0/0
- 6197 - Add appointment creation date. Add date when the appointment was created. Important for tracking waitlist.
WG Response. Appointments are really the concrete result after finishing being on a waiting list. Currently don't have a concept specifically covering a wait list (unless we profile a specific list resource, so not really). With that said, we do have the Meta.LastModifedDate and the whole history of the resource (when used). So could track the age of appointments (and how many updates it gets).
The WG consider this needing more discussion.
- 6957 - Change team member cardinalities Existing Wording: EpisodeOfCare.CareTeam with cardinality 0..* and EpisodeOfCare.CareTeam.member with cardinality 0..1. Proposed Wording: EpisodeOfCare.CareTeam.member with cardinality 0..*
Looks like an episodeOfCare can have zero to many care teams - 0..* (e.g. admitted patient is being care for by the respiratory team and the orthopaedic team). However, there is a maximum of one member (0..1)from each team. Suggest EpisodeOfCare.CareTeam.member with cardinality 0..*
Brian suggested: This wasn’t designed for managing different types of teams, it was for managing different types of tem members and the roles that they will have within this episode. Other teams are probable going to be interested in a different episode of care. Interested in further feedback from others (will discuss in PA)
The WG considered this and decided that the concept will be changed to EpisodeOfCare.CareTeamMember and EpisodeOfCare.CareTeamMember.Individual for now. The WG will solicit additional feedback.
Action Item. Follow up is needed.
- 7478 - Neonate birth date/time. Patient.birthDate has been changed from a DateTime to a Date. That's fine, but then how should a neonate's birthdate/time be captured? With an observation?
When you come to the birthdate for the individual, but if you look at the detail, there is a standard extension to include time for specific implementation needs.
The WG considered this a good response to the item.
Meeting Outcomes
|
|
Next Meeting/Preliminary Agenda Items
|
Return to PA Main Page © 2015 Health Level Seven® International. All rights reserved.
