无创通气

VentialtorEntity

action/consumer:接口调用、监听数据、监听扫码、监听呼吸机调整完成等

可改善点1、呼吸机参数修改是否完成不驱动流程运行【但是和无创治疗主题是否偏离】2、将呼吸机实体独立，若以后有需要呼吸机的地方也可直接复用3、tips和dialog转为使用继承的实现，可重写compare【原因：    1、当多次下发处方时，可重写compare，加上settingversion的判断。      2、第一轮滴定结束，第二轮开始，重写compare，加上round的判断。维稳           的提示同理】4、当在维稳或滴定阶段，手动改了呼吸机回到滴定是否需要重置治疗前后数值，去除【已发送评定结果..提示】5、OSA、流程更新、扫码主动更新这三种有事件能够直接知道，但是无法直接知道是不是直接改了呼吸机参数这种情况，导致需要很多条件来判断现在是不是手动直接修改了呼吸参数【是否是调节状态，是否同步的参数和下次期待的参数是否一致，但仅靠这两个条件时，一开始的下发参数又会混淆进来，无法区分是不是一开始的下发参数导致的参数同步，又需要加一个变量】

CooditorEntity

1、完成状态的跳转【通气适应等】2、完成同步呼吸机参数的更新，同时需要判断此时是什么行为导致的呼吸机参数更新【OSA、流程更新、扫码主动更新等】，同时作出相应的响应【最难判断的地方】

NPPVControllerEntity

呼吸机参数更新

目前该类的作用比较薄弱，设想将此类变为和NPPVControllerEntity同级，由NPPVEntityl来直接调用，然后通过NPPVEntity作为中介来控制流程类

流程完成返回到上层

1、不同情况的提示清空，有不同的清除法，当暂停时，如果此时已经发送了结局判定，这个提示不能被移除，有新处方提示不能移除等等

将行为传递到流程中

app

NPPVEntity

完成tips等行为

1、在接收到呼吸机参数调整完成的事件时，需要更新流程状态，比较难判断