2016-01-13 PA WGM Minutes
Return to: WGM Minutes > 2016 > January Orlando
Patient Administration Work Group Minutes - January 13, 2015
Wednesday Q1
| HL7 Patient Administration Meeting Minutes Location: Winter Park Room 49 |
Date: 2016-01-13 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 | Iryna Roy | Gevity/HL7, Canada | |
| X | Simone Heckmann | HL7 Germany | |
| X | Andrew Tores | Cerner, USA | |
| X | Peter Bernhardt | Relay Health, USA | |
| X | Tim McNeil | Surescripts, USA | |
| X | Jim Whicker | Cognosante | |
| X | JenniSyed | Cerner, USA | |
| X | Sean Moore | EPIC, USA | |
| X | Michael Donnely | EPIC, USA | |
| X | Toril Reite | NL7 Norway | |
| Quorum Requirements Met (Chair + 2 members): Yes | |||
Agenda
Agenda Topics
Welcome/introductions
FHIR Discussion on Practitioner and Location
Supporting Documents
Minutes
Minutes/Conclusions Reached:
Practitioner resource
The WG discussed the practitioner resource. Epic covered their concern about the source of the data for practitioner. The idea is that if a provider directory is populated with data from another source, how do you express that that data comes from that source and not from the provider of the data. The example given was in a newspaper article, often at the bottom the article would declare the source to be Associated Press.
The WG discussed how this could be done and landed on the concept of an extension element called “curator”, which can be used at the level at which data has been updated, validated, etc. For instance, if the entire practitioner record has been consolidated or validated, the curator element can be included. If the role has been validated, then perhaps that element can be included at that “level” to show curation at that level. After discussion, it appears that this can be useful for other resources.
No Place to store alternate names
9067 Practitioner name does not support multiple cardinalities
In our application we want to support alias for practitioners. This is possible for patients and as such should be available for practitioners as well in the same manner.
The WG discussed the importance of this is for display names. For practitioners that might have aliases, how does the display name know which to show the preferred? One thing that can be done is to change the name element’s cardinality. With this, you can assign the “usual name” of the human name data type.
A discussion was had over the search parameters and how that might be affected by the change in the cardinality of the name element. It was noted that when searching, then entire resource is returned.
The WG then gave guidance on what to do to populate Display name.
Brian moves to update the cardinality of the name property of the Practitioner resource to 0..*.
Include addiotnall guidance aas to how to select the name for display name
Peter seconded.
Discussion: none
Vote (For/against/Against): 13/0/0
Guidance should be given to apply this information.
Such as recommending to select based on:
- There is more than 1 name
- Use = usual
- Period is current to the date of the usage
- Use = official
- Other order as decided by internal business rules.
9243 - Modify Practitioner.Role.ManagingOrganization to Practitioner.Role.Organization
We propose modifying the name of managingOrganization to merely organization to clarify the intent of the field to indicate the organization to which the role is performed.
Motion made by Michael to update the name of the property of managingOrganization on the practitioner resource to “Organization”. Brian seconded.
Discussion: None
Vote: 13/0/0
9244 - Summary: Proposal to add identifiers and telecoms to practitioner role
Identifiers and telecoms are often associated with a given practitioner's role within an organization - for example SureScript identifiers, AUS provider numbers. Those identifiers need to be associated with a given location in order to describe meaning.
During a prior PA call, we also discussed associating an address with the practitioner Role element. Brian proposed a standard address extension on the role element to override the address only if the Location associated with the role is different than practitioner.address.
Add the new properties “Identifier” and “telecom” to the Practitioner.
There was a lengthy discussion around identifiers for practitioners in their potentially various roles. Should these be part of the practitioner ids or only on the practitionerRole level since some of these only apply to a specific role? It was decided that the role-specific ids should stay on the PractionerRole level while the practitioner level should retain the non-role specific ids.
A concern was raised about searching and whether this would mean having to repeat the search. It was clarified that there is a way to do one search that would search all ids since they are all in one resource (there was an idea to separate Practitioner into two resources into another named PractionerRole).
Michael moved to add the new properties “Identifier” and “telecom” to the Practitioner and update the search to include them and explain why address is not included. Brian seconded.
Discussion: None
Vote: 12/0/0
9245 - Clarify practitioner address use to indicate intended use
The comments on the address field should be clarified to indicate that this is normally expected to only contain
Brian moved, Irma seconded
Discussion: None
Vote: 12/0/0
Meeting Outcomes
Actions (Include Owner, Action Item, and due date)
|
Next Meeting/Preliminary Agenda Items
|
Wednesday Q2
| HL7 Patient Administration Meeting Minutes Location: Winter Park Room 49 |
Date: 2016-01-13 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 | Line Saele | HL7 Norway | |
| X | Andrew tores | Cerner, USA | |
| X | Iryna Roy | Gevity/HL7 Canada | |
| X | Christian Hay | GS1 | |
| X | Jenni Syed | Cerner, USA | |
| X | Michelle Miller | Cerner, USA | |
| X | Tim McNeil | Surescripts, USA | |
| X | Michael Tan | Nictiz, The Netherlands | |
| X | Toril Reite | HL7 Norway | |
| X | Nat Wong | HL7 Australia | |
| X | Jim Whicker | Cognosante, USA | |
| X | Emma Jones | Allscripts, USA | |
| Quorum Requirements Met (Chair +2 members): Yes | |||
Agenda
Agenda Topics
- FJOR DSTU 2 PA Resources – Joint with Patient Care
Supporting Documents
Minutes
Minutes/Conclusions Reached:
Introductions – Joint with Patient Care
The WG started with the shared interests of the FHIR resources. Specifically Concern and Care teams.
EpisodeOfCare
HealthConcern model
Patient Care (Michael) discussed healthconcern versus a problem concern. Problems are usually connected related to one diagnosis but you have to manipulate these problems into a healthConcern. The intention of the HealthConcern model is to parse the problem lists into an overall health focus.
So in an example, there could be one problem list that produces two health concerns.
The WG continued with the review of the HealthConcern model
There was discussions around the difference between EpisodeofCare and Healthconcern
Meaningful use has stipulated that systems have to support HealthConcern. This means that this information can be captured and can be exchanged.
There seemed to be some disconnect when talking about the HealthConcern versus the EpisodeOfCare.
The WG continued to discuss Care Team. Brian showed how
Patient resource has the primary GP, this might remain.
EpisodeOfCare resource has simple care team
Care Plan resource has a full detail of the care team relevant for the care plan.
The idea on the table is perhaps to have care team pulled out of EpisodeOfCare and CarePlane to be a full class resource on its own and referenced. Member datatypes can also be harmonized.
Seems that the member element should be harmonized to include Practitioner/Related Person/Patient/Organization
There will be a gForge item opened on the proposal to move care team to a first level resource by patient care.
Meeting Outcomes
Actions (Include Owner, Action Item, and due date)
|
Next Meeting/Preliminary Agenda Items
|
Wednesday Q3
| HL7 Patient Administration Meeting Minutes Location: Winter Park Room 59 |
Date: 2016-01-13 Time: Wednesday Q3 | ||
| Facilitator | Line Saele | Scribe | Alex de Leon |
| Attendee | Name | Affiliation | |
| X | Irma Jongeneel | HL7 Netherlands | |
| X | Line Saele | HL7 Norway | |
| X | Alex de Leon | Kaiser Permanente | |
| X | Iryna Roy | Gevity/HL7 Canada | |
| X | Frank Noge | Infor (Cloverleaf), USA | |
| X | Simone Heckmann | HL7 Germany | |
| X | Jim Whicker | Cognosante, USA | |
| X | Toril Reite | HL7 Norway | |
| X | Inger H Khateer | HL7 Norway | |
| X | Sean Moore | EPIC, USA | |
| X | Michael Donnelly | EPIC, USA | |
| Quorum Requirements Met (Chair + 2 members): Yes | |||
Agenda
Agenda Topics
- FHIR DSTU2 Ballot Reconciliation
Supporting Documents
Minutes
Minutes/Conclusions Reached:
Introductions
3500 - Human name of practitioner cannot capture all needed components for a name
Will add additional documentation on HumanName to have a table that provides some examples of how the components are used (and where extensions might be used) to allow the typical usage to be easily understood
Tod Pa to decide on recommendation to make Practitoiner.name repeat.
This has been resolved with # 9067
9249 - Manage the Provenance of Practitioner (and Other Resources) using an Extension
Discussed Q1 today (01/13/16)
Use of Provenance (which would likely have a 1:1 relationship with the source resource) was discussed but seemed to be a little “heavy”
We will to test this approach at the next connectathon, which will provide more direction on this.
8513 – Practitioner qualification needs work
1. Practitioner.qualification needs a type code, e.g. Degree, License, certification, Professional 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 looked at this and decided to leave this for another discussion
8732 - Organization.type has cardinality of 0..1, but would like to see this changed to 0..*
For example, there are religious-based schools, religious-based hospitals, and academic/teaching-based hospitals, so picking one org type (religious, school, or hospital) is too restrictive.
The submitter was in another work group but wants to ta
lk about this. After discussion, the WG will entertain this item in the next quarter. This will be time boxed as we will be covering the FHIR account resource.
5616 - Add <specialty> to <Organization> as an optional repeating element
Two applications I am working with apply the concept of <specialty> to Organizations, such as 'dental practice', 'physiotherapy practice' etc. If you want a dental appointment then only the dental practices are listed.
After discussion, the WG discovered that on the healthCareService resource has a “providedBy” element that was not included within the Organization resource. This may answer the submitter’s request.
The WG feels that the specialty is not an appropriate property to the Organization but rather to services or providers associated to that organization. Therefore the HealthCareService where it is currently modeled seems the most appropriate place to derive this. However, the requirement of the HealthcareSercce meandating the inclusion of a location seems to e very restrictive. To alleviate this, the cardiality can be changed to 0..1 (or 0..*) to allow the location to be omitted. Searches would them remain on the healthcareService for specialty.
Using the 0..* cardinality on the providedby element will permit the same healthcare servce record to be used by multiple locations. If wanting to have different opening hours, then use additional healthcare service instances.
Irma moved to change the cardiality for location in HealthcareService from 1..1 to 0..*. Brian seconded.
Discussion: None
Vote: 14/0/0
9250 - Clarify that repeating elements in PractitionerRole all apply to one another
Make it clear in the documentation of PractitionerRole that all repeating elements apply to one another in a many to many relationship. If a practitioner practices at two location and has a different specialty at each locations, for example, there will be two PractitionerRoles each with one location and one specialty.
Michael from EPIC suggested instead to resolve this to change a text to express that for any repeating elements, there may be a many to many relationships. The expressed example given:
If a practitioner is an oncologist within an organization is at three locations, you can have a single practitionerRole at three locations, however if that same practitioner is a pediatric oncologist, then there would be one practitioner role with three locations and one pediatric oncologist practitionerrole with one location.
Micheal moved to add descriptive notes and examples for the practitioner will be changed to include more guidance on using the repeating elements within the practitioner role. Iryna seconded.
Discussion: None
Vote: 10/0/0
Meeting Outcomes
Actions (Include Owner, Action Item, and due date)
|
Next Meeting/Preliminary Agenda Items
|
Wednesday Q4
| HL7 Patient Administration Meeting Minutes Location: Winter Park Room 49 |
Date: 2016-01-13 Time: Wednesday Q4 | ||
| Facilitator | Brian Postlethwaite | Scribe | Alex de Leon |
| Attendee | Name | Affiliation | |
| X | Irma Jongeneel | HL7 Netherlands | |
| X | Line Saele | HL7 Norway | |
| X | Brian Postlethwaite | HealthConnex, Australia | |
| X | Alexander de Leon | Kaiser Permanente, USA | |
| X | Jenni Syed | Cerner, USA | |
| X | Andrew Torres | Cerner, USA | |
| X | Frank Noge | Infor, USA | |
| X | Simone Heckmann | HL7 Germany | |
| X | Michelle Miller | Cerner, USA | |
| X | Toril Riete | HL7 Norway | |
| X | Iryna Roy | Gevity/HL7 Canada | |
| X | Peter Bernhardt | Relay Health, USA | |
| Quorum Requirements Met (Chair + 2 members): Yes | |||
Agenda
Agenda Topics
- FHIR Account Resource Review/Preparation
Supporting Documents
Minutes
Minutes/Conclusions Reached:
Introductions
Timeboxed discussion regarding 8732 Organization.type cardinality
Michelle explained the need. For multiple “types” for organizations.
When asked about what is being communicated with type, Michelle from Cerner displayed a list of about 30, which included Employer, Practice, School. Cerner was asked about the usage. Cerner agreed that they could look at usage data to see how often this is actually used and what for.
Action Item: Simone is having trouble mapping v2 location to Fhir location, she will try to make a draft mapping and we will discuss that in a conference call.
The WG continued on with the review of the diagram which associates the various resources involved in PA and FM resources.
<<insert diagram>>
This includes the created
Patient
RelatedPerson
Organization
EpisodeOfCare
Encounter
BillableItem
Account resource
The WG reviewed the account model created by Alex d. based on v2 concepts and created before today’s account, contract, coverage, just to assure the elements are covered by current resources or other FHIR concepts.
Action: Alex to “pull out” the remaining elements in the prototype account and send to Brian.
Meeting Outcomes
Actions (Include Owner, Action Item, and due date)
Action: Alex to “pull out” the remaining elements in the prototype account and send to Brian. . |
Next Meeting/Preliminary Agenda Items
|
- Go To Monday Minutes
- Go To Tuesday Minutes
- Go To Wednesday Minutes
- Go To Thursday Minutes
- Return to PA January 2016 WGM
- Return to PA Main Page
© 2016 Health Level Seven® International. All rights reserved.
