| PA Work Group Conference Call
Minutes
GoToMeeting
Local numbers sent to list
Meeting Information
| PA Work Group Conference Call
Minutes
Gotomeeting - see pafm@lists.hl7.org
HL7 Conference Call phone number
|
Date: Tuesday, November 28, 2017
Time: 12:00 PM (US Pacific Time, GMT -7)
Quorum Met (Chair+2, Yes/No)? Yes
|
| Facilitator
|
Irma Jongeneel
|
Scribe
|
Sam Mater
|
|
|
| Attendee
|
Name
|
Affiliation
|
| X
|
Brian Postlethwaite
|
Telstra Health, AU
|
| X
|
Sam Mater
|
Epic
|
| X
|
Irma Jongeneel
|
VZVZ, NL
|
| X
|
Alexander Henket
|
Nictiz, NL
|
| X
|
Louis Bedor
|
US
|
| X
|
Michelle Miller
|
Cerner, US
|
| X
|
Simone Heckmann
|
Health Comm GmbH
|
Agenda
Agenda Topics
Agenda – 2 tracker items:
- https://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_item_id=14224&start=0
- https://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_item_id=14024&start=0
Other items (if there’s time)?
Irma - Implementation Guide for Provider Directory - not enough progress has been made
Simone - change request, structuring the encounter resource
Supporting Documents
Minutes
14224 - Patient.generalPractitioner should point to PractitionerRole (too)
10 minute discussion
Alexander: Want to convey a general practitioner as part of an organization to the patient. Currently patient allows Practitioner OR Organization, but can only tie the two using PractitionerRole. If we connect to Practitioner, we do not know which practice, and if we connect to Organization, we do not know which practitioner we have.
Simone: it could be a good idea to go through all the PA resources and check where there is a reference to Practitioner, if it makes sense to also add PractitionerRole, so we're not running into this problem elsewhere.
General consensus is that these are both good ideas.
Proposal: Add PractitionerRole as an alternative reference in the generalPractitioner reference on Patient. This will have to go through community consultations as Patient is a level 5 resource that is about to go normative.
Question: should we remove Practitioner? A: no.
Mover/Seconder: For-Against-Abstain:
Alexander Henket/Simone Heckmann: 6-0-0
We find this persuasive.
14024 - Patient.contact and RelatedPerson need better connection
30 minute discussion
Within patient is patient context. Within that is data inline, that in some systems is kept separately in related person. When a relatedPerson is also a contact, you'll need to duplicate data in patient contact, because there is not reference between contact and relatedPerson. This tracker is about two things, 1. If someone is both mother and guardian, relatedPerson is mission the option to have multiple relationships, and 2. Should there be an option to have contact information not be inline, and instead exist as a reference to a relatedPerson.
This discussion should be about should we have the option to have contact information not be inline, but have a reference to relatedPerson.
Simone: Why was Patient originally built this way?
Alexander: More systems do not keep separate person registries, only have information comparable to what is modeled right now in the patient.
Irma: Some systems have maybe just a name or a phone number.
Simone: Usually we just "contain" a resource.
Brian: But then patient would have to reference relatedPerson, instead of the other way around.
Detail that should go with the patient everywhere, whereas there can be fifty or sixty related persons used in a variety of ways.
Simone: If we flipped the direction of the link (replacing contact info), we could also put the type of the relationship with the reference, instead of on the related person, therefore allowing multiple relationships for one
Alexander: still wants contact and relatedPerson as separate elements.
Brian: We should look at changing cardinality of relationship
Louis: Why are we changing cardinality instead of changing list of possible types?
Simone: It would explode the table (it would certainly create a large number of possible values).
Idea floated that we trim down the valueSets for both patient.contact.relationship (v2 Contact Role) and relatedPerson.relationship, so that contact relationships are not in the relatedPerson.relationship valueset, and we are left with more familial values. If there is one relatedPerson with multiple relationships, what do we do?
Alexander: If related persons are contacts, why not make that explicit?
No patient extension exists for this currently. This is another option. Include an extension on patient to point to the relatedPerson. However, the extension doesn't address the need to duplicate information, if there are systems that don't understand the extension.
Patient.contact cannot be referenced by other things. It has to be a relatedPerson resource to be referenced elsewhere.
Michelle: If we use an extension, then it's more critical for us to up the cardinality of relationship on relatedPerson. If we keep them separate and simplify the valuesets, then we can use contact and a relatedPerson extension to give different information.
Brian: no objections to making the cardinality multiple, but thinks it should be separated from other issues, makes a motion for this which Alexander seconds. Alexander to create a new tracker item specifically for this.
14225 - RelatedPerson relationship 0..1 => 0..*
https://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_item_id=14225&start=0
Mover/Seconder: For-Against-Abstain:
Brian Postlethwaite/Alexander Henket: 6-0-0
We find this persuasive.
We are left with: Should relatedPerson be an option under patient.contact?
Simplest thing is to add an extension on contact to point to relatedPerson. Would we still expect contact to be populated as it is today, or would you be allowed to omit that part and expect system to read relatedPerson for these details?
Brian: As a user, would rather that this information is duplicated. Doesn't mean it has to be stored in a system this way, moves to make this a standard extension
Proposal: "Create a standard extension on patient.contact to reference the relatedPerson that his is equivalent to. This would still expect that the fields of the patient.contact would be populated with the relevant data that is also on the referenced relatedPerson (enabling systems displaying patient.contact to remain simple)."
Questions:
Michelle: Do we want to differentiate between contact relationship and relatedPerson relationship? Or should we put all relationships in both? Contact.relationship can feel a little different than demographics.
Irma: Could this change in cardinality expose information that shouldn't be privy to: i.e. that the mother is also the billing contact?
We will leave this discussion open rather than voting, to be resumed in two weeks.
Mover/Seconder: For-Against-Abstain:
Brian Postlethwaite/Alexander Henket: motion was shelved.
|
