The ORSCF specifications describe 4 separate backend modules, which are visualized as databases in the graphic below:

The “VisitData” module represents the primary data storage for visits. Although the internal data storage is of course subject to the respective individual implementation, we still deliver a completely usable data model and even a ShowCase implemented in C # (fully executable). The communication standard itself can be implemented on different transport technologies. The most common ways are the transport in form of FIHR ressources or by accessing a REST-API. For the last one we provide an OpenAPI-/Swagger-Definition describing the ‘VisitDataRepository-API‘. In all cases the specified schema is mandatory.

The “BillingData” module stores billing related information for the visits. Also for this module we deliver a completely usable data model, and an OpenAPI-/Swagger-Definition for access via REST.

The “IdentityData” module represents the primary source for data which is related to the personal identity of patients and/or study participants. The data model we have shown here does not claim to describe a complete identity management system. Only the part relevant for studies has been modeled here. When the usage of REST is planned, see the OpenAPI-/Swagger-Definition.

Last, but not least, the most complex part: the “StudyWorkflowDefinition” module. The specified model is a standard to describe a study protocol (as supplied by the sponsor) in a digital form. A special attention was given to the challenge to describe timeline of the required visits and cycles. In this part were have reached a unique level of detail, so that this part will be given more priority in future. Such digital workflow definitions can be supplied in form of a json-file, or persited into a repository (FIHR/REST/…). Here again an OpenAPI-/Swagger-Definition for REST, which also comes along with a ShowCase implemented in C # (fully executable).

Additional samples for FIHR will be supplied as soon as possible.