临床受试者数据库管理平台

第一篇：临床受试者数据库管理平台

临床受试者数据库管理平台 主办单位：北京市科学技术委员会 承办单位：北京中兴正远科技有限公司 军事医学科学院附属307医院

培训由军事医学科学院307医院刘泽源教授主持，北京市科委曹巍处长；解放军总后卫生部药品监督管理局马金昌大校；解放军307医院张宏副院长等相关领导致辞，北京协和医院江冀教授对《规范加强受试者管理-北京市临床研究受试者数据库系统建设进展》进行详细的阐述，我公司陈总对各成员单位进行系统讲解。

临床受试者数据库系统在北京市科委大力支持下，得到北京协和医院、北京大学第一医院、解放军307医院、北京医院等多家单位的大力支持，从而组建了（北京G20平台）临床试验受试者数据管理中心。

目前系统已经在北京11家临床研究机构使用，本次培训对已经安装的单位和即将部署的单位进行系统的培训，得到了多家单位的一致好评；培训结束后，各成员单位参观了307医院的使用情况，并实际操作系统，系统的便捷性和易用性得到了各成员单位的一致好评。下一步准备在北京市科委的倡议下，结合京津冀发展战略，打造区域平台，为提高临床试验的质量提供服务。

【中兴正远视点】为进一步促进我国临床药理事业的发展，进一步保证受试者权益和临床试验的质量，由我公司联合在京的药物临床试验单位资源设立了“北京市新药临床研究受试者数据库”并制定了数据库公约。依托北京的专家资源优势，未来一段时间内，该系统将在北京29家临床药理基地部署，下一步京津冀地区受试者数据平台资源共享，并逐渐面向全国的临床药理基地推广使用。

第二篇：浅谈临床受试者的权益保护

浅谈临床受试者的权益保护

药物的出现无疑提高了人民的健康水平，改善了人民的生活质量，可是，大家都知道“是药三分毒”，因而一种药物从研发到上市需要经历重重的研究、临床实验、审批，最终才会到老百姓的手中，为老百姓治病。

可是，我记得以前看过的一个报道，2008年，安徽南山村的高血压者迎来了一批“送药送医”的“白衣天使”，一些自称是安徽医科大学专家教授的人进行了一项“为乡下老年人高血压患者免费送医送药下乡”的活动，他们所送的药药名为“依那普利叶酸片”，药瓶上写明了是“临床观察用药”，更荒谬的是，这些老人们竟然服用这种药服用了两年！我国2003年9月实施的《药物临床试验质量管理规范》明确规定,新药进入临床试验阶段前必须经国家药监局审批,并且只能在经过国家考核确认的临床药理基地进行,具体负责新药临床试验的医生也要经过国家特殊专业培训,经考核合格取得相关证书才能参与这项工作。同时,在规范第三章规定受试者参加试验应是自愿的,试验期间,如发生与试验相关的损害时,受试者可以获得治疗和相应的补偿,也就是说,新药的临床试验,必须与试药人签订知情同意书。而这群老人们却并不知晓“依那普利叶酸片”是临床观察用药，也并未签订任何知情同意书。我们都知道只要是药都有毒负作用，特别是新药的毒副作用有时是潜在的，必须让当事人知情，而且新药上市的程序非常严格，一般需要动物实验证明，药基本无毒有效以后，再在人身上做临床试验，然后国家才能根据结果批准是否上市。而且一些新药的试验周期长，要不断地观察分析，如果在试验过程中发现不良反应较多,国家就会取消该药的审批,哪怕是四期临床试验,如果达不到要求,也有叫停的。可见，国家在新药的上市前的临床试验还是非常严格的，毕竟这是关乎人的生命安全的大事。可是在这个案例中，那些老人作为“临床受试者”却得不到任何的保障，药监局也表示由于这种药标注的是临床观察用药，处于试验阶段，并没有国药准字号，还不能界定是药品，所以药监局无权管辖，找不到处罚的依据。而国家这方面还没有针对试药人人体试验方面的专门法律。同时,这一类诉讼面临取证难的问题,因为很难进行药理鉴定证明试药人确实是因为服用该药品引发了疾病。而同时据我了解，将农村作为临床用药受试点也是屡见不鲜的事。

同时，社会上还有很多为了临床试验的报酬而甘愿当“小白鼠”的人，他们的利益又如何保障？临床试验前，受试者要先填写一份《知情同意书》并领取体检表。《知情同意书》分为三部分：对实验项目的内容介绍、风险告知；对受试人受益部分的告知；告知受试者可随时志愿加入、随时自愿退出。而受试者也要在通过体检后才能试药，体检内容包括肝、肾、心电图、电解质、尿常规、血压等。同时会对受试者的个人资料和体检数据保密。可是目前很多临床试验单位在实践中并没有尊重，甚至侵犯受试者的知情同意权，隐瞒药物风险性、解释不清或只达成口头知情同意等。而我国目前还没有针对人体试药方面的专门法律，国内规范试药行为的只有一部《药物临床实验质量管理规范》，该规范并不具备强制作用，试药人与院方签订的知情同意书也存在漏洞。此外，规范对经济补偿金额并无明确标准。临床试验在我国已进行了几十年，但受试者仍处于弱势地位、无法得到保护。反观国外，世界医学会制订了《赫尔辛基宣言》，该宣言制定了涉及人体对象医学研究的道德原则，是一份包括以人作为受试对象的生物医学研究的伦理原则和限制条件。该宣言包括四项原则：对受试者有利、公正、尊重、不伤害。保障受试者的六项权益：生命健康权、知情同意权、自主参与权、隐私权、获得救治权、补偿权和损害赔偿权。

目前我国的医药行业正在迅猛发展，新药的研制也是很多制药企业研发的重点，而在医药业蓬勃发展的同时，希望国家也能采取相应措施，制定相应法律条例，保障临床受试者的利益，临床受试者是推动医药发展新进程的开拓者，也有可能是医药发展的牺牲者。切实保障临床受试者的权益，以最大的努力让制药方和受试者步入良性循环的轨道。

第三篇：借助邮政客户数据库营销平台

借助邮政客户数据库营销平台

打造湖北邮政发展的战略平台

时间：2008-10-22 15:18

通过客户数据的采集、维护、挖掘和使用，实现了对现有客户和潜在客户的集中管理；通过对客户有针对性地宣传、推介企业产品，激发客户用邮需求，实现营销目标，从而有效地扩大邮政营销业绩，提升支局的核心竞争能力。

支局将数据库建设与运用确定为打基础、管长远的一项重要项目。组建了项目小组，组长为支局长，成员支局窗口员口，努力构建数据库运用平台。着力落实“两手抓，两手都要硬 ”即:一手抓数据库的建设。主要以窗口用邮大客户进行名址、爱好等信息收集，另外项目小组上门收集辖区内居民、企业、学校等客户信息;一手抓数据库的营销运用。一方面“邮政数据库帮您找客户”，积极做好与企业、合作商的数据库营销的运用，拓展市场，实现多赢局面，另一方面为邮政企业自身重点业务发展，提供瞄准器，定点找客户，产生效益.整个建库过程中，我支局始终坚持“边建库、边营销”的工作思路，将建设客户数据库和开展数据库营销有机结合起来，收到了较好的效果。

1.2009年春节期间，支局组织开展了“打工数据库”专项营销活动，利用旺季营销的有利时机开展业务营销，收集、整理和完善城镇、农村数据库信息，取得了较好成效。“打工数据库”专项营销活动取得圆满成功，共收集打工人员信息10000条，寄递数据库商函8000万元，实现家乡包裹业务收入5000元，移动放号120万户，发放邮储绿卡1200万张，带动邮储余额增长900万元。

2.客户数据库营销。以数据库为营销的切入点，资源共享，实现多赢，成功的开发了三湖水湖贺卡1000枚，形成收入2200元数据库的建设与运用将是我支局的一项长期工作，数据库营销收入快速增长为目的。目前，我支局虽然迈出了数据库营销的第一步，但是这项工作仍然处在起步阶段，还有很多问题需要在实践中提炼、总结。不断的完善客户数据库信息化管理、维护和应用有助于我支局实现又好又快发展。

第四篇：数据库管理规定

数据库管理规定

第一章

总

则

第一条为加强联合信用评级有限公司(以下简称“公司”)数据库管理，保障评级数据库正常、有效运行，确保数据库安全，使数据库能更好地服务于评级工作，特制定本管理制度。

第二条公司系统管理员负责评级数据库的日常维护和运行管理。第三条公司总经理负责对数据库使用者进行权限审批。

第二章

数据的录入

第三条各业务部门的评级分析师负责评级数据库的数据录入工作，部门负责人为本部门评级业务数据录入工作的责任人。

第四条评级项目组负责人是其负责项目的评级信息录入工作的责任人。评级项目组在现场考察和访谈结束后___个工作日内，应将该评级项目的相关评级信息输入评级数据库。跟踪评级时资料有更新的，应在跟踪评级工作结束前将更新资料录入数据库。在资料归档前，评级项目负责人应对录入的数据资料进行格式和内容核查。

第五条录入的数据源主要包括宏观经济信息、行业信息、发行人基本信息、证券的基本信息、发行人生产经营情况和财务数据等，其中发行人基本信息和财务数据是必须录入的数据。

第六条数据库数据应严格按系统管理员下发的录入模板标准进行采集和录入。

第三章

数据库的使用

第七条根据评级业务对数据库用户管理的要求，公司应制定数据库用户管理制度和数据库操作规程。

第八条根据公司总经理授权，数据库用户权限级别分三种：普通用户、录入用户、高级用户。

第九条普通用户拥有查询、浏览、使用数据库中公开发布的各类数据的权利。

第十条录入用户除拥有普通用户权限外，拥有录入数据和修改本人录入的数据的权利。

第十一条高级用户除具有录入用户的权限外，经授权还具有修改本部门数据的权限。

第十二条根据工作需要经公司总经理批准用户权限级别可变更。特殊用户的权限设置应由公司总经理批准。

第十三条系统管理员负责按审批规定办理具体用户的授权、变更权限和注销等管理工作。

第十四条用户的密码管理应遵循如下规定：用户密码必须通过复杂性检验，位数不少于___位，并不得以数字开头;密码应定期更改;用户名和密码为个人专用，不得泄露给他人，特殊情况需要他人以自己的用户名和密码进入数据库时，应取得部门负责人同意，并在工作完成后及时修改密码。

第十五条所有用户均应遵守公司《评级业务信息保密制度》，未经许可不得对外提供数据库中相关数据，不得越权使用和修改数据。

第四章

数据库系统的修改和维护

第十六条数据库系统的修改，应在系统管理员征求各业务部门对于数据库使用的意见和建议并提出修改方案的基础上，由公司评级总监提出，经公司总经理签字同意后实施。可根据实际情况由公司组织人员修改(或重新开发)或委托外部机构修改(或重新开发)。

第十七条数据库系统的修改，应保证数据的延续性和历史数据的可用性。

第十八条业务人员在使用数据库的过程中，对数据库不完善或不方便使用之处，有信息监督和反馈的义务。

第五章

数据库的安全管理

第十九条系统管理员负责数据库系统的安全管理，保证安全管理软件的及时升级。

第二十条数据库应每周至少备份一次，系统管理员应在保证数据安全和保密的情况下，采取适当方式保存备份文件，保证数据库出现异常时能快速恢复，避免或尽量减少数据丢失。

第二十一条除系统管理员和经公司总经理批准的人员外，其他人员不得进入放置有存放数据库设备的机房内。

第六章

附

则

第二十二条评级业务数据在技术条件许可的情况下应永久保存。

第二十三条本制度由总经理办公会负责解释、修订。

第二十四条本制度于通过之日起执行

第五篇：数据库版本管理

简介

在软件开发过程中，版本控制是一个广为人知的概念。因为一个项目可能会需要不同角色人员的参与，通过使用版本控制软件，可以使得项目中不同角色的人并行参与到项目当中。源代码控制使得代码可以存在多个版本，而不会将代码库变得混乱，典型的场景包括Bug修复、添加新功能、版本整合等。

虽然在开发层面的版本控制软件已经非常成熟，但目前国内还没有专门针对数据库层面的版本控制软件来帮助不同角色的人员在数据库层面进行团队协作、变更代码管理以及对数据库的变更进行查看和比对。在数据库层面版本控制工具的缺乏可能会出现如下场景：

 无法在数据库层面进行团队协作：开















发人员A对存储过程的修改导致

开发人员B创建的存储过程被覆盖，从而无法比对和追踪

开发人员-开发DBA-测试人员难以协作：SVN等版本工具是基于文件的，很难在数据库层面进行版本控制

数据库发生的变更难以追踪：现有的技术无法追踪由谁、在什么时间、对数据库修改了什么，当发生由数据库引起的报错或性能下降时，难以排查

无法记录对数据库变更的过程资产：数据库变更的历史记录只有数据库运维人员了解，当该相关人员离职或调岗，这些过程资产难以继承

难以审计数据库：现有的数据库审计功能往往依赖于日志，对性能造成很大影响。

SQL脚本无法有效管理：现有的做法往往是将SQL以文件形式保存，无法有效管理和共享

无法查看被加密的数据库对象：当需要对加密的数据库对象进行修改时，如果无法找到对象定义的原始记录，则必须重写该对象

SVN建立和使用复杂：SVN使用流程对于数据库人员过于繁琐，为数据库人员增加了额外的工作负担 由于数据库是整个业务应用的核心，上述问题无论是在开发环境还是在生产环境如果得不到有效的解决，会造成生产力低下、过程资产无法得到管理、数据库审查无法进行、难以排查由数据库变更导致的问题等情况。

下面来介绍一下Source Safe for SQL Server如何解决该类问题。

软件的安装

软件的官网下载完Source Safe的安装包后一路下一步，安装完成后打开Management Studio，在需要加入到源代码控制器的某个数据库服务器上右键，在弹出菜单中选择“添加数据库到版本控制”，如图1所示。

图1.将数据库添加到版本控制 然后设置相关的选项，如图2所示。

图2.添加数据库到版本控制相关设置

现在再来看，整个数据库都已经在版本控制之下了，如图3所示。

图3.查看受版本控制的数据库

至此，Source Safefor SQL Server就安装配置完成了。

典型应用场景

Source Safe可以解决下述问题： 开发团队进行版本控制 在一个开发团队中，对于数据库对象的每一次变更都会自动覆盖上一个版本，导致上一个版本对象定义的丢失。比如说开发人员A创建了存储过程“ProcA”，然后开发人员B修改了存储过程“ProcA”，开发人员A创建的存储过程将会被开发人员B所做的修改覆盖，造成之前定义存储过程的丢失和无法回滚。使用Source Safe可以轻松解决该类问题。通过图4，我们看到存储过程“ProcA”由开发人员“Jack”创建后，开发人员“CareySon”对其进行了修改，Source Safe可以完整的记录由谁，在什么时间，做了哪些修改，如图所示。

图4.查看存储过程“ProcA”被修改的历史记录

图5.查看存储过程 “ProcA”两个版本的差异部分 开发里程碑标记

在开发过程中，往往需要对开发里程碑进行迭代，每一个开发里程碑导致的数据库对象变更都可以完整的被记录和文档化。

图6.里程碑版本以及涉及到的对象变更 生产环境变更管理

在生产环境中，程序的升级、程序或人为对数据库对象的更改有可能导致数据库出现问题，例如应用程序报错或数据库性能下降。通过SourceSafe可以快速比较出数据库之前版本和当前数据库定义中存在差异的部分，并根据具体情况回滚导致数据库出现问题的对象，从而快速排除错误并保证数据库持续稳定运行。如图7所示。

图7.选择需要版本比较的对象 常用脚本管理

无论是开发人员还是数据库的运维人员，都会有常用脚本需要保存。过去的做法往往是将SQL代码以文件的形式保存，这样既不方便使用，也不方便分类管理。利用Source Safe的代码管理功能，可以方便的将SQL代码的管理无缝集成到SQL Server Management Studio中。如图8所示。

图

8、使用Source Safe的脚本管理功能对SQL进行管理

此外，Source Safe特别设定了默认文件夹“工具栏快捷方式”，用户可以将频繁使用的SQL代码置于此处，在该分类下的脚本会自动出现在Management Studio的工具栏中，如图9所示。

图

9、将常用脚本置于“工具栏快捷方式”中 对选定的对象进行版本归类

虽然Source Safe每次同步之后都会生成一个基于变更的版本号，但在某些特殊情况下，比如需要对库中某些变更进行管理、对库中的版本进行归类的情况下会需要额外的标签。如图10所示。

图

10、利用标签标出某个业务版本涉及到的数据库对象 与SVN的无缝集成 SourceSafe的版本内容和历史记录可以直接导出到SVN、TFS、VSS中，从而打通数据库版本控制和现有的SVN系统。在数据库中我们对存储过程dbo.TestProc做了三次变更，如图11所示。

图11.对存储过程的3次变更 接下来将历史记录导出到SVN，如图12所示。

图12.将SourceSafe记录导出到SVN 导出完成后，通过SVN客户端软件可以看到对应SQL文件的在数据库中对应图10的三次变更，如图13所示。

图13.SVN对应SourceSafe中的3次变更

软件的下载

软件的下载可以在软件的官网下载，下载地址(http://?tab=sourcesafe-for-sql-server)。