In my many years of doing health IT architecture, I've sat through innumerable marketing presentations and pretty Powerpoint charts, all promising buzzword-compliant shiny new things by folks who have little or no understanding of the practical realities of medical informatics. This has lead me to a "show me, don't tell me" attitude: point me to a real, live success story, not just another bunch of diagrams and buzzwords.
We apologize for not providing an update last Friday - we are in the process of finalizing some larger deliverables that are due at the end of this month; they are fundamental for helping us choose which module(s) to start refactoring. Hopefully we’ll have more for everyone to read sometime near the middle/end of next week. Until then, please feel free to leave any comments, questions, or start a discussion thread. Have a great holiday weekend, everyone!
Refactoring any significant package will require hundreds or perhaps thousands of automated test cases to ensure that the refactored package matches both the functionality and performance of the original package. I have looked at the testing tools on this site and they describe more how to run automated testing and sanity-level functional testing rather that how to build large numbers of automated tests that provide the coverage necessary for confidence in a refactored package. What is the current understanding of how these tests will be developed and maintained?
While it is true that a picture is worth a 1000 words, it does help to have an associated detailed description to go with a diagram like the one on the front page of Refactoring, and I have not found it on this site (perhaps I missed it?). Since this diagram exists, I assume that there has been significant internal discussions on how it will work and why it is the best approach. Can you provide better detail on how the refactored system will work? For example, I see that you have an Event Driver common service:
To our new and old group members alike,
Please feel free to utilize this space for your thoughts, comments, reflections, or questions on the project, what our group has done, what we are going to do, or any direction you think we should take. We welcome all of your feedback! Many thanks in advance.
The Open Source Electronic Health Record Agent (OSEHRA) will start a weekly teleconference to discuss the current set of OSEHRA software development tools on Wednesday, November 16 from 3:30pm to 4:30pm EST. This first meeting will provide an introduction to the many software development tools that are now available for VistA/M developers from the www.osehra.org website. This includes OSEHRA’s:
Last week I retrieved the full list of the active IA (Integration Agreement) Description Nov 2010 from the VA download site - url - https://downloads.va.gov, to begin the process of using the IAs to validate the dependencies between Vista modules. Even though we received an ICRs listing from Julie Harvey of VA back in October, that list contained only 616 so-called “public” ICRs; whereas the full list retrieved from VA download site contained 4197 of “public”, “private”, and “controlled” ICRs. The IA, a.k.a.
The OSEHRA-VistA Visual Cross-Reference codebase-documentation is based on an automated XINDEX analysis and can be accessed directly via http://code.osehra.org/dox or from the OSEHRA web page -> Resources ->Development Tools -> Web Based Code Review.
I just thought I'd throw out some titles of the books I've been reading. These are mostly to catch up on conversations I've been having with Ralph Johnson (who wrote the first paper on refactoring) and Ward Cunningham, another ubergeek. There is a cluster of activity/thinking around the notions of refactoring, pattern languages, open systems, and dynamic languages (Smalltalk, in particular).