sdhealthconnect/leap-cds

LEAP Consent Decision Service

leap-cds's Issues

Support Content Class

Content Class is part of the consent resource provision which enables a consent directive to limit the type of medical information that can be released under the provisions of the consent.
This should be implemented as obligations similar to security labels.

JSON Schema for Response

This will help statically-typed languages like Java to be able to create models automatically.

Accommodate `scope` being recorded in `category` according to the most recent changes in FHIR Consent specs.

Recent changes to the FHIR Consent specs removes scope and expects the scope to be recorded in the category array. The LEAP-CDS must accommodate both models in order to ensure the old and new demos work seamlessly.

SPIKE - CDS Cloud Deployment Strategy

• Create white paper describing our release environment
• Present to development and management teams.

Audit Service

The CDS should generate AuditEvents at the respective Consent store when a consent is used to grant or deny access.

Support multiple actor IDs in the hook request

The client must be able to list more than one identifier for the actor in the context of the hook, to accommodate for cases where different actor identifiers may be used on the FHIR server side.

The strategy at the Consent Decision Service is to interpret this as matching "any of" the identifiers. For example if an organization has two different types of identifiers, the client should be able to list both in the hook context and the Consent Decision Service should match based on any of the provided identifiers.

This also requires a change in the schema of the hook context to identify the actor with an array of identifiers, rather than a single one.

Add tests for Consent with Practitioner

Make `scope` optional

Since the CBCP WG has voted to phased out the scope parameter, we will make this an optional parameter in the LEAP-CDS request and ignore it in searching to fetch patient consents from consent stores.

Support for content type specification in the CDS query

Revise the Provision Processing Logic

After carefully examining the provisions semantics for the blog post and the proposed change request, there are some minor issues in the current provision logic that must be fixed to properly process the hierarchical provision structure.

Support basic Actor matching in consent decision processing.

The consent decision processing must consider the actor attribute from the context of the request, which in the exchange use-case represents the recipient of the exchange, and take it into consideration in the consent decision.

Simple JWT-based Auth

The Consent Decision Service needs some authorization service. We will stick to a simple non-OAuth JWT-based access token for simplicity.

Process consent expiry date

Parse and consume the validity period of a consent and take them into account in the consent decision.

XACML REST/JSON Endpoint

Since we are already returning an XACML response as an extension in the CDS hooks response, it may make sense to have a direct XACML endpoint for querying Consent. Since the code to generate the response is already written, this only requires adding the code to validate and parse a request.

Test server setup script

A script to upload all the required test resources (Patient, Organization, Consent) to a given FHIR server to populate the server with data required for test and demonstration.

These resources currently reside in https://github.com/sdhealthconnect/leap-cds/tree/master/test/fixtures and are used for unit and integration tests.

The best way to implement this script is to use cURL to submit all the resources in the form of a single bundle and use a transaction POST to upload all the data at once.

Expose Consent Discovery as a service

The consent discovery module which is in charge of finding and retrieving all applicable consents to a query context is currently not accessible to outside clients. However, there is value in exposing this service as a "consent directory" service to enable clients that are capable of processing consent on their own, or are interested in consent discovery for other reasons, to use LEAP CDS to find and retrieve patient consents.

Independent consent fixtures

Currently there is a base consent fixture and it's being edited and manipulated in the code for different test cases. It's better to have many fixtures instead so that the code for these tests get simpler and also we will have full resources that can be posted to an actual live server for live testing the same functionalities.

Support for security labels

• The CDS must consume and process security labels in Consent provisions.
• The request context must enable a resource attribute where labels of the resources in question can be specified.

Error when POU is ETREAT

This may be a leap-ces-java-client library issue ...
REQUEST

{
  "hook": "patient-consent-consult",
  "hookInstance": "privacy-consent-scenario-H-UI",
  "context": {
    "patientId": [{
      "system": "http://hl7.org/fhir/sid/us-ssn",
      "value": "111111199"
    }],
    "scope": "adr",
    "purposeOfUse": "ETREAT",
    "actor": [
      {
        "system": "urn:ietf:rfc:3986",
        "value": "urn:oid:1.1.8"
      }
    ]
  }
}

RESPONSE:

CDSHooks Request FailedCannot construct instance of `gov.hhs.onc.leap.ces.common.clients.model.card.Context$PurposeOfUse`, problem: ETREAT
 at [Source: (String)"{"hook":"patient-consent-consult","hookInstance":"privacy-consent-scenario-H-UI","context":{"patientId":[{"system":"http://hl7.org/fhir/sid/us-ssn","value":"111111199"}],"scope":"adr","purposeOfUse":"ETREAT","actor":[{"system":"urn:ietf:rfc:3986","value":"urn:oid:1.1.8"}]}}"; line: 1, column: 200] (through reference chain: gov.hhs.onc.leap.ces.common.clients.model.card.PatientConsentConsultHookRequest["context"]->gov.hhs.onc.leap.ces.common.clients.model.card.Context["purposeOfUse"])
Response headers

Content Type in the request

The client must be able to specify a content type in the request to narrow down the type of data that's being accessed.

move out documentation artifacts to its own repo

it makes more sense for the documentation to be hosted in its own repository since it will cover components and demo artifacts beyond the LEAP CDS repository.

Document auto-deploy setup

The auto-deploy setup needs to be documented briefly so that the process is repeatable.

Set up Swagger/OpenAPI

Support a `lang` parameter

Client must be able to request that any human-readable portion of the the LEAP-CDS response to be in either Spanish or English.

Take into account Consent Scope in Consent Discovery

Consent Discovery should be able to specify a Consent Scope and narrow down the search to a specific consent scope.

Set up CD for the LEAP-Consent Decision Service

• Set up continuous deployment for the LEAP-Consent Decision Service to google cloud platform.
• Add the deployment endpoint address to the documentation.

Resolve Docker Restart Removing Deployed Extensions

When using docker-compose up/down the original image is restored and any extension loaded via mirth administration is lost.

• modify docker configuration to copy these jars/src files to their respective folders in ./extensions on docker restart.

Nested provisions must be processed as arrays

The Consent specs define nested provisions with 0..* multiplicity so even though the examples use simple elements, these can be arrays. Currently the service assumes a single element which should be fixed.

• A quick fix is to look at only the first element of the array for now and deploy so the demo can proceed.
• A final fix should consider all the provisions and combine the decisions. This is quite unclear since the decisions could be contradictory. But assuming consistency, we have to accumulate the obligations from each provision if the final decision is permit.

switch from request to superagent

request has been deprecated, so it's best if we move away from this dependency.
https://medium.com/better-programming/request-has-been-deprecated-a76415b4910b

Enumeration on XACML decision in the schema

Documentation and Github Pages setup

We need to set up a documentation folder to start recording thoughts and design decisions as well as feedback to the FHIR community. This can be set up in a way that can host a github pages website.
This is also a preamble to opening up the repo to public and promoting the project.

Consent Discovery

The Consent Decision Service must be able to discover and fetch a given patient's consent(s) from a fixed list of FHIR consent servers.

Basic Consent Query Processor

The Consent Decision Service must be able to verify the basic attributes defined in the context of the consent hook and return a consent decision accordingly.

Mock CDS interface

Provide a rapidly developed interface for the Consent Decision Service based on the Clinical Decision Support Service Hooks to enable test. This mock service needs to provide the query/response interface without actually relying on a decision backed by processing a consent and enables rapid integration with the rest of the architecture while consent processing is being incrementally added.

• Determine the minimal attributes required for a consent decision query
• Minimal interface based on CDS Hooks
• Minimal hook definition.
• Request/Response test coverage.

SPIKE - CDS Continuous Integration & Deployment Strategy

• Create white paper on our CI/CD process.
• Present to dev and management teams.

meaningful error handling when patient or organization references do not resolve

Currently, the CDS returns a 404 response which is not helpful.

• log the invalid consent
• ignore it in the process

Support Asynchronous Response

Responding to a CDS query requires finding the patient and then looking for the associated consents in every FHIR server attached to the CDS. Depending on the number of FHIR servers, this can increasingly involve a larger number of HTTP requests and therefore is not synchronously scalable and when the number of associated FHIR servers is large, requests may time out because they will have to wait for a large number of backend calls.
This can also cause issues if the backend FHIR servers are rate-limited, since a bust of traffic on the CDS can cause hitting rate-limits for these backend services.
To resolve this, the CDS needs to support asynchronous response to the client and instead of making backend http calls synchronously, these calls should be queued.

Error while logging into Consent UI

Add CDS Hook discovery endpoint

The client must be able to discover the CDS hook on this server and its specifications via the service discovery endpoint as defined by the CDS Hooks specs.

SPIKE - CDS Testing Approach

• Create white paper on overall testing approach
• Present to development and management team

Set up CI for LEAP-Consent Decision Service

Set up continuous integration (automatic tests/linting checks) using github actions.

Basic support for purpose of use

The consent decision processing must take into consideration the purposeOfUse attribute and consider it in processing the consent and making a consent decision.

SLS/PPS Micro-services

• Refactor sls/pps to utilize latest version of spring
• Unit testing and coverage

Deploy HAPI FHIR JPAServer - GCP

• Create configuration with HAPI FHIR JPAServer Starter project
• Implement FHIR R4
• Configure to utilize GCP hosted MySQL Server 5.7.x

Switch to using HL7 FHIR obligation and refrain codes instead of custom obligation ids.

FHIR handling instruction valueset could potentially be leveraged for obligation IDs in the response from the API.

HL7v2 Messaging Test Environement

• Import Mirth Channel or Channel Group Definitions
• Document the environment specification (docker-compose yaml?).
• Deploy Mirth-Connect Docker Image to Google Cloud

Support looking up patient based on multiple identifiers

Currently the patient is identified in the request by a single identifier. This assumes that the same identifier is used in all FHIR servers where patient consents are hosted. This assumption may not hold if the patient is recorded with a different identifier type at different consent servers.
The expected behaviour in this case for the CDS is to read an array of identifiers from the request context and take into account consent from patients matching any of the identifiers listed in that array.