iEHR Web Application Framework System Architecture Document

iEHR Web Application Framework System Architecture Document
Version 1.3
October 2011
Prepared by: Pacific Telehealth & Technology Hui 459 Patterson Road 4th Floor, E-Wing Honolulu, HI 96819-1522
Version 1.3 October 2011
Revision History
Date 6/20/11 8/3/11 Version 1.0 1.1 Description of Change Initial Draft Changed title of document from iEHR Framework System Architecture Document to iEHR Web Application Framework System Architecture Document. Changed reference from iEHR to iEHR Web Application. Edits Corrected grammatical error Author Danette Amoy Danette Amoy
9/11/11 10/28/2011
1.2 1.3
Danette Amoy Danette Amoy
Page 2 of 14
Table of Contents
1. System Architecture ............................................................................................................................... 5 1.1 Presentation Tier.............................................................................................................................. 5 1.2 Abstraction Tier................................................................................................................................ 5 1.3 Data/Storage Tier ............................................................................................................................. 6 2. Major Components................................................................................................................................. 6 2.1 iEHR Web Application ...................................................................................................................... 7 2.2 jMeadows Interface ......................................................................................................................... 7 2.3 Patient Cross-Reference Index (PIX) ................................................................................................ 7 2.4 Data Source Interface ...................................................................................................................... 8 2.5 Data Source Storage ........................................................................................................................ 8 3. jMeadows Implementation .................................................................................................................... 8 4. Interface Transactions ............................................................................................................................ 9 5. Web Service Transactions .................................................................................................................... 10 5.1 VistA Data Service Interface........................................................................................................... 10 5.2 CHCS Data Service Interface .......................................................................................................... 10 5.3 BHIE Relay Service Interface .......................................................................................................... 10 6. Cach Servers ....................................................................................................................................... 10 7. Application Servers ............................................................................................................................... 10 8. Database Server ................................................................................................................................... 10 9. Physical Architecture ............................................................................................................................ 10 10. Transport Security (SSL)........................................................................................................................ 11 11. Message Authentication over SSL ........................................................................................................ 11 12. Configuration and Code Management ................................................................................................. 12 Appendix A: Definitions, Acronyms, and Abbreviations ............................................................................. 13
Page 3 of 14
List of Figures
Figure 1-1. Example of an N-Tier Architecture ............................................................................................. 5 Figure 2-1. iEHR Web Application Architecture ............................................................................................ 6 Figure 2-2. Logical Diagram of the iEHR Web Application Framework at Local VistA .................................. 7 Figure 3-1. Flowchart of the iEHR Web Application and jMeadows Interface ............................................. 9 Figure 9-1. System Diagram of the iEHR Web Application Framework ...................................................... 11
Page 4 of 14
1.
System Architecture
The iEHR Web Application framework is an n-tier hierarchical model comprising the presentation, abstraction, and data/storage tiers as shown in Figure 1-1. The key principle of this hierarchical design is that each element in the hierarchy has a specific set of functions and services that it offers and a specific role to play in each tier of the design.
Presentation Tier
The top-most level of the application is the user interface. The main function of the interface is to translate tasks and results to something the user can understand.
Client
SOAP
Abstraction Tier
This tier coordinates the application, processes commands, and makes logical decisions and evaluations. It also moves and processes data between the two surrounding layers.
Web Service SOAP Web Service
SOAP
Data/Storage Tier
Here information is stored and retrieved from a database or file system. The information is then passed back to the Abstraction Tier for processing, and then eventually back to the user.
Database
Storage
Figure 1-1. Example of an N-Tier Architecture
1.1
Presentation Tier
The presentation tier, or client tier, is the top-most level of the n-tier architecture and is the user interface. The main function of the interface is to translate tasks and results for the client to understand.
1.2
Abstraction Tier
The abstraction tier, or application tier, is the tier that the presentation tier and the data/storage tier use to communicate with each other. It moves and processes data between the presentation tier and the data/storage tier. The abstraction tier coordinates the application, processes commands, and makes logical decisions and evaluations. The process of abstracting the data sources from the application takes place here.
Page 5 of 14
1.3
Data/Storage Tier
The data/storage tier is basically where a source applications data is stored and from where data is retrieved. The data access components in the abstraction tier are used for communication between the presentation and data/storage tiers.
2.
Major Components
The jMeadows implementation of the iEHR Web Application framework is presented in Figure 2-1. In this diagram, five major components and the messaging method are identified: Component #1 is the iEHR Web Application, which is the client. Component #2 is the jMeadows Data Service, which is a web service. Component #3 is the Patient Cross-Reference Index (PIX), which is a web service. Component #4 is comprised of the data source interfaces, which are the CHCS Data Service, VistA Data Service, and BHIE Relay Service. These data source interfaces are web services. Component #5 is comprised of data source storage containers that hold patients electronic medical records (EMRs). These data source storage containers are accessed by the data source interfaces. The messaging protocol that communicates between the systems is SOAP (Simple Objects Access Protocol) version 2.0.
iEHR Web Application
Presentation Tier
SOAP
SOAP
jMeadows Data Service
PIX Service
Abstraction Tier
SOAP
CHCS Data Service
VistA Data Service
BHIE Relay Service
PACS
Data/Storage Tier
Figure 2-1. iEHR Web Application Architecture
Page 6 of 14
2.1
The iEHR Web Application provides the ability to view specific clinical data stored in any electronic medical record systems available to the abstraction tier. Authorized users access a patients clinical data via a web front end via a browser from within the sites intranet. The iEHR Web Application provides a common data view of read-only, real-time patient information from separate and distinct electronic medical record systems. The iEHR Web Application uses a Java 2 Platform Enterprise Edition (J2EE) object-oriented platform. J2EE is an Open Source standard and can be shared with other Open Source development efforts.
Local North Chicago
GUI Application
DoD/VA Security Boundary (JALFHCC Special Purpose Gateway)
Janus GUI Web Application
DoD ESB North Chicago jMeadows
VA ESB North Chicago
Local Service Bus

VistA Data Service BHIE Relay Service* (patient-centric data) CHCS Data Service (provider-centric data only) PIX Service
Local Data Access Layer Local Data Services
Cach Objects Server for CHCS North Chicago
PACS Broker (Medweb)
Cach Objects Server for VistA North Chicago
CHCS North Chicago
Navy PACS (Agfa) North Chicago
VA PACS (Agfa) North Chicago
VistA North Chicago
*BHIE Services preferred for Patient Data/fail-back to CHCS Cach as optional data source for 1-Dec.
Central/Regional Enterprise Data Services Enterprise Data Sources Key

Clinical Data Repository (CDR) BHIE 5 Montgomery BHIE Framework Philadelphia Identity Management Service Austin
Theater Medical Data Store (TMDS)
CHCS (enterprise access)
VistA (enterprise access)
VA IdM Austin
Includes DoD identities
New to North Chicago
Common
VA-unique
DoD-unique
Existing Component in Tripler Solution
Figure 2-2. Logical Diagram of the iEHR Web Application Framework Implemented at Local VistA
2.2
jMeadows Interface
The jMeadows interface is a web service that retrieves clinical data from EMR systems. The jMeadows interface issues a patient lookup against the Patient Cross-Reference Index (PIX) service for patient location information. If the PIX search is successful, the PIX Service returns patient identifiers associated with the patient locations to the jMeadows interface. Then, the jMeadows interface reviews the list of patient locations and queries the locations for patient clinical data.
2.3
Patient Cross-Reference Index (PIX)
The Patient Cross-Reference Index is implemented as a web service that correlates information about a single patient from sources that are known by different patient identifiers (e.g. DoD EDIPN, VA ICN, VA
Page 7 of 14
IEN, and CHCS IEN). These cross-referenced patient identifiers are used by identity consumer systems to map patient information.
2.4
Data Source Interface
A data source interface is a web service implemented by the jMeadows interface when it queries patients locations. The following are data source interface web services currently supported at local VistA: VistA Data Service CHCS Data Service BHIE Relay Service
2.5
Data Source Storage

Composite Health Care System (CHCS) (via the DoD ESB) Veterans Health Information Systems and Technology Architecture (VistA) (via the VA ESB) Bidirectional Health Information Exchange (BHIE) BHIE 5 Montgomery (via the DoD ESB) Navy Picture Archive and Communication System (PACS) (via the DoD ESB) VA Picture Archive and Communication System (PACS) (via the VA ESB)
Currently, the EMR systems available at local VistA are:
3.
jMeadows Implementation
The iEHR Web Application framework uses Java-based web services technology to specify a web service interface. The iEHR Web Application framework uses request- and response-driven transactions for the web service system interfaces (see Figure 3-1 and flowchart, below). The jMeadows interface server provides a web service implemented per SOAP version 2.0. When a SOAP request is received for a patient, the jMeadows interface issues a PIX lookup to determine where the patient has data. jMeadows then interfaces with the data source web services to call each EMR system at which the patient is registered. If data from the EMR systems are retrieved, the necessary data conversions and sorting will be performed prior to returning the requested data as a SOAP response.
Page 8 of 14
1 2
jMeadows Interface PIX Service
4 3 5
Data Source
Data Storage
Figure 3-1. Flowchart of the iEHR Web Application and jMeadows Interface
1. 2. 3. 4. 5. The iEHR Web Application requests patient information from the jMeadows interface. The jMeadows interface checks the PIX Service to find locations for the patient. The PIX Service returns a list of locations for the patient. The PIX Service returns a DoD location (if the patient has DoD records) with the patients DoD EDIPN or a VA location (if the patient has VA records) with the patients VA IEN. The jMeadows interface: (a) uses the DoD EDIPN to retrieve data from the CHCS Data Service, (b) uses the VA IEN and VA ICN to retrieve data from the VistA Data Service, or (c) passes in the local CHCS IEN from the BHIE Relay Service. The patient clinical data is retrieved and sent back to the requestor.
6.
4.
Interface Transactions
The transactions between the iEHR Web Application and the data source systems are request- and response-driven for the web service system interfaces.
Page 9 of 14
5.
5.1
Web Service Transactions

VistA Data Service Interface
Upon receipt of a SOAP request from the iEHR Web Application, the VistA Data Service interface determines if the site ID of the requesting entity is listed as a valid Cach site. If it is listed as a valid Cach site, the VistA Data Service interface server queries the VistA system using Cach Objects. The VistA Data Service interface server formulates a SOAP response and returns it to the requestor. The SOAP messages are sent to the VistA Data Service web service as Hyper Text Transmission Protocol (HTTP) over Secure Sockets Layer (SSL) via TCP/IP. If the VistA Data Service interface cannot validate the site ID as a Cach site, then the VistA Data Service interface server queries the VistA system using remote procedure calls (RPCs). The VistA Data Service interface aggregates the VistA data and formulates a SOAP response and returns it to the requestor.
5.2
CHCS Data Service Interface
Upon receipt of a SOAP request from the iEHR Web Application, the CHCS Data Service interface server queries the CHCS system using Cach Objects for provider-centric data. The Cach Objects calls the Cach database for data. The results of the query are sent to the CHCS Data Service interface server. The CHCS Data Service interface server formulates a SOAP response and returns it to the requestor. The SOAP messages are sent to the CHCS Data Service web service as HTTP/SSL via TCP/IP.
5.3
BHIE Relay Service Interface
Upon receipt of a SOAP request from the iEHR Web Application, the BHIE Relay Service queries the BHIE 5 Montgomery system for patient-centric data. This interface was developed by VA/DoD Enterprise for the BHIE project. The iEHR Web Application Framework is re-using this interface.
6.
TBD
Cach Servers Application Servers Database Server Physical Architecture
7.
TBD
8.
TBD
9.
TBD
Page 10 of 14
DOD Network
Test (Gold) ESB Context CDR CHCS AHLTA CHCS Internet Gateway
External IP Address XXX.XXX.XXX.XXX Via NAT
Internet Zone
Internet Gateway
External IP Address 152.1XX.XXX.XXX Via NAT
VA Network
Janus Application Server r02hinapp18pp
vaww.esbpp.r02.med.va.gov
XXX.XXX.7.150
ESB Load Balancer
Internet
Port 443
VA WAN
Port 443
r02hinapp19pp XXX.XXX.7.151
Port 443
Port 443
Janus Web Server
The ESB load balancer will direct Port 443 to:

App18pp App19pp r02hinapp18pp.r02.med.va.gov r02hinapp19pp.r02.med.va.gov
through two server farms (one per server). There is no HA and load balancing for this application
Figure 9-1. System Diagram of the iEHR Web Application Framework
10.
Transport Security (SSL)
The Transport Security mechanism protects the application during transport using Secure Sockets Layer (SSL) for authentication and confidentiality. Transport-layer security is provided by the transport mechanisms used to transmit information over the wire between clients and providers, thus transportlayer security relies on secure HTTP transport (HTTPS) using SSL. Transport security is a point-to-point security mechanism that can be used for authentication, message integrity, and confidentiality. When running over an SSL-protected session, the server and client can authenticate one another and negotiate an encryption algorithm and cryptographic keys before the application protocol transmits or receives its first byte of data. Security is live from the time it leaves the consumer until it arrives at the provider or vice versa. The problem is that it is not protected once it gets to its destination. For protection of data after it reaches its destination, one of the security mechanisms that uses SSL and that also secures data at the message level will be utilized. Digital certificates are necessary when running HTTPS using SSL. The HTTPS service of most web servers will not run unless a digital certificate has been installed. Digital certificates have been created for the GlassFish server, and the default certificates are sufficient for running this mechanism, and are required when using atomic transactions. However, the message security mechanisms require a newer version of certificates than is available with the GlassFish server.
11.
Message Authentication over SSL
The Message Authentication over SSL mechanism attaches a cryptographically secured identity or authentication token with the message and uses SSL for confidentiality protection.
Page 11 of 14
12.
Configuration and Code Management
Currently, Mercurial is used as the code repository management software. The following have been implemented to support version control: iEHR products will have the tag JANUS_IEHR_0_1_0. The first 0 in the tag represents major. The 1 in the tag represents minor. The second 0 in the tag represents build. Whenever there are new features in the push, the minor number will be incremented. Whenever there are bug fixes to the feature set, the build number will be incremented. It is not necessary to tag all of the projects each time something is pushed. It is assumed that the latest tag should be compatible with any projects with later tags. Release documentation can be found at: https://sp.pacifichui.org/dev/Dev%20Wiki/Release%20Documentation.aspx Server deployment information can be found at: https://sp.pacifichui.org/dev/Dev%20Wiki/Server%20Deployments.aspx
Page 12 of 14
Appendix A: Definitions, Acronyms, and Abbreviations

BHIE CHCS DICOM DoD EDIPN eDR EMR ESB HL7 HTTP IDE ICN IEN J2EE JALFHCC jMeadows JMS LOINC MUMPS Bidirectional Health Information Exchange Composite Health Care System - DoD Digital Imaging and Communications in Medicine Department of Defense Electronic Data Interchange Person Number Enhanced Document Referral electronic medical record enterprise service bus Health Level 7 Hyper Text Transfer Protocol integrated development environment internal control number internal entry number Java 2 Platform, Enterprise Edition Captain James A. Lovell Federal Health Care Center North Chicago Meadows Web Service Java Message Service Logical Observation Identifiers Names and Codes Massachusetts General Hospital Utility Multi-Programming System (also known as M) Pharmacy Data Transaction Service
PDTS
Page 13 of 14
PIX RAID RPC SOAP SQL SSL TCP/IP VA VAMC VistA WSDL
Patient Cross-Reference Index redundant array of independent disks; term for computer data storage remote procedure call Simple Object Access Protocol structured query language Secure Sockets Layer Transmission Control Protocol/Internet Protocol Veterans Administration Veterans Administration Medical Center Veterans Health Information Systems and Technology Architecture - VA Web Services Description Language
Page 14 of 14

iEHR Web Application Framework System Architecture Document

Uploaded by

Copyright:

Available Formats

iEHR Web Application Framework System Architecture Document

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

iEHR Web Application Framework System Architecture Document

Uploaded by

Copyright:

Available Formats

iEHR Web Application Framework System Architecture Document