Transferring UI Data for Logging

Hi all,

Our SMART on FHIR application needs to send UI related data back to our FHIR server. For example, if a user makes an item selection, button click, or does some type of action on the UI, we would like a way to report this information back to the FHIR server for logging. Is there a resource or other FHIR solution that would be best to relay this information?

I have looked into using:

  1. The OperationOutcome resource

    • From the FHIR spec, this resource is primarily to be used for outcomes of system operations, and not necessarily the use case above.
  2. Messaging using FHIR resources (

    • The documentation here says that a request message would be sent to a destination application where an event happens. In our use case, the “event” would be logging/data retention on info inside the message.

Are either of these solutions appropriate? Or, is there another way to accomplish this that is more FHIR compliant.

Thanks in advance!

Messaging would be an extremely heavy way to do what you’re trying to do (which is sort of outside FHIR’s expected scope). My leaning would be to leverage the Basic resource with a couple of extensions to represent a ‘UI Event’. You could use the standard code to indicate that it’s a UI event, and author and created together with an extension or two to convey the specific UI element manipulated and what happened to it (e.g. toggled on/off, clicked, text changed to “foo”) or whatever other data you need.

1 Like

Thanks Lloyd, I have started designing this based on the Basic resource.

My current design is for the UI to perform a create interaction with the FHIR server. So essentially the UI would send a POST to create a new Basic resource that would represent the action a user performed on the UI.

My concern is with the transactional integrity of this approach. The FHIR server would accept and “create” these Basic resources, but would not support any read functionality.

The spec says our FHIR server should document transaction integrity (or in this case, lack-thereof) in the capability statement. However, I wanted to verify that there is not a better approach that I am missing.

Transaction integrity relates to what you choose to store (or not), not whether you support ‘read’ or not. It’s legitimate to support create, but not read. (Though if you support update, you’ll need to either ensure that only the client that created the record can update or have some mechanism of avoiding collisions where someone has updated the record since the creator last saw it.) If you don’t store everything that is POSTed, you should include a copy of what actually was stored in the payload. Your CapabilityStatement will declare what operations you support for Basic. (Where things will get a little messy is if you use Basic for multiple purposes and support read for some of them, but not all - but that’s what the ‘documentation’ element is for :>)

1 Like

Sounds goo @lloyd thanks for the input!