WIXLIB

In alignment with general enterprise plans to leverage contract renewals or replacement, DSHS is already planningfor the replacement of ACES, whose eligibility function was assessed in the SS-A. It is worth noting that DSHS isreplacing the aging technology which supports, not only Medicaid eligibility, but also fulfilment of required Federaland State programs included in cash, food, medical, and child care. Toward this monumental effort, DSHS isadopting FEAF with plans to make MITA framework the core process model. The MITA TMS has the opportunityto leverage this redesign to drive urgency of enterprise planning. In addition, DSHS expressed an interest in havingthe state-wide OCIO assist in aligning other state agencies to adopt FEAF and MITA.HCA is documenting its enterprise architecture model in ABACUS, including business, application, data, andtechnology layers. It has the flexibility to transform elements over 100 industry standard modeling frameworks andnotations, including TOGAF, PEAF, FEAF, etc., and can use different model for any layer or partial layer. Thistool provides flexibility to adapt HCA’s models to various enterprise architecture standards.Performance Management ValidationMonitoring and managing systems’ performance is conducted by the systems’ owner. For larger systems,performance is validated contractually. For ProviderOne, this is contractually based with CNSI. The performancereport includes service level agreement against performance benchmarks and queries for expectations, such asresponse times and reliability. Similarly, ACES, has contractually based performance service level agreements withIBM. The performance benchmarks evolve over time and contracts updated. Not all systems have performancemanagement reports, principally with internal systems. Efforts are prioritized on business critical systems.Service Hub Architecture PracticeProviderOne is a modular, web-based J2EE compliant system that utilizes an Oracle RDBMS as the back enddatabase engine. The system leverages an Enterprise Service Bus (ESB) to interact with COTS products and webservices to facilitate data sharing across business entities and trading partners. The ProviderOne businessarchitecture aligns with MITA core business areas and provides the flexibility to support efficient operations. Thecore system includes the conventional six subsystems of an MMIS, namely: recipient; provider; claims processing;reference file; surveillance and utilization review; and management and administrative reporting. Also within thecore of business processing is a Rules Engine.ProviderOne interfaces with the ACES that was recently remediated and enhanced to include a modular EligibilityService (ES) that determines eligibility for new Modified Adjusted Gross Income (MAGI) based Medicaid clients.The ES interfaces with Washington’s state-based Health Insurance Exchange system, HealthPlanFinder (HPF). In2015 enhancements were implemented to further integrate ProviderOne, ACES/ES, and HPF to interfaceProviderOne with HPF so that Medicaid clients can also utilize the functionality of HPF for their MedicaidManaged Care Organization (MCO) selection. This modular architecture aligns with MITA principles and providesthe flexibility to support efficient operations of an enterprise MMIS.The Clinical Data Repository (CDR) is an integrated component of Washington’s enterprise MMIS that will providethe State access to data currently housed in provider systems. For many business areas, the use of clinical data isrequired for level four MITA maturity. The CDR is a necessary tool that will allow these MITA business areas tocontinue to advance in maturity.4

Figure 2.3.1 Washington’s Enterprise Medicaid Management Information SystemThe diagram below represents DSHS Medicaid Eligibility infrastructure, which includes additional Federaland State programs, e.g. cash, food, medical, and child care.Figure 2.3.2 WA Medicaid Eligibility Infrastructure5

The state’s developed Enterprise Service Bus as part of the ProviderOne (MMIS) design, development andimplementation effort was leveraged for sharing data across the enterprise between HBE and the Eligibility Service.This overall approach of establishing a separate Eligibility Service for HBE use, and leveraging existing architecturewhile also aligning with CMS’s seven conditions and standards:1. Creates greater modularity by establishing eligibility functionality into a new module within the overallACES infrastructure and loosely integrated with HBE.2. Aligns with Medicaid Information Technology Architecture (MITA) principles.3. Uses industry standard tools and architecture such as service oriented architecture (SOA), business rulesengine, and best of breed commercial off the shelf (COTS) products.4. Leverages existing investments including ACES, Enterprise Service Bus, and Washington Connection.5. Focuses on business results through greater automation, high degree of customer service experience andmeets HBE business needs through defined performance standards/Service Level Agreements.6. Supports a reporting feature where the Eligibility Service shares data with the other modules and includes arobust reporting tool.7. Establishes inter-operability between systems with even greater inter-operability available in the future.ProviderOne was architected based on MITA principles, including the use of service oriented architecture (SOA)and development of a modular component driven development approach. Therefore, the opportunity exists toreplace individual modules as needed, without replacing the entire MMIS. As part of HCA’s comprehensiveassessment of subcontracted components of ProviderOne, HCA has prioritized the Data Warehouse/Reporting foradvanced analytics capability captured in the DSAI MITA Roadmap initiative.SOA AlignmentThe Medicaid enterprise is still considering domains and potential modular services. To date, there is limitedplanning in place to align Service Oriented Architecture (SOA). There is an opportunity that with every contractupdate, SOA expectation may be a new requirement. For example, for the Business and IT Transformationinitiative, DSHS is exploring implementing modular service with an ESB. The State will continue to look foropportunities to build service structures. APIs or batch file interfaces are currently more cost-effective in the stateMedicaid environment.SOA is cost effective and a reusable solution for the Enterprise. ESB is a low cost integration solution for moderatetransition volume. Both have their advantages and disadvantages which should be considered as basic tenets indesigning the exchanges. As the DSHS Business and IT Transformation project progresses, there is an opportunityto favor SOA and ESB technology when designing systems’ interfaces. There needs to be a technical sharing bodyto optimally support this effort. ESB and SOA are not always the best solutions for all exchanges. In these cases,technical governance should be in place that outlines how to deal with special case situations in order to deter an adhoc solution as result.Cloud Computing JustificationOne current example of migration to the cloud, is the exploration of a ProviderOne Proof-Of-Concept (POC) froma physical location from on premise to the cloud. ProviderOne was architected based on MITA principles,including the use of service oriented architecture (SOA) and development of a modular component drivendevelopment approach. Current POC (subject to change) includes eCAMS (6 core business areas) and COTSproducts (includes Siebel application for call center support). This may lead to additional opportunities forleveraging existing cloud based technology solutions and demands thoughtful planning to more easily integrate a6

variety of solutions, such as Software as a Service. HCA is leveraging WA OCIO objectives for cloud based sharedservices or COTS that meet the business needs.Standards and Technology MaturityThe ProviderOne system is based on MITA standards for each business area which increases the scope of reuse.Since other states use similar CNSI products, WA can leverage improvements without requiring time-consumingand unique customization. This current modular architecture aligns with MITA principles and provides theflexibility to support efficient operations and updates to technology.HCA’s priority and focus is on defining or adopting standards for data. In general, technology standards used inprocurements are guided by WA Office of the Chief Information Officer (OCIO) and the Seven Standards andConditions: Modularity, MITA, Industry Standards, Leverage, Business Results, Reporting and Interoperability.COTS UsageOne of the major benefits of a COTS product is being able to procure a functional system that doesn’t requiredevelopment or major enhancements to implement. Examples of COTS product used in the original ProviderOnedesign include Siebel (Call Center,), Pitney Bowes (DOC1) and Oracle Finance (OFIN). More recent examples ofCOTS products used in other business areas include: Clarizen for Project Planning Management SharpCloud for relational mapping used in planning processes Abacus for business process, data and technology modellingWA plans on understanding our business requirements for consideration of future COTS products. Technicalgovernance may proactively address where COTS products best serve our business needs or if alternatives shouldbe pursued.IPOne is a Software as a Service (SaaS) solution and operates as a web-based front-end solution for the individualproviders to report hours, tasks, mileage and paid leave. IPOne interfaces with ProviderOne to receiveauthorization and provider information and send back payment information. Through this exchange of electronicdata, the ProviderOne data warehouse contains a holistic view of Washington State Medicaid expenditures at thespecific client and provider level.Technical Model ArtifactsHCA has chosen ABACUS to model its enterprise architecture, including business, application, data, andtechnology layers. Several models for HCA already exists in ABACUS, including system models, physical datamodels, ProviderOne logical data models, and data interface/interaction models. The Software as a Service (andCOTS) has flexibility to transform elements over 100 industry standard modeling frameworks and notations,including TOGAF, PEAF, FEAF, etc., enabling accelerated production of artifacts, viewpoints and other keydeliverables. The basic function of ABACUS is the ability to perform quantitative impact analysis of architectureswhich HCA has started to do on data layer. ABACUS achieves this by building layers of functionality around thecore architectural model. In its most diluted sense, the ABACUS architectural model is composed of threeelements: components, connections and properties. HCA has started limited analytical analysis of data models.There is an opportunity to spread use of Abacus across the WA.7

Figure 2.8.1 WA Technical Architecture Framework (Abacus)Business Rules EngineThere is a common desire by all the Medicaid agency partners to be flexible to the fast changing Medicaidenvironment. HCA’s MMIS system, ProviderOne, employs a rules engine-based architecture with rich userinterfaces. The ProviderOne business rules are expressed in a natural language, with defined vocabulary thatcontains words and expressions corresponding to business objects and conditions and the operations involved.With the defined and implemented vocabulary, most business rules changes can also be made by HCA staff. Asbusiness changes, ProviderOne contractor, CNSI and HCA Staff, must collaborate to expand the vocabularyaccordingly.Customer Relationship ManagementThere is a common desire to provide providers and clients with direct support, such as self-service portal or appsfor mobile devices. The WA Medicaid agencies often collaborate enterprise-wide when implementing specificcapabilities. For example, the Joint Management Team, consisting of members from each agency, uses a sharepointsite for sharing info on specific system changes. This could be further leveraged by developing or utilizingcollaboration tools such as Clarizen’s Enterprise Project Management software that HCA is adopting. As cross8

agency projects are identified or standards defined, a project management portal across the enterprise would beideal to share information. This approach would allow easy access to data in a loosely-coupled way.Technical Architecture SS-A ResultsOverall, the As-Is MITA Maturity Level (MML)of the Technical Architecture is mostly MML 1, with most technicalservice classifications having at least one system at MML1. The table below displays the fifteen technical serviceclassifications and reflects the MML for each system assessed. The MITA team prioritized 13 key systems to assessand the MITA Maturity Levels are summarized below for ease of reference:Overall, the TA MML 1 indicates that many systems have processes that are primarily manual in nature, disparatedata stores, and manual tasks in performance reporting. There are a number of systems that do have higher levels ofmaturity in several technical service classifications. Most processes are a mix of manual and automated processes,and many systems would advance to a MML 2 from improvement in only a few technical service classifications.Systems were assessed against the business area that they directly support. For example, ACES was assessed againstFinancial Management and Eligibility & Enrollment business areas, and not against its full functionality. Please referto the full SS-A for detailed IA assessment results.Performance MeasurementSecurity & PrivacyBusiness Process Mgmt.Relationship ManagementData ConnectivityService Oriented ArchitectureSystem ExtensibilityConfiguration ManagementData Access & ManagementDecision ManagementLoggingUtilityWA MMISForms and ReportingProviderOneSystemDescriptionBusiness IntelligenceSystemNameClient SupportTechnical Architecture ProfileSystem Profile Description & As-Is MITA Maturity Levels333222222222233ACESAutomated ClientEligibility System342332321311222AFRSAgency FinancialReporting CDRIPOneHPFBarcodeClaimsAdjudicationRecovery SystemClinical DataRepository- Subsystem of MMISIndividual provider-Sub-system ofMMISHealth Plan FinderDocumentScanning System9

Technical Architecture ProfileSystem Profile Description & As-Is MITA Maturity LevelsPRISMICBDMC-Track ECMSWEBSWeb applicationIntegrated ClientDatabaseManaged CareTrack - Sub-systemof ectronicBusiness Solutions33133222 N/A 12123222123222111213232222 N/A 2 N/A 1 N/A 22234423 N/A N/A N/A N/A N/A 2 N/A 23234223 N/A N/A N/A N/A N/A 2 N/A 23211Figure 2.11.1 WA Systems Technical Architecture MITA Maturity Level3 SummaryThe TMS is a document that is used to gauge the level of technical strategy throughout the Medicaid enterprise.Many key stakeholders throughout the enterprise provided valuable insight into how they believe the technicalenvironment exists today and where it is heading in the future.The WA Medicaid systems, with the core MMIS , HCA’s Provider One, and sharing data across the enterprisebetween HBE’s HealthPlanFinder and the DSHS Eligibility Service as part of ACES, is modular by nature.Historically, data has been shared through ESB, periodic batches, transactional or transformed into data products –depending on the agency’s business needs. SOA, ESB and hub-and-spoke technologies are considered withchanging business needs. A current example of SOA and ESB hub-and-spoke technology is the Clinical DataRepository. HCA is advancing the electronic exchange of clinical records for Medicaid clients by establishing anintegrated patient record housed in a CDR using a service provided by the State HIE and sponsored by HCA underthe HIT program. The CDR will blend administrative data from ProviderOne with clinical data from providerelectronic health record systems to measure quality of care being purchased and inform Medicaid programdecisions. HCA will phase in requirements for providers subcontracted with Managed Care Organizations usingcertified electronic health record systems to contribute patient level care summaries each time a Medicaid patient isseen. Authorized providers will have access to the integrated health records to improve treatment decisions at thepoint of care. Future activities include broadening CDR with additional providers, in phases, and will requiretechnology to support its’ long term development, maintenance and use.There is opportunity to accelerate the technology improvements. Several ideas for consideration have beenmentioned in this document. They are summarized below for ease of reference.10

ReferenceCurrent Plans2.3 Service HubMMIS P/I APD: Decision SupportArchitecture practice and Analytics Infrastructure - In orderto support data driven decision makingacross the agency, HCA plans toenhance the enterprise MMIS with thedata analytics functionality, e.g. DataIntegration Engine Functionality ,Master Data Management ToolsEnterprise Data WarehouseFunctionality2.4 SOA Alignment MITA: IT Transformation Initiative DSHS replacing aging ACEStechnology, adopting FEAF, MITAframework the core process model DSHS exploring modular servicewith an ESB as part of ITTransformation initiative2.5 CloudComputingJustification2.7 COTS Usage Exploration of ProviderOne(MMIS) on-site physical locationtoward cloud HCA is leveraging WA OCIOobjectives for cloud based sharedservices or COTSPlans for understanding businessrequirements for consideration offuture COTS products2.8 Technical Model HCA has started limited analyticalArtifactsanalysis of data models.2.10 CustomerRelationshipManagementHCA adoption of Clarizen enterpriseproject management toolFuture ConsiderationsOpportunity exists to replace MMISindividual modules as needed, withoutreplacing the entire MMIS due to thearchitected design elements ofProviderOne Medicaid enterprise has an opportunityto leverage ACES technology redesignto drive urgency of enterprise planning As IT Transformation progresses,opportunity exists to favor SOA andESB technology when designingsystems’ interfaces Opportunity to embed SOAexpectation into contract updates (e.g.MITA: IT Transformation Initiative) Opportunity to leverage other state’simprovements as ProviderOne CNSIproducts used by other states Opportunity to leverage existing cloudbased technology solutionsFavorable circumstances leading toformation of robust technical governancethat outlines how

2 TECHNICAL MANAGEMENT STRATEGY . Enterprise Architecture Adoption . There is general adoption of the MITA Framework and Federal Enterprise Architecture Framework (FEAF) as reference architectural models. FEAF is one of the architectures recommended by the MITA 3.0 Framework in Part III, Chapter 2 Technical Management Strategy.