Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 11 Next »

Additions or changes requested

overall

EHR

  • Add /ehr/{ehr_id}/folder and /ehr/{ehr_id}/versioned_folder SPECITS-63 - Getting issue details... STATUS

  • Add missing EHR_ACCESS ?

  • fix EHR summary - not “very” restful => this is a breaking change

Definitions

  • SPECITS-43 - Getting issue details... STATUS => admin?

  • should we support also archetypes? => no, or at least is low prio, perhaps next version

  • are we going to support (reading) terminology / value sets? => no, this is the job of terminology service

  • add alternative /definition/adl2/{archetype_id_matcher} and deprecate /definition/adl2/{template_id}/{version_pattern} - potentially breaking change

  • query type => add “formalism” in text

(new endpoint) Demographics / Registry

group is ok to do the following, in a separate api page, but it should remain optional, not be required by conformance testing

  • ACTOR is abstract, so we’ll need concrete types

  • Sync SM specs

  • Add /registry/person/{version_uid} and /registry/versioned_person/{versioned_object_uid}

  • Add /registry/agent/{version_uid} and /registry/versioned_agent/{versioned_object_uid}

  • Add /registry/group/{version_uid} and /registry/versioned_group/{versioned_object_uid}

  • Add /registry/organisation/{version_uid} and /registry/versioned_organisation/{versioned_object_uid}

  • Add /registry/role/{version_uid} and /registry/versioned_role/{versioned_object_uid}

  • Add /registry/party_relationship/{uid}

  • Add also /registry/contribution/{contribution_uid} similar to /ehr/{ehr_id}/contribution/{contribution_uid}

Initially we discussed about /registry endpoint but we'll keep this for later (a new RM Entity?) and in the meanwhile we'll use /demographic as that matches current Demographic IM component name.

see also Pablo’s proposal SPECPR-406 - Getting issue details... STATUS and SPECITS-70 - Getting issue details... STATUS

TAGs

see 2023-06-05/07 Barcelona SEC Meeting tags suggestion (todo Sebastian Iancu )

POST|PUT|GET|DELETE /api/v1/ehr/{ehr_id}/(composition|folder..)/{version_uid}/tags[/{tag_key}[/{target_path}]] - Update tags on a COMPOSITION (and FOLDERs?). Existing tags will be replaced

(question: does the tags should also consider target_path? do we need to support case where more tags with same key is used for same target but with different target_path ?)

perhaps querying/filtering of tagged objects can be done like:

GET /api/v1/ehr/{ehr_id}/(composition|folder..)?tags[key]=value

adding tags on creation-time on compositions via headers in case of committing composition resource, and inline inside the contribution resource.

GET /api/v1/ehr/{ehr_id}/tags - Get all tags currently defined in the CDR for the current EHR.

Dips:

GET /api/v1/tag/keys - Get all tags keys currently defined in the CDR (DIPS variant).

Seref: maybe support tag incrementally, i.e. allow it to be used in Composition endpoint but not allow the full constraint semantics for tag to be used for aql because it may make it difficult for the implementers to apply the tag constraint to aql results (what if the tag.target_path is not in the SELECT OF AQL?)

Sidharth: What will happen if a composition is created with a tag atomically during POST, but is updated using PUT without the tags using the API

Sidharth/Erik: Strategy for filtering based on tags: 

  • OR tags: composition?tag=key1,key2

  • AND tags: composition?tag=key1&tag=key2

What should happen when we update a composition and the tags are pointing to a specific (previous) version, or to a path that does not exists inside the composition

Erik: perhaps we should add an invariant, stating that a path should be only used when the target is a version<T>.

Erik: should we support logic not() on query params?

(new endpoint) Admin

  • how should we deal with admin required functionality, e.g. destroy EHR, Compositions, Actors, etc ? Need a specific endpoint /admin or use DELETE action over resources, assuming ACL permits ?

  • delete template is problematic, if is “in use” - but on the other hand this is an admin endpoint, so it should be fine

  • export (and import), later also (partial) extract

    • /admin/ehr/{ehr_id}/export - need to define what will this dump - zip?

    • need something for ehr_extract ?

  • merging EHRs

  • system?

Bugs

  • SPECITS-60 - Getting issue details... STATUS

  • SPECITS-46 - Getting issue details... STATUS - might be a breaking change

  • SPECITS-44 - Getting issue details... STATUS but also to other places

  • SPECITS-68 - Getting issue details... STATUS

Headers

Missing (specification) details

  • SPECITS-62 - Getting issue details... STATUS

  • SPECITS-61 - Getting issue details... STATUS

  • SPECITS-50 - Getting issue details... STATUS try with prefer=identifiers

  • SPECITS-48 - Getting issue details... STATUS discussed on discourse, we should allow it (todo check), no need to do anything on REST level

Others

  • Reformat Introduction

  • Conformance info

  • IANA SPECITS-39 - Getting issue details... STATUS

  • Reformat and reorganize SPECITS-36 - Getting issue details... STATUS

  • Overall Layout

  • sync with SM, add UV models (relaxed RM) SPECITS-34 - Getting issue details... STATUS

  • authentication endpoint => (still) no needed

  • audit service endpoint => not prio, perhaps not part of rest api

  • (cds) hooks => if Cambio can help with a proposal then it can be included, but we should also look into generalized triggers

  • simplify, consolidate and reuse yaml-blocks while building up specs

All issues

The followings are all Jira issues scheduled for REST API Release 1.1.0:

key summary type created updated priority status resolution acceptance
Refresh

  • No labels