General concepts and terminology
It is worth mentioning that the concepts listed below will assist you in constructing the XML files that will be used for the M2M data exchange (see Technical documentation for further details):
Entity model: Represents the canonical model of business entities (e.g. actor, actor registration, device, certificate, etc.)
Service model: Models how data is shaped in order to be transported, encapsulated and delivered to the right service
Data exchange communication patterns: Defines how the data is exchanged between participants
Service definition: Describes how to represent and access the business capability.
Entity model
Most main business entities contain the abstract superclass Entity to express the versioning capability.
Generally, most of the entities exchanged (through the exposed services) are interrelated (have dependencies between them). To model this, a concept of link has been introduced. In this way, it is possible to isolate the information related to a specific sub-domain and only reference to the other related entities.
Service model
The service model describes the EUDAMED data structures used to perform information exchange and consists of the following elements:
Information about the type of message (from the data exchange messaging patterns pull/push)
Service destination information (each operation will represent a specific functionality)
Means to query / filter (criteria) the request
Security rules that may apply depending on the actor that performs it
Information available as response, number of provided entities, pagination and versioning capabilities.
Supported services operation
The following services operation are supported by EUDAMED:
GET: The GET method requests transfer of a current selected representation for the target resource. GET is the primary mechanism of information retrieval and the focus of almost all performance optimisations. Hence, when people speak of retrieving some identifiable information via HTTP, they are generally referring to making a GET request (PULL message type).
POST: The POST method requests that the target resource process the representation enclosed in the request according to the resource's own specific semantics (PUSH message type).
PUT: The PUT method requests that the state of the target resource be created or replaced with the state defined by the representation enclosed in the request message payload. A successful PUT of a given representation would suggest that a subsequent GET on that same target resource will result in an equivalent representation being sent in a 200 (OK) response. However, there is no guarantee that such a state change will be observable, since the target resource might be acted upon by other user agents in parallel, or might be subject to dynamic processing by the origin server, before any subsequent GET is received. Thus, a PUT request always contains a full resource. This is necessary because, a necessary quality of PUT requests is idempotence – the quality of producing the same result even if the same request is made multiple times (PUSH message type).
PATCH: The PATCH method requests that a set of changes described in the request entity be applied to the resource identified by the Request. With PATCH, however, the enclosed entity contains a set of instructions describing how a resource currently residing on the origin server should be modified to produce a new version. The PATCH method affects the resource identified by the Request-URI, and it also may have side effects on other resources; i.e., new resources may be created, or existing ones modified, by the application of a PATCH. To ensure an idempotent behaviour, clients using this kind of patch application should use a conditional request such that the request will fail if the resource has been updated since the client last accessed the resource (PUSH message type).
More information for each operation is presented in the table below.
Operation | Description | Supported communication patterns | Payload | Return value |
|---|---|---|---|---|
Download (GET) | This operation is invoked to request information using a criteria mechanism. | Pull | Search criteria | A PullResponse type message containing a list of the entity(ies) and all related fields based on the criteria specified in the request message |
Upload (POST) | This operation is invoked to upload (create) information to EUDAMED. | Push | For a specific entity fields to be filled to create the entity | Acknowledgement |
Update (PUT/PATCH) | This operation is invoked to update information to EUDAMED. | Push | For a specific entity fields to be updated | Acknowledgement |