Seeding development of the responder (October, 2011)

 

BACKGROUND

 

-          The University of Utah (UoU) had a CDC-funded research project that was to provide an infobutton-accessible repository of disease outbreak monographs. As a result, UoU had a start on three components that comprise a complete “solution”: a standards-compliant query responder interface, a repository capable of storing multiple types of document content, and a browser-based tool for loading content and applying metadata.  This was developed to the stage of a working prototype, though not production grade.

-          UoU was willing to have the existing work used as a foundation for a joint project as long as they could use the results – which was completely consistent with the VA’s objective of producing software to be made widely available.   That interest also extended to making some time available of the developer who did the repository work to help the VA developer with architecture choices, understanding what currently exists, etc.  It was clear that starting with that seed work would significantly accelerate availability of a responder that could be used in VA (e.g., with AViVA).

-          Due to its own budget cuts, CDC had to cut funding for some projects, and this one was impacted.  The direct consequence is that the software engineer who did the upload / tailoring tool – and who was lent out by the Utah Department of Health – had to return to his usual position. That means that significant knowledge transfer had to take place in a short timeframe.

 

TECHNICAL POINTS

 

-          Dependencies that would have to be explicitly recognized and managed:

o   The UoU prototype uses Oracle. UoU is already interested in moving away from Oracle at some point to a more “open” platform, possibly / probably to MySQL.  VA would like to be able to use MS SQL, and UoU would like to continue with Oracle for a while.  However, the positive aspect is that there is already interest at UoU to move to a less restrictive platform, and VA should be able to accommodate that eventually.  (The VA developer would need to take a look at what would be required to isolate the data layer and determine the level of effort to do so. If that was feasible, VA could take that tack from the get-go, otherwise it’s likely there would be one version for the VA and one for UoU for a while.)

o   The UoU prototype currently uses Apelon’s terminology service software.  UoU is already interested in moving away from that to NLM’s UMLS DTS.  Again, VA and UofU interests are aligned, but it may be that this project will  need to continue to use Apelon on an interim basis. (I.e., the terminology server application, regardless of maintenance and support.)

-          Development is all in java.

-          UoU already has a source repository (SVN) that is externally accessible for their contractors. It was suggested that the source be kept there to get around issues of keeping it inside the VA firewall.  Access for the VA developer was to be investigated.

-          There was agreement that using the Infobutton site on Google Sites to house this work (other than the source code repository) would work, at least initially, and it was felt that it would help to position the infobutton manager software and infobutton query responder / repository software as companion pieces.

-          It was noted that pairing an infobutton query responder with the infobutton manager effort would arguably let VA fold the new work into the scope of the VA-UoU-IHC collaboration agreement signed earlier, and reduce energy barriers that would result from trying to get a new / second agreement in place.

 

Comments