2015-10-07 PA WGM Minutes

Patient Administration Work Group Minutes - October 7, 2015

Wednesday Q1

HL7 Patient Administration Meeting Minutes Location: Georgia 12 Conference Room		Date: 2015-10-07 Time: Wednesday Q1
Facilitator	Line Saele	Scribe	Alex de Leon
Attendee	Name	Affiliation
X	Irma Jongeneel	HL7 Netherlands
X	Alex de Leon	Kaiser Permanente
X	Line Saele
X	Brian Postlethwaite	HealthConnex, Australia
X		Gevity, Canada
X		GS1
X	Alexander Henket	EPIC
X		EPIC
X
Quorum Requirements Met (Chair + 2 members): Yes

Agenda

Agenda Topics
Approve Paris Minutes
Plan next meeting
Harmonization proposals
v2 work

Minutes

Minutes/Conclusions Reached:
Introductions
Mead walker presented regarding death reporting. Health Information system -> provider supplied death information->Jurisdictional Vital Registry -> Registry Death Information ->National Statistical Agency Social security number - Certificate Number – Death certificate number
Auxiliary File Number – File number assigned to the certificate in the file system in the local registry.
In consulting with vocab Ted Klein birth was set as a code for BC for Birth Certificate, so Mead Walker is approaching the WG to see if we can add a DC to indicate Death Certificate.
The second request is to use the SR (State Registry number) for Auxiliary File Number.
The WG discussed using the assigning authority for this. Since the assigning authority is the same, that most likely is not a good option.
Mead makes a motion for PA to endorse the work to add to the identified type (Table 0203) the values of DC and DCFN, Irma seconds.
Discussion:
Vote: 5/0/0 (For/against/abstain)
Alex presented the vocabulary issues that Ted Klein presented having to do with “cleaning up” the values within the tables referenced by Chapter 3. Some of the issues are simply defining values that are shown as “value1… value10”. These need to be either individually noted and defined or referenced as an external set as suggested values. Alex will work on this list for clean up and present the work to the WG within the next telecons for work group approval.

Alex d. presented 839.doc change, which outlines a change in the NTE segment but the presenters are asking for PA approval of inclusion of the NTE for visit-specific notes/comments.
Irma noted that we should clarify that these notes are for administrative purposes only not clinical. She also suggested we look at other trigger events in which this would be of value.
Alex d. moves to accept/endores change request 839 and look at other trigger events and add the NTE after PV2 in which this would be appropriate. Irma seconded.
Discussion:
Vote: 6/0/0

The WG continued on with the review/approval of the minutes.
Action: Check for date consistency.
Action: Talk to HQ and fix the missing attendance list.
Action: Update Lines affiliation to HL7 Norway.
Irma moves to approved the minutes with the understanding that the attendees lists will be updated with core members minimally, and full attendees if possible. Jim seconds.
Discussion:
Vote: 5/0/0 (For/against/abstain)
The WG reviewed the draft agenda.
The WG continued with the review of the trigger events within chapter 3 of the standard that might need to be updated with the NTE segment as per proposal # 839.
The proposal is asking to add to A01, A03, A04, A05, A08, A28.
The WG reviewed the other triggers not covered by the structure patterns above to be sure all situations are covered.
The WG advises that all the trigger events will also be updated except for:
A17 – Swap patients - Excluded because the NTE is a visit level comment, however this is a lower level bed swap trigger. A18 and A19 have been withdrawn from the standard.
A20 – Bed Status update. Excluded because there is no visit segments.
A23 – Delete a patient record has an A21 structure. If we can change the structure into it’s own, then we will exclude. Otherwise, it will be added to this as well.
InM needs to be talked to if we want to change the structure reference in A23. Also can the NTE be done at all for v2.9.
Alex, with Irma’s help, will be working on the analysis of the rest of the trigger events for inclusion/exclusion of the NTE segment.

Meeting Outcomes

Actions (Include Owner, Action Item, and due date) Action: Check for date consistency. Action: Talk to HQ and fix the missing attendance list. Action: Update Lines affiliation to HL7 Norway.

Next Meeting/Preliminary Agenda Items .

Wednesday Q2

HL7 Patient Administration Meeting Minutes Location: Room # 1367		Date: 2014-05-05 Time: Wednesday Q2
Facilitator	Irma Jongeneel	Scribe	Alex de Leon
Attendee	Name	Affiliation
X	Irma Jongeneel	HL7 Netherlands
X	Alex de Leon	Kaiser Permanente, USA
X	Brian Postlethwaite	Kaiser Permanente, USA
X	Daniel Lowenstein	EPIC
X	Alexander Henket	Nictiz
X	Iryna Roy	HL7 Canada
X	Christian Hay	GS1
X	Younjian Bao	GE Healthcare
Quorum Requirements Met (Chair +2 members): Yes

Agenda

Agenda Topics

1. FHIR DSTU 2 PA Resources . PC representative will join

Minutes

Minutes/Conclusions Reached:
Introductions
Joint with Patient Care
EpisodeOfCare – responsibility of an organization. There may not be physical contact but the org is responsible for managing that condition.
The definition of EpisodeOfCare includes : “…The managing organization assumes a level of responsibility for the patient during this time.” The rules for starting/stopping the EpisodeOfCare is very much business related.
The WGs discussed the relationships between Encounter, EpisodeOfCare, and proposed HealthConcern.
The concept of when a patient episode has been closed and cannot be opened from administrative and financial perspective, then the episodes of care would have to be linked.
Lloyd is working on creating a way of linking conditions together in a proposed resource named HealthConcern. The EpisodeOfCare may be this linking mechanism. The WGs discussed this.
The WGs are focused on making sure that the overall umbrella concept which PA has modelled as EpisodeOfCare from an administrative/financial perspective can meet the needs for the clinical perspective.
The discussion focused on whether these concepts of aggregating clinical events, procedures, etc. into one “health concern” and the aggregation of administrative/financial events into “EpisodeOfCare“ into one resource.
The WGs continued the discussion regarding health concern.
In conclusion, having to do with EpisodeOfCare, the WGs should explore either using this to meet the PC needs. We should move forward. This should be
Action: Brian to talk to Lloyd to find out what is planned for the linkage resource. This may be more of an infrastructure thing. Brian will report back. He will be the contact person. The contacts are PC – Michael Tan , PA – Brian, FHIR – Lloyd
Care Team – the concern is the nominated provider, the care team and any other participants.
In the care plan there is the construct of care team which is made up of Patient, Family Member, Provider, Carer. In looking at the CareTeam defined in EpisodeOfCare, the members only have Practitioner, Organization.
Action: Change the subcomponent of EpisodeOfCare currently called “CareTeam” to Participant or something else, as more appropriate. Irma also noted that the relationship of this concept to the EpisodeOfCare should be also
clarified so that it is known what type of Practitioners and/or Organizations should be used.
Irma suggested that there might need to be a track for
Action: Patient care will need to do harmonization with care plan participant construct with the fhir participant resource. Then a review of the participant in episode of care . PC will be open to assuring that the care plan
construct in EpisodeOfCare could be used with an extension to this for use in PC.
Alex noted that Steven was referring to an extension of the Paritipant construct. He clarified that this is a subcomponent to the EpisodeOfCare resource. Steven then introduced the idea that the participant construct might be raised to an individual resource if it is shared amongst resources. This will be considered perhaps after harmonization.
The ReferralRequest resource was discussed. This is referenced from EpisodeOfCare. It was noted that the referral may have a workflow that has not been fleshed out. Once done, PA may need to consider this reference if there is a more appropriate reference once done.
Irma noted that the ReferralRequest also references an Encounter, while Encounters reference the EpisodeOfCare. This is a circular reference. There is an encounter, which could lead to a referral. This referral will lead to another encounter. One is the initiating encounter while the other is the encounter as a result of the referral (resulting encounter). The resulting encounters are the one’s that reference the EpisodeOfCare.

Orders – Appointments
Encounter/Patient/EpisodeOfCare/CarePlan How is care team represented.

Meeting Outcomes

Actions (Include Owner, Action Item, and due date) Action: Brian to talk to Lloyd to find out what is planned for the linkage resource. This may be more of an infrastructure thing. Brian will report back. He will be the contact person. The contacts are PC – Michael Tan , PA – Brian, FHIR – Lloyd Action: Change the subcomponent of EpisodeOfCare currently called “CareTeam” to Participant or something else, as more appropriate. Irma also noted that the relationship of this concept to the EpisodeOfCare should be also clarified so that it is known what type of Practitioners and/or Organizations should be used. Action: Patient care will need to do harmonization with care plan participant construct with the fhir participant resource. Then a review of the participant in episode of care . PC will be open to assuring that the care plan construct in EpisodeOfCare could be used with an extension to this for use in PC.

Next Meeting/Preliminary Agenda Items .

Wednesday Q3

HL7 Patient Administration Meeting Minutes Location: Room # 1367		Date: 2014-05-05 Time: Wednesday Q3
Facilitator	Irma Jongeneel	Scribe	Alex de Leon
Attendee	Name	Affiliation
X	Irma Jongeneel	HL7 Netherlands
X	Alex de Leon	Kaiser Permanente
X	Christian Hay	GS1
X	Brian Postlethwaite	HL7 Australia
X	Prashant Trivedi	EPIC
X	Iryna Roy	HL7 Canada
Quorum Requirements Met (Chair + 2 members): Yes

Agenda

Agenda Topics

1. Ballot reconciliation Encounter

Supporting Documents

Minutes

Minutes/Conclusions Reached:
Introductions
V3 Encounter The WG reviewed the Sept ballot and noted that there were no negatives on Encounter. This was to move it to normative with no changes. It was noted that there was a comment on one affirmative. This was to change televideo conference to telemedicine consultation. This discussed. The WG agreed with this and voted Vote: 10/0/0 Action: For Alexander H. to make the above changes and proceed to publication (e.g. Request for publication, etc.)
FHIR The WG continued with the tracker items for the FHIR DSTU 2 content.

1. 8517

It is unclear exactly what the meaning of a value using Patient.multipleBirthInteger. The definition text states "the actual birth order", so presumably a value of say "2" means that there were at least 2 births in the birth event. The text could be a little bit clearer about this, however, the main issue is what does a value of "1' mean? Does use of the Patient.multipleBirthInteger element imply that were at least 2 births in the birth event? It would helpful to explain this more fully and especially what the cases of "1" means, e.g. a value of "1" means "the first of at least 2". Virginia noted that in v2, PID-24 PID-25 map to these elements. The description reads, PID-24 - This field indicates whether the patient was part of a multiple birth. PID-25 - “When a patient was part of a multiple birth, a value (number) indicating the patient's birth order is entered in this field.” Brian moved to accept the above changes, Alex seconded. Vote: 11/0/0 This is intended to be included in 2.1 of FHIR since it is a clarification.

1. 8513

1. Practitioner.qualification needs a type code, e.g. Degree, License, certification, Prodessional society membership 2. The current value set for Occupations is not a good fit. The fact that a person is currently employed as a proctologist does not mean they are qualified to be one.

The WG reviewed the Practitioner resource. Will add a “type” property to the qualification. Brian asked if there was a binding set for this. Irma suggested we look at v2. Upon looking V2 has entire segments that cover “professional affiliation”, “certification” and “education.” Action: Review the v2 elements that cover this area and consider how or if to craft this into the Practitioner resource. Owner: Brian

1. 8413

HealthService.serviceType.type definition needs improving - what's a 'type'? It would be more helpful to define it as the clinical specialty being delivered, performed or planned The WG discussed this and reviewed type. This has a value set. The specialty does not have a value set. The question came up as to whether the specialties at the Oranizational, Practitioner and HealthCareService are the same value set. It seems that they are. However, the specialties may need to be more of a nested structure which would allow for subspecialities, etc. Action: Identify the binding concepts for “HealthcareService.serviceType.specialty” Appointment types versus healthcare service versus We already have specialty in the healthcare service definition. This requires a mapping to some snomed codes. We are considering the removal of servicetype, and just having the servicecategory and specialty. However we need to check the implications of this on the appointments, schedule and slots. The binding currently allocated to the type could be allocated to the specialty (need the verify this).

1. 6516

Add <specdalty> to <Organization> as an optional repeating element. The WG discussed this at length as the HealthcareService seems the most likely match for the specialty that in needed by the submitter. But the WG noted that location is required on this resource, and the submitter noted that they do not store the HealthcareService nor location. The WG found that this cannot be resolved during this WGM and will need to do more research and potentially resolve this without crafting a specialty concept at the organizational level, but instead using the vocabulary and elements we have today (e.g. virtual location in location within the HealthcareService resource. The location is unable to currently handle virtual locations correctly. This will need to be resolved. The organization is now linked to the healthcareservice directly, so doesn;t have to go "through" the location. We are going to have a conference call with some additional people that understand this context very intimately.

1. 5750

Groups have no validity range information, either at the group level, or membership level. This seems to have been resolved, while the there are still questions about why the tracker item was assigned to PA.

1. 4873

I would propose a change to encounter that allows us to track the encounter.class for each period of time (similar to what is done with accommodations/beds). For example, if a patient shows up in the emergency department, then encounter.class begins as emergency. However, if that patient ends up getting admitted as an inpatient, then the encounter.class changes to inpatient. Just as the patient's location (bed) over time is modeled, same should be done for encounter.class as well.

Summary: Can we make a suggestion to either remove Encounter.StatusHistory or include class in this subcomponent. Action: Invite submitter to the next telecom.

Meeting Outcomes

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

Next Meeting/Preliminary Agenda Items .

Wednesday Q4

HL7 Patient Administration Meeting Minutes Location: Room # 1367		Date: 2014-05-05 Time: Wednesday Q4
Facilitator	Irma Jongeneel	Scribe	Alex de Leon
Attendee	Name	Affiliation
X	Irma Jongeneel	HL7 Netherlands
X	Barry Guinn	EPIC
X	Nat Wong	HL7 Australia
X	Christian Hay	GS1
X	Alexander Henket	E. Novation
X	Alex de Leon	Kaiser Permanente
Quorum Requirements Met (Chair + 2 members): Yes

Agenda

Agenda Topics

1. Ballot reconciliation FHIR DSTU2

Supporting Documents

Minutes

Minutes/Conclusions Reached:
The WG continued with the DSTU 2 quality work. The last quarter ended with “entered in error”.
The WG started with the “entered in error” scenario for Encounter. This is made up of multiple sub-components. Irma brought up that there may be implications if we focus only on the main resource.
However, Brian noted that this can be the case for other resources that are made up of multiple components overall.
Action: Brian will follow up with FMG for the entered in error warning to see if it has an effect on workflow and/or subcomponents.
The WG decided to move on to find other “entered in error” QA issues.
EpisodeOfCare.status
The current definition staths “planned, waitlist, active, onhold, finished, cancelled”. The WG considered the addition of “Deleted” to handle the enter in error status.
Brian moved to update this definition with the deleted status. Line seconded.
Vote: 6/0/0 (for/against/abstain)

HealthcareService
The WG looked at Organization and found that this was a Boolean active flag. This seemed to be enough to answer the entered in error situation. The WG decided that this would be done for HealthcareService as well. In addition, the entered in error solution will be to set the Boolean flag to inactive.
Brian moved to update the HealthcareService with an active flag, Boolean, and indicate that setting this to inactive would be the “entered in error” solution. Alex seconded.
Discussion: None
Vote: 5/0/0 (for/against/abstain)


Location Resource
Warning: Short description doesn’t add any new content.
Brian moved to update thes short description loction, the the description of the location and add “description not otherwise captured.” Alex seconded.
Discussion:
Vote: 5/0/0

RelatedPerson Resource
The WG noted that there was no status. Brian proposes adding an active boolean flag.
Brian moved to adding an active boolean flag. Alex seconded.
Discussion: Alex had doubts so it was discussed and clarified.
Vote: 5/0/0 (For/against/abstain)

Schedule Resource
For entered in error, Brian suggests that in his case, he would delete the schedule. Irma noted that there might be slots related to this schedule. The response from Brian is that he would take the slots along with the deletion. After talking through some use cases, this seemed not a viable option. After working through the workflow implications.
Brian introduced the idea that we may have to create a specific section that addresses what should be done if a schedule resource needs to be deleted and what must be done afterward (e.g. replace, merely delete, etc.). For instance, resolving appointments once a schedule is deleted and the appointments are disassociated with the slots.
For earlier resources, wherein a flag or process was put into place this will refer or be included into this section. This will resolve the entered in error QA warnings.
Slot Resource
The solution for the “entered in error” warning should be resolved by the schedule solution.
Brian moved to change the Slot.freeBusyType to “Slot.Status” and the name of the search parameter from “FB-Type” to “Status”. Alex seconded.
Discussion: None
Vote: 5/0/0 (for/against/abstain)

The WG then moved back to encounter to see if resolutions of the warnings could be find.
The WG the moved to Encounter.hospitalization.reAdmission which showed Element has a todo associated with it (Need a harmonization proposal for this.).
Action: Brian to find out who entered the “Todo” to find out what needs to be harmonized or if this is because there is no value set established, or… ?
The WG continued with considering what else could be handled with the time we had left. In looking at the Patient resource, we found INFORMATION:Patient Search Parameter name 'deathdate' does not follow the style guide.
This led to the continuation of the birth time/date that was started by Dale during the co-chair dinner. He had an issue with needing the birth date in some situations (neonatal) but not in others within the same system. He did not think it a good design to have to look at the core for one situation, when the time is not needed (since core only has birth date and not time elements) and look in another (within the extension for this element which defines birth date-time). After looking at the extension within the specification, the WG discovered that there could be more explanatory text to help with such situations of use.
Action: Update the description of the Extension time or day of birth to help with usage. Brian.
Action: If an extension has an overlap with a core element, what happens especially when the values differ? Brian.

Meeting Outcomes

Actions (Include Owner, Action Item, and due date) Action: Brian will follow up with FMG for the entered in error warning to see if it has an effect on workflow and/or subcomponents. Action: Brian to find out who entered the “Todo” to find out what needs to be harmonized or if this is because there is no value set established, or… ? Action: Update the description of the Extension time or day of birth to help with usage. Brian. Action: If an extension has an overlap with a core element, what happens especially when the values differ? Brian.

Next Meeting/Preliminary Agenda Items .

Navigation

• Go To Monday Minutes
• Go To Tuesday Minutes
• Go To Wednesday Minutes
• Go To Thursday Minutes
• Return to PA October 2015 WGM
• Return to PA Main Page

© 2011 Health Level Seven® International. All rights reserved.