Tim C. Responded: Which set(s) of GCP guidelines is Epidata using as the goal?
GCP is an abbreviation of "Good Clinical Practice".
The whole issue of GCP guidelines is a difficult one. The preparation in itself involves reading a lot of " heavy legal text". The major issue is that the principles are described in lengthy documents, but there is no strict definition as of what it really implies in terms of specific implementation (apart from the principles). I will add a summary of the main documents later.
In the most recent time I have been experimenting with various software tools for the task: - bug tracking - developmental documentation of tasks resolved. - documentation in general - testing and verifying software behaviour - how to accomplish solutions which are operating system independent. ........
To develop all the details of this is going to be a lot of work, which is why collaborative efforts are crucial. One of the issues is persontime and funding and another is testing. As soon as I can reveal more details of the work plan and steps of this process the list will be informed. And interested persons invited to participate.
Regards Jens Lauritsen
epidata-list@lists.umanitoba.ca wrote:
Tim C. Responded: Which set(s) of GCP guidelines is Epidata using as the goal?
GCP is an abbreviation of "Good Clinical Practice".
The whole issue of GCP guidelines is a difficult one. The preparation in itself involves reading a lot of " heavy legal text". The major issue is that the principles are described in lengthy documents, but there is no strict definition as of what it really implies in terms of specific implementation (apart from the principles). I will add a summary of the main documents later.
In the most recent time I have been experimenting with various software tools for the task:
- bug tracking
- developmental documentation of tasks resolved.
- documentation in general
- testing and verifying software behaviour
- how to accomplish solutions which are operating system independent.
........
To develop all the details of this is going to be a lot of work, which is why collaborative efforts are crucial. One of the issues is persontime and funding and another is testing. As soon as I can reveal more details of the work plan and steps of this process the list will be informed. And interested persons invited to participate.
Ah, OK, I misunderstood - you are referring to adapting GCP principles to the software engineering of EpiData, rather than ensuring that EpiData meets the needs of those who are trying to practice GCP in their clinical work. Regarding the second aim, I think that a) those requirements cannot easily be described in a single document or set of requirements - it depends so much on the nature of the clinical work and the type of data and study designs being used, and no one software tool can every hope to meet all those requirements; and b) for many tasks within the scope of data collection and management, and exploratory data analysis, EpiData does a good job already.
Regarding the first goal, I wonder whether GCP documentation is the best place to look? There is a large literature on software quality and quality assurance in software engineering in the computer science literature - it might be quicker to consult that body of knowledge rather than trying to glean principles from GCP guidelines. I doubt that you will find much discussion of things like formal test plans, calculation of the coverage of unit tests, and the issues of testing "corner cases" and how to check for "numerical bruising" and other subtle computational problems in the GCP guidelines, but those topics are pretty standard in most texts on quality assurance and testing in software engineering - or so I am told. I have just been reading some lecture notes from some undergraduate computer science courses on these topics and found them very instructive and helpful indeed.
Tim C
epidata-list@lists.umanitoba.ca wrote:
Tim C. Responded: Which set(s) of GCP guidelines is Epidata using as the goal?
GCP is an abbreviation of "Good Clinical Practice".
The whole issue of GCP guidelines is a difficult one. The preparation in itself involves reading a lot of " heavy legal text". The major issue is that the principles are described in lengthy documents, but there is no strict definition as of what it really implies in terms of specific implementation (apart from the principles). I will add a summary of the main documents later.
In the most recent time I have been experimenting with various software tools for the task:
- bug tracking
- developmental documentation of tasks resolved.
- documentation in general
- testing and verifying software behaviour
- how to accomplish solutions which are operating system independent.
........
To develop all the details of this is going to be a lot of work, which is why collaborative efforts are crucial. One of the issues is persontime and funding and another is testing. As soon as I can reveal more details of the work plan and steps of this process the list will be informed. And interested persons invited to participate.
Ah, OK, I misunderstood - you are referring to adapting GCP principles to the software engineering of EpiData, rather than ensuring that EpiData meets the needs of those who are trying to practice GCP in their clinical work. Regarding the second aim, I think that a) those requirements cannot easily be described in a single document or set of requirements - it depends so much on the nature of the clinical work and the type of data and study designs being used, and no one software tool can every hope to meet all those requirements; and b) for many tasks within the scope of data collection and management, and exploratory data analysis, EpiData does a good job already.
Regarding the first goal, I wonder whether GCP documentation is the best place to look? There is a large literature on software quality and quality assurance in software engineering in the computer science literature - it might be quicker to consult that body of knowledge rather than trying to glean principles from GCP guidelines. I doubt that you will find much discussion of things like formal test plans, calculation of the coverage of unit tests, and the issues of testing "corner cases" and how to check for "numerical bruising" and other subtle computational problems in the GCP guidelines, but those topics are pretty standard in most texts on quality assurance and testing in software engineering - or so I am told. I have just been reading some lecture notes from some undergraduate computer science courses on these topics and found them very instructive and helpful indeed.
Tim C
participants (1)
-
epidata-list＠lists.umanitoba.ca