I was a bit cryptic about my conversation with James yesterday, not knowing whether his project was public or not. He has announced a study to collect 1 million people on Facebook: https://socialheartstudy.org/
"Phase I of the Social Heart Study will help participants estimate their own risk for future heart attacks, and help us see if online social network use is associated with cardiovascular health. Phases II and III will enable other social network features and start enrolling participants in prevention research studies."
In effort to best meet our major deliverables that were submitted 11/30, we have spent the last two weeks "refactoring" XINDEX and adding functionality to it. We had a number of reasons to spend the time doing this: first, for our deliverables we wanted to extract package-to-package interface information; second, we wanted a tool that we knew inside and out that we could change quickly to obtain information about anything we needed about the VistA Mumps codebase; third, we wanted to have a Mumps parser that could possibly extend as an automated refactoring tool.
It’s a gathering of citizens in cities around the world to write applications, liberate data, create visualizations and publish analyses using open public data to show support for and encourage the adoption open data policies by the world's local, regional and national governments.
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.