This wiki has undergone a migration to Confluence found Here
<meta name="googlebot" content="noindex">

Difference between revisions of "2017-09-16 PA WGM Minutes"

From HL7Wiki
Jump to navigation Jump to search
(Created page with "Category:WGM Minutes 2016 01-Orlando Return to: WGM Minutes > 2016 > :Category:WGM Minutes 2016 01-Orlando|Janu...")
 
m
 
Line 685: Line 685:
 
|}
 
|}
 
==Navigation==
 
==Navigation==
* [[2016-01-11_PA_WGM_Minutes|Go To Monday Minutes]]
+
* [[2017-01-16_PA_WGM_Minutes|Go To Monday Minutes]]
* [[2016-01-12_PA_WGM_Minutes|Go To Tuesday Minutes]]
+
* [[2017-01-17_PA_WGM_Minutes|Go To Tuesday Minutes]]
* [[2016-01-13_PA_WGM_Minutes|Go To Wednesday Minutes]]
+
* [[2017-01-18_PA_WGM_Minutes|Go To Wednesday Minutes]]
* [[2016-01-14_PA_WGM_Minutes|Go To Thursday Minutes]]
+
* [[2017-01-19_PA_WGM_Minutes|Go To Thursday Minutes]]
* [[2016-01_PA_WGM_Agenda|Return to PA January 2016 WGM]]
+
* [[2017-01_PA_WGM_Agenda|Return to PA January 2016 WGM]]
 
* [[Patient_Administration|Return to PA Main Page]]
 
* [[Patient_Administration|Return to PA Main Page]]
© 2016 Health Level Seven® International.  All rights reserved.
+
© 2017 Health Level Seven® International.  All rights reserved.
 
[[Category:PA_Minutes]]
 
[[Category:PA_Minutes]]
[[Category:2016_PA_Minutes]]
+
[[Category:2017_PA_Minutes]]
[[Category:2016_PA_WGM_Minutes]
+
[[Category:2017_PA_WGM_Minutes]

Latest revision as of 19:46, 20 January 2017


Return to: WGM Minutes > 2016 > January Orlando

Patient Administration Work Group Minutes - January 11, 2015

Monday Q1

HL7 Patient Administration Meeting Minutes

Location: Directors Conference Room

Date: 2017-01-16
Time: Monday 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 HL7 Norway
X Brian Postlethwaite HealthConnex, Australia
X Nat Wong HL7 Australia
X Christian Hay GS1
X Iryna Roy Gevity/HL7 Canada
X Jim Whicker Cognosante
Quorum Requirements Met (Chair + 2 members): Yes

Agenda

Agenda Topics
Welcome/introductions

Supporting Documents

Minutes

Minutes/Conclusions Reached:
Introductions
WG started with the approval of the agenda. During jthe meeting there was a quesiont of a tracker item by a new attendee inquiring about when it would be handled. The WG clarified that that particular item has been voted on and dispositioned in GForge. The WG continued with review of the agenda. Brian moved to approve the agenda. Second by Irma for agenda approval. Vote (for against/abstain): 11/0/1. Motion Passes
The WG continued to review the mission and charter. No changes were needed.

The WG reviewed the Decision Making Practices. There was focus on the reduction of the quorum from chair plus 3 to chair plus 2. This is primarily to cover the teleconferences attendance. There was a question as to whether this covers the appropriate amount of attendees to cover this domain. It was clarified that when it appears that an item is of a larger scope, it will be introduced to the general community via listserv, wiki, etc. before voting or deciding on it.

The WG continued looking at the 3 year work plan. There was a discussion about the usefulness of the 3 year work plan since the work, especially with FHIR, is so dynamic.

Action: Fix link of DMP to most recent document (v3 to v4). Line.
The WG continued to review the 3 year work plan. The Occupational Health Project was included. Dates were updated

The WG continued reviewing the SWOT. The SWOT was updated mainly with the FHIR initiatives.
Motion to approve the updated Swot by Brian. Seconded by Wes.
Vote: 11/0/1

There was an idea to put Argonaut project on the agenda as an update from the project.

Motion: A motion for was made by Brian as a a friendly amendment to the agenda updating Q3 with feedback from projects in general. Second Irma. Vote: 11/1/0

Motion Passes
The WG entertained a question by Mead Walker having to do with use of data within the v2 messages regarding mother/baby encounters. There was a discussion around creation of patient records for fetal demise. The subject is around CDA sending reports (birth and death) and who should be the patient, the baby/fetus or the mother. Today most data collected is with the focus on the mother, until the baby is actually born, at which time a record is created (or promoted). The feeling seems to be to retain the mother as the PID. Alexander noted that in chapter 7 of v2, there is an adverse effect scenario wherein the baby is in the PID and the mother is NK1. Further discussion seemed to indicate some feelings in the room that the fetus should be the subject (PID) and the mother as the related subject (NK1). There was an idea to create a zmessage event.

The suggesting was to contact AHIMA to get some guidance.


Meeting Outcomes

Actions (Include Owner, Action Item, and due date)
  • Action: Irma will talk to Hans Buitendijk as one of the co chairs of OnO to assure that they know that they are the steward of chapter 17 (Materials Management).
  • Action: Update the mission statement to include Scheduling. Owner: Line
  • Action: Update the Formal Relationship with other HL7 Groups to include FHIR Infrastructure
  • Action: Action: move the top header which now shows Scheduling and Logistics (Archived) to the bottom of the page and add Personnel management.
  • Action: Action: Personnel management page to refer back to Patient Administration.
  • Action:
Next Meeting/Preliminary Agenda Items
  • .

Monday Q2

HL7 Patient Administration Meeting Minutes

Location: Winter Park Room 49

Date: 2016-01-11
Time: Monday Q2
Facilitator Irma Jongeneel Scribe Alex de Leon
Attendee Name Affiliation
X Irma Jongeneel HL7 Netherlands
X Alex de Leon Kaiser Permanente, USA
X Brian Postlethwaite HealthConnex, Australia
X Line Saele HL7 Norway
X Peter Bernhardt Relay Health, USA
X Andrew Torres Cerner
X Iryna Roy HL7 Canada
X Christian Hay GS1
X Jim Whicker Cognosante, USA
X Sean Moor EPIC, USA
X Nat Wong HL7 Australia
X Steve Bauman McKesson, USA
X Toril Reite HL7 Norway
X Dennis Basinger eviCore Healthcare, USA
Quorum Requirements Met (Chair +2 members): Yes

Agenda

Agenda Topics

  1. Open Session for new proposals
  1. Feedback from implementation of Appointment Resource
  2. Feedback from implementation of Encounter Resource

Supporting Documents

Minutes

Minutes/Conclusions Reached:
Introductions
FHIR
Preparation processing cadidaet tracher items for WGM

  1. 9235 - 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)

Thye WG discussed how this data is used more widely than just with the scope of the encounter and thus including it on the Encounter resource (as an element or an extension) doesn’t seem to be most appropriate.

The WG feels that this content should be better modelled as an observation, especially since there are SNOMED codes that support this type of information and thus will defer to Patient Care and discuss during the joint session with them (Wed Q2).

  1. 9260 - Restructure availability in HealthService resource

A motion was made by Irma to defer until after DST3 do to the fact that the WG has not received “real world” experience with the resource itself. Seconded by cooper.
Discussion: Alex clarified that this is whin our domain because it is describing healthcare services provided at a particular location wihin an Ornanization.
Vote: 11/0/0

10235 - Encounter priority search parameter, sorting
I think sorting by priority in Encounter is an important use case, Eg. Emergency Department patient tracking lists should be sortable by triage category.

There should be a search parameter on Encounter.priority to enable sorting, and possibly a review of the priority example codes provided (triage categories are usually 1-5, which is machine-sortable).
The WG discussed first the concept of sortability. After discussion, the WG deemed that the priority field will be added as a searchable property as requested. The example value set as it is an example binding, it can be replaced as needed. A motion was made by Irma to add the priority field sa s earchapby propert and make noews that it is a sample binding. Sort is made by the application and that not all elements will be Vote: 10/0/1

  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).
The WG examined the Encounter resource. The Enounter.indication element “points to” the condigion or procedure. After reviewing the Encounter, Condition and Procedure, the WG noted that the ranking of procedures to be performed during an encounter is not stored within the encounter. The same approach should also be applied to the conditions.
This would be on the actual procedure record itself, thus the WG decided to discuss this during the joint session with Patient Care (Wed Q2).
Kath noted that there is no clear use case and that perhaps the WG should solicit the use case that prompted this tracker item since we have assumed a billing context.

  1. 9194 - Episode of Care - revisit linkage

The WG discussed and noted the current reference structure and determined that the current structure is flexible and supports the creation of the episode of care in planning and referencing the encounters to that episode of care as well as discovering various encounters are related and must be referenced back to an overall EpisodeOfCare. Therefore, the WG considered
Cooper moved to retain the current structures that support the various use cases. Alex seconded.
Discussion: None
Vote: 10/0/1

  1. 9276 - Add arrival date/time in Encounter

The date and time when the ambulance/Emergency Medical Services (EMS) pulls into the hospital driveway and arrives at the hospital. If arrival is by air ambulance, it is the date when the aircraft lands on the facility's heliport. See for related data element
The WG reviewed the Encounter resource and noted that there is a statusHIstory.period that can support the date/time of arrival.
Diuring this discussion, the WG noted that the required status which is required does not include Triage
This will also be discussed during Wed Q1
Irma moved to not persuasive. Alex seconded
Vote: 8/0/2
Resolved. No change.

Meeting Outcomes

Actions (Include Owner, Action Item, and due date)
  • Action: Explore an easier way to find schedule with available slots. Owner: Brian
  • Action: For MPI searches, further define the query. Owner: Brian
Next Meeting/Preliminary Agenda Items
  • .

Monday Q3

HL7 Patient Administration Meeting Minutes

Location: Room # Winter Park Room 49

Date: 2016-01-11
Time: Monday Q3
Facilitator Irma Jongeneel Scribe Alex de Leon
Attendee Name Affiliation
X Irma Jongeneel HL7 Netherlands
X Line Saele HL7 Norway
X Alex de Leon Kaiser Permanente
X Christian Hay GS1
X Jim Whicker Cognosante, USA
X Toril Reite HL7 Norway
X Alexander Henket Nictiz, The Netherlands
Quorum Requirements Met (Chair + 2 members): Yes

Agenda

Agenda Topics

  1. Ballot reconciliation of CMETs

Supporting Documents

Minutes

Minutes/Conclusions Reached:
Introductions
Connectathon Update
Patient Track had a more rigorous use along with the “beginners” track. Doesn’t seem to be any major issues with the Patient resource

Brian also presented a topic that came up during the connectation regarding Provider role and location. Various visuals were presented attempting to model organizations, locations and practitioner roles with their relationships.

Action: Next connectathon new track for evaluating updates and creation of encounters potentially using the Patch operations. Brian.
Patch operation.

Argonaut project is also interested in provider directory which is more US centric. Australia has an effort for provider directory using FHIR. Action: Discuss organization/Provider Role/endpoint relationship models as potential material for an implementation guide and where it should be stored/balloted/etc. during joint meeting with FMG/Infrastructure Tuesday Q1. This could also set the standard practice for future such documentation. Brian

Organization Affiliation resource proposal – Brian reviewed the proposal for an affiliation backbone element off of the Organization to indicate the affilications such as networks, organization relationships, etc. This seemed to be something needed by representatives to the WG. The next question would be if it is truly an element off of the Organization resource or a resource unto itself. The WG noted that there were similar resources such as:
Group







===Meeting Outcomes===

Actions (Include Owner, Action Item, and due date)
  • Action: Submit a publication request. Owner: Line
  • Action: Send a thank you to the voters for voting and passing of the CMETS. Owner: Line
  • Action: Update the attendance list. Owner: Alex de Leon
Next Meeting/Preliminary Agenda Items
  • .

Monday Q4

HL7 Patient Administration Meeting Minutes

Location: Room # 1367

Date: 2016-01-11
Time: Monday Q4
Facilitator Line Saele Scribe Alex de Leon
Attendee Name Affiliation
X Irma Jongeneel HL7 Netherlands
X Line Saele HL7 Norway
X Alex de Leon Kaiser Permanente, USA
X Christian Hay GS1
Quorum Requirements Met (Chair + 2 members): Yes

Agenda

Agenda Topics

  1. Approve Atlanta Minutes
  2. Plan next meeting Draft Agenda
  3. Harmonization proposals
  4. v2 work

Supporting Documents

Minutes

Minutes/Conclusions Reached:
Introductions

  1. 9626 No way to store what services are available at a facility

One use case we want to use the location resource for is discovering information about a facility, including the services it offers. When a patient is being referred, it's important to know which facilities provide the services that patient needs to recieve adequate treatment. It's common for facilities to have a list of services they provide. For example, a hospital might have a cardiology, oncology, and obstetrics services available. We propose adding a healthcareService element to the location resource.

No change, the information of linkages is in the resource. Resolved no change

  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.

I see the improvement. But you still require an Endpoint to have at least one declared payload. What about open-ended endpoints? I would rather see this as 0..* Especially logical since all you have is an example valueset, which indicates to me a very immature concept.

Secondary worry about disconnect between payload mime types and payload types... and if these are inbound vs outbound formats? Are these informative or a conformance? I suspect these are just informative.
To be discusedTues Q1

  1. 10764 - Endpoint.publicKey Endpoint.publicKey should be 0..*;

There are times late in a public certificate life when a new certificate is introduced. Thus thre is a period where two (or more) public keys overlap. This is especially important for asynchronous endpoints. Pushed to Wed Q1.

  1. 8413 - HealthService.serviceType.type definition needs improving

what's a 'type'? It would be more helpful to define it as the clinical specialty being delivered, performed or planned. This was submitted when healthcare servire had a “type” but it has been renamed as “serviceType”. So, work to clarify this has already been completed. Question answered.

  1. 10175 - payloadFormat should be 1..*, and be part of a payload backbone element PayloadFormat should be multi response (0..*). since it's common for an interface to support multiple payload formats. For example, Denmark has a national binary interface (Medcom XBIN) that has a list of over 30 different filetypes it supports. In the US, EHRs often accept XML documents, and a subset of 'image' documents that are allowed to be exchanged with the XML document.

I would also propose that payload format and type be included under a 'payload' backbone element. The main benefit with this would be to allow implementers to associate a specific format, type and extensions in one logical unit. For a close to real world example, consider a healthcare organization that uses CDA, and accepts both CCR and CCDA (version 2.1) documents. the MIME type for all of these would be application/xml, and the type would be CDA. However CCR and CCDA are all specific implementations of CDA, with their own versioning, etc. A backbone element would allow implementers to associate extensions with their specific versions/types of CDA documents.

WG response: The Endpoint resource has been substantially reworked since this item and covers the issues noted here. Considered no action required.

  1. 10174 - (HTTP) Method should be a standard extension of Endpoint

Method is an HTTP specific concept, and the endpoint resource should not be HTTP specific. I propose making method a standard extension that should be specified if the connectionType is HTTP.

The WG noted that the Method concept was removed from the core as part of the redesign of the endpoint resource. No action require. Resolved, no change.

  1. 10099 - connectionType element is vague, and not robust enough on Endpoint resource. The connectionType element and valueset are vauge and difficult to use. It also does not capture all of the necessary information to establish a connection for all of the SOAP based use cases we want to use it for.

This property has undergone significant rework since this item was logged and now covers the identified issue. It has been refined and clarified. This was interactive with method. Now it addresses this issue. No change needed. Considerd no change.

  1. 10140 - Binding for Endpoint.payloadType

I think these need to be aligned DocumentReference.content.format http://hl7.org/fhir/documentreference-definitions.html#DocumentReference.content.format WG noted that the binding currently set covers the DocumentReference.content.format. The code systems are aligned but are not the same value sets. But future requirements may need additions to the DOcumentReference.content.format. Cooper moves to disposition this non persuasive/Andrew seconded. Discussion: None Vote: 12/0/0

  1. 8732 - Organization.type cardinality

Organization.type has cardinality of 0..1, but would like to see this changed to 0..* For example, there are religious-based schools, religious-based hospitals, and academic/teaching-based hospitals, so picking one org type (religious, school, or hospital) is too restrictive.
The WG initially leaned toward relaxing the cardinality, but Simone noted that in practice there is no way to set a hierarchy or role based to determine the primary organization. In the end nobody had an objection to relaxing the cardinality. We expect that some jurisdictions will profile this down, and we do encourage that it is used sparingly. Many cases where this might be considered, could be better represented using child organization resources. This will be clarified in the detailed description of the element.

A motion was made by Andrew to change the cardinality of Organization.type to 0..* Seconded by Cooper Discussion: None Vote: 11/2/0

Meeting Outcomes

Actions (Include Owner, Action Item, and due date)
  • Alex Action Item - PA decision: No suggested values and remove the values in 2.9. Include following URLs for example values as part of implementation notes:
  • Action: Communicate to the v2 project to remove the above. Alex
  • Action Item: (Alex/Wendy) Contact CGIT co-chairs, and Brian Pech from publishing and Tony Julian from INM to see if this is possible to update this table 452 as noted above. Same for tables 453, 454. Also contact Heather Grain on the HTA. If approved, then the PAWG would like to change the table to user-defined, remove suggested values and reference the appropriate level of the ANSI ASC X12 Health Care Provider by table.
  • Action item: Follow up with Wendy on action items. Followed up with Ted
Next Meeting/Preliminary Agenda Items
  • .

Navigation

© 2017 Health Level Seven® International. All rights reserved. [[Category:2017_PA_WGM_Minutes]