Lee Surprenant

Some good related discussion of late: * https://chat.fhir.org/#narrow/stream/179166-implementers/topic/Narrative.2C.20usefullness.20of * https://chat.fhir.org/#narrow/stream/179166-implementers/topic/Narrative.20generators

individual updates are pointed in the corresponding stories, testing is pointed at the epic level

To just omit it from the response is pretty simple. To prevent reading it from the db, it might take some work, but is probably worth looking into (for performance).

Thanks for the bug report. This "conditional reference" feature is only supported for transaction bundles. In the spec, its described under https://www.hl7.org/fhir/http.html#trules and its includes text like this: > Because...

Lets use this ticket for changing our current 500 server error to a 400 Bad Request for this scenario. Feel free to open a separate feature request for going beyond...

I'll also note that the documented `mvn liberty:dev -f parent -pl module2 -am` syntax didn't work for me at all. That one produces an error like this: ``` [ERROR] [ERROR]...

I saw #1569 is marked as completed now... are we expecting that to also address the issue presented here?

> if the idea was to provide failsafe configuration in module2 with a test packaged in module1 then I think this could be a gotcha, since I believe dev mode...

I confirmed that, with fhir-smart installed in userlib, creating or updating a Binary resource that has a valued Binary.securityContext element now results in an 403 with an operation outcome like...

Additionally, I confirmed that by setting `validateBinarySecurityContext` in fhir-server-config.json this error goes away and becomes just a warning in the server logs. Personally I think the message detail could be...