Design and define API REST interface for the FOSPS connectors.

[gmej]

All FOSPS connectors will be exposed through a single HTTP REST API interface. This task consists of creating an OpenAPI file, and uploading it to FOSPS swagger to be validated by everyone.

Connectors have two operation modes: push and pull.

• Push refersh to the connector, on its own, reading from a source and writing changes or new resources to the FOSPS platform. This can be scheduled periodically, or it can be invoked manually. This operation mode MUST generate provenance if the source didn't contain it.
• Pull refers to the connector reading resources only on demand, e.g, when a user request a specific resource, it will return that resource.

IMPORTANT: All these FHIR resources returned by this API must contain provenance. A resource will be returned with its correspondant provenance:

• ePI
• IPS
• Lens
• RMM metadata

This interface can be under a path like /connector/api/

These operations will be available in this API:

1. A FHIR resource can be queried through the connector via FHIR queries. A FHIR query is sent to the connector, and it will look in the correct place to look for the requested resource. This will loop (or not) through all the connectors.
2. A FHIR resource can be queried through its identifier. It wil loop over all the connectors, and the one containing the resource will return it.
3. The connectors can be manually triggered to completely update from all the sources on demand. This will be invoked through a HTTP endpoint too.

[gmej]

I have drafted the first version of the FHIR connector interface. You can find it in the swagger deployment in dev: https://gravitate-health.lst.tfo.upm.es/swagger-fosps/?urls.primaryName=FHIR%20Connector

I need feedback with this interface definition before implementing the connector as a proxy for other FHIR servers.

ping @amedranogil @joofio

[amedranogil]

I see no issue with this definition, other than connectors should offer access to any FHIR type, so maybe we should enable a "type free" search and retrieval for future-proofing?

[gmej]

OK, I'll make it available for any resource type.

[gmej]

@jkiddo @joofio How can we achieve this? Is there a possibility to search at system level? I think it's not implemented yet in HAPI FHIR https://hapifhir.io/hapi-fhir/docs/server_plain/rest_operations.html#system_search

[jkiddo]

I dont fully understand what you are trying to achieve

[gmej]

So the thing is we are implementing the "proxy mode" for the connector. It will look on all the sources to find the resource you are trying to query (being hosted in FOSPS or other FHIR sources outside). What I am trying to do is enabling an endpoint with a "generic" HAPI FHIR search, i.e. looking for any kind of resource matching the query

[jkiddo]

You can do 'generic' searches using transactions, e.g.:

{
    "resourceType": "Bundle",
    "type": "transaction",
    "entry": [

        {
            "request": {
                "method": "GET",
                "url": "Patient?_elements=id"
            }
        },
        {
            "request": {
                "method": "GET",
                "url": "Composition?type=document"
            }
        }
    ]
}

[jkiddo]

you post it to the root of the endpoint, e.g. https://gravitate-health.lst.tfo.upm.es/epi/api/fhir

[gmej]

That's exactly what we needed to know, thanks!

[gmej]

This is a "FHIR transaction" right? Like its documented in the example HAPI FHIR server? https://hapi.fhir.org/baseR4/swagger-ui/#/System%20Level%20Operations/post_

[jkiddo]

Its a regular FHIR transaction, yes

[jkiddo]

You can find the documentation here https://www.hl7.org/fhir/http.html#transaction

[gmej]

I've updated it for this generic FHIR transaction, I'll implement this, and the connector will execute the search in different FHIR servers and respond with all results.

[gmej]

I have implemented a "proxy" for this Generic search (FHIR transaction). The endpoint is /connector/api/. The schema is in the documentation Jens sent. The service accepts a list of FHIR Urls to execute the search transaction. Now we have configured both FHIR servers in FOSPS (ePI and IPS), but external FHIR servers can be connected.

Here is an example of this service. Search for a Patient which name is like alicia, and a Bundle with id = bundlepackageleaflet-en-f3d8b9999dbf0bb7ed96cabee591db10:

curl --location 'https://gravitate-health.lst.tfo.upm.es/connector/api/' \
--header 'Content-Type: application/json' \
--data '{
  "resourceType": "Bundle",
  "type": "transaction",
  "entry": [
    {
      "request": {
        "method": "GET",
        "url": "Patient?name=alicia"
      }
    },
    {
      "request": {
        "method": "GET",
        "url": "Bundle?_id=bundlepackageleaflet-en-f3d8b9999dbf0bb7ed96cabee591db10"
      }
    }
  ]
}'

The response are now 4 entries: one entry per request-server pair. In this case: 2 servers * 2 requests = 4 entries.