Skip to end of metadata
Go to start of metadata

Tuesday Q1

Reviewed Agenda, made some minor adjustments, cancelled the Friday Q4 session due to availability of co-chairs

Approval of Agenda Motion by Brian Postlethwaite / Gabriela Espinosa 7-0-0

The Mission and charter was reviewed, and no amendments were suggested

Reviewing the 3 year workplan

  • HAVE/TEP project - is this still ongoing, now that its published
  • Question status of the Scheduling project for review to consider removing in San Antonio
  • Nothing to take to the Steering division

Reviewed the SWOT, and no changes suggested

V3 Person Ballot was re-affirmed, 39-48-0 (Quorum 87.88%) ballot passed

Review V2 projects, 2.9, questioning will the next official version be 2.9.1, or 2.10?

There are 2 open change requests

  • NTE segment was created for adding notes, but no message structures have yet been updated to use it yet, expecting to add it to Encounters (requested by Cerner)
  • Irma Jongeneel - check with Hans to see if the NTE segment changes is still desired.
  • Adjust telecom fields on the contact person to support repeating telecom values, deprecate and add repeating segment

Brian gave an overview of the results of the Connectathon

2020-02 Connectathon 23

Request for New Projects if any were to be considered

  • Uday referred to the Child Health project and pharmacy projects - in progress by ADHA (STU3), tight schedule preventing move to R4 at this stage



"Work Group" = "Patient Administration [pa]" AND "Related Artifact(s)" = "Encounter: core [FHIR-core-Encounter]" and not status in ( Applied, Canceled, published, "Resolved - change required", "Resolved - No Change", Duplicate) ORDER BY cf[11300] ASC

Tuesday Q2

Encounter trackers


Currently using an extension - period, start, end and servicetype.

FHIR-23764 - Encounter v2 mappings

Update the mappings as provided

Brian Postlethwaite/Michael Donnelly: 6-0-7

Tuesday Q3

FHIR-25037 deferred to Wed Q4

FHIR-17304 not pursuasive Brian Postlethwaite/Uday Chandrupatla : 6-0-2

FHIR-20479 persuasive Brian Postlethwaite/Pascal Pfiffner: 7-0-1

FHIR-25215 persuasive Russell McDonell/Tarek Assad: 6-0-1

FHIR-23837 Rename Encounter.participant.type to role? 

Discussed the type vs role, in existing systems this appears to be quite fluid and not well differentiated.

General agreement was that the model as defined in the CareTeam structure was more consistent with intent, and seeking feedback from Patient Care (and anyone else) if changing the property (in Encounter and Appointment) to be consistent with CareTeam would cause issues.

e.g. Encounter.participant.role 0..1 CodeableConcept (and bind to the SNOMED participant roles valueset) 

Tuesday Q4

FHIR-22766 Encounter Planned dates

Persuasive with mod Brian Postlethwaite/Alexander Henket: 11-0-1

FHIR-17303 Encounter.statusHistory.code should be an extensible vocabulary

This was referred back to John Moerke for review on the existing design and approach to handle it

FHIR-22726 Suggesting guidance regarding Encounter Period start and stop times

This was discussed and noted for some clarifications, will follow up with this tomorrow

Wednesday Q1

FHIR-22726 Suggesting guidance regarding Encounter Period start and stop times

Drafted a proposed resolution that we agree on, and scheduled time to discuss with FM/PC before we put to a vote

FHIR-22765 - Getting issue details... STATUS  remove Encounter.length

FHIR-22767 - Getting issue details... STATUS  This will be deferred to handle when 22764 is done

Wednesday Q2

FHIR-25725 - question answered on possible approaches on how to handle Practitioner Master record management.

FHIR-24014 - Getting issue details... STATUS  After discussion (noted in the tracker) this has been moved to the joint session with FM, and may defer to O&O if needed.

FHIR-22764 - Getting issue details... STATUS  Make Encounter.reason more versatile, this was discussed, and will be postposed to discuss in person, hopefully at the San Antonio meeting (or an upcoming conference call)

Wednesday Q3

Patient Merge Review, walked though the definition, down to Post Merge Operations.

Consider when putting into the spec break into multiple pages

Wednesday Q4

FHIR I joint session

What resources are targeting for normative for R5

25427 - no one has asked to have this as a datatype as yet, so not so fussed it if was promoted.

25037 - Allow to search encounter by end/start date (where used on a period)

This could be handled through custom search parameters, which we are considering if these should go into the core specification already.

We have consulted with FHIR Infrastructure to see if there should be a more generic approach, or at least a consistent model to apply if/when others want to achieve this same outcome.

Currently recommending using the same sp name with X-start or X-end for the other 2 parameter names.

Will retain the joint session in San Antonio for the Tue Q1

The walkthrough of the Patient Merge operation was continued and concluded with the errors table. Several of the errors were reclassified from "Bad Request" to "Unprocessible Entity".

Thursday Q1

FHIR-25267 Patient Care advised that the Care Team is going to be updated to include a participant status - still in progress.

Patient Care have accepted sponsor for the IPA project (International Patient Access) - Grahame will be drafting the PSS

FHIR-22485 - Getting issue details... STATUS  after some discussion, and agreement that could change the cardinality on the serviceType and inclusion of a history property, that might be better to consider the more significant change on the Movement event.

Discussion on the refactoring of the Encounter to separate out the MovementEvent

The concept of a MovementEvent as being purely sequential was considered, however would desire to support concurrent/overlapping movements also.

If this is a backbone element, profiling to prevent overlapping could be done, with a new resource, this may be a challenge.

Is an EMS Transport an encounter? Maybe, and could be jurisdictional/system defined

Properties that are both on the Movement and Encounter may have different meanings, but for a start, will assume the encounter value is "current".

Should EpisodeOfCare also change? The relationship there isn't proposed to change - we may need to update the EoC documentation to also cover this.

The "definition" of what a "Movement" was called into question, and lead to a basic consideration of the original definition of Encounter as the direct recording of an interaction between a Patient and Healthcare professional, which is the definition as noted by the WHO. Over the past year FHIR has relaxed this definition, and we are considering covering the inpatient definition of an encounter as covering the entire admission.

In the next quarter we will complete the initial draft mapping the properties between the Enc/Movement then get onto the other trackers

FHIR-25453 may be discussed next Q

Thursday Q2

Complete the Mapping of the split between Movement and Encounter

Encounter.statusE/M *
Movement.encounterM (if it’s a resource)

Review the PA trackers

FHIR-23837 - Getting issue details... STATUS  This tracker has been referred to FHIR-I/MnM to try and decide if this is 

Review 25453 if needed - This was discussed with the submitter, and Michelle Miller identified that the submitter desires to re-challenge the outcome, Michelle will follow up on what the process the submitter needs to go through to achieve this.

Thursday Q3

FHIR-20484 - Getting issue details... STATUS  Persuasive with Mod: Brian Postlethwaite/Alexander Henket: 10-0-0

FHIR-22767 - Getting issue details... STATUS  associated with other refactoring exercises

  • Brian Postlethwaite to ask the community if the pre-admission Identifier is in common usage (wasn't among the members of the meeting)
  •  Brian Postlethwaite co-ordinate the scheduling of some joint PA/PC sessions to discuss the remaining Encounter design work.

In order to improve the quality and maturity of the Encounter resource and Implementation Guide is proposed to be created to provide informative guidance on ways of using the Encounter resource in different contexts.

This will be balloted as an informative only guide, and not going to normative.

  • Brian Postlethwaite to prepare an IG proposal form for approval on an upcoming PA call, then take to FMG

This IG could be similar to the guidance/profiles/examples sections in this guide.

FHIR-25793 - Getting issue details... STATUS

We explicitly chose to be the instant data type for force the type.

We didn't identify any use cases where you get an appointment with only a date(s), and no time component.

Cases where the exact time isn't known, but have a range of times such as home care where the appointment might be between 9 and 10 for 15 minutes is also supported with the current structure.

The other cases we had were where there was a request to schedule an 30 minute appointment sometime next week, which is covered through the requestedPeriod property. 

Logically when you get an appointment, you are always provided a time, otherwise its a requestedPeriod.

Scheduling systems which manage appointments all work on dates and times.

Not persuasive: Brian Postlethwaite/Issac Vetter: 10-0-0

Thursday Q4

FHIR-25419 - Getting issue details... STATUS  Persuasive with mod Jenni Syed/Brian Postlethwaite: 8-0-0

FHIR-22121 - Getting issue details... STATUS  Persuasive with mod Alexander Henket/Jenni Syed: 5-0-3

FHIR-22143 - Getting issue details... STATUS  

The CareTeam is included as a potential performer in the same way that the Organization is, essentially indicating that some member from this team performed the action, who it was wasn't recorded, or needed to be recorded.

The inclusion of the HealthcareService as a potential reference does make sense to be done here.

Were there other resources using this pattern that we should also be looking at, such as Encounter/Appointment?

The ChargeItem also has PerformingOrganization as well as this seems to be redundant, this needs further review.

FHIR-22101 - Getting issue details... STATUS  Appointment.priority / Request.priority

Extensive review of this and other related resources/usages of priority was done, and concern over the fixed nature of other used, and how we have handled Encounter which is also inconsistent.

Notes added and referred to Grahame Grieve for further comment.

Friday Q1

Hans Buitendijk discussed the status of the V2 to FHIR project

This project is mapping the stuff that people uses, not the complete set of v2 stuff.

Desire to produce consistent v2 mappings where possible/practical

The content will eventually be balloted, and intended to go to normative status

ADT, Orders, Results, Immunizations are the start point for the project

Walked through the structure of the mapping excel spreadsheet

The spreadsheet (GoogleSheet) will be migrating into ConceptMap resources to permit it to be more maintainable, and potentially used to generate code/used in mapping engines

Eventually will be moving to GitHub like any other FHIR IG

Will produce a visualization of this for inclusion in the IGs, which is likely similar to the spreadsheet

This mapping is a v2 to FHIR computable mapping, the reverse could be derived, but may need "tweaking"

Mapping to a FHIR profile was considered, but decided that this was overkill, will see how it goes. (e.g. for home phone vs work phone)

The narrative column provides the ability to define the "non computable" rules, which may then be further processed later if can be done

Properties that are usually or always localized such as race and ethnicity will be used as an example on how to provide some guidance, as we did with the patient in core, referring to the US Core examples.

These mappings for jurisdictions may be managed at the country, state, region, jurisdiction, product or installation level (as is done in v2)

Reviewing the minutes of the Sept 2019 was done, Michael Donnelly/Brian Postlethwaite 7-0-1

There was 1 image in the minutes that was missing (suspect is linking to Alex's local content)

Brian/Line/Alex will need to follow up with their action items.

There are no ballots to approve at this time

The 3 year work plan was reviewed, and the next few months will be dedicated to completing the R5 Encounter work to move its FMM status up.

Move the draft definition of the Patient Merge into the R5 FHIR spec  Brian Postlethwaite/Reinhard Egelkraut: 5-0-3

(note not a vote on if it is complete and final, but ready for wider review and exposure in the specification)

 current FMM normative status plan changing

Encounters will be the focus of the next meeting cycle or 2, prioritizing the refactoring with MovementEvent proposal and the linkage to the PC issues.

  • Brian Postlethwaite to prepare a connectathon track to test the new Encounter models/relationsips for San Antonio

The existing set of resources to target normative in R5 is unchanged:

Encounter, Endpoint, Location, Organization, Practitioner, PractitionerRole

Irma asked if the status of OrganizationRole not being very high could impact Organization going normative, Brian indicates doesn't believe so, no significant objections either way.

Discussion on the boundaries of Organization and Location was done to check the current understanding of the relationships and usages.

Describe without FHIR terms a set of 10-20 common use cases for real life situations for what you would expect to require an org/location, and then describe how these may be represented in FHIR.

Prepare a reference map of what /why things connect to Organization/Location to assist in this analysis, to review these linkages.

Friday Q2

Paul has been working with some others on Statements and Invoices etc. and expect that will see some changes coming through. PSS coming for this draft.

FHIR-22726 - Getting issue details... STATUS  Persuasive Brian Postlethwaite/Mary Kay McDaniel: 19-0-0

FHIR-24014 - Getting issue details... STATUS  This was discussed and between FM/PA we believe that the 2 models are different for valid reasons and cover different scenarios, however the Encounter data will inform the billing systems to generate claims, which might not be direct. The issue has been passed over to FM, to follow up with Flloyd (the submitter)

FHIR-14409 - Getting issue details... STATUS  persuasive with mod Brian Postlethwaite/Mary Kay McDaniel: 19-0-0

Walked through the proposed Encounter split and advised that plan to bring it to the May Connectathon for testing/decision.

As PA progresses with the design work will notify milestones to FM, and David Pyke may join in reviewing as it goes also.

Friday Q3

FHIR-25024 - Getting issue details... STATUS  Persuasive Brian Postlethwaite/Tarek Assad: 7-0-1

FHIR-24678 - Getting issue details... STATUS  The patient $match operation was reviewed and explained to provide a baseline understanding of its operation and intent. Then proposed some additional guidance as requested.


To ask an MPI to match a patient, clients use the "$match" operation, which accepts a patient resource which may be only partially complete. The data provided is interpreted as an MPI input and processed by an algorithm of some kind that uses the data to determine the most appropriate matches in the patient set. Note that different MPI matching algorithms have different required inputs. Consult with the vendor implementing the $match operation as to its specific behaviors.

The generic $match operation does not specify any particular algorithm, nor a minimum set of information that must be provided when asking for an MPI match operation to be performed, but many implementations will have a set of minimum information, which may be declared in their definition of the $match operation by specifying a profile on the resource parameter, indicating which properties are required in the search.

The patient resource submitted to the operation does not have to be complete, nor does it need to pass validation (i.e. mandatory fields don't need to be populated), but it does have to be a valid instance, as it is used as the reference data to match against.

Implementers of the $match algorithm should consider the relevance of returning inactive patients, particularly ones associated with patient merges.

E.g. If an inactive patient is "matched" and its merged target resource will be included, then inactive one may be excluded, however if a patient was just marked as inactive for other reasons, it could be included in the results.

(any specific MPI algorithm may or may not behave as in these examples)


Persuasive Brian Postlethwaite/Reinhard Egelkraut: 8-0-0

FHIR-24652 - Getting issue details... STATUS  This has been transferred to FMG for consideration on process, and asking where the FHIR registry is up to.

This issue is requesting where they can register their custom extensions, what is the status of the FHIR registry (outside standard extensions)

PA does not believe that we should be creating a standard extension for Age on Patient.

FHIR-25732 - Getting issue details... STATUS  Not Persuasive Brian Postlethwaite/Jenni Syed: 8-0-0

The middle name is supported through the iso extension (as noted in the tracker)

  • No labels

1 Comment

  1. I made a tracker for the Scheduling & Appointments diagram on the Admin Module page:  FHIR-25932 - Getting issue details... STATUS