Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

availability of data and safety #506

Closed
wants to merge 3 commits into from
Closed

availability of data and safety #506

Changes from 1 commit
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
2604ade
availability of data and safety
isaacvetter Oct 9, 2019
e34f699
availability of FHIR resources from ids in context
isaacvetter Oct 15, 2019
ae0e88e
safety paragraph - stale clinical data
isaacvetter Oct 15, 2019
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
6 changes: 5 additions & 1 deletion docs/hooks/patient-view.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -12,14 +12,18 @@ The user has just opened a patient's record.

## Context

The patient whose record was opened, including their encounter, if applicable.
The patient whose record was opened, including their encounter, if applicable.

The FHIR ids referenced in `context` are expected to be available via the FHIR Server (if `fhirServer` is populated in the request) or via prefetch, if supported. However, the specification does not explicitly require this behavior and implementations should be aware that integrations may not fully support this expectation.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggest:
If the CDS-Client supports pretech and/or provides a FHIR Server, the CDS-Client SHOULD provide FHIR Resources referenced by FHIR ids in context. As this behavior is optional, CDS-Server implementers need to be aware that not all CDS-Clients will support this behavior.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it appropriate to add a statement to the base spec about the nature of context? e.g. if ids are provided, they must be resolvable through some mechanism available to the CDS Service. The point being that if an id is present, in order to be useful, the CDS Service must be able to call the FHIR server to retrieve it, or to have that same data prefetched by the CDS Client.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hey Bas, does the rewrite address your concerns? I modified your suggestion for readability and consistency in terminology.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

First, a few relevant sections of the spec:

  • On CDS Hooks Anatomy, a hook is

    A defined point within the client system's workflow with well-known contextual information provided as part of the request

  • On the HTTP Request to a CDS Service, context is

    Hook-specific contextual data that the CDS service will need.

  • On Providing FHIR Resources to a CDS Service

    Each CDS Service will require specific FHIR resources in order to compute the recommendations the CDS Client requests...this specification defines a process to allow a CDS Service to request and obtain FHIR resources efficiently. Two optional methods are provided....Each CDS Client SHOULD decide which approach, or combination, is preferred.

  • On Prefetch Template

    If the CDS Service is unable to obtain required data because it cannot access the FHIR server and the request did not contain the necessary prefetch keys, the service SHALL respond with an HTTP 412 Precondition Failed status code.

In summary, the spec emphasizes that:

  1. A CDS Client's purpose in invoking a hook is to communicate well-known and needed information to the CDS Service
  2. CDS Clients SHOULD decide whether to support exposing their FHIR server or implementing prefetch or both.
  3. CDS Services SHALL return a 412 if they do not get the information that they need from either the FHIR Server or prefetch (as opposed to returning something unsafe like an empty array of cards).

It isn't the responsibility of a hook definition to warn CDS Services about CDS Clients that choose to limit decision support by preventing access to needed data (or otherwise). Such CDS Clients will not gain adoption and I don't think statements on a hook definition to address their unusable nature add much value.

If we want to add clarifications to a future version of the spec to comment on the nature of FHIR references in a given context, that or other similar updates may be helpful. In the meantime, I don't think the 1.0 specification precludes the ability to publish the existing patient-view definition (prior to these amendments).

@bvdh, thoughts?


Field | Optionality | Prefetch Token | Type | Description
----- | -------- | ---- | ---- | ----
`userId` | REQUIRED | Yes | *string* | The id of the current user.<br />For example, if the user represents a FHIR resource on the given FHIR server, the resource type would be one of [Practitioner](https://www.hl7.org/fhir/practitioner.html), [Patient](https://www.hl7.org/fhir/patient.html), or [RelatedPerson](https://www.hl7.org/fhir/relatedperson.html).<br />If the user was a Practitioner, this value would be `Practitioner/123`
`patientId` | REQUIRED | Yes | *string* | The FHIR `Patient.id` of the current patient in context
`encounterId` | OPTIONAL | Yes | *string* | The FHIR `Encounter.id` of the current encounter in context

For information on patient safety issues see [Security & Safety](../../specification/1.0/#security-and-safety).
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggest:
The patient-view hook only allows advice that is based on information provided using prefetch and/or the FHIR-server. As is stated in [Security & Safety], implementers should be aware that using the patient-view hook might result in a decision based on outdated patient data, resulting in a safety risk to the patient. E.g. because the data the advice has been based on has been altered in the current user-session.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does this addition provide any information that is not already available in the base spec?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Dennis - that's a good question. Bas, how much of the base spec should we be repeating here?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Adding comments about outdated/stale clinical data and a link to the Security and Safety page is redundant since the 1.0 specification already calls this out

Security and safety risks associated with the CDS Hooks API include:
...
6. The risk that a CDS Service could return a decision based on outdated patient data, resulting in a safety risk to the patient.

@bvdh, are you agreeable to removing this language from the hook since it's already covered by the published base spec?


### Examples

```json
Expand Down