2018-05-14 PA WGM Minutes

Return to: WGM Minutes > 2018 > May Cologne

Patient Administration Work Group Minutes - May 14, 2018

Monday Q1

HL7 Patient Administration Meeting Minutes Location: Maritime Hotel, Cologne, Salon 20 Fulda		Date: 2018-01-29 Time: Monday Q1
Facilitator	Line Saele	Scribe	Alex de Leon
Attendee	Name	Affiliation
X	Irma Jongeneel	HL7 Netherlands
X	Alex de Leon	Kaiser Permanente, USA
X	Line Saele	HL7 Norway
X	Brian Postlethwaite	Telstra Health, Australia
X	Cooper Thompson	EPIC, USA
X	Christian Hay	GS1, Switzerland
X	Bidyut Parruck	Interface ED, USA
X	Simone Heckmann	HL7 Germany
X	Hans Buitendyjk	Cerner, USA
X	Andrew Torres	Cerner, USA
X	Kathy Pickering	Cerner
Quorum Requirements Met (Chair + 2 members): Yes

Agenda

Agenda Topics
Welcome and introductions Joint meeting with Financial Management - FHIR

• Invoice draft review
• ChargeItemDefintion draft review
• ProductPlan review
• Payment/Adjustment resource?

Supporting Documents

• PA mission & charter
  
• PA decision making practice
• PA 3-year work plan
  
• [SWOT
  ===Minutes===

Plenery

Meeting Outcomes

Actions (Include Owner, Action Item, and due date) Action:

Next Meeting/Preliminary Agenda Items .

Monday Q2

HL7 Patient Administration Meeting Minutes Location: Hilton New Orleans Riverside, Durham Conference Room		Date: 2018-01-29 Time: Monday Q2
Facilitator	Brian Postlethwaite	Scribe	Alex de Leon
Attendee	Name	Affiliation
X	Brian Postlethwaite	Telstra Health, Australia
X	Irma Jongeneel	HL7 Netherlands
X	Alex de Leon	Kaiser Permanente, USA
X	Line Saele	HL7 Norway
X	Cooper Thompson	EPIC, USA
X	Kathy Pickering	Cerner, USA
X	Christian Hay	GS1, Switzerland
X	Simone Heckmann	HL7 Germany
X	Bidyut Parruck	Interface ED, USA
Quorum Requirements Met (Chair +2 members): Yes

Agenda

Agenda Topics

1. FHIR New Proposals
2. Feedback from Connectathon

Supporting Documents

Minutes

Minutes/Conclusions Reached:
Introductions

Brian asked if there were any proposals for new resources.

Simone spoke about continuing to define the ChargeItemDefinition resource as a new resource. She believes she can craft a proposal, but it will be very generic. This resource will be the place where the “rules” of how to process the ChargeItem for billing. May be part of the Catalog profile on Composition.
Brian asked whether PA should retain “ownership” of this (as we have with ChargeItem) or not. The group decided it made no sense to separate the two since they essentially cover the same subject.

Invoice resource – Draft created for review this WGM
ONC/CMS eLTSS Presentation for Thurs Q4 (from Evelyn This is scheduled for joint meeting Thursday Q4. The WG reviewed the slide presentation sent by Evelyn Gallegos. May need to add EpisodeOfCare. ChargeItemDefinition and HealthcareService may be relevant.

Connectathon feedback. Brian as our FHIR facilitator reported back that he ran 2 tracks: Patient Match and Provider Directory. There was little participation in both, but EPIC (Cooper) implemented Patient Match. There was one other participant for Provider Directory. Brian noted that even though this other participant built a model for resource relationships and process, they came up with the same as the Australian model. Brian showed the model.

Cooper reported back on the Scheduling track for the connectathon. While there were few actual connections, there were many discussions regarding scheduling. One discussion had to do with subscription style scheduling to reduce having to “pull down” entire schedule slots to determine scheduling. Subscription on schedule, then search for slots in update schedule (via operation). So only when changes are done will subscriber receive change.

Alex reported back that Kaiser Permanente is starting to “ramp up” their interest in FHIR. This WGM, Kaiser Permanente participated in the Patient Track, collaborating with QRiva on Saturday to run through the scenarios presented (Register, Read, Update and Delete a patient [CRUD]), then version read a patient and search. On Sunday, the creation of an patient ID as a client, then as a server was tested with QRiva through the HL7-sanctioned Aegis Touchstone FHIR server to validate compliance. All tests passed successfully.

Meeting Outcomes

Actions (Include Owner, Action Item, and due date) None

Next Meeting/Preliminary Agenda Items .

Monday Q3

HL7 Patient Administration Meeting Minutes Location: Hilton New Orleans Riverside, Durham Conference Room		Date: 2018-01-29 Time: Monday Q3
Facilitator	Line Saele	Scribe	Alex de Leon
Attendee	Name	Affiliation
X	Irma Jongeneel	HL7 Netherlands
X	Line Saele	HL7 Norway
X	Brian Postlethwaite	Telstra Health, Australia
X	Alex de Leon	Kaiser Permanente, USA
X	Toril Reite	HL7 Norway
X	Cooper Thompson	EPIC, USA
X	Oyvind Aassve	HL7 Norway
X	Michelle Miller	Cerner
X	Tricia Chitwood	Cerner, USA
Quorum Requirements Met (Chair + 2 members): Yes

Agenda

Agenda Topics

1. FHIR Ballot Reconciliation

Supporting Documents

• 14333 - Provide more clarity between administrativeGender, sex, and gender identity

• 14154 - Searching a patient by Identifier Type

• 14099 - Guidance on how to request a new identifier (e.g. MRN)

• 14341 - Replace "hermaphrodite" with "intersex"

• 14174 - herd should be able to reference the owner

Minutes

Minutes/Conclusions Reached:
Introductions

14866 - Multiple birth order should be a positive integer (not an integer) - 2018-Jan Core #206
The WGreviewed the tacker item and considered this reasonable.

1. 14719 - Patient Gender representation is lacking
   

Existing Wording: In addition, to this gender, other kinds of gender may be represented
Proposed Wording: Add link to US Core Birth Sex extension, and develop guidance for sending Clinical Gender
--- The current description notes "other types of Patient Gender may be represented but gives no guidance" Add link to US birth Sex extension, Add link to Observation resource or create specific profile.

The WG was a little confused about the need for this. After discussion, it seems the submitter wanted hyperlinks to Observation. When reviewing the Patient Gender section, it appears all information is clear there.

In an attempt to clarify, the reference to “Meaningful Use” will be removed. The last sentence in that paragraph will now say “The US realm defines the US specific extension for this for concept,”
An example will be created for the clinical Gender and referenced

The new Gender Identity standard extension will be included in the bulleted items tracker #13843
Moved Brian, second Cooper.
Vote: 7/0/2

1. 14754 - Gender can't drive clinical processes if it's administrative - 2018-Jan Core #91
   

Administrative Gender - the gender that the patient is considered to have for administration and record keeping purposes.

Needed for identification of the individual, in combination with (at least) name and birth date. Gender of individual drives many clinical processes.

The gender might not match the biological sex as determined by genetics, or the individual's preferred identification. Note that for both humans and particularly animals, there are other legitimate possibilities than M and F, though the vast majority of systems and contexts only support M and F. Systems providing decision support or enforcing business rules should ideally do this on the basis of Observations dealing with the specific gender aspect of interest (anatomical, chromosonal, social, etc.) However, because these observations are infrequently recorded, defaulting to the administrative gender is common practice. Where such defaulting occurs, rule enforcement should allow for the variation between administrative and biological, chromosonal and other gender aspects. For example, an alert about a hysterectomy on a male should be handled as a warning or overrideable error, not a "hard" error.
Proposed Wording: Requirements
Needed for identification of the individual, in combination with (at least) name and birth date.

Suggest you remove the statement "Gender of individual drives many clinical processes." since this contradicts your comments on "Administrative Gender", e.g. (The basic gender included in Patient.gender has a limited use, that of the administrative gender: the gender that the patient is considered to have for administration and record keeping purposes.)

To support your statement "Systems providing decision support or enforcing business rules should ideally do this on the basis of Observations dealing with the specific gender aspect of interest (anatomical, chromosomal, social, etc.)." suggest referring to LOINC codes for Sex assigned at birth (768909) since it may be different from the current Administrative Gender. Also suggest adding reference to LOINC code for Gender Identity in this section.

Cooper moves to disposition this persuasive with mod, Brian seconded.
Discussion: None
Vote: 5/1/3

14756# - Provide LOINC code for sex assigned at birth - 2018-Jan Core #93

Submitted by: Freida Hall (Quest Diagnostics)
On behalf of: Freida Hall (freida.x.hall@questdiagnostics.com)
Existing Wording: Tracking a patient's gender presents a number of challenges due to biological variations, differing cultural expectations and legal restrictions, and the availability of various kinds of gender re-assignment. The basic gender included in Patient.gender has a limited use, that of the administrative gender: the gender that the patient is considered to have for administration and record keeping purposes. In addition, to this gender, other kinds of gender may be represented:
•Birth Sex - the sex assigned at birth / on the birth registration. Some countries allow variations such as not yet determined, unknown, or undifferentiated, while others do not. The US realm defines a US Specific extension for this for Meaningful Use
•Clinical Gender - an observation about the patient, typically using the LOINC code 76691-5 ). LOINC also provides a set of possible codes , or SNOMED CT has the descendents of 285116001 : Gender identity finding

Since you provide a LOINC code for Clinical Gender in the 2nd bulleted section, suggest also providing the LOINC code for "Sex assigned at birth" (76689-9) in the 1st bulleted section text description.

Provide LOINC code for sex assigned at birth
Michelle moved seconded by Brian to accept this with additional wording “Alternatively, if you were reepresentint this concept with an observation you could use the LOINC code 76689-9.”
Vote: 8/1/0

1. 14099 - Guidance on how to request a new identifier (e.g. MRN)
   

See https://chat.fhir.org/#narrow/stream/implementers/topic/Create.20Identifier.20(MRN)
Need consistent guidance in the spec on how to request a new identifier be created (e.g. MRN). Brainstorming ranged from:

• An operation
• Use data absent reason extension to convey Identifier.value is "not yet assigned, so please assign it"
• An Identifier.assigner populated without Identifier.value populated

After discussion, An Identifier.assigner populated without Identifier.value populated
To be continued

Meeting Outcomes

Actions (Include Owner, Action Item, and due date) Action: Action:

Next Meeting/Preliminary Agenda Items .

Monday Q4

HL7 Patient Administration Meeting Minutes Location: Hilton New Orleans Riverside, Durham Conference Room		Date: 2018-01-29 Time: Monday Q4
Facilitator	Irma Jongeneel	Scribe	Alex de Leon
Attendee	Name	Affiliation
X	Irma Jongeneel	HL7 Netherlands
X	Line Saele	HL7 Norway
X	Brian Postlethwaite	Telstra Health, Australia
X	Alex de Leon	Kaiser Permanente, USA
X	Christian Hay	GS1, Switzerland
X	Cooper Thompson	EPIC, USA
X	Hanhong Lu	EPIC, USA
X	Simone Heckman	HL7 Germany
X	Drew Torres	Cerner, USA
X	Isabel Gibaud	HL7 France
X	Tricia Chitwood	Cerner, USA
Quorum Requirements Met (Chair + 2 members): Yes

Agenda

Agenda Topics

1. FHIR Ballot Reconciliation - Encounter

Supporting Documents

Minutes

Minutes/Conclusions Reached:
Introductions

1. 14099 - Summary: Guidance on how to request a new identifier (e.g. MRN) (cont.)
   

Guidance will be provided in the section “8.1.3 Patient Id’s and Patient resource id’s”. Where there is a need to implement an automated MRN Identifier creation for a patient record, this could be achieved by providing an identifier in the patient with the MRN type, an appropriate assigner and no value assigned. Internal business rules can then detect this and replace/populate this id with 1 or more ids (as required).
Drew moves/Brian
Persuasive
Vote: 8/0/2

1. 14823 Add search for Encounter.account –
   

Brian moves/Drew seconds to accept as persuasive.
Vote: 9/0/1

1. 14824 - Encounter.class should be 1..1
   

Class cardinality should be 1..1 as mentioned in section 8.11.4 Notes
The class element describes the setting (in/outpatient etc.) in which the Encounter took place. Since this is important for interpreting the context of the encounter, choosing the appropriate business rules to enforce and for the management of the process, this element is required. Moreover in class history it is marked as 1..1, so unless it is mandatory in current encounter, there won't be way to have it mandated in history

Encounter.class should be 1..1
This seems reasonable to the WG.
Alex/Simone second
Vote: 9/0/1

1. 14499 - Encounter.class description/definition contains duplicates (not in value set)
   

Description/definition says "inpatient | outpatient | ambulatory | emergency +"
The format of that description/definition usually implies those are specific codes in the value set, but the value set doesn't differentiate between outpatient and ambulatory. There is a single code for ambulatory, so it seems a bit misleading to imply there are codes for both.
The WG discussed this and decided upon a different description.
“Concepts representing classifciatin of patient encounter such as ambulatory (outpatient), inpatient
Simone moves/Line seconds
Vote: 9/0/0

1. 14758 - Summary: Add example to Encounter.diagnosis.rol to address principal diagnosis for an Encounter as noted in the comment provided (or add an additional role of principalDiagnosis). - 2018-Jan Core #95
   

Clinical quality measures need to address the concept of a Principal Diagnosis defined by statute as the coded diagnosis/problem established after study to be chiefly responsible for occasioning the admission of the patient to the hospital for care. The roles provided do not directly address principal diagnosis. FHIR tracker (https://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_item_id=10544) suggest that encounter-primaryDiagnosis and encounter-relatedCondition extensions will be removed as they are redundant with the core resource (using Encounter,diagnosis.role and Encounter.diagnosis.rank. However, the extension remains. And the example in Encounter.diagnosis.role does not address principal diagnosis. Encounter.diagnosis.role should include an example for definiing Principal diagnosis (e.g., role = billing diagnosis AND rank = 1, or role = discharge diagnosis AND rank = 1. Alternatively, add a role of "principalDiagnosis" to enable clinical quality measures and clinical decision support.

Add example to Encounter.diagnosis.role to address principal diagnosis for an Encounter as noted in the comment provided (or add an additional role of principalDiagnosis).
The encounter-primaryDiagnosis and encounter-relatedCondition will be removed as being redundant to Encounter.diagnosis.role and Encounter.diagnosis.rank.
As for the example reference, Simone suggested to make this an example binding. THe WG determined to update example
The redundant extension will be removed.
Example f202 will be updated to remove the extension and clarify the usage.
Cooper Thompson moves and Tricia Chitwood seconds to make this persuasive with mod
Vote: 8/0/2

1. 14477 - Encounter.serviceType needs binding to value set
   

Encounter.serviceType needs a binding to a value set.
After some research, it seems the binding is there, but the references from the Encounter.type does not point to the existing binding set which is an example set.
Brian moves, Alex seconds to move this persuasive.
Vote: 8/0/1

1. 14451 - PA resources do not have a clean Workflow report
   

The workflow project has put together a report identifying places where resources don't align with patterns, as well as a mechanism for work groups to mark as "ignored" if they don't feel alignment is appropriate/necessary. Your work group has resources that are still showing up on the report - meaning that an alignment review has not been completed (or there are issues with the suppression process - in which case please let me know). Alignment is most critical for normative resources, but should be completed for all resources that are FMM3 or higher (and should be considered for resources with lower FMM levels)
After discussion our FHIR SMEs decided to “divide and conquer” the work based on the specific resources defined in the tracker item:

* ChargeItem - Simone

• Encounter - Drew
• EpisodeOfCare - Cooper
• AppointmentResponse – Brian
• Appointment - Brian

Meeting Outcomes

Actions (Include Owner, Action Item, and due date)

Next Meeting/Preliminary Agenda Items .

Navigation

• Go To Monday Minutes
• Go To Tuesday Minutes
• Go To Wednesday Minutes
• Go To Thursday Minutes
• Return to Agenda PA May 2018 WGM
• May Cologne
• Return to PA Main Page

© 2018 Health Level Seven® International. All rights reserved. [[Category:2018_PA_WGM_Minutes]