Author Archives: tone

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.

New Beginnings, Passion, and Purpose!

Although I am not typically a big New Year’s resolution sort of guy I have, somewhat unexpectedly, ended up in a position this year of having an opportunity to start fresh with my career. I have had the very fortunate opportunity to join with Ready Computing as a Standards and Interoperability Architect. We are a small healthcare IT consultancy, who also dabbles a bit in other industries. This new opportunity will allow me to continue problem solving in the healthcare domain, which I cannot express in words how excited I am about.

So that brings me to the purpose of this blog which is primarily to explore thoughts on healthcare IT, but since this is my personal blog I cannot guarantee that will always be the case. I am also married and a father of four and an avid Toyota Land Cruiser fan. I enjoy working on my truck as it presents me with a different sort of problem solving than I get in my career, which I find helps to maintain perspective and understand different approaches to solutions, not unlike that of how learning a new programming language can help to make one more proficient at their primary programming langauge. My point here is that I may wander off into other topics.

Initially the reason I got into HIT was simple – I needed a job, a raise to support my new family and more opportunity in the technology space and found that at a company that happened to be focused in HIT. I was fortunate enough to have the opportunity through my last two employers to participate in the development and implementation of several todo: IHE profiles – and for this I am ever grateful because it has afforded me the opportunity to be a part of the last frontier of electronification of an industry.

However the real reason I remain passionate about HIT and refuse to leave it (as long as I have the option not to) is because of my own experiences with the US healthcare system with my family. In spring 2012 my wife rushed our oldest daughter (seven years old at the time) to the hospital with terrible stomach pains. She spent three hours in the closest emergency room to our home, and then was transported to a children’s hospital for further examination. I found out about all this about twelve hours after it started when my wife was finally able to contact me via my cell phone as I was in Napoleon’s Apartments in the Louvre in Paris, France. I was in Paris for IHE committee meetings. I flew home the following day, our daughter was in stable condition but could not eat solid foods. We had a team of doctors trying to figure out what was going on, and my wife and I felt more or less helpless. We were in the hospital a total of nine days and were discharged with a diagnosis of Eosinophilic Gastroenteritis, and our daughter with a feeding tube installed with a week’s supply of formula. She stayed on the formula for nine more days. She could also drink orange gatorade so we made every form of gatorade we could imagine – popsicles in all shapes and sizes, slushies, etc. We were still trying to process all this, and in typical fashion read many of the worst case scenarios – about people with this disease who could eat nothing but hypoallergenic formula for the remainder of their lives.

To make a long story short we had a comprehensive allergy test run and found her allergic to the following foods: pork, beef, lamb, peaches, beans, tree nuts, soy, navy beans, peanuts, dairy, eggs and mustard. In the end this has all turned out quite well as from that point forward we knew what it was we were dealing with. Additionally, since her reaction is gastric and not anaphylactic we can simply avoid consumption of food (versus airborne exposure) she is allergic to and she will be fine. And she has been ever since. She is now a happy nine year old, doing well in school and maintaining a healthy weight.

While our experience was fortunately not a tragic one, it still made me begin to think through the many ways things may have not turned out so well, and often do not for so many families. In our case we had been dealing with this disease since she was born but we did not know it. For some families seven years would be too long. Had her reaction been anaphylatic and not gastric we may have found ourselves in a very different situation.

So this is my story, and now the reason behind my passion for driving forward the electronification of healthcare in the US and worldwide. I very much look forward to continuing the march, continuing the innovation and continuing the betterment of healthcare!