FHIR Chat · docs / Issue #34 Add CDS Service logo/icon? · cds hooks

Stream: cds hooks

Topic: docs / Issue #34 Add CDS Service logo/icon?

Github Notifications (May 04 2017 at 21:09):

kpshek milestoned Issue #34

Github Notifications (May 04 2017 at 21:09):

kpshek opened Issue #34

It has become apparent that CDS Service vendors/developers want to include a logo or image of some sort in their cards. Today, these developers are doing this with an image tag in the Markdown of the card details. This is fraught with UX issues as the CDS Service developer doesn't know how big to make the image since how it is rendered varies by EHR.

Perhaps we should add first-class support for a logo/icon either in the card itself (via a first-class attribute) or in the CDS service definition in the Discovery endpoint.

We should be prescriptive on the size and format of the logo/icon. Additionally, we should be clear if this is a logo or an icon (there is a difference from a UX perspective).

I'd like to explore first if we can put this in the Discovery endpoint for each service rather than an attribute on the card.

Github Notifications (May 04 2017 at 21:12):

jmandel commented on Issue #34

I think an explicit field for log, with prescriptions on size, would be lovely.

I'd be wary of making the Discovery endpoint the only place where this info lives, because I want to enable the possibility of aggregator services that might present a unified discovery endpoint for services in different groups or from different publishers. (We could say: this happens with separate discover endpoints for each group/publisher, but there are advantages to having this happen in one place, unless we want to design a meta-discovery protocol :p)

If we need an attribute in the cards, I'd rather avoid the complexity of defaulting-to-a-discovery-supplied-logo.

Isaac Vetter (May 04 2017 at 21:14):

Perhaps we should add first-class support for a logo/icon either in the card itself (via a first-class attribute) or in the CDS service definition in the Discovery endpoint.
We should be prescriptive on the size and format of the logo/icon. Additionally, we should be clear if this is a logo or an icon (there is a difference from a UX perspective).

Github Notifications (May 05 2017 at 19:26):

kpshek commented on Issue #34

I've attempted to lay out the various options and their impact/considerations:

Defining in Discovery

• Allows the EHR to display the image in any tool used by users configuring the CDS Services
• Allows the EHR to cache images upfront / early (no need for a just-in-time cache)
• Requires EHRs to cache images and apply them to each card
• Hampers aggregation services if they intended to display a unique image based upon the underlying service they wrapped/aggregated.
• Should the image be defined for the discovery endpoint (for all services) or per service? Flexibility at the cost of added complexity.

Defining in each card

• Allows the all services (including aggregation services) to define whatever image they want (perhaps they want to provide a tailored image for each card)
• Removes the burden of the EHR from storing the images (if they don't want to cache them)
• EHR has no image to display in a tool used by users configuring CDS Services
• EHRs must implement a just-in-time / progressive cache (if they are caching images at all)

Defined in both Discovery and each card

• Image defined in card would override image defined in Discovery
• Most complex of the three options
• Addresses all of just defining in Discovery
• Addresses of EHR not having an image for a Discovery tool

---

I'm going to solicit feedback from our CDS Service participants at the Connectathon this weekend. I don't know of anyone who represents an aggregation CDS Service. I wonder how many of these are/will exist.

After writing up all of these options and thinking through each, I'm now leaning towards what I believe to be the most simple approach -- defining this in each card.

Github Notifications (May 06 2017 at 17:46):

peremarshall commented on Issue #34

For consistency, I think it belongs in the JSON for each card. That's where all the rest of the content is sourced. As for the downsides of that approach...

• I don't think the people doing the configuration of the services need a logo.
• All of the other content on the card can't be cached upfront, including the "source" attribution which is most closely related to this logo asset.

I think having it in both would lead to confusion.

Last updated: Apr 12 2022 at 19:14 UTC