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

May 2014 WGM

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

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.

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

9737 and #9226

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

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

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

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

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.

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)

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