hinai technical architecture document
DESCRIPTION
Solutions Overview, Components Overview and Connected Framework.TRANSCRIPT
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
HINAI® Technical Document
Page 2
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 3
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
HINAI® Technical Document
Page 4
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.
HINAI® Technical Document
Page 5
1.2 SOLUTION OVERVIEW
Figure 1 Solution Overview
Figure 2 The Extended Healthcare Landscape
HINAI® Technical Document
Page 6
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
HINAI® Technical Document
Page 7
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
HINAI® Technical Document
Page 8
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
HINAI® Technical Document
Page 9
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).
HINAI® Technical Document
Page 10
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
HINAI® Technical Document
Page 11
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 12
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 13
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.
HINAI® Technical Document
Page 14
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.
HINAI® Technical Document
Page 15
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 16
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.
HINAI® Technical Document
Page 17
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 18
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.
HINAI® Technical Document
Page 19
6 SUMMARY: TECHNICAL BENEFITS OF HINAI® ARCHITECTURE
Figure 7 HINAI
® Technology Benefits