cds-hooks / sandbox

CDS Hooks Sandbox

This repository is unused by archived here for posterity.

Instead, please visit:

• http://cds-hooks.org/
• https://github.com/cds-hooks/docs (specification & website)
• https://github.com/cds-hooks/sandbox (Sandbox)

sandbox's Issues

How Acute/Repeat and Repeat-Reauthrization is mapped to MedicationRequest resource of CDS Hooks

I posted the same question on Julip and got the answer as below

It's new for R4. For R3, we'll be defining a standard extension for those who want to pre-adopt. You can find the R4 preview here: http://build.fhir.org/medicationrequest.html
The solution is courseTherapyType property which is introduced in R4 version.

However, I am bit confused about the repeat-authorization. I shared the information that Renewal and repeat-re authorization both are same.
Lloyd McKenzie** replied that

Not in course of therapy because they're separate things. A prescription might be accute or long-term. But "accute" doesn't mean it might not require renewals. So you could have original accute and long-term prescriptions and renewal accute and long-term prescriptions. courseOfTherapy deals with accute vs. longterm. Whether something is a renewal or not is determined by whether there's a pointer back to a prior prescription.

So I think for repeat-authorization, medication request prescription should be repeated ?

Can you please share your views on this.

Prefetch results may be dropped due to race condition

When there are multiple prefetches (pfA, pfB, pfC), sometimes the service is invoked with only a subset of their results even if they are all valid. This is because the logic resolves the entire sequence as soon as the last prefetch (pfC) is retrieved, even if other prefetches (pfA, pfB) are still in flight. This bug can be demonstrated easily on the public sandbox with any service that has multiple prefetches (especially if there are many and/or the last prefetch is simpler than previous prefetches).

I've submitted pull request #53 to address this issue.

Implement support for `order-select` from "Radiology Orders" tab

When changes are made to a code or reasonCode, fire off an order-select hook and display returned cards.

JWT does not contain all fields in 1.0 spec

The JWT that is sent on every CDS Service invocation does not have the sub field in the JWT body, or the jku field in the JWT header. We need to update to include these fields so the Sandbox can remain compliant with the 1.0 spec in regards to services trusting EHRs.

Ability to switch user/practitioner and patient from the UI

Hi, we are using the CDS sandbox in a workflow which involves validation by switching between user/practitioner and patients. It will be quite handy to be able to do these switching from the UI itself. What I am thinking of is displaying a list of users somewhere in the main view(header?) fetched from /Practitioner endpoint and also be able to select a Patient from a list of available patients(/Patient endpoint) in the patient entry page. I am keen to know if there was any such enhancement request before or if someone is already working on it. Is this something you are keen to add to the sandbox if I raise a PR with the changes?

Prefetch data is being sent as a Bundle.entry

The prefetch data from the Sandbox is being sent as FHIR Bundle.entry objects. However, back at the New Orleans WGM meeting (Jan 2018), we decided to forego this and just send the resource itself (see cds-hooks/docs#176).

Remove user and patient from request

In the following PRs to the spec, user and patient were migrated from the request to individual hook contexts. This update should be made to the sandbox, as well.

cds-hooks/docs#425
cds-hooks/docs#153

Add a "Radiology Orders" tab

The tab should include a note at the top like:

This tab is provided as a convenience to simplify connectathon testing of the CDS Hooks for PAMA guide from Argonaut. Eventually the functionality from this tab will be incorporated into the general purpose "Ordering" tab, since it exercise the same order-select and order-sign hooks at that tab.

Update JWT algorithm to match spec recommendation

In the JWT provided to CDS Services, the ES256 algorithm is used. Since the 1.0 spec recommends ES384 (or RS384), the sandbox should be uplifted to match this recommendation.

Validate CDS card data

There is no validation of CDS cards today. For instance, cards can have summary fields with > 140 characters and the card is still rendered. We should flag these cards for errors and/or not render them so that the CDS Service developer knows there is an issue that needs to be corrected.

Pass smart_messaging_origin to SMART apps at launch time

When launching a SMART app, ensure that the a smart_messaging_origin is configured as part of the launch process. In practice, this means injecting this parameter into the launch when the CDS Hook sandbox configures it at

sandbox/src/retrieve-data-helpers/launch-context-retrieval.js

Line 11 in ae63679

const launchParameters = {

. The HSPC sandbox _services/smart/Launch API should allow an arbitrary dict of parameters here, but this needs to be verified. (Perhaps @nschwertner can confirm?)

fhirAuthorization.expires_in is required field

When launching sandbox app through HSPC, fhirAuthorization populates fine but missing expires_in field.

"fhirAuthorization": {
    "access_token": "ey..",
    "token_type": "Bearer",
    "scope": "patient/*.* user/*.* launch openid profile online_access",
    "subject": "48163c5e-88b5-4cb3-92d3-23b800caa927"
  },

The sandbox code sets the expires_in based on the expires_in smart launch token response but looks like HSPC is not sending expires_in value when launching sandbox as SOF app. Not sure if this is the right place to post this given this is related to HSPC sandbox. But also wondering if the sandbox code should catch this

Clicking the same hook tab you are on clears the CDS Service request/response in the CDS Developer Panel

To reproduce:

1. Go to http://sandbox.cds-hooks.org/
2. Wait for the Patient Greeting service to return a card, noting the request and response are displayed in the CDS Developer Panel
3. Click on the Patient View tab
4. Note that the request and response now say "No request made to CDS Service" and "No response made to CDS Service", respectively.

I would expect either:

• (Preferred) Upon clicking the Patient View tab, the patient-view CDS Services are invoked, just as if you visited the page for the first time or refreshed the page.
  OR
• No patient-view CDS Services are invoked but the previous invocations request and response were still visible in the panel

Add sub field to JWT payload

Originally, I proposed leaving off the sub field in the JWT payload. We should go ahead and add in the sub field for now.

See also https://chat.fhir.org/#narrow/stream/17-cds-hooks/subject/sandbox

Sandbox does not save configuration

Once I configure a service, if I refresh the page the sandbox forgets about the configuration.

Prepare a short list of reason codes for connectathon testing

Prepare a valueset with the display names and codes for each of the reason codes mentioned in https://github.com/argonautproject/cds-hooks-for-pama/blob/master/connectathon-scenarios-2019-09/overview.md .

Commit the result as a FHIR ValueSet resource in a fixtures directory of this repo.

HSPC Cds hook FHIR server is not open any more?

Hi, I am trying to run the sandbox in my local machine and its failing because the default FHIR endpoint (https://api.hspconsortium.org/cdshooksdstu2/open/) is not open anymore. Is there anyway I can get it working in my local again?

cds-hooks specification & examples mismatch

Hello,

I am doing some proof of concept on cds-hooks. Here is what i found some issues.

1. As per API specification (http://editor.swagger.io/?url=https://raw.githubusercontent.com/cds-hooks/docs/master/docs/specification/1.0-api.yaml ), to invoke a cds-service the “context” should be passed as array of objects but as per examples “context” is just an object. You can refer the examples here https://cds-hooks.org/specification/1.0/
2. As per API specification “patient” and “encounter” defined outside the “context” but in examples “patient” and “encounter” is defined inside “context” object. Also the names have been changed to “patientId” and “encounterId” in examples.

Similarly there are lots of other discrepancies which I don’t want to put else it will be a long mail. There are also discrepancies with respect to HL7 standard https://www.hl7.org/FHIR/medicationrequest.html

Is the specification outdated or the examples outdated ?

Update context.user to context.userId

patient-view and medication-prescribe (as well as newer hooks) include "userId" as a context field. However, the current sandbox functionality sends this data as "user" and should be updated.

Missing fhirAuthorization property in service requests

The 1.0 spec defines an optional fhirAuthorization field that can be included in service requests that pass along the access token, scopes, and other relevant information so services can query the EHR's FHIR server for more data. This would normally be included only if the Sandbox is launched securely and is configured with a secured FHIR endpoint. Currently, the Sandbox does not send this property, but it is important to do so for services that need it.

Add a "default-services-readme.md" file

1. Describe each service enabled by default, in a default-services-readme.md .

2. For each, explain what the purpose of the service is / what it does -- and how a user can interact with the sandbox to select a tab, enter data, etc, that will trigger this specific hook. In other words, tell the story that will help a developer see/try the hook.

3. Link to this from a top-level "help" or "?" icon inside the sandbox -- maybe under "Reset Configuration" add "About default services"

Allow Sandbox to pre-configure properties from URL params

It would be nice if the Sandbox can have as many settings pre-configured as possible with values from URL parameters. This way, users won't have to enter in the same medication or CDS service every time, and can just use a URL with these values to pre-populate the Sandbox accordingly.

Currently, the Sandbox handles pre-configuration for the FHIR server (via the fhirServiceUrl param), and the patient in context (via the patientId param). These values are handled automatically by the fhir-client library the Sandbox pulls in. The Sandbox could also pre-configure discovery service URL's, the hook (view), and medication details (ID, dosage, dates, etc.).

example: https://sandbox.cds-hooks.org?hook=medication-prescribe&medication=731370&patientId=123

Process `.extension.systemActions` returned from CDS Services in "Radiology Orders" tab

When a CDS Service responds with .extension.systemActions PAMA response, update the draft order by applying the relevant PAMA extensions (which will, in turn, update the UX through the PAMA badge defined in #86)

Support scratchpad.delete, scratchpad.create from SMART Web Messaging

After #91, add support for operations that add/remove items from the draft orders scratchpad. When a scratchpad.delete or scratchpad.create message arrives from an app launched from the "Radiology Orders" tab, the in-progress draft orders should be updated appropriately.

Medications field in the context of a request needs to be updated

The medications field in the context property of the CDS Service request (for medication-prescribe) is currently structured with an array of MedicationOrder or MedicationRequest resources. This needs to be updated to be a single FHIR bundle with each medication resource in the entry array under a resource object.

Build order entry form for imaging

After #82, #83, #84 add to the tab a form for entering orders. Supports at a minimum:

• choice of imaging procedures with a dropdown or typeahead list that includes codes and display names for all CPT codes in #83
• choice of reason codes with a dropdown or typeahead list that includes codes and display names for all CPT codes in #84

Add support for R4 resources

The current sandbox supports dstu2 and stu3, but should be uplifted to also interact with R4 FHIR servers and be able to send R4 resources as hook context.

Also TODO: update default FHIR server to be the HSPC r4 server.

Add a "PAMA Appropriateness" badge to the radiology order entry screen

A draft order should have a built-in "PAMA Score" badge that initially renders with a ? inside, and then updates to a ✓ Appropriate, ✗ Not Appropriate, or — No Applicable Criteria whenever a score is assigned (via ServiceRequest.extension[url=http://fhir.org/argonaut/pama-rating]).

HSPC registration carry over

Hey all,
I'm a developer on the HSPC Sandbox team. We just kicked off the ability to register and test cds-hooks in the HSPC Sandbox. These services are persisted in the backend and therefore are always available to the user. My question is whether it would be possible to pass those registered discovery endpoints to the cds-hooks sandbox when it is launched in a user's HSPC sandbox?
It seems that those endpoints are stored in LocalStorage under the "PERSISTED_cdsServices" variable. Is this correct?
One idea I have would be to have the ability to include a list of cdsServices in the app launch context which would be available at the token response. Then the cds hooks sandbox could add those services to the ui. The question would be, should these endpoints be added to the localStorage "PERSISTED_cdsServices" variable or a sessionStorage variable that doesn't persist beyond the app launch.

Enable secure SMART App launch (EHR launch flow) directly from sandbox

Currently, the sandbox doesn't support a SMART EHR Launch for apps, unless a user first creates an account with HSPC, creates a new sandbox, and launches the CDS sandbox from there. It's a lot of prerequisites that make local development more challenging.

We should do something like:

• Render smart app links as non-clickable when the CDS Hooks Sandbox cannot execute a standard SMART launch (to avoid developer confusion about the expected behavior of a smart link)

• Update CDS Hooks to allow a standalone launch against a source FHIR Server (e.g., add a "Sign into FHIR Server" button)

• Alternatively (better still) connect to the SMART Launcher (open endpoint) by default, and enable the launcher to generate launch contexts directly. This will enable a full SMART app launch flow without developers having to take an extra sign-in step to the Sandbox by default.

Support order-sign hook

When a draft order is considered "ready to sign" (i.e., when it has an indication and a reason code), fire the order-sign hook in addition to the order-select hook.

Create sharable links option for a pre-configured Sandbox

Once the work on #30 is done, the Sandbox could add an option on the settings dropdown to create a shareable URL that contains the configured data on the current user's Sandbox session. This shareable URL could be displayed on a modal of some kind. As a result, the URL could be shared among others to have a similarly pre-configured Sandbox, which would help with trying to replicate scenarios for testing, or demos.

Update Rx View to invoke order-select hook

Since the medication-prescribe hook is deprecated, update the Rx View tab to invoke the order-select hook.

Prefetch template does not follow 1.0 spec prefetch syntax

Currently, the Sandbox is parsing prefetch templates against incorrect syntax with {{Patient.id}} or {{User.id}}. The Sandbox should be parsing according to the spec, where it should replace {{context.patientId}} or {{context.user}} with the appropriate values.

feature request: reload configuration

It would be helpful to be able to reload the configuration from a registered service so that changes to the service definition can be picked up without having to de-register and then re-register the service.

Allow for inspection and editing of the JWT

We recently had a Zulip discussion around allowing a user to both inspect and edit a JWT.

Regarding inspecting a JWT, at a minimum it would be nice to show the raw JWT value face up for each request. It would be a delighter to show the contents of the JWT (a la https://jwt.io/).

Regarding editing a JWT, it would be nice it a user could modify the contents, allowing them to customize the values within as they see fit. Additionally, a user could modify the JWT to set values incorrectly so they an see how their CDS Service responds (or rejects) the request.

change to prefetch query format in default FHIR server?

Hello,

Our prototype cds-hooks service stopped working recently and I think I've tracked the problem down to the prefetch query. My queries are,

Condition?patient={{Patient.id}}&_sort=clinicalstatus&_sort:desc=onset

Patient/{{Patient.id}}

I'm thinking maybe the server no longer supports DSTU2 and I need to change these to the DSTU3 format, but I want make sure before I begin chasing that. Thanks.

Add support for non-med order types to be used with order-select

If the Rx View tab is switched to invoke order-select (#74), a logical next step would be the ability to invoke it using other order types. In the Argonaut space, a key order type to start with would be ServiceRequest for radiology orders.

Sandbox seems to have a hard-coded Practitioner

I always get Practitioner/COREPRACTITIONER1 no matter who I set as the Practitioner when launching from the HSPC sandbox.

Adding CDS Service working properly?

I go through the steps of adding a CDS Service - After which the UI says "Configured CDS Service(s) found at the endpoint".

I do not see the service under "Select a Service" drop down after that. I do see it when I go to Configure CDS services, however, even if I try to delete the others I can find no way to display the service I just added in the select a service drop down.

CDS response Card array does not have any field like "status"

Hi Team,

I would like to understand suggestion card response for CDS response object.
We definitely require status kind of field as defined by HL7 specification i.e. https://www.hl7.org/FHIR/valueset-guidance-response-status.html

This gives more information to the service user.

Is there any way we can tell the service user to call other hook if any response returned by the card is not appropriate. We are looking the solution for this kind of scenario in our business.

Support scratchpad.update operations within "Radiology Orders" tab

Write a handler to receive scratchpad.update operations for messages from launched SMART apps. When a scratchpad.update message arrives from an app launched from the "Radiology Orders" tab, the in-progress order should be updated to match.

Can we have a interaction between EHR UI and service provider

Hi,
I would like to understand is there any way to communicate between card UI and service builder.

Ask 1: Let's say : In sandbox medication-prescribe hook example (http://sandbox.cds-hooks.org/), If they click 'change to generic' button, I want some information (some custom information used in the card) to share it to service provider.
Is there any possibility to create any button click event (Change to Generic) or any custom hook that can be called through this event.

Ask 2: I want to keep a feedback text-box inside the Card UI, and send the info to service.

Please share any link if you have any example for this.

Support multiple orders on "Radiology Orders" tab

After we've covered the essentials... can go back and support entering multiple orders into the Scratchpad, rather than just one.

• Add an "Add Draft Order" button to the order entry form
• Add a list of draft orders below the order entry form
• Include a PAMA Appropriateness badge for each draft order
• Include a "X" (to delete) for each draft order
• Include all draft orders in the outbound orderSelect CDS Hook payload

feature request... A resubmit button

When testing against a local service, it would be helpful to be able to trigger re-requesting of cds-hooks from the registered services so I can iterate quickly on testing. Currently the only way to this is change the hook view to 'rx view' and back.

Running with HAPI FHIR

Quick question: how to I change the port for CDS Hooks so it can coexist with HAPI on 8080?

Prepare a "CPT for Advanced Diagnostic Imaging" valueset

Prepare a valueset with the display names and CPT codes for each of the imaging studies mentioned in https://www.cms.gov/Outreach-and-Education/Medicare-Learning-Network-MLN/MLNMattersArticles/Downloads/MM10481.pdf

Commit the result as a FHIR ValueSet resource in a fixtures directory of this repo.

Add Secure Option CDS Services

Problem

Need the ability to add zero or more request headers when configuring the cds-service discovery endpoint, so that when a cds hook is fired it can pass the request header to the secure service endpoint.

Example

Request:

{
  "headers": {
     "x-apikey": "1234"
  }
}

Proposal

In the add cds services modal,

add the ability to add zero or more header key and values when

Prefetch length limits

While testing a cds service at the connectathon I observed that very long prefetch definitions failed.

In my case I was launching the cds-hooks sandbox from an HSPC sandbox (using Chrome).

Support ui.done messages within "Radiology Orders" tab

Write a handler to receive ui.done operations for messages from launched SMART apps. When a ui.done message arrives from an app launched from the "Radiology Orders" tab, the launched app should be closed and focus returned to the "Radiology Orders" tab.