As we continue to evolve and refine the Clinical Encounter platform, we are looking into ways to make the interface easier to use while also exploring and different platforms upon which it can build.

Using our first entry framework of the Clinical Encounter: Writer as a guide, we started working on a 2.0 version. We first defined what fields were necessary, how the data needed to be framed, what flexibility we could allow within the data collection, and what new interactive elements we might need. We knew that we wanted a product that was easily expandable and less intensive to run and that would store data in XML format to make it easy to save, export, and reload. The XML format also works well with the whole system due to how structured it is. Within every section there are tabs that can contain from a single page of data to numerous data entries, such as medications. This creates a hierarchy, in a sense, that is easy to map.

After completing a backend framework for the data entry, we worked on making the interface user-friendly and consistent. As the Clinical Encounter platform expands, consistency is key. Independent of platform and use-case, all iterations of Clinical Encounter need to look and work the same. Thus, transforming the tablet-based case reader application into a new web-based case writer and mobile-based case reader started with the user interface and experience design.

Condensing a content-heavy tablet application into a mobile screen without sacrificing any information or functionality requires breaking up the way the content is presented. The result is more clicks, more scrolling, and more nested navigation than the tablet app in order to navigate to the same information. The focus for the mobile case reader was to effectively use all the real estate to ensure it is just as easy to navigate as the tablet version. Color coded pages and easy access to menu, back, and exit buttons prevent getting lost within the case, and collapsing / expanding panels save space and prevent information overload. The designs are still in the works as mock-ups created in Adobe Illustrator. After a lot of experimentation with colors and layouts, there’s a good foundation of assets to export for use in Unity once the mobile design is finalized.

Working backwards from the Clinical Encounter: Reader application we had in the first iteration, the Clinical Encounter: Writer was designed as a toolbox for creating the content that would be rendered. The components in the reader necessary for creating a successful case were broken down into individual pieces that can be added, removed, renamed, reordered, and customized. Some cases require more content while others require less. The design allows for the flexibility to use the pieces in whatever manner best fits the case. The structure of sections, tabs, and panels is still in place so the information added in the writer can easily be transferred to the reader, but the number of sections, the layout of tabs, and the arrangement of panels is up to the case creator. The individual components were generalized and designed in Adobe Illustrator so that everything looked consistent, but general enough to be customized. The exported graphic components were transferred into Unity and built into a usable framework using Unity Canvas so they can be used in the Unity application whenever needed.

With a strong back-end support for the data entry elements and an interface for the Clinical Encounter: Writer that is easy-to-use, we are now able to think about the different platforms that we can move into. Whether a case needs to be rendered on a mobile app, the web, or even in a VR environment, the Clinical Encounter platform should be able to support it. And we are looking forward to seeing its continued development, exploring how we can integrate this type of training into medical education classrooms across the country!