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

2017-01-16 PA WGM Minutes

From HL7Wiki
Revision as of 01:07, 28 January 2017 by Ajdeleon7 (talk | contribs) (Created page with "Category:WGM Minutes 2017 01-San Antonio Return to: WGM Minutes > 2017 > :Category:WGM Minutes 2017 01-San Anto...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search


Return to: WGM Minutes > 2017 > January San Antonio

Patient Administration Work Group Minutes - January 16, 2017

Monday Q1

HL7 Patient Administration Meeting Minutes

Location: Hyatt Regency San Antonio, 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, USA
X Line Saele HL7 Norway
X Brian Postlethwaite Telstra Health, Australia
X Cooper Thompson EPIC, USA
X Christian Hay GS1, Switzerland
X Sam Mater EPIC, USA
X Alexander Henket NICTIZ, The Netherlands
X Jonathan Shultif Transend Insights
X Wes Rishel Self
X Mead Walker Northrup Grumman IT
X Sam Rubenstein Montefiore
X Kathy Pickering Cerner
Quorum Requirements Met (Chair + 2 members): Yes

Agenda

Agenda Topics
Welcome/introductions

  • Approve agenda
  • Review PA Mission & Charter
  • Review Decision Making Practice]
  • Review 3-Year Work Plan]
  • Review SWOT Analysis

Supporting Documents

Minutes/Conclusions Reached:
Introductions
WG started with the approval of the agenda.
During the meeting there was a question 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.
The WG agreed that this would be the best course of action.

Meeting Outcomes

Actions (Include Owner, Action Item, and due date)
  • Action: Fix link of DMP to most recent document (v3 to v4). Line.


Next Meeting/Preliminary Agenda Items
  • .

Monday Q2

HL7 Patient Administration Meeting Minutes

Location: Hyatt Regency San Antonio, Directors Conference Room

Date: 2017-01-16
Time: Monday Q2
Facilitator Brian Postlethwaite Scribe Alex de Leon
Attendee Name Affiliation
X Brian Postlethwaite Telstra Health, Australia
X Irma Jongeneel HL7 Netherlands
X Alex de Leon Kaiser Permanente, USA
X Line Saele HL7 Norway
X Cooper Thompson EPIC, USA
X Sam Mater EPIC, USA
X Mark Kramer MITRE, USA
X Jonathan Shultis Transcend Insights, USA
X Christian Hay GS1, Switzerland
X Wes Rishel Self, USA
X Sam Rubenstein Montefiore, USA
X Kathy Pickering Cerner, USA
Quorum Requirements Met (Chair +2 members): Yes

Agenda

Agenda Topics

  1. FHIR Preparation Processing Candidate Tracker Items for WGM Discussion

Supporting Documents

Minutes

Minutes/Conclusions Reached:
Introductions
FHIR
Preparation processing candidate tracker 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)

The 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 as searchable property and make known that it has a sample binding. Sort is made by the application and that not all elements will be required. 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 condition 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).
Kathy 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

Current linkage between Episode of Care and Encounter materializes as a reference on Encounter. The rationale has been stated as EoC being created first and therefore should be the target of reference from later created Encounters. I think this neglects a substantial use case in the multi-disciplinary practice world and also limits the utility of EoC for practice and other analytics. Consider these (prevalent at Mayo for instance): Each practice defines an EoC for their particular context to (both operationally and analytically) measure practice performance. For instance, a surgical practice defines an EoC that starts with any initial consult that is followed by a surgery in which the practice participates. This means that a series of surgeries may all be part of the primary services EoC, but a second EoC might exist for Plastics that got involved only in the 3rd of the series. In the current model, Encounters would be continually updated as rules and other actors determine that new EoC have initiated. This does not reduce the utility or efficacy of the primary service's EoC (what I think the current model is targetting), but adds capability/reduces churn for the others. The second rationale for the change looks at the "concreteness" of Encounter vs. EoC. In many (most?) systems, Encounter is relatively well defined, has inception and termination criteria, and generally is unambiguous in information systems. EoC on the other hand is much more of a composite contruct to coordinate/measure activity. A general principle then could be to try and make the more concrete resource stable (Observation is a great example - don't cause churn on Observation!) and allow the more ephemeral to "catch" the churn. In other words, I would argue that in many real world scenarios, the EoC doesn't exist first as currently stated, but rather is triggered by the creation of the Encounter (admission, consult, etc.).

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 the feedback but determined to keep the current reference from encounter to EpisodeOfCare.

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. This can be referenced to capture the arrival date and time since the codes show as “planned | arrived | in-progress | onleave | finished | cancelled | entered-in-error”.
During this discussion, the WG noted that the Encounter.status, which is required, does not include Triage which is most likely needed to cover most use cases.
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)
  • None
Next Meeting/Preliminary Agenda Items
  • .

Monday Q3

HL7 Patient Administration Meeting Minutes

Location: Hyatt Regency San Antonio, Directors Conference Room

Date: 2017-01-16
Time: Monday Q3
Facilitator Irma Jongeneel Scribe Alex de Leon
Attendee Name Affiliation
X Irma Jongeneel HL7 Netherlands
X Line Saele HL7 Norway
X Brian Postlethwaite Telstra Health, Australia
X Alex de Leon Kaiser Permanente, USA
X Christian Hay GS1, Switzerland
X Cooper Thompson EPIC, USA
X Sam Mater EPIC, USA
X Simone Heckmann HL7 Germany
X Tim McNeil Surescripts, USA
X Jonathan Shultis Transcend Insights, USA
X Sam Rubenstein Montefiore, USA
X Drew Torres Cerner, USA
X Richard Kavanaugh NHS Digital, UK
Quorum Requirements Met (Chair + 2 members): Yes

Agenda

Agenda Topics

  1. Open for New proposals/Update FHIR Connectathon/Projects

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 the Group resource.

Action: The Group resource needs to be discussed and compared to the proposed OrganizationAffiliation proposal thougths. Brian

===Meeting Outcomes===

Actions (Include Owner, Action Item, and due date)
  • Action: Next connectathon new track for evaluating updates and creation of encounters potentially using the Patch operations. Brian.
  • Action: The Group resource needs to be discussed and compared to the proposed OrganizationAffiliation proposal thougths. Brian
Next Meeting/Preliminary Agenda Items
  • .

Monday Q4

HL7 Patient Administration Meeting Minutes

Location: Hyatt Regency San Antonio, Directors Conference Room

Date: 2017-01-16
Time: Monday Q4
Facilitator Brian Postlethwaite Scribe Alex de Leon
Attendee Name Affiliation
X Irma Jongeneel HL7 Netherlands
X Line Saele HL7 Norway
X Brian Postlethwaite Telstra Health, Australia
X Alex de Leon Kaiser Permanente, USA
X Christian Hay GS1, Switzerland
X Cooper Thompson EPIC, USA
X Sam Mater EPIC, USA
X Simone Heckman HL7 Germany
X Jonathan Shultis Transcend Insights, USA
X Richard Kavanaugh NHS Digital, United Kingdom
X Sam Rubenstein Montefiore, USA
X Drew Torres Cerner, USA
X Daniel Cheat Health and Human Services-Office of the National Coordinator, USA
X Sandeep Giri University of California San Francisco, USA
Quorum Requirements Met (Chair + 2 members): Yes

Agenda

Agenda Topics

  1. FHIR Provider Directory resource development

Supporting Documents

Minutes

Minutes/Conclusions Reached:
Introductions
The WG continued with the FHIR tracker items as the parties to discuss FHIR Provider Directory were not present.

  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 discussed Tues 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 Drew 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)


Next Meeting/Preliminary Agenda Items
  • .

Navigation

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