This website contains the software architecture documentation for the K.S.C.H. Workflows project.

Overview

The sections of the documentation are derived from the arc42 template:

Introduction and Goals

K.S.C.H. Workflows is a prototype for a custom-built hospital information system (HIS) for the Kirpal Sagar Charitable Hospital.

For the time being it should be considered as academic endevour, aimed at learning to build solid software systems, outside of the commercial pressure of normal software projects and health care facilities.

Quality goals

Out of the quality attributes classified by the ISO 25010 standard, the following three are the most important:

References

• https://blog.crisp.se/2016/03/16/perlundholm/continuous-discovery-and-validation
• https://dev.to/janux_de/building-a-greenfield-hospital-information-system-with-java-spring-boot-apache-wicket-and-gradle-4np1
• Building a Greenfield Hospital Information System with Java, Spring Boot, Apache Wicket and Gradle | dev.to

arc42

• https://docs.arc42.org/section-1/
• Introduction and Goals | dokchess.de/en

Constraints

References

arc42

• https://docs.arc42.org/section-2/
• Constraints | dokchess.de/en

Context and Scope

References

arc42

• https://docs.arc42.org/section-3/
• Context | dokchess.de/en

Solution Strategy

References

arc42

• https://docs.arc42.org/section-4/
• Solution Strategy | dokchess.de/en

Majestic Monolith

Motivation

Building microservices is often seen as synonym for building modern applications with clear separation of concerns. However, this architectural approach comes with a high complexity in terms of operations and development. Since the KSCH should also have a modern application but simplicity is one of the main quality goals, a different approach is taken: the Majestic Monolith approach. This combines some of the advantages of microservices - like facilitating the usage of Domain-Driven Design and event-based communication - with a simple deployment model. This is achieved with the help of modualization of the code base.

Clean Architecture

Also see

• DDD, Hexagonal, Onion, Clean, CQRS, … How I put it all together | hgraca
• https://medium.com/@mubashirhussain29/the-screaming-architecture-story-08750691291f
• https://levelup.gitconnected.com/what-is-screaming-architecture-f7c327af9bb2
• https://blog.cleancoder.com/uncle-bob/2011/09/30/Screaming-Architecture.html
• https://cleancoders.com/episode/clean-code-episode-67
• Hexagonal : Ports and Adapters

Gradle Multi-Projects

The modularization is build on the dependency configuration levels provided by the tool that is used to build the application. Gradle has the api and implementation dependency configuration levels (there are still a few more). And it enables to create subprojects for a Java project. In other words, projects can be nested with subprojects. If a sub-project A depends on another sub-project B with the api dependency configuration, then A can use all the types defined in B and another sub-project C that depends on A can also use all the types defined in B. On the other hand, if A depends on B with the implementation dependency configuration, then A can still use the typed defined in B, but if C depends on A, it has no access on the types in B.

Also see

• https://docs.gradle.org/current/userguide/declaring_dependencies.html#sec:what-are-dependency-configurations

Domain Modules

At the root of the backend repository are directories with the prefix "ksch.". In the context of the KSCH Workflows system these are referred to as domain modules since they are a digital model of parts of the KSCH. Those modules that are needed for technical reasons can be found in the "commons" and "server" directory.

├── commons
├── ksch.administration
├── ksch.billing
├── ksch.patientmanagement
├── ksch.reporting
├── ksch.scheduling
├── ksch.visit
├── server

Subprojects

Also see

• Go - The Ultimate Folder Structure
• Flat Application Structure in Go

Spring Application Events

Also see

• https://www.youtube.com/watch?v=5YdjBWSGtbE

References

• https://www.youtube.com/watch?v=BOvxJaklcr0
• https://www.monolithic.dev/
• https://robertorodes.com/the-blog/the-majestic-monolith-demystified/
• https://www.youtube.com/watch?v=IXnhHhE_rgM
• Spring Modulith

Domain Driven Design

Motivation

Form follows function

The purpose of this software system is to support the day-to-day processes in the Kirpal Sagar Charitable Hospital. How the system is structured internally is a secondary matter. What is important is that it supports the functional and operational requirements of the hospital staff. Further, it is important that the system can be molded when there the requirements are changing. So when new developers are coming into the system, it should be fairly easy for them to add new features or adapt existing features.

All software design patterns which are introduced need to be tested against this testing stone.

Object naming conventions

Data bag

In every software system there are actors and work materials which manifest in various layers of the software. In each layer there is a different focus for what needs to be done with the data.

• In the persitence layer it needs to be mapped to the database structure.
• In the domain layer there are business processes which are working on the data.
• In the user interface layer the data gets received.

In order to keep the different concerns distinct but still be able to keep them in sync, for every actor or work material there should be an interface which defines getter methods for the required data, e.g.

public interface Patient {
    Object getName();
    Object getAge();
    Object getGender();
}

On this layer the abstract Object type is being used so that each layer can decide on its own what is the approperiate data type there, e.g. getName() can return String on the database layer and Optional<Name> on the business layer.

Data Access Object

For the sake of convenience the object relational mapper JPA/Hibernate will be used in this project. The objects which will be mapped to the database columns will have the suffix "Dao".

The main idea here is to keep the JPA related annotations distinct from the classes which are used to process the business logic.

In order to prevent a broad usage of those classes, they should be package private.

Please note that this is a custom interpretation of the name "Data Access Object" which differs from common DAO pattern implementations. So maybe in future this could be renamed. However, other possible terms for this design idea, e.g. "Bean", might also invoke connotations to different concepts.

Domain Events

• https://martinfowler.com/eaaDev/DomainEvent.html
• https://docs.microsoft.com/en-us/dotnet/architecture/microservices/microservice-ddd-cqrs-patterns/domain-events-design-implementation
• https://www.innoq.com/en/blog/domain-events-versus-event-sourcing/

References

• https://github.com/xmolecules/jmolecules
• https://www.reddit.com/r/learnjava/comments/b2h3pm/differences_between_java_bean_entity_class_dao/
• https://www.martinfowler.com/bliki/AnemicDomainModel.html
• https://en.wikipedia.org/wiki/Data_access_object
• https://ddd-book.karthiks.in/
• https://vaadin.com/blog/ddd-part-2-tactical-domain-driven-design
• https://learn.microsoft.com/en-us/dotnet/architecture/microservices/microservice-ddd-cqrs-patterns/seedwork-domain-model-base-classes-interfaces

OpenAPI

OpenAPI is a standard for the specification of HTTP APIs. It is designed to be readable both by humans and by machines. So, it is possible to declare OpenAPI Specifications (OAS) in a plain text file that can then be used by computer projects for validation and code generation.

Table of contents

• Overview
• Design process
• Documentation
• References

Overview

The backend component offers a REST API for the frontend components like for example registration-desk. Inside the backend there are for example the sub-components ksch.patientmanagement.impl and test. The ksch.patientmanagement.iml component defines the REST handlers which will process the requests from the API clients.

The test component defines various utilities which can be used for the internal tests of the other components. It has a dependency on Atlassian's open-source project swagger-request-validator and defines a utility class for its initialisation. The internal tests of ksch.patientmanagement.impl components leverage the functionality of swagger-request-validator to verify that the test requests and responses match with the API structure defined in the OAS.

The registration-desk uses the Dart library ksch-dart-client for accessing the REST API. Currently, the code of that component is manually created. Later on, the Dart code in the ksch-dart-client component could be generated from the openapi.yml file.

The structures described above are visualised with the following UML Component Diagram:

API design process

The idea of the API design process is to create the "spec first" and afterwards the implementation. So, if the maintainers of frontend clients need a change in the backend API, they can propose a change in the openapi.yml. Once there is an agreement on the change to the OSA, the backend maintainer and the frontend client maintainers can work in parallel on the new feature.

Also see

• Using spec-first API development for speed and sanity | atlassian.com
• Episode 542: Brendan Callum on Contract-Driven APIs | se-radio.net

Documentation

The backend's API documentation is generated from the OAS with the free plan of the SaaS service bump.sh.

References

• OpenAPI Specification 3.0
• Spring: Adding OpenAPI validation to MockMVC tests | dev.to

Building Block View

The backend provides a REST API which abstracts database access and business process validations for the client applications.

All the client applications are Flutter apps. They are using the ksch-dart-client library for accessing the REST API of the backend.

The registration-desk is a Flutter Web app to be used at the registration desk of the KSCH.

Later on there should also be a Flutter Web app for the pharmacy desk.

Further, there should be a Flutter Android app for the hospital administrator.

For the first experiments with the system, all the REST requests will be unauthenticated. When the system goes live, the requests should be authenticated using an API token aquired via an OAuth 2.1 authorization server.

References

arc42

• https://docs.arc42.org/section-5/
• Building Block View | dokchess.de/en

Runtime View

References

arc42

• https://docs.arc42.org/section-6/
• Runtime View | dokchess.de/en

Deployment View

Development

The backend is hosted on the Google App Engine.

The Flutter Web apps for the various work stations are hosted on GitHub pages. It might be better not to bundle those components during development, so that the online apps can be updated independently. This simplifies the continuous deployment process and shortes the build times and thus the feedback cycle.

Staging

The final QA for production releases could be done with temporay VMs hosted on the Digital Ocean platform, using the same app structure like the production system.

Production

The production system is started via Docker Compose with the following services:

• MySQL database
• backend
• for each Flutter Web app there is a separate HTTP service which hosts it

Maybe the web apps could also be copied into the src/main/resources/static directory of the backend when it is compiled for production use. This would also make it possible to host the whole system on the Google App Engine which would have the advantage that it can be accessed by the doctors also from home. And if the system doesn't deal with medical records, the data should not be too sensitive to be hosted in a public cloud.

Even if we use the cloud for the production system, it might be best to use Digital Ocean or plain VMs on the Google Cloud to keep the door open for self-hosted servers. Using the Google App Engine would simplify the operations, though. It takes care e.g. care of log storage and alerts.

References

arc42

• https://docs.arc42.org/section-7/
• Deployment View | dokchess.de/en

Crosscutting Concepts

References

• How links are added to REST resources across modules | dev.to

arc42

• https://docs.arc42.org/section-8/
• Technical and Crosscutting Concepts | dokchess.de/en

Data interfaces

Motivation

In Spring applications it is possible to use the same class type for the deserialization of payload of HTTP requests and database persistence. This may become a problem if not all properties of the type should be accessible on the API. Also, it may raise security concerns. And following the ideas of DDD, the entities should represent the business domain and its rules. If the entity also contains the necessary annotations for the HTTP serialization/deserialization and database serialization/deserialization, the business rules are mixed up with those concerns and become harder to understand as the application grows over the years.

Data interfaces

In KSCH Workflows, each module has a subproject called "api" where interfaces of data classes reside. Those interfaces contain only the getter methods for the properties of the data classes. They may be part of event types that are also part of the "api" subproject. Or potentially also parameters and return types for API services.

public interface Patient {
    UUID getId();
    String getName();
    Integer getAge();
    Gender getGender();
    String getPhoneNumber();
    String getResidentialAddress();
    String getPatientCategory();
}

Data interface implementation

Most data interfaces will have three implementations: (1) the entity class for the application core, (2) the data access object for the persistence layer, and (3) the data transfer object for the web layer.

This approach provides a clear separation of concerns where each class has a distinct, single responsibility. However, it comes at the cost of requiring mapping code at the layer boundaries. The preferred way to implement this is without any third-party packages but with simple static factory methods.

@Getter
@Builder
// ...
public class PatientEntity implements Patient {

    private final UUID id;

    private final String name;

    // ...

    public static PatientEntity from(Patient patient) {
        return PatientEntity.builder()
            .id(patient.getId())
            .name(patient.getName())
            .age(patient.getAge())
            .gender(patient.getGender())
            .phoneNumber(patient.getPhoneNumber())
            .residentialAddress(patient.getResidentialAddress())
            .patientCategory(patient.getPatientCategory())
            .build();
    }
}

Testing

When manual mapping of dozens of properties in multiple places is required, it comes with the risk of forgetting one or the other property. This can be mitigated by creating objects with all fields propagated with random data with the help of Instancio and then checking if the object created with the from factory method equals the original object.

public class PatientEntityTest {

    @Test
    @DisplayName("Should create patient entity from data interface")
    void test_from_factory_happy_path() {
        var originalPatientEntity = Instancio.create(PatientEntity.class);

        var clonedPatientEntity = PatientEntity.from(originalPatientEntity);

        assertThat(clonedPatientEntity).isEqualTo(originalPatientEntity);
    }
}

References

• https://cinish.medium.com/java-consider-static-factory-methods-when-you-want-to-provide-ability-to-create-instances-of-2a4755e66424
• https://thorben-janssen.com/dont-expose-entities-in-api/
• https://softwareengineering.stackexchange.com/questions/390084/is-there-a-reason-to-define-an-interface-for-a-pure-data-class
• https://www.reddit.com/r/Kotlin/comments/s6utca/return_interface_instead_of_data_class/
• https://discuss.kotlinlang.org/t/data-interfaces/25278/4
• https://docs.spring.io/spring-framework/reference/core/validation/convert.html
• https://www.petrikainulainen.net/programming/spring-framework/spring-from-the-trenches-using-type-converters-with-spring-mvc/
• https://github.com/vbauer/houdini

Data classes

• https://github.com/lets-data/letsdata-data-interface
• https://openjdk.org/projects/amber/design-notes/data-classes-historical-1
• https://medium.com/androiddevelopers/data-classes-the-classy-way-to-hold-data-ab3b11ea4939

DDD

• https://ksch-workflows.github.io/architecture/04_solution-strategy/ddd/index.html
• https://martinfowler.com/bliki/AnemicDomainModel.html
• https://stackoverflow.com/questions/2352654/should-domain-entities-be-exposed-as-interfaces-or-as-plain-objects
• https://deviq.com/domain-driven-design/shared-kernel

Architectural Decisions

This section provides an overview over the rationale behind important structural decisions.

• 2024
• 2021

References

arc42

• https://docs.arc42.org/section-9/
• Design Decisions | dokchess.de/en

2024

Replace MySQL with Postgres

Other projects one the same CloudSQL instance might use PostgreSQL due to its full text search capabilities.

By using PostgreSQL also for KSCH Workflows, both apps might share the CloudSQL instance with separate databases.

In the context of the KSCH it would be better to use MySQL, because this is used for other applications in Kirpal Sagar. Since the production use of KSCH Workflows is only in the very far future, the cost factor for the development environment is more relevant, for now.

Archive Flutter Web app

Context

• Currently there is only one developer maintaining this project.
• Flutter Web is a great technology, but not yet commonly used in enterprise applications.
• React and Angular are commonly used in enterprise applications.
• Keeping up-to-date with more than two technology stacks (Java/Spring, Dart/Flutter, JavaScript/React) is too time-consuming.

Decision

• The backend of the KSCH Workflows system is developed with production-quality.
• The frontend of the KSCH Workflows system is developed in prototype-quaility.
  • The frontend technology gets now replaced from Flutter Web to React/Bootstrap.
  • In a few month it may again get replaced with Angular.
  • It is assumed that the frontend gets re-created from scratch if professional frontend developers and/or designers join the project.

2021

Java application architecture style

Context

There needs to be a concept for the module structure of the backend server.

Design goals

• The business logic of the software needs to be very flexible, so that it can be adjusted to changing requirements of the KSCH.
• The system needs to have good testability, so that there can be a very good test coverage for those business rules.
• Enable hobby developer to contribute to the project in limited spare time. In order to achieve this, the congnitive load for working on a part of the system needs to be reduced to the minimum.
• The system needs to be able to grow to support a wide range of functional requirements, so that it can potentially support all the IT based processes in the KSCH.

Constraints

• As programming language, Java should be used, since it will most likely be supported and have a large community over the next decade.
• As application framework, Spring should be used, since it allows to make rather fast progress with a very small development team.
• There will be only a single process running for the backend server, i.e. no microservice architecture. The reason for this to keep the operational complexity of the system at a level where the KSCH staff might operate the system independently.

Alternatives

(A) Gradle based modules

The modules may be based on Gradle's multi-project builds. Every module can have two nested modules: one for the API and one for the implementation. If one module wants to use the API of another module, it will only be able to use the classes defined in the API submodule.

Pros

• Gradle features take care to limit cross-module access on the intended API and to avoid cyclic dependencies between modules.
• It is theoretically possible to automatically render module dependendency graphs by parsing the Gradle configuration.
• The system design can be understood by referencing to the Gradle documentation which is good.
• Once it Gradle parts are understood, it is fairly each to introduce new modules.

Cons

• In order to add new modulues, one needs to understand the Gradle project structure and then do a dozen of steps.
• Gradle makes regular breaking changes, which leads to maintenance efforts.
• There is no known example for a production system which was successful using this architecture.
• It is not yet clear how to manage database migrations with this architecture style.

References

• https://github.com/ksch-workflows/ksch-workflows
• https://docs.gradle.org/current/userguide/multi_project_builds.html
• https://dev.to/janux_de/building-a-greenfield-hospital-information-system-with-java-spring-boot-apache-wicket-and-gradle-4np1
• https://www.petrikainulainen.net/programming/gradle/getting-started-with-gradle-creating-a-multi-project-build/
• https://www.tutorialspoint.com/gradle/gradle_multi_project_build.htm
• https://spring.io/guides/gs/multi-module/

(B) Modulith

The Moduliths project is an experimental approach to achieve a good modularization for monolithic Spring applications by Oliver Drotbohm.

Pros

• There is a low risk of the "Architect's Ivory Tower" where there is a "Lack of Transparency" of the system's architecture and a "Lack of Understanding" from the developers (see Knoernschild, p. 30 ff.).
• The concept addresses many common architectural problems: cyclic dendencies, complexity, ...

Cons

• Learning efforts for Maven and ArcUnit.
• Using this approach creates a depencency on a one-person project which might be abandoned at any time.
• The README introduces the project as "A playground to build technology supporting the development of modular monolithic (modulithic) Java applications." So it looks rather like an experimentation ground than an estabilished pattern for production systems.
• It relies on conventions enforced by ArchUnit to provide access control. The api/implementation destincition from Gradle might make it clearer what is intended to be accessible or not.
• It assumes that the whole application is living a in a single Java package. The modules are then defined as subpackages. This creation a weaker demarkation line for modules than Maven or Gradle sub-projects.

References

• https://github.com/odrotbohm/moduliths
• https://www.youtube.com/results?search_query=modulith+drotbohm
• https://github.com/st-tu-dresden/salespoint
• Knoernschild: Java Application Architecture, Kirk Knoernschild

(C) Buckpal

The Buckpal project is a reference implementation of the clean architecture principles by Tom Hombergs.

Pros

• Clear application structure based on the "Hexagonal architecture" design which may be considered as "best practice".

Cons

• The example application is for a rather small domain. So it is not clear how this application style will scale for large domains.

References

• https://github.com/thombergs/buckpal
• https://www.amazon.de/dp/B07YFS3DNF/ref=dp-kindle-redirect?_encoding=UTF8&btkr=1

(D) Leasing Ninja

The Leasing Ninja project is a reference implementation of domain-driven design principles by Henning Schwentner.

Pros

• Clear separation of concerns
• Clear modularization
• Support for domain driven design principles

Cons

Interesting advice about Java Module System by @joshbloch in Effective Java 3rd edition: "It is too early to say whether modules will achieve widespread use outside of the JDK itself. In the meantime, it seems best to avoid them unless you have a compelling need." - twitter.com

References

• https://github.com/leasingninja/leasingninja-java-boundedcontexts-domainmodel
• https://leasingninja.github.io/
• https://blog.plan99.net/is-jigsaw-good-or-is-it-wack-ec634d36dd6f
• https://trishagee.github.io/presentation/real_world_java_9/
• https://developer.ibm.com/languages/java/tutorials/java-modularity-1/
• Effective Java, Edition 3, Joshua Bloch, Item 15.
• reasons for low adoption of JPMS - https://youtu.be/YYvc-DNuwr8?t=1272

(E) OSGi

Pros

• Strong modularization support
• Enables a plugin system

Cons

• No direct Spring support (see https://docs.spring.io/spring-osgi/)
• Not all Java libraries cannot be used out of the box, but they need to be compiled specifically for OSGi.
• High learning effort
• It's rather a non-mainstream technologies which stands in the way for getting more developers for the system.

References

• https://en.wikipedia.org/wiki/OSGi

Decision

A combination of option A and option D seems most promising.

Use Java instead of Kotlin

Context

Kotlin tries to solve some of the problem in the design of the Java programming language. There are many senior developers which advocate to use Kotlin over Java. Also it is preferred by many mid-level developers.

Alternatives

(A) Java

Pros

• Very broadly used
• Many tools which support the language
• Lots of tutorials

Cons

• Verbose syntax
• No null safety

(B) Kotlin

Pros

• Null safety
• Good reputation
• Enables to write elegant code

Cons

• Pushes for certain design ideas (e.g. no inheritance possible by default)
• It adds an additional layer on top of Java which increases the complexity
• In some edge cases this abstraction layer in incomplete and workaround are needed
• The documentation of the standard libraries is pretty abstract

Decision

Java will be used for the sake of its simplicity. This will enable more people to work on it.

Use Google App Engine for the deployment of the staging environment

Context

In order to iterative development cycles for acceptance testing and user experience design, it is necessary provide the software in a publicly accessible domain. Since the instance will only be sporadicly used at random times, having an always online instance hosted on a rented virtual machine would be wasteful.

Alternatives

(A) AWS Lambda

Pros

• AWS offers lots of powerful features to build web applications.
• The usage based pricing plans lead to fair operational costs.

Cons

• Requires much learning to get used to the serverless paradigm.
• Using MySQL from Dart would require a package which is licensed with a copyleft license (GPL).
• Using AWS' DynamoDB would require much learning to get used to the NoSQL paradigm.
• Using Spring on AWS is possible to seems like not a good idea because of Java/Spring warm start is required.
• Using AWS Lambda creates vendor lock-in which makes it difficult to switch to another deployment platform later on.

References

• Learn AWS Serverless Computing: A beginner's guide to using AWS Lambda, Amazon API Gateway, and services from Amazon Web Services
• AWS Lambda and API Gateway Basics - Build Serverless website
• AWS Lambda and the Serverless Framework Training | Udemy
• AWS Lambda & Serverless Architecture Bootcamp (Build 5 Apps) | Udemy
• AWS Serverless APIs & Web Apps - A Complete Introduction | Udemy

(B) Google Cloud Functions

• https://github.com/GoogleCloudPlatform/functions-framework-dart

Pros

• It might be possible to use Dart both in the frontend and backend and thus have a simple system.
• Serverless computing can provide good performance with little operational effort.

Cons

• The Dart support is a prototype, at the moment.
• The maintainers of the project give feedback on pull requests or issues with low priority. E.g. there is no comment on PR#179 after 13 days.

(C) Firebase

Pros

• Low operational costs.
• Powerful features, e.g. storage and user authentication.

Cons

• Vendor lock-in.
• Business logic in storefront.
• Since Dart is not supported for Firebase's serverless offerings, it is not possible to create custom APIs without adding a new language in the stack (e.g. Python or JavaScript).
• Restrictions on the number of projects which can be created.

(D) Heroku

• Backend can be implemented with Java/Spring.
• The VM is started when a request is coming in.
• When there is no request for 30 minutes, the VM goes to sleep.

Pros

• Simple deployment process.
• Keeps to door open for an on-premise deployment.
• No operational cost.

Cons

• The free plan is limited to 512 MB (this should be sufficient for quite a while, though).
• Also the next standard plans are limited to 512 MB. And getting more RAM for a production environment would be very expensive.
• The idea to use Dart for both the backend and the frontend needs to be discarded.
• Uses Postgres as preferred database while MySQL is already in use in Kirpal Sagar.

(E) Google App Enginge

• Backend can be implemented with Java/Spring.
• It is possible to (auto?) scale to the app instances to zero when they are not used.

Pros

• Simple deployment process.
• Keeps to door open for an on-premise deployment.
• Supports MySQL via CloudSQL

Cons

• The idea to use Dart for both the backend and the frontend needs to be discarded.

References

• Scaling Google App Engine to No Instances (or maybe just 1) | by drew | Google Cloud - Community | Medium
• google app engine - How to scale down to 0 instances in GAE Standard Go - Stack Overflow
• google cloud platform - GAE automatic scaling does not scale down to 0 - Server Fault

Decision

• AWS Lambda requires too much learning and creates too much vendor lock-in.
• Google Cloud Functions via the Dart functions framework created too much risk because it may never be production ready.
• Using Firebase creates vendor lock-in and moves all the business logic in the frontend.
• Heroku is applicable but they don't offer temporary high-performance VMs.
• Google App Engine offers hosting of Java/Spring applications on high-performance VMs which can scale down to zero instances.

So, it seems like it will be better to use a classic Java/Spring backend instead of a cutting-edge serverless backend. Google App Engine seems like a good fit in terms of features and price.

Use Flutter as framework for frontend

Alternatives

(A) Apache Wicket

Pros

• Powerful framework to create Java based web applications.
• Relativly small learning curve for new contributors.
• Supports the reaction of a well designed, modular page structure.
• Very active community.
• The framework is time-tested and stable.

Cons

• Adding pages with highly dynamic content requires JavaScript which is possible to be hooked into Wicket applications but this gets more and more complicated and thus goes against the goal of maximum simplicity of the source code.
• Very small community.

(B) Vaadin

Pros

• Powerful framework to create Java based web applications.

Cons

• It is hard to write the Vaadin apps using TDD.
• Comprehensive testing of Vaadin apps requires their enterprise plan which costs too much for this project and is not suitable for open source contributors.

(C) Flutter

Flutter is a frontend framework which started out for mobile devices and now supports also web and desktop applications.

Pros

• There is a very large community around Flutter.
• Enables professional designs without complex CSS.
• Has a high potential to become one of the next mainstream UI frameworks.

Cons

• The web and desktop support is not yet mature.

Decision

Only with Flutter it is possible to create user interfaces for the web, mobile devices, and the desktop. This is essential because of the tiny size of the development team. Even though Flutter Web and desktop support is rather new, it works and will surely become better and better over time. That's why it seems like Flutter is the best choice for this project.

Quality Requirements

Truck factor

TBD

References

arc42

• https://docs.arc42.org/section-10/
• Quality Requirements | dokchess.de/en

Risks and Technical Debt

References

arc42

• Risks and Technical Debt | docs.arc42.org
• Risks | dokchess.de/en

Correctness risks

• Misunderstanding of requirements
  • Wrongly specified requirements
  • Not identified requirements
• Software defects (program not behaving according to specification)
  • Defects resulting in business process disturbance
  • Defects resulting in clinical errors
    • Mis-identification of patients

Security and privacy

• Patient data might get stolen
• Staff data might get exposed outside authorized persons
• Internal data might get exposed
• System is not available
• inappropriate access
• malicious theft
• viruses, worms, denial of service attacks etc.

References

• openEHR system overview | Threats to Security and Privacy

Maintenance risks

• Costs
  • Opportunity costs: the funds needed for the system may be put to better use somewhere else
  • Insufficient funds of implementation of legal requirements
• Support
  • Non-availability of first level support
  • Non-availablity of second level support
  • Non-availablity of third level support
• The further development of the project might come to a hold

Laws and regulations

• Violation of legal regulations
• Unawareness of legal regulations

Mitigation strategy

Focus on administration

A hospital information system deals with administrative data and medical records. The former is less critical than the latter, so until there is a budget for legal consulting, it might be best to focus on the administrative data.

Apply openEHR specifications

Taking openEHR as inspiriation, the quality standard will probably high enough to adapt to local requirements.

References

• https://dev.to/italon9/comment/98o8

Glossary

References

arc42

• https://docs.arc42.org/section-12/
• Glossary | dokchess.de/en