2017-01-18 PA WGM Minutes

Return to: WGM Minutes > 2017 > January San Antonio

Patient Administration Work Group Minutes - January 18, 2017

Wednesday Q1

HL7 Patient Administration Meeting Minutes 'Location: Hyatt Regency San Antonio – Directors Conference Room		Date: 2017-01-18 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	Wes Rishel	Self, USA
X	Simone Heckmann	HL7 Germany
X	Andrew Tores	Cerner, USA
X	Richard Cavanaugh	NHS, UK
X	Farzanah Nahiel	NHS Digital, UK
X	Christian Hay	GS1, Switzerland
X	Sam Rubenstein	Montefiore, USA
X	Sam Mater	EPIC, USA
X	Cooper Thompson	EPIC, USA
X	Nick Radov	Optum, USA
X	Nancy Orvis	DoD/Military Health, USA
Quorum Requirements Met (Chair + 2 members): Yes

Agenda

Agenda Topics
Welcome/introductions

1. FHIR STU3 resource work

• Beef up use cases 11471
• PatientRelationshipType 11929
• RelatedPerson.relationship 10524
• Attorney relationship 12141
• ValueSet for RelatedPerson.relationship 9242
• Add triaged to Encounter.status 12620

Minutes

Minutes/Conclusions Reached:
Introduction

FHIR STU3 Resource

1. 12620 -Add a status of triaged to the Encounter.status value set
   

Based discussion on tracker 9276, there was a desire to add a status of "triaged" to the Encounter status value set: http://build.fhir.org/valueset-encounter-status.html
The patient has been assessed for the priority of their treatment based on the severity of their condition.
This is used after the triage assessment, and they are waiting.

Internal business rules will indicate the appropriate sequence of statuses but usually after arrival but bfore in ptorgress
Moved by Brian seconded by Wes to add the status of triaged to Encounter.status. Discussion: Drew asked if there was a reason that the binding does not have Unknown and Other. He felt that this might be a QA requirement. Brian answered that if a binding was not considered to be a complete set then those might be needed. Since the addition of this status completes the set, then there may not need to be added. The WG noted that this is a required field so it cannot be blank.

The WG discussed various statuses and how this binding would cover those scenarios (e.g. left to spoke, etc.). Drew noted that he will create a tracker item to include Unknown and Other. This does not effect the decision in this case.

Vote: 14/0/0

The WG discussed the update to the text being updated in the FHIR specification. Brian explained how it would be updated.

1. 9242 - ValueSet for RelatedPerson.relationship is too large

Monitor item
The ValueSet for RelatedPerson.relationship is too large and concepts are overlapping
e.g. What am I supposed to pick for "father"? family / parent / FAMMEMB / FTH ??
I believe the 80% requires a lot less detail.
Also, there's no need to have codes for both gender versions of each relationship since the RelatedPerson also has a gender attribute
mother = relationship(parent)+gender(female)

The WG reviewed the FHIR specification and noted that this value set includes both the V2 concepts and v3 concepts combined. This does include quite a few overlapping options.

The WG reviewed the Valueset resource doesn’t have all elements to depict a hierarchy (used for PatientRelationshipType). So, in looking to answer this tracker, the issue that the hierarchy is not visible came up. This may need a tracker of its own.
The expansion for this valueset is quite large with other tracker items to add to this binding (e.g. attorneys, etc.) which would result in an even larger list. There are also several jurisdictions that would prefer o use entirely different valuesets in place f the noted ses. As a results the WG will relax the binding from extensible to preferred so that local valuesets can be used.
The relationship element of the RelatedPerson resource uses the PatientRelationshipType which includes both v2 and v3 bindings.
The WG noted that there are other tracker items involvd in the value set, such as:

12141 - Add a code for 'Attorney' to relationship and participant.role value sets
The committee feels this should not be part of the standard binding, but since the code has an extensible binding, the code can be added if needed.

11929 – Recommend PatientRelationshipType https://www.hl7.org/fhir/valueset-relatedperson-relationshiptype.html - 2016-09 daf #13 Has already been changed in the current build.
These tracker items are associated as they are related persons. Therefore, to allow use of local values, the binding is being changed to preferred from extensive
A motion was made by Brian to related person relationship type value binding will e relaxed from extensible to preferrerd (was required in DSTU2) and no change made to Patient.contact.relationship. This will serve as a block vote for 9242, 12141, 10524, 11929. Seconded by Irma.
Discussion: None
Vote: 14/0/0
Motion passes: persuasive with mod.

1. 11471 - Beef up use-cases - 2016-09 core #635
   

Use-cases section needs to talk about encounters & episodes, managing device-level configuration & communication and other stuff - make sure you've covered the primary use-cases for all resources. (And while you're at it, get rid of the extra blank bullet point :))

The WG reviewed the PA use cases draft by Brian for the administrative module.

Nancy – Value set changes for encounter.status 12620 add a value of triage with a definition to the FHIR binding. This may need that v2 and v3 may need to be updated. Irma noted that it should not be a default behavior to add to previous version bindings just for consistency.

Brian moved to add the following use cases into the Administration module:
Managing a Master Record of a Patient and a Person (e.g. MPI) - A #Patient resource is used to describe patient demographic and visit information and any updates to it. It can be used to communicate #Patient information to other systems (e.g. other registries, clinical, ancillary and financial systems). Some systems distinguish the Patient Registry (or Client Registry) from the Person Registry. A #Person resource is a base for the Person Registry system. The Patient/Person Management use case includes creation, update, as well as merge/unmerge and link/unlink scenarios.
Managing a Master Record of a Provider and Service Catalogue (e.g. Provider Registry, Service Directory) – A #Practitioner resource is a base resource for enabling the registry of individuals, related to providing health care services. Other resources, such as #Organization, #Location, #HealthcareService, are creating a complete picture of where, how and by whom the care services are enabled to a patient. The resources can be used for managing the master record or as a reference in clinical resources to inform about participants and places for various clinical resources.
Managing Other Administrative Records – The Administration domain of the FHIR standard includes creation and update of #Device and #Substance records. Resources can be used for managing a master record or communicating its information to other systems.
Enabling Patient Profiles, Clinical Reporting, Connecting clinical records – Administration Resources are referred by almost all clinical resources. Querying systems, using the references to Administration Resources enables the creation of profiles and reports of various complexities.
Enabling Clinical Grouping and Financial Reporting – Other use cases are included in the roadmap of resources, developed by the Patient Administration group. The roadmap section lists plans and updates of the current work.

Cooper seconded.
Discussion: None
Vote: 14/0/0

Meeting Outcomes

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

Next Meeting/Preliminary Agenda Items .

Wednesday Q2

HL7 Patient Administration Meeting Minutes 'Location: Hyatt Regency San Antonio – Directors Conference Room		Date: 2017-01-18 Time: Wednesday Q2
Facilitator	Brian Postlethwaite	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	Wes Rishel	Self, USA
X	Richard Cavanaugh	NHS Digital
X	Farzanah Nahid	NHS Digital
X	Michael Tan	NICTIZ, The Netherlands
X	Sam Rubenstein	Montefiore, USA
X	Sam Mater	EPIC, USA
X	Cooper Thompson	EPIC, USA
X	Amit Popat	EPIC, USA
X	Dave Carlson	Veteran’s Administration, USA
Quorum Requirements Met (Chair +2 members): Yes

Agenda

Agenda Topics

1. FHIR STU3 PA Resources . PC representative will join - PractitionerRole separation, CareTeam, EpisodeOfCare discussions

• Location-specific practitioner contact info 9622
• Living situation 9235
• Procedure ranking 9226

Supporting Documents

Minutes

Minutes/Conclusions Reached:

Patient Care representation.
Introductions

The WG discussed the CareTeam resource as a shared interest to both work groups.
Michellle noted that during the QA process, many items have come up that could be discussed here.
CareteamCategory valueset was show.
Michelle noted some of the changes, such as the addition of a care team potentially being part of another care team for CareTeam.participant.member to include another care team.
The WG discussed CareTeam.participant.role cardinality. Right now it is “0…1”. Brian suggested that this might open up to “0...*”. However if one member has more than one role, there could be multiple participants.

1. EposideOfCare -
   

Condition resourse was reviewed. The Patient Care representatives felt that this is fairly well worked out as a resource.

PractitionerRole separate from Practioner.
Brian reveiewed the practioner and practitioner role items.

Brign noted that these changes might affect the CareTEam resource for the member. Practitioner references:
Add the Organization next to the Practitioner or add PractitonerRole.

If implementors would want to reference practitioner role. The issue was about refrencing the practitioner in his/her role within various contexts.

The main issue is the ability to update the practitioner role without updating the practitioner.

PractitionerRole is merely relevant in the context of ProviderDirectories, in most other cases referencing the provider and maybe organization would be sufficient. Action item: Notify the other work groups as owners of other resources that reference practitioner resource, that they will require additional properties to capture the context of use, given that the practitioner is able to reference other organizations. We will provide example guidance, such as CareTeam where (potential) context is needed and another where it is not needed. Responsible: Brian Due: San Antonio WGM.

Patient Care commited to the addition element will be added to CareTeam, potentially called PractitionerOrganization… with an invariant stating that this is to be used only when the member is a Practitioner.
Amit moved to create a standard extention element called PractionerOrganization, on references from all the resources referencing Practitoiner, which is a reference to an organization specifically for the Practitioner with the understanding that usage notes will clarify the context. Michelle seconds. Discussion: None. Vote: 14/0/0
Action: Pratitioner pade will have a new section to describe referernces to practitioner and roles/organization reference. Also when to reference PractitionerRole or Practitoner with addition of PractitionerOrganization extentino.

1. 9226 - Provide a way to rank procedures in the context of an encounter. Provide a way to rank procedures in the context of an encounter (e.g. main procedure/most clinically significant).
   

Michelle noted that there is a discussion to split the Procedure into two to depict surgercal procedure, into stated procedure. Perform versus patient stated procedures In one case ranking or prioritization makes sense while in the other it may not.
The WG reviewed the Encounter resource which has the Encounter.indication which references Condition or Procedure. There was a discussion around whether the references should be reversed so that the procedure references the Encounter.
Add a sequience # to the condition resource or take the reference off condition to Encounter and make a multiple procedure references off Encounter.

We will continue this discussion in Q4 today.

Meeting Outcomes

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

Next Meeting/Preliminary Agenda Items .

Wednesday Q3

HL7 Patient Administration Meeting Minutes 'Location: Hyatt Regency San Antonio – Directors Conference Room		Date: 2017-01-18 Time: Wednesday Q3
Facilitator	Irma Jongeneel	Scribe	Alex de Leon
Attendee	Name	Affiliation
X	Irma Jongeneel	HL7 Netherlands
X	Wes Rishel	Self, USA
X	Alex de Leon	Kaiser Permanente
X	Sam Rubenstein	Montefiore, USA
X	Drew Torres	Cerner, USA
X	Michael Donnely	EPIC, USA
X	Sam Mater	EPIC, USA
X	Cooper Thompson	EPIC, USA
Quorum Requirements Met (Chair + 2 members): Yes

Agenda

Agenda Topics

1. FHIR STU3 resources

• Person vs. Individual 9893
• Arrival date/time on Encounter 9276
• Location.status 12048

Supporting Documents

• gForge Open Resource Tracker Items

Minutes

Minutes/Conclusions Reached:
Introductions

1. 9276 - Add arrival date/time in Encounter
   

Has been updated and resolved.

1. 9893 - Person and RelatedPerson -> Individual and RelatedIndividual
   

The use-case for identifying related people also applies to related organizations. For example, the guardian of a patient might be the state (and they might be the recipient of information). Similarly, the owner of an animal might be a company (e.g. farm) rather than an individual. As well, when linking elements via Person, we could actually be linking animals and, if the above goes through, organizations. So I think renaming them to Individual is appropriate. I think the elements could remain largely unchanged. Obviously sex won't apply to organizations, but that should be ok. Not sure if there's a need to differentiate whether you're talking about an organization or a person.
The WG discussed the guardian or ward of the state would not be covered by Individual RelatedIndividual any more than the Person or RelatedPerson.

The WG continued to discuss the original and current thoughts behind the usage of Person and RelatedPerson.
After much discussion, the WG considered the Patient.contact element on the Patient should be used where the guardian is the state and where the owner of an animal is a company where there is reference to an organization. Since this information is vital in the care of the patient, this should be as close to the patient information as possible.

The WG also considered that the contact element can be used for the further use cases.
Cooper moves to disposition this as non persuasive. Brian seconded.
Discussion: None
Vote: 8/0/0
Friendly amendment: If the organization the relatedperson is representing is required, an extension could be used to cover this use case and if this becomes common, we could make it standard extension.

1. 9274 - Add method of arrival in facility in encounter Already covered. Referenced by 9276. Already handled sa well.
   

1. 10763 - endpoint.payloadFormat 0..* Endpoint.payloadFormat is indicated as 1..1; yet even the description indicates that it should be blank if no payload. This item should be 0..* to support no payload; and to support a list of mime types.

Secondary worry is that this i too disconnected from the list of payloadTypes. One might have a different mime type support for each of the payload types.
Follow up with MnM or FHIR infrastructure.

9235 Living Arrangement - Living Arrangement. Moved to Q4 to allow for submitter to respond (Michelle from Cerner).

9739 - Encounter.hospitalization.dischargeDiagnosis references a Condition resource presumably created after the Encounter Moved to Q4 to allow for submitter to respond (Michelle from Cerner)

9162 - Appointment resource should have 'evidence' and 'related' linkages .
Appointments are often the outcome of other activities. Two uses cases raised in Patient Care WG are 1. Appointments as a result of some form of investigation or assesment which could be recorded using the ClinicalImpression resouce - suggestion - add an element of 'evidence', being a reference to ClinicalImpression resource and any other resources that may provide background information about the reason for the appointment. 2. Appointments as a result of an appointment that did not complete the diagnostic or care process - usually referred to as 'follow-up appointments' - suggestion - add an element of 'previousAppointment' which is a repeating element, being a reference to Appointment resource.

The WG discussed this and noted that within Encounter, the Condition reference contains the Evidence backbone element. The WG is considering including this into the Appointment resource to answer this tracker item and reasonable needs within this group. The Group will handle the completion of this in Q4 today to allow for inclusion within Patient Care concepts.
Deffered to Q4

1. 12048 - Limitation of Location.status
   

How I can map or write status of bed like- closed, housekeeping, occupied, Unoccupied, Contaminated and isolated. These all are possible in V2 (A20 message, NPU-2 field, 0116 table number). Location.status valueset is Required so I can’t extend it. It only contains three values- active, inactive and suspended. I cannot map V2 0116 table values with these values. In short, I feel that status should have more values to cover various aspects of bed status as already covered by V2 table.
I asked the same question in Zulip (https://chat.fhir.org), someone suggested to add a tracker item into gForge, so adding it here. Thanks. Aditya Joshi.

The WG discussed the current status and the status needed above. After much discussion and review of use cases, the group decided to keep the Location.status with the retained values of active/inactive/suspended but also adding another status, Location.opterationalStatus with a coding type with the v2 value set. Description The Operational status covers operational values most relevant to the beds (but can slo apply to rooms/units/dialysis chair, etc., such as isolation units).
This typically convers concepts such as contamination, housekeeping, and other activities like maintenance.
A motion was made by Wes, Sam seconds to accept the above disposition. Pursuasive. Discussion: none. Vote: 6/0/1

Meeting Outcomes

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

Next Meeting/Preliminary Agenda Items .

Wednesday Q4

HL7 Patient Administration Meeting Minutes 'Location: Hyatt Regency San Antonio – Directors Conference Room		Date: 2017-01-18 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	Sam Mater	EPIC, USA
X	Andrew Torres	Cerner, USA
X	Wes Rishel	Self, USA
X	Simone Heckmann	HL7 Germany
X	Michelle Miller	Cerner, USA
X	Sam Rubenstein	Montefiore, USA
Quorum Requirements Met (Chair + 2 members): Yes

Agenda

Agenda Topics

1. FHIR STU3 resources - continue Procedure/Condition/Encounter relationships (maybe diagram for Module page)

• Condition circular references 9739
• Appointment evidence 9162

Supporting Documents

• FHIR Account Resource

Minutes

Minutes/Conclusions Reached:
Introductions

9249 – Management provenance of Practitioner (and other resources using an Ex
Deferred to post STU3.
Irma moved, Wes seconded disposition this item to deferred.
Discussion: Line asked for an explanation. Considered for future use.
Vote: 8/0/0/

9993 - Patient LinkType Negation
In reviewing an internal use I see a need for considering how a system may express the assertion that two patient records within its control are NOT the same person. Currently the link type enumeration only allows for qualifying an affirmative link.
I propose adding a new entry to http://hl7.org/fhir/link-type that expresses the negation use case. code: negated
display: Negated
definition: The system has confirmed that the referenced patient record does not belong to the same person. This may be used to correct an erroneously created affirmative link and will enable version-aware systems to correctly determine the current status of a link relationship.

Irma moves to defer this until post STU3. Consider for future use. Wes seconds. Dicusssion: None. Vote: 8/0/0

1. 9162 - Appointment resource should have 'evidence' and 'related' linkages
   

From last quarter:
The Condition's evidence backbone element covers this type of functionality.
We have already approved the inclusion of the condition onto the appointment (matching Encounter).
Possibly consider copying these elements (evidence backbone element) from the Conditioon onto the appointment
(so that a condition is not required to be created at appointment creation time).
We will check with PC that this solution would be acceptable.

This was covered so that Michelle as a representative from Patient Care could weigh in. After discussion and looking across other resources, the group jointly decided to use the supportintInformation name for this element to be included with a
supportinginformation 0..* Reference (any)
Discription : Additional information to support the appointment?
Drew moved Irma seconded the disposition above.
Discussion: None
Vote: 9/ 0 /0

9191 – Add reasonReference element to Appointment
Appointment has an 'reason' element, but no way of linking supporting information.
Such linkage is available in DiagnosticOrder, ReferalRequest, ProcedureRequest, MedicationOrder and SupplyReqeust which help viewers of those orders/requests understand the evidence behind those orders/requests. Appointments are no different; viewers of appointments should have ready access to the supporting evidence for the appointment.
The linkage from ClinicalImpression to Appointment in ClinicalImpression.action is wrong. ClinicalImpressions are created and stored. Subsequently an Appointment may be created as a direct result of the impression. So linkage between the ClinicalImpression and Appointment is required. However, it should be from Appointment to ClinicalImpression. The addition of a reasonReference element, being a reference to ClinicalImpression, is required to facilitate this.
The Patient Care Work Group wishes to remove the 'action' element from ClinicalImpression, because the linkage is the wrong way around. However that would require a mechanism for linking from an Appointment to a ClinicalImpress (linkage to the other resources is already possible with just a minor addtion of ClinicalImpression, to the list of referencable resources).

Most of the changes discussed here are covered by the similary tracker issue aboce (9162) however the incoming referral should be a separate property, and not get lost in the supporting information. We will add the new property (matching encounter)
IcomingRefrreeal 0..* Reference (referralRequest)

Irma moved the above, Drew seconded.
Discussion: None
Vote: 9/0/0

9235 - Living Arrangement
The patient's living situation at the time of visit/encounter. Sample values include: Living with spouse/partner (includes common-law and same sex partner); Living with family (includes extended family)

The WG believes that this does not belong on the Encounter (either as a native property or as an extension) and should be modeled as an Observation (or Questionnaire) under the OO workgroup.
Michelle moves to refer to OO and Simone as under their domain.
Discussion: None
Vote: 8/1/0
Motion passes.

4873 - History of Encounter.class
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.

If the encounter was different, then related orders/results etc. that were in progress hen the discharge into the encounter would potentially cause discontinued necessitating new orders by practitioners.
This provides good reason for using a single encounter, rather than multiple encounters. After discussion, it appears that there are strong use cases to support class history on the encounter. It’s not enough to capture only the admission dates or change from outpatient to inpatient, but all class in case they are changed or “downgraded” from inpatient.

Michelle moved to include the backbone element after the class property to capture class. Same seconds. Persuasive.
Discussion: None.
Vote: 9/0/0

9226 - Provide a way to rank procedures in the context of an encounter
9739 - Encounter.hospitalization.dischargeDiagnosis references a Condition resource presumably created after the Encounter. eferences a Condition resource, which is most often created after the Encounter is created (hence, the name, discharge diagnosis). The Condition resource (created last) also references the Encounter (created first), thereby having bi-directional references between Condition and Encounter.
I thought it was preferred to have the resource created last reference the resource created first. As a side note, we would need Condition to support capturing the role in context of the encounter (e.g. admitting, discharge, death, etc).
The challenge with having the Encounter.hospitalization.dischargeDiagnosis reference a Condition is that our Encounter meta data (versionId and lastUpdated) doesn't necessarily change when a discharge diagnosis is made since that happens on the Condition side (not the Encounter side). We have a hack/workaround, but wanted to make sure that it was appropriate and intentional to have bi-directional references between Condition and Encounter.
The WG did not come to a consensus on the issue and it is clear that it needs more discussion.

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

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