3       High-Level Architecture

The following figure depicts the preliminary high-level system architecture as envisioned based on the scenarios.  At this point, the goal is to identify the major system components and connections in order to provide a richer context (and some terminology) for the use cases.  The design document will later delve into more architectural details. 

3.1   CLIENTS

Four Client/End-User applications have been identified - three of these are for provider use while one is for patient use as follow:

3.1.1     Provider Services

Rule Workbench:  is the authoring environment for capturing clinical domain knowledge and workflow rules.   The Workbench stores its knowledge artifacts (rules) in the Knowledge Management Repository (KMR).

MedAlert: is the application that provides alerts to providers (physician and non-physician providers, bedside terminals).

Universal Inbox: is a workflow-focused ‘one-stop’ central application for providers.  It is meant to centralize provider workflows and task related activities, and can be integrated within a variety of health information system clients .

3.1.2     Patient Application

Patient Medical Record: is the client application that the patient uses to see his health records, upload medical device data from home and communicate with her provider. It is meant as a MS Outlook-like productivity tool for patients and serve as the central application for patients. More than just a read-only PHR, the Patient Medical Record is a comprehensive, interactive application with functionality similar to a provider EMR only tailored to the patient experience.

3.2   Infrastructure Components

DDSS and KMR are the two critical infrastructure components that enable clinical decision support. DDSS is the run-time system that provides the results of inference evaluations, while KMR is the database or repository of the knowledge artifacts or rules.  Both are SOA services.

The SOA Enterprise Bus is part of the NHIN CONNECT framework services that exposes web services and enables communication among the components connected to it.

The Common Access Layer Service is an important service provided by NHIN CONNECT that allows DDSS (and other components connected to the SOA Bus) to access Data Systems such as the EMR or Disease Registries in a vendor agnostic and standards-based way.

3.3   Data Systems

Applicable data systems are all the applications / databases that contain health/medical information that DDSS/KMR needs to provide its functionality.  They include case management, personnel, EMR, inventory and disease registry systems.

4       Services Identified

4.1   DDSS/KMR Services

1. Signal-processing service
2.  

4.2   NHIN/Infrastructure Services

1. Notification service
2. Action service
3.  

5       Application Roles

The following user roles have been identified based on the scenarios discussed above:

1)    Patient

2)    Provider (generic)

3)    Ordering Provider

4)    Attending Provider

5)    Covering Provider

6)    Charge Nurse

7)    Clinic Nurse

8)    Scheduled (Assigned) Nurse

9)    Cross-over Nurse

10) Unit Attending

11) Notification Supervisor

12) Rule Manager

13) Notification Manager

14) System Administrator

6       Assumptions and Constraints

Assumptions:

- DDSS is a medical system containing patient health information subject to the Privacy Act of 1974.  Personal information contained in this system may be used only by authorized personal in the conduct of official business.

- The system requires Java and will be OS and browser independent.

-The system is a service deployed on and relying on NHIN CONNECT services and components.

- This project will not affect the availability of the underlying HIE system.

- The system will allow users (patients and providers) to complete workflow tasks with a streamlined graphical, web-based application. 

Constraints:

- Legacy code, data structure, and workflow are to be preserved.

- The system should use open source software components unless other units are specifically approved.

- The system will employ open standards and will not use licensed ontologies unless required and approved.

- The system should be capable of running on a minimal VOE hardware implementation.

7       Conclusion

The above use cases define the functional requirements of the solution.  This will be followed by a Design Document that details how these requirements can be met in an architectural sound way.