正如近幾年來炙手可熱的“自動駕駛”技術，通過各種傳感器如攝像頭、激光雷達、毫米波雷達等對外部環(huán)境進行感知并采集數(shù)據(jù)，通過數(shù)據(jù)存儲、數(shù)據(jù)預處理、難例挖掘、數(shù)據(jù)標注以及模型訓練這五大環(huán)節(jié)訓練感知模型，讓汽車看清并識別路面障礙，進而進行路線規(guī)劃和動態(tài)決策。

不少院長表示，隨著近幾十年來醫(yī)療信息化的發(fā)展，各家醫(yī)院的平臺建設和數(shù)據(jù)互通共享已逐步走上正軌。然而，擁有醫(yī)療數(shù)據(jù)是一回事，能把數(shù)據(jù)價值釋放出來又是另一回事，能持續(xù)不斷且高效地實現(xiàn)數(shù)據(jù)價值最大化則又達到了一個新高度。

（圖片素材來源于網(wǎng)絡）

而在過去的二十年間，醫(yī)療信息化的快速發(fā)展，一方面要打破數(shù)據(jù)孤島，實現(xiàn)數(shù)據(jù)互聯(lián)互通，另一方面又要在高速推進信息化建設的過程中避免流程操作的重復。我們不難發(fā)現(xiàn)，被寄于厚望的“數(shù)字化轉型”既不是快速見效的“救命稻草”，也不能拿來照搬“隨波逐流”，在醫(yī)院數(shù)字化轉型過程中必然會迎來業(yè)務流程重構的“陣痛”。

以前，我們普遍運用瀑布式開發(fā)模式來推進產(chǎn)品研發(fā)和運維。瀑布模型是最典型的預見性的方法，嚴格遵循預先計劃的需求、分析、設計、編碼、測試的步驟順序進行。瀑布式方法在需求不明并且在項目進行過程中可能變化的情況下基本是不可行的。雖然敏捷軟件開發(fā)以用戶的需求進化為核心，采用迭代方法進行解決了部分問題，但依然無法有效解決內容持續(xù)運營迭代的需求。

首先，我們來談談數(shù)據(jù)運營體系（DataOps），可以簡單理解為大家熟知的數(shù)據(jù)治理的工程化，旨在支撐數(shù)據(jù)應用大規(guī)模部署，本質上是要實現(xiàn)對數(shù)據(jù)端到端的全程管理，包含源數(shù)據(jù)模型、元數(shù)據(jù)、主數(shù)據(jù)、自然語言處理、數(shù)據(jù)質量管理、數(shù)據(jù)安全等方面。通過全過程的融合監(jiān)管一體化，實現(xiàn)數(shù)據(jù)運營的持續(xù)交付。這就好比汽車自動駕駛背后的“實時導航地圖”，汽車在行駛過程中需要持續(xù)更新收集“路況信息”，不斷調整“地圖”，為精準的路線規(guī)劃與導航打下數(shù)據(jù)基礎。

（圖片來源于網(wǎng)絡）

人工智能技術的成功，既要具備數(shù)據(jù)、算法、算力三要素，又要依托于強大的人工智能工程能力，才能讓復雜的人工智能技術大規(guī)模加速落地。人工智能模型運營體系（MLOps）是實現(xiàn)模型從設計、特征工程、模型訓練、模型評估到部署應用和持續(xù)優(yōu)化的一體化管理。我們再把目光轉向汽車自動駕駛，人工智能模型的“成熟度”——讓人工智能技術能夠大規(guī)?？焖俾涞厍页掷m(xù)調優(yōu)的能力將影響其訓練效率、訓練能力、訓練準確度等，最終決定汽車在復雜多變的路況下的應變能力。

（圖片來源于網(wǎng)絡）

上述兩個運營體系都是基礎性工作，而將數(shù)據(jù)洞察轉化為業(yè)務智能需要研發(fā)運營體系（DevOps）建設，實現(xiàn)應用開發(fā)、應用運維和質量保障部門之間溝通、協(xié)同和有機的整合。除了傳統(tǒng)的軟件功能版本更新迭代之外，更多的是業(yè)務內涵的持續(xù)更新迭代。比如針對單病種的全過程質量管理、臨床重點專業(yè)管理指標、臨床輔助決策知識規(guī)則等內容生產(chǎn)配置、版本更新，都需要自動化管理、發(fā)布和更新，運行性能監(jiān)測等。同樣的道理，對于汽車自動駕駛來說就是將“實時導航地圖”與“AI體系”的有機結合，確保一輛配置自動駕駛模塊的智能汽車能夠順利投放量產(chǎn)并持續(xù)進化迭代。

（圖片來源于網(wǎng)絡）