Care Coordination and EMR Workflow Systems: Key Ideas

Short Link:

As the phrase “clinical groupware” gains currency [UPDATE: well, it gained and then lost that, but what it means is just as important today!], it’s worth considering the history of groupware in general, and workflow in particular, to understand the relationship between EMR workflow systems and clinical groupware. This relationship is at the technological heart of the care coordination problem.

Workflow systems are a form of groupware, and EMR workflow systems are a form of clinical groupware. Jonathan Grudin, in a 1994 Communications of the Association for Computing Machinery article (second most cited for “groupware” in Google Scholar) wrote:

“Desktop conferencing, videoconferencing, co-authoring features and applications, electronic mail and bulletin boards, meeting support systems, voice applications, workflow systems, and group calendars are key examples of groupware.” (Groupware and Social Dynamics: Eight Challenges for Developers, 1994, my emphasis)

Last week I described the landmark 2000 HIMSS presentation and proceedings paper about a workflow-based clinical groupware system installed in ten pediatric practices and one family medicine practice. In it I quoted from two early (1988 and 1992) collections of readings about groupware. I found so much relevant material that I collated, annotated, and published it (see below) so it can become part of a larger conversation about clinical groupware. I’ll refer to this material in future posts.


 From My Bookshelf

Year Origins of Groupware My Comments
"The term groupware was coined by Peter and Trudy Johnson-Lenz…as follows: “GROUPWARE= intentional GROUP processes and procedures to achieve specific purposes + softWARE tools designed to support and facilitate the group’s work” I used this definition of groupware in my previous post Ten Years Ago, Dallas HIMSS: Landmark Presentation on Modular Pediatric EMR Workflow Groupware. "Groupware" was apparently coined even earlier, in 1978.

See it applied to a pediatric office.

1988 "A new class of commercial software has been named “groupware.” It is software designed to take group work into account in an integral way. Groupware products...have in common that they put coordination technology into the hands of the group members, giving them access to the positive aspects of coordination—not just preventing collisions, but enabling collaboration. Groupware will be made commonplace, by the evolving understanding of what the key coordination technologies are, how they should appear to end-users, and what the software libraries are that embody this understanding." Four posts about EMR workflow systems and care coordination:

The High-Performance Medical Home and Pediatric and Primary Care EMR Workflow Systems: Key Ideas

Workflow-Related Interoperability Requirements for the High-Performance Pediatric Medical Home

Well Understood, Consistently Executed, Adaptively Resilient, and Systematically Improvable Pediatric and Primary Care EMR Workflow

Why Pediatricians Need Pediatric EMRs That Understand More Than Pediatrics

1992 "Computer-supported cooperative computer-assisted coordinated activity such as problem solving and communication carried out by a group of collaborating individuals. The multi-user software supporting CSCW systems is known as groupware" "Computer-Supported Cooperative Work" and "CSCW" do not role off the tongue like "groupware." (4440 hits (2/2/10) in Google versus 63700 hits). Groupware is the software. CSCW is the combined system of software and people.
1988 "Groupware is distinguished from normal software by the basic assumption it makes: groupware makes the user aware that he is part of a group, while most other software seeks to hide and protect users from each other…Groupware…is software that accentuates the multiple user environment, coordinating and orchestrating things so that users can ‘see’ each other, yet do not conflict with each other" EncounterPRO Pediatric EMR "users can ‘see’ each other" in the Office View ("radar view" to usability engineers)

Task colors correspond to users and roles.

1988 "All software will be groupware" Most will be. All EMR software will include clinical groupware functionality.
Groupware Usability Clinical Groupware Usability
1988 "The Human Factors in Computing community has a...challenge [to] find ways to test and evaluate technological impacts on groups. It’s difficult enough to get meaningful results that take into account differences in experience and individual differences of users to their reactions to user interfaces. But at least it’s possible to get volunteers to sit down with word processing systems and spreadsheet programs for relatively self-contained tasks. It is more difficult to “stage” a realistic group-work setting in a lab and have volunteers use the system in a way that provides meaningful data. Methodologies for testing individual user interfaces don’t apply as well to group support systems. As a result, CSCW is looking more to anthropology to find methodologies for studying groups at work in their natural settings." We need new conceptual models to even think about clinical groupware usability. Previously I wrote:

Usability is “the effectiveness, efficiency, and satisfaction with which specified users achieve specified goals in particular environments. [ISO 9241]” However, in the case of pediatric EMR workflow systems, usability must be construed not only relative to single users, but also with respect to the entire team of patients, pediatricians, and pediatric staff who work together for common goals. One might rephrase this definition of usability to become the effectiveness, efficiency, and satisfaction with which teams of users achieve collections of goals in complex social environments". (Pediatric EMR Usability: Natural, Consistent, Relevant, Supportive, Flexible Workflow)

1991 "Until recently, most user interface research has focused on single-user systems. Groupware challenges researchers to broaden this perspective, to address the issues of human-user interaction with the context of multiuser or *group* interfaces. Since these interfaces are sensitive to such factors as group dynamics and organizational structure—factors not normally considered relevant to user interface design—it is vital that social scientists and end users play a role in the development of group interfaces." "Similarities between a medical team and a football team are more than an amusing analogy. All teams are cognitive systems, and their study is called team cognition (with contributions from distributed cognition). Shared mental models, workspace awareness, radar views, and teams of experts versus expert teams are topics of team cognition that apply to all teams, including those in medicine and football." (Football Plays and EHR Workflow Congratulations Saints for their 2010 Super Bowl win!)
1990 "Evaluating groupware 'in the field' is remarkably complex because of the number of people to observe at each site, the wide variability of group composition, and the range of environmental factors that play roles in determining acceptance" "It is the entire system of patients, parents, guardians, pediatricians, pediatric subspecialists, non-pediatric primary care physicians, physician assistants, nurses, staff, acute and subacute participants in all the workflows and processes of child health that needs to be optimized. [T]here is no guarantee that optimizing single user usability won’t in suboptimize higher level global system goals. So I prefer a definition of usability that emphasizes team, rather than individual, performance." (The Cognitive Science Behind Pediatric EMR Usability Checklists)
1990 "Five factors contributing to groupware failure…:
  1. Groupware applications often fail because they require that some people do additional work, and those people are not the ones who perceive a direct benefit from the use of the applications.
  2. Groupware may lead to activity that violates social taboos, threatens existing political structures, or otherwise demotivates users who are crucial to its success.
  3. Groupware may fail if it does not allow for a wide range of exception handling and improvisation that characterizes much group activity.
  4. We fail to learn from experience because these complex applications introduce insurmountable obstacles to meaningful, generalizable analysis and evaluation.
  5. The groupware development process fails because our intuitions are especially poor for multiuser applications."
Grudin provided five reasons why groupware fails in 1990 and expanded it to eight challenges in 1994. The list stands up well; here it is used in a 2008 Ph.D. thesis. "Groupware" was not just coined and discussed before the Web existed, but the difficulties of getting groupware right were understood in ways that still apply today. The same challenges that Grudin listed in 1990 and 1994 also apply to successful clinical groupware today.

Grudin’s Eight Challenges for (Clinical) Groupware Developers

  1. Disparity of work and benefit
  2. Critical mass and prisoner's dilemma
  3. Disruption of social processes
  4. Exception handling
  5. Unobtrusive accessibility
  6. Difficulty of evaluation
  7. Failure of intuition
  8. The adoption process

(In Knowledge Management Systems and Customer Knowledge Use in Organizations, 2008, Ph.D. Thesis)

1991 "Distributed Cognition takes as its unit of analysis a complex cognitive system: collections of individuals and artifacts that participate in the performance of a task. The external structures exchanged by agents of complex cognitive systems comprise its “mental” state and unlike individual cognition, where mental states are inaccessible, these states are observable and available for direct analysis." Distributed clinical cognition requires distributed clinical information design. From my 2004 TEPR proceedings paper EHR Workflow Management Systems: Essentials, History, Healthcare (also see my post on interruptions): "Human-Centered Distributed Information Design...distinguishes four levels of distributed analysis: user, function, task, and representation, which correspond well to workflow management architectural distinctions."
"The Coordination Problem" The Care Coordination Problem
1991 "The coordination problem is the 'integration and harmonious adjustment of individual work efforts toward the accomplishment of a larger goal'...Coordination systems address this problem in a variety of ways. Typically these systems allow individuals to view their actions, as well as the relevant actions of others, within the context of the overall goal. Systems may also trigger users’ actions by informing users of the states of their actions and their wait conditions, or by generating automatic reminders and alerts" On the EncounterPRO Pediatric EMR Workflow System ("Clinical Groupware for Pediatric Practice") product website:

“The simple capacity to connect and communicate data is insufficient. You need to connect, communicate, and coordinate. EMR workflow systems are all about coordination. Workflow engines execute process definitions in order to coordinate the accomplishment of tasks.” (EncounterPRO Pediatric EMR Workflow System care coordination vision)

1990 "We define coordination theory as a body of principles about how activities can be coordinated, that is, about how actors can work together harmoniously...In coordination theory, the common problems have to do with coordination: How can overall goals be subdivided into activities? How can actions be assigned to groups or to individual actors. How can resources be allocated among different actors? How can information be shared among different actors to help achieve the overall goals?"

[CW: See related quotes from The Interdisciplinary Study of Coordination and Making Care Coordination a Critical Component of the Pediatric Health System: A Multidisciplinary Framework (where "coordination" occurs 256 times)]

"EMR BPM suites [Business Process Management/EMR workflow systems plus BPM modules] coordinate clinical tasks and synchronize clinical data across existing pediatric, pediatric subspecialty, and non-pediatric primary care EMRs. They also help coordinate clinical activities, streamlining clinical tasks, triggers, and timelines related to a care coordination process, and assuring they are completed as defined by a care coordination process model. An EHR BPM suite makes care coordination processes more efficient, agile, and visible by ensuring that every care coordination process step is explicitly defined, monitored over time, and optimized for maximum productivity." (Well Understood, Consistently Executed, Adaptively Resilient, and Systematically Improvable Pediatric and Primary Care EMR Workflow)
1990 "Narrow definition of coordination: the act of managing interdependencies between activities performed to achieve a goal" The following quotes, from a treatise on coordination (next row, left), the other from a paper about workflow-based clinical groupware for pediatric practice (next row, right), show that EMR workflow systems are coordination systems.
1990 Numbers in brackets ([1-4]) map between equivalent concepts in the quote to the left (written in 1990 about solving the "coordination problem") and the quote on the right (written ten years later about workflow-based clinical groupware that solved the care coordination problem within ten pediatric practices).

"Components of coordination and associated coordination processes:

  • Goals [1]
    Identifying goals
  • Activities [2]
    Mapping goals to activities (e.g. goal decomposition)
  • Actors [3]
    Selecting actors, Assigning activities to actors
  • Interdependencies [4]
    Managing interdependencies"

[CW: This quote is not specifically about care coordination. However, it surely applies to the care coordination problem. To the degree that workflow systems address the coordination problem, clinical groupware workflow systems address the care coordination problem.]

"A workflow system is a complex, dynamic assemblage of:

  • Tasks—These are activities [2] that must be completed in order to achieve a business goal [1]. The CPR in this study has a task-based orientation.
  • Actors [3]—Tasks are performed in a specific order by specific actors (that is, receptionists, nurses, physicians) based on business roles.
  • Roles—Roles are defined independent of the actors or the processes that fill that role. For example, the CPR defines a nurse’s role as different from a physician’s role in the ambulatory care office.
  • Processes—Processes are the sequences of tasks to be performed based on business conditions [4]"

(Ten Years Ago, Dallas HIMSS: Landmark Presentation on Modular Pediatric EMR Workflow Groupware)

Processes, as described in this quote, clearly are about managing interdependencies [4] (task performance based on conditions).

Informal & Unstructured vs. Formal & Structured Coordination Informal & Unstructured vs. Formal & Structured Care Coordination
1991 "Cooperative problems can be thought of as existing at some point on a spectrum ranging from unstructured problems at one end to prescriptive tasks at the other. Unstructured problems are those requiring creative input from a number of users which often cannot be detailed or described in advance...Prescriptive tasks, on the other hand, represent the routine procedural cooperative mechanisms used to solve problems which have existing group solutions. Prescriptive tasks respond well to detailed control of cooperation while unstructured problems require a significant degree of freedom to be exercised by the cooperative system." I was privileged to audit classes taught by Herbert Simon, the Nobel prize-winning economist, cognitive scientist, and artificial intelligence researcher. (BTW, he graduated from my alma mater, the University of Chicago).

I came to cognitive science and medical informatics from Industrial Engineering (including operations research), which emphasized what Simon called "well structured" problems. He had written "Operations research has demonstrated its effectiveness in dealing with the kinds of management problems that we might call 'well structured,' but it has left pretty much untouched the remaining, 'ill structured,' problems."

1995 "Groupware systems can be separated into two very broad categories:
  • Informal and creative interactions to encourage group communication: ...Informal interactions do not mean there are no goals or deliverables. The implication is the lack of rigid structures and requirements in accomplishing the task or deliverables.
  • Products and systems that have strict structures, policies, and procedures: These enhance the communication and delivery procedures but making sure all intermediate steps are accomplished and all constraints are satisfied."
Clinical groupware applications also exist along a spectrum from ill-structured cooperative problem solving (requiring unpredictable group input) to well-structured cooperative problem solving (amenable to workflow engines executing process definitions). While EMR workflow systems are closer to the well-structured end of this spectrum, the EncounterPRO Pediatric EMR handles both routine and non-routine pediatric workflows well (see next comment below).
Workflow Systems are Groupware EMR Workflow Systems are Clinical Groupware
1995 "Some people infer antithesis between the formal policy orientation of workflow and the informal collaborations of groupware....Although groupware is associated with systems that encourage and nurture information group interactions, there are groupware systems that encourage and enforce more formal interactions between team members: for example, shared calendars or scheduling systems.... really just another type of groupware" This perceived "antithesis" is due to lack of appreciation of the spectrum between well-structured and ill-structured cooperative problem solving and the kinds of groupware needed to facilitate computer-supported cooperative work in healthcare. Both kinds of cooperative problem solving require clinical groupware. EMR workflow systems fare especially well on well-structured care coordination problems. The EncounterPRO Pediatric EMR handles both ends of the spectrum well: a workflow engine to handle routine group workflows and the Office View to handle non-routine group workflows.
1995 "Workflow is one of the hottest areas in groupware today...Workflow is often explained with the analogy of the factory floor. In America, manufacturing made great strides in productivity during the late ‘80s and early ‘90s, mostly due to automation. Now, visionaries want to take the automated processes of the factory floor and apply them to the office." This was written in 1995, which shows how far behind the healthcare industry is in adopting groupware and workflow systems. Patients aren't widgets and pediatric offices aren't factory lines. However, many of the same industrial engineering techniques that helped increase manufacturing productivity can also be applied to pediatric and primary care. To "bend the cost curve" healthcare needs to make similar "great strides in productivity" (Though, to be fair and balanced, please read the late great William Safire on bending the cost curve).
1995 "In groupware technologies, workflow systems constitute some of the most powerful environments that enable collaborative computations to automate workflow processes" Adapted to healthcare: In clinical groupware technologies, EMR workflow systems constitute some of the most powerful environments that enable collaborative computations to automate clinical workflow processes.

It is fitting to close this litany of groupware, coordination, and workflow quotes and comments with one more wrinkle, what Frisse, Schnase, and Metcalfe call “The Problem of Language: The efforts to integrate information from disparate sources into a single, unified, computer-based patient record are challenged more by the enormous range of human expression than by technology” (Models of Patient Records,1994). Using the phrase “medical groupware,” not “clinical groupware”, they eloquently describe the importance of medical “conversation” to clinical groupware (see my earlier posts on syntactic, semantic, pragmatic, and “conversational” EMR interoperability):

Models for Patient Records

“When performance is defined as the result of collective efforts rather than as the result of the actions of an individual, software systems supporting these activities may be labeled under the popular rubric groupware….Although it is tempting to think of these activities as “transactions” it is equally valid to consider them “conversations” related to the solution of specific tasks….Using conversations as a central metaphor for handling patients’ records reflects workflow in a clinical setting….the introduction of groupware designed to facilitate conversations will allow for the acknowledgement and representation of the centrality of human conversation rather than force individuals to reconstruct these conversations through examination of data tables and unstructured patient records….medical groupware helps us redefine where our information systems are going and reflect on their origins and true purpose….it should be remembered that the system is nothing more or less than the community of individuals who collectively care for one another.” [CW: my emphasis]

Some workflow systems literally model, execute, and monitor speech acts (proposals, counter-proposals, promises, excuses, and so on). If we are to move from “conversation” as an interesting metaphor, to practical ways to coordinate the “community of individuals who collectively care for one another,” we will need both the informal and spontaneous clinical groupware, and the more formal and prescriptive clinical groupware known as EMR workflow systems. Their strategic combination is at the technological heart of the care coordination opportunity.


  1. Baecker, R. Part I: Introduction, Baecker, R. (Ed.) Readings in Groupware and Computer-Supported Cooperative Work: Assisting Human-Human Collaboration, Morgan Kaufmann, 1992.
  2. Coleman, D. & Khanna, R., Groupware: Technology and Applications, Prentice Hall, 1995.
  3. Ellis, C, Gibbs, S, & Rein, G, Groupware: Some Issues and Experiences, Communications of the ACM, Volume 34, No 1, January, 1991.
  4. Flor, N, & Hutchens, E. Analyzing Distributed Cognition in Software Teams: A Case Study of Team Programming During Perfective Software Maintenance, In Joenemann-Belliveau, T, Moher, T. & Robertson, S. (Eds.) Empirical Studies of Programmers, Fourth Workshop, Ablex, 1991.
  5. Frisse, M, Schnase, J, Metcalfe, E, Models of Patient Records, Vol 69, No 7, July 1994, Academic Medicine.
  6. Grief, I. (Ed.) Computer-Supported Cooperative Work: A Book of Readings, Morgan Kaufmann, 1988.
  7. Grudin, J. Groupware and Cooperative Work: Problems and Prospects, In Laural, B (Ed.), The Art of Human Computer Interface Design, Addison-Wesley, 1990.
  8. Johnson-Lenz, P. & Johnson-Lenz, T. Groupware: The Process and Impacts of Design Choices. In Kerr, E. & Hiltz, S. (Eds.), Computer-Mediated Communication Systems: Status and Evaluation, Academic Press, 1982.
  9. Khoshafian, S. & and Buckiewicz, M., Introduction to Groupware, Workflow, and Workgroup Computing, Wiley, 1995.
  10. Malone, T. & Crowston, K, What is Coordination Theory and How Can It Help Design Cooperative Work Systems, In Halasz, F. (Ed.) CSCW 90: Proceedings of the Conference on Computer-Supported Cooperative Work, Los Angeles, Oct 7-10, 1990, ACM.
  11. Rodden, T. & Blair, G. CSCW and Distributed Systems: The Problem of Control, Bannen, L., Robinson, M, & Schmidt, K, (Eds.) Proceedings of the Second European Conference on Computer-Supported Cooperative Work, Sept 25-27, 1991, Amsterdam.
This entry was posted in EHR Workflow. Bookmark the permalink. Post a comment or leave a trackback: Trackback URL.


  1. Posted February 17, 2010 at 7:31 am | Permalink

    Dear Chuck: Great piece! There are really no new ideas, are there? But good ones can be re-cycled as times change. I would suggest you contact some of the people and firms in the Clinical Groupware Collaborative, to lend your expertise and also to learn about what these folks are trying to accomplish. I’d also suggest that the involvement of the patient/consumer in the groupware and workflow model that we’re espousing for EHR technology is new and very important, IT that supports the new Participatory Medicine conceptual framework. It’s not an accident that a pediatrician, Alan Greene, MD, is one of the leaders of that movement.
    Very kind regards, dCK

  2. chuckwebster
    Posted February 17, 2010 at 11:04 am | Permalink

    And thank you David!

    Both for your kind comment and your continuing leadership.

    Your posts and publications are the items I most frequently forward to my colleagues.

    I’ve already spoken with Vince Kuraitis from the CGC, look forward to further exchanges of ideas, and intend for clinical groupware and clinical BPM to realize their full potential.

    There is a great deal to be gained by combining the kind of clinical groupware advocated by the CGC with the process-aware EMR groupware I’ve been promoting for a decade.

    The three technology trends I see coming together are:

    Process-aware EMR workflow/BMP approaches,

    CSCW/Clinical groupware and social informatics approaches, and

    Modular componentized EMR architectures.



  3. Posted February 17, 2010 at 1:20 pm | Permalink

    David, I see something very different in Chuck’s approach.

    Conventional wisdom: health information exchange first, then maybe get around to thinking about workflow later

    Chuck’s model: understand/define workflow (and EMR usability) FIRST, then define health information exchange (data) requirements.


  4. chuckwebster
    Posted February 17, 2010 at 4:29 pm | Permalink

    “Well understood, consistently executed, adaptively resilient, and systematically improvable workflow *between* health care organizations is not possible without well understood, consistently executed, adaptively resilient, and systematically improvable workflow *within* health care organizations.”

    Well Understood, Consistently Executed, Adaptively Resilient, and Systematically Improvable Pediatric and Primary Care EMR Workflow

  5. chuckwebster
    Posted February 20, 2010 at 9:25 am | Permalink

    I received a comment from someone through my contact page that this question deserves a more serious reply, or at least they’d like to hear one. I agree.

    Great clinical groupware across organizational boundaries won’t be possible without great clinical groupware within organizational boundaries. It’s not a question of which to do first but rather whether or not to do both well.

    Effective, efficient, and satisfactory clinical groupware (parallelism with the ISO usability definition is intentional) across organizational boundaries won’t be possible without effective, efficient, and satisfactory clinical groupware within organizational boundaries.

    Without some kind of workflow-based clinical groupware engine, or engines, within and without the physician practice, passing data *and* coordinating the pragmatic effects of that data (that is, supporting and facilitating care coordination) the result will be fragile, ambiguous, unscalable, frozen cross-organizational workflows.

  6. Posted April 20, 2010 at 4:50 pm | Permalink

    Chuck, your bookshelf looks surprisingly similar to mine. (Seriously, I have those books in almost the same order … are you sure you didn’t sneak in an take the picture in my office? :-)

    I think you have a really good point that the idea behind “clinical groupware” are very similar to, and very compatible with, the ideas of adaptive case management. Need to get these groups talking.

    Adaptive Case Management Blog Posts

    -Keith Swenson

  7. chuckwebster
    Posted April 20, 2010 at 6:19 pm | Permalink

    Hi Keith, was a great conference (I attended specifically for the adaptive case management content).

    Several other folks sent me pictures of similar stacks of books. Maybe I should create a sort of exhibition of pictures of stacks of favorite books.

    Seriously, there are amazing numbers of interesting connections between the workflow management systems/business process management/case management industry on one hand and the EMR/EHR/clinical groupware industry on the other. It’s like standing at an intersection and watching two speeding cars who aren’t aware of each other. The impetus for this blog was an intent to entice and cajole more intellectual commerce between these two complementary and growing software sectors.

    The collision (a good one) is inevitable. It’s just a matter of speeding it up.

    Looking forward to the next Adaptive Case Management conference (with a healthcare track!).


  8. Carl Hirschman
    Posted January 2, 2014 at 1:15 pm | Permalink

    Very interesting article.

    There seems to be a few competing interests here that bring up some challenges. Care coordination and work flow management in EMR’s current state revolves around a single institution organizing its internal teams or individuals. The reality of healthcare today is that care coordination has to happen across multiple systems and disconnected teams or individuals that are acting in silos currently.

    HIEs help with information flow between the parties, but don’t give insights into current actions being taken for true care coordination or a platform for communication between parties. Care coordination must focus on the individual, the patient, and revolve around their ecosystem that involves multiple ‘silos’ of care.

    In practice, we can centralize the health information for a patient into a central record that is very easy for anyone to use. We then empower all of the care stakeholders to see what is happening in real-time, without disrupting their current work flow. Individual providers can see how their care relates to what others are doing and are now incentivized to do so through readmission penalties, patient-centered medical homes, and ACOs. Care managers (professional or informal family ones) can then assign tasks, implement automated workflows (such as reminders or alerts) that work for that individual patient, and can make sure care the overall care is going down the correct path without any unnecessary duplication. We call it CareTree (

  9. chuckwebster
    Posted January 2, 2014 at 1:57 pm | Permalink

    Thanks Carl,

    I hope you don’t mind me pulling your self-description (I’ve added my comments too, below)….

    CareTree: A “HIPAA compliant Facebook” for better Care Coordination and Universal HIE

    (From Pioneer Pitch Day, October 16, 2013, New York City)

    “Families are the best care managers, especially with AARP’s projected shortage of caregivers. Families have a patient load of 1 or 2, instead of 100 or 200, and are incentivized to make sure loved ones have the best care, stay healthy, manage their chronic conditions, and stay out of the hospital (or avoid readmissions). Families WANT to be empowered to do this.

    CareTree is the solution. Simply create a patient profile and invite other care stakeholders to access it, controlling who can see what. Users can document care activities, exchange messages, receive text messages for emergencies, track vitals, centralize documents, and keep all of the care activities in one calendar. It’s easy for families to use. Professionals can provide better care, increase patient satisfaction and engagement, and lower readmissions without disrupting their workflow using CareTree’s EMR integration that logs into patient portals and centralizes health records across any EMR nationwide (also creating a self-sustaining national HIE).”

    Thank you for pointing out CareTree to me!

    You make many excellent points: important role of the family, difference between mere data and actionable data, and integration of automated workflows into a health record.

    Not too long ago, EHRs and PHRs were repositories of data. Then data began to flow among them and other systems. This requires syntactic interop (HL7’s pipes “|” and hats “^”) and semantic interop (does this number or code in your system mean the same as in my system). This is all well and good.

    However, there is another level of interop, above syntax and semantics, that is sometimes referred to as workflow or pragmatic (a term from linguistics) interop. A message may be transmitted from system to system due to syntactic interop. The message, should someone happen to view it, has the same meaning across systems, due to semantic interop. However, to ensure that a transmitted message has the intended effect, that is, causes the right thing to happen to the right person at the right time and in the right manner…this requires a layer of intelligent representation of workflow.

    I call this representation an “executable process model.” it can be quite detailed, as in prescribing what happens in what order and which resources are consumed to achieve what goals. Or it can be more proscriptive, simply preventing things from happening, but also allowing users, including patients, to do their job or fulfill their role as they see fit, but more efficiently and effectively.

    I did see suggestions of this workflow level of interoperability in your Pioneer Pitch. I’d love to learn more about your system architecture. Do you represent workflows? If so, at what level of granularity? How easy are they for users and designers to understand and improve? Are you collecting workflow analytics to systematically improve user and patient experience? That sort of thing.

    By the way, I’ll add CareTree to a directory of vendors I maintain. It celebrates People and Organizations improving Workflow with Health IT, or POW!HIT!. If you search Twitter for #POWHIT you’ll see tweets pointing to various POW!HIT! Profiles. I’ll tweet you at @CareTreeMe when it’s up.

    In closing, thank you very much for stopping by. I’m seeing more and more, not just task management (along hardcoded workflows), but true workflow management in healthcare, in which users and designers have the freedom and are empowered to ever more systematically improve healthcare efficiency, effectiveness, and user satisfaction.


Post a Comment

Your email is never published nor shared. Required fields are marked *


You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

You can add images to your comment by clicking here.