2016-09-21 PA WGM Minutes

Patient Administration Work Group Minutes - Wednesday September 21, 2016

Wednesday Q1

HL7 Patient Administration Meeting Minutes Location: Hyatt Regency, Baltimore, MD, Guest Room #603		Date: 2016-09-21 Time: Wednesday Q1
Facilitator	Line Saele	Scribe	Alex de Leon
Attendee	Name	Affiliation
X	Line Saele	Helse Vest IKT Norway
X	Brian Postlethwaite	Telstra Health
X	Alex de Leon	Kaiser Permanente
X
Quorum Requirements Met (Chair + 2 members): Yes

Agenda

Agenda Topics

Supporting Documents

Minutes

Minutes/Conclusions Reached:
Introductions
The WG began by addressing the Endpoint FHIR resource. Brian presented an overview of the Endpoint. For example Overall assumption is that an endpoint is defining only a single connection. In other FHIR resources this will be used to replace a single URL field.

ConnectinType

• Proposed a value set and definition change
• Aliases Protocol/Profile/Standard
• PayloadFormat and Method are to be collapsed into this property
  

Changes to SDO + standard Additional details should be in an SDO specific extension

Extensible value set (for connectathontype binding) IHE

• XCPD
• XCA
• XDR
• XDS.b
• IID

HL7

• FHIR-REST
• FHIR-MSG
• V2
• V3

DICOM

The WG reviewed the changes to the Endpoint resource which came out mainly out of the connectathon this WGM. The question about the payuloadMimeType was discussed as there Is a question of what to do if you have blank payload (just pinging) versus “send all”. Brian moved to accept the changes by provider directory group to the Endpoint resources. Kevin seconded. Discussion: Vote (for/against/abstain): 10/0/0 The WG continued with the tracker issues.

1. 11251 - Summary: Update name of payloadFormat to supportedMIMEtypes - 2016-09 core #405
   

The payloadFormat is a list of supported MIME types. This name is causing confusion with payloads such as CCD, DischargeSummary,etc.
As noted above the payloadFormat has been renamed to payloadMimeType to avoid confusion. The cardinality has been set to 0..* to enale configuration of systems such as ESBs to have any type without enumerating all of them and also cases where no content desired.
Brian moves to disposition this as persuasive with modification. Cooper seconds.
Discussion: none
Vote (for/against/abstain): 10/0/0

1. 11250 - Summary: Update definition and value set for endPoint.connectionType - 2016-09 core #404
   

This list has been updated as noted above in the changes to Endpoint.
Brian move to disposition this as persuasive. Cooper seconded.
Discussion: None
Vote (for/against/abstain): 10/0/0

1. 11201 – Summary: Why no required Pracitioner properties? - 2016-09 core #355
   

None of the properties of Practitoner in the resource is required
For a Practitioner to be identifiable, shouldn't at least the name be required?

Resources are designed to be useable in a variety of contexts. Because there are use-cases where a name might not be known or might not be shareable, it is optional. There are similar use-cases for other elements. All instances must have at least one element present, but it would be up to the implementation context to determine which element(s) were appropriate/necessary. Such requirements could be enforced with a profile.
Question answered
Vote (for/against/abstain): 10/0/0

1. 11037 - Summary: Gender code issue conflict with US requirements - 2016-09 core #56
   

Administrative Gender Value Set
http://www.hl7.org/FHIR/2016Sep/valueset-administrative-gender.html
is the mandatory encoding for:
Patient.gender (Required) the most commonly used resource
RelatedPerson.gender (Required)
Practitioner.gender (Required)
Person.gender (Required)
FamilyMemberHistory.gender (Required)
StructureDefinition FamilyMemberHistory-Genetic: FamilyMemberHistory.gender ((Required))
Patient.contact.gender (Required)
However this code is not consistent with US mandates to use Consolidatd-CDA which requires that " patient SHALL contain exactly one [1..1] administrativeGenderCode, which SHALL be selected from ValueSet Administrative Gender (HL7 V3) urn:oid:2.16.840.1.113883.1.11.1 DYNAMIC (CONF:2212-6394)."
Furthermore, the code and display name for each "code" are identical except for capitalization: male for the code and Male for the display label. Most system already use M and F because they try to conserve screen space. Using an English word as a code is not consistent.
Based on past discussions, this value set may require harmonization but recreating new codes specifically for FHIR does not make sense since most implementations already use M and F for administrative gender. New attributes such as gender at birth and gender identity have been added to better describe the patient but this value should still be backwards compatible and harmonized with V3/CDA and V2 as much as possible.

The "required" administrative-gender Value Set is not consistent with US mandate to use Administrative Gender (HL7 V3) urn:oid:2.16.840.1.113883.1.11.1 and requires further harmonization.

Meeting Outcomes

Actions (Include Owner, Action Item, and due date) <<consolidate action items>>

Next Meeting/Preliminary Agenda Items .

Wednesday Q2

HL7 Patient Administration Meeting Minutes Location: Hyatt Regency, Baltimore, MD, Guest Room #603		Date: 2016-09-21 Time: Wednesday Q2
Facilitator	Brian Postlethwaite	Scribe	Alex de Leon
Attendee	Name	Affiliation
X	Line Saele	Helse Vest IKT Norway
X	<< Update Attendees >>
Quorum Requirements Met (Chair + 2 members): Yes

Agenda

Agenda Topics

1. << update agenda topics >>

Supporting Documents

Minutes

Minutes/Conclusions Reached:
Introductions

The WG is hosting Patient Care mainly to discuss shared FHIR resources.




First the Encounter resource was discussed. The WGs reviewed the condition and the ccontext. Condition.category Condition that is managed over time – ProblemListItem Condition related to a specific Encounter – EncounterDiagnosis The work groups discussed Concern and how it is used in context of this according to PC. Condition The WG discussed the elements on Encounter, including the indication, admittingDiagnosis. A third place would be the Encounter extension to identify the primary diagnosis http://hl7.org/fhir/StructureDefinition/Encounter/relatedCondition Encounter.context Due to the various elements being discussed, the WG created a diagram <<diagram>> This was used as a talking point and to clarify the various diagnosis, indication, problem, etc. Michelle proposed that the Encounter.reason which today is a codeable concept, be reserved for the patient stated reason for the Encounter (still codeable) and use a new element to contain the clinical diagnosis with the roles played by that diagnosis (e.g. admitting, discharge, billing, etc.).
The WG continued to draft up a proposal for a new element Encounter.diagnosis Michelle noted that there was a GFORGE tracker item where this discussion/resolution can be logged

1. 10544 - Summary: Add condition extension(s) to represent a role in context of Condition.encounter (e.g. Primary/Sequence, Admit, Discharge etc.)

Add condition extension(s) to represent a role in context of Condition.encounter (e.g. Primary/Sequence, Admit, Discharge etc.) Encounter.inidication replaced by Encounter.diagnosis in Encounter. Reason will remain but will be updated to be clear that it is more patient-centric reason for the encounter.

Encounter.diagnosis 0..* backbone element Encounter.diagnosis. condition 1..1 reference (condition) Encounter.diagnosis.role 0..1 codeable concept (new valuseset with admission, discharge, billing, chief compaing, cobmorbidity, pre-op post op billing Encounter.diagosis.rank 0..1 positiveInt (this is to be sequential per role type)

Hospitalization.dischargeDiagnosis and hopsitllization.admissionDiagnosis will be removed. Remove extension encounter-primaryDiagnosis and encounter-relatedCondition reason Alexander moved to disposition this as persuasive with mod considering the changes above. Alex seconded Discussion: None Vote(for/against/abstain): 11/0/0

Care Team Evelyn from the office of the ONC discussed their interest in the CareTeam resource. It was made clear that Patient Care owns the reasource but PA definitely has a stake in the resource development. PAs stake in the care team has to do with the roles of the practitioners which is directly related to our resources. The WGs discussed the roles and where these are defined, perhaps v3 value sets, even though there is a FHIR value set “owned” by PC, however this needs work to refine. The discussion also made a differentiation between certifications, qualifications versus the role the practitioner is playing in the care plan. Care team participant role. Brian noted that Practitioner.role versus participant.role seem to be the same with different value sets. Simone noted that it might be good to keep one value set for the both. Quarter end.

Meeting Outcomes

Actions (Include Owner, Action Item, and due date) <<consolidate action items>>

Next Meeting/Preliminary Agenda Items .

Wednesday Q3

HL7 Patient Administration Meeting Minutes Location: Hyatt Regency, Baltimore, MD, Guest Room #603		Date: 2016-09-21 Time: Wednesday Q3
Facilitator		Note taker	Alex de Leon
Attendee	Name	Affiliation
X	Line Saele	Helse Vest IKT Norway
X	<< Update Attendees list >>
Quorum Requirements Met (Chair + 2 members): Yes

Agenda

Agenda Topics

1. << update agenda topics >>

Supporting Documents

Minutes

Minutes/Conclusions Reached:

1. 11471 - Summary: 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 will be adding additional content to the use cases section to give a more complete coverage. And assure the use cases for all resources are referenced. Iryna/Brain Action Item: Add additional content to the use cases section to make it more complete and cover the primary resources. Owner: Iryna, Due: Telecon

1. 11470 - Summary: Beef up privacy section

Should add the following to the "privacy" section: Note that privacy considerations apply to Person, Practitioner and RelatedPerson records in addition to Patient's. While Organization, Location, Device and other non-person-identifying records are generally subject to less stringent security precautions, such data must still be protected to avoid safety issues (e.g. someone maliciously changing the ingredients associated with a drug to cause/fail to cause alerts) Devices can be linked to Patients. If this occurs, they must be protected as any other patient-linked element
The WG considers this a reasonable request to add
Brian moves to add the following text to the 8.0.3 Privacy and Security Section of the Administration Module Page. Alex seconded. Discussion: None Vote (for/against/abstain): 6/0/0

1. 11467 - Summary: Patient.link vs. Linkage - 2016-09 core #63

We need to figure out whether it's necessary for the Patient.link capability to exist now that the Linkage resource exists - and if so, provide guidance on when to use each. The WG considered the two concepts (Patient.link and the new Linkage resource) After much discussion of the advantages and disadvantages of link, linkage (resource) and merge, the WG considered crafting language that strongly suggests to implementors to have a two-way reference (today there is one from the replaced record to the new record) so that implementors will be “aware” of the potentially historical patient information. Brian clarified that the WG seems to agree that the Linkage resource should not be used to actually link the persons-type resources together. In the case of Patient link/merge the knowledge that the patient resource being used has within it any information regarding its validity to be used for referencing other resources. Not detecting/checking for a potential linkage could mean that most of the clinical record is not discovered. Knowing that the resource was replaced/merged into a newer resource is vital to patient safety. Brian moved to disposition this as not persuasive with mod and include the text clarify that Linkage is not to be used Simone seconded. atient: When a patient resource instance has been linked/merged, it should have some internal indication that there is another patient resource that should also be considered. Not detecting/checking for a potential linkage could mean that related clinical records are not discovered, potentially impacting patient safety. Person: The Person resource is not just a linkage resource, it may be used as a central person demographic registry of information, potentially as the master of those core details. By just using the linkage resource we would need to recommend ALL uses of Patient to use the reverse include functionality to test if there are any linkages to other patients to be considered.

Section 8.1.4 on Patient Linkage will include additional text to indicate why not to use the Linkage resource. And we will also update the linkage resource to include these reasons also. We also recommend that an invariant be added to the linkage resource to prevent using it on patient/practitioner/person/relatedperson resources.

Simone noted that there was a related tracker:

1. 10434 Summary: client responsibilities on reading merged patients need clarification

Meeting Outcomes

Actions (Include Owner, Action Item, and due date) << Consolidate Action Items >>

Next Meeting/Preliminary Agenda Items .

Wednesday Q4

HL7 Patient Administration Meeting Minutes Location: Hyatt Regency, Baltimore, MD, Guest Room #603		Date: 2016-09-21 Time: Wednesday Q4
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

1. <<update agenda topics>>

Supporting Documents

Minutes

Minutes/Conclusions Reached:

1. 10434 Summary: client responsibilities on reading merged patients need clarification
   

Context: the client responsibility is not clear. The original idea was to give direction to the clients on merged (linked) patients to say that the active status must be looked at and if it is inactive, you must look at the linked record to get a full view of the patient record.
When thinking this through Simone noted that she realized that there must be both ways a reference to get a good picture. The value set for the Patient.linkType includes the “seealso” value, but the definition should be changed as it references that both should be regarded as equally valid.

Simone and Andrew put forth that perhaps we should remove the refers and seealso from the vocabulary binding for linkType and add verbiage to say that when records are considered within one system, the implmenters should us “link” but should consider using Person to refer to the various records in case the sysstems are replaced, etc., so as not to have “dead links”,
This caused quite a lot of discussion.
Simone motioned to add a new code “replaces” to the Patient vlue set linkType and rename the replace code “to replaced-by” and further note on the patient link section of the specification to describe the pending areas of investigation. Disposition is persuasive with mod. Iryna seconded. Discussion: None
Vote (for/against/abstain): 4/0/3

1. 10636 - Summary: QA 5a: Resource references exist in both directions for Procedure and Encounter
   

Resource references exist in both directions for Procedure and Encounter as follows: Procedure.encounter (to Encounter) Encounter.indication (to Procedure) Per QA 5a: Elements with a type of Resource Reference should be reviewed such that a given relationship shall only be represented in one resource, not both (and should generally be present on the resource that is normally created second – e.g. Procedure is usually created after Encounter, so reference would live on Procedure)

The setup of the references are avalide bu they should never be the same encounter procedure referred which creates a circular reference. The example discussed in the workgroup would be a follow up encounter to resolve cmomplications from from another encounter’s proecedure. Clarifying text will be added to tehe specification Andrew moves to add clarifying text to the specification on the use of these references. Iryna seconds. Discussion: None Vote (for/against/absain): 7/0/0

1. 10043 – relatedPerson - Summary: Description of RelatedPerson identifier search parameter

Alex moves to correct the relatedperson description as to relatedperson identifier (currently says Patient) Discuss: None Vote (for/against/abstain): 7/0/0

1. 9699 – This refers to and was resolved in #10544
2. 9698 - Summary: Encounter.participant.period definition

The current definition of Encounter.participant.period is "The period of time that the specified participant was present during the encounter. These can overlap or be sub-sets of the overall encounters period" This reads as if the participant needs to be physically present. For example, would there be multiple participants for the same person (e.g. Attending Physician) representing each time period the participant is with the patient? What about others, such as a pathologist, who may never see the patient face to face? Are they still considered participants without a period populated? The issue seems to be the “present”. The WG considered removing or replacing this. The proposal was to change the word to “active”. This also supports type visits of “virtual”. Andrew moves to change the wording on Encounter.participant.period from “Period of time during the encounter participant was present” to “Period of time during the encounter participant participated”. Iryna seconds. Discussion: None Vote: 7/0/0 Next session in President. HAVE and TEP with PHER

Meeting Outcomes

Actions (Include Owner, Action Item, and due date) <<consolidate action items>>

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 2016 WGM

© 2007-2016 Health Level Seven® International. All rights reserved.