Lee Surprenant

Thanks @sidharthramesh we need to beef up our documentation here. The `fhir-server-config.json` security section is more about *advertising* what security is enabled (e.g. for building the server's CapabilityStatement which is...

Once difference between what was implemented and what I sort of expected is that I thought that the values of the `_firstId` and `_lastId` parameters would be the internal, numeric...

With that said, I verified the implementation by issuing a Patient search that yeilded over 100 results (using the default page size of 10). I then proceeded to 1. copy...

I also confirmed that this warning is *not* added to the pages when the `_firstId` or `_lastId` parameters are omitted or unchanged (i.e. the actual id matches the expected id)

Talked with Robin and he was expecting us to use the primary key of the x_RESOURCES table for these entries as well. One possible downside to that is that resource...

I confirm that we're now using the internal resource ids in these urls. For example: previous: Practitioner?_page=1&_lastId=1037 self: Practitioner?_count=10&_page=2&_firstId=1041&_lastId=1077 next: Practitioner?_page=3&_firstId=1081 I also reconfirmed that the warning shows up on...

As part of this task, we should remove the current "data" section which consists of a "count" for each type of interaction within the bundle (without any indication of which...

Dag felt that it would also make the most sense to fire individual audit event messages for each interaction in the bundle (if successful) and only emit the event for...

Consider updating the e2e audit tests to invoke the fhir history endpoint and then confirm that we have a corresponding audit event in kafka for each interaction.

Looks like there are two classes from this package that have been added under fhir-term-graph. @JohnTimm do you remember why this was done?