6.4本地化制定流程
根据上面形成并建立的基于FHIR的本地化实施步骤。将FHIR本地化主要分为四大步骤。整体步骤如下所示：
6.4.1 需求分析
需求分析主要目的是为了理解信息交互的业务场景和需求，通过需求分析，可以对业务交互事件或服务进行抽象，比如患者注册可能在很多的系统之间需要进行交互，通过对业务事件的抽象，可以减少对相同内容交互的重复定义。另外，通过交互事件的分析，可以识别出系统之间需要提供哪些接口能力，比如新增患者、患者更新、患者合并等。
需求分析阶段主要涉及三个活动：用例分析、数据模型分析及FHIR资源分析，用例分析以用例模型和交互模型的形式存在，用例模型识别出交互各方的角色，交互的事件等，交互模型定义了交互双方需要交互的操作及内容，以及操作的返回等。一旦识别出双方交互的内容后，我们需要对交互的内容进行详细分析，包括交互的数据元素，每个数据元素的数据类型、长度、默认值、相对应的数据字典、基数、与其他对象之间的关系等，该过程产生的是。最后将定义好的数据模型和FHIR资源进行一一对比映射，通过该活动，识别出在潜在的FHIR资源，以及每一个FHIR资源在应用过程中的约束和扩展。
此阶段主要是将每个场景中的数据集结合医院的实际交互场景交互的数据集，确定数据模型；最后将数据模型的数据元素与FHIR标准资源中的元素做映射，并梳理出需要扩展的业务元素及需要定义的ValueSet值集，形成《FHIR资源映射关系表》。
6.4.2 资源模型设计
资源模型设计阶段会根据需求分析阶段的《资源映射关系表》的分析结果，利用Forge工具（Forge是一个专业创建、编辑和验证Profile、Extension等文件的工具）定义出相应Extension扩展文件、ValueSet值集文件，结合医院设计交互场景，在标准元素Profile文件基础上引用相应的Extension扩展、绑定相应的ValueSet值集等约束操作生成特定医疗场景下的Profile集成规范文件。
通过前面的需求分析阶段，我们已经分析出了需要使用的FHIR资源，以及每一个FHIR资源应用的进一步约束和需要扩展的地方，在这个阶段，需要针对所有需要扩展的部分进行扩展定义，扩展的定义将以独立扩展资源存在。针对应用进一步约束，需要针对每一个资源定义Profile，比如约束基数、值集、强制性等，Profile的定义也是以独立的StructureDefinition资源存在。详细流程参考下列图示。在该阶段会产生三个最重要的成果，分别是扩展标准库、值集库和Profile标准库，这三个库的核心目标是开放定义成果，避免重复定义或相同概念定义的潜在冲突。
6.4.3 交互设计
此阶段需要确定FHIR资源的交互方式。FHIR的交互方式有四种：RESTful、Messages、Document及Service。此阶段主要任务为资源的API定义及查询参数定义。
交互设计用来识别出交互双方使用哪种范式进行交互，比如API、消息或者文档。如果选择API的方式进行交互，那么还需要识别出支持哪些API接口，比如：POST、PUT、GET等，针对一些特定的需求，还有可能需要定义Operation，比如患者合并，同时针对一些特定的查询，还可以定义查询条件。交互设计能力的产出是一个CapabilityStatement资源。详细流程参考下列图示。这一阶段的最主要成果是交互能力定义库。
6.4.4 规范发布
通过之前的三个步骤，已经设计并形成了包含Profile集成规范、API接口说明的FHIR 规范文件，如需发布使用还需要进一步细化交互规范明细，形成系统间交互文档。经过评审、修改完善及对四个场景的交互验证，最终进行规范发布。
总体流程图如下所示：
（撰写人：首都医科大学附属友谊医院 王力华 张光亮 范益辉 北大医信）