HINAI TECHNICAL DOCUMENT

Version 1.0 Date: 27.04.2013

ICT HEALTH 9-1R, Al-Razi Building, Block D, Dubai Healthcare City, Dubai, PO Box 9076, United Arab Emirates www.icthealth.com

Confidentiality Note

This document contains proprietary information of ICT HEALTH. No part of this document may be reproduced, stored, copied, or transmitted in any form or by any means now known or hereinafter invented, electronic, digital, mechanical, photocopying, scanning, recording or by any information storage or retrieval system, without the express consent of ICT HEALTH.

HINAI Technical Document

Page 2

Contents
1 PURPOSE ....................................................................................................................................... 4 1.1 1.2 2 2.1 HINAI- SOLUTION SUMMARY ............................................................................................. 4 SOLUTION OVERVIEW ........................................................................................................... 5 LAYER IMPLEMENTATION STRATEGY ................................................................................ 7

HINAI- ARCHITECTURAL REPRESENTATION ......................................................................... 6

2.1.1 2.1.2 2.1.3 2.1.4

UI Layer ............................................................................................................................. 7 Application Layer............................................................................................................... 7 Domain Layer .................................................................................................................... 7 Infrastructure Layer........................................................................................................... 7

List of sub layers.............................................................................................................................. 7

2.2 3 KEY FEATURES ...................................................................................................................... 8 HINAI- Messaging and Integration Overview ............................................................................... 9

3.1.1
4 4.1

Message Mapping ............................................................................................................. 9

HINAI- DOMAIN MODELING ..................................................................................................... 10 HINAI- COMPONENTS OVERVIEW ................................................................................... 11

4.1.1 4.1.2 4.1.3 4.1.4 4.1.5 4.1.6 4.1.7 4.1.8 4.1.9 4.1.10 4.1.11 4.1.12
4.2

Reporting Services ......................................................................................................... 11 Auditing Services ........................................................................................................... 11 Logging Services ............................................................................................................. 11 Workflow Services ......................................................................................................... 12 HIS Services .................................................................................................................... 12 PACS Services ................................................................................................................. 12 Procurement & Inventory Services .............................................................................. 12 Financial accounting & Budgeting Services ................................................................. 12 Data access Services ...................................................................................................... 12 Messaging Services .................................................................................................... 12 Cache Services ............................................................................................................ 12 Security Services ........................................................................................................ 13 Why we chose HIBERNATE? .......................................................................................... 16 Why we chose JSF? ........................................................................................................ 16 Why we chose Spring? .................................................................................................. 17

HINAI- TECHNICAL COMPONENT OVERVIEW ................................................................ 15

4.2.1 4.2.2 4.2.3

5 6

Connected Care ............................................................................................................................ 18 Summary: Technical BENEFITS OF HINAI ARCHITECTURE .................................................. 19

HINAI Technical Document

Page 3

PURPOSE

This Software Architecture Document describes elements from which the HINAI platform is built, the interactions between the elements of the platform, patterns describing the layout of elements and interactions, guidance on their composition, constraints on the patterns and corporate rationale describing why it was chosen. It results in assembling a certain number of architectural elements in well-chosen forms to satisfy the major functionality and performance requirements of a health system, as well as some other, non-functional requirements such as reliability, scalability, security, portability, and availability

1.1 HINAI- SOLUTION SUMMARY

In order to understand technical architecture, it is necessary to look into the solution summary. Broadly, the services of the system are classified into 4 categories 1) Clinical Interaction Services 2) Imaging Services 3) Enterprise Resource Planning Services 4) Portal (m-Health) Services The services under these categories are integrated and accordingly orchestrated in different protocols to achieve the functionalities depicted in the proposal. Since these services are implemented as different suites of various systems and patient information is in omnipresent in all of them, integration of these systems is crucial in order to accomplish aggregated data mining and consolidated business intelligence. A global data repository, capable of accommodating the comprehensive data captured in the healthcare domain and directly linked to the relevant patient, is required. The natural option is a HL7 V3 repository as it is the only true standard in healthcare that aims to support any and all stakeholder workflows. To achieve the envisaged goals, the HINAI platform employs the appropriate Service Oriented Architecture (SOA) that delivers system design and management principles to support reuse and sharing of system resources across a healthcare provider.

HINAI Technical Document

Page 4

1.2 SOLUTION OVERVIEW

Figure 1 Solution Overview

Figure 2 The Extended Healthcare Landscape

HINAI Technical Document

Page 5

HINAI- ARCHITECTURAL REPRESENTATION

To describe the above solution, there should be a suitable, common architecture for the elements across the entire application stack. The architectural representation of the HINAI platform is comprised of the 4 main packages The User Interface Package contains classes for each of the forms that the actors use to communicate with and within the system. The Business Services Package contains control classes for interfacing with the user and other systems and controls the current use case. The Domain Objects Package includes application domain based objects which encapsulate the business actions of the application. The Infrastructure Package supports other packages to get information from the Database, Transaction management, Security, Audit Log and other various system level activities.

Figure 3 Layer Implementation View

HINAI Technical Document

Page 6

2.1 LAYER IMPLEMENTATION STRATEGY

2.1.1 UI LAYER This layer acts as the interface to the end user view and the associated actions. The UI layers primary responsibility is to visually present the interface components to the user, handle data validation and execute the user action by interacting with the application layer. The UI Layer implementation is done using Java Server Faces (JCF) components from Apache Tomahawk and Jboss Richfaces UI Components. Facelets is used as the JSF View handler for page layout. 2.1.2 APPLICATION LAYER This layer acts as the controller for a particular use-case. This layer controls the users interaction with the infrastructure layer. This layers main purpose is control the use-case by calling the other infrastructure sub systems into action including persistence, workflow, rule engine, transaction management and security etc. This layer uses the repository to persist the object to the database. 2.1.3 DOMAIN LAYER This layer encapsulates the domain model of the application. All business related validations and rules of the application are handled by this layer in the application. The domain layer objects represent the real world business objects of the problem domain. This layer is implemented using POJO. 2.1.4 INFRASTRUCTURE LAYER This layers purpose is to provide all the non-functional requirements of the application. Based on the non-functional requirements more sub layers can be added to this layer in the application. LIST OF SUB LAYERS Persistence Audit Log Transaction Management Security Workflow Rule Engine Messaging Monitoring

HINAI Technical Document

Page 7

Except for Persistence, all the sub layers are implemented using AOP around the Application layer. This facilitates adding more sub layers into the application by increasing cross cutting AOP. Persistence of the application is implemented using Hibernate, which supports Object to Relational Mapping.

2.2 KEY FEATURES

With the aforementioned layer implementation strategy, HINAIs architecture is studded with the following key features making it the finest applications platform for the extended healthcare domain. Layered Architecture Web based solution JEE Standard Architecture Cross Browser Support Web Service support Event Driven Messaging Domain Driven Design Integrated Workflow & Rule Engine Role based fine grained Privileges for security

HINAI Technical Document

Page 8

HINAI- MESSAGING AND INTEGRATION OVERVIEW

The following are the major functionalities of messaging services 1) 2) 3) 4) 5) 6) Establish standard communication among HINAI suites Interface HINAI suites with ERP suites Interface HINAI suites with Medical Imaging Suites and Radiology modalities Interface HINAI suites with Laboratory modalities Establish communication with other 3rd Party applications and systems Utilize HL7 message services to convert domain objects, standard xml and HL7 V2.x messages to HL7 V3 messages and deposits them in an HL7 V3 repository 7) Support standard protocols for integration TCP(S), FTP, SFTP, HTTP(S), JDBC, SQL, JMS Queues, Serial (RS-232) communications, File based

Figure 4 Messaging Services Overview

3.1.1 MESSAGE MAPPING Message mapping tools deliver a clear graphical interface to allow rapid mapping of data between systems with different data formats. The mapping code is automatically generated by dragging a field from a single message format to a field in the output format. The generated code can be modified for full flexibility, and an integrated debugger allows effortless testing and configuration of the mapping. The Message Mapper supports EDI, XML and custom schemas, thereby catering to almost any specification, including Health Level 7 (HL7) versions 2 (EDI) and 3 (XML).

HINAI Technical Document

Page 9

HINAI- DOMAIN MODELING

The entire architecture is evolved around a proven concept called Domain Driven Design. The components of HINAI are mapped to the elements of the Domain Driven Design and the artifacts to express, create and retrieve domain models are described in the below diagram.

Figure 5 HINAI Domain Model

HINAI Technical Document

Page 10

4.1 HINAI- COMPONENTS OVERVIEW

The below diagram depicts the different components and respective layer services in the application platform and how they are packaged in the solution.

Figure 6 HINAI Layer Components

4.1.1 Reporting Services The Business Intelligence & Reporting Tool (BIRT) from Eclipse is used for design and a BIRT API is used for recreating the reports in various formats. 4.1.2 Auditing Services Hibernate Enver is used for the versioning of the domain. Hibernate Enver can leverage the @Versioned annotation to log the domain model to the history table. 4.1.3 Logging Services Apache log4j is used for the logging of the different aspects the application by using different levels like debug, info, error and fatal.

HINAI Technical Document

Page 11

4.1.4 Workflow Services Jboss jbpm provides the flow definition designer using Eclipse. Workflow can be used to define various flows of the documents like sequential, parallel flows, conditional flows etc. Assignment of the task can be made to specific users / roles. The assignment can be dynamically assigned by extending the Assignment Handler. 4.1.5 HIS Services HIS Services is the broad classification of different services like patient management, practice management, patient accounting, pharmacy, laboratory, surgical, transfusion medicine etc. 4.1.6 PACS Services PACS Services include imaging, archival services for the patient images. 4.1.7 Procurement & Inventory Services Procurement & Inventory Services cater to the sourcing, purchasing and distribution of goods and services. 4.1.8 Financial accounting & Budgeting Services All modules financial transactions are controlled by the Financial Accounting Services. Budgeting services control the financial movement in an enterprise. 4.1.9 Data access Services Hibernate is used as the ORM mapping tool, which is also the persistence of the domain model. Hibernate provides HQL which utilizes a similar manner of querying the object as used in SQL. 4.1.10 Messaging Services Apache ActiveMQ is used as the JMS Messaging implementation. Communication between the modules is handled by messaging by using the Publisher / Subscriber model. ActiveMQ provides persistence, high performance and the open source solution JMS implementation of the JEE Specification. 4.1.11 Cache Services The Cache Services used load the masters into the respective repository and synchronize with the database using Hibernate EHCache Services.

HINAI Technical Document

Page 12

4.1.12 Security Services Spring Security is used to provide authentication and authorization of the users to the application. In the application, users can be assigned multiple roles and roles can be attached with multiple privileges. JSF compile time weaving is used for providing UI component-wise security to the application by cross cutting the rendering phase of the JSF and checking the logged-in user, privileges. If the user does not have the privilege the relevant UI component is made invisible from the JSF Component tree. Security Management: The HINAI is fully compliant to healthcare security standards and privacy risk management processes to effectively identify, assess, track and close security and privacy risks that impact the System. HINAI has a fully supported Security Incident Handling and Response Plan to define a systematic incident response approach and the incident escalation structure through which incidents are notified and resolved. It also has a fully supported set of reports and logs on a monthly basis to facilitate the monitoring and reporting of security activities carried out. Data Security: HINAI has fully supported controls to segregate data belonging to different owners, to prevent data leakage and/or intentional or accidental compromise between tenants in a multi-tenant environment and to secure and protect sensitive data at rest, and in motion. It provides sanitization and disposal services of storage media as long as the storage media needs to be replaced or taken out of a providers premises or the Clients data center. It also provides fully supported assurance to sanitize all computing resources of tenant data once a customer has exited the environment or has vacated a resource. It ensures that all data and backup resides within the Client site. Infrastructure Security: HINAI and all supporting infrastructure systems, including servers, routers, firewalls, OS, and virtualization components can be hardened. We have controls like firewalls, VPN, etc. to secure the network perimeter if required. We provide a 2-factor authentication mechanism for system administration and other privileged user access. We implement security patch management processes to ensure critical security updates are deployed promptly. There are provisions to conduct penetration tests of infrastructure regularly as prescribed by industry best practices and guidance. The system can capture events or changes made by an application or operating system component in a centralized location. There is also provision for centralized monitoring of the environment in a timely fashion so that unauthorized access or security intrusions/incidents can be detected immediately for timely incident response measures to be put in place to mitigate the threats.

HINAI Technical Document

Page 13

Audit Trail: The system has an audit log record which indicates timestamp, user-id and module. The system also keeps a chronological record of transactions containing evidence directly pertaining to and resulting from the execution of a business process or system function by individual people, systems, accounts or other entities. HINAI incorporates HIPAA-based Full Audit trails for a comprehensive tracking of all the events performed by the various users. Authentication and Authorizations HINAI has the ability to verify and confirm the claimed identity of an entity including confirming the identity of a person and assuring that a system is trusted. The system has the ability to specify user access rights and permissions to resources, related to information and system security, in accordance to policies. Identity and Access Management ICT Health has the capacity to implement, maintain, operate and manage an identity and access management infrastructure and service (IAM) that supports the creation, maintenance, utilization and termination of a digital identity for a user. The required User Management and Role Management capabilities shall be supported for the Client. There is provision for single sign on capability for secure access to multiple applications with minimum need to re-enter passwords. Application Security All HINAI application development activities for custom components / interfaces have a secure system development life cycle environment .HINAI can conduct penetration tests on the Clients setup using a proven methodology which comprehensively tests the system for any potential vulnerabilities that could result from poor system or application configuration, hardware or software flaws, operational weakness in process or technical countermeasures. Security Standards Our products and partner solutions comply to the applicable healthcare industry standards like Data / messaging standard- Health Level 7, Imaging Standard- DICOM, Workflow Standard- IHE Protocols and Security Standard- Healthcare Information Portability and Accountability Act and various other industry quality standards like ISO, FDA 510K etc.

HINAI Technical Document

Page 14

4.2 HINAI- TECHNICAL COMPONENT OVERVIEW

Suites across the HINAI platform conform to identical technical architecture, where the core domain is separated from the technology and the user interface. The Application Stack shows the different software used to implement different layers and the respective technical solution used.

Figure 7 HINAI Technical Stacks

HINAI Technical Document

Page 15

No. 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13

Common name Spring Hibernate My faces Facelets Tomahawk Richfaces Aj4jsf Spring Security jbpm Drools AspectJ EHCache Hibernate Search Business Intelligence & Reporting Tool (BIRT) Adobe AIR

Purpose Framework ORM JSF Implementation JSF view Handler JSF components JSF components Ajax for JSF Security framework Workflow Engine Rule Engine AOP Cache Provider Indexing & Search Engine Business Intelligence & Reporting Engine User Interface

14 15

4.2.1 Why we chose HIBERNATE? Hibernate is a very mature ORM mapping framework and very highly rated by the open source community for the enterprise level applications. Its open source community is very active and backed by Jboss and now by Redhat. Hibernate 2nd level cache using EHCache can reduce the round-trips between the database and application server thereby improving the performance of the application. Hibernate supports a wide range of database servers. With Enver, Hibernate supports versions of the entity model by creating history table(s) for the domain model. This may be used for auditing of the domain model. 4.2.2 Why we chose JSF? Java Server Faces is the component model specification by Sun for web application development. JSF provides a standard approach to web application development on top of Java Servlets, by providing lifecycle(s) to web requests.

HINAI Technical Document

Page 16

The JSF component provides directly binding facility for the domain model without concern regarding the HTTPRequest and HTTPResponse. JSF Validation framework also facilitates data validation which secures the domain model from input errors by the users. 4.2.3 Why we chose Spring? Lightweight container Centralized, automated configuration and wiring of your application objects Transaction Management Aspect Oriented Programming JDBC abstraction layer Flexible MVC web application framework Easy Integration to Workflow Easy Integration and Unit Testing Neat Code

HINAI Technical Document

Page 17

CONNECTED CARE

The architecture of the HINAI network combines the new requirements of connected health, collaboration and e-services trends with best-in-class functionality. Built on a SOA (service orientated architecture), evolved into a MOA (message oriented architecture), it utilizes the latest standards to provide a virtual healthcare community, open to collaboration and deployment of new services across traditional organizational boundaries. It does all of this in a manner that places control of information into the hands of its legal owner. By using open source, public domain standards and service based hosting, it lowers the cost of ownership to its lowest possible levels and creates an environment of innovation and user controlled content. It is ideal for delivering EMR, EHR and related e-services to a widely distributed user base with limited communication infrastructure while simultaneously gathering and compiling the best possible statistics without fear of participation. There are many different ways to deploy and use this technology; from the patient to the service provider, small private practice to the large enterprise, the regulator to insurer; almost any healthcare stakeholder can benefit from this technology.

HINAI Technical Document

Page 18

SUMMARY: TECHNICAL BENEFITS OF HINAI ARCHITECTURE

Figure 7 HINAI Technology Benefits

HINAI Technical Document

Page 19