Table 2.
Adopted semantic web standards, their use rationale, and implementation details.
| Standard | Description | Use | Reason chosen |
| HTTP 2 [22] | Ubiquitous web standard that declares and defines the semantics of client-server communication with a rich and readily available debugging and implementation toolset and ecosystem not available for custom binary protocols | Implemented by core programming libraries and the backend | In contrast to TCPa-based binary data protocols requiring specialized tooling to access and work with data, almost all systems and tools are able to interact with web standards through the HTTP protocol. |
| RESTb [25] | Ubiquitous lightweight HTTP-based web standard that defines systems logically through accessibility and manipulation of remote resources instead of invocation of remote functions | Implemented by core programming libraries and the backend | In contrast to a custom implementation of remote function invocation that would require custom programming libraries to interface with, most web systems are able to interact with REST-based resources in a logical manner. In the absence of developer knowledge or pre-existing tools, it remains possible to communicate with RESTful systems. |
| JSONc [26] | Ubiquitous web standard that supports structured (as opposed to tabular, ie, CSV files) formatting and markup of data using strict data types | Implemented across all components in the platform | In contrast to encoded binary data formats requiring specialized tooling to interpret and work with data, most programming environments support the JSON standard. |
| TLSd version 1.3 [27] | Ubiquitous web standard that enables encryption of data in transit between client and server | Implemented by core modules and programming libraries, used by all components in the platform | No alternative |
| AES-256e [28] | Ubiquitous cryptographic standard that enables encryption of data at REST (on disk) by a database | Implemented by the backend and mandated by the backend and deployment configuration for the database within which data shall be stored | No alternative |
| JSON Schema [24] | Web standard that describes JSON-encoded data and metadata through ahead-of-time specification of a universally agreed upon schematic, as opposed to inline schema provided only at runtime | Implemented by the backend and used by the frontend | Although binary protocols require a predetermined strict schema to format the data, JSON does not. JSON Schema provides ahead-of-time resolution of the contents of a data payload and can be used to validate and harmonize data as well. |
| OpenAPI [23] | Web standard that describes REST-based web services and metadata through ahead-of-time specification of a universally agreed upon schematic | Implemented by the backend and core programming libraries and used by the frontend | In contrast to writing programming libraries and testing or validation tools, the generation of these tools and packages by the OpenAPI ecosystem increases productivity. |
| HTML5 [29] | Ubiquitous web standard that makes it possible to securely embed custom user interfaces backing patient-facing activities | Implemented by the frontend and all patient-facing activities, with wide support for CSS3f and JavaScript 2016 (ES6g) | No alternative |
| Vega [30] | Visualization grammar standard that encodes charts and graphs as JSON documents that are then rendered and viewed interactively by apps | Implemented using HTML5. Implemented by the frontend and Cortex analysis code | In contrast to static images and handwritten analysis code, the ability to declaratively generate interactive real-time charts through an embedded query reduces data science and clinician effort and fatigue. |
aTCP: transmission control protocol.
bREST: Representational State Transfer.
cJSON: JavaScript Object Notation.
dTLS: Transport Layer Security.
eAES-256: Advanced Encryption Standard.
fCSS: Cascading Style Sheets.
gES: ECMAScript.