信息部门该如何规划CDR、ODR、RDR的裸金层？

目前，CDR、ODR、RDR的定位和作用医疗圈是有共识的，但是其建设方式、模式及数据交互方式尚处于百花齐放的阶段。不同的公司有各自的解决方案，不同的医院和机构也根据自己实际业务的需求和特点进行着有针对性的建设，所以我理解因为其建设的非标准化特性，希望有一种规划、或者一种模式把基础架构搭建起来，然后后续不再变动，不再调整，从而避免重复建设，这种本身是与信息化技术与发展的日新月异的特性和特点相违背的。当下，数字中国日益提上日程、物联网、5G的快速应用、区块链、数字孪生、人工智能等新技术与医疗的融合也将日益紧密，数据中台的讨论也不绝于耳。所以CDR、ODR、RDR这种适合当下的数据层架构和方法论是否适合未来3-5年的技术发展尚不可知，所以其基础架构的不确定性也更加不能形成定论。
目前就CDR、ODR、RDR的建设而言，个人觉得，应该把握几个建设原则。
第一，分类原则。不管技术如何发展，架构如何调整，数据的分类应该是不会有太大的调整。结构化、半结构化、非结构化，其适宜的存储架构是有明确的规范和要求的，数据的重要性与否，数据的响应时效要求，数据容灾要求，这些都是数据分类的具体指标，也为我们底层架构的建设提供指引，避免低需高配和高需低配的情况出现，保证需求和配置的相适宜；所以针对不同数据类型和数据要求，要有与之相适应的存储底层，故数据中心的裸金层也是存在多种架构存在的。
第二，可扩展原则。CDR、ODR和RDR，在建设初期，因为需求的不明确、中心数据的磨合、与各业务系统的交互和上层应用的梳理等原因，前期数据体量不会太大，随着业务的推进，技术、流程和方法的日趋成熟，需求也会处于井喷期，其数据增长也会指数型增长，原来的架构应该要充分考虑其可扩展性，以及扩展后保证数据性能、数据时效响应等方面不会下降。

没有一蹴而就的系统，也没有一招鲜吃遍天的技术；
针对临床数据中心（CDR），运营数据中心（ODR）和科研数据中心（RDR）不用的特点可以用不同的技术方法来满足要求；
CDR ODR更多是结构化数据，数据量相对较小，可以采用关系型数据库+SAN存储的模式；如戴尔科技PowerStore企业级全闪存存储；
RDR 涉及海量数据同时对算力要求非常高，可通过医疗数据湖+HPC高性能计算集群来满足业务要求；数据湖建设要考量海量数据复制迁移（多项目使用是否要拷贝多份）、生命周期管理（性能容量要求和建设成本的矛盾）；戴尔科技PowerScale+ECS数据湖方案可以实现整合应用、消除孤岛、提高效率、降低成本，并且有丰富的三甲医院案例，可联系我们当地技术支持人员做进一步沟通交流；

这种问题还需要讨论吗？肯定按照 CDR、ODR、RDR运行在什么DB上，根据DB要求、反应时间来选择存储。