hinai technical architecture document

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

http://www.icthealth.com/

HINAI® Technical Document

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.


Contents

1 PURPOSE ....................................................................................................................................... 4

1.1 HINAI®- SOLUTION SUMMARY ............................................................................................. 4

1.2 SOLUTION OVERVIEW ........................................................................................................... 5

2 HINAI®- ARCHITECTURAL REPRESENTATION ......................................................................... 6

2.1 LAYER IMPLEMENTATION STRATEGY ................................................................................ 7

2.1.1 UI Layer ............................................................................................................................. 7

2.1.2 Application Layer ............................................................................................................... 7

2.1.3 Domain Layer .................................................................................................................... 7

2.1.4 Infrastructure Layer ........................................................................................................... 7

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

2.2 KEY FEATURES ...................................................................................................................... 8

3 HINAI®- Messaging and Integration Overview ............................................................................... 9

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

4 HINAI®- DOMAIN MODELING ..................................................................................................... 10

4.1 HINAI®- COMPONENTS OVERVIEW ................................................................................... 11

4.1.1 Reporting Services ......................................................................................................... 11

4.1.2 Auditing Services ........................................................................................................... 11

4.1.3 Logging Services ............................................................................................................. 11

4.1.4 Workflow Services ......................................................................................................... 12

4.1.5 HIS Services .................................................................................................................... 12

4.1.6 PACS Services ................................................................................................................. 12

4.1.7 Procurement & Inventory Services .............................................................................. 12

4.1.8 Financial accounting & Budgeting Services ................................................................. 12

4.1.9 Data access Services ...................................................................................................... 12

4.1.10 Messaging Services .................................................................................................... 12

4.1.11 Cache Services ............................................................................................................ 12

4.1.12 Security Services ........................................................................................................ 13

4.2 HINAI®- TECHNICAL COMPONENT OVERVIEW ................................................................ 15

4.2.1 Why we chose HIBERNATE? .......................................................................................... 16

4.2.2 Why we chose JSF? ........................................................................................................ 16

4.2.3 Why we chose Spring? .................................................................................................. 17

5 Connected Care ............................................................................................................................ 18

6 Summary: Technical BENEFITS OF HINAI® ARCHITECTURE .................................................. 19


1 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.


1.2 SOLUTION OVERVIEW

Figure 1 Solution Overview

Figure 2 The Extended Healthcare Landscape


2 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


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

layer’s 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 user’s

interaction with the infrastructure layer.

This layer’s 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 layer’s 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


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, HINAI®’s 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


3 HINAI®- MESSAGING AND INTEGRATION OVERVIEW

The following are the major functionalities of messaging services

1) Establish standard communication among HINAI® suites

2) Interface HINAI® suites with ERP suites

3) Interface HINAI® suites with Medical Imaging Suites and Radiology modalities

4) Interface HINAI® suites with Laboratory modalities

5) Establish communication with other 3rd Party applications and systems

6) 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).


4 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


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.


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.


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 provider’s premises or the Client’s 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.


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 Client’s 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.


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


No. Common name Purpose

1. Spring Framework

2. Hibernate ORM

3. My faces JSF Implementation

4. Facelets JSF view Handler

5. Tomahawk JSF components

6. Richfaces JSF components

7. Aj4jsf Ajax for JSF

8. Spring Security Security framework

9. jbpm Workflow Engine

10. Drools Rule Engine

11. AspectJ AOP

12. EHCache Cache Provider

13 Hibernate Search Indexing & Search

Engine

14

Business Intelligence

& Reporting Tool

(BIRT)

Business Intelligence &

Reporting Engine

15 Adobe AIR User Interface

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.


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


5 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.


6 SUMMARY: TECHNICAL BENEFITS OF HINAI® ARCHITECTURE

Figure 7 HINAI

® Technology Benefits

hinai technical architecture document

Documents

hinai technical document

hinai messaging

hinai components overview

hinai solution summary

hinai domain modeling

domain layer

ui layer

application layer