Team Doctor

Plan your projects and define important tasks and actions

Comienza Ya. Es Gratis
ó regístrate con tu dirección de correo electrónico
Rocket clouds
Team Doctor por Mind Map: Team Doctor

1. Justification

1.1. Adoption of Information Tecnology

1.1.1. Make available remote online resources to the doctors/consultants

1.1.2. Improve access of consultants

1.1.3. Reducing costs of access to specialiced resources

1.1.3.1. Invest the savings in improving other parts of the hospital

1.2. Limitations

1.2.1. Schedule

1.2.2. Budget

1.3. Define Project Development Measurement

1.3.1. KPI's

2. Assumptions

2.1. The system will be accesed by pcs through internet

2.2. It is assumed that cliente tier has affordance, usability and feedback

2.3. It's assumed that the web services are used for all external clients. This is just for readonly and for external clients that need this service

2.4. 5. The performance it's important because it’s a manifest quality and we are going to give quick responses to the user. This can be achieved with the use of load balancing and jms. a. Load balancing allow us process requests asynchronic quickly as the insertion in local database and access to web presentation b. JMS allow put process in queue for giving a quick response and let the system process the request later.

2.5. 6. We are going to publish the web services with UDDI for external clientes. This ensure that there will be an only access point

2.6. There will be a LDAP server who has all the security, users, roles and priviledeges for all the system

2.7. The web services only will be used for clients who arent java, otherwise we will use RMI because is faster

2.8. patient's information in all the hospitals will be loaded in a database local and the identification will be the id. This id is unique

2.9. The scalability well be garanticed by a load balancer.

3. Stakeholders

3.1. Health care industry

3.1.1. Doctor/Consultants

3.1.2. Hospitals

3.1.2.1. NorthAmerica

3.1.2.2. Europe

3.1.2.3. Asia

3.1.3. Hospital Management Comittee

3.2. Architect

3.2.1. Lead the team responsible for the design

3.2.2. Implementation

3.2.3. ongoing management

4. Project Information

4.1. Component Diagram

4.2. Class Diagram

4.3. Deployment Diagram

4.4. Interaction Diagrams

4.5. Risk and Mitigarion Risks

5. workshop

5.1. Doctors

5.1.1. Place requests for assistance

5.1.1.1. attach relevant documentation

5.2. system team doctor

5.2.1. Place the request into work queue

5.3. Consultants

5.3.1. Review

5.3.1.1. MRI Scans

5.3.1.2. X-rays

5.3.1.3. Review a patiens case history

5.3.2. Provide feedback to the doctor in charge

5.4. Systems

5.4.1. Rich content repository

5.4.1.1. high resolution medical images

5.4.1.2. binary content

5.4.2. Patient Record System

5.4.2.1. Medical History

5.4.3. Prescription database

5.4.4. Acceso

5.4.4.1. Web Services to read data

5.4.4.2. When doctors/consultans access the system remotely it will be in read-only

5.4.5. The system will save any action over any of the systems

5.5. Patients are identified by a unique ID

6. System Qualities

6.1. Availability

6.2. Security

6.2.1. Web Services

6.2.1.1. WS-Security

6.2.1.1.1. XML Signature. To achieve message authentication and integrity

6.2.1.1.2. XML Encription. To achieve message confidentiality

6.2.1.1.3. Security Tokens- To achieve Authentication and autorization

6.2.1.2. EJB

6.2.1.2.1. JAAS

6.3. Extensibility

6.4. Scalability

6.4.1. Load Balancer

7. Tecnologies JEE

7.1. Client Tier

7.1.1. PC

7.1.2. Design Principles

7.1.2.1. Affordance

7.1.2.1.1. Elements obvious to user

7.1.2.2. Feedback

7.1.2.2.1. User sent information following their action

7.2. Web Tier

7.2.1. JSF

7.2.1.1. Para garantizar interfaces ricas

7.2.2. JAAS

7.3. Integration Tier

7.3.1. JMS API and Message Driven Beans

7.3.1.1. queue

7.3.1.1.1. Post Request

7.3.1.2. topic

7.3.1.2.1. Provide Advice

7.3.1.2.2. Review Advice/Request Clarification

7.3.1.2.3. Respond to Additional Request

7.3.2. Web Services

7.3.2.1. SAAJ

7.3.2.1.1. Attaching documentation

7.3.2.2. WS-Security

7.3.2.3. Para la conexión entre la presentacion y la capa de servicios

7.3.2.4. SOAP

7.3.2.5. UDDI

7.3.2.5.1. Publish web services and have a single point to access them

7.3.3. JPA

7.3.3.1. For manage the persistence and garantice the transactionality

7.3.4. HTTPS

7.3.4.1. Garantice that the site is secure to the user

7.3.5. RMI

7.3.5.1. For clients who are java

7.4. Bussines Tier

7.4.1. Gestor Documental

7.4.2. JAAS

7.4.2.1. Garantice security with different modules

7.4.3. EJB

7.4.3.1. It provides the bussines logic

7.5. EIS Tier

7.5.1. Relational Database

7.5.2. LDAP Server

8. Design pattern

8.1. Proxy Pattern

8.1.1. Manejo de imagenes

8.2. Bussines Delegate

8.3. Factory Pattern

8.3.1. Choose which system should be used

8.4. Composite View

8.4.1. To manage the different views in just one

8.5. View Helper

8.5.1. Manage the logic of data access apart

8.5.2. Custom tags

8.6. Transfer Object

8.6.1. Manage the information through dtos and maintain a low latency

8.7. Bussines Delegate

8.7.1. Hide the details to connect to the bussines tier

8.8. Service Locator

8.8.1. Locate the services

9. Topologia

9.1. Modularility

9.1.1. Medium because it increase security but decrease availability

9.2. Redudancy

9.2.1. Medium because it increase availavility but decrease security

9.2.2. Cluster to help to availavility

9.3. Capacity

9.3.1. High because availavility

10. Risks

10.1. Network Communication and Layout. Due to there are many zones geographicly far away

10.1.1. Implementar alarmas de contingencia a nivel de red qeu permitan detectar caidas

10.2. The performance can have a delay because of security and distribucion

10.2.1. No abusar de la redundancia y la modularidad realizando controles con pruebas de estress de las mismas

10.2.2. Increase de server system capacity

10.3. Que los servidores excedan su capacidad de almacenamiento debido a que las imagenes son muy grandes

10.3.1. Generar políticas de archiving con los datos historicos

10.3.2. Garantizar que los servidores no superen el 80% de capacidad con alarmas

10.4. Usability - System is too complex to the users

10.4.1. Simplify the user interface and the interaction pattern

10.5. Througput - System insufficient to support the desired workload

10.5.1. Add Additional server cluster nodes

10.6. Scalability - System growth exceeds expected maximum rate

10.6.1. Plan for additional server cluster nodes so they can be added as necessary

10.7. Need for redistributing of services

10.7.1. Utilice some mecanism of publish as UDDI for web services

10.8. Attacks to the vulnerabilities

10.8.1. Avoid sql injection

10.8.2. Avoid cross-site scripting

10.8.3. Avoid denial of service with catchas

10.8.4. Dont show confidential information

10.9. Fuga Informacion confidencial

10.9.1. Implement security through all the layers

10.9.2. Provide an authorizacion and autentication system with JASS

11. Tradeoff

11.1. To ensure security will increase modularity. This can affect the availavility but we compensate this with a modrate level of redundancy an high capacity

11.2. We'll have a moderate level of redundancy for not affecting the security

11.3. We'll have hich capacity in all layers ensure availability