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
- Irma Jongeneel / Brian Postlethwaite report to steering division that the V3 Person ballot was re-affirmed
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
- Irma Jongeneel - Check with Hans on this too
Brian gave an overview of the results of the Connectathon
- Brian Postlethwaite to update progress of some of the projects at the next WGM
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 ASC
Currently using an extension - period, start, end and servicetype.
- Brian Postlethwaite Gabriela Espinosa , Jenni Syed will assist in drafting some content as noted in FHIR-22485 on multiple service types and encounters
FHIR-23764 - Encounter v2 mappings
Update the mappings as provided
Brian Postlethwaite/Michael Donnelly: 6-0-7
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)
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
- Brian Postlethwaite to update the http://build.fhir.org/valueset-encounter-status.html as a tracker to indicate that the patient isn't needed to be present, but that the encounter is active
This was discussed and noted for some clarifications, will follow up with this tomorrow
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-25725 - question answered on possible approaches on how to handle Practitioner Master record management.
- FHIR-22764Getting 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)
Patient Merge Review, walked though the definition, down to Post Merge Operations.
Consider when putting into the spec break into multiple pages
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".
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-22485Getting 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
Complete the Mapping of the split between Movement and Encounter
|Movement.encounter||M (if it’s a resource)|
Review the PA trackers
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.
- 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.
- Irma Jongeneel to add this IG work to the 3 year work plan
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
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 performer.actor(Organization) this seems to be redundant, this needs further review.
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.
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)
- Brian Postlethwaite to move the draft definition of the Patient
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.
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-24014Getting 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)
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.
- FHIR-24678Getting 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
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.
The middle name is supported through the iso extension (as noted in the tracker)