Clinical Care Informatics vs. Research Informatics

I have been blogging steadily now for almost two months, which leaves me still in the newbie category, but over time I have looked at a lot of other blogs with a similar focus, and have realized that mine is a bit different. My passion is biomedical research informatics technology, whereas most health IT sites are focused on the much larger and more mainstream market of clinical care IT.  There are some major differences, though we have a lot in common, especially with respect to visions of the future. This table enumerates the ones that come to mind.

Here's the contrasts I see:

Clinical Care IT	Biomedical Research Informatics IT
Mission-critical to medical care, sometimes life or death in the near term	Mission-critical to research, a life or death aspect sometimes exists but it is almost never in the near term.   When emergencies arise, research becomes clinical care right quickly.
Real-time response often needed	Real-time is not normally an issue
Cost of care is an ongoing issue, forcing compromise decisions about which technologies to use	Once research is funded, technologies are dictated by the protocol or its implementation and money is no longer an issue (but is definitely is during the grant application process)
Professional medical ethics apply	Professional medical ethics apply here too, but the Common Rule or its equivalent (in the US, it has different names in different countries) imposes a higher ethical standard
Data collection needs to be "good enough" in terms of quality and level of detail (good enough to meet an acceptable standard of care)	Data collection must be precise and often more detailed than in clinical care; every discrepant data point must be addressed, not thrown out and the test re-done as would be appropriate in clinical care
Extensive capitalization of infrastructure is ubiquitous (at least in tertiary/quaternary care institutions worldwide and secondary care institutions in developed nations)	Except in the most prosperous and visionary institutions, IT infrastructure  has been pieced together on a project-by-project basis at the investigator level
Software engineering best practices are given lip service in IT units everywhere and actually implemented in many institutions	Software is mainly developed either by commercial entities focused on the needs of the wealthier customers (i.e., pharmas), or by research associates and young investigators with minimal understanding of and respect for industry best practices
Understanding and implementation of regulatory requirements is the norm	Understanding and implementation of regulatory requirements is widely variable
Efficient operation is key to organizational survival, so there is a guarded but real motivation to move to new technologies as soon as they prove their worth	With rare exceptions, research investigators couldn't care less about information technology, are often more baffled by now-commonplace technologies than their administrative assistants, and certainly more baffled than their under-35 post-docs. None of which keeps the informatics professionals from looking out at the horizon.

I don't have time to get into the nuances, but these are the major differences I live with every day. Obviously there are commonalities galore that I am not highlighting here, the most important of which is a deep and enduring commitment on both sides of the house to the well-being of the patient and the good of society. I am proud of the work I do and very appreciative of the efforts and achievements of my counterparts supporting our institution's clinical care mission.

Comments

[Robert DiLaura]

Hospital HIT organizations have a fundamentally different mission from a research informatics group. The former must first perform like the power company, providing consistent, standard and highly available IT services that support patient care. They can push the curve be offering features beyond commercial installations with highly customized configurations, but beyond that they run the risk of a single organizational group losing focus. Their progress should be slower and wih greater emphasis on detail and contingency planning (and incurring the additional associated costs). Research informatics groups often look (for better or worse) at each new clinical study as a one-off coding challenge. Each investigator is unique, and wants something different that should be accomodated as much as possible. Our challenge is to be more sensitive to the ROI for programming efforts (a stress often felt by the patient care HIT folks, but not by research informaticians), with better reuse of code and data models that already exist.
The inherent competitiveness between the institutional IT group and a research informatics group may be necessary and healthy if understood and managed at the organizational level for net benefit. Having the central IT group manage research data (for example in an EHR/EMR) may be impossible due to current system design constraints and given the way current research studies are designed seeking uniqueness. Likewise, having a research informatics group design systems that support healthcare indirectly but may be useful for future research needs is a grey area to read that likewise conflicts with the core competency and mission. Both groups add value and need to co-exist in some degree of harmony.
As efforts continue to build a National Health Information Network (the backbone that will enable exchange of healthcare information) and Personal Health Records (the ability for individuals to have granular control over their own protected health information (and thus shift the question of "who owns the data" into the hands of the individual that the information represents), the lines between institutional IT and research IT will blur even further. And this might be a good thing, but will call on the centralized resources to become more innovative and agile, while the reserarch-focused resources will need to operate more professionally and efficiently under the competitive pressure to use limited funding to meet dramatically increasing demands on all technical staff time.