Skip to end of metadata
Go to start of metadata

 Webinar with Certificate | Recorded Webinar |  Additional Resources | Others from this presenter | Related Questions

 

Thumbnail

 

Thumbnail Page Comment

Rick Marshall

Rick is the founder and executive director of the VISTA Expertise Network. He is a tier-five, master-hardhat VISTA developer who has implemented, programmed,

 

Webinar Overview
  Learn about the unique structure and organization of VISTA, so you can unleash its full potential. Which management techniques help VISTA thrive—and which ones sink it? Rick Marshall offers an insider’s look at the world’s most effective medical software."

Course with Certificate

The license could not be verified: License Certificate has expired!

Recorded Webinar - (Watch Part 2)

(Note: If you don't see the recorded webinar please refresh your browser or contact info@vxvista.org)

 

Additional resources

Books Recommended

 

 

Presenter Webinars Participation

Recent Questions

Topics:

  1. 0
    votes
  2. 0
    votes
  3. 0
    votes
  4. 0
    votes
  5. 0
    votes
  6. 0
    votes
  7. 0
    votes
  8. 0
    votes
  9. 0
    votes
  10. 0
    votes
  11. 0
    votes
  12. 0
    votes
  13. 0
    votes
    status
  14. 0
    votes
  15. 0
    votes
  16. 0
    votes
  17. 0
    votes
  18. 0
    votes
  19. 0
    votes
  20. 0
    votes
  21. 0
    votes
  22. 0
    votes
  23. 1
    vote
  24. 0
    votes
    status

11 Comments

  1. I'm going to check in here regularly, so if you have any questions or comments about this webinar or if you'd like to continue the discussion, I'll be here to participate.

    1. Thanks Rick. I am sure the community will enjoy this presentation and wait for more like this one

  2. Many thanks for this introductory material Rick..

    It is beginning to expose and explain the VistA architecture in a way that is both helpful and thought provoking.

    You implicitly draw parallels with Complex Adaptive Systems throughout this webinar, which is very encouraging. I note from your blog writings and that of Tom Munnecke that this complexity thinking appears to shape yours, yet it is often difficult to explicitly state this when presenting to a wide audience.
    Interestingly I've come to appreciate that patterns amidst complex systems are immensely useful to understand and apply in each of the clinical/managerial/technical domains of my own work, which is why I've also written about them of late. FYI I think you would appreciate the Cynefin framework which explains complex systems alongside complicated systems.. I think you'll find this of real interest and it may help to explain elements of the Onion further!
    http://frectal.com/book/chaos-complex-complicated-simple-and-cynefin/

    I was very glad to hear your repeatedly talk of patterns within the Vista onion, at many layers, in many directions etc etc, as one would expect from a complex system. My sense is that this approach to harnessing patterns amidst complexity is not yet consistently understood across modern software engineering.
    http://frectal.com/2011/06/29/software-development-simplecomplicatedcomplexchaotic/

    Q: Do you sense that the design principles inherent in VistA are becoming better understood as the software engineering discipline matures? 

    Q: Perhaps you may be able to help me understand what material may be available that explores common patterns of clinical process and their fit with VistA architecture? I have little doubt they are supported within Vista, I just have never seen the "how" documented. 

    Q: Are you aware of overlap in VistA architecture concepts with the two level modelling paradigm of openEHR? which, in theory at least, separates common patterns of EHR "content" into archetypes while allowing local customisation of content at at template level..

    BTW one of the reasons I ask is that while previously exploring the complexity of people, process and technology patterns in healthcare I sensed value in a generic process oriented EHR architecture (eg openEHR... which is another days discussion)..http://frectal.com/book/healthcare-change-the-way-forward/healthcare-openehr%e2%80%99s-potential-to-handle-complexity-diversity/   

    Also a related question about Vista UI issues please. One of the challenges I see with Vista is the wide diversity of the UI approaches that the user faces.. from CPRS to Roll n Scroll.. as I currently see it. From what I have seen there is significant room for improvement in harnessing better UI design patterns at the VistA UI layer.

    Q: To your knowledge has any work been done on a patterns based UI framework for Vista?

    (Also FYI I've recently been involved with Rob Tweeds & Chris Casey, harnessing EWD to demonstrate some related work I've been doing in the UK NHS on Clinical UI design patterns. This work was recently presented at the VCM meeting.) http://clinuip.wordpress.com/

    Anyway many thanks for this Introduction.. look forward to progressing the discussion and learning.

    Kind regards

    Tony Shannon

     

     

     

     

     

  3. Hi, Tony.

    I'm glad you enjoyed the webinar.

    Yes, Complex Adaptive Systems are central to both my and Tom's thinking about VISTA. He came by it honestly, on his own, from his early work on VISTA and from his discussions with computer-science and futurist luminaries in the 1980s and 1990s. I came to it much later, during the 1990s, partly as a result of working so long on VISTA, whose architecture is so clearly shaped by it, and partly through exposure to the work of Christopher Alexander. Tom's thinking on this definitely influenced mine, though indirectly.

    I'm still struggling with the problem of how to explain organic order and complex adaptive systems, but I recognize that it must be done. We're dealing with a new generation of managers and technical folks who are interested in VISTA but are not being trained up through the craftsmanship model that taught me and other VISTA hardhats how these things work and apply to VISTA. Therefore, we must learn how to teach these things more directly.

    I'm looking forward to reading the links you provided, and I'll respond again with feedback afterward about how it struck me.

    I'll tackle your very interesting questions in individual responses.

  4. "Q: Do you sense that the design principles inherent in VistA are becoming better understood as the software engineering discipline matures?"

    Yes. When I studied computer science in the 1980s and early 1990s, most of the core principles of VISTA's architecture and software lifecycle had no accepted academic theoretical framework behind them. We organized the system and ourselves the way we did because it worked, because empirical studies out of the National Bureau of Standards in the 1960s and 1970s proved they did, but none of this had become acceptable yet.

    Most academic programs explicitly taught that all the major principles that drove VISTA's organization were precisely backward, wrong, and that we should stop what we were doing and shift to the proper design-then-develop, waterfall model of development. The problem was, that very model, the proper and accepted one, the respectable one, had been disproven by VA itself through the failures in the 1970s of the Office of Data Management and Technology. Not knowing the history, when I took over development of Task Manager I tried to change it to fit what I was learning my computer science program, and it broke VISTA. Trying to shift to a declarative, early binding, static model runs immediately counter to the needs of dynamic systems most of whose data is shifting and continuously modified by users.

    The cleanness and purity required by the dominant early-binding paradigm was wholly absent in a production medical-informatics setting, so after several false starts I began to realize that the theory had to give way to reality. This is a recurring theme in VISTA development, one we explicitly call out in our new book VISTA Mastery - that too many people are not only willing but eager to sacrifice what works in reality in favor of what is supposed to work in theory. I think it becomes a kind of security blanket when working outside our areas of expertise, to rely upon abstract theories that seem to fulfill the same role that actual concrete experience does. The vague generalizations of theory feel powerful because they are simultaneously so sweeping and so specific, and of course most IT theories work just fine in the kind of limited-complexity settings where individuals "confirm" theories to their own satisfaction. Unfortunately, most things that work on a small scale fall apart at large scales in production, where the pressures split apart all the fissures in the poor fit between the theory and the reality.

    Although wise IT practitioners are always ready to let reality be their guide in overturning even cherished theories, too many people can't let go when confronted with contradictory evidence. I was fortunate enough to have no choice. I simply had to get my new version of Task Manager working, so I was compelled to either abandon theories or fail on my first major assignment at the national level. Sometimes pressure is a good thing; I didn't give up my theories lightly, but in the end I had to leat VISTA teach me about the importance of late binding, loose coupling, extensible frameworks, and other architectural and lifecycle principles.

    Today things have halfway changed in the right direction.

    On the positive side, I can't tell you what a relief it is to hear people extolling rapid prototyping, extreme programming, agile development, scrums, user-driven development, and so many other good development approaches. Even VA has shifted to PMAS and is seriously exploring agile development, which are big steps in the right direction. It is a bit disorienting actually to hear the same institutions that used to ridicule us for doing these very things now commend us for seeing the light and doing things their way, but the important thing is that the core observations that Ted O'Neill, Tom Munnecke, and others discovered and applied to VISTA in the 1960s, 1970s, and early 1980s have now spread; they can do more good in the world, now that more people recognize the importance of these approaches and perspectives, and we get less resistance to doing things the right way.

    On the not-yet-positive-enough side, however, the underlying problem of the eagerness to sacrifice actual solutions in favor of theoretical ones is stronger than ever. In fact, the good I described above has come about because the theoretical has shifted in those ways to align with the actual, not because people are any better at giving up a beautiful theory when an ugly fact contradicts it. In this era, computer science is embracing rapid prototyping well enough, but it's also manic about chopping everything into tiny pieces or thin layers and then trying to sew the resulting software corpses back together with interfaces, APIs, messaging buses, and other glue or snap-on layers. The price, the effort, and the high failure rate associated with this mania for dissection goes largely unmeasured, and failures caused by it are brushed away and quickly forgotten when the next big push to dissect gets funded. It's a profitable theory, if not a pragmatic one.

    Integration is seen as inherently bad and is misrepresented as an unstructured rat's nest, as though the only way to integrate a system were with spaghetti code. Nothing could be further from the truth, as we'll explore in this series of webinars, but the only way to learn that VISTA is integrated in a structured way is to work with the code internally long enough to have the rat's-nest myth beaten out of our heads by the software's actual reality - and of course most of the people who propagate the myth have never spent much time in the software's internals and never will, making them immune to correction through exposure to reality.

    Another compensating good development, though, is the wider acceptance of refactoring. As refactoring projects spread, we will not only improve the software and raise up a new generation of VISTA experts (since refactoring is the best way to master someone else's code), we also get new programmers into the architecture, where sooner or later they learn that for all the genuine rattiness that needed to be cleaned up, the larger-scale architecture actually makes sense and is accomplished without spaghetti code. Since small refactoring projects have such a high success rate compared to the old, absurd, mega-replacement projects of the past fifteen years, these new programmers will come out of their projects with shiny reputations which will help others hear their message that though any number of individual routines and programs need to be cleaned up, the larger architecture mostly makes sense and just needs to be extended in new directions.

    So overall, I'd say yes, as the software engineering discipline matures, slowly the design principles in VISTA are becoming better understood.

    Thanks for asking such a good question.

  5. "Q: Perhaps you may be able to help me understand what material may be available that explores common patterns of clinical process and their fit with VistA architecture? I have little doubt they are supported within Vista, I just have never seen the 'how' documented."

    Ah, yes. Here is a lingering issue. VISTA is simultaneously some of the best-documented software in the world and some of the worst-documented.

    It is so thoroughly documented that the complete collection of manuals fills a floor-to-ceiling bookcase on a long wall. Indeed, it is so thoroughly documented that one of the challenges with VISTA is finding the information you're looking for in all that documentation.

    And yet, VISTA is so complex that all that documentation still falls far short of what is needed.

    Much of the documentation reads more like parts manuals than like the kind of information actual people need. Sure, you learn how to install a VISTA package and what options are available in it, but almost always missing are the other layers, such as teaching materials, implementation guides, orientation and perspectives, roles and responsibilities, and the overall architecture and lifecycle. With a few notable exceptions (CPRS and NOIS are particularly well documented, for example), most of these layers of documentation that are so intensely needed are nevertheless wholly absent.

    It's not that there isn't a vast body of knowledge about these things, such as your topic, common patterns of clinical process and their fit with VISTA's architecture. There is. The problem is that we've never taken the time to write most of it down. It's oral and organizational culture contained in the experience of thousands of individuals and in the existing relationships and workflows between them.

    The existing documentation standards are more concerned with enforcing an extremely restrictive typography (Arial, Courier, Times New Roman, at point sizes and with margins as required) and supplying a canned set of parts manuals (parts of installation, parts for user, parts for programmers, parts for security, and a technical yet oddly incomplete list of software parts) than with ensuring that users get meaningful explanations of the various service roles and business practices the software supports and how. The documenters have done a great job with what they've been allowed to do, but like the programmers they're bottlenecked and handcuffed by restrictive policies.

    This could easily be changed if it were a priority, but VA would need to hire more documenters and give users and programmers more free time to work together with the documenters to capture these additional layers of knowledge in writing.

    Any outside organization could likewise fund projects to work with VA and IHS adopters to learn these things and document them. It just has to be someone's priority to ensure the work actually happens. I agree with you that it is important and valuable information that should be in writing.

  6. "Q: Are you aware of overlap in VistA architecture concepts with the two level modelling paradigm of openEHR? which, in theory at least, separates common patterns of EHR 'content' into archetypes while allowing local customisation of content at at template level.

    "BTW one of the reasons I ask is that while previously exploring the complexity of people, process and technology patterns in healthcare I sensed value in a generic process oriented EHR architecture (eg openEHR... which is another days discussion)..http://frectal.com/book/healthcare-change-the-way-forward/healthcare-openehr%e2%80%99s-potential-to-handle-complexity-diversity/   "

    This sounds like the makings of a great day-long brainstorming and education session. I don't know enough about Open EHR to speak authoritatively about it, though I've been involved in a lot of abstract, peripheral discussions about it. The general approach of having a rules engine that allows modular extensions to be easily reorganized is core to all of VISTA extensible frameworks, though I doubt we have all the features you'd be interested in converted yet into extensible framework. The development of new extensible frameworks slowed down greatly during the recent decade and a half of centralization, which has drastically reduced the rate of innovation.

    There are many more extensible frameworks that should be added to VISTA to achieve the maximum useful level of flexibility. This is one of my top three architectural recommendations for anyone thinking about VISTA's future development, whether under its own name or as the precursor to iEHR, and this general approach sounds a lot like what you're describing in Open EHR.

    Please don't hesitate to correct me if I seem to be misunderstanding your question.

    1. Perhaps a somewhat related openEHR version of (parts of) the "onion" could be figure 1 in http://www.openehr.org/releases/1.0.2/html/architecture/overview/Output/main.html (PDF version at http://www.openehr.org/releases/1.0.2/architecture/overview.pdf)

      I find the discussion on this page and the comments very interesting. Thanks for sharing your experiences!

  7. "Also a related question about Vista UI issues please. One of the challenges I see with Vista is the wide diversity of the UI approaches that the user faces.. from CPRS to Roll n Scroll.. as I currently see it. From what I have seen there is significant room for improvement in harnessing better UI design patterns at the VistA UI layer.

    "Q: To your knowledge has any work been done on a patterns based UI framework for Vista?

    (Also FYI I've recently been involved with Rob Tweeds & Chris Casey, harnessing EWD to demonstrate some related work I've been doing in the UK NHS on Clinical UI design patterns. This work was recently presented at the VCM meeting.) http://clinuip.wordpress.com/""

    Yes. The problems with VISTA's current generation of UIs are twofold.

    First, although the scrolling-mode UI and the screen-mode UI were developed following VISTA standards and conventions that consisted of coordinated UI design patterns, the development of the existing generation of Delphi GUIs was done in far more of a hurry. For example, the CPRS developers (who are great VISTA developers) did what they could to come up with coherent UI and other architectural patterns, but overall the CPRS client is not nearly extensible enough (compare it with Dr. Doug Martin's CPRS client alternative, Vuecentric, which allows anyone to easily plug in new tabs), and the UI pattern suite they came up with is not quite as coherent as the old scrolling-mode pattern suite. Unfortunately, the Delphi clients for other VISTA applications follow the lead of CPRS's UI patterns only half-heartedly, leading to an overall inadequate degree of coherence between the various VISTA Delphi GUI applications.

    Second, there was a big debate about the choice of Delphi in the 1990s. Although it let the CPRS team rapidly develop a working and impressive-looking CPRS client in a hurry (the importance of which to VISTA's survival should not be understated, considering the political sharks circling VISTA at the time), it broke VISTA's architectural coherence (including its UI coherence) in a number of important ways. Above all, it was an awkward enough fit with the existing VISTA software that any hope of a complete upgrade of VISTA's UI to a new GUI format was dashed. There were several competing approaches to GUIs being explored in the mid-1990s, and more than one of them would have allowed for inexpensive, rapid development of GUIs for all of VISTA following a coherent set of new UI patterns, but VA central office took the then-unusual step of suppressing all experimentation with alternatives (a historic step in the wrong direction that marked the beginning of the VA's march to centralized paralysis) and mandating Delphi-only for GUI development with VISTA. This was a bad move for VISTA, but it was great timing for Borland (creators of Delphi), a company that was teetering on the edge of bankruptcy but was bailed out by this VA commitment to Delphi. I'm glad Borland is still around (I've always liked their work), and I'm very glad that CPRS got a good looking CPRS client quickly enough to head off the political sharks and save VISTA (which was renamed from DHCP with the high-visibility rollout of the new CPRS client), but tying all VA GUI development to CPRS's immediate deadline by canceling all other GUI projects was the beginning of the end for productive, decentralized development in VA, and it led VISTA directly into the confused mix of UIs it has today.

    Fortunately, there are three important advantages for VISTA that result directly from these problems, from the mess caused by the centralized interference with the VISTA lifecycle around the CPRS client decision caused VA and the larger VISTA community.

    First, everyone agrees that the current mess of UIs is not desirable. If we had successfully converted all of VISTA to a workstation-based GUI model, like Epic did, it would be functional enough that there would be resistance to making the investment to upgrade to web and mobile UIs; there would have been a lot of lip service but not much actual organizational will to commit to change. Because we didn't, we don't face those serious obstacles. In a community that can at times polarized into either fractious and tribal or centralized and resistant to change, there is a universal acknowledgement that something needs to be done. Since most of the problems the VISTA community faces are with the peopleware, especially with the organizational ossification of its largest adopter's VISTA lifecycle, getting a consensus on such a complex issue is rare and precious. We can actually make change happen here with considerably less resistance than many other important architectural or lifecycle innovations face, ad through OSEHRA and VA's Innovations office these improvements can actually spread throughout the entire VISTA community. Real change is possible.

    Second, thanks to Rob Tweed's work on EWD, we have a viable new framework for UIs for VISTA, one that can with a bit more investment in its VISTA-aware toolkit become the kind of rapid-UI-development framework needed to convert all of VISTA back to a unified UI based on patterns. Part of what stopped the conversion from scrolling mode to workstation GUI mode is that the latter took so much longer to develop UIs for than the former. A decently trained VISTA developer can churn out a new scrolling-mode option for end users in an hour or less; doing the same with Delphi takes days or weeks, depending on how much toolkit-building work has already been done in advance. With the new, emerging generation of VISTA-aware tools for doing EWD development, we're lowering the EWD-based-UI development time down from weeks to days, and by the end of the year it will be back down to hours, comparable with the blinding speed of the old scrollingmode-UI development. Since that was the speed with which we generated the small galaxy of scrolling-mode options that need to be duplicated to give VISTA a new coherent GUI, nothing less than that speed will be sufficient for replacing it any time soon. We are very excited by EWD's promise of development speed.

    Third, thanks to the paralysis and muddle that bogged down VISTA development (some technical, most organizational), VISTA is in a position to just leapfrog over the "modern" workstation GUI on its way to a wholly portable mobile and web-based GUI. In its day, VISTA's scrolling-mode UI was sexy and revolutionary, back when mini-computers were the upstarts challenging the supremacy of mainframes. VISTA's role in the world was always supposed to be as a revolutionary system that helps us give doctors, nurses, and other caregivers the best possible medical-informatics support. By skipping past the stale UIs of the previously "modern" workstation GUIs, EWD promises to restore VISTA to its proper place as a beautiful and revolutionary system designed by and for the people it serves.

    I am convinced that EWD is the future of VISTA - it's already becoming the present with a new generation of VISTA applications already being deployed - and I will work closely with my colleagues in the VISTA community to ensure that we fully commit to developing those UIs in accordance with a coherent set of UI design patterns.

    Thank you for asking this question and giving me the opportunity to write about such an important subject.

  8. Tony, if you have any more questions about any of this, or if anyone else does, please do not hesitate to ask.

  9. For anyone interested in learning more about EWD, Dr. Rob Tweed is offering three-day crash course in EWD-based development in Seattle Saturday, 8 September through Monday, 10 September 2012 as a lead-in to the VISTA Expo and Symposium (Tuesday the 11th through Friday the 14th). His in-person training is the best way to learn to do EWD-based UI development. Visit the VISTA Expo site at http://www.vistaexpo.net/index.html to register.