这是一篇开放获取的文章,根据创作共用署名许可协议(http://creativecommons.org/licenses/by/2.0/)发布,该协议允许在任何媒体上不受限制地使用、分发和复制,前提是要正确引用最初发表在《医学互联网研究杂志》上的原始作品。必须包括完整的书目信息,//www.mybigtv.com/上的原始出版物链接,以及版权和许可信息。
智能手机和平板电脑等智能设备已经成为日常生活和专业应用中不可或缺的一部分。医学也是如此[
为了解决目前在向应用的潜在用户提供应用信息方面的不足,Lewis在最近给JMIR的一封信中提出了一套标准标准[
虽然这肯定是一个有前途的方法,但我想补充几点。首先,在一个国际环境中,用户来自不同的背景(很多情况下是非专业的),很难将他们引导到一个独立的平台,而不是用户所习惯的标准应用发行平台。对于休闲用户来说尤其如此,他们可能倾向于使用应用商店中现成的信息,或者只是阅读其他用户对应用的评论。
在我看来,在整个过程中不应该忽视用户本身,因为他们在将手头的信息应用到他们感兴趣的产品上,并评估产品是否满足他们的需求上,扮演着重要的角色。与其他医疗产品(如临床使用)不同的是,许多专业用户面对的是由专家标记为适当的已经选择的产品,许多专业人员或外行人必须自己决定医疗应用程序的适当性。因此,特别是应用程序,确保患者安全还必须包括识别正确的产品,在这种情况下是应用程序,符合所需的设置和适应症。涵盖必要方面的每条信息都有助于决策者和/或专业环境中的最终用户以及私人使用的终端用户确定一个应用程序是否可以信任和安全。因此,为了确保高影响力,在用户期望的地方提供适当的信息是有意义的(例如,直接在应用商店的应用描述和/或制造商的主页和/或营销材料上)。这应遵循一个标准化的结构,其中包括具有明确理由的标准(
已经有一些现有的计划和项目使用了与Lewis建议的几乎相同的标准,例如,2013年由《医学互联网研究杂志》(JMIR)推出的“应用程序同行评审”[
如果制造商在应用程序概要之后发布必要的信息,他们和用户显然都将受益。用户将收到一组完整而容易理解的信息,这将在他们的决策过程中提供支持,而制造商将能够遵循概要的简单结构来编译必要的信息,而无需花费太多精力,因为他们只需要编译他们应该已经可以获得的信息。虽然这并不等同于官方认可的认证过程,但如果双方之间有任何争议,根据概要发布的信息仍可作为参考。
评估健康应用程序和医疗应用程序的标准。
标准 | 内容 | 基本原理 |
印记 | 关于制造商/分销商和联营商的信息 | 保持联系,确定赞助商和所有相关方的利益冲突(影响) |
应用的元数据 | 获取关于应用程序现状的基本信息 | |
基本原理 | 描述应用程序的预期用途、目标用户、应用程序的专用设置、医疗/非医疗应用程序的分类 | 了解应用程序背后的思想,专业层面上的分类,以及理想的部署设置和应用领域 |
功能 | 对应用程序的功能和特性以及限制和限制的描述 | 了解实现应用程序目的的基本功能及其限制和风险,以评估应用程序使用是否安全 |
关于采取了哪些措施来确保应用程序的良好可用性的细节 | 了解在开发周期中针对特定目标群体应用的可用性所采用的方法 | |
效度和信度 | 该应用程序基于信息源的描述和可靠性 | 评估内容及其作者是否可靠,以及功能是否基于可靠和有效的信息源 |
质量保证方法的描述 | 评估应用程序制作过程中的质量水平 | |
数据申请和管理 | 对正在收集和处理的数据的数量和类型的描述 | 能够确定应用程序的数据收集和处理是否足以满足规定的目的 |
数据保护和隐私 | 关于制造商遵守数据保护和隐私法律法规的情况以及所涉及的司法管辖区的信息 | 了解制造商是否提供符合应用程序用途的隐私声明和数据保护政策 |
数据传输与存储 | 描述为保护委托给应用程序的数据而采取的所有措施 | 评估数据传输和存储是否得到充分保护 |
健康应用程序和医疗应用程序的应用程序概要项目的详细说明。
项目类别 | 清单项目 | 子产品 |
1.印记 | 1.1元数据 | 1.操作系统 |
2.版本号 | ||
3.Web链接(项目页面和应用商店链接) | ||
4.类别:商业项目,非商业项目,其他 | ||
5.类别:通过应用商店的公共访问,只提供给有限数量的用户/专家(内部),其他(请注明) | ||
1.2开发人员/经销商 | 1.关于制造商/开发人员的信息 | |
名称、地址、网页、联系人、电子邮件地址、电话和传真号码 | ||
2.关于分销商的信息 | ||
2.1名称、地址、网页、联系人、电子邮件地址、电话和传真号码 | ||
1.3赞助/广告 | 1.用于开发应用程序的资金信息 | |
1.1类别:赞助、广告、其他 | ||
2.基本原理 | 2.1类 | 1.类别:是否医疗产品,如果是:是哪个类别;应用程序是自愿认证的(谁认证的?),未认证的应用程序 |
2.2用户组 | 对于每个用户组: | |
1.特定疾病/状况(或作为替代/补充:针对哪些保健专业,等等) | ||
2.性别、年龄(范围)、其他描述性项目 | ||
2.3设置 | 1.临床,门诊设置,在家里,其他 | |
2.典型“用例”的简短描述 | ||
2.4目的 | 1.对应用程序目的的简短描述 | |
2.类别:信息,参考工作,教育资源,文件,诊断,治疗,预防,研究,其他 | ||
3.应用程序的基本描述,包括用户组的特定信息 | ||
3.功能 | 3.1功能和特性 | 对于每个可用的功能/特性: |
1.函数(指定) | ||
1.1的例子 | ||
1.2源(年代) | ||
1.3分类:科学接受的、最新的内容,并反映当前的科学和技术状态,如果适用,证据水平 | ||
3.2约束与限制 | 1.应用程序的限制和限制 | |
1.1应用程序的限制和限制的具体描述 | ||
1.2对用户组潜在或现有风险的描述 | ||
1.3已采取的规避用户群体风险的措施 | ||
2.已知的不良影响 | ||
2.1不良影响的详细描述(如有) | ||
3.3可用性 | 1.在开发周期中使用的方法 | |
1.1可用性测试结果 | ||
4.效度和信度 | 4.1内容 | 1.负责应用程序内容的专家的信息 |
1.1作者姓名 | ||
1.2对专家资格的描述 | ||
1.3描述潜在或实际的利益冲突 | ||
2.关于整合到应用程序中的所有内容和算法的来源/引用的信息 | ||
2.1信息源的具体信息 | ||
2.2信息源的证据水平 | ||
3.关于该应用程序的研究 | ||
3.1研究类型、参考文献/文献、其他证据 | ||
4.关于应用程序的其他材料(测试报告等) | ||
4.1附加材料的类型、参考链接、…… | ||
4.2质量保证 | 1.关于开发过程中使用的质量保证措施的信息 | |
5.数据申请和管理 | 5.1数据处理 | 1.数据处理 |
1.1应用中集成的数据采集机制信息 | ||
2.数据保护和隐私 | ||
2.1自愿参与任何数据收集 | ||
3.数据传输与存储 | ||
3.1数据收集的目的 | ||
3.2谁从收集的数据中获利 | ||
3.3收集的数据种类和数量,在什么时间(包括适用的时间间隔)? |
||
3.4使用了哪些方法来存储和评估数据? | ||
3.5关于用户获取关于其所存储的任何数据的信息的权利的细节;此外,必须有方法撤销已经授予的存储数据的权限。为此,必须指定联系地址。 | ||
3.6还必须能够删除已经存储的数据,并且必须通知用户在真正删除数据之前所需要的时间跨度。 | ||
3.7在传输、存储和评估过程中保护用户数据的加密方法和级别。还应该指定是否可以将特定用户连接到存储的数据,或者数据是匿名存储的还是匿名存储的。 | ||
3.8说明是否有可能防止数据收集和/或传输,如果有,如何防止。 |
本文没有获得任何资金或赞助来源,也没有财务披露。由于没有涉及人体实验对象,伦理批准被认为是没有必要的。
没有宣布。