Skip to main content

Table 1 URI patterns for central resources

From: Applying representational state transfer (REST) architecture to archetype-based electronic health record systems

URI path template
Example path(s)
  Fetches a VERSION, identified by creating_system_id combined with version_tree_id, from the VERSIONED_OBJECT identified by object_id. URIs containing fragments (after a # sign) will have the same effect. Thus /ehr:12344321/ will also fetch the entire VERSION from the server and let the client deal with the fragment.
  Fetches only the part of a VERSION specified by the path after the id. This can be used by applications that for example due to privacy reasons only want to retrieve part of a version.
  Fetches object lists or metadata of different kinds depending on command, see openEHR specifications [8] for details.
  Fetches version based on lookup command, for example the version that was current at a specific time.
  Ad-hoc queries in the ‘multi’ use case can also produce lists or reports, sometimes containing detail hyperlinks pointing to versioned objects. By prepending multi to the path such objects can optionally be fetched from, and thus logged by, the multi database instead of the single database, if desired.
/ehr:12344321/contributions/?start = 1&end = 5&descending = true
  HTTP GET returns all contributions for the EHR identified by ehr_id, paged by variables start (default 1) and end (default 20) the default ordering is descending (most recent contribution listed first).
  HTTP POST is used to commit a contribution; all new and changed VERSIONs should be included in the body of the POST. The current LiU EEE implementation accepts either XML or serialized Java objects. Some web-based applications will instead of POSTing to this URI prefer to use the /cb/{committer_id}/{ehr_id}/{cb- id}/commit/ command (described in Table 2) that calls the same verification and storage mechanisms internally.
  Fetches the contribution identified by contribution_id
  1. Table 1 shows a subset of URI template patterns identifying central openEHR objects. A background to versioning and commands can be found in the openEHR Common Information Model specification [8]. The prefix ‘ehr:’ uses the colon sign so that interface designers more easily can make calls to EHR URIs as described in Section 11.3 of the openEHR Architecture Overview [5]. By prepending a slash (/) to an EHR URI found within data, it will become a fully functional HTTP link to the desired EHR object.