When it comes to HIPAA, Mayan is compatible with the intended goals of the Act by having strong access control system based on roles. The access control is fail secure and denies all access by default.
Mayan performs OCR in parallel to document text extraction and using the workflow system can perform advanced logic to detect and act upon Personally Identifiable Information (PII).
Here is an example based on actual support events: Detecting and tagging documents that contain social security numbers in the OCR
Assets and the image layer system can be used to superimpose watermarks for documents not allowed for printing. The watermark can also be controlled using versions as to produced marked or unmarked hard copies based on the role of the user.
Mayan has a complete event system to create an electronic paper trail for audits.
Regarding FISMA, Mayan has:
- Very comprehensive testing to reduce the chance of security issues. We test positives, negatives, access, no access, results, states, and artifacts (MERC 2: Test writing — Mayan EDMS 4.6.1 documentation). We test the components in conjunction and independently: views, API, data models, links, classes, etc.
- Security issues are listed, documented, and fixed in a little time: Security — Mayan EDMS 4.6.1 documentation. In 12 years only 5 minor security issues have been found.
- We have built our own dependency manager which allows updating any vulnerable dependency with a single change that then migrates to all app and build using the dependency (MERC 3: Using JavaScript libraries — Mayan EDMS 4.6.1 documentation)
- Mayan was one of the first, large scale Python projects to institute required used of keyword arguments to avoid the issues associated with positional arguments. MERC 5: Explicit arguments — Mayan EDMS 4.6.1 documentation
- Mayan also adopts a reduced information disclosure approach common in enterprise and mainframe systems: MERC 6: Lower information disclose — Mayan EDMS 4.6.1 documentation
- Documents are converted into images using isolated environments to avoid scripts or macros effects.
- Version 4.6 added document firmware scanning. Using the workflow infected documents can be managed in a multiple of ways: tagging, isolation, deletion.
- Mayan has explicit mitigation for common file based denial of service attacks like decompression bombs: mayan/apps/converter/classes.py · master · Mayan EDMS / Mayan EDMS · GitLab
- We have a very advanced CD/CI which allows performing builds and new releases in an automated manner. Our test suite is about 4,400 test unit. Before a release the entire test suite is execute against PostgreSQL, SQLite, PostgreSQL simulating an upgrade, SQLite simulating an upgrade, then finally inside a Docker image against PostgreSQL. A release pipeline executes close to 16,000 tests and only performs the version release if every single test passes: Pipeline · Mayan EDMS / Mayan EDMS · GitLab
- Memory and CPU usage is controlled at the individual worker level: config.env · master · Mayan EDMS / Mayan EDMS · GitLab
For Accessibility, we follow the general guidelines regarding ARIA tags and layouts friendly to screen reader, we also use a high contrast theme by default, but each user can have their own unique theme as required. The themes can be created without code modification. We use Bootstrap and follow its accessibility implementations.
Mayan uses has always used a UI system that relies on reusable markup which creates predictable and easy to parse UI. In version 4.6 we took it step further and converted the reusable templates into a component based web UI system. Components can now be improved independently without having to rewrite the entire user interface:
As you can see Mayan is a free open source project but is not managed in the typical open source project fashion when it comes to features and patches. Mayan is engineered and does not follow the more common chaotic development model of other open source software. Every feature is debated, then designed, implemented, tested, before being shipped.
As a project being used worldwide, it would be impossible to have the software certified or even comply with every possible design regulation or guideline. We follow the most common aspects of each guideline.
Final certification or validation will depend on the organization’s intended use of Mayan EDMS by itself or as an integration to a large element of their document projects.
Validations are available as part of the custom contract tier of our technical service product: