本记录中的FHIR是针对于截止2018年2月28日的FHIR3版本。
一、讨论主题
如何将FHIR中的organization的设计应用在系统中？
二、参与人员
三、会议时间
2018 年 2 月 28 日 9：00 至 11：20
四、会议共识
- 组织概念 ：organization的中文理解为组织，组织是为实现某种形式的集体行动而成立的正式或非正式承认的人员或组织集团。按照此定义，医院系统中的机构、科室、病区都属于组织。组织organization要和地址location分开，具体参照FHIR标准。
- 分层约定： 对于系统的实体对象来说可以按照FHIR对象设计。我们系统架构分为应用层与服务层，服务层返回FHIR对象，以便以后对接应用层是前后端的交互层，需要前端与应用层开发人员约定统一的VO对象，应用层开发者从服务层取出的FHIR对象建议封装一层，避免前端嵌套调用取得对象的属性。
- 组织实体类：组织实体类是一个顶层的实体类，有共同的属性。机构、科室等应该继承于组织，再分别定义自己的属性。对于数据库的设计来说也是同样的设计，暂定设计见附件。
- 组织联系人：按照FHIR的设计，机构联系人是可维护的，体现在页面上是可以选择的，而实际上我们是直接填写的。即使联系人作为FHIR网状结构的一个网点，像这种没有数据来源的对象按照FHIR的设计也是不符合我们的需求，所以我们数据库针对于这种情况，约定每个业务表维护自己的联系人表，比如病人的联系人维护自己的联系人表。
- 地址：组织地址(1对多)与联系人地址(1对多)在FHIR中指向的相同的实体对象，对于数据库不能这样设计，如果地址表设计一个组织ID字段，设计一个联系人字段，地址作为一个网状点，需要设计很多个ID字段，其实这样也没有达到网状的设计理念。经过讨论，暂定各自维护自己的地址。比如组织维护组织地址表，联系人维护联系人地址表。由于地址中的省市区在FHIR实体中只有一个字段，而在我们系统中实际上是由编码和对应的值组成的，所以在设计中的将这几个属性拓展了。
- 期间：组织的联系人的期间，在不设计为单独的一张表，设计为联系方式表的字段。
- 冗余字段：冗余字段需要在中文备注的表现出来，方式为字段备注后面加上 “（冗余）” 字样。
晚上心得体会补充
- 设计理念：对于FHIR对象需要多个工程可能都要用到的，用一个工程存放这些对象，比如Address对象，可以放在core工程里面，在项目初期如果不能及时按照FHIR设计所有的对象，可以逐步添加到工程中，这就需要开发人员形成一个意识，用到一个fire对象时先看core工程里面是否有这个对象。
- FHIR对象：对于服务层返回的FHIR对象，尽量与FHIR标准一样，举例，Address对象，在FHIR标准中这个对象的省市区是三个字段，而在我们系统设计中，这三个字段分别还对应着自己的编码，那么如果我们要返回对象则是继承于原FHIR对象的扩展后的子对象。
- FHIR设计领域思想：老总在晚上心得分享会上明确，我们不一定完全按照FHIR设计类、数据库，但是我们要掌握FHIR这种设计的思想，比如，各自维护一份自己的联系人表、地址表也是可以的，如果完全按照那样设计，可能还是一个失败的产品、项目。
2018/3/1 更新
- FHIR对象的设计：在设计组织的过程中，发现organization其实上面还有两层，DomainResource、Resouce，保存了一些资源的定义，由于暂时没有找到具体的用处，所以暂时设计不考虑上面两层；再说organization内部的包设计，我们可以按照FHIR资源首页中架构设计，比如包路径
fhir.resource.base.entities.organization
一般来说要比FHIR对象是不足以完全满足系统中的数据的，需要我们扩展，此时我们设计的包路径就是这样子的
fhir.extend.base.entities.organization
现在的问题是如何拓展FHIR对象？我们暂时想到了两种思路，第一种新建继承于FHIR对象的拓展类，有个问题，假如我们再与其他系统对接的时候会，我们会返回这个拓展类，这种情况很多，而其他对应商并不知道这些类，我们还得出相应的对接文档，这样实际上并没有把FHIR作为共同的设计文档设计。第二种将新建的拓展类设计成FHIR对象的属性，拓展类里面在设计你相关的数据类型，举个例子，在我们系统中的organization这个FHIR对象需要有共有属性organizationCode,并且组织是有机构（institute）和科室（department）等子类的，那么我会在organization对象里添加一个OrganizationExtend对象的属性,在OrganizationExtend对象添加组织共有的属性比如organizationCode,子类institute对象和department对象，department科室对象假如有自己单独的比如床位数的属性就就可以扩充了。OrganizationExtend对象可以扩充很多属性，我们觉得这样的设计是很好的，服务层也可以返回的也是FHIR对象。
2018/3/2 10:00PM更新
- FHIR对象的设计(推翻第11点）：关于如何拓展FHIR对象的问题，先不考虑厂商对接的问题，对于系统内部设计，公有属性可以放在FHIR对象中，需要拓展的私有属性用继承的方式。
- 数据库对象与FHIR对象的设计：mapper层返回FHIR或者FHIR拓展的对象，可以用mybatis的collection多层嵌套。这样可以没有数据库对象。
- 数据是否有效：active表示是否有效，作为一个基本属性、字段设计。在数据库表中，active代表原来的status字段，针对于mysql存储TINYINT(1)类型表示布尔值，true 和 false 分别被对应为1和0；在实体中，active属性是布尔值。在业务中，active更接近与删除状态的意思，不能用其表示暂停等意思，如果FHIR中有status属性，那么也要按照FHIR中这个属性含义设计status属性、字段。
2018/3/2 13:40PM 重大更新
- 推翻上面一切设计：阿里的人上午来指导了，指出我们是不是曲解FHIR意图了。FHIR实体是FHIR实体，我们不应该在其上面扩展，所有对FHIR对象的操作应该单独的，是一个工程，拓展的应该是单独的一个local工程，中间用FIRE对象的ID管理。然后FHIR工程和Local工程共同组成应用层所需要的，对于数据库的设计暂时没有定。
五、会议遗留
无
六、附件
