这篇文章里将会讲到如何从单纯的业务去逆推未来的产品架构，再从单业务线延伸的方向可以是SaaS、PaaS、业务中台等。从互联网医疗领域最简单的预约挂号功能的设计开始，所有是复杂的功能合集都是由简单的产品组成的，掌握了核心的底层逻辑，未来大部分产品迭代将会有较为稳定的思路。

　　①对于实体医院挂号对于实体医院的定位是医疗综合业务的开始、基础收入之一、流量入口；医院并不会过于关注挂号费用，而是关注挂号后到院就医的门诊量，医院的门诊量基本上相对固定的，大型三甲医院的年门诊量一般在100-200万左右。符合国家智慧医院的建设方向，是公立实体医院建设互联网医院的核心标准功能之一。

　　②对于互联网诊疗平台对于互联网诊疗平台（微医、微脉、好大夫等）来说，是流量入口，因为挂号收入全部是医院的，并不能从里面获取任何的收益。 相对于互联网营销、广告等，挂号功能对于互联网诊疗平台来说，就是用户刚需的功能，并且其实投入成本相对有限，和医院做挂号对应系统的1对1的对接，后期负责维护及跟进问题。但能带来流量，用户一定的粘性，获取用户的就医部分数据来进行分析，有利于未来对用户在药品、在线咨询、服务包等方面做推荐。

　　③挂号的其他理解及样板互联网医疗领域，挂号已然完全和互联网诊疗平台、互联网医院、区域卫健委主导的健康管理平台（政府自建和聚合）完全融合在一起，是最基础的功能之一。 互联网医疗行业的早期，是从挂号展开的商业模式，以互联网的思维获取流量，然后再叠加其他的业务和流量；但是，最后互联网思维，并未完全在这里展现，因为医疗场景的特殊性，更像是一种便捷工具，而且是企业基本没任何机会抽取挂号费用的费率，因为国家政策规定的所有费用都是直接到医院的，因此挂号功能的定位就很清晰，引流→转化其他商业模式，在线咨询、卖药、卖保险、保健等业务模式。微医的发展基本符合以上逻辑，最早成立于2010年，曾经就叫挂号网，以解决患者挂号难问题起家，是网络医疗领域的探索者，于2015年获得3.94亿美元融资后改名微医。 微医于2015年创建了全国首家互联网医院——乌镇互联网医院，开创了中国在线诊疗、处方流转、医保在线支付等新业态，被习在第二届世界互联网大会主旨演讲中称为“中国互联网创新发展的缩影”。核心业务覆盖医疗、医药、医检、健保等领域，是行业内唯一覆盖“互联网+医疗健康”全产业链的数字健康平台。

　　国家对挂号功能技术标准做了官方的定义及背书，中华人民共和国卫生行业标准WS/T 790.15-2021号文件《区域卫生信息平台交互标准 第 15 部分：预约挂号服务》里，预约挂号服务角色定义如下：

　　预约挂号服务（RRS）：提供预约排班信息管理、预约管理服务。包括预约排班信息提交、预约排班信息更新、预约排班信息删除、预约排班信息查询、预约申请、预约取消、预约查询、预约排班信息订阅，向预约排班信息提供者发送预约申请通知、预约取消通知，向预约申请者发送预约排班信息更新通知、预约排班信息删除通知； 预约排班信息订阅者（SISub）：为预约排班信息提供者及预约申请者订阅通知； 预约排班信息提供者（SIP）：提供预约排班信息，向预约挂号服务提交、更新、删除预约排班信息，接收预约申请通知、预约取消通知； 预约申请者（RA）：查询预约排班信息，申请、取消、查询预约，接收预约排班信息更新通知、预约排班信息删除通知。

　　国家卫健委在2021年11月08日发布的WS/T 790.15-2021号文件《区域卫生信息平台交互标准 第 15 部分：预约挂号服务》文件里，说明了预约挂号的角色官方标准定义。患者在里面的角色是预约申请者，医生是预约挂号服务的服务提供者，医院管理人员是预约排班信息提供者在业务里共同组成了挂号的业务。在互联网医院、互联网诊疗平台里更多的只涉及到患者、调取医院对应医生、医院、号源等信息来完成功能，这一些数据并不是凭空产生的，而是已经在运行很多年的。

　　患者在医院的APP/小程序/微信公众号上预约挂号，下单后订单返向互联网医院/在线诊疗平台，系统将订单反馈给医生，医生在诊室坐诊，到了预约当日患者到达医院，完成取号-签到-候诊-叫号后到达门诊室，由医生接诊，并在这样的一个过程中提供高度专业的医疗服务（诊断治疗、健康咨询、用药咨询等），医生开医嘱、治疗、开单后，门诊流程结束。 这项功能的业务管理一般在医院的HIS的医生管理后台，负责叫号、接诊、诊结、开医嘱、开药、开检查检验单等，一般医院都是有这样的管理后台的，基本不需要企业来进行开发。如果有在2022年的现在有企业要做这个功能，那绝大多数都是HIS重构迭代、医院综合管理系统或者门诊系统重构等项目，除此之外关于医生端的医生管理后台，是完全不需要仔细考虑的。因此，挂号功能的后台，基本上只会设置排班、业务开启关闭、订单查看、订单数据统计等功能，并不会很复杂。

　　一些特殊的情况： ①在医院看来预约挂号、当日挂号定义会不一致，预约（预约号源）指的是提前选择号源并且下单，并不一定需要支付；挂号（当日挂号），指的是选择当日号源，一般是需要支付的，并且只能到医院的缴费窗口进行取消； ②预约挂号，一般在挂号日当日0:00前可以取消，超过了以后只能到医院窗口处取；当日挂号，挂的是当日的号源，挂号后不能取消； ③医院的科室并不一定和国家标准科室匹配，可能科室、门诊制定并不会标准； ④支付预约费用的情况，在各家医院的情况不一致； ⑤互联网诊疗平台的挂号，是设计产品流程后，调用医院或者政府的统一挂号接口，来实现挂号功能，本质上来说是从医院HIS里调取接口，下单后再向医院传输数据； ⑥如果当日未能到院就医，并且订单没有取消，则会被记录到医院的黑名单，正常的情况来说，如果在几个月内超过3次违约，那就会在一段时间内无法到达该医院就医。

　　如果作为一名产品经理，将针对一家医院的定制化内容转化为最有利于公司发展的核心架构？ 由挂号衍生的医疗平台的业务中台思考，当医院慢慢的变多时，一定不可以是简单的进行好处理，而是需要一个架构，来让所有的内容标准化，然后才能快速接入到各家医院的业务。 凭心来说，这样的平台可以是卫健委管辖下的区域医疗聚合的平台，也可以是以互联网挂号、在线咨询、体检预约、专科服务结合的在线诊疗平台，同时也可以聚合处方外流等内容和业务，医院实际经营和平台之间会存在比较大的问题： 每一家医院都有结合着医院内部业务的功能——在线问诊、开药、检查检验预约、查报告等，怎么样才可以更好地实施呢？微医、微脉、阿里健康、平安好医生、好大夫等，是怎么样处理多家医院的预约挂号功能的呢？业务和医院关联度较高的别的产品，在线咨询、诊后随访、体检、检查检验预约等功能，又是怎么样处理的呢？

　　任何事物都是有规律的，即使是永远在做不规则分子运动的单个分子个体，当他们聚集足够多的数量时，不同分子为主导的物体也会表现为肉眼可见稳定的物质（水、铁、石头、塑料等）。 氢气和氧气在燃烧的条件下生成水并产生热量，医生和患者在医疗行为的条件下，最终组合成为了一些功能，实际他们的在本质上是不一样的，但是能将其想象成为化学反应公式，并且不单单是医疗领域，仔细思考也适用于其他大部分功能的设计。医疗产品设计方程式：有某种医疗需求的患者携带着一些信息，和医生在线上、诊室发生了反应，有一些医疗行为和医疗器械催化下发生了反应，最后标准化的数据、流程、行为就是所需要的功能。产品意义上的场景是，医疗行为+医疗器械，在公式里可以视为催化剂，没有了医疗行为和医疗器械，对应的流程将不会发生。

　　从某些维度上来说，氢气和氧气携带着很多H₂分子和O₂分子，和医生的基础属性+患者基础属性，在挂号的业务流程下，最终构成了挂号功能在某些逻辑上是能够寻找到一致性的。 举例，图文咨询：患者（基本信息、病情描述等），向某医院妇科专家付费咨询妇科疾病，医生在线接诊，在医院系统里调取患者门诊、住院电子病历了解患者疾病信息，和患者进一步沟通后，下达咨询建议帮助患者。

　　①患者的基础属性：姓名、年龄、身份证号、病案号... ... ②医生的基础属性：姓名、性别、职称、科室、医院... ... ③医疗行为：挂号是由患者预约医生的门诊服务，在线上下单后，在预约的到院日期到达医院后，取号就诊的医疗行为； ④医疗器械：取号机、签到机、叫号机等会在这一流程产生一定的影响；一般来说，挂号的功能，挂号成功之后，到院取号之后，挂号功能的流程就结束了； ⑤挂号到院取号之后的签到-候诊-叫号-门诊等行为是到医院后的门诊流程。

　　很多时候会好奇，前端怎么来实现页面交互逻辑的，后端研发是怎么来实现技术逻辑的，如何存储数据？刚成为产品经理的时候，由于多年做运营的经验，浅薄的认为，大部分移动端的业务流程，都是已经有了业务模式的前提下，前端带着字段、数据、规则向后端传输和调取数据。本质上来说，最初很多概念就在大脑框架中，就已经存在了技术范围、实现机制框架，只是没有系统的去整理。 产品的底层逻辑就是角色数据+属性数据+业务流程=功能，角色会有基础数据字段，业务相关的内容也会有基础数据字段，在符合该项业务流程里不一样的角色的行为们构成了业务流程，最终就形成了一个完整的功能。

　　这一类的调用方式，和做G端政府项目、B端少部分项目时是一样的。通过调取他们已完成标准封装的接口获取数据，然后再完成对应的功能开发。还有一种场景大家可能很少想到的，阿里巴巴、腾讯等作为总包，设计好了大型的中台体系，对内对外将复杂繁杂的业务相关的研发内容外包，由内外部团队去进行某些业务开发时，这些团队在做数据调用时也和这个类似。

　　①标准接口（内部）：满足这项业务流程时，所需要的数据合集，封装为企业内部定义的标准流程的接口； ②标准数据（外部）：经接口转换器将不同医院的挂号数据不同命名方式、状态变化方式，最终转化为的符合标准接口（内部）能完成业务流程的数据； ③调用方法（预约挂号）：1-在用户点击挂号功能后，调用医院科室-门诊等信息；2-用户选择科室时，会展示对应门诊；3-用户选择门诊后，调用未来7日门诊下坐诊医生的号源信息，并且进行展示；4-选择对应日期，展示号源满足该日期坐诊医生；5-选择医生后，调取对应医生的号源，选择对应日期-上下午号源后，调取当日-上午或下午的可选择号源；6-选择号源后，跳转确定页面，确定后在医院HIS下单，并返回下单是否成功状态；7-下单成功后，自动推送或调用获取到该状态；8-用户取号、取消挂号、违约等流程结束，号源释放回医院号源池； ④接口转换器：当用户行为发生明显的变化时，从标准接口的数据中，向医院数据库里发起符合挂号业务流程挂号方法1-8流程的数据请求，然后返回到标准数据库（外部）→标准数据库（内部），最终完成业务流程； ⑤单业务线的标准接口合集：多家医院接入时，工作将会变得简单；并且是经历过转换后的数据是互通的；

　　照葫芦画瓢去设计功能是初级产品助理应该去做的事，产品专家应当是去理解更深层级的理解，甚至能够基于理解去设计产品架构，以全局视野去匹配公司技术路径、业务路径、未来发展。有了一个良好的产品架构，能够让产品经理为主导的团队里，设计、技术等在混乱不堪的公司方向里，有一个清晰的未来方向，并能在设计. 具备了之前思维的情况下，再回过头看到UML知识的内容，才会深刻理解这样的思维方法，是符合技术的一些思考、表达方式的。然后，再把自己的理解，逆向推导及代入到UML的框架里做映照。

　　所有功能的技术实现都是能够直接进行分割的，只有在特定的场景下，孤立对象之间进行了某些信息交互才表现出我们所看到的那样一个过程。UML是描绘计算机语言实现产品功能逻辑的一个工具，本质上去认知业务流程，UML能够面向对象的分析设计方法。用不太恰当的话来说，属性类图、Person类图凝练为了数据库表单，构件图、部署图转换为了接口、技术架构、规范或中间件。

　　①活动图：多个活动和行为之间的顺序流程，和流程图很像； ②状态机图：针对做某件事、某个行为在不同的阶段具备不同的状态，状态变化的展示； ③顺序图：多个角色之间怎么样共同参与到这个业务流程里； ④通信图：表示不一样的角色之间传递信息，需求分析时较少用到； ⑤用例图：不同的角色能通过软件做什么事； ⑥时序图：某些事物伴随时间而变化的状态，比如订单15分钟未支付自动取消；

　　如何使用将思维嫁接入UML技术知识体系内，来思考产品架构呢？通过这样的思考，设计出来的产品大概率能够较为快速地让研发理解产品思维路径，较好的在同一个共同思考层级上做沟通。而且极为严谨，六步法走完，就可以基于全局意识下的对功能的业务流程、状态变化、数据传输、用户都能够做什么等进行设计。

　　①把多个人的行为按照事件发生的顺序写出来——活动图； ②并且思考归纳出，某些行为前后会产生的状态变化，并对状态命名——状态机图； ③将不一样的角色行为按照事物发生的流程关联起来——顺序图； ④角色在什么动作发生时会向另外的角色传递信息，信息是什么，才能让流程自然进行——通信图； ⑤归纳出不一样的角色在这套系统里可以做什么事——用例图； ⑥表示某东西的状态随时间变化而变化——时序图； 这是技术思维路径下对于产品功能设计的思考，极为严谨，更接近于代码实现逻辑机制；不同于于运营思维，从用户属性、商业模式、市场机会开始的思考，运营时考虑投入产出比、新增、留存、增长；也不同于产品思维，集中于客户的真实需求、用户习惯、客户的真实需求、新增-留存-增长，以实现C端客户的真实需求、B端客户的真实需求为核心。

　　①产品盘点：竞品分析，HIS底层数据盘点，卫生部官方技术文件，基于已有产品流程盘点； ②按照每个客户已有接口，对照及提炼内部核心，提炼不一样的客户的产品共性，合乎行业广泛适配性的标准流程； ③解析技术结构：完成企业内部能满足业务流转的接口封装，外部依据情况，定制化研发； ④实施部署：服务于技术可实施路径的产品架构设计，和技术讨论可实施性，符合技术需求的架构；

　　①业务盘点：行业背景、市场及客户，业务流程盘点，涉及字段-表单-数据的分析； 不熟悉业务流程，不知道涉及字段-表单-数据等，是没有资格进行产品功能设计的，除非是抄作业； ②产品设计：根据盘点的业务，设计产品流程，完成功能设计，产品流程是合乎行业广泛适配性的标准流程，提炼能够很好的满足技术路径的标准数据接口； ③解析技术结构：完成企业内部能满足业务流转的接口封装，外部依据情况，定制化研发； ④实施部署：服务于运营业务增长的产品架构设计，和技术讨论可实施性，符合业务需求的架构；

　　建立模型是人们解决现实世界问题的一种常用手段。我们一般接触到的建模是未解决某个问题而建立的一个数学模型，通过数学计算来分析和预测，找出处理问题的办法。从理论上说，建立模型是指通过对客观事物建立一种抽象的方法，用来表征事物并获得对事物本身的理解，再把这种理解概念化，并将这些逻辑概念组织起来，形成对所观察的对象的内部结构和工作原理的便于理解的表达。 使用参与业务模型的人，作为基础信息源自的提供者，使用业务流程的需求者，例如挂号里的患者，需要挂号获取医院号源；UML中采用Use Case来表示基础的驱动业务目标，假定为现实中能轻松实现的事；通过建立对应的业务场景、用例场景，这就是技术语言上的业务模型。

　　概念模型，UML通过概念化建立适合计算机理解和实现的模型，称之为分析模型；分析模型中有边界类、实体类和控制类。 边界类——大家所熟悉的界面操作，所有前端交互都在界面进行，而前端界面的操作行为将会怎么样影响后端数据库的交互方式。 实体类——可以看做是业务实体的实例化结果，映射了现实世界的业务中参与完成业务时设计的事务。 控制类——边界和实体都是静态的，本身并不会有动作，而控制类就是用来表示原始需求中的动态信息，即业务或用例场景中的步骤和活动，换成产品经理常见的语言就是，产品的业务流程、操作行为与之产生的关联影响。 在实际思考中，从业务路径的思维，转化为包含边界类、实体类、控制类的分析模型组合，再将分析模型组合凝练为计算机语言里的包、组件、节点概念，这样就最终转换为了概念模型。而产品经理里的业务流程、界面操作流程等，就是从这里简化为现实世界中的实物，通过对应业务流程、操作流程串联起来而产生的。