/
Overview for REST API todos - for Release 1.1.0 (or 2.0.0)

Overview for REST API todos - for Release 1.1.0 (or 2.0.0)

1 EHR | 2 Definitions | 3 Demographics | 4 TAGs | 5 Admin | 6 Query | 7 Bugs | 8 Headers | 9 Missing (specification) details | 10 Others | 11 Priority tickets: | 12 All issues

EHR

Definitions

  • https://openehr.atlassian.net/browse/SPECITS-43 => 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

Demographics

https://openehr.atlassian.net/browse/SPECPR-406 and https://openehr.atlassian.net/browse/SPECITS-70

TAGs

https://openehr.atlassian.net/browse/SPECITS-77

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 ?

  • shredding Person/EHR (partial, cohort) Use case: e.g. after archiving them elsewhere based on some (AQL) selection criteria.

    • POST https://{baseUrl}/v1/admin/ehr/$destroy?query={stored_query_name}&target={ehrs|compositions} - still need to think about this. (Query should, depending on target parameter, return either a list of ehr ids or a list of composition ids)

  • delete contribution:

    • @Alex Vidrean is not possible in EHRbase as leads to inconsistencies; instead there might be a need to support roll-back

    • conclusion: this functionality (hard-delete) will not be supported, but consider to discuss in the future about a roll-back

  • delete template is problematic, if is “in use”

  • delete stored query, including delete stored query at version

  • export / import

    • /admin/ehr/exports

    • /admin/ehr/import

    • configure the export/import task scope with a payload (e.g. all-ehrs, subset of ehrs based on their ehrIds, “some compositions”)

    • background tasks - consider polling

    • need to define what will be the format for this dump - zip?

      • we will need to define schema for this export format

        • @Severin Kohler what should be the resource format? for data scientists would be better as flat-format, perhaps based on a parameter on the export-time

        • @Erik Sundvall If looking for database-like dumps it could be worth comparing https://www.sqlite.org/ to  https://parquet.apache.org/ (that is often used in data lakes etc.)

      • @Seref Arikan sqlite would be a good interop file format, but the content (data) needs to be discussed

        • @Severin Kohler csv or json?

      • Ian: see Josh Mandel on dumping ehr-data

      • do we need something like ehr_extract ?

      • self-contained package, including templates, archetypes; maintaining cross references, versioning, contribution

      • import should work on existing populated CDR

        • what if template or other data already exists?

        • Alex: consider keycloak import/export strategies

      • consider flag to anonymize data upon export

    • can be used for data migration from one CDR to another, or another version

    • Ian: https://msc-ehi-export.medsphere.com/

    • consider POST https://{baseUrl}/v1/admin/ehr/{source_ehr_id}/$export ?

  • merging EHRs

    • parameters: source ehr-id and target ehr-id

    • Sebastian: it will move data from old ehr to new ehr

    • Sebastian: might be possible to use ehr_status to indicate that source ehr was merged, perhaps use folders or tags to mark the merged content

    • Alex: use ehr_status other_details or feeder_audit to indicate merging information

    • see also Linking and Merging EHR IDs

    • Erik: I wonder if merge is a variant action of moving data

    • better has also unmerge and move operations

    • how to deal with merge-conflicts ? imagine merging persisting compositions, episodes, demographic data, duplicates tags, etc

    • POST https://{baseUrl}/v1/ehr/{target_ehr_id}/$merge?source={ehr_id} not very clear, a more clear suggestion is POST https://{baseUrl}/v1/admin/ehr/$merge?source={ehr_id}&target={ehr_id}

  • system?

Query

  • looking to federative-AQL issues, the result-set needs perhaps an extra name column. can the AQL return named columns in result-set (as now is just an array).

  • think about adding views

Bugs

Headers

Missing (specification) details

Others

 

Priority tickets:

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

Related content