# Smart on openEHR OpenAPI

**Category:** [ITS](https://discourse.openehr.org/c/its/41)
**Created:** 2024-01-25 15:05 UTC
**Views:** 429
**Replies:** 3
**URL:** https://discourse.openehr.org/t/smart-on-openehr-openapi/4857

---

## Post #1 by @joostholslag

> * `openapi`: A URL to the OpenAPI specification of the service
…

With example:
```
"openapi": "https://platform.example.com/openehr/rest/v1/openapi.json"
```
At:
https://specifications.openehr.org/releases/ITS-REST/latest/smart_app_launch.html#_services

Why doesn’t the OpenAPI always point to openEHR OpenAPI files at https://github.com/openEHR/specifications-ITS-REST/tree/master/computable/OAS
They shouldn’t be vendor/server specific right?

---

## Post #2 by @Sidharth_Ramesh

We've redirected it to the ITS-REST page for now (https://specifications.openehr.org/releases/ITS-REST/latest), but this could be a mistake. @sebastian.iancu what do you think? Should we change this link to what @joostholslag is suggesting?

![image|690x164](upload://a9B3jTaG9Q5X8oxJ03f3fkguAtY.png)

---

## Post #3 by @sebastian.iancu

I thought that the idea is that discovery is always real to a real life implementation inside the playform. So it is not about a generic (abstract) openapi spec but rather the exact one provided by the platform service. For sure, for conformance perspective this supposed to be 100% aligned with specification, but inreality they might not (for instance when at least that vendor is supporting more serializations formats, more endpoints, various flavours on headers , etc). 
Also you have to imagine that in time we will have more version of the spec published, but a vendor implementation always supports a spannor versions or functionality (perhaps does not support latest version).
As a consumer application I would like to see what exists on service side, not what suppose to exist.
 Does it make sense to you also?

---

## Post #4 by @thomas.beale

The text at that link has this:
> A response from the SMART Configuration endpoint should include besides the [FHIR metadata](https://www.hl7.org/fhir/smart-app-launch/conformance.html#metadata) also a hash of all available `services` on the *Platform*. The `services` section allows the application to discover the APIs of all services that can be used along with their description and documentation. The `services` section is represented as a hash, where the key is represented by a reverse domain name of the service (e.g. `org.openehr.rest`), and the value represents the service specification.

In the above the term 'hash' is used to what I assume is really a 'map' (could be implemented by a hash table). The term 'hash' on its own usually means cryptographic hash, e.g. SHA-256 or similar.

I suggest changing 'hash' to 'map' in this document.

---


**Canonical:** https://discourse.openehr.org/t/smart-on-openehr-openapi/4857
**Original content:** https://discourse.openehr.org/t/smart-on-openehr-openapi/4857