Category Archives: HIT

A Changing Landscape in Healthcare IT Software

For many of the years that I have been involved in Healthcare IT I have had the good fortune of working for EHR software vendor organizations. It was very exciting to develop bleeding edge technology supporting interoperability standards, and see the benefits realized in real-world use. We broke through many barriers in the healthcare field, although we certainly did not reach the ceiling. However, as in many market sectors, times change and with such change innovation and new ideas take a front row to what has become solid and stable. EHR solutions are mostly now considered to be the foundation for the industry, providing a solid framework upon which more complete solutions are being delivered in interest of bettering patient health outcomes.

In the past few years so many niche applications have arisen to address very specific problem areas. This is in part due to a natural industry shift requiring fresh perspectives on older problems. This is in other part (in the US) due to government incentive programs driving forward a need to improve patient health outcomes such as ACO, PCMH, and MACRA (QPP).

As technology solutions mature, they naturally become more difficult to adapt to changing conditions. The more components a solution has the more effort it requires to update those components while retaining backwards compatibility and the harder it is to craft deployment packages that do not interrupt existing live productions in significant negative ways. Managing a technology solution over the long term definitely comes with its challenges as well as its benefits. New comers into the market are able to quickly adapt to changing requirements that exist, freely building innovative and creative solutions that are not so dependent on existing components and choices made earlier in development by the more established solutions. These newer solutions are able to be plugged into the older solutions to address gaps in functionality that might not otherwise be addressed. This is the nature of software engineering and development as it has progressed since its inception in the middle of the last century.

The other driver of new technology solutions in healthcare is that of federal incentive programs that are placing a strong emphasis on improving patient health outcomes. Research is beginning to show that improving health outcomes for patients across a population is more than just using a certified EHR system or following the medical practice guidelines from the appropriate medical college. Rather, it involves a much more complete and holistic approach of medical practice that looks not only at the clinical facts of a patient, but engages the patient in a relational aspect, understanding the impact that social determinants have on that particular patient. Understanding the mental health of the patient is also quite important, often times being very difficult to properly diagnose and treat for a number of good reasons. To address these sorts of issues doctors must find ways to meet patients where they are today, using tools and approaches that are natural to patients. This means making use of apps developed against popular platforms that interact with social media, are intuitive to use, integrate with existing systems of all kinds to provide seamless access and management of the patients health data and care from both the provider and patient perspectives.

This IS the new face of healthcare, this combination of the foundational EHR vendors’ existing solutions, in conjunction with newer solutions that focus in on very specific problems that need solving. And really, this is not much different than how technology has always been managed. As solutions age, various components of those solutions are wrapped with interfaces that abstract them away, providing a way for the newer, more efficient, and many times more socially accepted solutions to interact with the older technologies. In the same thought, wisdom is valued more than mere intelligence or trend. That wisdom is grounded in the foundational participants in healthcare IT that continue to drive forward standards-based development efforts, focusing on the shared goal between patients, providers, and payers of improved patient health outcomes for all.

Workflows in Healthcare Standards

Workflows are a big challenge in healthcare interoperability. Workflows exist everywhere, and in all forms. There are complex workflows, simple and straight-forward workflows, confusing workflows, cross-domain workflows, single-domain workflows, static workflows, dynamic workflows, defined workflows, and undefined workflows. Workflows are at the core of everything that happens in healthcare. We, as an industry are just beginning to understand how to go about defining workflows from an electronic perspective. For years IHE and other standards development organizations have been creating implementation guidance components that ultimately make up these larger workflows. These workflows derive from the various medical colleges that spend much time studying clinical workflows and producing guidance on implementation of these workflows in healthcare practices.

This blog post will not go into detail on all the different types and aspects of workflows mentioned above, however, it will introduce a couple of approaches that IHE has been using: static workflows and dynamic workflows.

Static workflows are those that are very well defined, and rarely, if ever, need to change from their original guidance. I admit that I am no expert in radiology, but I do know that the radiology domain profiles workflows that are fairly well understood and able to be controlled – at least to some degree. For example, a patient needs to have a certain imaging procedure performed, so they will first be registered in the system, an order will then be placed for the imaging procedure, the procedure will be scheduled and placed onto a DICOM Modality Worklist. The procedure is managed on the worklist according to the specifics involved (which are different for various imaging procedures). All in all, the process is fairly well understood. What happens outside the bounds of that particular procedure are of course variable, but the imaging procedure itself fits nicely into a well-defined workflow, and is finished within a single outpatient visit.

Dynamic workflows are much less predictable and must provide appropriate levels of adaptability in order to be successfully implemented. These workflows are those that are very open ended and dependent on many varying factors. Did the patient actually take their medication? Did the patient schedule that follow up appointment? It turns out that it is hard to ensure that patients follow their care plans prescribed by their providers. It is often times equally as hard for the patients themselves to follow their own care plans, amid busy schedules, with families to manage, work, etc. Sometimes tasks are forgotten or deemed to be less important than the task competing for their immediate attention. There is also a level of importance placed upon any given task in a patient’s care plan based on the amount of benefit that would be received from the task.

For example, a care provider may prescribe some sort of physical therapy, and if the patient completes the physical therapy then she will show signs of improvement (less pain, more mobility, etc). Maybe that is enough to satisfy the patient, but it would not satisfy her doctor. The patient decides to stop going to the physical therapy sessions because she thinks she is “better enough.” However, her condition worsens over the next few months, and she must schedule a follow up visit with her doctor to determine how to reengage with her physical therapy. The same scenario could be applied to many other situations, one common example being medication adherence for anemia.

Another aspect of primary care is dealing with patients that have comorbidities. Multiple chronic conditions can greatly complicate being able to effectively care for a patient. Combined with the fact that different people have different metabolic rates for medications that are not based on consistent factors – such as body weight, height, and vital signs – the doctor needs a system that is flexible and adaptable in order to do their job. This is one reason that adoption of EHRs has been so sluggish in the past few years. They tend to constrain care providers to a certain workflow that gets in the way of the doctor caring for their patient.

Workflows are addressed in IHE domains in various different ways depending on the clinical use cases being addressed. There are a handful of different underlying standards that are profiled, and in many cases those standards are profiled in slightly different ways for the varying clinical use cases present. Workflows exist everywhere, in every system – both healthcare specific and generic. What makes implementation guidance effective is a combination of factors, one of the key factors being how well the clinical workflow is understood by the specification author (or committee) and how well the underlying standard is matched to the clinical use case in a way that an implementer (i.e. health IT software vendor) can understand and write code to it, providing a useable product to the clinician.

Listening!

High quality listening skills are so important to many roles across various types of organizations. I am reminded of this constantly. Recently, that reminder came through watching a documentary about the assassination of US President James Garfield in 1888. Dr. Willard Bliss, the physician treating President Garfield, was guilty of not listening. He was perhaps blinded by his own ambition, or maybe his ego. Dr. Willard was not an uneducated man, he was understood the importance of listening, he had to in order to achieve the status he had. When Alexander Graham Bell visited the injured president to offer the use of his newly developed technology in metal detection in attempt to find the bullet lodged in his body, Dr. Bliss would not allow Bell to test the instrument on the president’s left side, claiming that the metal springs in the bed were interfering with the device. Why Garfield could not be moved to another bed without metal springs, or why Bliss did not simply allow Bell to at least try on the opposite side of Garfield will likely never be fully known. Regardless, the hindsight wisdom is of course that he should have been more open to alternatives, putting his ego, ambition, or whatever was in the way of his ability to listen in the best interest of his President and patient.

In a software company listening to customers is also quite important. There are two parts to listening: the actual act of listening, and the interpretation of what is being communicated. The latter being achieved often by ensuring the right questions are asked to ensure the sharer of information is providing all of the right context and information necessary to make a good decision. In a product management role the act of listening to the customer is often driven by the organizational structure more so than the individual with the opportunity to listen. What I mean by that statement is that some companies promote as much communication as possible between product analyst teams and their end users (customers of the product) understanding the benefit that comes from that communication is much more often than not positive improvements in the product feature sets. Other companies stifle this communication by providing a process by which there are teams that build the product and then there are teams that manage the customer relations. The idea is to isolate or protect the builder teams from too much customer chatter to keep their productivity levels high. But the problem is the same one found in the game of Telephone (Chinese Whispers), where the resulting message communicated to the builders that originated from the client engagement folks is not the intended message! Building software is a complex task, and there is much room for error when taking this approach.

As the software industry matures, one of the leading ideas that has introduced an incredible paradigm shift in this regard is the Agile Manifesto, an idea that many of you are likely very familiar with. Following the Agile Manifesto, and associated methodologies that are built on its principals ensures that you and your team are outstanding listeners. In fact, the third rule in the manifesto is “Customer collaboration over contract negotiation.” Agile also supports a very strong idea of accountability, ensuring that you and your teammates are all good listeners, among other things. So how is your listening? Are you asking the right questions by deeply processing what your customers are saying and applying critical thinking?

Prescribing Behavior

At the InterSystems Global Summit a few weeks ago I heard about this new approach to solving medical problems, in lieu of medications. It’s the idea of prescribing behavior to a patient, just the same as a medication would be prescribed. The idea is basically centered around an app store for clinicians. A doctor will issue a prescription for an app, and use the medical app store software to ensure adherence to proper use of the app. The clinician will be notified when the patient installs the app, and will be able to track whether the patient is using the app as it was intended to be used. If the patient is not using the app then appropriate follow up actions can be taken (e.g. text message, phone call). It could be essentially the same workflow that happens today with medication adherence.

This brings up a couple of interesting ideas. One is that our day to day behaviors sometimes lead to improved outcomes (and perhaps more often than not!). If a patient has Type 2 Diabetes then diet and excercise can have tremendous benefit. This particular example is, of course, not a new discovery. The less understood, or perhaps less quantifiable aspect here is the impact from improved emotional health. Does happiness truly help a patient to combat certain diseases? Some researchers think so. In this line of thinking, an app that somehow tracks and improves happiness levels could also be used to collect data correlating to disease outcomes.

Another interesting idea is how this might impact the existing pharma industry. Surely there are still and will remain very valid reasons for and effective outcomes resulting in the prescription of real medications. I am in no way advocating this is a silver bullet, and we do not need medications. However I do know, from personal experience how technology can influence change in habits, for better or for worse. And I also have seen how our culture today readily embraces convenience – people want to have their cake and eat it too. If doctors start prescribing apps, and medication sales decline, pharma might need to rethink its strategy – perhaps it gets in on the app store business.

Although there are clinicians using this now from what I have heard, from the overall industry perspective I believe this is still a medium to long term plan. If I were to guess it would weigh heavily on the fact that there is still a generation gap with technology adoption. All in all the clinician app store approach is all about encouraging the patient by providing motivation to adopt and maintain behaviors that result in better outcomes. And things that improve outcomes are things that I am very much a fan of.

IHE Patient Care Coordination – Past, Present, and Future: Part III

The Future!

This is the third post in a series on the past, present and future of the IHE PCC domain. So what’s next? Lots of stuff! At our face to face meeting this past summer we held a strategy meeting to discuss what we are doing with our domain as we were in a place of needing such clarification. The results of that two or so hour long session were new vision and mission statements, and a set of shiny new strategic goals for our domain.

Vision

The vision of PCC is to continually improve patient outcomes through the use of technology connecting patients and their care providers across healthcare disciplines and care paths.

Mission

The mission of PCC is to develop and maintain interoperability profiles to support coordination of care for patients where care crosses providers, patient conditions and health concerns, or time.

Strategic Goals

The strategic goals of PCC, which are 3–5 years in length, are to focus on content, workflow and nursing.. These three goals originate out of the work we have been focused on for the past several years and so they are not new concepts to us. However we felt it important to document specifics items around these goals to ensure our path forward is clear.

Content

PCC has had such a heavy focus on content over its lifetime, and naturally content standards and implementation guidance is changing along with the landscape of HIT. HL7 has recently produced the Consolidated CDA implementation guide, which directly competes with PCC content profiles. I am not convinced this was entirely intentional on HL7’s part, as the implementation guide itself is actually quite good and there are even a few references to PCC content templates within it. To be more specific, C-CDA replaces the family of HITSP implementation guides that all sit on top of PCC content templates, but C-CDA also has breaking changes to the existing PCC templates, and at the current time is US realm only. This last bit is a big challenge for many non-US implementers, and the reason why adoption and uptake of C-CDA has been primarily US focused vendors. Due to these recent events around content PCC feels that it should be proactive and engaged with HL7 to ensure that the responsibility to create and maintain content templates is shared between the two organizations.

So what roles do each play as it relates to content? I believe HL7 should continue to play the role of providing the framework aspect of content with a bit of guidance based on healthcare domain, so they would own how any given CDA section and CDA entry should be structured with minimal guidance on implementation details of those templates. PCC would own the more specific implementations of those artefacts based on specific clinical use cases. This would include extensions to the schema, value sets and optionality. This makes sense as HL7 has a lot of experience with vetting standards to ensure they are broadly adoptable, and IHE has a lot of experience working with stakeholders from a variety of medical disciplines and has a great process already in place (Connectathons) to test profiles.

Workflow

Workflow has long been a focus of PCC but really only in piecemeal, which is the same approach many other IHE domains follow. By piecemeal I mean more focused inwardly on solving a clinical use cases that have been brought to our domain rather than taking a cross-domain approach. Yes we do have a few profiles that have crossed into other domains, but by and large we author those profiles within PCC and have not always actively engaged other domains in our efforts. I believe PCC is well positioned to expand outside of our domain and across to other IHE domains to bring together workflows that are realized in the real world but have yet to be well represented in the interoperability profiling space.

PCC has received several profile proposals this year (four to be exact) that came from other IHE domains. Those domains are Radiology and Patient Care Devices. So you can imagine our delight of this news after our recent strategy sessions which concluded this exact effort is something we should be working on. It seems to be confirmation in every way that we are moving in the right direction.

Nursing

The Nursing Sub-committee of PCC was established in 2008 and has had decent participation over the years, however the uptake of work produced from this sector of PCC has not been strong. I believe this is primarily because the content profiles we have produced easily apply to both nursing and clinician/physician based content. The difference however, is primarily in the workflows, and workflow also happens to be one of our strategic goals. We have learned that nursing workflows are often times vastly different from their counterpart clinician/physician workflows. And so we are presented with an opportunity to provide better guidance in this space.

In Closing

Overall PCC is in a great place right now, on the cusp of exploring new opportunities as the world of HIT and interoperability continues to mature and change. If you are interested in getting involved check out our wiki page here.

2015 IHE NA Connectathon

It’s time to rock your interop at the 2015 IHE North America Connectathon! If you are not familiar with IHE Connectathons there is certainly sufficient information on the internet to educate you. If you or your company has an opportunity to participate and you are on the fence I would strongly encourage you to attend. Not only is it a great technical conformance testing event, it is also a great networking and idea sharing opportunity. Registration opens on August 25th, 2014. So go forth, register, code, configure, and interoperate! Hope to see you there!

IHE_Connecthon_Infographic_V2

*Infographic courtesy of HIMSS Marketing

IHE Patient Care Coordination – Past, Present, and Future: Part II

The Present

Today the PCC domain is in a place of discovering where it is we are going next. We have published a few dozen profiles over the past several years, many of which are content focused, but some of which also cover integration and workflow. As the HIT interoperability landscape evolves PCC must continually assess the work it is producing for validity in the marketplace. Specifically with the advent of HL7’s Consolidated CDA implementation guide we now have duplicate templates and a split in the market. PCC has many international stakeholders that continue to reference our templates, however most US based systems are focused first on C-CDA as it is core to the interoperability components of Meaningful Use Stage 2 compliance.

So how are we figuring this out? We are talking amongst ourselves first and foremost to better understand what our vision and mission is, what our core values are so we stay true to our purpose and role within IHE and the industry. Secondly we are talking with external organizations to ensure we align and/or harmonize our work efforts as appropriate, lest we find ourselves suffering from the Ostrich Effect.

To provide a little background (and expand on my previous post) we have created and published a total of 23 content profiles, 7 integration profiles, and 5 workflow profiles since 2005. This year we are publishing two profiles, one of which is new, the other is a re-write/update, and also a white paper. Our profiles are Multiple Content Views (MCV) and Reconciliation of Clinical Content and Care Providers (RECON). Our white paper is A Data Access Framework using IHE Profiles (DAF).

MCV provides guidance on how text in CDA documents may be tagged to achieve different rendering behaviors. For example, a patient does not necessarily need or want to see all of the details of their lab results, they may just want to simply know if the results are “good” or “bad.” MCV provides a mechanism upon which data can be presented to meet this requirement. However, in no way does MCV change, remove or exclude data from the CDA document itself – it is still intact, in the narrative text and/or in the structured entries. MCV is really focused only on rendering of the data, and the narrative text in CDA documents is what is primarily leveraged to achieve this end.

RECON was originally published in 2011, focusing on problems, medications, and allergies sections. Upon further assessment last year it was determined that we needed to make two adjustments to the existing RECON profile : provide an easier implementation path and expand to include additional sections of data. RECON is important to patient safety to ensure that the right data is available to the right person at the right time. Without reconciliation in any given clinical workflow pertinant data may exist across multiple documents or locations in the system and the care provider may not have time to find that data, and assemble in a way that is meaningful for appropriate care of the patient. For more detail see the use cases outlined in the RECON profile. This is especially true in an emergency situation where time is of the utmost importance.

The DAF white paper describes a framework by which IHE profiles can support multiple means of access through substitutable modules (IHE profiles). This work effort was brought to IHE via the US ONC, and is not so much an attempt to map out implementation guidance, but to explore how various IHE profiles could be implemented to create successful interoperability scenarios, based on various use cases and business requirements. This effort utilized a few different enterprise architecture frameworks to assist including:

We covered these new profiles, as well as other PCC topics on our annual domain update webinar this week. This webinar was recorded and will be available online soon at http://ihe.net/webinars/.

If you look at our work this year as well as last year you will see a pattern emerging that our focus is shifting away from straight templating of content, and more toward how that content is used in various systems and situations. I see this as a natural next step in the evolution of content-based standards. However our templates are still quite important to many non-US based stakeholders, and so IHE and HL7 are working together at the executive leadership level to resolve the issues around duplication of templates that exist today. My sincerest hope is that IHE PCC is able to remain in the content template guidance space as it is vitally important to working through content requirements for a number of international stakeholders.

IHE Patient Care Coordination – Past, Present, and Future: Part I

The Past

As co-chair elections are around the corner it got me to thinking about where the Patient Care Coordination (PCC) domain has been, where we are today, and where we are going. We operate in such a fast changing world in health IT and if you blink your eyes you will miss opportunities to innovate and impact the future of health IT in a positive way. This will be a multi-part blog post that takes a look at the past, present and future of the PCC domain.

My first IHE Patient Care Coordination (PCC) meeting was early in 2007 at the first face to face meeting for writing profiles of that cycle. I was not only a green software engineer (more or less) but also completely new to the world of health IT. My involvement at that time was a whopping six months, and that six months was spent primarily working on a new login process for my company’s patient portal application. So much for bringing any clinical application development experience to the table. Fortunately I was surrounded by peers in IHE whose knowledge and experience far exceeded my own and I had the opportunity to learn from and lean on their expertise. My task was to help write an obstetric profile, one that was based on various paper standards in use. At the end of that summer we had published the Anteparum Summary (APS) content profile (now in Final Text). In addition to participating in creating the APS profile I also had the opportunity to implement this profile along with the family of ITI profiles for document exchange (XDS, PIX, ATNA, CT) within an HIE.

In the following years in PCC we continued working on several other profiles covering a broad range of clinical use cases, providing guidance on content as well as integration. My focus was specifically around obstetric profiles, focusing on the ante, intra and post partum phases of the birthing process. I switched companies and continued developing interoperability solutions for the next several years. Along the way my IHE PCC colleagues bestowed the honor upon me of co-chair of the technical committee. I did that for a couple of years, and it was then that I developed a much more complete understanding of the processes within IHE as well as the importance of and opportunity of this organization to influence the world of health IT and ultimately improve patient care and outcomes.

After one term I stepped down as technical co-chair due to workload constraints (my wife and I also were blessed with a total of four children from 2004 to 2011 so family was certainly a big part of my life, and still is). A year or so later one of my colleagues convinced me to run for PCC Planning Committee co-chair, I thought on it for about 30 minutes and accepted the nomination and was voted in. As we are moving into another year of the IHE development cycle co-chair elections are upon us once again and I intend to run for another term of PCC Planning co-chair. Should I have the honor of serving my domain for another two years, I intend to sail us in some slightly new directions, focusing more on workflow and a bit less on content (but certainly not excluding content!), but more on that later in a subsequent blog post.

From the inception of the PCC domain in 2005 until the present (2014), PCC has published upwards of 35 profiles and several white papers. It has largely filled a gap in the industry providing content template guidance that has been eagerly adopted by implementers as well as international programs and initiatives (e.g. Meaningful Use, epSOS, ASIP Sante). We are now at a juncture of figuring out where to go next. Content template guidance will likely be a part of our future, but we must also consider our role in the workflow space, and how we can help to improve patient outcomes by providing guidance on the use of standards around interoperability.

Navigating IHE PCC Content Templates

One of the challenges with reading and understanding how CDA templates link together in PCC is that we are continuing to create new content templates, and have several still in Public Comment or Trial Implementation state. This means that we have document, section and entry content templates in several different published documents instead of neatly wrapped up in a single technical framework document. A single technical framework document (volume 2) is the end goal, but we must eat this elephant one bite at a time and deal with the complexities that come with such a task. Basically templates can be documented in one of 3 places: PCC Technical Framework Volume 2 (hereafter referred to as PCC-TF–2), CDA Content Modules Supplement, or profile supplements to the PCC-TF–2. Where templates are documented depends on their current state in the IHE development and publication process: Public Comment, Trial Implementation or Final Text. So yes, it is a bit confusing to navigate at first, but once you understand the makeup it is actually fairly straightforward. First let us cover these 3 locations, then we will talk about specifics of the types of templates and where each might be found.

PCC Technical Framework Volume 2

This contains all templates that are in Final Text state. That is, those templates that have been released into production. It is certainly possible that document templates in profile supplements may reference templates here.

CDA Content Modules Supplement

This is a holding tank for section and entry templates that are in the Public Comment or Trial Implementation state. PCC created this document several years ago to accomodate the need to share templates in draft state (Public Comment or Trial Implementation) across and between various profile supplements. At the time we had a lot of duplication across profile supplements and it quickly became very complicated to manage so this was a nice change. As it turned out this also became a great tool for other IHE domains to use as well. The QRPH domain has several templates in this same published document.

Profile Supplements

New IHE profiles are written initially as supplements to the Final Text version of the technical framework. This was intentionally designed in this way so that profiles must go through a period of implementation and testing to determine if they are ready to be released into the wild, which in IHE is defined as Final Text. More information on the process can be found on the IHE wiki. Getting back to the topic at hand, only document content templates will be found in profile supplements. Those document templates will reference section and/or entry templates that will be found in either the PCC-TF–2 or CDA Content Modules. So now that you understand a bit about where templates can be found here is a quick breakdown of the different types of templates that are found in these locations.

Document Templates

Document templates contain a list of section (and sometimes entry) templates and are identified by a name and a LOINC code. Document templates may be found in either the PCC-TF–2 or in profile supplements.

Section Templates

Section templates may contain other sections or entries, or both. These templates may be found in either the PCC-TF–2 or the CDA Content Modules Supplement, however are typically not found in profile supplements.

Entry Templates

Entry templates are essentially the same as Section templates, in that they may be found in PCC-TF–2 or CDA Content Modules, but typically not in profile supplements.

In summary consider the matrix below that shows where each type of template may be found. Note the the PCC-TF–2 is the only location where all three are found, and this makes sense as the ultimate goal is to roll everything into the technical framework.

TemplateMatrix

Finding a Template

To find a particular template of interest the best way is to look in the table of contents in the appropriate document, alternately one could search by name, or better yet by the template identifier. Every template in PCC (as well as other domains) is assigned a unique template identifier. The registry for these templates is available on the wiki, however these template identifiers also appear in the three document locations covered in this post (reference above matrix for which ones appear in which document). So while searching by name will get you most of the way there, searching by the unique template identifier is gaurenteed an exact match.

This revised approach of template management has certainly helped PCC (and QRPH) to manage the influx of new templates over the past several years, with the trade-off that finding the template you are looking for takes a bit of understanding of where to look. Hopefully this post fills in some of the gaps for folks who need it.

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!