https://www.na-mic.org/w/index.php?action=history&feed=atom&title=Note8Note8 - Revision history2026-04-21T18:09:02ZRevision history for this page on the wikiMediaWiki 1.33.0https://www.na-mic.org/w/index.php?title=Note8&diff=3977&oldid=prevAndy: Update from Wiki2006-12-18T13:33:17Z<p>Update from Wiki</p>
<p><b>New page</b></p><div>* How to specify requirements?<br />
** Is there something inbetween highly rigorous industrial practices and back of the envelope specifications?<br />
** synchronization of code and requirements<br />
** different scenarios, could be iterative process = no single requirement specification<br />
*** often need refinement<br />
*** ISO9000 lite<br />
** see FDA requirements<br />
*** need method for reporting problems<br />
<br />
* Should we collect and disseminate case studies?<br />
** Workshop?<br />
** record processes = best practices manual?<br />
** sell the development process...<br />
* How do we develop guidelines for validation?<br />
** need mechanism to pool our results<br />
** testing: gathing information, evaluation metrics<br />
** case data costs money<br />
** uniform methods/tools for gathering data (e.g., OpenTracker)<br />
** see Nafis study for methodology for tracking validation - example of how to share methods?<br />
** NEED consensus on how to evaluate "correctness"<br />
** "Open Data", just like "Open Source" used to be?<br />
** suggestion: when designing IRBs, try to broaden a little bit so that the results can be used more widely or more effectively.<br />
** patient advocacy groups - mechanisms to make data available for patients to share if they wish,<br />
<br />
* Do we need to develop better/additional hardware and software standards for IGT?<br />
** let the software be the driver by using "open source", at least initially<br />
** standards problem = no standards and too many standards simultaneously (standards, but not enough agreement) - this is probably not a research problem - where should it come from?<br />
** e.g., motivation for APIs exist for trackers (due to demand of customer), but for others (e.g., interventional imaging systems) there is less motivation for the manufacturer.<br />
** NIH play a role in funding industry to develop these standard interfaces (APIs?)<br />
** portability of standards is important (e.g., explicit support of legacy systems)<br />
** what is the value proposition for industry to invest into opening interfaces or developing standards?<br />
*** there will always be competing standards - it is up to the marketplace which will win - where is the marketplace located in our community?<br />
*** therapy is smaller niche than diagnostic, how to convince manufacturers of new methods<br />
*** work with imaging people who also need to open up interfaces for new diagnostic methods<br />
*** Chris Hasser: incentive to undustry - take advantage of resources, brain power that are being brought to bear by the research community - low cost and accelerated prototyping<br />
*** shouldn't underestimate amount of engineering required to produce stable API<br />
*** existing hooks exist in most vendor's equipment - until vendors agree on standards, community can contribute work to interface with these interfaces under research agreements,<br />
*** Guy Schechter (Philips): these things are understood<br />
**** need to take the lead and chrystallize the needs (leverage the power of the group)<br />
**** but real power is buying power? research community is often weak!<br />
**** critical mass (need to convince a few companies)<br />
**** standards may need to be narrow in their respective areas in order to be feasible (broad standards will take too much time, or not happen at all)<br />
<br />
* Develop algorithm repositories?<br />
** awareness - disseminate links to information about things like OpenTracker<br />
** participants of this workshop should add these links on the workshop wiki<br />
** perhaps recast: ask companies to permit us to provide a uniform interface, with having them be forced to comply with the interface.<br />
** hardware knowledge repositories should also be considered,<br />
** Open Source (1. freely available use) (2. distributed community of contributors)<br />
*** should we choose prototype applications to drive an open interaction?<br />
*** heirarchy of need - simple lab-based tests, versus complex assembly of many modules (IGT-lite and IGT-serious)<br />
*** evolutionary process of developing open collaborations<br />
** PeterK - how about a forum for user evaluation and comments? (e.g., just like Amazon customer reviews)<br />
*** Insight Journal could host such discussions. Forum for discussion or review.<br />
**** what is the incentive for the review? danger in review bias.<br />
**** won't this just end up evolving into peer review?<br />
** This community could come together to write requirements to give to industry - agree on common elements of functionality.<br />
*** Larry Clarke: there is dialog between NIST and FDA on this topic<br />
** FDA/legal/regulatory impact on opening access to machine<br />
<br />
<br /><br />
<br />
* Database of simulators (see work in the MRI neuro-imaging world)<br />
<br />
<br /><br />
<br />
* Is there some need for focused study section in this area?<br />
** absence of reference standards for judging IGT research proposals<br />
** the community is its own worst enemy - study section<br />
** what role can NIH play?<br />
** new study section?<br />
** how many IGT proposals are actually going in.<br />
*** there is a coding for diseases, but not for technologies, so this is difficult to track. keywords? this group could help define these keywords.<br />
*** e.g., what should we call this community?<br />
*** goal for breakouts: identify keywords</div>Andy