2015-05-12 PA WGM Minutes

Patient Administration Work Group Meeting - Tuesday May 12, 2015

Tuesday Q1

HL7 Patient Administration Meeting Minutes Location: Hyatt, Paris, France, Room #2331		Date: 2015-05-12 Time: Tuesday Q1
Facilitator	Line Saele	Note taker	Alexander de Leon
Attendee	Name	Affiliation
X	Line Saele	Helse Vest IKT Norway
Quorum Requirements Met (Chair + 2 members): Yes

Agenda

Agenda Topics

Supporting Documents

Minutes

Minutes/Conclusions Reached:
Introductions
FHIR Core team.
Graham complimented the PAWG on their responsiveness to implementors and work toward development of FHIR resources. He spoke about HIMMS and an effort around “patient matching” algorithms, presumably to match and merge records. This is also being talked about for patient consent. Creating services around this. HIMMS. USA in August. CBCC doing consent.
DSTU 2.1
There are some parts of FHIR that are more mature than others. Maturity framework for FHIR. So the higher level of maturity FHIR resources will be published as DSTU 2. Holding the mature stuff stable. Patient, Encounter and Practitioner are considered very mature.
So there is a FHIR Maturity Model which defines 5 levels of maturity for resources.
DSTU 2 July timeline to finish up the PA ballot reconciliation and apply the changes. This includes all maturity levels. The term “ballot reconciliation” includes actual ballot comments and any QA items that came forth as a part of the FHIR QA process.
The WG continued with the FHIR work since there are aggressive timelines. There are 110 ballot comment items at this time.
First the negative major items were addressed.

1. 7346 - address element - references 3918 – this has to do with “address” which is not sufficient information for how to make this work for patient queries. Suggestion to break out any address related search parameters for more specificity. Include 1 or 2 of the most common items to assist patient search allow adding search parameters, such as comeCity, homePostalCode.
   

The WG discussed and considered defining individual search parameters: City, state, postcode, country.
Graham moved to define “addressCity”, “addressState”, “addressPostCode” “addressCountry” and “addressUse” (for the type of address) as search parameters for address, Peter seconds.
Discussion: The WG discussed whether this was just about patient address or all addresses. This is for all addresses. This proposal would be for adding these search parameters to the current search nor replacing the current search. Patient, Person, Practitioner Location Organization and RelatedPerson.
Vote(for/against/abstain): 13/0/0

1. 7506 – Encounter - There should be a rule that that all resources that have an identifier element have an identifier search parameter. This was pertinent for Encounter.
   

Graham moved to add the identifier search parameter to Encounter. Brian seconded.
Discussion: During QA cycle any other resources will be updated with this as they arise.
Vote(for/against/abstain): 13/0/0

1. 7348 – Appointment - the use of participant needs further definition and clarification. Please define the required elements for each participant in the list – a participant without an actor is meaningless.
   

Brian moves to include an invariant to enforces that there is either type and/or actor on the participant Additional documentation on the element and supporting notes better describing the use cases where the actor can be expected to be null. Irma seconded.
Discussion: Not persuasive with mod.
Vote (for/against/abstain): 12/0/1
Graham asked for the WG to look at 4 tasks and discuss them.

1. 8047 – We need a system URI for NPI (National Provider ID)
   

Graham suggests that we work with vocabulary work group as to creating this since they have the experience. There will be a US realm discussion on this and further on Q4.

1. 7114 – Make Race and Ethnicity core. Make a comment “Race and ethnicity not in core due to variabililty around the world” or something that explicitly states that these two elements were not included and directing them to the US Realm location for usage.
   
2. 7301 – BirthTime – the resources are not consistent. Person was missed in “clean up”. It will be done.
   
3. 7606 – Deceased – Suggest re-reviewing whether overloaded attributes should in fact be separate attributes. E/g. patient. Deceased is allowed to be both Boolean and dateTime. It seems like there should be a Patient.
   

Meeting Outcomes

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

Next Meeting/Preliminary Agenda Items .

Tuesday Q2

HL7 Patient Administration Meeting Minutes Location: Hilton Chicago, Guest Room #1704		Date: 2015-05-12 Time: Tuesday Q2
Facilitator	Line Saele	Note taker	Alex de Leon
Attendee	Name	Affiliation
X	Line Saele	Helse Vest IKT Norway
Quorum Requirements Met (Chair + 2 members): Yes

Agenda

Agenda Topics

Supporting Documents

Minutes

Minutes/Conclusions Reached: FHIR Reconciliation

1. 6912 – Episodes of care – The relationship between an encounter and episode of care is not parent child. Mayo has encounters linked to multiple episodes of care. (see attached document: Episode of Care and Encounters.pdf).
   

Two patterns could be considered, encounters pointing to episodes of care or episode of care pointing to contained encounters. Mayo implmenters have expressed a desire to have episode(s) of care point to associated encounters. They would like to leave encounters untouched when grouping them under an episode of care.

Existing Wording: An episode of care that this encounter should be recorded against - also the UML Diagram Proposed Wording: Episodes of care can overlap and reference common encounters.

Makes sense to the work group. The WG considered changing the cardinality of episodeOfCare from “0..1” to 1..*.

The WG discussed the various use cases where multiple encounters can be within one episode of care, or multiple

Brian moved to change the cardinality of the EpisodeOfCare property on the encounter resource from 0..1 to 0..*, and also include additional notes describing the usage between the 2 and that profiling may be used to constrain for specific use cases. Irma seconded.

Vote: 7/0/1

1. 7098 – Duplicate of # 6912
   

1. 7965 – Duplicate of # 7348
   

1. 7347 – Schedule actor has resource type of any – The type of actor should be limited to resources which can realistically be scheduled, not any resource. This should be consistent with the type of actor supported by appointment.
   

Irma moved to update the actor reference type from any to Patient/ practitioner/ RelatedPerson, Device healthcareService, location, making it consistent with appointment, Brian seconded.
Discussion:
Vote(for/against/abstain) : 7/0/1

1. 7966 duplicate of 7347
   
2. 6126 - make clear that related person and practioner be an animal. Add to notes. Lloyd has submitted this and has requested an in person resolution. Since this is in person, the chair will send a message to Lloyd for his time.
   
3. 6928 – Make race Ethnicity core on Person Resource– Provide some guidance notes in the introduction of the Patient resource to explain that race and ethnicity properties widely differ between jurisdiction and properties and refer to the profile.
   

The WG discussed this at length, especially after Graham’s suggestion. After much discussion, the WG suggested
Brian moves to include the following text at the top of the patient resource. “Not all concepts are included within the base core resources (e.g. ethnicity, organ donor status, nationality, etc.) but may be found in in profiles defined for specific jurisdictions or standard extensions found at <URI>)”. Nat seconded.
Discussion:
Vote (for/against/abstain): 7/0/1

1. 7085 – Patient - What about patient preferences which may impact their healthcare, such as religion, diet, preference for exercise over surgery, etc.?
   

The WG discussed this and could find use cases for this. However, this seems like they should be standard extensions, however, some, such as religion might only be under profile.
Brian moves to reply with the following text. Irma seconded:
“These types of information unlikely to become part of the core resource, however the WG would be happy to include some specific standard extensions if clearly defined. The issue with defining a “standard extension” would be defining valueset that can apply globally. For example, in some jurisdictions, religion is not permitted to be captured or even asked and where it is permitted the value sets that would be used are not likely to be the same”
Discussion:
Vote(for/against/abstain): 7/0/1
The WG then briefly discussed the patientAccount to get the U.K. perspective. In the U.K., Prashant noted, payments are made per patient outcome. There is no aggregation of cost of care data within an account.

Meeting Outcomes

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

Next Meeting/Preliminary Agenda Items .

Tuesday Q3

HL7 Patient Administration Meeting Minutes Location: Constellation C		Date: 2015-05-12 Time: Tuesday Q3
Facilitator	Line Saele	Note taker	Alex de Leon
Attendee	Name	Affiliation
X	Line Saele	Helse Vest IKT Norway
Quorum Requirements Met (Chair + 2 members): Yes/No

Agenda

Agenda Topics

Supporting Documents

Minutes

Minutes/Conclusions Reached: The WG continued with the reconciliation of FHIR DSTU 2:

1. 6126 - make clear that related person and practioner be an animal. Add to notes. Lloyd has submitted this and has requested an in person resolution. Since this is in person, the chair will send a message to Lloyd for his time.
   

Lloyd joined the group and explained that there is no computable way to know that a patient is non human beyond the absence of seeing animal elements. If there is a need to know that a patient is human or non human, then we should flag it.
Animals do not only manifest as patients but can manifest as practitioners. Animals might be acting in a relationship to a patient. If this needs to be communicated, then the only way it can be communicated would be with the RelatedPerson resource. Usage note that might say that although these resources are designed around the idea that these are human, in the case where these are animals acting in this capacity, these could be used and add the elements for animals such as “species” or “breed” as a standard extension.
The WG discussed the distinction of “practitioner” and “relatedPerson” in the context. As an example, if the patient owns the animal who is providing a service or “doing something” for the patient, then the appropriate resource to use to communicate this would be “relatedPerson”, while.. if the animal is providing a health related service for an organization to a patient, the best resource to communicate this would be “practitioner”.
Brian moved to include the following text into the “Boundaries and Relationships” and also to include species as a standard extension. Lloyd seconds:
The distinction between a Practitioner and a RelatedPerson, would be based on whether the person/animal operates on behalf of the care delivery organization over multiple patients (Practitioner) or, where the person/animal is not associated with the organization, and instead is allocated tasks specifically for the RelatedPerson's patient (RelatedPerson).
Discussion:
Vote (for/against/abstain): 5/1/1

1. 3655 – Need to allow for patients where there no indication of human vs animals.
   

While the humans involved in capturing a Patient record would likely always know whether a given patient is a human or an animal, this isn't always conveyed by underlying systems as a discrete element. It could well be buried in text. From a discrete information perspective, there may be no means to tell that a patient is a human or a cat - and furthermore, no need to tell. We therefore can't use the presence or absense of "animal" to infer animal vs. human because that leaves no way to communicate "don't know/data absent". There are lots of systems that deal with humans but may occasionally deal with an animal (e.g. community pharmacy systems) that would have no way of determining whether to send the "animal" element. Right now, they would likely omit the element and have other systems infer that the data always referred to humans when in some cases it might not.
Lloyd explained that there are going to be systems that deal with humans and animals, that do not have a “computable way” to identify patients as animals.
Either PAWG can include usage notes clearly noting that the lack of usage of the elements normally associated with animals does not necessarily imply that the patient is a human or a specific flag can be used to indicate an animal.
Lloyd moved the following, and Nat seconded:

Update the definition of the animal property description from:

"This element has a value if the patient is an animal."

to

"This patient is known to be an animal."

Update the comments section of the animal property from:

"The animal element is labeled "Is Modifier" since patients may be non-human. Systems SHALL either handle patient details appropriately (e.g. inform users patient is not human) or reject non-human patient records."

to

"The animal element is labeled "Is Modifier" since patients may be non-human. Systems SHALL either handle patient details appropriately (e.g. inform users patient is not human) or reject declared animal records.

The absense of the animal element does not imply that the patient is a human. If a system requires such a positive assertion that the patient is human, an extension will be required.

(Do not use a species of homo-sapiens in animal species, as this would incorrectly infer that the patient is an animal)

The absence of the animal element does not imply that the patient is a human. If a system requires such a positive assertion that the patient is human, an extension will be required. (Do not use a species of homo-sapiens in animial species as this would lead systems to infer that the patient is an animal>
Discussion:
Vote (for/against/abstain): 5/0/2

1. 6124 – it would be useful to have a solid statement somewhere that Practitioner + Patient + RelatedPerson=Everyone
   

Lloyd is looking for clear guidance on where Person where can and cannot be used. Lloyd noted that FMG allowed this with the premise that this would be used as a mapping vector.

Meeting Outcomes

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

Next Meeting/Preliminary Agenda Items .

Tuesday Q4

HL7 Patient Administration Meeting Minutes Location: Hyatt Paris, France, Guest Room #2331		Date: 2015-05-12 Time: Tuesday Q4
Facilitator	Irma Jongeneel	Note taker	Alex de Leon
Attendee	Name	Affiliation
X	Line Saele	Helse Vest IKT Norway
Quorum Requirements Met (Chair + 3 members): Yes

Agenda

Agenda Topics

1. 3 Year Work Plan – FHIR

Supporting Documents

Minutes

Minutes/Conclusions Reached: The WG created a webex to include our collegue Daniel Lowenstein to address their face to face comment.
Christian moved to accept all type ballot comments in one vote. Specifically 6955, 6956 7608 7650 7652 7896. Line seconded.
Discussion: None
Vote (for/against/abstain): 8/0/0

1. 7343 The participant needs to indicate if they accept the appointment by changing this status to one of the other statuses. Accepted, declined, tentative, unknown.
   

Brian moves to remain with the current definitions of statuses as they are. Line seconds.
Discussion: None
Vote: 6/0/2

1. 7344 Clarify the use case for location. Some ambiguity of when to use Location vs. when to use Organization.
   

Brian noted that the problem does exist but it exists in the space. Many systems blur the lines between organizational structures and use them based on location or organizational structure.
After some discussion, the WG invited any further text to make less ambiguous the usage of either. The submitters have agreed to review and try to provide further text.
Action Item: Awaiting further input from submitter. Responsible: Daniel/Sam, Due: July 1, 2015

1. 7345 – Require server/client behavior for merged patients.
   

Existing Wording: This specification does not specify merge functionality: if multiple patient records are found to be duplicates, they can be linked together, as described above.
The WG discussed suggested options provided in the following text from the tracker:

If for some reason a server doesn't keep around a record of the source of a merge, then it has no option but to respond with a 404 when receiving a resource ID of a merged off patient record.
Alternatively, when a server does keep a record of the merged off resource ID there are a few different alternatives for the server's behavior
A. Respond with whatever information is available for the source record's resource Id and (hopefully) include Link so that the client can traverse to the target record.
B. Respond with a 404 so that the client's user re-queries with demographic information to get the resource Id of the target record.
C. Respond with a 301 to redirect the client to the appropriate resource.

For the sake of having both clients and servers be able to gracefully handle merged off patient records, we feel that the specification should not leave this behavior open-ended.
Planning to discuss with PA at Q4 on Tuesday.
The WG discussed these options at length.
Brian introduced another option to create an operation for Patient to essentially create business rules to merge patients.
Alex noted that the original comment was about requiring client/server behavior however, within this discussion it’s clear that there are differing client/server behaviors that both have their merits for what happens in a patient merge (or link). Therefore while there should be maybe some guidance or recommendation on behavior, these behaviors should not be required.
Other options considered included using a new patient operation to perform the merge, and also what searching for other resourced. E.g. observations should do when apatient record has been linked.
(should you get observatinos from all linked/merged patient records while searching?)
Server based workflows and business rules will need to be considered when updating this guidance text on the patient resources.
Action Item: More input for guidance from group. Responsible: Brian/Peter/Daniel, Due: july 1, 2015

1. 7346 – Duplicate of #3918
   

This was discussed this morning. Daniel was asked to review the resolution.

1. 7347 – Already addressed
   

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 May 2015 WGM

© 2007-2015 Health Level Seven® International. All rights reserved.Patient Administration – Tuesday, May 12, 2015