2015-01-20 PA WGM Minutes
Patient Administration Work Group Meeting – Tuesday January 20, 2015
Tuesday Q1
| HL7 Patient Administration Meeting Minutes Location: Directors Conference Room |
Date: 2015-01-20 Time: Tuesday Q1 | ||
| Facilitator | Line Saele | Scribe | Alex de Leon |
| Attendee | Name | Affiliation | |
| X | Line Saele | HL7 Norway | |
| X | Alexander Henket | HL7 Netherlands | |
| X | Helen Drijfhout | HL7 Netherlands | |
| X | Christian Hay | GS1 | |
| X | Toril Reite | HL7 Norway | |
| X | Brad Fonseca | Canada Health Infoway | |
| X | Tanya Achilles | Canada Health Infoway | |
| X | Alex de Leon | Kaiser Permanente | |
| Quorum Requirements Met (Chair + 2 members): Yes | |||
Agenda
Agenda Topics
- Coordination with FHIR Core Team
Supporting Documents
Minutes
Introductions
Coordination with FHIR Core Team
The WG discussed the roles of FHIR facilitator and FHIR liason. The co-chairs updated the group that this ite was discussed in the steering division. After much discussion during that meeting around roles of facilitator versus liason, no decision was made. The suggestion was that this should be brought to the FHIR management group.
- Action Item: The WG is requesting an official role of HL7 FHIR Facilitator to the FMG. Responsible: Brian
The WG then was informed of key due dates
Due dates: March 22, midnight eastern. For content.
April 3rd - Ballot open, midnight eastern.
Question was asked what happens if the group does not meet deadline. Brian answered that there are two alternatives if the group is not able to make the deadline:
- Ballot might be extended
- If the material is not ready, then it would be included but a note would be also there indicating that this material is draft.
Status DSTU 2 for comment only. April will be the DSTU 2.
May meeting would be the reconciliation of DSTU2 material.
What do we need to do from a QA perspective.
The WG was directed toward the HL7 DSTU 2 QA guidelines found at:
http://wiki.hl7.org/index.php?title=DSTU_2_QA_guidelines
Alexander asked if a server does not support all search parameters in the specification is it considered non-compliant? The answer was that each server would have a compliance statement stating which search perameters are supported. There seems to be a minimum set of 5 search parameters:
_id
_language
_lastUpdate
_profile
_security
_tag
Daniel asked what a narrative resource is. It apparently used only where text might be sent.
There is a spreadsheet that should be used for QA:
https://docs.google.com/a/lmckenzie.com/spreadsheets/d/18HfXF7mUCUV7jACCG0oejFp6D-ibtvbmcgywNhn76lw/edit?pli=1#gid=0
The WG inquired about questions or comments that come up during this time at WGM or shortly thereafter. The answer from the WG is to submit it via tie GForge tracker.
A question was asked as to whether it seemed that there would be versions beyond DSTU 2. The FMG representatives (Josh and Brian) stated that there probably will be a DSTU 3.
Argonaut
A group of stakeholders who want to see FHIR succeed. EHR Vendors and clinical stakeholders. Making sure that the community is provided what is needed for supporting FHIR QA, support of Meaningful Use, providers running applications using FHIR. Provides funding as support.
Brian asked how PA could support the Argonaut project. Continuing with the work to support the profiles produced as a result of the resources within the PA domain is the best work that can continue.
FHIR Ballot Reconciliation
Tracker# 5190 A-S.
The working group agrees with the suggestion. The wording in Section 5.3.4 for the link element in RelatedPerson will be changed from “The link element is used to related resources under a common person record” to “The link element is used to relate resources under a common person record.”
Tracker# 5191 Neg Min
A person resource provides a mechanism for linking patient human resource across different organizations and their unique patient identity domains
Is the scope and usage based on the design of the resource, the scope/usage seems like it is for linking resources across different FHIR servers as opposed to organizational boundaries.
This will be consolidated with action on tracker #5189 and marked as clarified no change.
Tracker# 5192 A-Q
Discussion about freeProvisionCode.
A lively discussion was had regarding the name and concepts behind this. It was made clear that the intention of this is to provide information about any free, discount, contractual provisions, etc.
Meeting Outcomes
Actions (Include Owner, Action Item, and due date)
|
Next Meeting/Preliminary Agenda Items
|
Tuesday Q2
| HL7 Patient Administration Meeting Minutes ‘‘‘Location: Directors Conference Room |
Date: 2015-01-20 Time: Tuesday Q2 | ||
| Facilitator | Line Saele | Scribe | Alex de Leon |
| Attendee | Name | Affiliation | |
| X | Line Saele | HL7 Norway | |
| X | Alex de Leon | Kaiser Permanente | |
| X | Barry Guinn | EPIC | |
| X | Helen Drijfhout | HL7 Netherlands | |
| X | Toril Reite | HL7 Norway | |
| X | Christian Hay | GS1 | |
| Quorum Requirements Met (Chair + 2 members): Yes | |||
Agenda
Agenda Topics
Supporting Documents
Minutes
FHIR Tracker Reconciliation (Cont.)
Tracker# 5192
The WG continued with the proposed name “serviceProvisionCode” with the description. Cardinality will change from “0..1” to “0..*”.
Tracker# 5193 Neg-Min
The tracker authors feel tha the following elements should be moved outside of the standard (not 80%):
- Contact point
- Referral method
- Setting
- Target Group
- Coverage area
- Catchment area
Rename contact point to “telecom” to be consistent where this is used elsewhere in spec.
Referral method – the WG concluded that this would be valuable to keep on the healthcare service.
Setting – The WG concluded that this was redundant with Location.mode. The description of location will be updated to reflect this.
Target Group – The WG considered this to be an extension.
coverageArea and CatchmentArea - need to have descrpitions so that a decision can be made as to keep them.
Email was sent to define these, while we wait, the WG moved on to the next tracker item.
Tracker# 5195 7-0 A-S
birthDate has a data type of dateTime which captures a suggestion to change it to capture date only.
This prompted a discussion about time zones, however, to answer the most wide use case, the WG agreed with the suggestion to change this to capture date only. For implementers that need to support time, an extension can be used. There was a question as to whether this might make sense for the Practitioner resource as well.
- Action: Explore whether there is a consideration within the Practitioner resource around dateTime versus just date. Responsible: Brian
Tracker# 5196 Neg Min
It is unclear how an implementer would communicate a role that is defined with the content of an encounter. E.g. suppose that Smith is an attending
The WG discussed the codesets for practitioner.role and encounter.participationType and whether these should be related. It was brought forth by Yonjian that the role is the potential roles that the practitioner can perform while the participationType is the role that the practitioner played in a specific instance. So these are semantically different codesets.
Issue described and answered the issue. There is a spelling mistake that will be corrected.
For the practitioner roles, derived from terms of employment education, licensing.
Motion to correct the spelling mistake Brian. Second was made by Iryna.
Discussion: None
For (for/abstain/against): 9/1/0
Tracker# 5197 A-Q
Practitioner resource
How would one communicate that a practitioner works as a general practitioner in Clinic X during the week and as an emergency practitioner in Hospital Y on the weekend?
Should role, period, and location all be put under a grouping within the resource?
Brian agreed that there is no way to indicate when a provider performs different roles in different places. He referred to a potential resource that might encompass the “practitioner role”.
There are still questions as to whether this information should be as part of the practitioner resource or be a whole new resource.
The WG continued to explore what the “grouping” of elements around PractitionerRole (either as part of the practitioner resource or as it’s own resource):
- 0..* PractitionerRole
- 0…1 Organization
- 1…1 Role
- 0…* Specialty
- 0…1 Period
- 0…* Location
- 0…* HealthcareService
Alexander noted that the healthcare service has location on it.
The WG had considerable discussion about this therefore agreed that this should be voted on based on the significance of the change.
Daniel moved and Alexander H seconded to add the role related processes into a subcomponent called PractitionerRole as shown above.
Discussion: None
Vote (for/abstain/against): 11/1/0
Motion passes.
Meeting Outcomes
| Actions (Include Owner, Action Item, and due date)
. |
Next Meeting/Preliminary Agenda Items
|
Tuesday Q3
| HL7 Patient Administration Meeting Minutes ‘‘‘Location: Directors Conference Room |
Date: 2015-01-20 Time: Tuesday Q3 | ||
| Facilitator | Line Saele | Scribe | Alex de Leon |
| Attendee | Name | Affiliation | |
| X | Line Saele | HL7 Norway | |
| X | Alex de Leon | Kaiser Permanente | |
| X | Nat Wong | HL7 Australia | |
| X | Toril Reite | HL7 Norway | |
| X | Helen Drijfhout | HL7 Netherlands | |
| Quorum Requirements Met (Chair + 2 members): Yes | |||
Agenda
Agenda Topics
Supporting Documents
Minutes
Minutes/Conclusions Reached:
FHIR Reconciliation (cont.)
Tracker# 5198 Neg-Min
Currently, location is a standard query parameter for Schedule but isn't included for Appointment. Queries for appointments based on locations are supported in v2. Location should probably be added to Appointment as a search parameter.
The WG discussed perhaps making the location an participant for appointment.
Brian has moved to remove the location from the appointment resource and instead utilize the actor property on the participant sub component. This property is already searchable, so meets the need of the issue. Further usage guidance on this will be included. Daniel seconds.
Discussion: This also removes the special cases required for the location, and can be considered for scheduling/availability checking the same as all other participants in the appointment.
Vote: 12/0/0
Motion passes.
Tracker# 5199 Neg-Min
Several mappings for v2 are missing. E.g. Appointment.Type -> AIS-3
The WG agrees to The submitter (Daniel) will provide suggested mappings to be reviewed on the PA con calls. No decision was made so the WG vote will be held on the call.
- Action: Provide suggested mappings for the appointment resources. Responsible: Daniel
Meeting Outcomes
| Actions (Include Owner, Action Item, and due date)
|
Next Meeting/Preliminary Agenda Items
|
Tuesday Q4
| HL7 Patient Administration Meeting Minutes ‘‘‘Location: Directors Conference Room |
Date: 2015-01-20 Time: Tuesday Q4 | ||
| Facilitator | Line Saele | Scribe | Alex de Leon |
| Attendee | Name | Affiliation | |
| X | Line Saele | HL7 Norway | |
| X | Toril Reite | HL7 Norway | |
| X | Alex de Leon | Kaiser Permanente | |
| X | Alexander Henket | HL7 Netherlands | |
| X | Helen Drijfhout | HL7 Netherlands | |
| X | Brad Fonseca | Canada Health Infoway | |
| Quorum Requirements Met (Chair + 2 members): Yes | |||
Agenda
Agenda Topics
- FHIR Ballot Reconciliation
Supporting Documents
Minutes
FHIR Reconciliation (Cont.)
Tracker# 5201 A-S
“It would appear that managingOrganization and period are intended to be tightly coupled. I think it would make sense to incorporate them into the specification as tightly coupled items. E.g.
managingOrganization “
-> reference
-> period
It might also make sense to allow for multiple different managing organizations.
Brian explained that the episode of care would be an episode of care from the the organization’s perspective. Therefore the period is for the episode of care. Even though care may continue for the specific problem, a new episode of care would be created when taken over by another organization. Further guidance is required why this is the case, especially how transfers of care would be handled and how multiple organizations would have their own EpisodeOfCare instances. This will be included into the defition.
Tracker# 5202 A-S
Existing wording
The primary difference between the EpisodeOfCare and the Encounter is that the Encounter records the details of an activity directly relating to the patient, while the EpisodeOfCare is the container that can link a series of Encounters together for a specific problem/issue.
Proposed writing.
The primary difference between the EpisodeOfCare and the Encounter is that the Encounter records the details of an activity directly relating to the patient, while the EpisodeOfCare is the container that can link a series of Encounters together for problems/issues.
The WG accepts the suggestion.
Tracker# 5203 A-Q
EpisodeOfCare
When I reviewed the specification with some of our application developers, they weren't sure what was meant by "Problem based General Practice systems".
Is there a more standard term that would be known industry-wide?
Problem based General Practice is a subset of General Practice systems in which the problem is the focus and is this term is understood within the industry of healthcare. Question answered.
Tracker# 5204 A-S
Existing Wording – EpisodeOfCare, Background and Context
The minimal information that would be required in an episode of care would be a patient, healthcare provider and a reason for the ongoing association.
Proposed Wording
Some countries/systems may only track an episode at an organization. It seems like "healthcare provider" should be "healthcare provider or healthcare organization"
Changing “healthcare provider” to “organization”
Tracker# 5205 A-S
EpisodeOfCare
currentStatus
planned | active | onhold | finished | withdrawn | other
Wouldn't active, finished, deleted be sufficient for the 80%?
The WG discussed this and decided that the current statuses suffice for the 80%. For “deleted” HTTOP code could be used for resources created in error (as this the the resource deleted status in FHIR).
Tracker# 5206 A-Q
Episode of Care
statusHistory element
When I reviewed the specification with some of our application developers, they had a hard time understanding how this would be implemented/used by disparate systems.
Is there more use case information around this that could be provided?
Could FHIR versioning be sufficient for supporting these use cases?
This is for the history of the status property. This is relevant for tracking how long the episode has been at any specific status.
Brian will provide further clarity and guidance on the usage and usage of the statusHistory element used, including verbiage that remove the requirement of the server to support FHIR versioning for access to status history.
Tracker# 5207 A-Q
Episode of care definition
The type can be very important in processing as this could be used in determining if the episodeofcare is relevant to specific government reporting, or other types of classifications.
"type" seems to open ended. Is this meant to track pregnancy vs. diabetes treatment?
Or would this be more commonly used to track the larger administrative program that the episode falls under. E.g. Hospital Admission Risk Program (HARP) vs. Subacute Ambulatory Care Services (SACS)?
Can we have the spec clarify this?
The WG responded that this is meant to be open ended and it could be used for each of these instances.
Tracker# 5208 Neg-Min
The interval during which the managing organization assumes the defined responsibility
My understanding is that the episodeOfCare is solely a single organization's tracking of an episode. We should make sure that the standard is clear regarding this vs. multiple organizations managing a condition (or set of conditions) for a patient. If the intent is to try to make a standard for how multiple organizations can track periods of responsibility within a patient's episode of care, then I think the design needs much more discussion.
Otherwise, I think that "period" should be noted simply as tracking the start and end date as it is known to the organization.
The WG feels that this has been explained that the period is for a single organization. Other organizations would have their own episode of care as required.
A motion was made by Brian to accept the description as noted in tracker item # 5201. Peter Seconds.
Discussion: None
Vote (for/abstain/against): 6/0/0
Motion passes.
Tracker# 5209 Neg-Mi
referralRequest
Episode is designed to be a grouping of encounters. I think it would be more appropriate for the link between a referralRequest and an EpisodeOfCare to go through the encounter as this is inforamtion that is likely tracked/necessary at the encounter level as well.
The WG discussed that the EpisodeOfCare may be the response for a referralRequest . Encounter does not have a link to the referralRequest for systems that only consider the encounters. This should be discussed with Patient Care.
The referralRequest should have cardinality 0...* so that multiple referrals can be associated to the one EpisodeOfCare (this covers the case of the 12 month referral for this).
Since this requires follow up, the WG will hold off on a vote until the Patient Care Work Group can be consulted.
- Action: Refer tracker # 5209 to Patient Care regarding comment to link referralRequest and EpisodeOfCare and how Encounter relates. Responsible: Brian
Tracker #5210 A-S
referralRequest.
If the spec continues to track related referrals at the episode level, we ought to consider how to track/manage referral In vs. referral Out.
The WG discussed this and will refer to 5209 resolution which may resolve the differentiating in versus out referral. Action: Refer to Patient Care
Tracker # 5211 A-Q
Search Parameter – Date
Should this be tied to managing organization or simply just a date to filter on episodes which were active during the date?
Date – The interval during which the managing organization assumes the defined responsibility. EpisodeOfCare.period
The WG discussed this and decided to clarify the wording on the date search parameter. Change from the above to “The provided date search value falls within the EpisodeOfCare’s period.”
Question answered.
Tracker #5212 Neg-Min
Search Parameters -> EpisodeOfCare.managingOrganization
The organization that has assumed the specific responsibilities for the specified duration.
Is this something that is really part of the 80%?
It seems unlikely that a system is going to track multiple different organizations that have or are taking responsibility for an Episode.
Also, the description describes a query request that should actually include multiple query parameters in the URL.
Brian moved to change the wording of the search parameters to not mention duration, just that the filter restricts to the specified organization. Second Daniel.
Discussion: None
Vote: 6/0/0
Meeting Outcomes
| Actions (Include Owner, Action Item, and due date)
|
Next Meeting/Preliminary Agenda Items
Agenda topics:
© 2015 Health Level Seven® International. All rights reserved. |
