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

2017-01-19 PA WGM Minutes

From HL7Wiki
Jump to navigation Jump to search

Return to: WGM Minutes > 2017 > January San Antonio

Patient Administration Work Group Minutes - January 19, 2017

Thursday Q1

HL7 Patient Administration Meeting Minutes

Location: Hyatt San Antonio, Directors Conference Room

Date: 2017-01-19
Time: Thursday 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 Vadim Peretokin NEHTA
X Jim Whicker Cognosante
X Dominik Bremman Patient Care Work Group
X Alexander Henket NICTIZ, The Netherlands
X John Roberts PHER Work Group
X Chad Albert Infor, USA
Quorum Requirements Met (Chair + 2 members): Yes

Agenda

Agenda Topics
Welcome/introductions

  • HAVE Project/TEP

Supporting Documents

Minutes

Minutes/Conclusions Reached:
Introductions

The WG considered the work for this quarter. There does not seem to be any representatives ffrom PHER to discuss the HAVE/TEP project. The discussion centered around the current change in US administration and how that may have affected the progress, or lack thereof, for this project.

Congratulations to Irma for re-election to co-chair.

FHIR vocabulary – Nancy as our vocabulary facilitator went to the Encounter.status

  1. 9271 –Summary: The relationship between the scheduling resources should be summarized somewhere in the spec

The complex relationship between all the schedule related resources should be better documented, potentially with some diagrams, and the relationship between the fields. (see attached for draft) Typically schedulable resources: Practitoner, Location, HealthcareService, Device, Patient Actual schedule resources: Schedule, Slot, Appointment, Appointment Response Note: The typical status flows are already documetned in the Appointment.

<< scheduling diagram >> The WG worked through the diagram to be included into the FHIR specification to depict the relationship for scheduling resources. In comparing the diagram with the scheduling resource, the diagram needed the addition of the Practitioner Role, Device, RelatedPerson. The Organization was removed from the diagram as not being relevant to the scheduling relationships. This will be included on the modules page along with descriptions of the appointment, scheduleslot and appointmentrequest resource. A motion was made by Irma to disposition this as persuasive and continue with the addition of this diagram into the modules page of the FHIR specification. Seconded by Brian. Discussion: None Vote: 10/0/0 Motion carries.

  1. 9622 - No place to store location specific contact info or IDs on the practitioner resource

One of the primary use cases of the practitioner resource is to improve coordination of care by making providers more discoverable and facilitating communication. A very common use case is sending information to the next practitioner that will care for that patient. It's critical to send that information to the right person, at the right place. Practitioners usually work in more than one location, and have different systems of communication at each place. A practitioner will often have a different fax machine at each facility they work at. It's also common to have different electronic medical record systems at each location, which require different IDs to facilitate electronic exchange and routing. Each identifier or contact point is unique to one physical location. There's currently no place to store that kind of information on the practitioner resource. This makes routing and publishing information necessary for communications impossible.

We've discussed this with the PA group in a call and there are many different solutions. Some examples are

    1) changing the cardinality of the location to 1 in the practitionerRole resource, and creating 'dummy' locations that are specific to a provider at a location
    2) Adding addresses, contact points, and identifiers to the practitionerRole element
    3) Creating a new backbone element nested under practitionerRole that has a location or address element with a cardinality of 1. It would also contain contact points, identifiers, and healthcare services

I personally prefer some flavor of #3, because it avoids creating weird location resources, but is conceptually very similar to that resource, which is what we need. I believe the argonauts are moving in this direction as well.

This was before the practitionerRole was broken out of the Practitioner resource and the Pracitioner updated. Doing so has provided support for the use cases described here. Considered – Questions answered. Motion made by Brian to accept this disposition. Cooper seconded. Discussion: None Vote: 10/0/0

  1. 9737 and #9226

Action Item: Brian, Michelle and Lloyd will discuss offline and Brian will bring results to the group in call.

  1. 12635 - Should Unknown and/or other be added to the encounter status value set? Since status is required and has a required binding, should unknown be added to the list of supported values? Systems may create values that may not map to the value set required.

The WG discussed the addition of Unknown or Other and what that would mean in the context of the encounter status. After discussion, the WG considered that there were 3 options… relaxing the cardinality, use of Unknown or use of Other. There was no support in the room for relaxing the cardinality or use of Other. Unknown seemed to the additional status that would meet the needs of the submitter and still strongly encourage the use of the supplied codes. A motion was made by Brian and seconded by Drew to extend the Encounter.status value set by the addition of the Unknown. Discussion: None Vote: 10/0/0

  1. 8843 - Appointment V2 mapping corrections

Mapping corrections: ARQ-11.2 (Requested start date/time range) to Appointment.end is wrong ARQ-7 (Appointment Reason) Table 0276 (Routine/Walkin/Checkup...) doesn't semantically map to Appointment.reason (LOINC-Code)

This is with regards to the Appointment mappings to V2. The WG reviewed the mapping with the v2 specification. It was noted that because the FHIR Appoinment resource acts as both a request and response, the state of the Appointment maps to various elements for v2. Work was done to map as best as possible from the FHIR Appointment resource to v2. The ARQ11.2 was Additionally, some of the codes defined in v2 did not map directly to FHIR elements due to terminology (e.g. Appointment reason codes in v2 actually Appointment.appointmentType). Brian asked during this time if we could update the v3 mapping for the Appointment resource while we are covering this. Irma volunteered to look up the mapping for “requestedPeriod”. Motion moved by Brian, seconded by Irma to update mapping. Discussion: None Vote: 10/0/0

Meeting Outcomes

Actions (Include Owner, Action Item, and due date)
  • Action:
Next Meeting/Preliminary Agenda Items
  • .

Thursday Q2

HL7 Patient Administration Meeting Minutes

Location: Hyatt San Antonio, Directors Conference Room

Date: 2017-01-19
Time: Thursday 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 HealthConnex, Australia
X Line Saele HL7 Norway
X Erin Murphy Cognosante
X MaryKay McDaniel Congosante
X Eivind Kristiansen HL7 Norway
X Jim Whicker Cognosante
X Raheen Daya McKesson
X Lisa Doerr McKesson
X Paul Knapp HL7 Canada
Quorum Requirements Met (Chair +2 members): Yes

Agenda

Agenda Topics

  1. FHIR – Patient Administration and Financial Management joint resources

Supporting Documents

Minutes

Minutes/Conclusions Reached:
Introductions

The WG welcomed the joint with Financial Management. Paul Knapp asked to begin joint discussion on Administrative gender. Paul questioned the value of having a set of required values that have 4 values with extensions rather than have an extensible set of values.

The next item of mutual interest was the Coverage resource. The WG reviewed this specific resource. After a long discussion, around Coverage.beneficiary, having to do with insurance knowledge of the term versus the clarity around the subject of care which is consistently known as Patient. Since there was no consensus, the WGs decided to rely on the opening of a tracker item on this. However, the description will be updated to cover the various uses of this element.

The WG continued to cover the other elements within the Coverage resource.
The WG considered the use and relationship with the Account resource, which contains the reference Account.coverage.
WGs considered and discussed the creation of a backbone element to allow for priority and coordination of benefits.
Action: Create a backbone element that reference coverage and the coordination of benefits (ordering). Owner:Cooper

The WGs discussed the creation of ChargeItem resource to expess finance related service item what will be “billed” or put on a claim The Financial Transaction resource expresses the activities within the healthcare event (Encounter) to capture in the Account resource. .

The WGs discussed the flow.

The WGs considered that these two concepts might be expressed in one Resource.






Meeting Outcomes

Actions (Include Owner, Action Item, and due date)
  • Action:
Next Meeting/Preliminary Agenda Items
  • .

Thursday Q3

HL7 Patient Administration Meeting Minutes

Location: Hyatt San Antonio, Directors Conference Room

Date: 2017-01-19
Time: Thursday Q3|-
Facilitator Brian Postlethwaite Scribe Alex de Leon
Attendee Name Affiliation
X Irma Jongeneel HL7 The Netherlands
X Alex de Leon Kaiser Permanente, USA
X Toril Reite HL7 Norway
X Brian Postlethwaite HealthConnex, Australia
X Michelle Miller Cerner, USA
X Frank Noge Infor, USA
X Rusell McDonell Telstra Health, USA
X Richard Kavanaugh HSCIC (NHS), U.K.
X Simon Knee HSCIC (NHS), U.K.
X Inger H. Storeivedt-Khateeb HL7 Norway
Quorum Requirements Met (Chair + 2 members): Yes

Agenda

Agenda Topics

  1. FHIR – Joint with Patient Care

Supporting Documents

Minutes

Minutes/Conclusions Reached:
Introductions

FHIR QA and FMM review In reviewing the resources the WG considered the desired FMM levels this was considered with the following maturity levels as defined in the FHIR specification STU3: 2.28.3.8 Maturity Levels All resources in this specification are assigned a "Maturity Level", known as FMM (after the well known CMM grades). The FMM level can be used by implementers to judge how advanced - and therefore stable - a resource is. The following FMM levels are defined: 0. The resource or profile (artifact) has been published on the current build. This level is synonymous with Draft. 1. PLUS the artifact produces no warnings during the build process and the responsible WG has indicated that they consider the artifact substantially complete and ready for implementation 2. PLUS the artifact has been tested and successfully exchanged between at least three independently developed systems leveraging at least 80% of the core data elements using semi-realistic data and scenarios based on at least one of the declared scopes of the resource (e.g. at a connectathon). These interoperability results must have been reported to and accepted by the FMG 3. PLUS the artifact has been verified by the work group as meeting the STU Quality Guidelines and has been subject to a round of formal balloting; has at least 10 implementer comments recorded in the tracker drawn from at least 3 organizations resulting in at least one substantive change 4. PLUS the artifact has been tested across its scope (see below), published in a formal publication (e.g. STU), and implemented in multiple prototype projects. As well, the responsible work group agrees the resource is sufficiently stable to require implementer consultation for subsequent non-backward compatible changes. 5. PLUS the artifact has been published in two formal publication release cycles at FMM1+ (i.e. STU level) and has been implemented in at least 5 independent production systems in more than one country

Below are the resources discussed and their desired maturity level: Practioner – 3 PractitionerRole – 3 Paient – 5 RelateDPerson – 3 Person – 3 Appointment - 4
Patient WG considered if it could be raised to FMM level 4. Irma to approve the Patient resource to raise to FMM level 4. This is a commitment to raise this to that level and not make changes that could “break out” of the requirements for 4. Drew seconded. Discussion: None Vote: 8/0/0 Drew volunteers to do the editing for the Patient resource.

Practitioner The WG then went on to consider Practitioner. The WG noted that the following tracker item exists but now refers to an element. The approval to make the change within this tracker will resolve and allow the move of Practitioner to a higher FMM level.

  1. 8513 - Practitioner.qualification needs work There is a new project coming up for handling employment related information post STU3 and we can handle this during that project. 1. Practitioner.qualification needs a type code, e.g. Degree, License, certification, Prodessional society membership

2. The current value set for Occupations is not a good fit. The fact that a person is currently employed as a proctologist does not mean they are qualified to be one. The WG noted that this is persuasive. The WG considered this tracker as related to the one above however 8513 is being deferred as the code set is only a part of the request (e.g. addition of a type code)

  1. 12659 – Practioner. Change value set of practitioner.qualification to use taxonomy us codes. The example value set is not representative of the purpose of the field. We should switch the example value set to use the US taxonomy codes.

After some research, the WG decided to use the v2 value set from table 0360 to more appropriately list the codes for Practitioner.qualifcation.code code set. Drew moves to use the v2 Degree/license/Certifcation code table as the codes for the Practitioner.qualification.code. Micheal seconded. Discussion: None Vote: 9/0/0 Account – 1 Appointment - 4 Motion is made by Cooper, seconded by Drew to, approve as a work group the raising the Appointment Resource to level 4. Discussion: None Vote: 9/0/0

  • Appointment - 2

Left at 4

  • Encounter – 1

The WG noted that although there is at least one implementation in production, it has never been used in a connectathon, which is a requirement for FMM2. Cooper noted that the relationships to Condition and Procedure and potential “circular dependency” may change the resource enough to keep this at FMM1

  • EpisodeOfCare – 1

The WG decided to retain this at 1.

  • HealthcareService – 1

Left at 1

  • Location – 2

WG decided to commit to raise this to level 3.

  • Organization – 1

WG decided to commit to raise this to level 3

  • Person – 1

WG decided to commit to raise this to level 1

  • Practitoiner – 2

WG decided to commit to raise this to level 3

  • PractionerRole - 0

WG decided to commit to raise this to level 3

  • RelatedPerson – 1
  • Schedule – 2

WG decided to commit to raise this to level 3

  • Slot – 2

WG decided to commit to raise this to level 3

  • Endpoint – 0
WG decided to commit to raise this to level 3

New resource ChargeItem and OrganizationAffiliation (group?) Brian reviewed high level and needs for review and editing of the resources.

Meeting Outcomes

Actions (Include Owner, Action Item, and due date)
  • .
Next Meeting/Preliminary Agenda Items
  • .

Thursday Q4

HL7 Patient Administration Meeting Minutes

Location: Hyatt San Antonio, Directors Conference Room

Date: 2017-01-19
Time: Thursday Q4
Facilitator Irma Jongeneel Scribe Alex de Leon
Attendee Name Affiliation
X Irma Jongeneel HL7 Netherlands
X Line Saele HL7 Norway
X Alexander Henket NICTIZ, The Netherlands
X Jose Costa Ieixeira IHE
Quorum Requirements Met (Chair + 2 members): Yes

Agenda

Agenda Topics

  1. Wrap up
  2. Approve next ballot
  3. FHIR Planning
  4. Address PBX matrix
  5. Work Group Health
  6. 3 year work plan
  7. Address the draft agenda for May
  8. Approve the minutes from Atlanta (cont. from Monday)

Supporting Documents

Minutes

Minutes/Conclusions Reached:
Introductions
The WG continued with the ballot reconciliation of v2.9. Certain comments prompted action items to bring back to publishing for guidance. Comment # 113 – While the WG considered this persuasive, in the discussions were the inconsistency within the overall specification between the use of the ROL segment (here in PA) and the PRT segment (in OnO?), conveying the same information. During harmonization prior to v2.9, it was noted and suggested that the PRT segment be used throughout. Upon discussion, the PAWG was unclear regarding the use of the PRT segment, and felt that the replacement of this segment would break backward compatibility. In trying to identify the difffernces and reasoning behind these two segments, the WG noted that the PRT segment is defined in the Chapter 7 Observation Reporting, while the ROL segment is defined in Chapter 15 Personnel Management. It appears that these two segments were defined separately for similar usages which lead to the need to harmonize. This harmonization was done prior to v2.9 publication but the WG is unclear of when the decision was made to use the PRT segment throughout the specification.
Action: Contact Ted Klein as one leader in the harmonization effort to find out the reasoning of choosing the PRT segment to be used throughout the specification. Is it actually true that we need to replace? Alex. Due: 02/07/2017
Action Item: Depending on the action above, either work to use the PRT segment and get guidance on the breakage of backwards compatibility or continue usage of the ROL segment and advice the publishing group of the similarity of functions of these segments. Alex. Due: 02/07/2017
Action Item: Apply the changes based on the comment spreadsheet dispositions. Alex. Due: 02/07/2017
Action Item: Review the process for resolution and communication of the ballot resolutions with the submitters. Alex. Due: 02/07/2017
The WG will work on consolidating the action items for review and accountability. These will be reviewed and distributed via emails. Reminders to be sent Adjourned

Meeting Outcomes

Actions (Include Owner, Action Item, and due date)
  • .
Next Meeting/Preliminary Agenda Items
  • .

Navigation

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