* **[PLEASE sign in (attendance sheet)](https://docs.google.com/spreadsheets/d/12k0TTa6QVLUxjoonJYL6aZqEcPJ4Jnsd8eZB3B8VN2A/edit?usp=sharing)**
* [Calendar](https://calendar.google.com/calendar/embed?src=idchd9q6skpvncjc0u24s32h80%40group.calendar.google.com&ctz=America%2FChicago) / [HL7 Calendar](https://www.hl7.org/concalls/CallDetails.cfm?concall=71026)
* [Zoom call](https://us02web.zoom.us/j/89425509295?pwd=SDRxSW0zaWFQLzhmR1ltamdhQjdJQT09)
* [Zulip Chat](https://chat.fhir.org/#narrow/stream/179175-argonaut/topic/Detecting.20and.20Reporting.20Changes.20.28lastUpdated.29)

Scheduling
----------

* Wednesday, Feb 14
* Wednesday, Feb 21
* Wednesday, Feb 28
* Off for March 6 (consolidation of work)
* Off for March 13 (HIMSS)
* Wednesday, March 20
* Wednesday, March 27
* TBD

General Overview / Framing
--------------------------

* `_lastUpdated` is a search parameter
* [\_lastUpdated Standard Search Parameter](https://hl7.org/fhir/search.html#_lastUpdated)
* The `_lastUpdated` search parameter is defined as a [date](https://calendar.google.com/calendar/embed?src=idchd9q6skpvncjc0u24s32h80%40group.calendar.google.com&ctz=America%2FChicago) type parameter. Matching is performed against the element [Resource.meta.lastUpdated](https://www.hl7.org/concalls/CallDetails.cfm?concall=71026), or an implementation's internal equivalent.
* e.g., GET /Observation?patient=123&\_lastUpdated=gt2024-01-01T00:00:00.000Z
* Applications considering using this parameter should also consider defined synchronization approaches - [RESTful history](https://us02web.zoom.us/j/89425509295?pwd=SDRxSW0zaWFQLzhmR1ltamdhQjdJQT09) and [Subscriptions framework](https://hl7.org/fhir/subscriptions.html).
* Points to `Resource.meta.lastUpdated` 
* [Element Definition](https://chat.fhir.org/#narrow/stream/179175-argonaut/topic/Detecting.20and.20Reporting.20Changes.20.28lastUpdated.29)
* When the resource last changed - e.g. when the version changed.
* This element is generally omitted in instances submitted in a PUT or POST. Instead, it is populated in the response instance and when retrieving information using a GET. The server / resource manager sets this value; what a client provides is irrelevant. This is equivalent to the HTTP Last-Modified and SHOULD have the same value on a [read](https://hl7.org/fhir/http.html#read) interaction.
* [Record Versions vs Business Versions](https://hl7.org/fhir/resource.html#versions)
* There are 3 different versions of interest for a resource:

1. The Record Version: changes each time the resource changes (usually managed by a server)
2. The Business version: changes each time the content in the resources changes (managed by a human author or by business policy)
3. The FHIR Version: the version of FHIR in which the resource is represented (controlled by the author of the resource)
* Relevant context link to Bulk Data `_since` query parameter
* [Bulk Data Query Parameters](https://www.hl7.org/fhir/uv/bulkdata/export.html#query-parameters)
* Resources will be included in the response if their state has changed after the supplied time (e.g., if `Resource.meta.lastUpdated` is later than the supplied `_since` time). In the case of a Group level export, the server MAY return additional resources modified prior to the supplied time if the resources belong to the patient compartment of a patient added to the Group after the supplied time (this behavior SHOULD be clearly documented by the server). For Patient- and Group-level requests, the server MAY return resources that are referenced by the resources being returned regardless of when the referenced resources were last updated. For resources where the server does not maintain a last updated time, the server MAY include these resources in a response irrespective of the `_since` value supplied by a client.
* Relevance as trigger mechanism for a `SubscriptionTopic` resource.
* E.g., instead of triggering based on "any change to Encounters", can/should we trigger based on "when updated"?
* `Encounter.status` <-> `Encounter.meta.lastUpdated` 

Challenges / Items for Discussion
---------------------------------

### Facade Server

* Implementation Challenges
* Not necessarily storing FHIR representations of resources, so it can be a challenge to "compare versions".
* The granularity of content does not necessarily match the granularity of a FHIR resource (challenge when considering _any_ update to a resource).
* Complex cases where external changes result in changes to a patient record (e.g., a mapping table is changed and results in a different value for a resource).
* Conceptual Challenges
* Which types of changes actually matter?

### Client

* If `lastUpdated` is updated too infrequently or not supported (not updated for every resource change)
* Clients cannot rely on the element.
* Clients are forced back to polling (tradeoff: frequency vs. lag time).
* Clients must do change detection themselves.
* If `lastUpdated` is updated too frequently (updated for changes not visible in a resource)
* Clients can use the element as a starting point.
* Updates are received too frequently.
* Clients must do change detection themselves.
* In summary, without reliable `lastUpdated,` clients must:
* request data more frequently than it is changed (client and server operational costs)
* perform change detection between resource versions (pushes complexity from few servers to many clients)

Scope of Project
----------------

* Understand how `lastUpdated` can be used (consistently!) in:
* Bulk Data
* Use with the `_since` query parameter.
* Subscriptions
* What kinds of updates are good candidates for using as subscription triggers.
* RESTful Polling
* Clients understanding when a record has changed.
* Or should this be sets of elements that we care about changes in
* Propose dispositions/guidance for
* [FHIR-44106](/plugins/servlet/confluence/placeholder/macro?definition=e2ppcmE6a2V5PUZISVItNDQxMDZ9&locale=en_GB)
* [FHIR-43659](/plugins/servlet/confluence/placeholder/macro?definition=e2ppcmE6a2V5PUZISVItNDM2NTl9&locale=en_GB)

Agenda / Minutes
----------------

### March 27th

* Updates on guidance from FHIR-I
* Zulip thread [here](https://chat.fhir.org/#narrow/stream/179166-implementers/topic/Meaning.20of.20.60Resource.2Emeta.2ElastUpdated.60)
* Not settled yet but looking like update/clarification of `Meta.lastUpdated` and _add_ requirement/process to document policy.
* ❗Need to reopen CGP ticket [FHIR-43659](https://jira.hl7.org/browse/FHIR-43659) : Thursday 1:00 PM Eastern call
* Would require additional guidance for US Core.  Specifically, include minimum requirements of:
* SHALL Support the ability to populate `Meta.lastUpdated` in at least one resource type, and the ability to search via `_lastUpdated=gt{timestamp}` when `Meta.lastUpdated` is populated.
* *Note: we plan to expand this from a single resource cover more and specific resources in US Core Release 8.*
* SHOULD Support updating `Meta.lastUpdated` when any data in any US Core resource changes
* SHOULD^* Support, at a minimum, updates to `Meta.lastUpdated` based on changes in:
* Note: we intend to upgrade this SHOULD to SHALL in US Core Release 8; implementers are encouraged to begin work ASAP and share progress.*
* [US Core Laboratory Result Observation Profile](https://www.hl7.org/fhir/us/core/StructureDefinition-us-core-observation-lab.html)
* New Lab
* `Observation` created
* Reason: patient notified that a new lab result is available
* Changed status
* Updates on source for `Observation.status` 
* Note that this includes events that trigger the same status (e.g., `amended` → `amended`)
* Reason: patient notified that results have been finalized/amended/etc.
* [US Core DiagnosticReport Profile for Laboratory Results Reporting](https://www.hl7.org/fhir/us/core/StructureDefinition-us-core-diagnosticreport-lab.html)
* New Lab
* `DiagnosticReport` created
* Reason: patient notified that a new lab result is available
* Changed status
* Updates on source for `DiagnosticReport.status` 
* Note that this includes events that trigger the same status (e.g., `amended` → `amended`)
* Reason: patient notified that results have been finalized/amended/etc.
* [US Core Condition Problems and Health Concerns Profile](https://www.hl7.org/fhir/us/core/StructureDefinition-us-core-condition-problems-health-concerns.html)
* New Problem
* `Condition` created
* Reason: patient notified that new problem has been added to their problem-list
* Update to clinical status
* Updates on source for `Condition.clinicalStatus`
* Reason: patient notified that a problem has been updated in their record (e.g., `active` → `remission`, `remission` → `relapse`, etc.)
* Update to verification status
* Updates on source for `Condition.verificationStatus`
* Reason: patient notified that the record of a problem has had an administrative change (e.g., removed via `refuted` or `entered-in-error`).
* [US Core Encounter Profile](https://www.hl7.org/fhir/us/core/StructureDefinition-us-core-encounter.html)
* ❗Needs work❗
* New Encounter/Visit
* `Encounter` created
* Keying off of:
* v2: `ADT^A01` - Admit/Visit notification
* v2: `ADT^A04` - Patient registration (used in emergency admissions)
* Reason: notification to patient/caregiver/representative about a visit starting or admission
* End of patient encounter / discharge / end of visit
* Updates on source of `Encounter.status` 
* Keying off of:
* v2: `ADT^A03` - End visit notification
* Reason: notification to patient/caregiver/representative that a visit has concluded (e.g., ready for transportation, check for new prescriptions, etc.)
* Patient Transfer
* ❓Updates on source of `Encounter.location` 
* ❓Updates on source of `Encounter.hospitalization` 
* Keying off of:
* v2: `ADT^A02` - Transfer notification
* ❓Reason: notification about 'internal' appointments during hospitalization
* Guidance on Deleted resources
* Deleting resources can cause issues with clients looking for updates (i.e., orphaned records continue to exist)
* Today, a best practice recommendation is to change the resource's `status` element to `entered-in-error` and redact all PHI from the resource representation, rather than causing the resource to disappear from the API.
* Looking ahead, this is a good use case for Subscription-based notifications
* Next steps
* Check with overlap / consolidate with ECR reporting requirements.
* Design initial `SubscriptionTopic` resources for review and testing (match above).
* ❓Schedule breakout at connectathon May?
* ❓Schedule track for connectathon September or virtual connectathon?

### March 20th

* Summary of work / current proposal
* Proposed wordsmithing for US Core
* Servers **SHOULD** expose a method for clients to know if there are new or modified resources since their last polling time and advertise the mechanism in their `CapabilityStatement`.  For servers that are able to accurately populate `Meta.lastUpdated` , the preferred search is performed via the `_lastUpdated` search parameter as defined in the core FHIR specifications.  However, many servers are unable to populate this element accurately and work is in progress for an alternative search (see ) to provide similar functionality in a method suitable for those scenarios.  Also, as an alternative to search polling, work is in progress to enable Subscriptions for notifications on relevant events.
* For reference, if the optional `Meta.lastUpdated` element is populated (summary of rules from FHIR core specification):
* Any change in the resource implies a change in `Meta.lastUpdated`.
* Logically equivalent: a present and unchanged `Meta.lastUpdated` implies that there is no change in the resource.
* Note to clients that the most recent time does not necessarily reflect changes they have access to.  It is possible that a record has been changed and a client's view of the resource remains unchanged, for example if the client does not have authorization to see the changed data.
* Servers cannot populate `Meta.lastUpdated` if they cannot update it in accordance with the rules specified in the FHIR core specification.
* Supporting `Meta.lastUpdated` in a resource does not imply support for `_lastUpdated` searches.
* Supporting the `_lastUpdated` search parameter does not require use of `Meta.lastUpdated` - if a server has a way of reliably tracking changes to an instance, that mechanism can be used.
* Note: Updating the timestamp too frequently is better than missing updates (e.g., better off generating every time a resource is requested than mis-marking new data with an old timestamp)
* _Approved by general consensus_ 
* Source notes for guidance regarding `lastUpdated` and `_lastUpdated`. 
* Many servers cannot reliably populate `lastUpdated` as it is defined in the FHIR core specification.  However, the desired functionality of being able to differentiate new and modified records from existing ones is compelling.  For direct guidance on `lastUpdated`:
* Updating the timestamp too frequently is better than missing updates (e.g., better off generating every time a resource is requested than mis-marking new data with an old timestamp)
* If `Meta.lastUpdated` is present:
* Any change in the resource implies a change in `Meta.lastUpdated`.
* Logically equivalent: A present and unchanged `Meta.lastUpdated` implies that there is no change in the resource.
* Note that the inverse is NOT true: a changed `Meta.lastUpdated` does not necessarily imply that there is a change in the resource (especially that you have access to).
* Servers SHALL NOT (SHOULD NOT?) populate `Meta.lastUpdated` if they cannot maintain this guarantee.
* The element should only be present if this can be maintained.
* There may be some grey area re: whether some fields (e.g., display names?) "count", but if a server is populating `lastUpdated`, it is critical for clients to rely on that value to not miss _any_ updates. 
* Note that supporting the element does not imply support for `_lastUpdated` searches.
* Nor does the `_lastUpdated` search parameter require use of `Meta.lastUpdated` - if a server has a way of reliably tracking changes to an instance, that mechanism can be used.
* Note to clients that that the most recent time does not necessarily reflect changes they have access to.  It is possible that a record has been changed and a client's view of the resource remains unchanged.
* Tracking changes per-client is a larger request and currently out of scope, though it may be revisited in the future. 

* * First is the proposal for a new extension in the core extensions pack called `lastUnderlyingDataUpdate` .  
* Name: `lastUnderlyingDataUpdate` 
* Cardinality: `0..1` 
* Context: `Meta` 
* Type: `instant` 
* Short: When the server last updated underlying data relating to this resource
* Definition: An `instant` that identifies when data on a server has been updated that may impact this FHIR resource.
* Comments: This extension is used in situations where a server cannot track every type of change to a resource but still wants to indicate the times when data for the resource is changed.  For example, many servers generate instance details by mapping sets of codes from an internal system when an instance is requested.  In the case that the mapping table is updated, there may be millions of records changed which is not currently feasible to track on each individual instance.  This extension allows servers to track when core or significant resource elements (e.g., `status`, etc.) are changed without needing to track the entire graph of possible changes.
* Conformance Expectation: SHOULD implement either `lastUpdated` or this extension.
* _Approved by general consensus_ 
* With the new extension, we also suggest a new search parameter:
* Name: `_lastUnderlyingDataUpdate` 
* Type: `date` 
* Context: All resources
* Definition: Matching is performed against either the element `Resource.meta.lastUpdated`, the `lastUnderlyingDataUpdate` extension, or an implementation's internal equivalent.
* Conformance Expectation: SHOULD implement.
* _Approved by general consensus_ 
* Second is the recommendation to use FHIR subscriptions to detect changes.  While the intention long-term is to cover all desired use cases, an initial set of 'core' resources and changes have been selected to refine the design and provide implementation experience.  The following have been chosen for initial implementation:
* Labs
* Can be keyed off of either `Observation` ([US Core Laboratory Result Observation Profile](https://www.hl7.org/fhir/us/core/StructureDefinition-us-core-observation-lab.html)) and/or `DiagnosticReport` ([US Core DiagnosticReport Profile for Laboratory Results Reporting](https://www.hl7.org/fhir/us/core/StructureDefinition-us-core-diagnosticreport-lab.html)), as is consistent with current workflows.
* Required to trigger/update on:
* New lab result
* Change in status (e.g., move to `final`)
* V2 equivalent
* `ORU^R01` - Unsolicited Observation Message.
* Problems
* Keyed off of `Condition` ([US Core Condition Problems and Health Concerns Profile](https://www.hl7.org/fhir/us/core/StructureDefinition-us-core-condition-problems-health-concerns.html)).
* Required to trigger/update on:
* Added (new) problem
* Removed problem
* Note that many systems never remove problems, just change the status
* Update to problem: `clinicalStatus`
* Justification: 
* Update to problem: `verificationStatus`  .
* Justification: Specifically needed for items like `entered-in-error`, `refuted`, etc.
* V2 equivalent ❓
* Encounters / Visits
* Keyed off of `Encounter` ([US Core Encounter Profile](https://www.hl7.org/fhir/us/core/StructureDefinition-us-core-encounter.html))
* Required to trigger/update on:
* New Encounter/Visit: (`ADT^A01)` - Admit/Visit notification; 
* Also Register a patient (`ADT^A04`) - used for emergency admissions
* End of patient encounter / discharge / end of visit (`ADT^A03` - End visit notification).
* Patient Transfer (`ADT^A02` - Transfer notification)
* Next steps
* Check with overlap / consolidate with ECR reporting requirements.
* Design initial `SubscriptionTopic` resources for review and testing.
* ❓Schedule time at connectathon
* ❓Timeline

### February 28th

* Agenda:
* Quick look at structure documented below.
* Check in on homework assignments.
* Cooper
* Labs: any result event (i.e., prelim, final, amended) in any state and initial order is placed
* Problems: "update" event triggered by UI/API. Any time a clinician adds or updates a problem, there is an event.
* Note that there are other kinds of Conditions that have different rules.
* Encounter: a lot going on.
* Inpatient: admit, transfer, discharge
* There are "child encounters" like a radiology study or surgery that occurs during a hospital visit
* Events on a child encounter may not bubble up to parent encounter
* EHR's internal systems can track events in finer details than they report out (i.e., many use cases are not interested in child encounters, so they may not surface).
* Outpatient: check-in, sometimes check-out
* Could take up to 3 days to know the encounter is completed.
* There _are_ several different "final" statuses (e.g., patient left, practitioner sign-off, etc.), so it is not a single event.
* Note that this is about when the internal system triggers, then there are additional rules about when to actually notify others (i.e., providers).
* Chart-correction workflow
* E.g., moving something attributed to the wrong patient, etc..
* They are not triggers specific to labs/problems/encounters, but can trigger on them.
* There are two distinct phases here - one when the EHR knows that this happens, and a separate part for notifying others.
* Note that internally, there will be an `entered-in-error` and a new one, but they likely do not surface to the API (e.g., caller will receive 404).  Cooper will verify this behavior.
* (bonus) ECR Triggers
* Trigger based on coarse events and then use the tables to filter.
* Scheduled job each night
* Active work and not the expert.
* (chat) we do have support for real time eCR, but CDC complained because we sent too many reports, since some of the triggers can catch things that happen on a recurring basis through the day for inpatient.
* Fran
* Labs: trigger on any incoming result, can look at the status (e.g., filter out entered-in-error), can possibly look at the interpretation codes as well to trigger provider events
* Status, result name, and out-of-range result (e.g., abnormally high)
* Problems: added or updated.
* Can evaluate additional info like status, filters for specific problems, severity.
* Encounters:
* Main trigger is admission/discharge.  Also "update" to encounter.
* (bonus) ECR Triggers
* Different team that uses the FHIR API
* Uses the ecrNow app.
* Emma
* For Encounters: "finalized" (sign-off, ready for billing) can trigger notifications and make data ready for exchange
* For labs: "finalized" (i.e. results have been reviewed, provider considers it ready for release) can trigger notifications
* These are rules about when data will _appear on the API in the first place_
* After this point when data appear on the API, they can still change
* There is audit tracking internally for changes; internal tools can "watch" the audit tables to trigger
* These can be configured by organizational policy.
* (bonus) ECR Triggers
* CDA-based right now.
* CDA-to-direct based on lists of codes from CDC.
* Co-mingled with HAI reports.
* A lot of conversations around it.
* Jason
* Labs: a very complex tree that determines notifications
* Where from, ambulatory/acute, type of provider, and user preferences (i.e., if they want a notification)
* Observations and Diagnostic Reports (Labs, ITS?, microbio, blood bank etc)
* Encounters:
* Similar to Cooper
* Discharge is very case-specific.  Some are EoD, some are when patient leaves, some are on sign-off, etc..
* Some are tied to billing cycles.
* Triggers for ECR
* Case that could go to CDC, based on a lot of criteria.
* Maintain a diverse trigger table for that already 
* tables are maintained internally (based on ECR trigger standards when updates are published) and triggering themselves.
* Notifications triggered 72 Hours after visit ends.
* Q: What about jurisdictional "immediate" needs 
* Haven't implemented yet (on 2024 roadmap).
* Problems:
* eCR piece to trigger
* Steve
* Labs:
* Events for create/update and specifically on status → closed
* Problems:
* Create/update/delete, split into two flavors: historical and active diagnosis (all Conditions)
* Encounters:
* Check-in, sign-off, billing review, status change.
* (bonus) eCR
* Cron-based periodic check forwarded to the eCRNow app.
* Describe events for our top cases.
* Describe the actual triggering events in plain language.
* Describe detailed FHIR-resource changes.
* Show equivalent examples in event system (v2)
* Proposed structure of topics
* Josh: Can I make a proposal for starting point?
* Topic = "EHR thinks something may have changed in a 'Result' (bind this word to some specific enumerated list of US Core Profiles / USCDI Classes)"
* What are the triggers?
* MUST trigger when
* `DiagnosticReport.status or Observation.status` changes (including 1st appearance (resource created) or disappearance (resource deleted))
* Anything else, from discussion?
* SHOULD trigger when: ... ?
* MAY fail to trigger on other changes (i.e., false negatives are possible and anticipated)
* Clarify what is the scope - it is not "fail to trigger" it is an out-of-scope change.
* SHOULD NOT trigger if nothing has changed (i.e., false positives are possible but discouraged)
* What are the filters?
* MUST support
* "patient={}" filter
* "category={}" filter (don't need this if our Topic is scoped down to lab results already)
* anything else?
* SHOULD
* (patient care teams or group memberships?)
* What payload types?
* SHALL support "id-only" ?
* MAY support others
* What are relevant resources to _possibly_ include in notifications?
* Mixed - some want the 'least' and some want the 'most' (personal guess: around which side has to do the extra work =).
* How are changes explained to clients?
* Servers MAY provide detailed "change labels" (Codings their own taxonomy & docs)
* {"event": {"system": "https://ehr.example.org", "code": "user-action-17"} }
* Servers SHOULD provide a high-level v2 label when a v2 event caused the trigger
* We could publish some convention 
* Clients SHALL NOT rely on the presence of a label
* i.e., they can fall back to diffs 
* Zulip poll
* Future plans
* Continue discussion on topic resolution (e.g., Observations and/or DiagnosticReports)?
* Schedule next call?
* Josh: Yes please (we seem to have more discussion to drive specifics)
* Schedule Connectathon (mini or in Dallas)
* Are there additional security considerations
* Tie-in with eCR
* Finish tracker guidance
* Will have out-of-band discussion and review in time for US Core next pass
* Laboratory Values/Results: top-level event is "_Something has happened in a result about patient 123_".
* Details
* New lab result.
* `DiagnosticReport` created.
* `Observation` created.
* Lab result has an updated/corrected value.
* `DiagnosticReport.status` updated.
* `DiagnosticReport.result` added/deleted/updated.
* `Observation.status` updated.
* `Observation.value` added/deleted/updated.
* `Observation.component` added/deleted/updated.
* ❓`Observation.note` added/deleted/updated.
* ❓`Observation.interpretation` added/deleted/updated.
* Background Info / Related Context
* Resource anchoring
* `DiagnosticReport` 
* [https://hl7.org/fhir/us/core/STU6.1/StructureDefinition-us-core-diagnosticreport-lab.html](https://hl7.org/fhir/us/core/STU6.1/StructureDefinition-us-core-diagnosticreport-lab.html)
* Must Supports: `status`, `category`, `code`, `subject`, `effective`, `issued`, `performer`, `result`.
* SHALL Search Parameters: `patient`, `patient` + `category`, `patient` + `code`, `patient` + `category` + `date`.
* SHOULD Search Parameters: `patient` + `status`, `patient` + `code` + `date`.
* `Observation` 
* [https://hl7.org/fhir/us/core/STU6.1/StructureDefinition-us-core-observation-lab.html](https://hl7.org/fhir/us/core/STU6.1/StructureDefinition-us-core-observation-lab.html)
* Must Supports: `status`, `category`, `code`, `subject`, `effective`, `value`, `dataAbsentReason`, `specimen`.
* SHALL Search Parameters: `patient` + `category`, `patient` + `code`, `patient` + `category` + `date`.
* SHOULD Search Parameters: `patient` + `category` + `status`, `patient` + `code` + `date`.
* HL7 v2 Messages
* `ORU^R01` - Unsolicited Observation Message.
* [https://build.fhir.org/ig/HL7/v2-to-fhir/ConceptMap-message-oru-r01-to-bundle.html](https://build.fhir.org/ig/HL7/v2-to-fhir/ConceptMap-message-oru-r01-to-bundle.html)
* `ORU^W01` - Unsolicited Waveform
* Self-Discovered Epic-Related
* Ancillary Systems - Outgoing Results and Orders ([https://open.epic.com/Ancillary/Results](https://open.epic.com/Ancillary/Results))
* Problems: top-level event is "Something has happened in a Condition for patient 123"
* Details
* New condition
* `Condition` resource created.
* Condition has an updated/corrected value.
* `Condition.clinicalStatus` updated.
* `Condition.verificationStatus` updated.
* `❓Condition.abatement` added / updated.
* `❓Condition.stage` added / updated.
* Background Info / Related Context
* Resource Anchoring
* `Condition` 
* [https://hl7.org/fhir/us/core/STU6.1/StructureDefinition-us-core-condition-problems-health-concerns.html](https://hl7.org/fhir/us/core/STU6.1/StructureDefinition-us-core-condition-problems-health-concerns.html)
* Must Supports: `assertedDate`, `clinicalStatus`, `verificationStatus`, `category`, `code`, `subject`, `onset`, `abatement`, `recordedDate`.
* SHALL Search Parameters: `patient`, `patient` + `category`.
* SHOULD Search Parameters: `patient` + `clinical-status`, `patient` + `category` + `clinical-status`, `patient` + `category` + `encounter`, `patient` + `code`, `patient` + `onset-date`, `patient` + `asserted-date`, `patient` + `recorded-date`, `patient` + `abatement-date`.
* Self-Discovered Epic-Related
* Clinical Information - Outgoing Problem List ([https://open.epic.com/Clinical/HL7v2](https://open.epic.com/Clinical/HL7v2))
* Encounters / Visits: top-level event is "Something has happened in an Encounter about patient 123".
* Details
* New encounter
* `Encounter` resource created.
* Encounter has an updated/corrected value.
* `Encounter.status` updated.
* Background Info / Related Context
* Resource Anchoring
* `Encounter` 
* [https://hl7.org/fhir/us/core/STU6.1/StructureDefinition-us-core-encounter.html](https://hl7.org/fhir/us/core/STU6.1/StructureDefinition-us-core-encounter.html)
* Must Supports: `identifier`, `status`, `class`, `type`, `subject`, `participant`, `period`, `reasonCode`, `reasonReference`, `hospitalization`, `location`, `serviceProvider`.
* SHALL Search Parameters: `id` / `_id`, `patient`, `date` + `patient`.
* SHOULD Search Parameters: `identifier`, `class` + `patient`, `patient` + `type`, `patient` + `location`, `patient` + `status`, `patient` + `discharge-disposition`.
* HL7 v2 Messages
* `ADT^A01` - Admit/Visit notification.
* [https://build.fhir.org/ig/HL7/v2-to-fhir/ConceptMap-message-adt-a01-to-bundle.html](https://build.fhir.org/ig/HL7/v2-to-fhir/ConceptMap-message-adt-a01-to-bundle.html)
* `ADT^A02` - Transfer a patient.
* [https://build.fhir.org/ig/HL7/v2-to-fhir/ConceptMap-message-adt-a02-to-bundle.html](https://build.fhir.org/ig/HL7/v2-to-fhir/ConceptMap-message-adt-a02-to-bundle.html)
* `ADT^A03` - End visit notification.
* `ADT^A05` - Pre-admit a patient.
* [https://build.fhir.org/ig/HL7/v2-to-fhir/ConceptMap-message-adt-a05-to-bundle.html](https://build.fhir.org/ig/HL7/v2-to-fhir/ConceptMap-message-adt-a05-to-bundle.html)

### February 21st

* General consensus from the 14th is that `meta.lastUpdated` is not where vendors want to focus their energy.  Propose guidance:
* Updating too frequently is better than missing updates (e.g., better of generating every time a resource is requested than mis-marking new data with an old timestamp)
* Any (\*significant) change in the resource implies a change in Meta.lastUpdated _(if present)_
* Logically equivalent: No change in Meta.lastUpdated _(if present)_ implies no change in the resource
* Servers SHALL NOT (SHOULD NOT?) populate Meta.lastUpdated if they cannot maintain this guarantee  
* The element should only be present if this can be maintained.
* There may be some grey area re: whether some fields (e.g., display names?) "count"
* Does not imply support for `_lastUpdated` searches.
* Does not improve usefulness in Bulk Data - that can be taken up in the Bulk projects.
* Is not a viable element to use for subscription triggers - will be taken up in this series.
* Inform clients that the most recent time does not necessarily reflect changes they have access to. 
* Note that this is not ideal behavior and will be revisited in the future.
* Possibly define a new extension for something like `mostRecentTrackedEvent` 
* Possibly define a new search parameter for it 
* e.g., `Observation?_knownUpdated=ge20240101`  
* Move onwards to subscriptions.
* Reduced scope for "first bite of the apple".
* Short list
* Laboratory Values/Results
* Problems
* Encounters / Visits
* Based on short list:
* Identify resource/s used for anchoring.
* Identify elements being modified.
* Identify existing events.
* Ensure definition aligns: event + resource change.
* Identify time window / batching "reasonable expectations"
* Also:
* Define general "topic" structure.
* Assignment?  What would your docs look like for `knownUpdated` for those categories?
* Notes
* Pascal: Has there been any discussion about any distinction between _new_ resources and _updated_ resources.
* Gino: hasn't been discussed here - but there is a `_lastn` operation already
* Josh: Let's note what is easy:
* `create` operations are easy to track
* `status` changes/transitions are easy to track
* maybe others?
* Emma: Can we add Medications and AllergyIntolerances?
* Josh: Short list is to discuss, we will add more once we have the first ones done.
* Example: Laboratory Values/Results
* Resource: Observation
* "Real Life Events and What They Can Change" – aka "Landmark events in the lifecycle of a result"
* **External Lab Interface Message Arrives**
→ Can create a new Observation
→ Can change Observation elements {effective time, status, value, ...}
* Any more specific messages with more predictable outcomes? On call, no, typically an ORU^R01 overwrites everything previously received.
* Josh: From client perspective, an overwrite is not a bad thing to know.  It _probably_ has something new, and even if it does not, it should not be such high frequency that it is problematic.
* **Internal Lab API Updates
**→ Can create a new Observation
→ Can change Observation elements {effective time, status, value, ...}
* **Manual Data Entry **  → Can create a new Observation→ Can change {effective time, status, value, ...}
* Any more constrained flavors of edits?
* Order is signed
* Result is filed
* Addendum
* Changes:
* New value (i.e., created)
* Status change (note case: entered in error)
* New Note?
* Change in value?
* Casey: Order assigned / performed / addendum
* Casey: Noteworthy events that changes the resource.
* Jason: We don't have a lot of granularity on types of changes - many systems are pre-FHIR.
* Josh: we are categorizing changes, so what granularity to do you have?  E.g., manual user change, etc.
* Jason: worried that we cannot match changes at that level
* Jason: Jumping back - what kinds of alerts are sent to providers today?
* Don't have the info today, but SHALL have for next week.
* Casey: collecting information for a search parameter vs. a notification is slightly different.  Want to differentiate between things that are significant to the resource.
* Brett: question for Pascal: is this meeting your needs?
* Pascal: yes - we want what is feasible.
* Homework Assignments:
* Vendors to gather information about what changes are sent to providers in their systems today.
* Labs is great, if more is available, please provide anyway and we can filter for the call.
* Jason, Casey, 

### February 14th

* Introductions
* All participants
* Many requests for this to be implemented, general fear/uncertainty/doubt from server implementers
* Balance client desires with server practicality
* Context / Framing (5 mins)
* Show and/or tell from participants - what do you support and how does it work. (~5 mins per volunteer)
* Understand current state of support in your product
* Understand a _little_ of _why_ it is how/where it is.
* Please note any future plans you are comfortable sharing.
* Cooper:
* Looking at strict definitions and implementations
* Example of changing the mapping of a CVX code for an immunization - e.g., fixing a typo in a code mapping, or adding an extra concept to Immunization.vaccineCode. This will change the FHIR resource over the wire; does it constitute an update to Resource.meta.lastUpdated (for _all_ immunizations of that type in the system, which could be many thousands or more)?
* Expectations vs. risk management and what is "good enough"
* Not all stored information goes into a FHIR Resource, so changes to internal records may or may not result in changes to resources (false positives and false negatives)
* Excited to narrow expectations to fit what is practical
* Looking at `Encounter.status` - possible ways it could be detected
* Can monitor element for changes (change detection) – mostly relevant for "pure FHIR" servers, just do a diff on the two versions
* Can use events (e.g., v2 ADT)
* Can look at audits – e.g. Patient record might have thousands of elements. We internally maintain audit tables that track changes on fields that are useful to track.
* Jessica:
* Have it updated on per-resource basis (currently on 4, working on another 6)
* Resource contents are built from different services, so it can be difficult to get changes synchronized (e.g., parts of an Observation in conflict for last update timestamp)
* Fairly large uplift for each resource
* Some ambiguity around what `lastUpdated` actually means.  E.g., last time any change, last clinically relevant change, etc.
* Cooper: +1 on resources that come from multiple sources.
* Like some US Core Observations come from an a internal table of vitals data, and others come from a lab system, and these underlying systems have different capabilities. Makes it hard to present a uniform abstraction for clients.
* Fran:
* Regarding bulk specifically - they are currently post-filtering resources in order to add this information as necessary.
* Josh H:
* Bulk is currently the only place time-based queries are supported, via "\_since" param. Resource.meta.lastUpdated is not included in resource content. Getting updated values as they generate resources
* Whenever they look at general implementation, they have had the same questions - e.g., is change 'x' relevant?
* Data is stored in non-FHIR format, so they have the same questions as other implementers.
* Cooper:
* Business rules (e.g., decorating a resource with a calculated element in some circumstances, or truncating a name for patient-facing display) can  impact data as well. Would an update to the business rules impact lastUpdated? Or if an update happens but it is not visible to someone, is that wasted processing, should it go through, etc.?
* Example: a patient-facing display name for nurses changes from First Initial + Last Name to full name.
* Josh M:
* Are there examples of things that are already being well-tracked/audited?  Could this be a "low-hanging fruit" to standardize with at first
* Cooper:
* Patient demographics - audits and/or events.
* Labs often have a chunk of new data that arrive with an event, and these chunks might be logged into an audit table
* A lot of dark and complicated corners here
* Amy:
* Adding a query parameter that is not being honored.
* Providers can specify if it should be supported or not.
* Clients want to be good citizens regarding servers.
* Want to provide a better experience to patients/persons
* Cooper:
* What kinds of changes are you actually interested in?
* Everything they can group is grouped (e.g., categorizing Immunizations)
* Have issues when small things change - e.g., if a change in the `meta` occurs, the patient looks and sees nothing new.
* Changes in the _order_ of elements in the JSON are particularly frustrating.
* Would be really nice to specify which changes we are interested in
* Cooper:
* Was hoping the categorization was not happening, since that means that updates to things like mapping tables are much more relevant.
* Josh M:
* There are some obvious cases that matter (e.g., typo in CVX code changes meaning) and some that obviously don't (e.g., whitespace typo in display).
* Cooper:
* Issue is updating MM of records because a mapping has changed.
* Cooper:
* Spoiler: we define either sets of elements or sets of events that we care about.
* E.g., elements
* Specifically monitor things like `Encounter.status` for changes.
* E.g., events
* Gino: example: when result finalized happens, we know we need to update resources x, y, and z.  That will trigger a new `lastUpdated` .
* Does a server use these types of things for internal tracking (`lastUpdated`) or for external use (e.g., subscriptions).
* Emma:
* For events, how does scoping work?  E.g., result vs. condition vs. etc.
* Gino:
* If that is the route, it would be done over time - e.g., setup a "first bite of the apple" for the most critical updates and go from there.
* Cooper:
* Want to be aware of interactions between indexes and these properties
* [https://www.ihe.net/uploadedFiles/Documents/PCC/IHE\_PCC\_Suppl\_RECON.pdf](https://www.ihe.net/uploadedFiles/Documents/PCC/IHE_PCC_Suppl_RECON.pdf) - X.4.2 Considerations for Reconciliation
* Overview of challenges

This table captures the rough draft outline for the \_lastUpdated **weekly** calls planned for Wednesday's 2-3 PM Eastern starting 2/14.

1

Feb 14

Kick-off - Show N' Tell

**Review current state**

How have you implemented \_lastUpdated? How did you decide to not implement?

FHIR Core documentation [\_lastUpdated](https://www.hl7.org/fhir/search.html#_lastUpdated)

* The standard search parameter `_lastUpdated` is used to match resources based on when the most recent change has been made.

Bulk documentation on [\_since](https://build.fhir.org/ig/HL7/bulk-data/OperationDefinition-export.html#bulkdataexport)

* For resources where the server does not maintain a last updated time, the server MAY include these resources in a response irrespective of the \_since value supplied by a client

Challenges:

* New concept mappings on Resource (changing or new mapping)
* Updated text description on codeableConcept linked to a resource. 

2

Feb 21

Develop/Discuss proposals to resolve - Add \_lastUpdated search parameter for all resources ([FHIR-43659](https://jira.hl7.org/browse/FHIR-43659))

3

Feb 28