2015-01-21 PA WGM Minutes

Patient Administration Work Group Minutes - Wednesday January 21, 2015

Wednesday Q1

HL7 Patient Administration Meeting Minutes Location:		Date: 2015-01-21 Time: Wednesday Q1
Facilitator	Line Saele	Note taker	Daniel Loewenstein
Attendee	Name	Affiliation
X	Line Saele	Helse Vest IKT Norway
X	Peter Bernhardt	Relay Health
X	Alexander Henket	NICTIZ
X	Iryna Roy	Gevity
X	Brian Postlethwaite	Healthconnex, Australia
X	Daniel Loewenstein	Epic
X	Yongjian Bao	GE
X	Josh Roberson	Epic
Quorum Requirements Met (Chair + 2 members): Yes

Agenda

Agenda Topics

• Approve Chicago Minutes
• Draft agenda for Paris.
• Harmonization proposals.
• V2work.
• FHIR Gforge tracker items

Supporting Documents
n/a

Minutes

Minutes/Conclusions Reached:

1. Review of Chicago Minutes.
   
   1. Minutes reviewed.
      
   2. Changes needed
      
      1. Agenda topics for Tuesday Q1 need to be updated.
         
      2. Agenda topics missing:
         
      3. *Tuesday Q2, Tuesday Q3, Tuesday Q4, Wednesday Q1
         
      4. Tuesday Q4 incorrectly indicates that there was quorum. The participants listed are just the PA co-chairs.
         
      5. Wednesday –
         
         1. Update attendees.
            
         2. Update meeting outcomes.
            
         3. Address the line items that were marked as “update later”.
            
         4. Minutes/conclusions from Wednesday Q_ incorrectly note “Project #650” with the follow-up item with RTLS. Project 650 has to do with registries.
            
      6. Thursday
         
         1. Agendas, attendees incomplete.
            
         2. Links to documents missing.
            
   3. Follow-ups from Chicago that are still in progress.
      
      1. Determine if there are plans for a Consent resource in FHIR – Brian
         
      2. Determine if there is a plan to include a “preferred flag” within contactPoint data type – Brian
         
      3. Include examples for appointment for handling recurring – Brian.
         
   4. Motion:
      
      • Approve minutes assuming that Alex is able to update attendees list and agenda items. – Iryna. Second: Brian.
        
      • Vote: 7-0-0
        
2. Planning for Paris
   
   1. HL7 has asked for WGs to keep the sessions on Monday and Tuesday “interesting” b/c there’s an initiative to get more/new members to attend those days. “interesting” = avoid administrative/planning sessions.
      
   2. Planning for presentation of overview of PA during Monday Q3.
      
      1. Irma to prep general PA charter information (15 min or so)
         
      2. Brian to prep FHIR components.
         
   3. Proposal: hold a session for open questions and new proposals. Open questions in place to entice new members to join. Likely plan for Q4 Monday.
      
   4. PHER harmonization CMETs
      
   5. Action item:
      
      • Line to get a hold of Paris scheduling and work on offline on building agenda because of considerations for Monday/Tuesday.
        
3. Harmonization proposals
   
   • None noted.
     
4. V2
   
   • Daniel noted that supporting Infection information (e.g. patient has MRSA) was an item raised to the PA mailing list. This seems like a good thing to add/support in ADT. Moved to “parking lot” until Alex returns.
     
5. Gforge tracker issues
   
   1. 5263
      
      • Issue: A-S item regarding confusion over the user of RelatedPerson vs. Contact details being “either/or”.
        
      • Discussion: It is not the design of the specification for these two items to be explicitly “either/or”. Rather,
        
        • RelatedPerson is meant to track people that are directly participating in the patient’s care.
          
        • patient.contact is meant to track contact points for administrative or emergency scenarios.
          
      • Next step(s).
        
        • Update RelatedPerson to use suggested wording without the “e.g. care giver” text.
          
   2. 5265
      
      • Issue: A-S item for Patient regarding inconsistency with the number of scenarios cited in the header of 5.1.4
        
      • Discussion:
        
        • Believe that 5.1.4.4 and 5.1.4.5 ought to be separate topics. E.g. 5.1.5, 5.1.6
          
      • Next step(s)
        
        • Make updates as discussed.
          
        • Also, instead of stating “three scenarios” state, “the following” scenarios.
          
        • Finally, instead of “person”, state “patient records” to avoid confusion now that there is a Person resource.
          
   3. 5267
      
      • Issue: A-S item for Person for wording around where attributes are applicable.
        
      • Discussion:
        
        • Suggestion in tracker is referring to a section of the Person resource that was from back when Person was first proposed.
          
      • Next step(s)
        
        • Get rid of “Original PA Notes” by commenting it out in the HTML file.
          
   4. 5268
      
      • Issue: A-Q item on PRactioner. Section 5.4.5 implies that the absence of a value in practitioner.organization would indicate self-employment.
        
      • Discussion:
        
        • General agreement that absence of information shouldn’t be assumed to mean self-employment.
          
      • Next step(s)
        
        • Remove the bullet point.
          
   5. 5269
      
      • Issue: A-S item for practioner. Add Specialty and Role as search parameters.
        
      • Discussion: seems reasonable.
        
      • Next step(s): add search parameters as described.
        
   6. 5270
      
      • Issue: Negative-Minor – concerns with Healthcare Service not providing sufficient detail to implementers.
        
      • Discussion:
        
        • Agree that.
          
        • Daniel: Feel that HealthCare service is clearly a healthcare object that deserves a resource but standard
          
      • Motion
        
        • Add additional text for usage/guidance and add examples
          
        • Leave the Healthcare Service resource under its current attribution as it is not only for Scheduling.
          
        • Also, seek more comment from implementers
          
        • Primary: Brian
          
        • Second: Iryna
          
        • Vote: 6-0-0.
          

Meeting Outcomes

Actions (Include Owner, Action Item, and due date) Complete follow-ups from Chicago WGM – Brian Line to figure out the special considerations for Paris WGM scheduling and build draft agenda. Prep PA overview for Paris WGM – Brian/Irma * Brian to cover FHIR. Irma to cover PA’s charter.

Next Meeting/Preliminary Agenda Items

Wednesday Q2

HL7 Patient Administration Meeting Minutes Location: Directors Conference Room		Date: 2015-01-21 Time: Wednesday Q2
’‘‘Chair’’’	Line Saele	’‘‘Scribe’’’	Alex de Leon
Attendee	Name	Affiliation
X	Line Saele	HL7 Norway
X	Peter Berndhardt	Relay Health, USA
X	Daniel Lowenstein	EPIC
X	Alex de Leon	Kaiser Permanente
X	Brian Postlethwaite	Health Connex, Australia
X	Beat Heggli	HL7 Switzerland
X	Yongjian Bao	GE Health, USA
X	Wendy Huang	Infoway, Canada
X	Josh Roberson	EPIC, USA
X	Melissa Taylor	Web MD, USA
X	Prashant Trivedi	NHS, UK
Quorum Requirements Met (Chair + 2 members): Y

Agenda

Agenda Topics

• FHIR DSTU 2 Patient Administration Resources, joint with Patient Care

Supporting Documents

• FHIR DSTU2 Issues/Comments

Minutes

Minutes/Conclusions Reached:
Introductions
FHIR resources joint with Patient Care
First resource that the WG wanted to review with Patient Care was EpisodeOfCare .
In reviewing the various elements, the patient care representive asked if there was a “recommended” or some status before Planned. After discussion, it seems as though it should be added to reflect business realities. Need further consideration of a status to reflect the preliminary status “recommended”, “pending”, or something that reflects this. After discussion, and looking at the statuses across all resources, it seemed that “proposed” may be the best status instead of “planned”. This will be renamed.
Episode of Care
The WG discussed the managingOrganization
This is the entity who would use the episode of care. Typically this is the payor. managing organization (payor) would use this as much as the care organization. The WG discussed the cardinality of managingOrganization.
Should managing organization be 1..1 or 1..*. Prashant stated that he thought it should be 0...1. He noted that the patient is 0...1.
This highlighted the need to change the cardinality On Encounter.epicsode of care should be 0..*

The WG discussed the participants. The WG noted that there was a careplan resource developed by Patient Care WG that has participant with member subcomponent which includes Practitioner, RelatedPerson, Patient, Organization.
Add episodes of care reference to CarePlan 0…*
Include organization in the members of the care team. Yongjian suggested that CareTeam be renamed to CareTeamMember.
After discussion questioning the retention of the practitioner in the careManager role and the careTeam, Care manager, the Patient Care representative and PA decided that these should remain.
Include on the text on the care manager that if there is no named individual, then each careEpisode will define the organization as the CareManager.
This concluded the quarter and finished the review of the EpisodeOfCare with 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: Directors Conference Room		Date: 2015-01-21 Time: Wednesday Q3
’‘‘Chair’’’	Line Saele	’‘‘Scribe’’’	Alex de Leon
Attendee	Name	Affiliation
X	Line Saele	HL7 Norway
X	Alexander Henket	HL7 Netherlands
X	Daniel Lowenstein	EPIC, USA
X	Josh Roberson	EPIC, USA
X	Toril Ormberg Reite	HL7 Norway
X	Brian Postlethwaite	Health Connex, Australia
X	Alex de Leon	Kaiser Permanente, USA
X	Peter Bernhardt	Relay Health, USA
Quorum Requirements Met (Chair + 2 members): Yes

Agenda

Agenda Topics

• FHIR QA Updates to DSTU 1 Patient Administration Resources

Supporting Documents

• FHIR Patient Administration Resource Development Wiki Page
  

Minutes

Introductions
Ken Rubin – SOA WG attended and asked for some time. He came to express the willingness and interest to continue collaborating between the WGs
He has been involved with efforts around Coordination of Care service. Within this work the subject of resource management and scheduling services was raised. Although the team saw the value and need for this, it seemed that this was not appropriate to keep under the Coordination of Care “umbrella”. He wanted to bring this to the team as potential home within our domain and a potential collaborative opportunity for the two work groups.
Daniel asked if this was similar to profiles. Within OMG, there are Service Functional Model (SFM) there are service profiles
FHIR DSTU 2 Ballot Reconciliation
Tracker # 5291 A-S
Existing Wording:
As such in most cases planned encounters are not really considered an appointment, but an intent that the location is being prepared for the encounter to occur. During this time the patient may or may not be present at the location.
Proposed Wording:
As such an encounter in "planned" status is not identical to the appointment that scheduled it, but is the encounter prior to the its actual occurrence, with the expectation that encounter will be updated as it progresses to completion. Patient arrival at a location does not necessarily mean the start of the encounter (e.g., a patient arrives an hour earlier than he is actually seen by a practitioner).
Comments:
Confusing as to why a planned encounter is not consider an appointment, because "an appointment is used for establishing a date for the encounter" "In most cases" also introduces ambiguity. The proposed wording tries to simplify by focusing only on the distinction between appointment and planned encounter.
The WG agrees and will accept the new wording

Tracker #5292
EpisodeOfCare
Existing Wording:
EpisodeOfCare: Case, Program, Problem
Proposed Wording:
EpisodeOfCare: Case, Program
Comments:
Suggest removing "problem" as the Episode of Care may be for treatment of a problem, but is not synonymous with the problem. Similarly, an Encounter may be for a specific problem, but you wouldn't call the Encounter the Problem.

The WG discussed this and noted that some General Practice systems are specifically focused on the case, or problem and are known as “Problem-Based” in their General Practice systems. This is not related to Problem, Allergy, Medication, Immunization (PAMI).
Explained no change.

Tracker# 5411 Neg-Maj
Patient
Existing Wording:
Patient.animal
Comments:
The inclusion of animal in the Patient is an indication of RIM-based design by constraint approach to resource design. In the applications that I have been able to survey, not one has a need to mix human and non-human patients in either an exchange or in the back end repositories. If you were to apply the 80% 'rule' you would create a Patient resource and a NonHumanPatient resource.
Grahame's Comments:
There are many such systems; I managed one. We did create a patient and animal resource, but in the end this proved too difficult, and after much debate and trying several options, we elected to go with this least worst design

Disposition:
Not Persuasive
Disposition Comment:
There are examples of systems that mix human and non-human. Furthermore, human-based software can be used in animal-specific settings. There was a conscious decision in this situation to not follow the 80% rule to make clear that FHIR was intended to support veterinary care. The alternative - having a separate resource for animal patients would have required every reference to patient to instead reference two alternate near-identical resources. This complexity wasn't justified.

The WG discussed this and agrees with the problem and the survey of the applications, however, we support Graham’s comment that this may be the lest problematic of the available choices this is based on the consideration brought up by Alexander H. that came up during discussion is that creating a different resource “e.g. NonHumanPatient” would require a choice reference for this field of Patient, necessitating profiles to remove the choice to NonHumaPatient.

A motion was made Brian to leave the resource as is and provide the additional reasoning as noted above, extending on Graham’s disposition comment. Alex de Leon seconds.
Discussion: None.
Vote: 6/1/0

Tracker #5412 Neg-Mi
Patient
Patient.communication
Comments:
There is no way to specify the preferred communication (or language) for a patient. For an individual codeableConcept in the coomunication list, one of the Codings may be marked as primary but this does not indicate the primary communication. The primary on Coding only serves to indicate the 'original' or 'preferred' coding is a series of synonyms (ie. English expressed in two difference coding systems). You would not put english and Spanish in an individual communication item.
Grahame's Comments:
agree about primary. No opinion on the underlying language issue

The WG discussed this and decided to adopt a new structure for communication.
Interpreter required would be a standard extension:
Communication 0..*

Language 1…1

Peferred 0…1

(proficiency Level would be standard extension)

Daniel commented that this may be a duplicate submitted by him (#3743). Below
It appears that for simplicity's sake, the languages that a patient understands has been implemented as a CodeableConcept (list). Where a patient is a native speaker, the specification sets the expectation that there is Patient.communication ought to be kept empty. This will likely be a large percentage of exchanges of the patient resource.

When Patient.communication is provided, however, I believe that a user of a client application that is querying a FHIR server may not be able to use the Patient.communication data in a meaningful way because of the absence of information regarding the patient's proficiency level with speaking the native language.

We should consider enhancing Patient.Communication to track proficiency level and/or "needs interpreter" information as I believe that the majority of the systems that would track a patient's languages would also track this information.

Places where patients language is tracked along-side other "modifier" about that language:
HL7v2 LAN segment: LAN-2 = language, LAN-3 = Ability Code, LAN-4 = Proficiency Code
UK national EMPI service -> "Language Communication" object contains the language along with "Interpreter required indicator".
I don't know of systems that track whether or not the patient can read vs. write the language that is being recorded. I do know of systems that explicitly track "needs interpreter". I'm thinking that the later might be something worth including as part of Patient.communication (and thus it would need to be expanded from being just a CodeableConcept).
Submitting for discussion at the next available PA group meeting.

Motion was made by Brian to change the communication element as a nested structure and including interperester required and proficiency as standard extensions (See tracker item # 5412 and 3743)
Discusssion: None
Vote: 7/0/0
Motion Passes.

Meeting Outcomes

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

Next Meeting/Preliminary Agenda Items .

Wednesday Q4

HL7 Patient Administration Meeting Minutes Location: Directors Conference Room		Date: 2015-01-21 Time: Wednesday Q4
’‘‘Chair’’’	Line Saele	’‘‘Scribe’’’	Alex de Leon
Attendee	Name	Affiliation
X	Line Saele	HL7 Norway
X	Peter Bernhardt	Relay Health, USA
X	Josh Roberson	EPIC, USA
X	Prashant Trivedi	NHS, UK
X	Alex de Leon	Kaiser PermanenteD
X	Melissa Taylor	WebMD, USA
X	Toril Ormberg Reite	HL7 Norway
X	Martin Smits	Furore, The Netherlands
X	Brian Postlethwaite	Health Connex, Australia
X	Iryna Roy	Gevity, Canada
X	Rien Wertheim	Furore, The Netherlands
Quorum Requirements Met (Chair + 2 members): Yes

Agenda

Agenda Topics

• FHIR QA Updates to DSTU 1 Patient Administration Resources

Supporting Documents

• FHIR Patient Administration Resource Development Wiki Page
  

Minutes

Tracker # 5413
neg minor submitted on behalf of Andy Stetchshin.

Practitioner birthdate worth recording in systems?

Brian: choice of leaving it where it is or make a standard ext.

Melissa stated it is used for identity verification in their product.

Norway uses it (for search). As does Australia. Epic has it in its database.

Motion was made by Brian to respond to this item to indicate that birthdate remain and has been recorded in majority systems of those present and should not be moved into an extension. Alex de Leon seconds.
Discussion: None
Vote: 10/0/0
Motion passes.

Tracker 5414 Neg
Existing Wording:
Practitioner.gender
Comments:
Is there compelling evidence that most applications record the gender for a practitioner? This is unheard of in Canada, no system that I have worked with (the majority of Provider registries within Canada) recorded gender. Is Canada the exception in recording Practitioner information? (yes I know both comments look similar, Canada tracks neither birthdate nor gender in their practitioner registries) Grahame's Comments:
there are countries where this MATTERS. And other countries that track it anyway. But I have no strong opinion

This is a very important for the majority of systems providing care to record the gender of the practitioners to facilitate patient preference for selecting specific genders (and can be more important in some cultures).
Brian moves to adopt the text above and reject the tracker author’s negative. Martin seconds.
Discussion: None
Vote: 10/0/0
Motion passes.

Tracker #5415 A-Q
Practitioner.communication
Existing Wording:
Practitioner.communication
Comments:
Would adding somewhy to determine the primary communication for a practitioner be valuable
We believe that most systems do not have a concept of practitioners primary language. The languages provided in the communcition field should be considered that the practitioner is able to communicate medical information to patients.

Tracker# 5416 Neg-Mj
Existing Wording:
Practitioner.organization 0..1
Proposed Wording:
Practitioner.organization 0..*
Comments:
Practitioners work with multiple organizations. This was identified in a tracker item but the proposed linking using Person really is not functional, so I am raising this again. To use the Person as proposed would limiting identifier to 0..1 and moving qualifications for Person (which in turn does not make sense if you are also using Person to point to Patients). Or the qualifications would need to be updated on each Practitioner instance for the various organizations the Practitioner works for. Really the simple solution is to make organization 0..*

Tracker #5418 Neg Mi
Existing Wording:
Longitude as expressed in KML
Proposed Wording:
Longitude with WGS84 datum.
Comments:
Referencing KML is misleading to implementors. Stating the this is the same value that can be injected directly into KML is useful.

Brian moves to update the text for longitude, latitude, altitude from the google KML specification to the appropriate datatype (WGS84 datum). Martin seconds.
Discussion: Prashant asked about position. This is one way to get to position. The UK has a specific coordinate system mapping postal codes to unique numbers. This is used for ambulance dispatch. Brian noted that that could still be done through an extension. The WGS84 is within the 80% usage for this.
Vote: 10/0/0
Motion passes

Tracker #5419 Neg Mi
Existing Wording:
Latitude as expressed in KML
Proposed Wording:
Latitude with WGS84 datum.
Comments:
Referencing KML is misleading to implementors. Stating the this is the same value that can be injected directly into KML is useful.

Duplicate of 5418. See disposition and vote there.

Tracker# 5420 Neg - MI
Existing Wording:
Altitude as expressed in KML
Proposed Wording:
Distance above the earth's surface, in meters (taken from the KML documentation)
Comments:
Referencing KML is misleading to implementors. Stating the this is the same value that can be injected directly into KML is useful.
Duplicate of 5418. See disposition and vote there.

Tracker #5421 Neg Mi
Person
Comments:
I have concerns with this resource in general. In Canada, we never associate a Practitioner in the healthcare system with their interactions as a Patient within the healthcare system. This may be different in different countries. Also, this resource seems a large step backwards, FHIR originally had a Person in addition to Patient and Practitioner and the implementors said it made implementation needlessly complex. Patient already has a link class to link together multiple occurrences for an single individual, what use case is this solving? If it is necessary to link a Practitioner to their occurence as a Patient, then Practitioner should have a link (and I would need to be convinced that this was really something that the moajority of applications do)
Grahame's Comments:
need to add a little more documentation, but also, this is not the same as we had - Person is solving a different problem
Disposition:
Not Persuasive
Disposition Comment:
Person allows linking a variety of types. It can be used to link multiple Patient records, link Patient and RelatedPerson records. It can also be used to link multiple Practitioner records. Will add language to make these multiple potential uses.
Although the existing resource definition permits such a usage, the “Person and Linking” section clearly describes the 2 expected scenarios, which do not include the linkage of Patient with Practitioner resources.
Motion was made by Iryna to make no change and respond as noted above, and seconded by Brian
Discussion: None
Vote: 10/0/0

Tracker# 5302 A-S
Slot
Existing Wording:
The free/busy status of an appointment
Proposed Wording:
The free/busy status of an slot
Comments:
The slot does not contain information about the appointment but about the slot.

This is in the terminology/bindings section. The WG agrees with the suggestion. The phrase “an appointment” will be replaced with “a slot”.
Tracker #5303 A-S
Existing Wording:
Slots are categorized as open, booked, or blocked.
Comments:
Either revise this description to be consistent with the SlotStatus value set (BUSY, FREE, BUSY-UNAVAILABLE, BUSY-TENTATIVE), or change the value set to have values of open/booked/blocked

The Scope and usage text will be updated to remove the V2 reference and v2 text.

Tracker # 5301 A-T
Existing Wording:
Need to describe Searching for "Schedule's" that belong to a HealthcareService using Categories, or where using pracitioners or locations as the actor, then the "type" field is expected to be used to store the service categories. Advice to use as an actor. Also consider

Proposed Wording:
Need to describe Searching for "Schedules" that belong to a HealthcareService using Categories, or where using practitioners or locations as the actor, then the "type" field is expected to be used to store the service categories. To be added: advice to use as an actor, other considerations...

This is under the Scope and Usage. This will be reworded to provide more accurate information and the references to the v2 specifications will be removed.

Tracker # 5299 A-S
Appointment
Existing Wording:
A scheduled healthcare event for a patient and/or practitioner(s) where a service may take place at a specific date/time.
Proposed Wording:
A scheduled booking of a healthcare event (such as an Encounter) among patient(s) and/or practitioner(s) or other resources where the event may take place at a specific date/time.
Comments:
The resource allows for appointments for other things besides patients and practitioners, e.g., locations or equipment as mentioned later. I also added "reservation for" since the appointment is not the event itself (which may end up not happening). Similar to the distinction between appointment and encounter. "Booking" may not be the best word, but I didn't want to use "appointment" to describe itself. "Reservation" could also be used instead of "booking" but booking is used elsewhere on the page. Also, an appointment could cover multiple patients.
The "event" may not necessarily contain a "service"

The WG worked on the sentence and came up with “The booking of a healthcare event among a patient(s), practitioner(s), related person(s) and/or device(s) for a specific date/time. This may result in one or encounter.”

Tracker# 5300 A-S
Appointment
AppointmentResponse
Comments:
Both 5.24.1.1 and 5.24.1.2 seem out of place in the FHIR spec While they are helpful, the way they are written is very different from most other parts of FHIR, and seem more appropriate for a use case document, not FHIR. If included at all, the workflow is just illustrative, not normative, so it should be relegated to an "Examples" or "Appendix" tab rather than the main spec.
After much discussions and many meetings, this text has been proving very useful in understanding how to use the understanding the use of the Appointment set of resources within the appointment workflow. The WG discussed this and decided to keep the text where it is.

The WG has 5 tracker items left. These area expected to be resolved during the telecom meetings before the FHIR Management Group due dates.
Rejected, Explained no change
WG Adjourned at 5:10PM

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 PA January 2015 WGM
• Return to PA Main Page

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