This research project could rapidly get quite large, employing many people, so self-supportive must be feasible. Feasibility of this project must be viewed from the vantage of return on investment.
Either research and knowledge are valuable assets themselves, or they are not—however, money channels through its channels; corporate venture capital may not prove the best method to fund our research, since research must neither be hampered nor influenced by interests to turn a profit. Moreover, private non-profit might seem a favorable financial model for this project—however, we must not be hampered by the possibility that our efforts could prove profitable. Right now, profit is our concern; here the research stops.
Tuesday, April 13, 2010
#16. The Science of Willingness
Before we summarize our work so far, and further build the next logical step in series, we now may be best served to view our project from a few different vantages. We can return to developing human interfaces that front computer data structures later; right now let's regroup for a moment, and consider our own motivations into action.
Since we are usability scientists, and we are interested in human actions and human-computer interactions, we must consider their sources. Since we are largely studying human actions and reactions, we must be clear about the sources of these actions, instead of merely recording what they were, or how they manifested once they have already occured. We know that if we can anticipate likely future actions of end-users, based on their past actions, we can learn from our mistakes; however, we also know that it is best to categorize this behavior before we even get started. Therefore, we can again start with the broadest category, and work down to the minutia.
The Classical Greeks discovered that humans, as well as other organisms, are motivated by only two factors; that is, if all factors that motivate humans can be categorized, they will fall under one of two headings (or a percentage of both of them, in reality). These two factors that motivate actions are Fear and Desire—those are the only two options. People either move away from something, or move toward it. Although people may not act as the result of Fear or Desire, we know action (and sometimes inaction) is motivated by either of those two factors.
If our own desire is to create user-friendly healthcare software, then we can manifest that desire by cultivating the desire of the end-users of this software. This will be a completely different motivation to create software than relying on forcing healthcare workers to learn a faulty system, lest they lose their jobs. Not only would such threats be unfriendly, they would impede our ability to learn from our own mistakes; a user-hostile system would incorporate mistakes, and disallow all user input, except for that which the system channels.
Humans can be motivated by fear, but that is not the basis for the profession of healthcare, in general. The basis for healthcare is the desire to selflessly help others to achieve health. A desire for better health has sent willing patients to healthcare professionals, and these patients have willingly agreed to treatment from willing professionals.
At no point does fear make this system run more efficiently.
As the result, we know that we scientists are best served if we purposefully focus our own efforts toward cultivating willing participation of end-users without instilling any self-willed fear whatsoever, if that is possible. This will afford us the greatest possibility to extract the most accurate information from end-users, and will likely grow the system that mines data.
If user-friendliness is one benefit of user-centered design, then humble willingness will prove more profitable than proud willpower. This leads us to the next topic: We need to determine "profitable".
Since we are usability scientists, and we are interested in human actions and human-computer interactions, we must consider their sources. Since we are largely studying human actions and reactions, we must be clear about the sources of these actions, instead of merely recording what they were, or how they manifested once they have already occured. We know that if we can anticipate likely future actions of end-users, based on their past actions, we can learn from our mistakes; however, we also know that it is best to categorize this behavior before we even get started. Therefore, we can again start with the broadest category, and work down to the minutia.
The Classical Greeks discovered that humans, as well as other organisms, are motivated by only two factors; that is, if all factors that motivate humans can be categorized, they will fall under one of two headings (or a percentage of both of them, in reality). These two factors that motivate actions are Fear and Desire—those are the only two options. People either move away from something, or move toward it. Although people may not act as the result of Fear or Desire, we know action (and sometimes inaction) is motivated by either of those two factors.
If our own desire is to create user-friendly healthcare software, then we can manifest that desire by cultivating the desire of the end-users of this software. This will be a completely different motivation to create software than relying on forcing healthcare workers to learn a faulty system, lest they lose their jobs. Not only would such threats be unfriendly, they would impede our ability to learn from our own mistakes; a user-hostile system would incorporate mistakes, and disallow all user input, except for that which the system channels.
Humans can be motivated by fear, but that is not the basis for the profession of healthcare, in general. The basis for healthcare is the desire to selflessly help others to achieve health. A desire for better health has sent willing patients to healthcare professionals, and these patients have willingly agreed to treatment from willing professionals.
At no point does fear make this system run more efficiently.
As the result, we know that we scientists are best served if we purposefully focus our own efforts toward cultivating willing participation of end-users without instilling any self-willed fear whatsoever, if that is possible. This will afford us the greatest possibility to extract the most accurate information from end-users, and will likely grow the system that mines data.
If user-friendliness is one benefit of user-centered design, then humble willingness will prove more profitable than proud willpower. This leads us to the next topic: We need to determine "profitable".
Monday, April 12, 2010
#15. Crediting Novelty
Thus, we have developed an infrastructure whereby questions submitted on computer interfaces directed to individual healthcare professionals are organized so that organized computer interface answers can later be reflected back by the computer system to these individual healthcare workers. The computer system develops information trails, left by individual end-users, so that the computer system can direct specific communication to each individual end-user along the same trail in reverse.
To review: We know that end-users vary, that their jobs vary, that their patients vary, that symptoms vary, but that those entities can be organized and analyzed if we place them in variables (which themselves can vary, but that's later). Again we cannot make the mistake of limiting the input of information from these end-users, since they are the ones who are building their own system; rather, we know whatever system we create will not be perfect, so we must include the ability for users to amend it. Lastly, we also know that the scientific method asks questions, but answers to those questions actually spur a multitude of new questions.
(We must realize that the difference between a question and an answer becomes rather blurred at this point. Since end-users are submitting accounts of inadequacies within their own system that is presenting them with questions, they are actually questioning the authority of the system—which returns even more questions. We could go 'round and 'round with this debate of what constitutes a question versus an answer, so let's move on.)
Therefore, we must submit to end-users question/answers that are already established (from previously answered question/answers) in a different format from question/answers that are new. When question/answers are submitted to end-users from the computer system, their routine ones must be easily manipulated by clicking buttons, or similar third-key experiences, such as dragging pull-down menus—unless they are new questions/answers to the system—new answers must be typed; it is this ease of manipulation itself, that which differentiates routine from novelty, which can credit users with their own authoring.
For example, say we have created an interface that holds the question, "What is your last name?" However, family names in some cultures precede individual names—so the question does not capture accurate information as it relates to some end-users. We can employ this variance as an opportunity for our own growth, as well as crediting those who grow the research system.
This can be accomplished when some individual may claim the fact that in his culture family name comes first; this can be done by selecting the option, "This Question Does Not Fit," whereby he will be allowed to type information into a field directed to the creation of an entirely new Question Card (Development of these newly added Question Cards may be either reviewed first by authorized researchers, or submitted electronically with no oversight—nevertheless, the new cards are submitted into the system to be reused by others).
Therefore, research credit can be established for individuals as they submit information that finds faults with their system. (External rewards can be linked to this function, but let's just acknowledge its existence for now.)
This system not only allows users to upgrade their own system that they use, similar to the way that Wikipedia allows users to input information for upgrade, it also credits each user with the authoring of each amendment made. However, unlike Wikipedia, which submits one information interface to everyone, no author of novelty need be necessarily constrained to the practice of a preceding individual; each individual person has the ability to add information to this reverse data mine.
We will next investigate just how that individuality is expressed to each human individual.
To review: We know that end-users vary, that their jobs vary, that their patients vary, that symptoms vary, but that those entities can be organized and analyzed if we place them in variables (which themselves can vary, but that's later). Again we cannot make the mistake of limiting the input of information from these end-users, since they are the ones who are building their own system; rather, we know whatever system we create will not be perfect, so we must include the ability for users to amend it. Lastly, we also know that the scientific method asks questions, but answers to those questions actually spur a multitude of new questions.
(We must realize that the difference between a question and an answer becomes rather blurred at this point. Since end-users are submitting accounts of inadequacies within their own system that is presenting them with questions, they are actually questioning the authority of the system—which returns even more questions. We could go 'round and 'round with this debate of what constitutes a question versus an answer, so let's move on.)
Therefore, we must submit to end-users question/answers that are already established (from previously answered question/answers) in a different format from question/answers that are new. When question/answers are submitted to end-users from the computer system, their routine ones must be easily manipulated by clicking buttons, or similar third-key experiences, such as dragging pull-down menus—unless they are new questions/answers to the system—new answers must be typed; it is this ease of manipulation itself, that which differentiates routine from novelty, which can credit users with their own authoring.
For example, say we have created an interface that holds the question, "What is your last name?" However, family names in some cultures precede individual names—so the question does not capture accurate information as it relates to some end-users. We can employ this variance as an opportunity for our own growth, as well as crediting those who grow the research system.
This can be accomplished when some individual may claim the fact that in his culture family name comes first; this can be done by selecting the option, "This Question Does Not Fit," whereby he will be allowed to type information into a field directed to the creation of an entirely new Question Card (Development of these newly added Question Cards may be either reviewed first by authorized researchers, or submitted electronically with no oversight—nevertheless, the new cards are submitted into the system to be reused by others).
Therefore, research credit can be established for individuals as they submit information that finds faults with their system. (External rewards can be linked to this function, but let's just acknowledge its existence for now.)
This system not only allows users to upgrade their own system that they use, similar to the way that Wikipedia allows users to input information for upgrade, it also credits each user with the authoring of each amendment made. However, unlike Wikipedia, which submits one information interface to everyone, no author of novelty need be necessarily constrained to the practice of a preceding individual; each individual person has the ability to add information to this reverse data mine.
We will next investigate just how that individuality is expressed to each human individual.
#14. DNA of End-Use
We have proposed interface Question Cards to be subsequently submitted in series to individual healthcare workers; each Question Card is assigned a unique and invisible serial number, bar code, or other identifier, that a computer can read and process. Further, since initial questions submitted to each end user will be broad in scope, subsequently narrowing to questions regarding minutia, we can begin to organize the questionnaire structure as strings of data associated with individual end-users.
Different users can answer the same questions that other users have answered—that is, they can use the same Question Cards. However, different users are not constrained to using the same cards, or receiving them in the same order. Different users will assemble their questionnaires by using different cards already submitted into the data structure, or may need to create new questions.
In fact, sometimes different cards (with different serial numbers) must interface similar data fields, if we are to unify our research of end-use of varying professionals. For example, one Question Card may read "Please Enter Your Last (family) Name," while another Question Card may read "Пожалуйста впишите ваше последнее имя (семьи)," or "Incorpore por favor su nombre pasado (de la familia)", or "请输入您的前个(系列)名字." Regardless of human interface, our ability to gather similar data fields must be organized and unified for processing.
In essence, we have developed a method that allows healthcare professionals to build an informational genotype, of sorts; this genotype describes their work (which is performed to the class entitled Patients, and others) that can now be presented in the most efficient informational phenotype, if you will.
Rather, we now have strings of data regarding end-use of individual healthcare professionals—these are the interfaced Question Card serial numbers, and the sequences of their series. This information provides accurate data regarding end-use of each healthcare professional that we must attain to analyze the work of each individual. Once this work is accurately accumulated, we can then provide each individual with an accurate individual interface.
We must now submit the most efficient means for these professionals to communicate their jobs to the computer system, so that the computer system can reflect back their jobs, similar to the way that protein is expressed by nucleic acid molecules that have been linked appropriately.
Different users can answer the same questions that other users have answered—that is, they can use the same Question Cards. However, different users are not constrained to using the same cards, or receiving them in the same order. Different users will assemble their questionnaires by using different cards already submitted into the data structure, or may need to create new questions.
In fact, sometimes different cards (with different serial numbers) must interface similar data fields, if we are to unify our research of end-use of varying professionals. For example, one Question Card may read "Please Enter Your Last (family) Name," while another Question Card may read "Пожалуйста впишите ваше последнее имя (семьи)," or "Incorpore por favor su nombre pasado (de la familia)", or "请输入您的前个(系列)名字." Regardless of human interface, our ability to gather similar data fields must be organized and unified for processing.
In essence, we have developed a method that allows healthcare professionals to build an informational genotype, of sorts; this genotype describes their work (which is performed to the class entitled Patients, and others) that can now be presented in the most efficient informational phenotype, if you will.
Rather, we now have strings of data regarding end-use of individual healthcare professionals—these are the interfaced Question Card serial numbers, and the sequences of their series. This information provides accurate data regarding end-use of each healthcare professional that we must attain to analyze the work of each individual. Once this work is accurately accumulated, we can then provide each individual with an accurate individual interface.
We must now submit the most efficient means for these professionals to communicate their jobs to the computer system, so that the computer system can reflect back their jobs, similar to the way that protein is expressed by nucleic acid molecules that have been linked appropriately.
Thursday, April 8, 2010
#13. More About Presenting The Questions.
Human/Computer interaction is soft-coded.
Communication is dynamic. Languages change, word meanings change, people change, and medical practices change. Developing a system that is not preconceived to change must mean that either change has not been considered, or that the system has been preconceived to become outdated. Therefore, the best method for the computer to communicate with end-users is subject to change and advancement, along with technology and research into end-use of the individuals who interact with the system.
Nevertheless, we need to start somewhere, so we can accept our own limitations, while making some assumptions about these first few end-users to be studied:
• That they can read.
• That they can use the English language.
• That they have access to computers that are connected to the World Wide Web.
• That they have basic understanding of how to manipulate a computer, keyboard, and mouse (or other third-key device).
• That they have no handicaps that would compromise the efforts of this study.
So, while these opinionated assumptions are enough to get started, we must keep in mind that our opinions have been presented without an evidence base, so we must return to them. These opinions must simultaneously trigger our responses to further the researches into end-users to develop human/computer communication techniques that are more efficient than our first efforts will allow.
Interface tracking is hard coded.
Yet, we can begin by presenting our first interfaces that include the aforementioned criteria:
• That each individual end-user will be identified and instantiated by the first question (For example, "What is your name?").
• That each subsequent interface will be directed at each individual end-user.
• That each subsequent interface will be will be organized and presented in series for best comprehension.
• That each subsequent interface will be in the form of a question, regardless of communication technique.
• That each individual end-user will be able to change their questions.
• That the computer system will record these changes.
It will be important for us to develop a method to track these interface components as they are selected, compiled, amended and further developed. Not only will these interfaces provide a means for the human end-users to interact with their databases, these interface components themselves will become the objects of research; they must be labeled in such a way that a computer can compile them.
Therefore, these initial questionnaire components (let's refer to them as Question Cards) will have assigned alphanumeric serial numbers which may, or may not be visible to end-users. (I can think of no reason to hide these serial numbers from end-users, except that their visible presence could distract them from focusing their efforts of efficiently interacting with the system. That could change; but for now, let's hide these serial numbers in invisible metadata, off of the viewing screen.)
Communication is dynamic. Languages change, word meanings change, people change, and medical practices change. Developing a system that is not preconceived to change must mean that either change has not been considered, or that the system has been preconceived to become outdated. Therefore, the best method for the computer to communicate with end-users is subject to change and advancement, along with technology and research into end-use of the individuals who interact with the system.
Nevertheless, we need to start somewhere, so we can accept our own limitations, while making some assumptions about these first few end-users to be studied:
• That they can read.
• That they can use the English language.
• That they have access to computers that are connected to the World Wide Web.
• That they have basic understanding of how to manipulate a computer, keyboard, and mouse (or other third-key device).
• That they have no handicaps that would compromise the efforts of this study.
So, while these opinionated assumptions are enough to get started, we must keep in mind that our opinions have been presented without an evidence base, so we must return to them. These opinions must simultaneously trigger our responses to further the researches into end-users to develop human/computer communication techniques that are more efficient than our first efforts will allow.
Interface tracking is hard coded.
Yet, we can begin by presenting our first interfaces that include the aforementioned criteria:
• That each individual end-user will be identified and instantiated by the first question (For example, "What is your name?").
• That each subsequent interface will be directed at each individual end-user.
• That each subsequent interface will be will be organized and presented in series for best comprehension.
• That each subsequent interface will be in the form of a question, regardless of communication technique.
• That each individual end-user will be able to change their questions.
• That the computer system will record these changes.
It will be important for us to develop a method to track these interface components as they are selected, compiled, amended and further developed. Not only will these interfaces provide a means for the human end-users to interact with their databases, these interface components themselves will become the objects of research; they must be labeled in such a way that a computer can compile them.
Therefore, these initial questionnaire components (let's refer to them as Question Cards) will have assigned alphanumeric serial numbers which may, or may not be visible to end-users. (I can think of no reason to hide these serial numbers from end-users, except that their visible presence could distract them from focusing their efforts of efficiently interacting with the system. That could change; but for now, let's hide these serial numbers in invisible metadata, off of the viewing screen.)
Wednesday, April 7, 2010
#12. Data Mining In Reverse
Data mining is the process of extracting patterns from data accumulated; however, I must point out that we are set to reverse that trend. This study is being setup to develop a computerized information management system that studies the functions of end-users so that end-users do not need to study the function of the computerized information management system. Therefore, the computer system will be actually mining data that has not yet been accumulated, and the information resources mined are those of the end-users.
Once this information has been accumulated, it can then be further processed.
Therefore, if the entire effect of this study is to provide criteria to develop user-centered software for healthcare informatics, then that must remain our sole focus. Absolutely nothing must impede the effort of providing a friendly end-user experience, lest it undermine our primary goal of attracting willing users to help us to determine if Healthcare = 1/Crisis.
Once this information has been accumulated, it can then be further processed.
Therefore, if the entire effect of this study is to provide criteria to develop user-centered software for healthcare informatics, then that must remain our sole focus. Absolutely nothing must impede the effort of providing a friendly end-user experience, lest it undermine our primary goal of attracting willing users to help us to determine if Healthcare = 1/Crisis.
#11. Play 20 Questions With Your Interface.
Most who have played the child's game "Twenty Questions" realize that linear organization of questions can efficiently pinpoint answers; by beginning with the broadest possible scope of questions (EG "Are you an animal?") children can isolate objects and their locations in very few questions.
It is possible for computerized interfaces to submit questions to end-users in this fashion. It is possible to submit the correct healthcare practice questions (in an organized fashion) to the correct healthcare individuals, who can then answer them more efficiently than if the users, on their own, were forced to sort through a large list of questions that also contains questions not relevant to their jobs.
Since a format to receive the information has already been established at the database level, we merely continue organizing the questionnaire information—submitted on an interface structure—in the same format, forwarded to the end-users. Like dealing face-up cards to poker players, it is possible to submit appropriate questions to individuals without handing them the entire deck of the whole questionnaire.
For example, since everyone has a name (or an alias) that has instantiated their accounts, "What is your name, or alias?" might likely be the first question on an interface structure received by individual healthcare workers; the submitted name field will be different in every case. However, the second question submitted to individuals might be a job title (doctor, nurse, respiratory therapist, or the like); that job title will be similar to some, different from others. We now begin to find differences and similarities to study for the purpose of mining information about users to extract interface specifications to better serve these individuals when a user-centered informatics system is developed.
It is possible for computerized interfaces to submit questions to end-users in this fashion. It is possible to submit the correct healthcare practice questions (in an organized fashion) to the correct healthcare individuals, who can then answer them more efficiently than if the users, on their own, were forced to sort through a large list of questions that also contains questions not relevant to their jobs.
Since a format to receive the information has already been established at the database level, we merely continue organizing the questionnaire information—submitted on an interface structure—in the same format, forwarded to the end-users. Like dealing face-up cards to poker players, it is possible to submit appropriate questions to individuals without handing them the entire deck of the whole questionnaire.
For example, since everyone has a name (or an alias) that has instantiated their accounts, "What is your name, or alias?" might likely be the first question on an interface structure received by individual healthcare workers; the submitted name field will be different in every case. However, the second question submitted to individuals might be a job title (doctor, nurse, respiratory therapist, or the like); that job title will be similar to some, different from others. We now begin to find differences and similarities to study for the purpose of mining information about users to extract interface specifications to better serve these individuals when a user-centered informatics system is developed.
#10. Presenting To The Professionals.
When presenting a successful questionnaire (or any information) to another human being, we must communicate successfully, without blaming those who are trying to understand us for any failure of that communication. If an audience of willing participants does not understand our communication, we are ill served if we assume it is caused by the audience's innate inability to receive communication. If we were to assume that all healthcare professionals were too stupid to understand our failed communication attempts, that opinionated assumption would likely be wrong.
Even if an audience's inability to comprehend a presentation was to blame for a failed communication attempt, under no circumstance does the responsibility for receiving that information rely on the recipient—the successful exchange of information is almost always dependent on the person who submits the information; such is the nature of willingness.
For example, if participants are willing, but information is submitted in a foreign language, then chances for successful information transfer are not very great—and that willingness is lost—obfuscated by the necessity for recipients to learn a new language. Therefore, if we are cultivating a system that is based on the willing and peaceful participation that is inherent to healthcare as a profession, then we must not require end users to do anything, or conform in any way.
Moreover, one fact remains about the class of end users that we have assigned the label Healthcare Professionals (or other) that comprises doctors, nurses, respiratory therapists, and the like—they are varied.
In fact, not only do the individuals vary from one another as proven by their names and titles—their job descriptions vary widely; no singular job description entitled "healthcare professional" actually exists. Doctors have completely different job descriptions than do nurses; respiratory therapists have completely different job descriptions than do dentists, and so on. Job descriptions (comprising tasks) vary from field to field.
Furthermore, even individuals themselves differ from one another within their individual practices within their individual fields.
How ludicrous to assume that one questionnaire to hold all pertinent questions would suffice to address every individual who communicates in every language all the time. That one questionnaire to supposedly contain all healthcare practice would be so immense that no one could ever use it.
Therefore, guidelines to conduct a study of end-users within the field of healthcare (for the purpose of creating a user-centered healthcare electronic information system), must effectively submit different questions to different individuals.
Even if an audience's inability to comprehend a presentation was to blame for a failed communication attempt, under no circumstance does the responsibility for receiving that information rely on the recipient—the successful exchange of information is almost always dependent on the person who submits the information; such is the nature of willingness.
For example, if participants are willing, but information is submitted in a foreign language, then chances for successful information transfer are not very great—and that willingness is lost—obfuscated by the necessity for recipients to learn a new language. Therefore, if we are cultivating a system that is based on the willing and peaceful participation that is inherent to healthcare as a profession, then we must not require end users to do anything, or conform in any way.
Moreover, one fact remains about the class of end users that we have assigned the label Healthcare Professionals (or other) that comprises doctors, nurses, respiratory therapists, and the like—they are varied.
In fact, not only do the individuals vary from one another as proven by their names and titles—their job descriptions vary widely; no singular job description entitled "healthcare professional" actually exists. Doctors have completely different job descriptions than do nurses; respiratory therapists have completely different job descriptions than do dentists, and so on. Job descriptions (comprising tasks) vary from field to field.
Furthermore, even individuals themselves differ from one another within their individual practices within their individual fields.
How ludicrous to assume that one questionnaire to hold all pertinent questions would suffice to address every individual who communicates in every language all the time. That one questionnaire to supposedly contain all healthcare practice would be so immense that no one could ever use it.
Therefore, guidelines to conduct a study of end-users within the field of healthcare (for the purpose of creating a user-centered healthcare electronic information system), must effectively submit different questions to different individuals.
Thursday, April 1, 2010
#9. So Far, So Good...
So far, we have tentatively established a bare slate on which to record initial information regarding end-use. We now have a database table that holds classes entitled Healthcare and Crisis; within the Healthcare class are the classes Healthcare Professionals, Work, and Patients/Recipients, with the Work class between the two classes of humans. Each class of humans can now be further differentiated.
We researchers can either laboriously fill in these blanks ourselves, or we can allow the users to fill out their own data. (Either way, this is accomplished by a method called instantiation.)
However, the task of filling out all possible fields for all possible healthcare professionals, all possible work, and all possible patients might get too large for us to do by ourselves. Therefore, we must allow the healthcare professionals to fill out their own data, since healthcare professionals are the entities who, in reality, not only create instances for themselves, they know their work, and they also create the instances for the patients—whenever these patients show up for treatment.
Therefore, the format for the study of end-use has been established: End-users (healthcare professionals) will be allowed to submit information onto the fields that we provide. An end-user's willingness to participate in this study is all that is needed. (Confidentiality and security can be considered later.)
The computer is ready to receive the information, but the human end-users have neither incentive, ability, nor understanding of our goals and objectives; the interface is still undefined. If our mission is to create user-centered software, thereby rendering "friendly" usability of the healthcare informatics system, we need to do exactly that by translating the computer's mission to those who are using it—we do not force healthcare workers to learn a database application—or any other kind of application.
Moreover, since healthcare professionals are those who are experts in their own jobs, we must allow them to easily amend the system that we provide for them as we study them. If our mission is to study the end-use of healthcare professionals so that we can design a user-friendly informatics system for them so that they can more easily accomplish their work, we must make it our priority to provide flexible service to each willing healthcare professional—as they, themselves, define their own study criteria.
By allowing healthcare professionals to change the very structure of our study to better describe their own work, we can better describe the work that they perform. At no time do we tell brain surgeons, or any other professionals, how to do their jobs; this is true as we study healthcare user scenarios, or any other time. This ability for healthcare professionals to amend their own work descriptions must be preconceived and hard-coded into the system.
The job of treating patients is difficult enough without adding to the difficulty of fumbling through a new piece of software. We need to cater to them, not visa versa. So, we, ourselves, need to be flexible in our presentation to these professionals.
We researchers can either laboriously fill in these blanks ourselves, or we can allow the users to fill out their own data. (Either way, this is accomplished by a method called instantiation.)
However, the task of filling out all possible fields for all possible healthcare professionals, all possible work, and all possible patients might get too large for us to do by ourselves. Therefore, we must allow the healthcare professionals to fill out their own data, since healthcare professionals are the entities who, in reality, not only create instances for themselves, they know their work, and they also create the instances for the patients—whenever these patients show up for treatment.
Therefore, the format for the study of end-use has been established: End-users (healthcare professionals) will be allowed to submit information onto the fields that we provide. An end-user's willingness to participate in this study is all that is needed. (Confidentiality and security can be considered later.)
The computer is ready to receive the information, but the human end-users have neither incentive, ability, nor understanding of our goals and objectives; the interface is still undefined. If our mission is to create user-centered software, thereby rendering "friendly" usability of the healthcare informatics system, we need to do exactly that by translating the computer's mission to those who are using it—we do not force healthcare workers to learn a database application—or any other kind of application.
Moreover, since healthcare professionals are those who are experts in their own jobs, we must allow them to easily amend the system that we provide for them as we study them. If our mission is to study the end-use of healthcare professionals so that we can design a user-friendly informatics system for them so that they can more easily accomplish their work, we must make it our priority to provide flexible service to each willing healthcare professional—as they, themselves, define their own study criteria.
By allowing healthcare professionals to change the very structure of our study to better describe their own work, we can better describe the work that they perform. At no time do we tell brain surgeons, or any other professionals, how to do their jobs; this is true as we study healthcare user scenarios, or any other time. This ability for healthcare professionals to amend their own work descriptions must be preconceived and hard-coded into the system.
The job of treating patients is difficult enough without adding to the difficulty of fumbling through a new piece of software. We need to cater to them, not visa versa. So, we, ourselves, need to be flexible in our presentation to these professionals.
Wednesday, March 31, 2010
#8. Inside These Classes.
Three classes that describe Healthcare have been established: (Healthcare Professionals), (Work) and (Patients); these classes will contain the information that will be compiled to render end-user criteria upon which to build a user-centered healthcare informatics system.
Researchers can record the research into these classes onto a napkin, or even in a spreadsheet—however, we should give ourselves lots of room to expand and explore. Therefore, let's begin by recording the information that we attain from end-users into a database.
We know that this information will be stored within the aforementioned three containers, but the containers should not limit the need to expand the data held within. Therefore, we will setup three scalable database structures that retain information, and will not limit the potential to interact with one another later on.
This first class, (Healthcare Professionals), comprising doctors, nurses, respiratory therapists, and the like, must posses the ability to hold pertinent instantiated information regarding individuals who administer the healthcare. The third class, (Patients), will hold instantiated information regarding individuals who receive the care; this information is the patients' records. (Instantiation within these classes manifests as mere attributes to their objects, like adjectives describe their nouns.)
However, the interaction between these two classes—the class entitled (Work)—requires a bit more investigation. Describing (Work) for the purpose of user-centered design of healthcare informatics deserves more than simple analysis.
(Work) is an action (called a method in computer languages, a verb in human languages). Actions apply to objects as proven by their final state, minus their initial state. In other words, objects remain in one location, unless they are subject to Work, whereby they demonstrate a different final state.
For example, when a surgeon makes an incision, a scalpel is moved along an individual patient at precisely the correct anatomical landmark until it stops moving. The result of this incision can be called a Task. It will have been preceded by other tasks (possibly the work of other collaborators)—such as scrubbing or prepping—and followed by still other tasks—such as suctioning and suturing. These tasks all fit into a Task Flow that describes the sequence of tasks that individuals make as they treat their patients.
Therefore, we have developed an equation to accurately capture and discover data upon which to build a healthcare informatics system based upon actual clinical practice. This equation of a string of written-language variables may look something akin to the following:
(Healthcare Professionals) • (Work) • (Patients)
=
(individualIdentifier • department • subWorkClass • workClass)
•
(action • object1 • conjuction1 • object2 • conjuction2)
•
(predicate)
or
Respiratory Therapy Certified Respiratory Therapists Nebulize Medications With Nebulizers To Patients.
To those who work in the field of healthcare, the above string of variables submitted into the data structure may be recognizable as a routine task. This task can now be understood both by humans and by computers alike.
Therefore, we have successfully analyzed three classes that describe Healthcare: (Healthcare Professionals), (Work) and (Patients); these classes will contain the information that will be compiled to give us the end-user criteria upon which to build a user-centered healthcare informatics system.
Next, since end-users must still interact with their computers to submit information to be studied, we must further investigate human/computer communication techniques.
Researchers can record the research into these classes onto a napkin, or even in a spreadsheet—however, we should give ourselves lots of room to expand and explore. Therefore, let's begin by recording the information that we attain from end-users into a database.
We know that this information will be stored within the aforementioned three containers, but the containers should not limit the need to expand the data held within. Therefore, we will setup three scalable database structures that retain information, and will not limit the potential to interact with one another later on.
This first class, (Healthcare Professionals), comprising doctors, nurses, respiratory therapists, and the like, must posses the ability to hold pertinent instantiated information regarding individuals who administer the healthcare. The third class, (Patients), will hold instantiated information regarding individuals who receive the care; this information is the patients' records. (Instantiation within these classes manifests as mere attributes to their objects, like adjectives describe their nouns.)
However, the interaction between these two classes—the class entitled (Work)—requires a bit more investigation. Describing (Work) for the purpose of user-centered design of healthcare informatics deserves more than simple analysis.
(Work) is an action (called a method in computer languages, a verb in human languages). Actions apply to objects as proven by their final state, minus their initial state. In other words, objects remain in one location, unless they are subject to Work, whereby they demonstrate a different final state.
For example, when a surgeon makes an incision, a scalpel is moved along an individual patient at precisely the correct anatomical landmark until it stops moving. The result of this incision can be called a Task. It will have been preceded by other tasks (possibly the work of other collaborators)—such as scrubbing or prepping—and followed by still other tasks—such as suctioning and suturing. These tasks all fit into a Task Flow that describes the sequence of tasks that individuals make as they treat their patients.
Therefore, we have developed an equation to accurately capture and discover data upon which to build a healthcare informatics system based upon actual clinical practice. This equation of a string of written-language variables may look something akin to the following:
(Healthcare Professionals) • (Work) • (Patients)
=
(individualIdentifier • department • subWorkClass • workClass)
•
(action • object1 • conjuction1 • object2 • conjuction2)
•
(predicate)
or
Respiratory Therapy Certified Respiratory Therapists Nebulize Medications With Nebulizers To Patients.
To those who work in the field of healthcare, the above string of variables submitted into the data structure may be recognizable as a routine task. This task can now be understood both by humans and by computers alike.
Therefore, we have successfully analyzed three classes that describe Healthcare: (Healthcare Professionals), (Work) and (Patients); these classes will contain the information that will be compiled to give us the end-user criteria upon which to build a user-centered healthcare informatics system.
Next, since end-users must still interact with their computers to submit information to be studied, we must further investigate human/computer communication techniques.
#7. This Thing Called "Healthcare".
So let's find out if Healthcare = 1/Crisis.
Again, we do not force any solution, but further breakdown our terms into their lowest common denominators so that we can arrive at an accurate, reproducible, scientific solution.
To do this we first investigate the term Healthcare to determine exactly what Healthcare is, in objective terms—that all (or most) can agree on.
Almost all can agree that healthcare is given by a person and received by a person (although those two classes are not limited by "people", since some may see that veterinarians also provide healthcare; nevertheless, let's continue).
Therefore, two classes of individuals exist within the definition of Healthcare: Those Healthcare Professionals who give Healthcare, and those Patients who receive it. Those who give healthcare comprise, doctors, nurses, dentists, respiratory therapists, Certified Nurse Assistants, and others. Those who receive healthcare comprise patients, unless otherwise added to the class.
Moreover, a transaction takes place between these two individual classes; we can call this transaction Work.
Therefore,
(Healthcare Professionals) • (Work) • (Patients) = 1/Crisis
This exploded view of the problem set starts to look more like variables that a computer might be able to compile.
(I will not investigate the term Crisis so that it fits into the equation—that mission can be your job, should you decide to accept it.)
Again, we do not force any solution, but further breakdown our terms into their lowest common denominators so that we can arrive at an accurate, reproducible, scientific solution.
To do this we first investigate the term Healthcare to determine exactly what Healthcare is, in objective terms—that all (or most) can agree on.
Almost all can agree that healthcare is given by a person and received by a person (although those two classes are not limited by "people", since some may see that veterinarians also provide healthcare; nevertheless, let's continue).
Therefore, two classes of individuals exist within the definition of Healthcare: Those Healthcare Professionals who give Healthcare, and those Patients who receive it. Those who give healthcare comprise, doctors, nurses, dentists, respiratory therapists, Certified Nurse Assistants, and others. Those who receive healthcare comprise patients, unless otherwise added to the class.
Moreover, a transaction takes place between these two individual classes; we can call this transaction Work.
Therefore,
(Healthcare Professionals) • (Work) • (Patients) = 1/Crisis
This exploded view of the problem set starts to look more like variables that a computer might be able to compile.
(I will not investigate the term Crisis so that it fits into the equation—that mission can be your job, should you decide to accept it.)
#6. The Science of Healthcare Crisis.
Now this step requires a leap of faith, so humor me for a moment.
We have determined that the term Healthcare Crisis is meaningful to humans, since it is the basis for the creation of Healthcare Reform solutions by humans (which implies that Healthcare Crisis must be a problem for some), but that the term itself is subjective and worthless to a computer. Since we are dealing with human/computer interaction—and the computer's ability is limited by the people who create it, we must find common ground between the human end-users, and the tool that is the computer system.
So, if the term Healthcare Crisis is subjective and we need objectivity, we borrow an object.
Therefore:
Healthcare Crisis = 1
There.
We have successfully objectified the term, and haven't hurt anyone in the process.
Next, we proceed to isolate these terms:
Healthcare = 1/Crisis
We see that Healthcare is the reciprocal of Crisis
This statement implies that as Healthcare increases, Crisis decreases, and visa versa. This can actually mean many things, but is it true?
I claim it is.
However, you may claim this to be absolute malarkey—therefore, those two opposing opinions still remain to be proven right or wrong by virtue of the fact that they are merely opinions without a factual evidence base.
Therefore, the basis for our research project has been established—entirely on a leap of faith and the willingness to further investigate that which is the foundation for science itself.
We have determined that the term Healthcare Crisis is meaningful to humans, since it is the basis for the creation of Healthcare Reform solutions by humans (which implies that Healthcare Crisis must be a problem for some), but that the term itself is subjective and worthless to a computer. Since we are dealing with human/computer interaction—and the computer's ability is limited by the people who create it, we must find common ground between the human end-users, and the tool that is the computer system.
So, if the term Healthcare Crisis is subjective and we need objectivity, we borrow an object.
Therefore:
Healthcare Crisis = 1
There.
We have successfully objectified the term, and haven't hurt anyone in the process.
Next, we proceed to isolate these terms:
Healthcare = 1/Crisis
We see that Healthcare is the reciprocal of Crisis
This statement implies that as Healthcare increases, Crisis decreases, and visa versa. This can actually mean many things, but is it true?
I claim it is.
However, you may claim this to be absolute malarkey—therefore, those two opposing opinions still remain to be proven right or wrong by virtue of the fact that they are merely opinions without a factual evidence base.
Therefore, the basis for our research project has been established—entirely on a leap of faith and the willingness to further investigate that which is the foundation for science itself.
#5. Organization, or Confusion, Starts At The Top.
Much recent press has been given to the subjective terms healthcare debate, healthcare crisis, and healthcare reform; nevertheless, we need data that can be input to a computer, not a ballot box.
Although we have not yet established what we will be studying, we do know that organization of research follows a format. That format first finds a Goal, then finds Objectives, Tasks within those objectives, and a Task Flow—a series in which the tasks follow to meet their objectives. (We can develop this organization further as we progress through this logic.) Therefore, we know that whatever we do, our research will follow a format that fits into the guidelines that follow the overall Goal.
Furthermore, we earlier claimed that we are concerned with the problem (not the solution) of the Healthcare Crisis—and determined that the term was subjective, means different things to different people, and some even claim that no crisis exists at all.
Therefore, we have found an opinion.
Opinions spur research into the facts.
So, let's get started defining Healthcare Crisis in objective terms that a computer can compile; we can employ the following method, although other ways to achieve this Goal may coexist. (Please bear with me on this one—this may not seem relevant at the moment, so you will have to trust me for now.)
Although we have not yet established what we will be studying, we do know that organization of research follows a format. That format first finds a Goal, then finds Objectives, Tasks within those objectives, and a Task Flow—a series in which the tasks follow to meet their objectives. (We can develop this organization further as we progress through this logic.) Therefore, we know that whatever we do, our research will follow a format that fits into the guidelines that follow the overall Goal.
Furthermore, we earlier claimed that we are concerned with the problem (not the solution) of the Healthcare Crisis—and determined that the term was subjective, means different things to different people, and some even claim that no crisis exists at all.
Therefore, we have found an opinion.
Opinions spur research into the facts.
So, let's get started defining Healthcare Crisis in objective terms that a computer can compile; we can employ the following method, although other ways to achieve this Goal may coexist. (Please bear with me on this one—this may not seem relevant at the moment, so you will have to trust me for now.)
#4. Problem Identification. Not Solution Identification.
Albert Einstein is attributed with stating that A perfection of means, and confusion of aims, seems to be our main problem. If you agree, then you will also agree that we must accurately describe our problem in the most accurate of terms, instead of forcing a solution without an evidence-base, thereby running a risk that we force a solution that may not be agreeable to everyone.
Moreover, since we are dealing with a computer that compiles input into output, we must be unbiased and accurate about our input terms if we are to reap the benefits of an accurate, unbiased output of user-data upon which to base user-centered healthcare informatics design critia.
So, we are faced with the problem of accurately describing the problem: This is where most people drop out.
Therefore, our scientific research will begin with identifying the problem of healthcare crisis, rather than focusing on the solution of healthcare reform.
Moreover, since we are dealing with a computer that compiles input into output, we must be unbiased and accurate about our input terms if we are to reap the benefits of an accurate, unbiased output of user-data upon which to base user-centered healthcare informatics design critia.
So, we are faced with the problem of accurately describing the problem: This is where most people drop out.
Therefore, our scientific research will begin with identifying the problem of healthcare crisis, rather than focusing on the solution of healthcare reform.
#3. Science Is Not An Opinion.
If political opinions support at least two sides, scientific facts do not. In fact, when an opinion presents in a field of science, that opinion can only exist as an opportunity to further investigate subsequent facts, since the factual answers to these questions almost always give rise to even more questions. These questions that develop as the result of knowledge attained is often referred to as the scientific method. Only one omnipresent scientific method is known to exist; however many varied opinions coexist, especially in politics.
Therefore, when creating a scientific user-centered healthcare informatics system, we will be interested in researching and publishing factual information, while simultaneously employing the existence of any identified opinion as an opportunity to further research.
Therefore, when creating a scientific user-centered healthcare informatics system, we will be interested in researching and publishing factual information, while simultaneously employing the existence of any identified opinion as an opportunity to further research.
#2 Human Behavior: The Object/Subject of Study
If we are to study humans to build a computer system that serves their behavior, it is their behavior that we must study. Studying human behavior—their actions—is the basis for usability science, since usability implies "use"—an action. Those who do not use the information system are neither qualified to be studied, nor to invoke their untested solutions onto those who are—in this case, doctors, nurses, allied professionals, and the like.
Nevertheless, clearly most doctors, nurses, and allied professionals are not qualified to design a computerized informatics system, at least one that is based on their personal needs, devoid of their biased wants.
Therefore, we must study the actions of the individuals who submit care to others so that we can cater to their needs. We will not be concerned with criteria other than those actions, and those dynamic needs.
As a side note: Some of you may be programmers skilled in object-oriented languages, such as Ruby. For the purpose of this study these languages may be best employed if methods are prioritized over their objects, not visa versa; the point may seem moot, and theoretical to some, but you may come to agree with the point as it develops. For now, I will just mention it.
We can now continue to setup our study of human behavior, beginning with the broadest possible scope, and ending with study of the minutia of human behavior.
Nevertheless, clearly most doctors, nurses, and allied professionals are not qualified to design a computerized informatics system, at least one that is based on their personal needs, devoid of their biased wants.
Therefore, we must study the actions of the individuals who submit care to others so that we can cater to their needs. We will not be concerned with criteria other than those actions, and those dynamic needs.
As a side note: Some of you may be programmers skilled in object-oriented languages, such as Ruby. For the purpose of this study these languages may be best employed if methods are prioritized over their objects, not visa versa; the point may seem moot, and theoretical to some, but you may come to agree with the point as it develops. For now, I will just mention it.
We can now continue to setup our study of human behavior, beginning with the broadest possible scope, and ending with study of the minutia of human behavior.
#1. Computers Will Do Anything You Program Them To Do
The constraint of any computerized information system is that of the humans, not of the computers. Computers are merely the tools of humans, not visa-versa. Therefore, we must deduct that to design a world-classed healthcare informatics system to best serve the needs of healthcare (and thereby, humanity) we must first study the constraints of the humans, not the constraints of the computers.
All logic can be programmed into a computer; "it will never work" is not possible. However, the humans who program logic into computers must first have the logic that renders a logical system. Therefore, the first objective to creating a logical healthcare information management system is to provide accurate guidelines to those who design and develop these systems.
If a systematic method to accurately study that which renders logical guidelines for healthcare informatics systems is to be established—we need to setup the study, and that which renders guidelines for healthcare informatics systems is the study of the humans involved with the system; we need only rudimentary knowledge of computers.
All logic can be programmed into a computer; "it will never work" is not possible. However, the humans who program logic into computers must first have the logic that renders a logical system. Therefore, the first objective to creating a logical healthcare information management system is to provide accurate guidelines to those who design and develop these systems.
If a systematic method to accurately study that which renders logical guidelines for healthcare informatics systems is to be established—we need to setup the study, and that which renders guidelines for healthcare informatics systems is the study of the humans involved with the system; we need only rudimentary knowledge of computers.
Welcome To User-Centered Design for Healthcare Informatics
The purpose of this blog is to present a forum to exchange information regarding the design and development of a science-based, user-centered healthcare informatics system that is free from political constraints. This blog is to share information for the betterment of healthcare informatics, to cross-pollinate ideas, and to establish a forum of willing participants to create an information structure to serve humanity, to better the healthcare environment, and to advance the human experience in general.
This blog is not allied with any government, corporation, political party, or political ideology, has no opinions on outside issues—it's sole purpose is to provide scientific information to those who desire to offer an efficient human-computer experience to people who care for others.
Subscribe to:
Posts (Atom)
