Monthly Archives: February 2014

Collaboration is Key

I attended the IHE North America Connectathon Conference this year on January 29th for the first time ever. I have been to several IHE Connectathon testing events, but never to the conference where the “suits” are. I was pleasantly surprised by the content and ensuing discussions over the course of the day. I was surprised to see that approximately 80% of the audience’s hands were raised when asked by one of the presenters who had never attended one of these events before. I think this is fantastic and represents that IHE is healthy and growing.

Keith summarizes the event nicely on his blog post here, so I will not be covering those details, but I do want to elaborate on the value of collaboration, which was a key theme that was presented and discussed at the conference. I have seen projects fail to succeed based on poor or no collaboration between the participants. Collaboration is challenging because of many different barriers including geography, language, and personality.

Sheer distance between individuals creates a natural barrier. It takes more effort to communicate when you are not face to face with your teammates. It can be done yes, but often times is not because of the extra effort required. Not being able to see body language, or pick up on other non-verbal cues makes for tough communication. However, this can be overcome through the use of video conferencing technology, chat tools, and other online collaboration tooling. When such tools are not available, careful consideration of how ideas are presented and discussed can be used to create productive outcomes on a remote conference call.

Language barriers can also impact overall collaboration efforts. Many of us come from different cultural backgrounds and speak different native languages, with different accents. While the ability to communicate is typically present from either teammate, the question comes down to the effectiveness of that communication. The effort required for someone to understand my native Georgian tongue, for example, may be somewhat challenging (probably an understatement!), or vice versa. However, I have found over the years that the more I work with individuals from other countries and backgrounds the better I am able to understand and also to be understood through the use of direct and plain language and clear thoughts. So this challenge is definitely something that practice and experience can help to overcome.

Personality is probably the single biggest challenge around collaboration. I have seen projects slow down immensly because of personality differences. To be able to stay above the personality conflicts and focus on the end goal is the sign of a team with a strong leader. Even in the absense of strong leadership to provide this guidance I encourage everyone to consider how they can help to better such a situation. Stay professional, focus on the mission at hand and keep asking if every conversation, work item, etc is somehow contributing to the successful completion of the mission of the project.

With the growing landscape of telecomutters we are seeing more and more remote collaboration. Joint work between SDOs, profiling organizations, governments programs, vendors, and patient advocates will ever more rely on remote collaboration. Yes, there are face to face meetings, but they are expensive both to the facilitator and the attendee, difficult to coordinate and often times result in low turnout. So as a participant in the healthcare IT movement in an ever-growing remote culture please think through how you as an individual can contribute to the overall success of any given project or initiative that you find yourself a part of in HIT. If we all become aware of our role(s) in the project, and study on how we can be most effective then we can transcend the above challenges and create successful outcomes!

Use Cases – A Path to Clarity

Some call them user stories, others all them use cases but all in all they serve much the same purpose: to align the business and the technical interests in a project. Use cases have many benefits when used correctly and I have seen them used effectively in several different areas of life including healthcare standards, software development, and family decisions.

Use cases are beneficial in many ways. At the very basic level they bring needed clarity to any given situation by stepping back to consider what it really is that is trying to be achieved. I’ve seen so many software developers that just jump in and start designing and coding without vetting the business requirements first. And I know this especially well because I used to be one of those developers (it is an impulse problem, and as a developer gains experience he/she should learn to control it) . Use cases act as a bridge between the business and technical interests by providing a communication path for these different groups. In earlier software design and development models the generally accepted approach was to thoroughly vet the requirements, which included use cases, by the business analyst/product team. Once everything was vetted properly, which could take months, documentation was handed off to the development team to execute on them and deliver software. The problem with this model is that there is little to no communication between those two groups. As we have learned in the past decade or so requirements often change before software is delivered to the field, and methods have been created to combat this challenge. Use cases and user stories are often used as a central discussion point in support of such methods. Use cases also bring confirmation of the goals of the project by illustrating what the software (or whatever the use case is being applied to) is supposed to achieve. It is a way to “check your answer,” similar to what one would do to validate a math problem.

I have much experience with use cases in the realm of healthcare information technology standards profiling in my work within Integrating the Healthcare Enterprise (IHE). A profile in IHE provides implementation guidance for systems in the healthcare domain. One of the base level requirements of a profile is a use case, or set of use cases. I have been involved in the development of over 15 IHE profiles over the past several years and every time I discuss a profile with someone, be they architects, engineers, product managers or VPs, I always get back to the use case at some point. It is a very effective way to center the conversation around one central goal, consistently representing the message across and between these different groups.

Use cases can often be effectively applied to planning family excursions as well. My wife and I are very fortunate to have four children, and this means that we must thoroughly think through any vacations we plan, day trips or other traveling we may choose or be required to do as a family. Although we do not use the same terms as I would in my professional career, we use the concept of use cases constantly by playing out what our trip will look like. For example, say we are planning a camping trip, we need to plan what to bring (because no one wants to be stuck in the woods without the necessary supplies to care for a two year old). So we could play it out in conversation, my wife may say to me “Honey, we will be changing a few diapers while we are in the woods so we will need to bring plenty of supplies.” And I may say “Ah of course! This is a fantastic idea and makes complete sense! Let’s be sure to pack those items so we do not end up in an undesirable situation.” This of course is a bit of a stretch because we would not necessarily need to have such an explicit conversation. At this point in our child rearing experiences we inherently know that diapers, wipes and a sealable trash bag are a must on our packing list. However the point I am making here is that all of us do this in our heads on a daily basis, whether it is for a camping trip, a grocery store run, or something else that needs to be planned. It is a natural part of our psyche, so it makes sense that this can be effectively applied in a work situation as well.

In the event that use cases are not used for a project or at least not done so properly many negative consequences may occur. The worst case scenario would be a complete mismatch between what the stakeholders are expecting and what the development team delivers. In the camping trip example this would be the failure of one spouse delivering what the other spouse is expecting. Projects that fail to keep communication lines open between stakeholders and the development team are at a very high risk of this landing in this situation. It is easier than you might think to accidently “fool” the stakeholders of what is being developed. Without consistent hands on functionality demonstrations and reviews it is hard to really get a pulse on how closely aligned the development work is aligned with the project requirements.

Use cases help to mitigate this risk by bringing together all parties on agreement and understanding of the story the software should tell, that is, the functionality that the user will interact with, the problem being solved, and how from any end user’s perspective it solves it. Not using use cases usually results in the developer writing code as directed but without at least in part understanding why. This results in a high risk of delivering a solution that is far off the original target as understood by the stakeholders. In the camping example from above this would mean a messy situation in the middle of nowhere. In which case I would at least hope there is a water source and the temperature is not too cold! In a work environment this means money lost, unhappy customers, or worse: patients not properly cared for because the system the clinician is using does not provide the appropriate functionality.

Use cases need not be complicated. If you are in doubt of how to start my suggestion is just to write a short narrative of what you want to accomplish. If you find your narrative becoming overly complex then split it apart to more manageable pieces. Most importantly remember that use cases are meant to help clarify the business requirements, improve communication and ultimately create better results in whatever situation they are applied to.