Header

About the Header component

This component was designed primarily for integration within the Clinical Decision Support Console, ensuring a seamless experience for clinicians as they move between different apps. By maintaining a consistent header across applications, we support clear wayfinding and reduced cognitive load, especially in high-stakes clinical environments.

While optimized for use within the console, the header is also flexible enough to be adapted for standalone applications where maintaining alignment with the broader ecosystem is still important.

Key Features

• Patient Context: Automatically applied if applicable in your application, helping maintain continuity of care as clinicians navigate.
• Responsiveness: Adapts to various screen sizes while maintaining clarity and usability.

Guidance

When to use the header component

• Use the header at the top of applications within the Clinical Decision Support Console to maintain a consistent experience as clinicians navigate between tools.
• Include it in standalone applications when alignment with our broader clinical ecosystem is needed.
• Leverage the header to display patient context when your application operates within a patient record workflow.

When to consider something else

• Avoid using the header in modal dialogs, overlays, or other contained experiences where a full page header would be redundant or could disrupt the flow.
• Omit the header for content that lives entirely outside the clinical environment and does not rely on patient context or benefit from maintaining ecosystem consistency.

Usability guidance

When patient context is enabled and your application is embedded within the Clinical Decision Support Console, the header will behave as a sticky element, remaining fixed at the top of the screen to ensure patient information is always accessible.

The patient context area is responsive to the sidebar state:

• When the sidebar is closed, patient context will display in the header.
• When the sidebar is open, patient context will hide from the header to avoid redundancy and maintain a clean layout.

Recommendations for actions and navigation

• Limit the number of primary actions or navigation elements in the header to 2. This helps reduce cognitive load and ensures key actions are easily identifiable in fast-paced clinical workflows.
• When more complex navigation is required, use sub-navigation patterns to organize content without overwhelming the main header.

Accessibility

The header has been designed and built with accessibility best practices already in place. This includes support for keyboard navigation, visible focus indicators, appropriate color contrast, and robust labeling to ensure it can be used effectively by all clinicians, including those relying on assistive technologies.
Developer guidance

• Do not add “tabindex” to any interactive elements placed within the header. All interactive elements should follow the natural tab order (left to right, top to bottom) to maintain predictable keyboard navigation.
• Ensure any additional components or custom elements introduced into the header continue to meet accessibility requirements, including clear labels and appropriate contrast.

By relying on the header’s built-in patterns and avoiding manual overrides of tab order, you help preserve a consistent, accessible experience across the clinical ecosystem.