MAE HA Training

July 8, 2013

Developer Guide

• How to create DTO

• How to Expose a new service

Health Adapter SDK

• Set up HA Development Environment

• Git repository URLS

Software Design

July 8, 2013

Design Principles

• Core Principles─ Make the services easy to consume─ Keep the build times fast enough to encourage quick feedback─ Keep test coverage high enough to give confidence in making quick

changes─ Keep "data access" separate from the services

• HealthAdapter as a Resource-Oriented System─ Self-discoverable URI's─ Resource Directory─ Favor stateless calls─ Content Type Negotiation─ Favor Meaningful URI's─ Leverage HTTP protocol for "Methods"─ Leverage the HTTP Response Codes

Software Components

July 8, 2013

Overview

Staff HA

Domain Transfer Objects

• The Domain Transfer Objects (DTO's) are a set of java classes that represent the domain/business objects of the system. These classes exist to pass content between the layers of the system, including from the HealthAdapter to the consumer.

• DTO's are explain in more detail here.

Resource Service

• For a Resource Oriented Architecture / REST perspective, a resource is the entity that is being exposed and made available as a service. In the HealthAdapter, for there are a series of "domain" resource services. These classes define the REST services available from the system, including the paths, HTTP verbs in order to access them, and the representation (format).

• The concept of resource services are explained in more detail here

Data Links

• Within HealthAdapter, the resources returned from the resource services contain links to other resource services within the system. For example, when fetching a patient, the patient returned contains links to resources services relevant to that patient's such as that patient's allergies, lab results, etc.

• The concept and implementation of Data Links are discussed in more detail here.

Data Service

• The data services in the system are the layer responsible for expose data related services. The data services are generally invoked from the resource services. When invoked, the data services initiate the correct data layer component, translate the patient identifier as needed, and invoke the data layer. If there are any business rules these are generally encapsulated in this layer. The data services, like the resources services, are broken out by domain.

• The data services are explain in more detail here.

Data Layer

• The data layer is the layer responsible for the fetching and saving data. For each domain, there is a data layer interface, with an implementation for this data layer interface per source system (Vista, CDW, etc). There is generally a "mock" data layer implementation used during testing.

Service Registry

• The service registry's primary purpose is to provide factory methods for the data layer implementations. The structure of the service registry allows for different data layer implementations to be mapped to different "communities". A community can represent a single logical "data source", such as a Vista instance or it can represent a aggregated logical "data source", such as the VA or the DoD.

• The service registry is discussed in more detail here.

Subsystems

July 8, 2013

Notification Sub-System

• Notifications allow an authenticated user to push information via an alert to a user's registered device. Notifications are sent through Apple's Push Notification Service (APNS) from the Health Adapter (HA).

• More information can be found here.

Metrics Sub-System

• The metrics sub-system allows for application metrics, usage, and audit information to be tracked.

• This is accomplished two ways.

• First, all calls to the resource services are automatically tracked and stored in the metric repository using AOP.

• Second, the HealthAdapter exposes a resource that allows for other applications to publish metrics to track.

• The metric repository is currently a running set of files. It is expected that this will be migrated to a durable repository under current efforts.

Launchpad Support

• To do

MVI Gateway

• To do

Interface Control Document

July 8, 2013

ICD

• The Interface Control Document (ICD) specifies the interface requirements between the VA Health Adapter and (bullets below don't align well with illustration... get rid of illustration or update bullets?)

─ Mobile devices─ VistA─ Other???

ICD (continued)

• It describes the concept of operations for the interface, defines the message structure and protocols that govern the interchange of data, and identifies the communication paths along which the data are expected to flow.

• For each interface, the following information will be provided:

• A general description of the interface;

• Assumptions where appropriate;

• A description of the data exchange format and protocol for exchange

• The set of operations supported by the service using HTTP methods (e.g., GET, PUT, POST, or DELETE).

• Estimated size and frequency of data exchange.

ICD (continued)

• ICD is generated by a build job and can be found on the build server.

• If you don’t need the latest a copy is available here.

ICD- Resources

ICD- Data Model

Software Stack

• Get it from Mark M

• It is tracked here.

Data Field Mapping

• Gives the details of the data being pulled externally and being consumed by the HealthAdapter Server

─ Admission Mapping─ Allergy Mapping─ Patient Data Mapping─ Problem Mapping─ Radiology Mapping─ Vital Mapping

─ More information can be found here.

System Design

July 8, 2013

System Design

• HealthAdapter Services Overview

• System Architecture

• Network Architecture

• Security Model

• Data Architecture

• External Systems

Services Overview

• Authentication Services─ HTTP Basic Security─ OAuth 2.0─ Integrated with IAM SSOe

• Patient Search

• Clinical Services

• Patient-entered Data

• Calendar Services

• Notification Services

• Appointment Services

• Secure Messaging Services

• Metrics Services

Architecture Overview

A HealthAdapter System is composed of several components, including:

• A load balancer to distribute transactions among application servers (HealthAdapter Nodes)

• Application server to host the HealthAdapter services

• A MDWS instance to support access to VA systems

• An Enterprise Application/App Store

• A shared repository

• An Authorization Server

• An Active Directory Server

• More information on all these individual components can be found here.

HA Running Modes

• The HealthAdapter can be configured in various running modes to specify a configuration set.

─ Veteran Mode─ Staff Mode

Network Architecture

• To do

Security Model

July 8, 2013

Data at Rest

• HealthAdapter Server

• MDWS Server

• HealthAdapter Load Balancer

• HealthAdapter Repository Server

• Detailed information available here.

Protocol Security

• Applications to HealthAdapter Load Balancer

• Applications to IAM SSOe

• Authorization Server to HealthAdapter Repository Server

• EAS Server to HealthAdapter Server

• EAS Server to HealthAdapter Repository Server

• EAS Server to HealthAdapter AD Server

• HealthAdapter Load Balancer to HealthAdapter Server

• HealthAdapter Load Balancer to EAS Server

Protocol Security

• HealthAdapter Server to MDWS Server

• HealthAdapter Server to HealthAdapter Repository Server

• HealthAdapter Cluster to External Systems

• HealthAdapter AD Server to VA AD Server

• Oracle WebLogic Administration Server to Managed Servers

• (Oracle) Administrator to Oracle WebLogic Administration Server

• More information here.

Apple Push Notification Service (APNS)Security

• Apples require that all providers such as the HealthAdapter have a unique certificate and private cryptographic key for connection validation (see next section for more details). This certificate, provisioned by Apple, must identify the topic published by the HealthAdapter. The topic is the bundle ID of the client application. For each notification, the HealthAdapter must furnish the APNS with the device tokens for the target devices

Authentication and Right of Access• Staff Authentication

• Veteran Authentication

Staff Authentication• When the HealthAdapter is running in "staff" mode

(Staff Environment), the HealthAdapter protects its services by having users authenticate using their VistA credentials. The authentication process follows OAuth 2.0 specification.

More information available here.

The standard is defined here: http://tools.ietf.org/pdf/draft-ietf-oauth-v2-12.pdf

A simplified explanation as used by Facebook is defined here: https://developers.facebook.com/docs/authentication/

Single Sign-On for Health Adapter Applications

• The applications being built as part of the Clinic-in-Hand effort will implement single sign-on utilizing OAuth using the "Authorization Code" grant type workflow

• Prior to the application being deployed, the application is registered with the HealthAdapter, providing an application identifier, an application "weak-password" (come up with better name here), and an application logon redirect URI.

• More information here.

Veteran Authentication and Identification

• When running in "Veteran" mode (Veteran Environment), the HealthAdapter protects its services by having users authenticate using their DS Logon credentials. Authenticating and identifying the user is accomplished using DS Logon as an authentication provider and by using IAM's SSOe service offering to establish the session between the user and the HealthAdapter.

IAM SSOE

• IAM is the VA organization chartered for "Identity and Access Management". This group is responsible for identifying Veterans, tracking their "preferences", and protecting access to Veteran resources.

• IAM SSOe supports multiple authentication providers, but for "Veteran" mode will use DS Logon as the authentication provider/user credentials. If in the future other authentication provider support is required, the IAM emerging offering for Enterprise Authentication Gateway can be utilized to abstract the authentication provider.

IAM SSOE (continued)

• One of the challenges in this integration is that IAM SSOe is designed for web applications. This allows for an assumption that to provide single sign-on, all user traffic comes from a single client--a single browser on the user's device. All traffic flows from the user's browser to the IAM WebSeal, acting as a reverse proxy, to the VA web applications. When there are multiple client applications that need to share in this authentication content, as is the case with using native mobile applications, this approach does not work "out of the box".

IAM SSOE (continued)

• A second challenge is that DS Logon, by policy, does not allow for credentials to be proxied through another system. That is, it would not be appropriate for users to enter their credentials into the mobile application directly, nor for the credentials to be sent to the HealthAdapter and then forwarded to DS Logon.

• Authorization for HealthAdapter to Access Patient Data on Patient's Behalf

Patient Identifiers

• At the conclusion of the authentication process, users will be known by their identifier associated with their DS Logon account, which is their DoD identifier (EDIPI).

• In order to access patient data, it will be necessary to take a given patient identifier and discover the patient identifier used in various systems/contexts. For example, to access the CDW, the patient's ICN is used, while when accessing VistA, the patient's local IEN is used.

• More information here.

Data Architecture

July 8, 2013

HealthAdapter Data Sources

• The HealthAdapter has the capability to retrieve from multiple sources. The source system is determined based on the role of user (staff vs patient/Veteran) and the usage scenario (operational vs longitudinal).

• In general, a user in the role of staff has access to multiple patients, whereas a patient/Veteran has access to only his or her own data.

• The operational view of data is generally a narrow view from a single VistA, while the longitudinal view is the wide view of all data, often from an aggregated data source.

External Systems

• ADR

• APNS

• CDS (or Pathways)

• CDW

• CMOP

• IAM SSOe

• MDWS

• MHV

• MVI

• VistA

• Detailed information here.

References

• CDW Data Extract Technical Design

• CIH App Registration

• Deploying Staff Health Adapter

• Deploying veteran Health Adapter

• MDWS Installation and Configuration