Specifications include, but are not limited to: 9.2.1. Activity Management, Documentation and Coding - Functionality that supports documentation, coding and overall management of health care activities and services performed by select agencies – primarily the HD and CSB - and external providers as part of multiple programs for which those agencies are responsible. 9.2.2. Provider Decision Support - The capability to provide context-driven, intelligently filtered, appropriately timed knowledge and evidence to health care practitioners in a manner that is conducive to more accurate diagnoses and optimal care/service/treatment plans. 9.2.3. Care Management - Comprehensive functionality for assessment, care planning, care plan administration, service authorization and referral management, and medication reconciliation activities. Furthermore, the County expects that this module will encompass a Comprehensive Care Record – a longitudinal record of a client’s interactions with the HD, CSB and other relevant providers. The Comprehensive Care Record will be populated with data captured via the Activity Management, Documentation and Coding module and – through the possibility of leveraging health information exchange (HIE) services or interfaces - other information systems. 9.2.4. Patient Engagement - Functionality traditionally associated with a comprehensive personal health record (PHR), targeted educational materials, patient connectivity to providers/care team, self-management tools and aids. 9.2.5. Operations Management - Clinic/facility/site client scheduling, workload management, capacity management, pharmacy management, material, supply and equipment management. 9.2.6. Revenue Cycle Management - Client accounting, billing/invoicing/claiming/cost settlement, cashiering, third-party liability and coordination of benefits and cost accounting. 9.2.7. Health Analytics - Aggregation, mining, modeling, visualization and reporting of health information for both retrospective and prospective purposes including but not limited to population health management. 10.2. The technical requirements are grouped into the following nine categories: 10.2.1.Solution architecture – Requirements related to ensuring that the selected solution conforms to Service Oriented Architecture (SOA) principles, is comprised of distinct functionality components that can be added on or removed through installation addition or license expansion without requiring significant effort to add, remove or test. These functionality components should be designed to interoperate with other components, including components developed by other companies. 10.2.2.Interface and interoperability – The solution shall be built to support data integration with other systems, ideally using pre-built connectors or application programming interfaces, support the dynamic exchange of data from multiple solutions in real-time (as needed) and batch modes, and support linkage to an external document management solution for making images, transcriptions and other unstructuredinformation available to solution users (if deemed applicable). 10.2.3.User access modalities – Includes mobility enablement (e.g., ability to access the data aggregation solution using mobile devices such as tablets) as well as traditional user access modalities (desktop, laptop). 10.2.4.Solution-specific security model – Including identity management, user authentication and role-driven access management. 10.2.5.Solution performance – To establish expectations around response time to user commands and user-initiated jobs such as queries and reports. 10.2.6.Solution capacity, scalability and extensibility – These requirements ensure that the selected solution can scale, be expanded and be extended to other locations, other providers, individual users, services, programs, and data sources with the lowest possible level of effort and cost.