Name: Charles

Bio: Chief Medical Informatics Officer, EncounterPRO Healthcare Resources, Inc., Atlanta, Georgia. About those initials (my mother used to say I was killing myself by degrees): BS, Accountancy, University of Illinois; MD, University of Chicago; MSIE, Industrial Engineering, University of Illinois; MSIS, Intelligent Systems, University of Pittsburgh. (Those are kickbikes.)

Posts by :

    Copyright Received for EHR Workflow Management Systems Criteria

    March 10th, 2010

    Short Link: http://j.mp/cmsisv

    I received a cool looking document last week, the copyright certificate of registration for the EHR Workflow Management Systems survey of features and functions.

    copyright-seal-web

    A fan of open source and open minds, I license everything on this blog (and we everything on our product website) under the Creative Commons Attribution 3.0 License.

    creative-commons

    I essentially registered the copyright to give you (or anyone) the right to adapt and use the EHR workflow management survey criteria (with attribution, of course!).

    copyright-web

    So, please feel free to use or adapt and use the EHR Workflow Management Systems survey of features and function for any purpose whatsoever, knowing that you have the right to do so.

    Have fun!

    No Comments "

    Zowie! Tweets of the Week Ending March 7th, 2010: Real EMR Differentiators, Clinical Groupware, Captain Sullenberger, Pediatric Modules

    March 7th, 2010

    No Comments "

    #HIMSS10 Best Ever: Due in Large Part to Social Media

    March 4th, 2010

    Short Link: http://j.mp/9GEhUr

    “#HIMSS10” was the hashtag used in tweets about this year’s HIMSS conference in Atlanta, March 1-4. Attendees searched Twitter for #HIMSS10 to follow a gigantic conversation. #HIMSS10, or more precisely the convergence it symbolizes to me, transformed my HIMSS conference experience.

    I’ve been coming to HIMSS conferences for ten years. The added social media dimension improved my #HIMSS10 experience in three ways:

    1. Blogging, Twitter, Facebook, LinkedIn, and so on, are all relatively new and interesting to me. HIMSS session content on these subjects was superb. In particular, Twitter 101 and the three Meet the Blogger sessions (delivered and moderated by Cesar Torres, respectively, and facilitated by Ward Seward, both of HIMSS) were high points. I’ve been blogging for a year and tweeting for a couple months, but I’m still a newbie, which is great, because learning (and sharing) is so much fun.
    2. All the HIMSS sessions I attended (not just the social media sessions) were embedded in a dynamic, interactive, virtual matrix of back-channel chit-chat that entertained and provided valuable real-time annotations to what I observed at the podium. It was tonic that kept me awake (even after lunch or at the end of a long day) and provided a steady stream of valuable information (and links to valuable information) that I archived and, even now, as I write this post, consult.
    3. Representing my blog (chuckwebster.com) and twitter account (@chuckwebster), I came to HIMSS with new motivation to absorb, connect, and take away as much as I could, so that I can turn around and think, write, and interact about that content as much as I can. I’m not a reporter. I don’t have press credentials, but I felt a little bit like one. Each time (which was rare) my attention began to lag, I’d mentally slap myself, so as to not miss anything important, so as to not misattribute or misquote someone, so as to maximize the number of juicy new ideas to combine with my own.

    I have a new measure for HIMSS conference success: the number of new ideas I gain for future blog posts. By this measure #HIMSS10 hit it out of the ballpark. My ideas-for-future-posts.txt file just doubled. Of course, this number is only a coarse and indirect measure of something else, something more profound, involving learning, communication, and self-concept.

    A short anecdote:

    I wore a red carnation and tweeted this. A couple days later, while I’m walking the exhibit floor, I hear “Hey! You’re the guy with the carnation!” Well, yes I am. Do you follow me on Twitter? “No” Do you read my blog? (I stream tweets there) “No, I’ve just been reading all the tweets that contain #HIMSS10, and I remember one that said something like ‘I’m wearing a carnation, stop me if you see it,’ so I did.”

    Splendiferous!

    P.S. Follow me on Twitter at @chuckwebster

    No Comments "

    Clinical Groupware: A Definition (Version 2.0?)

    March 2nd, 2010

    Short Link: http://j.mp/aYkgbg

    A while ago I proposed the following definition of clinical groupware:

    “Intentional care team processes and procedures pertaining to the observation and treatment of patients plus the tools designed to support and facilitate a care team’s work.” (emphasis not in original)

    I received a surprising number of suggestions (but: Post! Post!). All food for thought.

    I do have a list of what I like and a list of what I think is possibly problematic about the definition. “plus the” and “tools” are on my second (possibly problematic) list.

    I’m tempted to replace “plus the” with “using,” or reverse the order of the primary clauses and use “applied to.” However I’d like to pay respect to the Johnson-Lenzs’ pioneering definition of groupware. I definitely *want* someone from the larger groupware industry and academic community to *recognize” this relatively well know construction. Nonetheless, I did replace “+” with “plus” because, well, “+” is just not a word.

    “Tools” was on the second list too, not so much because “tools” is vague (and even if it was vague, that’s not necessarily bad); it’s that it is too general (too high up the knowledge representation abstraction hierarchy, using artificial intelligence-speak, therefore violating the third requirement for a good definition). It might admit “examples” of clinical groupware that we don’t want to be counted as examples. A rock can be used to compel coordination. But it’s not nice.

    “Communication technology” is very close to what I had in mind. It implies information processing too, I think. However, successful communication does not ensure successful coordination to achieve common goals. Diplomatic instances of this give rise to the euphemism “a frank and constructive exchange of views.”

    I considered all the possible combinations of “information,” “processing,” “communication, “digital,” and “technology” but wasn’t happy with any of them. So I decided to leave it “tools” until I came up with better. I’d rather gradually tighten the definition to exclude false positive examples of clinical groupware than untighten to include false negative examples of clinical groupware.

    I’m also looking for a level of abstraction slightly higher than computer code-based clinical groupware. Examples of codeless coordination technology include the electrical lights and signal systems used in medical offices to represent who is where–with what priority–in real-time. EncounterPRO’s Office View is a digital example of this kind of radar view, albeit with much more task status information and driven automatically by the workflow engine.

    Some computers don’t rely on electrons at all (at least directly). They are physical machines that operate deterministically according to the laws of Newtonian physics (not the laws of a computer language). A problem to be computed is mapped to their physical state, the machines move to equilibrium or quiescence, and the solution is mapped back out. I used to build gadgets out of tinker toys and punch cards that would play Tic-Tac-Toe. It blows my mind to think of how different today’s world might be if Babbage had succeeded to build a computer based on gears and powered by steam.

    Physical machines can also be used to communicate (and I’m not talking  tin cans and string here). I recall that Leonardo De Vinci designed a mechanical means to convey a pixel-image from one location to another. Black and white squares in a grid are flipped, drive cords running over pulleys, which flip corresponding squares in another room. I don’t know if he built it and I can’t find it on the Web (keep coming up with television shows about his inventions instead of his invention of the television–or maybe I have the wrong inventor).

    If all this seems a bit far afield from clinical groupware, I’d stress that this definition needs to be “extensible.” It needs to be compatible with innovative approaches to coordinating patient care we haven’t even imagined yet.

    Technology is about more than digital computers. Finding the right representation for a coordination problem can be most of the battle. Annotating that representation, or moving physical tokens around on it, can be a groupware solution. Many board games are based on this idea. I’d like the definition of clinical groupware to be compatible with any such fiendishly clever annotatable or mutable physical representation (such as the common grease board). Codeless clinical groupware prototypes may be part of a developmental process in which some step will be to digital format.

    So far, the best phrase I’ve come up with to specialize “tools” and tighten up the definition is “coordination technology.” It captures what I think needs to be captured, and resonates nicely with current discussions about “care coordination.” 

    So here is another candidate for a definition for clinical groupware (version 2.0):

    “Intentional care team processes and procedures pertaining to the observation and treatment of patients plus the coordination technology designed to support and facilitate a care team’s work.”

    Just one problem though, it violates the fourth requirement for a good definition: Avoid obscurity. Coordination technology is not a commonplace and widely understood phrase. The interesting thing is that if I define coordination technology to be “tools designed to support and facilitate a (care) team’s work,” I end where I started.

    So, for now at least, I think I’ll stick with my original definition for clinical groupware:

    “Intentional care team processes and procedures pertaining to the observation and treatment of patients plus the tools designed to support and facilitate a care team’s work.”

    P.S. Follow me on Twitter at @chuckwebster.

    No Comments "

    Usable Clinical Groupware Requires Modular Components and Business Process Management

    February 28th, 2010

    Short Link: http://bit.ly/90cGhY

    I predict:

    Future extensible clinical groupware will coordinate delivery of EHR functionality to teams of users by combining modular components with executable process models whose usability (effectiveness, efficiency, and user satisfaction) will be systematically improved using business process management techniques.

    Let’s break this long and complicated sentence into parts, understand them, and then understand the prediction as a whole.

    1. Future extensible clinical groupware
    2. will coordinate delivery of EHR functionality to teams of users
    3. by combining modular components
    4. with executable process models
    5. whose usability (effectiveness, efficiency, and user satisfaction)
    6. will be systematically improved
    7. using business process management techniques.

    I’ll cover these topics (though in a different order) and important relationships among them.

    Usability: Effectiveness, Efficiency, and User Satisfaction

    The International Organization for Standardization definition of usability is frequently invoked:

    “[T]he extent to which a product can be used by specified users to achieve specified goals with effectiveness, efficiency and satisfaction in a specified context of use.” (my emphasis, ISO 9241)

    Great definition…but it just seems so, well, “singleware-ish.” Clinical groupware needs a less abstract definition of usability that is more direct about groupware’s unique usability issues (see the sixth, seventh, eighth, ninth, and tenth quotes from my Clinical Groupware…Key Ideas post). How about: Clinical groupware usability is…

    “The extent to which clinical groupware can be used by specified teams of users to coordinate activity and achieve specified collections of goals with overall effectiveness, efficiency and satisfaction in specified contexts of use.”

    This definition of clinical groupware usability is consistent with the ISO definition, just more specialized in ways to make it practically relevant to clinical groupware usability. In either definition, notice the tuple: (specified users, specified goals, specified contexts). We will return to it in a later section.

    That said, current discussions of EMR/EHR usability are shallow in two ways.

    The first sense in which current discussions of usability are “shallow” I address in The Cognitive Science Behind Pediatric EMR Usability Checklists. Usability checklists are the tip of the cognitive science iceberg. The rest of the iceberg is “deep” usability. UI/UX (user interface/user experience) expert Steve Krug suggests (tweeted about here, how does one cite a tweet anyway?) taking an intro to cognitive science course. I agree.

    But this post is about the second sense in which most usability discussion is shallow. I distinguish between shallow and deep EMR usability (inspired by an imperfect analogy to shallow versus deep models of medical reasoning). In fact, thinking about extensible EMRs using modular components requires thinking about deep usability. Consider the following quote about usability:

    “Usability is often considered only important for developing user interfaces. But the user interface is only the surface of many interdependent components, each with their own features that make them more or less usable. As a result, the overall usability of a system is actually the aggregate of how well individual components that make up the system work together.” (my emphasis, Designing Healthcare Solutions with Microsoft BizTalk Server 2004)

    Discussions about EMR user interfaces are about shallow usability (that is, about the surface or “skin” of an EMR). Deep usability is about the usability of individual components (seen and unseen) and how all those usabilities add up to total EMR system combined usability. In clinical groupware, deep usability spans time, space, content (multi-specialty), individual differences (potentially complementary, love the idea of team of experts versus expert team, especially the aviation and crew management connection, see my post Pediatric EMR Workflow System Usability–Roots in Aviation Human Factors), group dynamics, organizational structure, and culture in ways that prevent use of traditional usability assessment methods.

    Executable Process Models

    Modules and components will not be enough to achieve deep EMR usability, unless one of those modules is an executable process model. This executable process model will likely be a workflow engine executing workflow or process definitions (called “workplans” in the EncounterPRO Pediatric EMR Workflow System).

    Otherwise we will just be stuck with another version of the traditional clickity-clickity-click-click-click, hunt-and-peck EHR that most physicians hate because they don’t want to be workflow engines–which is what I think most mean when they say they don’t want to be data entry clerks. Physicians (especially pediatricians, who run the lowest margin, highest volume businesses of any specialty) need the EHR workflow engine equivalent of a hyper-competent operating room nurse who automatically hands you the right data entry or order entry tool at the right time and place in the patient encounter.

    In fact, that is the question: who or what is the workflow engine? If the answer is “who”, this is bad, because “who” is a person, a potentially expensive professional who should not be wasting their time doing what could be done more quickly, more consistently, and less expensively. If the answer is “what”, this is good, because “what” is a much less expensive inanimate object, the computer. If the computer can perform activities that don’t require a physician’s time and helps coordinate activities that do, then physicians will likely embrace clinical groupware and EMRs that include clinical groupware functionality.

    Six years ago I attended the Health Summit held in Washington DC in 2004. I was the only representative from an EMR vendor serving small to medium size primary care clinics at the time (I checked the attendee list). Then Secretary Tommy Thomson, assembled assistant secretaries, and blue ribbon panelists laid out plans for a National Health Information Network. (Here’s an archived news report). Much discussion was devoted to the need to subsidize EMRs because of their effects of physician workflow and productivity. At the end of the conference folks lined up behind the aisle microphone to address the meeting. Finally, a white haired man, who identified himself as a solo family medicine physician, got the microphone:

    “I don’t care if you give it to me free and then bribe me to use it, if it slows me down I won’t!”

    Amen! (If anyone can point me to an archived transcript of the public comments I’d appreciate it.)

    Business Process Management

    Business Process Management is a “process optimization process.” On this blog I’ve written extensively about BPM in healthcare. Consistent with an extensible-EMR-via-modular-component approach, BPM functionality is also provided by a set of modules (called a BPM suite) that can be used with process-aware information systems to achieve four categories of benefits. Combining EMR/EHR with BPM technology contributes to well understood, consistently executed, adaptively resilient, and systematically improvable clinical and administrative workflow,

    1. modeling and simulating all interaction patterns between physicians and other clinical and non-clinical staff, systems, and EMR components to create shared understanding about how to optimize care coordination processes and results; ( “well understood” )
    2. coordinating and managing the handoff of patient care tasks across organizational boundaries; ( “consistently executed” )
    3. providing real-time feedback to physicians and other care coordinators about care-in-progress to support patient care process adjustments; ( “adaptively resilient” )
    4. monitoring care coordination outcomes to performance targets, and continuously refining and adjusting care coordination process flows and rules. ( “systematically improvable” )

    These four categories of BPM contribution to healthcare roughly mirror my own 2005 five part list of contributions of workflow automation to EMR usability: naturalness, consistency, relevance, supportiveness, and flexibility. I didn’t know as much then about business process management as I do now, but I think my past self’s intuitions were spot on (thank you future self, you’re welcome past self).

    EHR Workflow Management Systems in Ambulatory Care, Healthcare Information and Management Systems Society Conference, February 14, 2005, Dallas, Texas Well Understood, Consistently Executed, Adaptively Resilient, and Systematically Improvable Pediatric and Primary Care EMR Workflow, 2010, this blog
    Natural Workflow Well Understood Processes
    Consistent Workflow Consistently Executed Processes
    Relevant Workflow Adaptively Resilient Processes
    Supportive Workflow Adaptively Resilient Processes
    Flexible Workflow Systematically Improvable Processes

    Systematically comparing the 2005 column to the 2010 column would be a great post, especially since the five items on the left were motivated by usability concerns, not categories of BPM functionality. I’ll put a tickler in my ideas-for-future-posts.txt file.

    Systematically Improved

    However, I do want to address importance of flexible workflow to systematically improvable workflow.

    • If workflow is not flexible, then it cannot be changed (without relying on a c# or Java programmer—no offense intended, since I am both myself).
    • If workflow cannot be changed then it cannot be improved.
    • If workflow cannot be improved then effectiveness, efficiency, and user satisfaction with workflow cannot increase.
    • If effectiveness, efficiency, and user satisfaction cannot increase then higher levels of “deep” EMR usability can be achieved.
    • Q.E.D.

    Let’s address just one of these dimensions of deep EMR usability: EMR workflow efficiency. In 2005 I wrote about a BPM technique called process mining (called that by analogy to data mining):

    “Workflow management systems generate tremendous amounts of time-stamped sequential data as a by-product of execution of process definitions by workflow engines. By analogy to data mining, analysis of such data (typically collected in log files) is called workflow or process mining [10]. Process mining can discover new and useful process definitions, compare process definitions to what users are really doing, and optimize existing process definitions—all of which can be used to improve ambulatory workflow.” ([10] reference: van der Aalst W and Weijters A. Process Mining: A Research Agenda. Computers in Industry 2004, 53(3):231-244.)

    Process mining is an excellent example of BPM being a “process optimization process.” However, much of the best BPM academic and industrial research  has occurred and been presented across the pond (both the little one and the big one). (Similarly, the first published reference to “Clinical Groupware” appears in Clemensen, Larsen, and Bardram’s 2004 Developing Pervasive e-health for Moving Experts from Hospital to Home. Simon Larson’s kind response to my emailed questions indicates that what we call clinical groupware appears to be part of a larger set of European research and industry initiatives called “pervasive healthcare.” Sounds like a future post to me.) The United States is a remarkable generator of new information technologies, from the large high tech companies to the university spin-offs to inventors who start in a garage (as was literally so in the case of the EncounterPRO Pediatric EMR Workflow System). However, in this case the healthcare IT industry may have to look not just outside healthcare, but outside the US as well.

    Coordinated Delivery of EHR Functionality to Teams of Users

    I’ve dealt with this topic at length in three previous posts:

    However, so this section can stand on its own (hyperlinks on printed hardcopy don’t work—yet) I’ll include a definition of clinical groupware:

    “Intentional care team processes and procedures pertaining to the observation and treatment of patients plus the tools designed to support and facilitate the care team’s work.”

    An earlier version of the prediction beginning (and ending) this post included the phrase “delivery of traditional EHR functionality.”

    “Traditional EHR” is a popular term these days—to apply to your competitors at least (see my Mirror, Mirror, On the Wall, Which EMR is Least Traditional of All?). This section is not about traditional EHRs, but rather the functionality traditionally provided. I like the eight category list provided in 2003 in Key Capabilities of an Electronic Health Record System: Letter Report to the Institute of Medicine. Feel free to review. (Disclaimer: I helped EncounterPRO user Dr. Cooper write his 2003 HIMSS Davies Award winning application based on these eight categories.)

    I removed “traditional” from my prediction about the future of clinical groupware because we will see new and decidedly untraditional EHR functionality delivered and coordinated by clinical groupware.

    Modular Components

    The best possible service this post can do is to define EMR extensibility, component, and module in ways that systematically relate them to each other and to deep EMR usability. However, it can be difficult to draft practical definitions, when it comes to information technology, without a reference implementation to ground meanings in practical real-world reality. If you’ve read *any* of my previous posts, I am sure you know what reference implementation I will use: EncounterPRO.

    The EncounterPRO Pediatric EMR Workflow System (publicly presented at the Dallas HIMSS in 2000) pioneered not just workflow engine-driven clinical groupware for pediatrics and primary care, but a modular component-based workflow engine-driven clinical groupware for pediatric and primary care. This is not a coincidence. There are important connections among EMR workflow engines, modular EMR components, and deep EMR usability.

    The EncounterPRO EHR Workflow Management System is the workflow management system used to generate a specialty-specific EMR workflow system (see Pediatric EMR Workflow Systems for further explanation). It is a platform for launching and managing EMR components just as an operating system is a platform for launching and managing user applications and software services. Both are “an agreement that the platform provider [gives] to the software developer that logic code will interpret consistently.”
    (http://en.wikipedia.org/wiki/Computing_platform)

    EncounterPRO EMR Workflow Systems are extensible by virtue of being generated by the EncounterPRO EHR Workflow Management System. Extensibility “means the system is designed to include hooks and mechanisms for expanding/enhancing the system with new capabilities without having to make major changes to the system infrastructure.”
    (http://en.wikipedia.org/wiki/Extensibility)

    An EMR “software extension is a computer program designed to be incorporated into another piece of software in order to enhance, or extend, the functionalities of the latter. On its own, the program is not useful or functional.” 
    (http://en.wikipedia.org/wiki/Computing_platform)

    EncounterPRO software extensions are components. Generically, a component “is any smaller, self-contained part of a larger entity.” However, I like even better (due to its early medical informatics context) Berkowicz, Barnett, and Chueh’s definition:

    “A component is an encapsulated functional element that can be used as a building block in application construction. Components can be reused if the format of the data upon which they operate is fully specified, and if a consistent environment for application.” (1998, Component Architecture For Web Based EMR Applications).

    EncounterPRO has half a dozen frequently used components (data display and order entry screens) and many specialized one-of components, about twenty in all. As long as a component adheres to EncounterPRO’s platform API (application programming interface), it can be incorporated into a process definition and executed. It doesn’t matter who created the component, EncounterPRO Healthcare Resources or a third-party source. Super users can add installed components to EncounterPRO process definitions without being .NET programmers.

    Components need configuration to behave usefully. You may already be familiar with application configuration files (XML and otherwise). A configuration object is a collection of declarative data that determines component and platform behavior in response to particular environmental inputs (from users and other sources). Our configuration objects, stored as fields in tables, can be exported and imported to share customized EncounterPRO content.

    Finally, EncounterPRO modules are collections of related components, and configuration data that determine component behavior to accomplish specific sets of logically related goals useful to specific classes of users (such as pediatricians, allergists, and obstetricians) in response to specific environmental inputs. “Module” is based on analogy to circuit boards on which are assembled electrical components such as resistors, diodes, and transistors (as I used to etch my own boards, I’m glad to find that hobbyists still do).

    From Wiki (my contributions are strategically placed ellipses and emboldened bracketed annotations):

    “[M]odules represent a separation of concerns [such as the concerns of pediatricians versus allergists versus obstetricians], and improve maintainability by enforcing logical boundaries between components….Modules are typically incorporated into the program through interfaces [EncounterPRO’s component APIs]. A module interface expresses the elements that are provided and required by the module. The elements defined in the interface are detectable by other modules. The implementation contains the working code that corresponds to the elements declared in the interface…One of the key aspects behind Modular Programming is the ability to separate concerns such that none or few modules depends upon other modules of the system. To have as few dependencies as possible is of utmost importance. Another key aspect is that when creating a Modular System, instead of creating a Monolithic application [traditional EHRs, in the views of many] where the smallest piece is the whole application itself, one creates several smaller Modules which, when composed together, will create the whole system….This makes Modularized Designed systems, if done right, far more reusable [by developers, and, increasingly, users too] than a traditional Monolithic design since all or many of these Modules may be reused in other projects. In addition it also makes breaking projects up into several smaller projects through divide and conquer easier….Modularized Programming is a loosely defined concept. With no official definition, it is the programming technique of composing loosely coupled modules, and forming them together into a complete system.” (http://en.wikipedia.org/wiki/Modular_programming)

    While a definition of clinical groupware should not invoke software modules, components, and sharable content and behavior (proprietary and monolithic groupware and clinical groupware applications surely exist), they are nonetheless important aspects of progressive modern software architecture and development practice. They make it easier to create what needs to be created, clinical groupware or otherwise. Since clinical groupware should rely on the best software development architecture available, clinical groupware should indeed rely on modules and components and sharable content and behavior.

    Future Extensible Clinical Groupware

    Note the parallels between my descriptions of EMR usability and EMR extensibility.

    EMR Usability EMR Extensibility
    specified (teams of) users specific classes of users
    specified (collections of) goals specific sets of logically related goals
    specified context(s) of use specific environmental inputs
    overall effectiveness, efficiency and satisfaction (from definition of clinical groupware usability) overall usability of a system (Designing Healthcare Solutions with Microsoft BizTalk Server 2004)

    EMR extensibility is the other side of the deep EMR usability coin. Deep EMR usability requires (1) combining the right components, collected into the right executable bundles (modules), achieving the right sets of logically related goals, for the right classes of expected users, in response to correctly predicted environmental inputs *and then* (2) application of a “process optimization process” to systematically improve overall usability dimensions of effectiveness, efficiency, and user satisfaction. The first step gets you in the ball park; the second step hits it out. The only practical means by which this will be achieved will be if modular EMR/EHR/clinical groupware systems also include within their very technological nature the ability to systematically change internal processes and workflows to better meet set objectives while working in typical environments.

    For these and other reasons I predict:

    Future extensible clinical groupware will coordinate delivery of EHR functionality to teams of users by combining modular components with executable process models whose usability (effectiveness, efficiency, and user satisfaction) will be systematically improved using business process management techniques.

    P.S. Follow me on Twitter at @chuckwebster.

    No Comments "

    Zowie! Tweets of the Week, February 28, 2010: HIMSS, Carnations, Visual Workflow, Pediatric EMR UI/UX

    February 28th, 2010

    No Comments "

    Tweeting Live from HIMSS, March 1-4, Atlanta: Pediatric & Primary Care, EMR/EHRs, Clinical Groupware, Workflow Automation, Usability/User Experience, & Kickbiking

    February 24th, 2010

    Short Link: http://j.mp/cROHmo

    Here are the most recent 20 tweets from @EMRGroupware: Auxiliary account used by @chuckwebster for real-time, high-frequency, event-related Twittering (not wishing to flood timelines following @chuckwebster). Next use: HIMSS March 1-4, Atlanta. Feel free to follow and respond to me (temporarily at @EMRGroupware) on Twitter (my replies with links to your tweet should show up below), or comment directly to this post.

    For older tweets visit @EMRGroupware

    No Comments "

Get Adobe Flash playerPlugin by wpburn.com wordpress themes