Build a preFetch Proxy

[jmandel]

An open question is how app developers should deal with uncertainty about the availability of preFetch data. If an app developer has to code defensively and write two code paths (one for the case where preFetch data are supplied by the EHR, and one of the case where they aren't), this leads to duplicated effort and mistakes.

This task: build a generic proxy (e.g. deployable via Docker) that takes the URL of an underlying service, and exposes a gateway in front of it. The service exposes two API call:

POST /:actualServiceUrl/$cds-hook
POST /:actualServiceUrl/$cds-hook-metadata

• When a cds-hook-metadata call arrives, simply proxy the the metadata from the actual service.
• When a cds-hook call arrives, use the actual service's metadata to determine which preFetch data are expected. Then examine the payload to determine if the data have been supplied to the EHR. If so, just pass the request to the actual service. Otherwise, call the EHR directly, issuing the necessary queries to assemble the required preFetchData. Then, after assembling the necessary payload, pass the updated request to the actual service.

Deployment details

• Deployable via Docker
• Demo deployment at https://prefetch-proxy.cds-hooks.org

[mattberther]

I can take this. It'll be a week or so before I have something back though.

[jmandel]

OK, that'd be totally awesome @mattberther! Of course the syntax above is for the old API; the updated set of calls to expose would be:

GET  /:actualServiceUrl/cds-services
POST /:actualServiceUrl/cds-services/:serviceId
POST /:actualServiceUrl/cds-services/:serviceId/analytics/:uuid

[mattberther]

The first call would actually be

GET /:actualServiceUrl/.well-known/cds-services

Right?

[jmandel]

You caught us mid-edit: we're updating the spec to drop .well-known/ from the discovery path :p

[mattberther]

@jmandel @kpshek - take a peek at https://github.com/cds-hooks/cds-prefetch-proxy and let me know if this is what you had in mind.

[jmandel]

This looks like exactly what I had in mind, quite! Thanks so much for putting this together. Three tiny notes:

• https://github.com/cds-hooks/cds-prefetch-proxy/blob/a01463f4bc7e56bf7dd13c22ea36ecbd68c55c7f/test/fixtures/service-request.json#L3 should not include a trailing slash in the FHIR base URL (and, as a consequence, there are a couple of places like https://github.com/cds-hooks/cds-prefetch-proxy/blob/c40f5c7e7f54aade5eb4fd68338ed2b52a306936/lib/routes.js#L55 where a slash may need to be interposed (or better, use urljoin).
• Labels for https://github.com/cds-hooks/cds-prefetch-proxy/blob/c40f5c7e7f54aade5eb4fd68338ed2b52a306936/test/integration-test.js#L129 and https://github.com/cds-hooks/cds-prefetch-proxy/blob/c40f5c7e7f54aade5eb4fd68338ed2b52a306936/test/integration-test.js#L140 appear to be reversed
• Overall for consistency across repos @kpshek and I were talking about trying to standardize on Travis CI -- do you have an allergic reaction to this idea?

[mattberther]

Thanks for the feedback. Ill go through and update to use url-join for consistency.

I dont believe labels are swapped. https://github.com/cds-hooks/cds-prefetch-proxy/blob/c40f5c7e7f54aade5eb4fd68338ed2b52a306936/test/integration-test.js#L140 should query the FHIR server and it does so by removing the prefetch key prior to submitting the request to the proxy. The absence of the prefetch key (and the presence of it on the service discovery) leads the proxy to query the FHIR server for the resource(s).

No concern at all about using Travis CI. My apologies - I didnt see that you all were already using it.

[jmandel]

Hmm, maybe I'm just having trouble parsing the description in your labels -- your explanation here makes perfect sense sense, but I can't see how it corresponds to

should query the fhir server if prefetch data is sent with the service request

I'd expect "query the FHIR server's if any prefech data is missing from the service request"

Re: Travis, you didn't miss anything here; it's just the tool that @kpshek and I have use in other (non CDS Hooks) projects :)

[mattberther]

Re: labels, indeed youre right. That's what happens when I respond late. Sorry.

Re: Travis, if you want to authorize Travis to the organization, Ill get the builds moved over.

[jmandel]

I've taken two steps:

1. Enabled Travis on the organization + directly enabled the testable repositories. See https://travis-ci.org/profile/cds-hooks
2. Added @mattberther as an admin user to the organization (so you should be able to fix config directly if needed)

[mattberther]

Thanks @jmandel - Ive updated all but two repos to build from travis. I havent done docker-stack or cds-service-example-csharp yet because im not sure how to do docker or csharp builds with travis. Ill continue to research.

[mattberther]

Also just pushed a couple commits which should address your original points (url concatenation and test verbiage).

cds-hooks/cds-prefetch-proxy@bf888ea

Ill close this issue out and we can track subsequent issues against the prefetch proxy on that repo.