Rostersource Architecture

Transcript

1. RosterSource Architecture
2. 2 Table of Contents  RosterSource Vision and Objectives  Overall RosterSource Architecture  Proof of Concept (PoC) Architecture  Technical Environment  Glossary Contact Us: Gunjan Siroya Gunjan.siroya@Netspective.com +1 (949) 236 7436 Lori Serafin lserafin@humana.com +1 (502) 580 2554
3. 3 RosterSource Vision - Business Objectives Vision: Consort with the brightest minds to collaboratively build an awe-inspiring solution that addresses the healthcare industry’s directory data quality deficiencies.  Make it easier for physician practices to communicate roster changes in a trusted and secure manner, without adding to the practice’s administrative burden.  Integrate with physician practices to obtain source-of-truth data, no matter where the data resides  Create operational efficiencies and savings for both data producer and data consumer.  The resulting solution is scalable, inspires enthusiastic adoption and is a springboard serving other business cases for value-adding services and products. Objective: Develop an open source solution that will enable data consumers to receive physician demographic updates near real-time via an online federated roster and attain  Highest accuracy – source of truth for public, directory-related information  Least disruption – no interruption in Provider workflow, annoyance avoidance  Regulatory compliance – fulfill CMS objectives for contact, effective process and consumer access
4. 4 RosterSource Vision - Network Layout PNA N (Payer Network N) EHR RCM HL7 EHR RCM HL7 PNA 1 PNA 3 PNA 2 PN 2 PNA 4 PNA 5 PN 1 PN 3 PN 4 NOTE: Provider data from any application in a practice or provider network can be shared or consolidated in to private RosterSource network for distribution with the supported plans. RCM RCM PROVIDER NETWORK 2 - ACO PROVIDER NETWORK 1 PNA 6 (Payer Network 1) IT Systems LEGEND: PNA: Provider Node Aggregator PN: Provider Node Provider = Physician Practice Payer = Health Plans IT Systems EHR PN 5
5. 5 RosterSource Vision - Network Layout Use Case AGGREGATOR NODE (PAYER NETWORK) IT Systems EHR PN 1 External Provider Data from Cloud* EMR* Provider CSV File PN 2 PROVIDER 1 WITH THREE DATA SOURCES PROVIDER 2 WITH TWO DATA SOURCES *PoC TEST DATA NOTE: Initial PoC will leverage OpenEMR product suite and NPPES test data. HL7 HL7 2.x Watcher with CEP knitting X.12 X.12 Watcher with CEP knitting** HL7 HL7 FHIR **Optional POC DEPLOYMENT NOTE: Node, Aggregator Node are copies of the same RosterSource software but configured differently depending on the role they need to play and policies of the organizations
6. 6 Provider RosterSource Vision - Architecture EHR 1 Custom RCM EHR 2 EHR Data Harvesting Agents RCM Other Sources EHR RosterSource Aggregator Agents (Data Normalization) RCM Other Sources Transform the Data into RosterSource common JSON format RosterSource Data Cleansing Agent Deduplication Data Cleaning Aggregated Data is cleaned after normalization RosterSource Local DB (Gun.JS) RosterSource Database (Gun.JS) Agent Updates the Local Provider DB Federation of Physician Data Payer 1 EHR EHR RCM CUSTOM XLSX CSV CSV FHIR if supported File Watch monitors and triggers Data Harvesting e.g. NPI Information Update Nodes in the Network Opensource Tools Used NodeJS - Open-source cross- platform JavaScript run-time environment Flow-based Agent Framework Local Provider Database Payer N Payer Provider 1 Provider N Peer Provider
7. 7 RosterSource Vision - Deployment Architecture Provider 1 RosterSource Node Provider 1 Private Network Provider 2 RosterSource Node Provider 2 Private Network APIs Payer IT Systems Write Only Write Only Aggregator RosterSource Node 1 2 3 Payer Network Gun.JS can be configured to accept data or only push the data. This will allow the network to be configured to only send data out but not receive, or send and receive with only configuration updates and no code changes. For POC it will be only Push from Providers.
8. 9 RosterSource Vision - Deployment Architecture Payer Provider 2 Provider 1 Node-RED & Nodes Node-RED & Nodes RosterSource Local DB (Gun.JS) RosterSource Local DB (Gun.JS) VM VM VM Node-RED & Nodes RosterSource Local DB (Gun.JS) Node-RED & Nodes RosterSource Local DB (Gun.JS) VM VM VM VM Legend VM: Virtual Machines
9. 11 RosterSource Proof of Concept (PoC)
10. 13 Proof of Concept (PoC) - Network Diagram AGGREGATOR NODE (PAYER NETWORK) IT Systems EHR PN 1 NPPES Cloud* POC DEPLOYMENT NOTE: Node, Aggregator Node are copies of the same RosterSource software but configured differently depending on the role they need to play and policies of the organizations OpenEMR* NPPES CSV File PN 2 PROVIDER 1 WITH TWO DATA SOURCES PROVIDER 2 WITH ONE DATA SOURCE *PoC TEST DATA NOTE: Initial PoC will leverage OpenEMR product suite and NPPES test data.
11. 14 Physician Data is spread across various sources in different formats PoC - Provider 1 Private Network Architecture EHR OpenEMR Data Harvesting Agents CSV Open EMR RosterSource Aggregator Agents (Data Normalization) CSV Transform the data into RosterSource common JSON format RosterSource Data Cleansing Agent Deduplication Data Cleaning Aggregated Data is cleaned after normalization RosterSource Local DB (Gun.JS) RosterSource Database (Gun.JS) Agent Updates the Local Provider DB OpenEMR NPPES CSV Physician 1 Physician 2 Aggregator Node in Payer Network This Provider 1 supports two Data Sources, OpenEMR and CSV file Gun.JS Listener OFF Node JS Provider 1 Private Network
12. 15 Physician Data is in NPPES (external system) retrieved using RESTful APis PoC - Provider 2 Private Network Architecture EHR NPPES Data Harvesting Agents NPPES RosterSource Aggregator Agents (Data Normalization) Transform the data into RosterSource common JSON format RosterSource Data Cleansing Agent Deduplication Data Cleaning Aggregated Data is cleaned after normalization RosterSource Database (Gun.JS) Agent Updates the Local Provider DB NPPES Cloud Gun.JS Listener OFF RosterSource Local DB (Gun.JS) Node JS This Provider 2 supports one Data Source from NPPES Cloud Aggregator Node in Payer Network Provider 2 Private Network
13. 16 PoC – Aggregator in Payer Network Architecture Gun.JS’s Listener is configured to access the data from Providers. Since there is no peer relationship established with Providers, no data is pushed between Providers Private Network 1 for Provider 1 Provider 1 Data RosterSource Node Private Network 2 for Provider 2 Provider 2 Data RosterSource Node APIs Aggregator in Payer Network (RosterSource Node) RosterSource Local DB (Gun.JS) Aggregator Agents Data Cleansing Agent Database (Gun.JS) Agent Gun.JS Listener ON Node JS Payer IT Systems
14. 17 PoC – RosterSource Deployment Architecture Payer IT Systems Gun.JS can be configured to accept data or only push the data. This will allow the network to be configured to only send data out but not receive, or send and receive with only configuration updates and no code changes. For POC it will be only Push from Providers. Provider 1 RosterSource Node Provider 1 Private Network Provider 2 RosterSource Node Provider 2 Private Network APIs Write Only Write Only Aggregator RosterSource Node 1 2 3 Payer Network
15. 18 PoC – RosterSource Deployment Approach  3 different deployment environments with common software components (Node)  2 for Providers  1 for Payer  Every deployment environment will be configured differently depending on the location of the node in the hierarchy and policy – Node or Aggregator  Node 1: In Node mode for Provider 1 Network  Node 2: In Node mode for Provider 2 Network  Node 3: In Aggregator mode in Payer Network  Monitoring and configuration software will ease the burden of deployments by mapping data with their sources and their status AGGREGAT OR NODE (PAYER NETWORK) IT Systems EHR PN 1 NPPES Cloud* Open EMR * NPPES CSV File PN 2 PROVIDER 1 WITH TWO DATA SOURCES PROVIDER 2 WITH ONE DATA SOURCE
16. 19 Technical Environment  The RosterSource Application is based on NodeJS framework.  RosterSource internally uses Node-Red for creating various agents (e.g. Data Harvesting Agents, Aggregator Agents etc.)  RosterSource internally uses GunJS as its local data storage.  Both Node-Red and GunJS will be installed when the RosterSource application is installed.  Pre-requisites for installing RosterSource - NodeJS (https://nodejs.org/en/, https://github.com/nodejs/node )  Libraries used by RosterSource  Gun JS (http://gun.js.org/, https://github.com/amark/gun )  Node-Red (https://nodered.org/, https://github.com/node-red/node-red )  Github is used for version control. List of tools/ software needed for RosterSource
17. 20 Glossary
18. 21 Data Harvesting Agents Definition  Specific to each Data Source format, there will be a Data Harvesting Agent which pulls data from the source and provides it to the respective RosterSource Aggregator Agent.  For example, there will be an FHIR Data Harvesting Agent which is capable of pulling data from a FHIR interface.  Creating multiple Data Harvesting Agents (e.g. FHIR Data Harvesting Agent for OpenEMR, SQL Data Harvesting Agent for OpenEMR etc. for the initial PoC) will be required for each of the Data and Data Source formats.  The output format of Data Harvesting Agents will be JSON. RosterSource Aggregator Agents process this JSON further.
19. 22 RosterSource Aggregator Agents Definition  RosterSource Aggregator Agents receive the data from the Data Source as JSON  RosterSource Aggregator Agents transform incoming JSON data in custom JSON format to RosterSource Common JSON format.  Specific to each Data Source format, there will be a RosterSource Aggregator Agent to transform the raw data that comes in from Data Harvesting Agents to RosterSource Common JSON format.  For example, a RosterSource Aggregator can filter out unwanted fields from the input and transform the data to RosterSource Common JSON format by renaming the fields as required.
20. 23 RosterSource Cleansing Agent Definition  Once the RosterSource Aggregator Agents transform the data received to the Common JSON Format, it requires cleaning.  The output of RosterSource Aggregator Agents is sent to RosterSource Cleansing Agent for performing cleaning operations.  The cleaning process is common for all data sources.  One example of the functionality of the RosterSource Data Cleansing Agent is the deduplication of Data in RosterSource Common JSON format.
21. 24 RosterSource Database (Gun.JS) Agent Definition  Once the data is cleansed, it needs to be stored in the local provider database (GunJS).  RosterSource Database Agent pushes the data received from RosterSource Cleansing Agent to the local provider DB in RosterSource Common JSON format from where it gets federated.