2017-12-05 PA Call Minutes

From HL7Wiki
Jump to navigation Jump to search

Patient Administration Call

Meeting Information

PA Work Group Conference Call

Local numbers sent to list

Meeting Information

PA Work Group Conference Call

Gotomeeting - see pafm@lists.hl7.org
HL7 Conference Call phone number

Date: Tuesday, December 05, 2017

Time: 12:00 PM (US Pacific Time, GMT -7)
Quorum Met (Chair+2, Yes/No)? Yes

Facilitator Line Saele Scribe Sam Mater
Attendee Name Affiliation
X Brian Postlethwaite Telstra Health, AU
X Sam Mater Epic
X Line Saele Nasjonal IKT HF, NO
X Alexander Henket Nictiz, NL
X Louis Bedor US
X Drew Torres Cerner, US
X Iryna Roy Gevity, Canada
X Cooper Thompson Epic, US
X Dan Chaput OMC, US


Agenda Topics
Agenda – 2 tracker items: https://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_item_id=14154
Other tracker items

Supporting Documents


14024 - Patient.contact and RelatedPerson need a better connection

After last week, we decided that further consideration was needed for contact linking to related person.

Alexander tried to convince it was a good idea to link to related person, we decided to create a core extension for related person instead of a core element. We wanted to discuss more what to do with inline properties of contact if we use this core extension.

Brian: What we've got looks okay. There was another tracker for RelatedPerson.relationship cardinality tracker [14225]. When creating the standard extension, we still expect the fields of patient.contact to be populated with relevant data that is also on relatedPerson (enabling systems displaying patient.contact to remain simple, and no need to resolve the reference to get the information).

There is some confusion between person and relatedPerson.

Alexander: Don't want to have to recreate someone like 'Mother' as a Person just because we want to make her a contact.

Brian: Person resource doesn't help because we can't point it at patient.contact.

Alexander: Why asking for this--because any person who is a contact to a patient is likely not just a person, but is a relatedPerson, which is why it makes more sense to make an extension towards relatedPerson. However, not opposed to allowing the reference to be a choice between Person and RelatedPerson. Argues that if we don't have this link, we'll have to recreate data extraneously.

Brian: Given the guidance that we don’t want to have anything pointing at person, that leaves us with just RelatedPerson. The suggestion as stands (without the option of choosing person) looks good to me.

Alexander: It looks good to me, but if Iryna needs it extended to Person, that would be okay.

Brian: Guidance says there should be no resources pointing at Person, so we shouldn't do this. One way from Person to everything else, rather than the other way around.

Alexander: This is the other way around from V3.

Brian: Yes, In V3 it's a core demographic, in FHIR it's a linkage (between different records that are the same person)

Alexander: V3 is role pointing at entity, not the other way around.

Proposal: Create a standard extension on Patient.contact to reference RelatedPerson that is equivalent to.

This would still expect that the relevant 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, and no need to resolve the reference to get the information).

Mover/Seconder: For-Against-Abstain:
Brian Postlethwaite/Alexander Henket: 7-0-1
We find this persuasive with mod.

14154 - Searching a Patient by Identifier Type

[Description: It would be beneficial to add a standard search criteria for Identifier Type. For example to allow for a search for a patient with MRN 123 using Identifier.type= http://hl7.org/fhir/v2/0203 | MR with a value of xyz.]

Brian: It makes sense, but is this something we would do typically?

Cooper: This seems useful in a lot of places. Do we want to suggest extending token data type a little to add another option?

Drew: Why doesn't searching the system get you that?

Cooper: System is part of token, but MRN is a good example, can have ~10 MRNs, want to find all patients with MRN of 123 regardless of system. Not good if searching over SSN or something. This is good for patient lookup.

Drew: This would return records from multiple systems.

Looking for clarification on this request, "Using this query would return records from multiple systems, is that what would be expected? Or were you planning on performing some type of PMI/Patient match query? Have you looked at the $match operation on patient? (this would also depend on the complexity on the servers implementation also) Is this constrained to just patient, or more generic for consideration at the core search on identifiers?
Brian: Should we leave this tracker with a request for more info?

Drew: Yes, getting clarification on what they want to do.

Status is now Waiting for Input.

Alexander: Simpler way to query based on type instead of knowing the system. Is this what match does?

Brian: Yes. Looking for any MRN value with this, goes across systems, could be likely to get the wrong patient back, so they'll likely need something else. The confidence on a PMI match is lower because we don’t know if the right one.

Cooper: Since we don't dictate the behavior of what a server does, $match might not do exactly what they want. Should add guidance to the operation.

14118 - Why does FHIR use codes that have been deprecated in V2.3?


Vocab call on 11/6 discussed this issue. See the tracker for more info.

Alexander: If a valueset contains values that shouldn’t be used in a version, that sounds like a tooling issue for Grahame.

Version notes say that some codes were removed after v2.3 ex. Some codesets can have them, but maybe as an extension shouldn't?

Brian: Should this be something we chat with Grahame about?

Line: Yes.

Action item: Brian to discuss with Grahame if this a tooling issue.
Status is now Waiting for Input.

PA thinks it's a reasonable request that our valuesets should exclude deprecated terms from the codeSystems.

14112 - Patient.communication should have way to designate if the preferred language is written versus verbal


Alexander: Like V3.

Drew: We [Cerner] don't record if the preferred language is written or spoken.

Cooper: Our use case might be: if they only speak a language, but can't read or write it, we don’t want to print them materials with instructions to take home in a language they can't read.

Alexander: Illiteracy isn't really handled either. It's not language dependent, but a state of being.

Drew: Would this be an observation?

Alexander: Still feels like part of communication in FHIR. We would probably extend patient in FHIR if the need comes up again.

Drew: Administrative task wouldn't document illiteracy, would be more of a clinical thing.

Alexander: If someone is illiterate, you'd want that to be part of where ever the patient goes (part of the Patient resource). Have not dealt with this need in FHIR yet.

Cooper: Makes sense, but we [Epic] also don't document this.

Alexander: If you care about proficiency for written in English, isn't that the same as caring about illiteracy in any language?

Cooper: In theory, yes.

Brian: Could have extension--

Drew: Or text

Brian: --that says they are illiterate, and then have no language.

Louis? Illiteracy the ability to read or write--and there are some languages that are only spoken. You can be "illiterate".

Alexander: This is not distinguishing because in that case, everyone in the language would be considered illiterate. Maybe we should ignore this concept and go back to what's in the tracker item. Proficiency codes / proficiency modes? Like V3

Drew: This isn't proficiency though.

Brian: It's not a first class property, so it's in extension territory. Should this be a standard extension?

Drew: Sounds like there's a use case for it, but primarily is Epic.

Alexander: Anyone who doesn't read the extension would see repetition of languages with no distinguishing features-- is this okay?

Drew: doesn't have to be separate from the communication

Alexander: Make it a modifying extension would signal that you can't understand the information well without understanding the extension.

Brian: If you don't understand the extension you shouldn't look at the resource or the property. If you put the extension on the preferred flag, it wouldn’t matter.

Cooper: Preferred is still a little separate from what we are discussing.

Drew: Right, this should be an extension on the communication.

Brian: That's not what's in the tracker.

Cooper: Would prefer it not to be on the "preferred", but some kind of sibling.

Alexander: It's an extension of language--written English versus spoken English.

Brian: preferred written or preferred spoken.

Cooper: We [Epic] have one overall preferred language, and then we have language for care, which is verbal.

Brian: Not an extension on language, extension on communication or preferred

Cooper: Communication, it's like a use, what way is this communication is used.

Alexander: That sounds right to me too.

Brian: With multiple uses, which one is the preferred use for written?

Can have multiple preferred communications. But if a system doesn't understand the extension, it won't differentiate.

Drew: Should be on backbone of communication as it's an attribute of the communication.

Alexander: If a language is both written a verbal, you can repeat an extension.

Brian: Is it preferred, or is it just able to? If we take preferred out of the picture is it still relevant?

Drew: yes.

Dan: With the Healthcare directory use of communication element, we added a proficiency and have found three valuesets that are used to describe proficiency. So they kind of go hand in hand because you might be proficient in a few, you might prefer a couple. There's a two pronged item. For them, it's Practitioner.communication.

Brian: This should also consider if proficiency is this concept.

We'll leave the tracker here, and come back to it at a future date.

Next Meeting/Preliminary Agenda Items
  • Next telecom meeting: Tuesday 12. Dec 2017


Return to PA Main Page © 2017 Health Level Seven® International. All rights reserved.