医疗保健研究和分析数据基础设施解决方案:用于医疗服务研究的数据仓库

简介

卫生服务研究是一个多学科研究领域，主要研究社会决定因素、组织结构和流程、技术、融资和报销、个人选择和行为对卫生保健服务的获取和质量以及个人整体健康和福祉的影响[1］．医疗服务研究的大部分数据来源是由医疗保险和医疗补助服务中心(CMS)提供的;然而，也有其他政府机构和非营利或营利性数据提供商提供的数据源。卫生服务研究人员，特别是使用二手数据的研究人员，可以通过使用合并数据集进行卫生服务研究来扩展他们的研究分析。由于缺乏单一的数据仓库，无法从以前完全不同的数据集中检索和分析数据，卫生服务研究人员被迫在每个单独的数据集上执行独立的、通常是冗余的数据相关任务。坊间报道表明，研究人员在数据准备上花费了多达60%的时间。充其量，我们可以将当前与数据相关的流程描述为低效、昂贵、耗时和繁琐[2］．此外，目前对这些不同数据集的不协调和孤立的努力可能是浪费的，因为它们可能会产生不可重复的研究结果，或者有时会产生误导，因为这些数据集中没有解决的固有问题。此外，如果没有必要的信息技术(IT)基础设施、分析和数据可视化工具，在这些不同的数据集中积累的日益增长的健康相关大数据的潜力仍将得不到开发[3.］．因此，需要一个网络基础设施，以安全和一致的方式集成这些不同的数据库，并提供必要的分析和可视化工具。

背景:围绕健康数据的系统

在其生命周期中，与健康相关的数据主要通过四种类型的系统，如顶部所示图1(改编自Ozaydin等人的研究[4])。患者级数据通常在操作系统中生成，这些操作系统分为临床、管理、研究和精准医疗系统，以及管理患者使用的医疗设备的系统。临床系统包括电子健康记录(EHR)中的所有内容，以及处理实验室、成像、医生记录、药物、病史、程序和诊断的系统，而不管它们是否属于电子健康记录的一部分。行政管理系统包括准入-出院-转移;计费、调度和索赔系统;还有一些不是专门针对医疗保健的系统，比如管理人力资源和工资的系统。与研究相关的健康数据由临床研究、临床试验和各种注册系统生成。此外，还有生成精准医疗数据的系统，如基因组学、音素学和微生物组，以及生成患者生成数据的系统，如移动医疗和远程医疗系统、物联网和其他数据生成医疗设备、社交媒体和患者门户。在一个数据生成系统中创建后，患者级数据通常在一个机构企业数据仓库系统中进行聚合。这些数据仓库通常作为机构数据分析和商业智能(BI)系统的基础设施，基于这些系统的报告和可视化系统(如仪表板)运行[4］．个别机构之外也有其他数据仓库系统，例如用于公共卫生目的的系统[5，6］．

‎ 查看此图

如底部所示图1的顶部部分所示的系统之间也有第二层系统图1．第二层系统包括决策支持系统、在第一层系统(即接口引擎)之间提供互操作性的系统、健康信息交换系统和机构数据仓库网络。如果需要使用实时数据，这些第二层系统更接近于数据生成系统。在不使用实时数据的情况下，这些系统依赖于数据仓库系统提供的延迟数据。随着决策支持系统的成熟，人们越来越希望尽可能实时地将结果提供给数据生成系统。迄今为止，已经开发了几个数据仓库网络，例如用于集成生物学和床边(i2b2)系统的信息学网络，称为共享健康研究信息网络，作为数据仓库网络，以集成从医疗保健实体的各种系统中提取的临床和管理数据。

医疗保健研究和分析数据基础设施解决方案的需求

到目前为止所描述的系统主要面向整合患者级的电子健康、账单和其他管理数据，用于临床和转化研究[2]，而不太关注组织级别的数据。第一层系统还包括生成总体级和提供级数据的系统，以及右侧所示的数据仓库系统图1．人口级仓库系统侧重于流行病学系统、管理国家和区域指数和调查的系统以及管理疾病控制和预防中心数据库的系统。提供者级仓库系统侧重于管理卫生服务管理数据的系统，例如质量度量、满意度评分、检查、财务绩效和所提供的服务。

除了用于患者级数据的数据仓库网络外，也有人试图创建综合数据存储库，以包括用于各种目的的卫生服务研究的选定数据源的某些部分(即研究数据援助中心[ResDAC] [7]和沃顿研究数据服务[WRDS] [8])。然而，我们没有找到任何成熟平台的证据，集成所有的目标数据源中提到文本框1或者在文献中创造这样一个平台的努力。大多数卫生服务数据继续积累并演变为各个政府或非政府实体内部孤立的数据筒仓[2]，而解释数据的研究工作也在各自为营。在这个时代，数据的生成超过了从中提取意义的努力，这些不协调的研究工作推迟了急需的研究效率的必要提高。因此，提高卫生服务研究效率需要一个平台，该平台有潜力整合不同的数据集和研究工作。

方法

本节介绍医疗保健研究和分析数据基础设施解决方案(HRADIS)平台的数据源和体系结构以及理论方向，并解释如何使用理论背景来为本研究的方法提供信息。

医疗保健研究和分析数据基础设施解决方案数据源和体系结构

为了满足上述需求，本项目旨在生成一个网络基础设施，首先使用Microsoft SQL Server平台创建一个数据仓库，以可靠、安全和一致的方式集成这些常用的健康服务数据源，然后构建一个BI系统，其中包括用于数据挖掘、分析和可视化的工具，如中所述图2(改编自克伦克和奥尔[9])。HRADIS的要素包括数据;元数据;数据和元数据的程序和应用;其他数据工具;以及用户、组和数据访问策略。如图2，有几个不同的数据交互领域。首先，数据与ETL(提取、转换、加载)流程交互，在ETL流程中准备数据存储在数据仓库中。接下来，数据仓库管理系统存储数据和元数据，并处理各种其他系统工具与存储数据之间的数据交互。最后，卫生服务研究人员与图形用户界面交互，通过数据挖掘和BI工具访问数据。HRADIS的第一阶段托管来自中所列数据源的数据文本框1．

‎ 查看此图

中列出的一些数据源文本框1已通过多个研究数据中心，如明尼苏达大学的ResDAC、宾夕法尼亚大学的WRDS和国家经济研究局(NBER) [10］．然而，这些研究数据中心不包括中列出的大部分数据源文本框1．他们主要提供关于特定数据源的培训和技术援助，如在ResDAC中CMS医疗保险和医疗补助数据，在WRDS中专注于非医疗保健领域，如财务和商业，或在NBER中改善现有数据源的可访问性，如CMS医疗保险成本报告(MCR)。还有商业数据中心，为个别医院提供质量、财务、住院和门诊结果的报告，如美国医院目录[11]或医院概要文件，例如医院数据[12］．然而，与HRADIS相比，这些商业数据中心并不全面，有些缺乏研究重点。

HRADIS的设计是可持续的和可扩展的，因此新数据源的包含和现有数据源的更新是有效的。这使得卫生服务研究人员可以将他们的模型应用于更新的数据或来自新来源的数据，而不必将新数据合并到他们的研究数据集中。

在解释伴随原始数据的复杂数据字典、布局和其他元数据元素时存在一个挑战，以便能够识别并可靠地提取给定研究项目感兴趣的参数。为了解决这个问题，HRADIS集成了元数据和ETL过程，ETL过程利用元数据根据元数据如何定义参数来识别和提取感兴趣的参数，而不是将元数据保存在单独的文件存储库或附带的文档仓库中[13］．为此，将源数据放入ETL任务的初始阶段，以填充基于实体关系图格式的关系型HRADIS数据模型创建的数据库表。此外，HRADIS还包括ETL任务的第二阶段，用于填充为最常用参数创建的维度和度量，以便更有效地执行基于星型模式图格式的多维HRADIS数据模型的数据挖掘、分析和可视化任务。换句话说，HRADIS受益于关系模型和维度模型及其图表表示的优势，如Corral等人的研究所述[14]及Schuff等[15］．

目前，我们已经将MCR、AHA、医疗保健提供商和系统的医院消费者评估(HCAHPS)、达特茅斯地图集、劳工统计局(BLS)和部分医院比较数据集与HRADIS加载，并已开始从多个数据源中提取数据用于试点项目。虽然纳入系统的大部分数据来自公众可访问的来源，但有些数据是受限制的。当我们用数据填充HRADIS时，我们也实现了系统的安全和数据治理组件。对于用户来说，安全性和数据治理非常重要，因为用户只能访问被授权的部分数据。

社会技术系统理论

虽然网络基础设施可以在以系统为中心的真空中设计和开发，但相关功能必须考虑用户的角色以及用户将如何与网络基础设施中的数据交互。考虑到人与技术之间相互作用的社会技术系统方法[16，17]因此是合适的，因为它促进了理论的发展，同时使系统设计者和开发人员能够纳入社会意识、组织行为或其他代表性不足的领域，例如文化，这可能是系统使用中的关键组成部分。许多工程系统创新在采用或使用方面失败，因为它们缺乏对必要和不可避免的人与技术交互的关注[18，19］．如果不认识到其社会心理影响，对现有实践进行各种改变的创新网络基础设施可能会失败。而且，在当今时代，社会与技术的不断共同进化[20.，21]，尤其是虚拟组织的出现[22]利用电讯技术的[23]或电子学习工具[24-26]，以及数字数据(即大数据)数量的激增[27]为系统开发人员设计用户友好、适应性强和复杂的网络基础设施带来了挑战。HRADIS考虑到直观的用户界面的重要性，这是认识到其用户的社会心理和教育背景。值得注意的是，要实现用户友好所要求的简单性的适应性和复杂性，可能需要在信息系统设计和开发过程中进行更多的投资。

作为概念框架的迭代过程模型

有多个数据库可用，但仍然互不相同，这使得卫生服务研究人员很难(如果不是不可能的话)开展具有普遍性和相关性的创新和严谨的研究并进行合作。文献提供了设计理论在关注工件开发中的设计过程方面的重要性的证据[28，29］．因此，我们使用设计科学过程框架来指导工件的设计，该工件旨在改善向卫生服务研究人员提供的数据，以便从业者更容易从见解和发现中受益。

设计科学是信息系统研究的重要组成部分，有望提高研究能力。通过工件创建，卫生服务研究人员可以立即访问多个和不断扩展的数据集，为以前认为繁琐和耗时的比较提供了机会。此工件可以是一个构造、方法、模型或实例化[30.］．本文重点研究了方法用于为卫生服务研究人员设计和开发数据仓库。

Offermann等[31他将设计研究过程综合为3类:(1)问题识别，(2)解决方案设计，(3)评估。本文介绍了信息系统的设计问题识别和解决方案设计类别。

文献提供了多种识别问题的方法[32，33］．从历史上看，访谈是与相关终端用户进行的，这样设计师就可以从用户的角度理解问题。此外，文献中先前的研究阐明了研究人员希望解决的问题。然而，最近，人们只需要阅读标题来识别问题:大量数据，在许多不同的地方，积累得非常快。有人称之为大数据但无论它被赋予什么标签，卫生服务研究人员都在呼吁有效的方法来清洗、组合、分析和可视化不同的数据集，以便于分析、协作、行动和发布。这样做有望分析和可视化数据组合，以揭示信息，当付诸实践时，可以给他们的组织带来竞争优势。

虽然有很多关于设计工程信息系统以接受数据的文献，但很少有文献关于设计针对不同健康数据集的解决方案的考虑，或者更简单地说，a如何方法(5，6］．

解决方案设计是演进过程的一部分，该过程有助于实现解决方案和一般系统分析和设计原则。Jonas提出的模型[34]，如图所示表1，适合作为面向卫生服务研究人员的数据仓库设计和开发的概念模型，因为它考虑到整个流程，并鼓励创造性的解决方案设计。在图3，设计探究的4个领域(分析、投影、综合和交流)表示为阶段设计的迭代宏过程，并全部用大写字母表示。4步骤而设计的迭代微过程(研究、分析、综合和实现)的重要性则是显而易见的用第一个大写字母和其他小写字母表示的．之前的每个微过程一步通知下一个微进程一步，如箭头所示。类似地，每个宏进程的输出阶段设计，它考虑设计的迭代微过程的每一步，然后通知下一个宏观过程阶段．微流程步骤和宏观流程阶段之间箭头上的虚线表示这是一个迭代过程。由于沟通是所有宏观阶段和微观步骤的驱动因素，这个连续的迭代过程用虚线圆形过程箭头表示。

12个阴影部分图3包含每个步骤发生的事情。例如，在分析/综合步骤中，需要理解当前相对于整体的情况。这个模型并不是完全规定性的如何这种理解发生了，因此允许各种类型的个性化设计过程。在迭代宏观过程的前两个阶段(分析和预测)中，模型允许从研究(收集关于问题的数据)到分析(理解那些问题)到综合(从看待系统作为一个整体的角度来表达问题，并将问题分配到类别中)，然后是实现(将这些问题作为一个问题/需求陈述来呈现)。前两个阶段之间的区别在于，在分析期间，模型允许我们关注当前的问题和需求，而在预测期间，模型允许我们关注未来的问题和理想系统的需求。在这两种情况下，最终产品都是各自类别中的问题的呈现。在SYNTHESIS阶段，所有从前两个阶段学到的知识都将用于整个系统核心功能的Research、Analysis、SYNTHESIS(或设计)和Realization(或开发和实现)，也就是系统的第一个版本。我们讨论了如何解释沟通方法部分。

‎ 查看此图

方法

与迭代过程模型一致的是，第一个阶段ANALYSIS是用数据理解当前状况，然后实现当前状况的可用表示。这可以通过以下方式实现:

• 研究:收集不同的数据、数据库、它们的元数据，以及卫生服务研究人员目前在处理这些数据源时面临的问题。
• 分析:了解每个数据库中的数据、结构和元数据，以及卫生服务研究人员面临的问题领域。
• 综合:从数据仓库项目的整体角度合并这些问题领域以及我们对数据和元数据的理解。
• 实现:为项目创建初始问题声明和需求文档。

表1给出了这个过程相对于数据仓库项目的ANALYSIS阶段的总结。

一旦认识到第一阶段，即分析数据、元数据、不同数据库及其结构和演变到目前为止，以及将它们用于卫生服务研究的问题，就应该考虑第二阶段，即预测，或者HRADIS的理想状态是什么。迭代设计过程中的第二个宏观阶段与项目的未来需求有关。首先，在Research步骤中，我们收集关于额外问题和需求的数据，这些问题和需求可能是Analysis阶段的分析、综合和实现的结果，以及关于源数据库及其结构的未来添加和更改的数据。接下来，在分析步骤中，我们根据在研究步骤中收集的信息来理解理想系统的未来需求。第三，在综合步骤中，我们进一步将未来需求综合为未来可能的场景。最后，在实现步骤中，我们根据数据源和系统用户的预期需求提出项目目标。表2相对于HRADIS项目的投影阶段，给出了这个过程的总结。

迭代(宏)流程设计的SYNTHESIS阶段考虑HRADIS如何处于可用状态。首先，研究步骤考虑到之前的分析和预测阶段的实现，以告知关于HRADIS项目第一个版本的需求的数据收集，该版本解决了其核心功能，并了解其未来功能将是什么。其次，分析步骤包括通过为这些核心功能创建流程和数据模型来理解核心功能的需求。第三，综合步骤涉及设计解决方案的创建，最后，实现步骤涉及这些核心功能的开发和实现。表3本文介绍了相对于HRADIS项目的SYNTHESIS阶段的这一过程的总结。

沟通阶段允许理解推进项目的过程，并包含迭代设计的其他3个宏观过程阶段。沟通阶段的主要前提是随着迭代过程的发展保持整个项目团队在同一页面上，并且设计不断地变化。考虑到社会技术方法，沟通还包括系统及其用户和利益相关者如何交互。

顾名思义，模型是水平和垂直迭代的(因此箭头表示迭代运动);因此，它允许连续更新其中的每个阴影框图3当我们增加对需求和项目设计的理解时。

结果

本节介绍了迭代过程模型在HRADIS问题识别和解决方案设计研究过程中的应用。

迭代过程模型-阶段1:分析

作为研究步骤的一部分，我们下载了原始数据文件和数据布局和/或数据字典(元数据)文件，用于从以下数据源发布的所有可用数据，这些数据源是卫生服务研究人员最常用的:CMS MCR、影响/最终规则文件、HCAHPS、区域卫生资源文件、AHA年度调查和IT补充、达特茅斯地图集和BLS。与迭代过程模型一致，目标是从单个数据库中的所有数据源捕获数据和元数据，而不改变源数据结构。通常，给定数据源的数据和元数据文件结构在各个版本中基本是一致的。在特定数据源的发布中，有一个或多个数据文件以及一个元数据文件。对于特定数据集的最新版本中包含的每个数据文件，我们在数据仓库中创建了一个表，将表命名为与数据文件名称相同的表，并使用与其数据源对应的前缀。如果以前的版本包含了最新版本中没有的数据文件，我们也可以用同样的方式为额外的数据文件添加表到数据仓库中。以CMS MCR数据源为例，最新版本包含三个数据文件，分别是ALPHA、NMRC(数字)和RPT(报告)。一些早期版本有另一个名为ROLLUP的数据文件。对于这4个数据文件中的每一个，我们都创建了以下表，其中使用MCR前缀表示它们的数据源，并使用HOSP前缀将它们与其他健康组织类型(将来可能包括这些类型的MCR数据)区分:MCR_HOSP_ALPHA、MCR_HOSP_NMRC、MCR_HOSP_RPT和MCR_HOSP_ROLLUP。类似地，我们为元数据文件创建了一个名为MCR_HOSP_DATAELEMENTS的表。

在将数据文件中的数据导入到数据仓库之前，我们为每个表创建了一个额外的列来存储发布信息。然后，我们将数据文件中的数据值导入到它们对应的表中，将多个发布文件合并到一个对应的表中。如果可能的话，我们对元数据文件重复相同的过程。上述过程产生了一个包含来自所有数据源的数据和元数据的数据库，这些数据源的不同版本合并到相应的表中，并保留了它们的版本信息。尽管来自不同来源的数据还没有作为集成数据库关联在一起，但拥有这样的数据库可以更好地理解源数据结构以及随着时间的推移对数据结构和元数据的更改，还可以在查询级别集成来自不同来源的数据，并能够保存查询逻辑。最后，这些手动导入过程为将来版本的导入任务的自动化提供了信息。

对数据、元数据以及卫生服务研究人员确定的问题和问题的分析有助于为综合步骤提供信息。在这一步中，我们考虑了问题的类别，每个类别对应于整个系统的一个模块(以设计为中心的综合和问题分类)。结果，在ANALYSIS阶段的实现步骤中，我们生成了HRADIS应该解决的问题列表，如中所示文本框2．

作为实现步骤的一部分，我们还基于上述问题陈述开发了需求文档，如中所示文本框3．

迭代过程模型-阶段2:投影

假设投影阶段处理的是理想的在研究阶段，与其他卫生服务研究人员的合作对于查明潜在的未来问题和需求以及更好地理解假设的二级数据分析研究项目的一般工作流程非常重要。

对从Research步骤收集的信息进行分析，可以深入了解HRADIS的目标和用户场景。这些将系统视为一个整体的见解的综合导致了PROJECTION阶段的实现步骤，在该步骤中，我们确定了理想数据仓库的任务和目标列表，如中所示文本框4．

此外，在实现步骤中，我们承认社会技术系统理论，该理论建议通过始终考虑最终用户的需求来开发技术。相对于这个项目，汇集各种数据源将产生成千上万的变量和度量。此外，筛选数千个变量可能会非常令人沮丧，除非通过考虑卫生服务研究人员的需求来简化这一过程。因此，为了实现研究项目的无缝开发，允许通过分类法直观地浏览和过滤元数据的界面是HRADIS的一个重要特性。与生物分类法类似，数据分类法也基于某些共同特征分离数据元素，简化浏览[35］．为此，我们开发了一种数据分类法(表4)结合我们自己的经验，从CMS医院比较网站[36]，以及卫生服务研究人员经常使用的等级分类[37-42］．这种分类法被合并到元数据表中，本质上是动态的，这意味着一个数据元素可以分为几个类别。换句话说，设想的用户界面将为卫生服务研究人员在分类数据元素方面提供一定的灵活性。这一过程体现了使用启发的研究模式，并随着使用和应用的增加促进了分类学的进一步增长和发展。

PROJECTION阶段的实现步骤的另一个产品是用于健康服务研究人员和系统管理员用户角色的高级用例。用例分析用于系统分析和设计，以记录每个用户角色与考虑创建的系统之间的交互[43］．用例分析通常在需求定义和用户角色确定之后执行。然后用例用于创建流程和数据模型。对于健康服务研究人员用户角色，用例包括浏览数据元素(元数据)而不创建项目、浏览已完成的项目并通过编辑选择一个项目来创建新项目、检索给定项目的数据以及创建新项目。类似地，对于系统管理员用户角色，用例包括创建系统规则、编辑系统规则、管理用户凭据、管理用户组以及管理用户和组权限。

举个例子，图4显示研究人员用户角色的随意格式用例，该用例不包括输入/输出数据元素及其源/目的地。

迭代过程模型允许考虑理想的在早期设计过程中。因此，考虑促进医疗服务研究人员用户角色的以下未来状态用例的决策支持工具:(1)浏览适当的数据分析方法，(2)选择适当的数据分析方法，(3)浏览数据可视化方法，以及(4)选择数据可视化方法。

‎ 查看此图

迭代过程模型-阶段3:综合

考虑到SYNTHESIS阶段的重点是真正的,它的研究步骤从分析和预测阶段的实现步骤(最终产品)的结果中收集信息，以开发即时使用的实际解决方案。对初始问题陈述和需求、用例、未来需求和系统目标的分析表明，任何实用的解决方案都必须平衡用于当前研究项目的优先级数据请求的时间和开发数据仓库基础设施所需的时间投资。

在实现步骤中，我们为实现HRADIS的第一个版本及其核心功能的计划制定了流程。然后，我们扩展了这个过程，包括高级步骤，以实现一些未来的功能，如数据分析和可视化模块。图5解释这个过程的步骤，也可以描述为系统模块，为什么考虑每个模块背后的原因，以及每个模块所涉及的任务。迭代过程模型支持部分阶段完成来开发一个即时使用的系统，同时在迭代环境中构建其他功能。因此，只完成了Synthesis阶段的Analysis、Synthesis和Realization步骤的各个部分。到目前为止，我们已经实现了的前三个模块图5．

‎ 查看此图

在这个阶段，为了更好地理解源系统中的数据和结构，我们还没有为HRADIS创建多维数据模型(多维模型可以更快地分析和输出大型复杂数据集)。相反，我们将源系统的数据模式保持在原始状态，并且表的创建只考虑原始数据和元数据表(中的第一项)图5)．这些表稍后将根据新的多维HRADIS数据模式将数据馈送到表中，该数据模式的数据模型将作为Synthesis步骤的一部分进行设计图5)，并将作为实现步骤的一部分来实现。作为过程的一部分，我们将来自AHA、Dartmouth Atlas、MCR、Hospital Compare和HCAHPS数据源的所有版本的数据合并到数据库中各自的表中。通过这样做，我们已经遇到了数据预处理和清理任务的例子，可以从中学习并在未来的迭代中应用。由于这些例子包括卫生服务研究项目的典型任务，为这些项目确定通用解决方案有助于隔离ETL流程、HRADIS多维模型的维度和度量，以及作为开发下一步的一部分需要创建的数据分析和可视化工具。

讨论

主要研究结果

这项研究为开发数据仓库系统作为支持卫生服务研究的基础设施的过程和方法提供了理论基础。本文讨论了在数据处理的获取、提取、预处理、清洗和过滤阶段，卫生服务研究人员之间存在的低效率、不同和不必要的重复工作以及缺乏协调。为此，我们将HRADIS设想为一个全面服务的数据仓库，集成了常用的卫生服务研究数据源、流程和方法，以及各种数据分析和可视化工具。结合社会技术系统理论的概念迭代过程模型框架为设计过程提供了指导。我们提出了迭代过程模型的4个阶段(即分析、投影、综合和交流)的应用。在以下各段中，将讨论几个突出的问题，并提供佐证例子、经验教训、反思和建议以及今后的考虑。

在迭代过程模型的应用方面(图3)纳入HRADIS的开发，为综合ANALYSIS和PROJECTION阶段提供的指导是相当重要的。传统上，一些系统开发策略建议在第一个版本中开发和实现系统的核心功能，然后在后面的阶段或版本中添加其他特性。然而，迭代过程模型为在开发各个部分时考虑整个系统提供了坚实的框架。使用该模型，PROJECTION阶段指导我们在为第一个版本设计系统的核心功能之前，分析系统理想状态的未来需求。这使得设计人员可以得到投影阶段的预期最终产品的通知，从而导致在合成阶段的设计考虑立即使用的解决方案包括理想系统的目标，其中一些目标将在未来设计和实现。

当一个小规模的开发团队只有几个成员时，正式的沟通可能就不那么重要了。在这样的环境中，团队自然地处于持续的沟通中，并且能够利用敏捷开发方法，在敏捷开发方法中，立即需要的特性被分析、设计和实现。所实现的特性满足了当前的需求，之后可能会经过轻微的修改，使之一般化并适合更大的项目。这也是HRADIS项目最初实现的方式，通过为即时研究项目创建临时数据提取、转换和加载过程以及查询。另一方面，与更大的团队合作，需要更正式的沟通，以建立对当前过程的共同理解，以及对更大过程的认识是项目。如前所述，系统如何与一般意义上的用户和涉众进行通信，以及在此特定上下文中的通信是至关重要的，例如，当请求将新数据源包含在仓库中时，以及当从系统请求数据提取时，系统与其用户之间的交互。

结论

在HRADIS的发展过程中，发现了一些值得进一步探讨的问题。我们相信，对于那些考虑尝试类似项目的人来说，下面的经验教训、反思和建议将是有用的。

首先，无缝进展需要在当前/紧急需求和推广正在考虑的解决方案之间取得平衡。为了达到这种平衡，我们在SYNTHESIS阶段通过认识到质量和成本之间的权衡，开发了实用的解决方案。对一个特定问题的高度一般化的、可重用的、质量更好的解决方案的时间投资，从长期来看会节省时间，但它的机会成本是，不把特定的时间花在多个效率较低但有效的临时解决方案上，这些解决方案可能在短期内产生结果。例如，当我们在一项研究中考虑了AHA数据中基于县、卫生服务区域(HSA)和卫生转诊区域(HRR)代码的医院的各种地理分类时，我们发现了数据中的缺失值，并考虑了几种计算缺失代码的方法。我们面临着一个决定，是创建一个包含所有可能的方法来计算缺失值的通用解决方案，还是创建一个特定于我们当时正在进行的试点项目的临时解决方案。与特定解决方案相比，通用解决方案需要更长的时间投资，具有用于许多研究的潜力。在这个特殊的情况下，我们选择实现通用的解决方案，因为重用的长期好处超过了延迟对特定试点项目使用HRADIS的机会成本。然而，这些类型的决策必须在个案的基础上加以考虑，因为决策将强烈地依赖于通用解决方案的潜在重用和特定研究的紧迫性。在对此类权衡进行决策时，还应该考虑临时解决方案在开发通用解决方案时的潜在好处，因为临时解决方案有时会提供所需的知识库和设计人员与数据之间的亲密关系。

第二，中提到的静态与动态数据导入的问题文本框2是一个重要的考虑因素。在开发数据导入的通用解决方案时，我们意识到需要两种不同的数据导入过程方法。这种需求是由于数据源的固有差异造成的。前一种方法是静态的，因为数据源本身是静态的，这意味着一旦发布了数据，数据的内容就不会随着时间而改变。后一种方法是动态的，因为数据源本身是动态的，这意味着数据会定期更新，甚至对于数据的归档版本(即年份)，内容也会发生变化。动态数据源的一个很好的例子是CMS MCR;早几年的报告可以在结算后重新开放，甚至存档数据也每季度更新一次[44］．在我们的例子中，从静态数据源导入数据并不需要太多的工作，因为为导入任务创建简单的SQL脚本就足够了。从动态源导入数据需要编写SQL存储过程，以自动化和简化每季度的数据导入过程。这一过程实现了我们的最终目标，即提高研究效率，减少花在冗余任务上的时间。

第三，如中所述文本框3，在设计这样的数据仓库时，团队可能会考虑利用不同数据源来改进数据的潜在方法。在我们的例子中，有时相同的变量或度量存在于不同的数据集中，或者来自另一个数据集。为了增强数据的完整性并解决任何缺失值问题，我们通过比较并最终输入缺失值来检查两个数据集。例如，在开发某些度量时，如Herfindahl-Hirshman指数，我们需要使用某些地理市场区域名称，如HSA、县或hrr。然而，由于现有数据集中某些年份的信息缺失，我们意识到有必要检查原始数据源(Dartmouth Atlas)。进一步研究表明，可以通过开发一种利用原始数据源和现有数据集的信息的算法来估算缺失的信息。

第四个教训是关于迭代设计过程的重要性。概念迭代过程模型框架改编自Jonas [34在HRADIS的开发过程中非常有用。尽管迭代的来回运动最初可能被认为是低效和耗时的，但它们对于开发长期有益的广义设计解决方案至关重要。尽管开发一个响应紧急数据需求的系统很有诱惑力，但我们发现坚持迭代过程模型是必要的。这样做与我们的同事建立了一个发展期望。

在未来，我们计划通过借鉴成功的增长战略和研究电子数据捕获(REDCap)的故事来改进HRADIS。这样做考虑到HRADIS和REDCap都是学术研究的产物，都有雄心勃勃的目标，但由于资源有限，它们开始时规模很小[45］．我们计划与有潜在贡献的研究人员合作，要求他们与我们一起概括他们的贡献，以适应HRADIS框架。通过这种方式，贡献者将可以访问所有HRADIS产品，而现有用户群将可以访问新的贡献者(在数据治理限制范围内)。