Revision as of 08:27, 7 October 2016

Patient Administration Work Group Minutes - Thursday May 14, 2014

Thursday Q1

HL7 Patient Administration Meeting Minutes Location: Hyatt, Paris, France, Guest Room 2331		Date: 2015-05-14 Time: Thursday Q1
Facilitator	Line Saele	Note taker	Alex de Leon

Attendee	Name	Affiliation
X	Line Saele	Helse Vest IKT Norway
X	<< update attendee list >>

Quorum Requirements Met (Chair + 2 members): No/Yes

Agenda

Agenda Topics

<<update agenda topics>>

Supporting Documents

Minutes

Minutes/Conclusions Reached:
Introductions
Joint with PHER and Emergency Care with OASIS present. The WG discussed the HAVE standard and the fact that the HL7 board declined to endorse the HAVE EDD standard. The option is to have a standard on both ends balloted by each organization (HL7 and OASIS). OASIS expresses the openness to have a joint effort, but the group is wondering if it is worth the effort on both sides to ballot on each. This seems to be the only option; to have the exact same standard published in both organizations and balloted in each. This will fall under the joint agreement originally crafted for the EDD HAVE standard.

John asked, even if there were a joint effort, how would it express itself? Would it be v3? FHIR? Line commented that it seems that FHIR would be the best method.

Brian noted that the area that seems to fit the emergency aspect of OASIS’s need is in Clinical Quality Measurement (CQM) which is currently being modelled in FHIR..

The WG discussed what the needs of the expression of the standard. The WG reviewed the EDD-HAVE information model. Brian Organization, Location, HealthcareService. The question came up about adding availability to the model. Brian noted that there is an availability element, but it focuses on opening/closing our. He noted that Scheduling resources could be resources.

Brian suggested to use the CQM tools using the resources (Organization, Locaion, HeahcareService and Scheduling) then the CQM tools for OASIS’s emergency care/triage availability needs. Patti will take this back to OASIS to see if that could be a good path.
Action: Brian to check to check with FMG about including this effort in a connectathon. This may help raise the maturity level of the HealthCareService.

Patti explained to the group the various organizations in the US that are overseeing efforts such as these. This was to explain the scope and what organizations today oversee these efforts.

John and Patti noted that there was a federal mandate to report up the availability of beds and services but that has been discontinued. However, John noted that states already have mandates anyway to report up.
The WGs agreed that efforts should be an international effort. This would mean the effort could choose their sponsors. PA is willing to be a sponsor, but not the only sponsors. So PA would be sponsors with EC and PHER will co-sponsor.
We should draft the PSS, alert the steering division.
Action: Draft PSS for this effort. Owner Line/Brian. Due: 10/5/16 with a target to 10/20/16.
The WG continued with tracker items.

11413 - Summary: Suggest changing attribute ‘communication’ to ‘language’ to be more clear. - 2016-09

core #571
Suggest changing attribute communication to language to be more clear.
The WG looked at the base resource on which all resources derive. It already has an element called “language” which is the language of the resource itself. So, there cannot be another element called “language”
Brian moves to find this non-persuasive based on the above. Alex seconds.
Discussion: None.
Vote (for/against/abstain): 7/0/1

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

Brian moved, to find this non-persuasive and no action taken based on this.Andrew seconds.
Discussion: None
Vote (for/against/abstain): 8/0/0

9893 - Summary: 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 noted that this was set for “in person” by Lloyd.

Not keen to change the name of the Person resource. The use case for the "ward of the state" was discussed and is stil being considered, and looking to try to define guidance on how to do this. Considered are Patient.Contact.organization, Adding an Organization reference to RelatedPerson, and/or using the new linkage resource. This will also be done differently in different jurisdictions, and should be able to be profiled there. We also discussed similar cases like Prisons.

Meeting Outcomes

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

<<Consolidate action items>>

Next Meeting/Preliminary Agenda Items

.

Thursday Q2

HL7 Patient Administration Meeting Minutes Location: Hyatt, Paris, France, Guest Room #2331		Date: 2015-05-14 Time: Thursday Q2
Facilitator	Line Saele	Note taker	Alex de Leon

Attendee	Name	Affiliation
X	Line Saele	Helse Vest IKT Norway
X	<<update attendee list>>	Kaiser Permanente

Quorum Requirements Met (Chair + 2 members): Yes

Agenda

Agenda Topics

<< update agenda topics >>

Supporting Documents

Minutes

Minutes/Conclusions Reached:
Joint with FM.

9200 - Summary: Capturing self payor

It is not clear, how to use the Coverage resource to capture the fact that a patient is self payor. Or would I express this using a different resource?

The WG reviewed the coverage resource and how the self pay might be expressed. In order to do so, this tracker is to request that the “PAY” to be added the HL7 V3 ActCoverageTypeCode value set and rename the name of Issuer property to be Payor. Brian moved to make the above changes. Simone seconded. Discussion: Cooper suggested that the binding to be preferred rather than example. This was made as a friendly amendment to the motion. Brian agreed. Vote (for/against/abstain): 11/0/1

9115 - Summary: BIN as Coverage attribute should be moved to extension or identifier

A quick non-representative survey among HL7 Affiliates in the Netherlands, Belgium, Austria, Switzerland and Germany showed that BINs are uncommon/unknown in the context of Coverage resources. The attribute "BIN" should probably either be moved to extensions or be used as an identifier with a specific namespace. The WGs discussed whether this item should be included in the coverage resource or not. There was a lively discussion around identifiers and the BIN #. FM agreed to move this into Organization.

BIN removed from coveage

Due to the change to the ResourceReference datatype the issuer type property

Simone asked to have the concepts of Group, plan subplan, class to try to get some insight into the identifiers which are currently of datatype string.

The WGs discussed attempting to “collapse” the concepts (e.g. group, plan, subplan, class) into one set of values that could be applicable universally.

The discussion then moved to the datatype, which seems to lend itself to coding system.

Mary Kay noted that there was an ISO standard for the structures being discussed (ISO 20302:2014 – Healthcare card standard) Br Leave as is, 2 replacing terms with single poperty multicardilaity coding with a string, multicardinailty identifier.

After discussing this, it seems that the single property (multicardinality) coding. The WG then discussed the name of this. No easy ones came to mind so the WGs agreed to name this “levels” for now. Upon further discussion

Remove BIN from coverage (handled by Organization) Elements replaced by a multi-cardinality property using coding. Coding system will be defined upon context specific usage. The display will contain the name of the detail e.g. “iron Lung workers” and the code will contain the actual value e.g. 54D.

Simone suggested that this be “tested” during the next connectathon. Paul and the WGs agreed that this could be done.

Brian moved to make he changes above. Paul seconded. Disussion: none Vote (for/against/abstain): 12/0/1

Meeting Outcomes

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

<<consolidate action items>>

Next Meeting/Preliminary Agenda Items

.

Thursday Q3

HL7 Patient Administration Meeting Minutes Location: Hyatt, Paris, France, Guest Room #2331		Date: 2015-05-14 Time: Thursday Q3
Facilitator	Line Saele	Note taker	Alex de Leon

Attendee	Name	Affiliation
X	Line Saele	HL7 Netherlands
X	<< update attendee list >>

Quorum Requirements Met (Chair + 2 members): Yes

Agenda

Agenda Topics

<<update agenda topics>>

Minutes/Conclusions Reached:
Introductions.

9893 – Person and RelatedPerson

The WG continued with this tracker, noting that Lloyd has read and replied to the tracker item as such: Well, in the Ward of the State case, the Organization will need to be an actor who participates on behalf of the patient (signing consents, receiving information, etc.), so Patient.contact won't fly. And Practitioner wouldn't be appropriate because they're not acting in the capacity of their relationship to the patient. As well, service animals who are actually doing work would be RelatedIndividuals, though that's probably more of an edge case.
The WG agrees that Patient.contact would not be the best fit for the use cases. RelatedPerson still seems like a good candidate, however to meet the use cases described by Lloyd, the element of Organization would have to be added to RelatedPerson (to support ward of the state and perhaps the prison scenario as well).

The WG continued looking into this and reviewed the RelatedPersonalRelationshiop value set.
The WG noted that the valueset would have to be extended to support the “ward of state concept for relationship type in RelatedPerson. Simone noted that there was a state agency and federal agency.

11248 - Summary: Add religion to core extensions. - 2016-09 core #402

Did Patient Care consider this for a US FHIR core extension?

The WG discussed this and noted that this concept goes beyond just US centric and that it is based on v3 concepts. The WG proposing to make the religion a standard extension. The WG noted also that the extension has a 0..* cardinality but should have the multiple cardinality on the religion element from the valueset. For this standard extension the Alex moves for the WG accept the changes aboce. the above: Patti Syed seconds. Discussion: Non Vote (for/against/abstain): 5/0/1 Action: Review all the extensions to check for multiple cardinality levels (entire extension versus value within extension). For example Patient disability which is 0..* and Brian.

This will be a non-compatible change due to the namespace update.

11205 -

The WG then entertained the representatives from PHER to discuss their PSS to add occupational industry elements to the v2 standard. Employers, The WG reviewed the draft PSS from PHER. Alex noted that there were no specific implementors noted, only internal HL7 orgnizations. He noted that when we move this through our steering division, they will require this. Brian then asked about profiling the (US) bindings and where would that be part of this work. If it is required, then the PHER representatives said that it would need to be.

Action: Brian to send the draft PSS to Bret Marquad.

Action:
Alex moves to include PA as the co-sponsor to the PSS to include the occupational industry elements into the v2 and FHIR standards. Cooper Thomson.
Discussion: None
Vote(for/against/abstain): 5/0/1

The Plan is for the PAWG to address this on the telecon meeting on 10/11.
Cooper moves to adjourn.

Meeting Outcomes

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

<<consolidate action items>>

Next Meeting/Preliminary Agenda Items

.

Thursday Q4

Meeting cancelled due to other duties of the core members}

Agenda

'

Minutes

Meeting Outcomes

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

<<consolidate action items>>

Next Meeting/Preliminary Agenda Items

.

Navigation

@@ Line 457: / Line 457: @@
 |                                                                          |
 ========================================================================--->
-<!-- ********  CHANGE WG Name or Project ON NEXT LINE *******************-->
-| width="50%" colspan="2" align="left" style="background:#f0f0f0;"|'''HL7 Patient Administration Meeting Minutes''' <br/>
-<!-- ********  CHANGE conf call details or meeting room ON NEXT LINE*****-->
-'''Location: Hyatt, Paris, France, Guest Room #2331'''
-<!-- ********  CHANGE Date and Time  ON NEXT LINE  **********************-->
-| width="50%" colspan="2" align="left" style="background:#f0f0f0;"|'''Date: 2015-05-14'''<br/> '''Time: Thursday Q4'''
-|-
-<!-- ********  CHANGE chair and scribe ON NEXT LINES  *******************-->
-| width="10%" colspan="1" align="right"|'''Facilitator'''
-| width="35%" colspan="1" align="left"|Line Saele
-| width="25%" colspan="1" align="right"|'''Note taker'''
-| width="30%" colspan="1" align="left"|Alex de Leon
-|-
-| border="4" cellpadding="1" colspan="4" style="background:#f0f0f0;"|
-|-
-| border="1" cellpadding="2" colspan="1" align="left"|'''Attendee'''
-| '''Name'''
-|colspan="2"|'''Affiliation'''
 <!---==============================================================================
 |                                                                                 |
@@ Line 485: / Line 467: @@
 ===============================================================================--->
 <!-- ********add attendee information here *********-->
-|-
+Meeting cancelled due to other duties of the core members}
-| X || Line Saele
-|colspan="2"| Helse Vest IKT Norway
-|-
-| X || <<update attendee list>>
-|colspan="2"|
-|-
-|colspan="4" style="background:#f0f0f0;"|
-|-
-|colspan="4" |'''Quorum Requirements Met''' (Chair + 2 members): '''Yes'''
-|}
 <!---=======================================================
 |                                                          |
@@ Line 506: / Line 478: @@
 ========================================================--->
 ===Agenda===
-'''Agenda Topics''' <br/>
+'<br/>
 <!-- ***** Delete instructions and fill in agenda items ON NEXT LINES  ****-->
-#Wrap up
-*
+'<br/>
-'''Supporting Documents'''<br/>
 <!-- *****  Delete instructions and add document names/links ON NEXT LINES *****-->
 *
@@ Line 524: / Line 495: @@
 =================================================================--->
 <!-- **** Delete instructions  and fill in minutes ON NEXT LINES  ******-->
-'''Minutes/Conclusions Reached:'''
-# 6929 – Need to sort out which healthcare providers are able to bill, vs those who can not. <br/>
-On the Practitioner Resource – the definition of a practitioner is quite broad.  Could we suggest relabeling it as Healthcare Employee and then have a sub-element for those providers who are allowed to provide medical care and are ‘billable’ and consider calling that individual a Healthcare Provider?   When we are working on analytic projects, we are typically trying to assess the care that was provided by a physician (or NP, PT, OT) who bills for the service and compare their efforts(including costs associated with care) - with the patient outcomes to derive the value of the care.  This definition is just too broad. <br/>
-Graham. I don't see that changing the definition is going to help with this, and the concern is a particularly US centric one. I think this should be resolved by US realm profiles<br/>
-The WG agrees with Graham’s comment regarding this being a jurisdictionally specific requirement that will need resolving based on local requirements. It is not part of the 80% for practitioner records. Suggest that this should be handled by a US realm entity. PA will refer to this to the US Realm task force<br/>
-# 7115 – Duplicate of 6929<br/>
-# 7116 – Similar to the comment posted on Patient regarding race and ethinicity. <br/>
-Duplicate of 6928 and 6930. <br/>
-# 7306 -  2015May core #496 - Add hospitalization.period <br/>
-The encompassing encounter period may be different than the hospitalization period. The hospitalization would start on admission, but if the patient went to the ER or other department first, that may have not triggered an admission at that time. <br/>
-The WG discussed the various ways that the current structures could be used to capture various implementations of the admission process that includes an encounter with a hospitalization. In the case where the ER encounter occurs prior to admission, a separate encounter could be used to capture this (with its own period) and then be linked into the admission encounter via the part-of property on the ER encounter. <br/>
-# 7117 - 2015May core #176 - Distinguish contact primary type <br/>
-Duplicate of 6931. <br/>
-# 7307 – RelatedPerson - Consider adding birthDate dateTime to resource, just as it is in the Person resource. Ager of the individual involved in the care could be important . <br/>
-WG agreed. This will be added to the relatedPerson resource. <br/>
-# 7308 - gender should be renamed to administrative gender to distinguish it from a possible meaning of biological gender which for more in depth clinical uses could be a much greater set of potential value.This is done for other HL7 specifications<br/>
-No change. <br/>
-The valueset applied to the property is from the administrativeGender and the description of the property also highlights that this is only administrative. <br/>
-From the context of a related person, there is no requirement for clinical gender representation. <br/>
-# 7309 – Person - gender should be renamed to administrative gender to distinguish it from a possible meaning of biological gender which for more in depth clinical uses could be a much greater set of potential value.This is done for other HL7 specifications<br/>
-No change. <br/>
-The valueset applied to the property is from the administrativeGender and the description of the property also highlights that this is only administrative. <br/>
-From the context of a related person, there is no requirement for clinical gender representation, as where a person is a patient, the patient is the context that applies into the clinical space. <br/>
-#7310 - - Practitioner. gender should be renamed to administrative gender to distinguish it from a possible meaning of biological gender which for more in depth clinical uses could be a much greater set of potential value.This is done for other HL7 specifications<br/>
-<p>No change.</p> <p>The valueset applied to the property is from the administrativeGender and the description of the property also highlights that this is only administrative.</p> <p>From the context of a practitioner, there is no requirement for clinical gender representations.</p><br/>
-# 7311 - Practitioner- Keep birthDate data type consistent with the Person resource <br/>
-<p>The person resource will have the date of birth field changed to date (not datetime) for consistency with the other person type resources.</p><br/>
-# 7511 - Make names consistent between Procedure and Encounter . Existing Wording: <br/>Encounter.participant.individual vs Procedure.performer.person<br/>
-After looking at the model, the individual element is set to be Practitioner or RelatedPerson. After discussion, it was decided that the Procedure.Performer.person resource field should be changed to Procedure. Performer.individual instead of applying changes to the encounter as the practitioner/related person (and patient for that matter) could be an animal, therefore individual fits better in these cases rather than person. <br/>
-# 7626 -  ContactPoint should provide a 'rank' attribute - ContactPoint should provide a 'rank' attribute in case different communication modalities should be attempted in a particular order. E.g., try my cell first, SMS second, followed by email or office phone. <br/>
-The WG discussed this and saw value in the usage of this construct. However, after looking at it, it appears to be a change to the ContactPoint datatype, adding a positive integer element. We will need to check with the core team before applying/approving. Brian will take this to core FHIR team for further direction. <br/>
-Waiting for input. <br/>
-# 7607- Review example with group <br/>
-Suggest re-reviewing whether structures with Element data types should be Resources or Data Types.  Rule of thumb could be that if it is likely to be used in more than one resource, it should be a Resource.  E.g., Patient.contact -- why is this an Element, when Patient.address is a Data Type?  Couldn't Patient.contact be generalized when used in other settings, like for a Provider (e.g., escalation needed for sending alerts, etc.)?  Also, profiling such structures requires profiling the entire containing Resource, which seems suboptimal. <br/>
-The example as provided of Patient.contact is actually different to the contact that is on an organization, hencewould not be able to re-use the type, even though the concept is very close to the same. <br/>
-Waiting for input. <br/>
-The WG looked at the remaining ones. There are 52 remaining tracker items (ballot comments) for FHIR DSTU 1 which will be handled in the telecons. <br/>
-The WG then discussed the telecom times. It was suggested to keep the Monday time until July 1 then switch to Tues for July and August then back to Monday from Sept 1st. <br/>
-Based on times that key members would be on holiday, the best time for the first WGM is May 26 (Tuesday) then  back to Mondays starting June 1st, and making the meetings 1.5 hours until the FHIR ballot reconciliations are complete. <br/>
-Brian makes a motion to adjourn. Peter seconds <br/>
-Vote: 3/0/0<br/>
 ===Meeting Outcomes===
 {|border="1" cellpadding="2" cellspacing="0"
@@ Line 594: / Line 524: @@
 [[Category:PA_Minutes]]
 [[Category:2015_PA_Minutes]]
 ==Navigation==
 * [[2015-05-11_PA_WGM_Minutes|Go To Monday Minutes]]

Difference between revisions of "2016 09-22 PA WGM Minutes"

Revision as of 08:27, 7 October 2016

Contents

Patient Administration Work Group Minutes - Thursday May 14, 2014

Thursday Q1

Agenda

Minutes

Meeting Outcomes

Thursday Q2

Agenda

Minutes

Meeting Outcomes

Thursday Q3

Agenda

Meeting Outcomes

Thursday Q4

Agenda

Minutes

Meeting Outcomes

Navigation

Navigation menu

Personal tools

Namespaces

Variants

Views

More

Search

Navigation

groups

meetings

general

Tools