当前位置：首页 > article >正文

工作记录 2017-01-25

article 2025/3/18 15:37:41

工作记录 2017-01-25

序号

工作

更新的问题

1、BillingJobPoster

1.1、修改了Demographics.CSV导入的Last Name、First Name的bug。

1.2、修改了InsuranceMas、DocMas、Facility的处理。

1.3、导入PatVisit时，改为只填充 “atnd_dr”。

1.4、增加了FIles的导入。需要导入的文件复制到“[设置中的导入目录]\files”目录下。导入的文件可以在Summary中看到。

2、修改了DataExport和配置文件。增加了MR#的处理。

3、Web的修改

3.1、修改了To Be Billed、Online Billing、Missing Info、Historical Job List的Insurance Name列。

3.2、当Doctor’s office 用户登录时，Missing Infos、Rejected、Denied/Partial Payment、Follow Up的Check列，改为可以New，增加了Notes输入框的宽度。

3.3、Historical Jobs的Biller Name 改为 Biller’s Initials。

3.4、修改了登录页面。

关于医生使用的EHR开发的想法

   一个适应于小诊所日常业务的EHR系统，再加上我们已有的Billing服务和Transcription服务，就可以为小诊所提供一个完整的解决方案。我们不需要做那种大而全的适应于不同规模的医院和诊所的系统，而是着眼于852这类的诊所（几个医生，也没有什么IT部门的）。我们需要实现的就是一些诊所日常使用的模块。我们的客户也就是这种类型的诊所。

  诊所EHR系统的开发和我们的Billing系统开发是有很大不同的。Billing的系统是在我们公司内部使用的，所以，可以频繁更新（貌似有点过于频繁了），即便是，有些业务细节不是很清楚，也可以先写程序，写错了再改。数据库结构都是频繁修改（曾经连续2个星期，每天都在新加字段或者新加表）。我们在开发Billing系统时，力求“快”，有好也有弊，好处是在很短的时间内适应了850、852这两家诊所的业务（虽然一路上小问题不断）。坏处是程序里面很多地方不合理也比较凌乱（一些地方，我在写程序之前就没真正理解业务，写完了再改，有时改几遍）。给医生使用的EHR系统是不可以这样的，在开发时要贯彻一个“稳”字。有一个试用的客户，不容易。我们的系统能够在这个客户那里真正的用起来，这个客户用了我们的系统，还有个好的反馈。这是最最理想的情况，最糟糕的情况是“用不起来，口碑还坏了”。医生有着自己的圈子，如果一个医生对我们的系统评价很差，在这个圈子里的其他医生可能都会拒绝我们的系统。我们的诊所EHR系统，在给诊所上线之前，必须是一个可用的（基本功能完整，流程清晰）、简单易用的、bug很少的系统。依据网上的统计，在开发中，大约每写30-100行代码，就会产生一个bug。在之前的Billing的开发中，有时，我一天写的代码超过2000行，再加上sql脚本和更新说明，算起来bug真不少。我每天睁开眼，就用手机打开邮箱，看看昨天的更新是否出现了大问题，如果没有问题:“好吧，可以再睡15分钟”。实际上，目前上我们的Billing系统上还有着很多bug，只是不太影响主要操作而已。对于诊所的EHR系统，如果医生在工作时，遇到了bug，我们就会很被动，解决这些bug需要时间，这会耽误医生的正常工作，如果数据出现了问题，对真实数据进行调整，也有很多风险。

   在诊所的EHR系统的工作上，可以分三部分：
1、系统设计：
这部分是整个工作中最重要的部分，要理清业务和需求。有些功能，看上去很美，但不是小诊所必须的功能，我们可以先跳过，以后再开发。有些功能实现起来很麻烦，但是，医生日常工作中需要这个功能，再困难，我们也要开发。整个业务上要完整，基本功能不能缺失。在理清业务需求后，就可以开始每个功能的设计，如果条件允许的话，可以设计的细致一些，例如：
u  页面的布局是怎么样的，可以在页面上看到那些内容，有没有滚动条，滚动条的处理是如何的（会不会出现横向的？会不会出现两条纵向的？等等）。不同的屏幕尺寸下，如何自动适应？
u  确定页面上的各种标签、文字、提示信息的内容，不能出现拼写错误，尽量专业。提示信息也尽量准确，医生一看就懂。
u  确定页面中各数据项的输入方式，是单行文本输入框，还是多行文本输入框，输入框的最大长度是多少?(Billing系统为了图“快”，其实很多地方都没处理，例如这个输入框的最大长度。有一次，有个Claim在CMS1500中不能保存，就是在页面上的数据项19的输入框，没有设置最大长度，数据库的字段原来是 varchar（63），那个Claim 当时要录入的文本有70多个字符，结果就保存失败了。其实这页面也压根不是我们自己写的，这个页面是从office ally上另存的，1万2行代码，里边大部分的地方，我现在也不清楚，有趣的是，在里边的js代码中，有些注释写着：“我也不清楚为什么要这样写，以前的程序员联系不上了”)。对于可以选择的数据项，是用下拉框，还是弹出一个搜索框，或者是一组RadioButton。等等，总之页面上的各项数据，最好能有一些相关的说明。
u  设计好的操作方式，例如，页面打开时焦点的位置。快捷键的处理，回车键和方向键的定义。那些地方有自动查询。那些地方有自动提示。在一个页面中可以对那些数据进行操作，数据修改了之后，那些地方自动刷新。（在很久很久以前，我为了摸清一些医生的操作，我在医院里穿着白大褂，待了几个星期，有时还直接替医生录入数据。然后经过反复揣摩，设计了操作方面的各种细节。用了公司的程序之后，医生每天可以节省大约半小时的时间。这样，医生就接受了我们公司的系统。）
这些设计，在预定的时间内，尽量多做。通过这些设计，在程序上线之前，我们就是知道：“我们要做什么，做出来之后的系统是什么样子”。大家也可以进行交流和讨论，不必等程序开发。

2、测试及其他：
这个工作分“程序开发前”、“程序开发中”和“程序开发后”这三个阶段:
u  程序开发前：按照系统设计，整理一些测试案例，例如，一个简单的病人首次就诊的例子，这个例子的测试脚本里，包含了病人的基本信息，医生的操作等，录入那些数据，正确的结果是什么，都要写清楚。然后，多设计几个案例，通过不同的案例，涵盖整个系统的所有功能。整理这些测试案例，特别是那种复杂的多次就诊，各种操作都有的案例，是需要很多时间的，尽量在程序开发之前就开始处理，等程序出来了一部分，就可以先测试的。另外，在程序开发时，这些案例也有很大的用处。在这个阶段，还可以准备一些字典数据。程序开始时用得上。
u  程序开发中：这个阶段，主要是配合程序开发，进行同步测试。另外，可以整理一些文档。
u  程序开发后：这个阶段，主要是整体测试。是上线前，最最重要的一个环节了，要花大力气在这里。另外还有操作文档了，演示视频等等。

3、程序开发：
先把数据库中需要的表的结构和关系做好，然后开始每个页面的开发，开发时，业务逻辑尽量的封装在数据库中。避免那种很多行的函数，重要的地方多加点注释。多记录一些日志（操作日志和程序错误日志）。

就工作量而言：系统设计占40%，测试及其他占30%，程序开发30%。
就时间顺序来说：“系统设计”先启动，大约启动2-3周后，“测试及其他”再启动。这是程序还没开发，测试需要做的是根据“系统设计”来准备测试案例。准备一些字典和文档。“程序开发”可以在这时同时启动，或者再拖后1-2周。具体看当时的情况。
就参与人员来看：“程序开发”肯定是由程序员来负责的。“系统设计”和“测试及其他”是可以大家都参与的。特别是在“系统设计”，交流和讨论是很有意义的。