2017-09-13 PA WGM Minutes

From HL7Wiki
Jump to navigation Jump to search

Patient Administration Work Group Minutes - Wednesday September 13, 2017

Wednesday Q1

HL7 Patient Administration Meeting Minutes

Location: Hyatt Regency, La Jolla, CA, Guest Room 311

Date: 2017-09-13
Time: Wednesday Q1
Facilitator Line Saele Scribe Alex de Leon
Attendee Name Affiliation
X Line Saele Helse Vest IKT Norway
X Brian Postlethwaite Telstra Health
X Alex de Leon Kaiser Permanente
X
Quorum Requirements Met (Chair + 2 members): Yes

Agenda

Agenda Topics

Supporting Documents

Minutes

Minutes/Conclusions Reached:
Introductions
HcDIR FHIR Relatioshios v2.5 << Insert PPT here>> The WG reviewed and discussed the Healthcare Directory effort presented by ONC-FHA Federal Healthcare Architecture (consortium of US government agencies. The WG reviewed the HcDir Master Data Elements list v2 8-7-17 <<Insert spreadsheet here>> Resources were reviewed for the GcDir IG
Individuals Entities/Place - Practitioner, organization, location, network,
Relationshipts - Pracioner Role, Care Team, Organization Role
Services - Healthcare Service
Things – Endpoint Prodcut/Plan Validation Restriction (Backbone Element?)
Structural – Structure Definition
Vocabulary -
Messaging-
The new resources proposed to support this effort: • Organization Role • Validation • ProductPlan
The queries can “pull down” a massive amount of information.
Craft a query for a subset (e.g. 50 miles around Pittsburgh, etc.). Then subsequent queries will pull down additions or changes.
The WG had questions around the new resources being proposed. OrganizationRole,

The WG discussed that this will probably need to be discussed within the joint meeting with Financial Management.

<<insert PSS here>>
The WG discussed the timelines and scope moving forward and getting these efforts completed.
Brian noted that the dates for this project and the R4 of FHIR could align. It would make sense to perhaps change the goal of this project from balloting STU3 today and waiting and aligning with R4. He suggested that this be done to assure more active usage of the implementation guide. Due to the addition of the 3 new resources noted above, it may be better to

Robert Dieterle stated that he is charged to have this done within STU3, based on contracts. He was quite adamant that this IG would need to be an STU before the year end.

For Comment ballot




Meeting Outcomes

Actions (Include Owner, Action Item, and due date)
  • <<consolidate action items>>
Next Meeting/Preliminary Agenda Items
  • .

Wednesday Q2

HL7 Patient Administration Meeting Minutes

Location: Hyatt Regency, La Jolla, CA, Guest Room 311

Date: 2017-09-13
Time: Wednesday Q2
Facilitator Brian Postlethwaite Scribe Alex de Leon
Attendee Name Affiliation
X Line Saele Helse Vest IKT Norway
X << Update Attendees >>
Quorum Requirements Met (Chair + 2 members): Yes

Agenda

Agenda Topics

  1. << update agenda topics >>

Supporting Documents

Minutes

Minutes/Conclusions Reached:
Introductions

The WG reviewed the tracker items.

  1. 13786 - Summary: Clarify Practitioner classification extension (and PractitionerRole.specialty)

The wg discussed the Classification, Qualifications and how they relate, either to Practitioner directly or to PractitionerRole.

http://hl7.org/fhir//extension-practitioner-classification.html
http://hl7.org/fhir/practitioner.html
http://hl7.org/fhir/practitionerrole.html

PractitionerRole – Specialty

Cooper moves to remove the classification extention from the practitioner resource because now specialty on the PractitionerRole. Irma seconds.
Discussion:
Vote (for/against/abstain): 18/0/0

Stephen asked about people who are not practitioners but might need to be defined. He has a problem defining this with the current resources.

  1. 13517 -Summary: PractitionerRole.active has the wrong definition

Brian moves/Irma seconds to correct the definition. Discussion: Stephen asked about the disposition: “This text as described was indeed copied from Practioner and will be clarified that it only applies to the role, to permit the marking of a practitioner role resource not to be used where dates are not available to perform that function (as guidance only).” Due to Stephen’s objection, the section “not to be used where dates are not available to perform that function” was removed. Vote (for/against/abstain): 17/0/0

  1. 12940 - Summary: PractitionerRole should leverage existing security role valueset

The WG reviewd the value set:
http://build.fhir.org/valueset-security-role-type.html

The WG reviewed and considered these codes not to be very relevant to the concept. Some are event related and patient related rather than role based based on what the provider may act as.

The current set is very limited and should be expanded.
Code Display Definition doctor Doctor A qualified/registered medical practitioner nurse Nurse A practitoner with nursing experience that may be qualified/registered pharmacist Pharmacist A qualified/registered/licensed pharmacist researcher Researcher A practitioner that may perform research teacher Teacher/educator Someone who is able to provide educational services ict ICT professional Someone who is qualified in Information and Communication Technologies
The WG considered the value sets participation and practitioner role in v3. It was decided to update the example valueset to include the codes from http://snomed.info/sct where concept is-a 223366009 (Healthcare professional)

Brian moves to make this non persuasive with modificatinos. Irma seconds.
Discussion: None
Vote (for/against/abstain): 15/0/0

Meeting Outcomes

Actions (Include Owner, Action Item, and due date)
  • <<consolidate action items>>
Next Meeting/Preliminary Agenda Items
  • .

Wednesday Q3

HL7 Patient Administration Meeting Minutes

Location: Hyatt Regency, La Jolla, CA, Guest Room 311

Date: 2017-09-13
Time: Wednesday Q3
Facilitator Note taker Alex de Leon
Attendee Name Affiliation
X Line Saele Helse Vest IKT Norway
X << Update Attendees list >>
Quorum Requirements Met (Chair + 2 members): Yes

Agenda

Agenda Topics

  1. << update agenda topics >>

Supporting Documents

Minutes

Minutes/Conclusions Reached:

The WG will respond to that this concept can be expressed in the encounter class and the value set for that is extensible. The WG recommends using this. If the submitter wants to make this part of the standard set, a tracker item can be created by the submiter

Line will remind Brian to reply with the WGs recommendation.
During the discussion, the submitter of the email arrived.
In speaking to the submitter, he agreed that the updated value set for this be part of the standard. He will put this through harmonization.

  1. 9238 -

The status of the patient’s employment at the time of admission. Sample values include: Full-time employment, part-time employment, unemployed.

There is an upcoming project that will be dealing with employment related information post STU3. So we recommend using a local extension until that project is complete. However, the WG discussed its appropriateness and recommends this would be more appropriate as a social history observation using SNOMED-CT Parent code 302768007 codes for this. This can be found in SNOMED as an observation with category Social-history.

BBrian moves to make this not persuasive with mod. Alex seconds. Discussion: None Vote (for/against/abstain): 7/0/2

  1. 13364 – Encounter lacks a correct mapping for PV1-10

V2 defines a "Hospital Service" field (PV1-10) that has no adequate representation FHIR. The mappings page (http://hl7.org/fhir/encounter-mappings.html) suggests that this segment might map to Encounter.serviceProvider, but the semantics are entirely different (as the mapping page acknowledges by saying they are "slightly out of alignment"). The issue is that they have different semantics and datatypes:

  • Encounter.serviceProvider conveys "The custodian organization of this Encounter record", and its type is a Reference(Organization).
  • PV1-10 conveys a "the treatment or type of surgery", and its type is a Coded Value (v2 IS datatype).

Now, V2 segment may be confusingly named — but the thing that it conveys (something like: what kind of service was this visit scheduled to provide) is important and missing from the FHIR Encounter resource. I would propose: 1. Remove the current (misleading) mapping from PV1-10 to Encounter.serviceProvider 2. Define a new element called encounter.service (0..1) with a type of CodeableConcept with an example binding (maybe to SNOMED CT procedure codes? Perhaps there's something more appropriate) and a definition like "type of treatment, surgery, or service that this Encounter was scheduled to provide, if any".


The WG discussed this issue and determined that there was a need for the addition of a specialtyType element on the Encounter resources. This would be consistent with the Appointment.ServiceType which maps forward. This new property will map to PV1-10, As the binding is example only, it can be replaced as required (for instance by the procedure codes which might be relevant in some situations. Encounter.Type property, which was considered, is not related to the servicetype being performed, in the same way that the appointment.appointmentType isn’t a service type.

Brian moves this disposition. Alex seconds. Discussion: Drew quesionted where this leaves procedure, diagnosis as ambigious. Vote (for/against/abstain): 9/0/0 THe WG, trying to save time tried to address some of the Wrap UP items. PBX metrix look good. Work group health looks good. 


Meeting Outcomes

Actions (Include Owner, Action Item, and due date)
  • << Consolidate Action Items >>
Next Meeting/Preliminary Agenda Items
  • .

Wednesday Q4

HL7 Patient Administration Meeting Minutes

Location: Hyatt Regency, La Jolla, CA, Guest Room 311

Date: 2017-09-13
Time: Wednesday Q4
Facilitator Line Saele Note taker Alex de Leon
Attendee Name Affiliation
X Line Saele Helse Vest IKT Norway
Quorum Requirements Met (Chair + 2 members): Yes

Agenda

Agenda Topics

  1. <<update agenda topics>>

Supporting Documents

Minutes

Minutes/Conclusions Reached:
Introduction

  1. 9993 - Summary: Patient LinkType Negation

In reviewing an internal use I see a need for considering how a system may express the assertion that two patient records within its control are NOT the same person. Currently the link type enumeration only allows for qualifying an affirmative link.
I propose adding a new entry to http://hl7.org/fhir/link-type that expresses the negation use case. code: negated
display: Negated
definition: The system has confirmed that the referenced patient record does not belong to the same person. This may be used to correct an erroneously created affirmative link and will enable version-aware systems to correctly determine the current status of a link relationship.

The WG discussed the value of this against the risk of relaying private information. IN addition, the WG discussed the various ways in which this can be represented in the FHIR structure. Do we put a flag on the patient, or make it part of the patient.link element. Eventually 4 different methods of communicating this were discussed.

After much further discussion, the WG decided that the “known non duplicate” situation should be handled operationally, perhaps with a merge FHIR function later. The concept and need was clear and the value was acknowledged, therefore the recommendation is to disposition this tracker item as non-persuasive/considered for future use.
Brian moved to disposition this as non persuasive with the disposition in the tracker item and Drew secondended.
Discussion: None Vote (for/against/abstain): 7/0/0

  1. 13617 - Summary: In Patient some data data elements are described using plural

The following definitions should be singular

  • Patient.address: "An address for..."
  • Patient.communication: "A language..."

See #6327

Cooper moved to disposition this as persuasive and change the definitions to singular. Drew seconded.
Discussion: None Vote (for/against/abstain): 7/0/0

  1. 13843 - Summary: Add genderIdentity property to Patient resource

I propose adding a genderIdentity property to the Patient resource (possibly as a standard extension, pending discussion).
We could potentially consider also adding preferredPronouns to communicate what pronouns the patient wants to be used when addressing them (also possibly as a standard extension).
Gender identity is used by staff throughout organizations to know how to address patients, so having that front-and-center in patient seems to make more sense than including it in Observation (which has been proposed in the past).
A proposed valueset for genderIdentity would include:
Female
Male
Transgender Female / Male-to-Female
Transgender Male / Female-to-Male
Other
Choose not to disclose

The WG discussed this and it difference from administrative sex and clinical sex.
A standard extension will be added for patient to cover the question as to how a patient would prefer to be addressed. (This is distinct to administrative gender, clinical gender or birth sex) genderIdentity CodeableConcept 0..1 "The term that the patient declares that they would like to be addressed" The binding for this will be only an example, and contains values similar to those found in administrative gender, plus genderqueer, declined to answer, among others that may be defined by local needs.
Cooper moved and Drew seconded the motion to make this persuasive . Discussion: None Vote (for/against/abstain):












===Meeting Outcomes===

Actions (Include Owner, Action Item, and due date)
  • <<consolidate action items>>
Next Meeting/Preliminary Agenda Items
  • .

Navigation

© 2007-2017 Health Level Seven® International. All rights reserved.