This Blog is where I write about my favorite kind of data analytics, Clinical and Healthcare analytics. Of course, all kinds of data and information analysis are fair game for discussion in keeping with my growing fascinations with Mathematics, Statistics and Data Mining.
My friend is in a Graduate Certificate Program in Health Informatics. Although this sounds like quite a specialized an area of study, a closer look might convince you that health informatics is really a set of skills to be acquired from many disciplines. Further there is no benefit to steeping a candidate deeply in any of the relevant disciplines.
First consider that the field is not very consistently or completely defined beyond being a study of health care information. That it is the product of many diverse perspectives and opinions is also not generally appreciated. Thus, it was not a surprise to me when my friend complained the program is not moving her towards the job she expected.
Hence, I have been looking at health informatics curricula, including my friend’s, to understand better why this is the case. It occurred to me at that point, as the cliché goes, that programs are too frequently developed and taught by persons who do not have a solid handle yet on what needs to be done that is different from informatics in general.
For my own part, I learned health informatics in bits and pieces before there was much attempt to set out the content of the field. From a clinical background, one set out to acquired some appreciation of database structure and design as well as application development. Then one added knowledge (or at that time contributed to development) of coding and classification of health and medical information. For physicians, who worked only superficially in multidisciplinary teams, the need to acquire awareness of and skills for dealing with how work was done in such teams. Usually, like many non-clinical duties physicians had, many of us were simply assigned to IT liaison roles in departmental meetings, to look out for the needs and interests of the clinicians.
Having looked at courses and program offerings of many academic centers, I have formed a somewhat dissenting opinion (admittedly, as I usually do) on how health or medical informatics should be done. My persective is illustrated by the upper graphic at right. I ran across the lower graphic in a Health Informatics presentation slide during my research and reproduced it's content here (the red barred circle is my addition). I think Health Care Informatics should be a truly integrative-collaborative discipline within a somewhat autonomous facilitation role. I have ultimately developed my ideas in a proof of concept study for a plan to develop a syllabus for a course (Introduction to Health Informatics). I would like it to be offered on-line as a supplementary or enrichment offering. My thoughts follow in a kind of report.
With the analysis of health informatics curricula, an early clarification is needed, which is whether Health Informatics is better considered as a special interest of the Health disciplines, a special area of practice in Information Technology or whether it is most effective as a discipline in its own right.
Consider that decisions about applying domain knowledge from different areas to complex problems has been much more a matter of political and management power (as currency) than the achieving of a “best of breeds” solution. Although ultimately, it is necessary to set aside the “silo wars” and “turf battles” of professions forced by circumstances to have an interface with each other it is Important to understand the origin and nature of these power struggles. Perhaps then there is hope to overcome their effects on domain informatics and in particular health informatics. Therefore, we will look at the baggage brought to the informatics table.
Looking for an optimal way to approach multidisciplinary information needs the writer principally intends to consider foremost the needs and requirements of health informatics projects and their owners. It should become obvious that the definition of the consultative domains of a project should be driven by the needs of the project itself. In this age of specialists, the role of the generalist as an integrator and coordinator is usually ignored. By generalists, I mean those defined by the broader scope and generality of their knowledge rather than their depth of knowledge. The case will be made that for medium to large multidisciplinary projects generalists are the best placed to bring together and liaise between disparate project resource centers (professionals)
In no place is the embracing of specialization more evident than in the US Health Provider hierarchy where even the generalist (general practitioners) were forced to organize as a specialty of stay in the provision of care. The argument has been that the field of medicine is too data intensive and information overloaded for a generalist alone to maintain required competencies. While this is true, diagnosis and treatment of specific diagnostic clusters, specialization by organ system, or by special skills
As a clinician, I lean naturally towards consideration of the dynamics between influences in health and disease. In the spirit of this kind of analysis, let us think of the history between users of information and data systems people, the traditional custodians and facilitators thereof. In the 60s and 70s, for clear economic and logistical reasons, data processing needs, were submitted by the user to the data processing department for triage and queuing. If they were lucky from the start, the data was included and if not simply the description of the job to be run was submitted for approval of system time.
In those early years equipment was physically large, expensive to acquire, complex to operate and often quirky and unreliable in operation. The computer operations sector was created to make these behemoths of bits function. This era saw the rise of the “You want it when?” modus operandi and bumper sticker. My experience is that when one “holds all the cards” one soon becomes rather cavalier and insensitive about how one hands them out. Given persistence of the situation, the cards entrusted to you actually become YOUR cards.
By the end of the 70s, the situation for the owners of small poorly funded jobs became dire. People were doing amazing and absurd things by hand (or hand calculator) on paper worksheets over weeks to months that were doable by computing machines in minutes. Then, the personal computer arrived followed very quickly by the electronic spreadsheet. The lines of the data processing department diminished to essentially zero consisting of company data filing routines.
Amazing things began to be done by users by themselves for themselves. Processing time wasting activities like word processing replaced the generation of reams of paper, consumption of Correctype (what’s Correctype?) and buckets of used carbon paper (what’s carbon paper?). Personal card files became desktop databases. The balance of power shifts.
Then some creative guys at Digital Equipment got this idea to connect PCs together to allow them to communicate and move files between them. The local area network was born, and who better to organize and coordinate the fun than the data processing people. (We’re baaack!) The power shifts again and the criteria for information processing forever leaves the user’s sphere of influence.
So, now the information to be stored and used is generated by health domain workers, particularly health care professionals: nurses, physical therapists, physicians, imaging technologists etc. However, their information is much too important, sensitive, or proprietary to trust them with so the information technology are entrusted with the care and feeding of data systems with data from others. Decisions about information characteristics and content drift from the grasp of users. It’s 1970 all over again.
The most important negative influence on health (particularly medical) information systems is provider acceptance. Providers, especially physicians, are in to unenviable position of those most able to scuttle any effort at a solution. My physician colleagues have come to mistrust IS people to the point of irrationality. One simply has to see the polling results of the healthcare press on physician acceptance of clinical data systems for a sense of the anger computerization of the patient record has generated.
For similar reasons my observations have been of an identical degree of distrust of physicians by information technology professional. They find physicians vague, hostile, and generally uncooperative with administrative processes. They likely also find physicians are reserved or withholding in multidisciplinary team situations and they do not share power easily. Much of this is true and is likely the reason why hospital administrators seem to have more difficulty working with physicians generally than most other groups.
There are good reasons why physicians behave as they do with those outside (and inside!) of the profession. These dynamics1 are base on historical, selection biased and education/skills based precedents. It is not in the scope of this discussion to explain these dynamics. It is only necessary here to point out that these characteristics are prized in the other roles physicians have served for longer and cannot be made to go away by simply making them employees. Thus, it is only important for us to know how all stakeholders can define and use the information tools to be developed, together.
Now, the information itself has become the behemoth, the demands on the data and information voracious and the complexity almost indecipherable it cannot be pretended to fit into any one domain. It has progressed from multispecialty through multidisciplinary to multifaceted. It is so unwieldy that mistakes and grievous outcomes are resulting from simple miscommunication of knowledge information or data as well user (practitioner) information overload. I have blogged about this aspect of the problem elsewhere2. A need for a comprehensive, manageable, integrated and user defined set of solutions is urgent. It is a multi-domain, polytechnically defined problem obviously beyond the scope of any single domain of knowledge (profession?). Further, I should be clear that its governance, design, implementation and administration is well beyond the priorities and skills of any single stakeholder.
The scope of the field of health informatics implied by the forgoing is a call for a kind of generalist that can stand comfortably, on demand, with a foot in any stakeholder domain to facilitate stakeholder needs effectively and efficiently within the larger context. This is a systems theory problem. The description implies a kind of diplomatic corps, which can give the appropriate sense of ownership to user-stakeholders.
I visualize a role analogous to the project management professional who functions as comfortably within any domain area as between specific domains. This is the classical general contractor role, in which the project manager is sufficiently conversant in the special knowledge of the stakeholders to communicate and interpret for all concerned and to facilitate problem-solving activities by all that results in a full buy-in to the solution of all concerned. For anyone who has worked on multidisciplinary teams of independent professionals requiring high involvement of members and their constituents this is a very tall order! Nevertheless, the very difficulties experienced by medical professionals attest to the need.
Most Academic Health Informatics programs reside in one single university department, school or faculty as a matter of administrative necessity. The result is that program stakeholder priorities become mired in departmental priorities and bureaucracies, which ultimately dilute program goals. The diluents include the very sort of issues outlined above. Program governance issues must not be allowed to become subservient to parochial degree or certificate granting processes.
With governance in mind program planning needs to be innovative. Finding an academic and administrative home for domain informatics may be best served by the setting aside of parochial agendas and thinking more outside of the box. Some institutions already have integrative or interdisciplinary studies faculties with a liberal invoking of cross appointments. There are Schools within some Institutions, which already have a rich interdisciplinary heritage, such as those of Engineering and Management. Project Management is often housed in Engineering Schools and Faculties. Systems Theory Studies in the early 70s were at most universities classed as an Engineering sub-discipline.
There are a number of knowledge areas or potential benefit to those working on Health Informatics projects. The depth of knowledge that is needed, or would be most helpful, is difficult to characterize. It obviously depends on the range of projects, which are to be considered common in health informatics practice. The earlier discussion clearly implies there is greater strength in the breath than the depth of knowledge for this integrative knowledge practitioner. These knowledge areas should include, in a general way,
There will always be a didactic tension between the value of over-learning common or essential skills and teaching effective abilities for the look-up of sources or of consultation to acquire expertise. It is better, in my experience, to know what you do not know and where to look it up than to commit vast amounts of information to memory. The pitfalls of the latter approach are becoming very topical as information overload becomes the rule and I blogged on this as the driving force for users of informatics.
There are many more programmers and data analysts than there are health informatics project experts who are able to communicate with the full range of stakeholders in any project. As an example, a need has been discovered for user experience experts. This was because user communication was not a reliable and consistent strength of programmers and systems architects. The niche, which needs to be filled, is analogous to user experience expert in the sense of a health informatics project. Training programmers who want to program to be liaisons for users is not playing taking advantages of strengths. Everyone self-selects for their strengths and interests in choosing their role. It is as futile a task as trying to teach physicians to delegate the responsibility for their own actions. Physicians may share roles and delegate actions and author under their roles but responsibility professional or otherwise is ours alone.
It is not a coincidence that the iterative process is central to so much of product and service design and implementation. The Agile process, the software development cycle and many other instances have inherited iteration from Continuous Process Improvement. Iteration makes the unattainable perfection everyone seeks in theory possible.
It is not necessary (and highly improbable) to “get it right the first time” with health informatics implementation. Even though both are mission critical, it is no more possible to have a finished solution suddenly appear than it is to bring about all the correct changes to the US Health Care System at once in order to provide appropriate and universal access for all Americans. Only politicians and lawyers can seriously profess such a goal while we keep in mind that they too self-selected into their role according to their own strengths, and weaknesses.
1After years of thought, I understand the dynamics of my peers much better, and I could tell you why; but then I would have to have you killed (or, send you a bill).
2 see Blog 1, re: complexity of medical information and medical errors
Who's Caring for the Patient, What are They Doing
