Reference no: EM131220071

Introduction

The assignment is to design a Service Oriented Architecture-based solution for a given domain. You must show a good understanding of Service Oriented principles. In addition you must show knowledge and understanding of specific SOA techniques, practices and approaches in the design.

Assessment objectives

This assignment is being assessed. Like other modules, you will pass or fail dependent on demonstrating certain things. In this case the main criteria for passing is that you understand and can apply SOA concepts, principles and approaches for reasonably complex systems. This means that you must address key issues such as governance, security, description and discovery in your assignment. Your assignment must also show good service decomposition and a good understanding of why to use services, where to use services, and what makes a good service.

Domain - Patient Records

The UK has had a failed top down attempt to create a single IT system that would allow any hospital or medical practice to access any patient's medical record, securely and reliably. Recently, the NHS has been changing the architecture to utilize a lot of open source tools instead of proprietary models.

In this assignment, we are going to explore a completely different alternative: one in which each patient has complete responsibility for their own data.

Patients can either (if they are technically savvy) run their own medical record service, or they can choose a provider.

If they choose a provider, the provider must ensure that the records are secure and meet the relevant privacy, security and protection rules. Patients must be able to delegate rights to various healthcare providers - for example, to allow their doctors to read and update their medical record. They might allow a hospital instant access to read their records, with a limited time. They should be able to put time limits on access. You might want to think about how this gets delegated - for example you may want a specific doctor or department in the hospital to see your data but not another.

Like mobile phone number portability, each provider must provide a facility to securely transfer their medical record to another provider and to ensure that all data is deleted after successful transfer.

This is a large domain problem with multiple solutions, so it is up to you to choose and approach and justify it. Issues of security, identity and reputation are key in this model, and open APIs spring to mind as being an essential aspect.

What is expected?
This is far too large a problem for us to solve completely. You are not expected to implement this system. Instead there are a set of questions about this system that you must answer.

You are not expected to provide a complete solution, and you are not expected to solve all the security and privacy issues of this problem, but you are expected to think significantly about these, given the security and privacy issues inherent in this problem.

Word count, excluding appendices. Expected 3000, Maximum 4500.

Questions:

Part A. External Architecture

There is an external facing part of this solution - i.e. the connectivity between hospitals, doctors' surgeries, etc and the patient record data management providers.

1. What are the main services that any medical data provider must implement. Name the services and provide a short description of each of them. A table would be a good approach to presenting this information.

2. What is the chosen standard technology interface to these services? SOAP or REST or a third option?

3. Provide a service description such that a third party can easily write a client to talk to it. For example, a well defined Swagger, RAML, WSDL, WADL or other technical description. Alternatively very clear hand-written documentation is another option. If you automatically generate the documentation make sure that it still provides clarity and description. Place a exemplary sample of the documentation in the main body of the text and use the appendices for the full documentation.

4. Are there any other services that are needed? For example, is there a need for any central registry, services or identity providers? Enumerate and describe these services in the same format as you chose for item A1.

5. Provide an overall architecture diagram of the external facing system and at least one sequence diagram showing service interactions between parties.

Part B. Internal Architecture

There is another aspect of this system, which is the design of the internal systems within a medical data provider.

1. Take one of the services that you have identified and provide an implementation of this service. Provide clear reasoning for your design choices. For example, if you choose to not use a particular aspect of SOA then you should demonstrate that it was a clear design choice and not an oversight. You may add code listings to the appendices. Provide a message trace of your service being called.

2. Draw an architecture diagram of a "reference architecture" for a medical data provider. Since this is an SOA, of course the providers participating in the network can use any technologies they like, but if you had to design such a provider, what would your architecture look like. Provide some brief overview of the architecture to accompany the diagram that explains how the required services would be implemented.

Part C. Non-functional requirements

1. How is the overall system secured? Provide clear details of the security model including how identities of patients are managed, how patients can authorize access to their records, and how confidentiality, integrity and other security aspects are maintained. How do the technologies you have chosen fit with a service-oriented architecture?

2. How is the system monitored and managed? How can the overall availability of the system be maintained and ensure that patients records are available as needed, especially when there are disparate parts implemented by different organizations.

3. What is the governance process and deployment/operations model you would propose for this system?

Part D. Conclusions

Having defined the system and very partially implemented it, you should have a good view on the success of this system in meeting the objectives. Please evaluate and validate your decisions and your approach.

1. Is there an ESB, API management system, a registry, or a business process manager in your solution?

2. If you chose to use an ESB, what was the driving force behind the decision and what benefits did it bring? If you chose not to use an ESB, what were the tradeoffs and what other technologies are you bringing to bear to ensure that the system is manageable, extensible and supports evolution?

3. How did you decide the granularity of your services?

4. What are the strengths and weaknesses of this design and of the use of SOA in this design?

5. What are the biggest challenges you came across in designing this architecture?