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:
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.
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.
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.
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 :>)