Stream: cds hooks
Topic: Machine-readable extension in Card object
Mohammad Jafari (Jan 25 2020 at 01:23):
I am wondering if anyone has had a use-case where machine-readable information needs to be returned by the CDS Service to be consumed by the backend (or a rich frontend library) to make more elaborate workflow decisions. We have a use-case in which we want to potentially carry instructions in a Card to direct the client how to render a patient's information (e.g., mask some fields) or instruct the client to take one path or another from a workflow (e.g., do not include this patient in a list).
The Card data structure seems to be designed very tightly coupled to be consumed by the UI so I'm wondering if anyone has implemented a use-case like this with CDS hooks and how they modeled the Card object.
We're currently thinking of an extension to the Card object where, similar to the case of context in the request, a free-formed object can be returned and consumed by the client.
Chris Moesel (Jan 25 2020 at 02:23):
We didn't do that exact use case, but we did want to return additional structured data to the client. In our use case, the CDS was backed by CQL and we wanted to return some of the direct CQL values as well. We used extensions. The spec actually has a section indicating that this is a permissible way to handle such a thing. See: https://cds-hooks.hl7.org/1.0/#extensions
In our case, we put extensions on the discovery response and the card responses. As the spec suggests, we "precoordinated" what the extensions would be with the client via supplemental documentation.
Isaac Vetter (Jan 30 2020 at 21:03):
Hey @Mohammad Jafari , I'll second Chris' recommendation of using extensions.
Isaac Vetter (Jan 30 2020 at 21:03):
Could you also better explain your workflow? I'd question if it really makes sense to standardly model this type of really specific and (as you say) elaborate UI guidance (which is why extensions make sense). FHIR is our payload data model in CDS Hooks. "Masking a patient's info" would be done with something like Consent resource, and I'd think that excluding a patient from a list would be updating a List resource. Notably, in FHIR these wouldn't be about the UI, but rather about the logic that governs the UI.
Last updated: Apr 12 2022 at 19:14 UTC
