Results 1 to 9 of 9
  1. #1

    Clinical Document Repository System

    Guys,

    I'm a clinical documentation specialist and I am thinking about creating an electronic repository system for document maintanence.

    Currently we are using a database written in Microsoft Access and it has all type of bugs.

    I am wonder what other software can I use to create this system. Something that is web based, faster and allow multiple connectives at the same time.

    It also should has the functions for reports generation.

    Any suggestions? Thanks.
    Counter-Strike Rule....

  2. #2
    Join Date
    Nov 2001
    Location
    Vancouver
    Posts
    2,416
    This sounds a little like a project I was involved in. We built a document management solution, in part using off the shelf s/w, part custom, for a medical products firm involved in nuclear medicine. They had a small user base but a big need to control access to documents (document change control; ensuring the latest approved revision is the only revision in use, etc). Just guessing but I imagine your needs probably have a fair amount of overlap.

    Since you mention using an Access DB now, would it be fair to assume that what is being maintained is more of a document inventory/status/approval tracking system, i.e. a list of all the important docs (manuals, procedures, policy guides and such), some revision history, and perhaps locations (physical or electronic)? Maybe some records classification as well?

    Building such a system from scratch will take some time and thought; you'll want to improve upon the Access DB no doubt, so simply using it as a template, just to get better/concurrent access, is probably not good enough.

    If the system is primarily to act as a document inventory and change management system then putting together a db schema and web based access forms and reporting isn't that difficult from a technology perspective.

    Some basic questions first, which more or less amount to Do it Yourself or rent a contractor, and Run it at Home, or rent a home:

    - Will the new system run on "in-house" servers (and what options does IT give you in that case) or is it to be run on outsourced equipment on the Internet (with appropriate security)?

    - Are you, or do you have access to web software developers? If so, what preferences do they have? Or if doing it yourself, what development experiences have you had to date?

    All the bits and bytes and tools questions kind of come secondary to answering these first questions.

    But to skip ahead, there are plenty of low or zero cost development tools which can be used to build such a solution.
    “Even those who arrange and design shrubberies are under
    considerable economic stress at this period in history.”

  3. #3
    First, I want to thank you for your long thoughtful reply.
    To be honest with you, I do not have the answer for all your questions. I probably need to speak to my team manager on this issue.

    As for my technical background, I have a four year degree in computer science and I have been doing some SQL and Access DB within the clinical environment. I have designed clinical data tracking system for CRF design group when I was working for Pfizer and some ASP, VBScript with Access DB experience when I worked as an assistant IT project manager.

    But nothing hardcore. After many years of working with Access DB, I believe the Access DB has some limitations in terms of multiple user connectivities, functionalities and performance.

    That's why I came up this idea to switch our current system into a totally different platform, something that is more robustic.
    Counter-Strike Rule....

  4. #4
    Join Date
    Nov 2001
    Location
    Vancouver
    Posts
    2,416
    Thanks for filling in some of the gaps; I was trying to determine if you were more "power user" or a possible developer. Many Access DB apps get developed, initially, by the former.

    Given your background, you no doubt can handle a re-development project. Depending on your exposure to web application development, you might want to have someone with web development experience working along side or in a team or in an advisory capacity, depending on how much exposure you have.

    Based on the standard platforms supported by the IT group there, you'll have a choice of environments. If its an all Microsoft shop, that will point you in one direction. If they run other application servers (Linux, Unix, one of the BSD's), that opens up other opportunities. So clearly you need to

    a) confirm that the application will in fact be web-based going forward. Sometimes its not the best platform for everythign; sometimes what you want is a "mix" of interfaces - web based reporting, perhaps some limited user-oriented data access/modification forms if there's a need for it, and a Windows (or Mac or..) GUI environment for the principle power users if such do exist.

    Quite often we'd build document change management and control systems in that manner. Very often people needed to see an HTML representation of the current documentation (which might be maintained in Word or...), or just check to ensure that they have the latest hardcopy (using a reporting tool, easily done via the web).

    b) determine the scope of the new application. Simple replacement of what you have, or additional functionality, and if so, define that functionality, assign levels of importants and sort out what the scope should be. Perhaps chunk it up into phases. And try to look to the future... what comes after this project that might be related in some way, share data in some way... this may affect choices.

    c) determine what platform (OS, application development language(s), database) will best fit into your development plans *and* be supportable by the IT group going forward.

    All we can say for sure at this point is that "yes" you can move from Access to something else.

    Over the years I've been involved in many such systems projects and increasingly the web has been involved. Many are now all web-based. Just use some caution - if there is a component of the business need that says "we need a gui here", be sure your overall architecture can handle that.

    As an example, one client has a massive collection (millions) of scanned images; the "right" front end for that solution was a high speed document scanner capable of hundreds of dual sided scans per minute (well, actually several of these) which front end a process driven by an image capture application (GUI, MS Windows based) that streamlines the capture, cleanup, and "indexing" (assigning relevant metadata) of images, for eventual "release" (commiting images and metadata to the document management system). That's one very clear example where you wouldn't shoehorn the web as the front-end of the application.

    However that same application has hundreds of users accessing the data using only a web app which implements certain functionality. Often a mix of app clients is appropriate.

    Good luck with your project!
    “Even those who arrange and design shrubberies are under
    considerable economic stress at this period in history.”

  5. #5
    Thanks again for your advices and suggestions. Your two cents is very useful to me.

    As a matter of fact, I just joined this company not long ago. The current Access DB was written by several different people from different background. I haven't fully test the DB yet. But I was told many of the functionalities are not working properly. I basically need to do alot of debugging in order to fix the bug. Usually the process of debugging is time consuming and difficult specially when the DB wasn't created by me.

    I rather create one from scratch myself. It's much easier for me maintain and upgrade.

    Anyway, I will have to talk to my manager and explain everything to her.
    Counter-Strike Rule....

  6. #6
    I also did some research on the internet and found Data Warehouse has been a good system for clinical data management. Is this true?

    I have never used Data Warehouse before and really dont know how this thing works.
    Counter-Strike Rule....

  7. #7
    Join Date
    Nov 2001
    Location
    Vancouver
    Posts
    2,416
    "Data Warehouse" being a concept, or a product? DW the concept is quite different from "document maintenance / management". Before discussing I think we ought to be sure we are talking about the same thing.

    Data Warehousing is used throughout many industries. Its more an approach, than a specific product, typified by the brining together of data from many different operational and planning systems within an enterprise. Data sourcing and collation, data cleanlieness, and business intelligence mining of the data tend to be key needs. There are products out there that address different parts of the DW spectrum.

    But this is quite different than a document maintenance system.
    “Even those who arrange and design shrubberies are under
    considerable economic stress at this period in history.”

  8. #8
    Join Date
    Jul 2003
    Location
    Kuwait
    Posts
    5,099
    I agree with mwatkins here. We need to clearly define what it is that you are trying to setup. Are you trying to setup a Document Management System, or a database of meta information related to documents and other data? There are a few good opensource DMS available like KnowledgeTree, which has an online demo. Perhaps it would help you if you played with a demo of these and saw what you can expect from a DMS? This might help you in refining what you are looking for.
    In order to understand recursion, one must first understand recursion.
    If you feel like it, you can read my blog
    Signal > Noise

  9. #9
    Thanks guys. I will definitely look into this matter alittle more and have a talk with my team to make sure what they really want before I can make a move.
    I will let you guys know.
    Counter-Strike Rule....

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •