Endpoint Registry Example

The following examples show an instance of the Endpoint Registry domain - an Organization that uses an Endpoint that implements an API Specification. The instance exemplifies a healthcare provider that uses an endpoint conforming to two example API specifications: Vaccines and Restriction register.

Healthcare provider (Organization)

This example of Organization shows an organization with an organization identifier as seen in the identifier element with system "urn:oid:2.5.4.97". It has a reference to the logical ID of the Endpoint it uses (see Endpoint section below) in the endpoint element.

Endpoint

This example of Endpoint shows an endpoint in active status that can be reached at the address "https://journalis.api.regiontornaland.se/fhir". It is a FHIR based endpoint as seen in the connectionType element.

API (Device)

This example of Endpoint describes a FHIR API located in a fictive Swedish regions EHR system.

The two extensions in the element conformsTo shows that the API conforms to API specifications for vaccinations and restriction-register. The extensions has the url "http://electronichealth.se/fhir/NDI/StructureDefinition/endpoint-payload-api-specification-er" that points to an ActorDefinition (see section ActorDefinition below), using the ActorDefinition's canonical URL. The two API specifications are both FHIR, as seen in the conformsTo.specification element.

The API uses Oauth as security method and the URL for the authorization server is https://auth.journalis.api as seen in the two first properties. The third property defines that the API is configured with a template endpoint url where the parameter "orgid" changes depending on which organization is using it to share their data.

The API references to the logical ID:s of it's Endpoints in the endpoint element. In this case it references the endpoint instance in the example above, with id c933bcd8-ae65-41ce-ae6f-82477c770333

API Specifications (ActorDefinition)

Example 1

This example of an API Specification shows meta data about a fictive API specification that is referenced in the Device example above. An ActorDefinition that defines a system rather than a person has to have the type element set to "system".

The API specification has the human readable name "API-specifikation Vaccinationer utbildningsmiljö" as seen in the title element, as well as a machine readable name "ExempelVaccinationer" as seen in the name element.

This specific instance is for version 1 of the specification. The url element is the canonical URL of the ActorDefinition and is the identifier that should be used to reference it, as done in the Endpoint example above.

The useContext element has the code "topic" which declares that the valueCoding defines a high level category that the ActorDefinition is a part of, in this example the category "utb".

The actual API specification can be found at the URL provided in the reference element, i.e. "https://example.com/fhir/exempel-specifikation-vaccinationer" in this example.

Example 2

This example of an API Specification shows meta data about another API specification that is referenced to in the Endpoint.payload example above.

The API specification has the human readable name "Spärregister" as seen in the title element, as well as a machine readable name "restriction-register" as seen in the name element. The publisher element declares that the API specification is published by NDI. This specific instance is for version 1 of the specification.

The useContext element has the code "topic" which declares that the valueCoding defines a high level category that the API specification is a part of, in this example the category "ndi-specifications".

The actual API specification can be found at the URL provided in the reference element, i.e. "https://simplifier.net/guide/swedishproxypermissionanddatarestrictionservice?version=current" in this example.