COSIGN

Cosign was another product of an interview process — I thought this project would be a breeze, but boy was I wrong. The brief was to design a patient chart portal for a family clinic… and that’s about the only simple thing about it. Extra requirements included things such as the following:

• Accommodate two views and levels of access, but keep the chart the same (physician and PA)
• Decide how the relevant data to today’s visit becomes visible with a quick scan
  • Without hiding the rest of the chart data
• Decide how the PA views restricted content, and how they request access
  • Access is limited time and expires. Design how this works and shows up visually on both ends
• Build a notes system so the PA can draft notes and the physician can co-sign them (hence the name)
  • Notes must have a lifecycle (Draft, Submitted, and Co-Signed or Returned with Comments)
• And finally… an Audit view only the physician can see

Regardless, I was tested and forced to learn and adapt, which is always good. This one came together in roughly 5 days.

Here is the main view, the patient chart for Jordan Reyes, who I hope is fictional…

Anyways, I had never designed anything like this before. Beyond that, I didn’t just have to make it look pretty, I had to make it function just as good. I started out by wasting a full day trying to just design a patient chart from scratch, using my web design skills and intuition, trying to make things look cool, etc. Nothing worked. I kept ending up with ugly charts that looked like they came from a 1980’s medicine textbook.

So I decided to go a different route. I was going to design this thing brick by brick. Make the small parts look pretty and work well, and then build the whole thing piece by piece, slot things together and see how they look and feel — and that was the key for building this project.

I started with the data cards, then I designed the rows and the little visual effects, and then I just kept piling on things little by little until eventually I had really good “pieces” to put together.

I tried not to look at too many patient chart references because I thought it would be fun to try and do this from an outsider’s perspective. I actually leaned heavily on a weird mixture of references and styles: One being Google’s general styling, and then I found this art auction house who had a really cool art and marketing style that I pulled a lot of the type and font choices from.

I was left with this type-forward, bento style grid that simply just worked well. Sometimes you have to shift energy from making the coolest looking thing that functions okay, and reverse that way of thinking. Here we have something that works great and looks to me… pretty good. If I was a physician, this is the patient chart I’d want to use.

This is a quick demo of how I implemented this “two view / two levels of access” solution. I made strong use of these “footers” on the row(s) because they didn’t technically change the chart, but they added the context and functionality I needed.

The other things to consider were the audit function, the restricted access, and the confidential note. You will see how they function next…

Now some of the fun stuff… the aforementioned restricted access. I decided the PA could see that there was a restricted result because maybe he would want to request it to give proper care. As for the confidential note, I decided that was only for the physician to see.

These were sort of easy to decide and design conceptually, PA can’t see, requests access, physician grants timed access that they both can see… whatever. But let me tell you, once that first layer is built and you run through it, you notice a new issue every time… most of the time they are small things, but that’s what drives you nuts.

Okay the main function is there, but how should the dropdown look? It should have a timestamp, shouldn’t it? What gets put into the pill/button shape? What doesn’t? How do we notify? Etc.

That theme carried on into multiple areas of the project, partially because of my OCD, partially because design is a granular thing. In the end we landed on a smooth interaction.

Now for the notes and audit duo… thankfully these were the last things I built, so I had already built up an almost fully designed system for them to slot into. I decided to make them both live on the bottom corners, which I feel is a good home for them. They wouldn’t look good in the patient info header, and they don’t belong in the main header (designed to be a part of a larger, assumed EHR) because they are patient specific.

The notes flow was pretty simple to conceptualize, as well as the audit. Notes gets a few handoffs and a lifecycle, along with a physician only confidential note — and then the audit tab is… well… just an audit tab with a few more features.

As I mentioned before, these are seemingly simple, but even when they were 90% done, I spent more time fine tuning the last 10% than I did building the initial 90%… story of my life.