If interpreted in an additive way (for example all records are added with timestamp in primary key), creates and updates in upstream data are functionally equivalent. To make deletes also functionally equivalent, we will add a deleted: true entry to output data. This value will be on the record in the first release in which a previously existing record no longer existed. Neither us nor downstream consumers should propagate the deleted value back to older records with the same id. If a record with the same id appears again in a later release, it will be a create upstream, and will be sent downstream from combiner without the deleted: true entry. Grouping on id, and ordering by date, consumers can interpret the record as existing for a period, then not existing for a period, and then existing again.
{
"id": "SCV1",
"entity_type": "clinical_assertion",
"release_date": "2021-01-01"
}
<record is deleted upstream at some point between releases>
{
"id": "SCV1",
"entity_type": "clinical_assertion",
"release_date": "2021-01-08",
"deleted": true
}
<record is added again upstream>
{
"id": "SCV1",
"entity_type": "clinical_assertion",
"release_date": "2021-01-15"
}
event_typefield will be removed based on #4.If interpreted in an additive way (for example all records are added with timestamp in primary key), creates and updates in upstream data are functionally equivalent. To make deletes also functionally equivalent, we will add a
deleted: trueentry to output data. This value will be on the record in the first release in which a previously existing record no longer existed. Neither us nor downstream consumers should propagate the deleted value back to older records with the sameid. If a record with the sameidappears again in a later release, it will be a create upstream, and will be sent downstream from combiner without thedeleted: trueentry. Grouping onid, and ordering by date, consumers can interpret the record as existing for a period, then not existing for a period, and then existing again.