specifications-ITS-REST
specifications-ITS-REST copied to clipboard
openEHR REST API Specifications
I see an error that repeats by following the steps on the README for building the on the development folder. ```shell Generating HTML file... redocly build-docs [api] Produce API documentation...
We are focusing now (initial phase) mainly on `/ehr`, `/template` and `/query` but we will have to support eventually also Demographics. Any idea or preferences before building something in apiary?
Even though @wolandscat has pointed out that use of OBJECT_VERSION_IDs for COMPOSITION.uid values does not imply any versioning semantics as per the specifications, at least one vendor and probably more...
It should revert to the version just before deletion.
The error conditions 400 and 409 defined on upload template should presumably also exist on upload archetype.
Shouldn't be more RESTful to have a dimension per each method in VERSIONED_OBJECT? And leave GET /ehr/{ehrId}/versioned_ehr_status to return just uid, owner_id and time_created. GET /ehr/{ehrId}/versioned_ehr_status/revision_history GET /ehr/{ehrId}/versioned_ehr_status/all_versions GET /ehr/{ehrId}/versioned_ehr_status/latest_trunk_version...
### Request GET ./ehr/{ehr_id}/composition?start_time=ge20170218T0000Z&archetype_id=openEHR-EHR-COMPOSITION.report.v1&template_id=pathology_report ### Response Good question. Following the RM it would be SET. This wouldn't be very useful for an application so we need a Resultset structure of...
It would be helpful to have an EHR-URI-resolving endpoint/resource standardized and possible to include in some level of the conformance spec. Likely the same conformance level as AQL since if...
Some openEHR implementations (in addition to posting full "canonical" instances of RM objects) allow posting compact "diffs" that use an existing version of an object (e.g. a COMPOSITION) as a...
Either as a part of the main REST spec or as an appendix we might want to have a look at specifying management and execution fo CDS rules via REST....