Use Cases
ClinicalDecisionSupport
Bases: BaseUseCase
Implements EHR backend simulator for Clinical Decision Support (CDS)
PARAMETER | DESCRIPTION |
---|---|
service_api
|
the function body to inject into the main service
TYPE:
|
service_config
|
the config kwargs for the uvicorn server passed into service
TYPE:
|
service
|
the service runner object
TYPE:
|
client
|
the client runner object
TYPE:
|
See https://cds-hooks.org/ for specification
Source code in healthchain/use_cases/cds.py
85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 |
|
cds_discovery()
CDS discovery endpoint for FastAPI app, should be mounted to /cds-services
Source code in healthchain/use_cases/cds.py
cds_service(id, request)
CDS service endpoint for FastAPI app, mounted to /cds-services/{id}
This method handles the execution of a specific CDS service. It validates the service configuration, checks the input parameters, executes the service function, and ensures the correct response type is returned.
PARAMETER | DESCRIPTION |
---|---|
id
|
The unique identifier of the CDS service to be executed.
TYPE:
|
request
|
The request object containing the input data for the CDS service.
TYPE:
|
RETURNS | DESCRIPTION |
---|---|
CDSResponse
|
The response object containing the cards generated by the CDS service.
TYPE:
|
RAISES | DESCRIPTION |
---|---|
AssertionError
|
If the service function is not properly configured. |
TypeError
|
If the input or output types do not match the expected types. |
Note
This method performs several checks to ensure the integrity of the service: 1. Verifies that the service API is configured. 2. Validates the signature of the service function. 3. Ensures the service function accepts a CDSRequest as its first argument. 4. Verifies that the service function returns a CDSResponse.
Source code in healthchain/use_cases/cds.py
ClinicalDecisionSupportStrategy
Bases: BaseStrategy
Handles the request construction and validation
Source code in healthchain/use_cases/cds.py
construct_request(data, workflow)
Constructs a HL7-compliant CDS request based on workflow.
PARAMETER | DESCRIPTION |
---|---|
data
|
FHIR data to be injected in request.
TYPE:
|
workflow
|
The CDS hook name, e.g. patient-view.
TYPE:
|
RETURNS | DESCRIPTION |
---|---|
CDSRequest
|
A Pydantic model that wraps a CDS request for REST
TYPE:
|
RAISES | DESCRIPTION |
---|---|
ValueError
|
If the workflow is invalid or the data does not validate properly. |
Source code in healthchain/use_cases/cds.py
CDSRequest
Bases: BaseModel
A model representing the data structure for a CDS service call, triggered by specific hooks within a healthcare application.
ATTRIBUTE | DESCRIPTION |
---|---|
hook |
The hook that triggered this CDS Service call. For example, 'patient-view'.
TYPE:
|
hookInstance |
A universally unique identifier for this particular hook call.
TYPE:
|
fhirServer |
The base URL of the CDS Client's FHIR server. This field is required if
TYPE:
|
fhirAuthorization |
Optional authorization details providing a bearer access token for FHIR resources.
TYPE:
|
context |
Hook-specific contextual data required by the CDS service.
TYPE:
|
prefetch |
Optional FHIR data that was prefetched by the CDS Client.
TYPE:
|
Documentation: https://cds-hooks.org/specification/current/#http-request_1
Source code in healthchain/models/requests/cdsrequest.py
Action
Bases: BaseModel
Within a suggestion, all actions are logically AND'd together, such that a user selecting a suggestion selects all of the actions within it. When a suggestion contains multiple actions, the actions SHOULD be processed as per FHIR's rules for processing transactions with the CDS Client's fhirServer as the base url for the inferred full URL of the transaction bundle entries.
https://cds-hooks.org/specification/current/#action
Source code in healthchain/models/responses/cdsresponse.py
ActionTypeEnum
CDSResponse
Bases: BaseModel
Represents the response from a CDS service.
This class models the structure of a CDS Hooks response, which includes cards for displaying information or suggestions to the user, and optional system actions that can be executed automatically.
ATTRIBUTE | DESCRIPTION |
---|---|
cards |
A list of Card objects to be displayed to the end user. Default is an empty list.
TYPE:
|
systemActions |
A list of Action objects representing actions that the CDS Client should execute as part of performing the decision support requested. This field is optional.
TYPE:
|
For more information, see: https://cds-hooks.org/specification/current/#cds-service-response
Source code in healthchain/models/responses/cdsresponse.py
Card
Bases: BaseModel
Cards can provide a combination of information (for reading), suggested actions (to be applied if a user selects them), and links (to launch an app if the user selects them). The CDS Client decides how to display cards, but this specification recommends displaying suggestions using buttons, and links using underlined text.
https://cds-hooks.org/specification/current/#card-attributes
Source code in healthchain/models/responses/cdsresponse.py
IndicatorEnum
Bases: str
, Enum
Urgency/importance of what Card conveys. Allowed values, in order of increasing urgency, are: info, warning, critical. The CDS Client MAY use this field to help make UI display decisions such as sort order or coloring.
Source code in healthchain/models/responses/cdsresponse.py
Link
Bases: BaseModel
-
CDS Client support for appContext requires additional coordination with the authorization server that is not described or specified in CDS Hooks nor SMART.
-
Autolaunchable is experimental
https://cds-hooks.org/specification/current/#link
Source code in healthchain/models/responses/cdsresponse.py
LinkTypeEnum
Bases: str
, Enum
The type of the given URL. There are two possible values for this field. A type of absolute indicates that the URL is absolute and should be treated as-is. A type of smart indicates that the URL is a SMART app launch URL and the CDS Client should ensure the SMART app launch URL is populated with the appropriate SMART launch parameters.
Source code in healthchain/models/responses/cdsresponse.py
SelectionBehaviorEnum
Bases: str
, Enum
Describes the intended selection behavior of the suggestions in the card. Allowed values are: at-most-one, indicating that the user may choose none or at most one of the suggestions; any, indicating that the end user may choose any number of suggestions including none of them and all of them. CDS Clients that do not understand the value MUST treat the card as an error.
Source code in healthchain/models/responses/cdsresponse.py
SimpleCoding
Bases: BaseModel
The Coding data type captures the concept of a code. This coding type is a standalone data type in CDS Hooks modeled after a trimmed down version of the FHIR Coding data type.
Source code in healthchain/models/responses/cdsresponse.py
Source
Bases: BaseModel
Grouping structure for the Source of the information displayed on this card. The source should be the primary source of guidance for the decision support Card represents.
https://cds-hooks.org/specification/current/#source
Source code in healthchain/models/responses/cdsresponse.py
Suggestion
Bases: BaseModel
Allows a service to suggest a set of changes in the context of the current activity (e.g. changing the dose of a medication currently being prescribed, for the order-sign activity). If suggestions are present, selectionBehavior MUST also be provided.
https://cds-hooks.org/specification/current/#suggestion
Source code in healthchain/models/responses/cdsresponse.py
ClinicalDocumentation
Bases: BaseUseCase
Implements EHR backend strategy for clinical documentation (NoteReader)
This class represents the backend strategy for clinical documentation using the NoteReader system.
It inherits from the BaseUseCase
class and provides methods for processing NoteReader documents.
ATTRIBUTE | DESCRIPTION |
---|---|
service_api |
The service API method to be used for processing the documents.
TYPE:
|
service_config |
The configuration for the service.
TYPE:
|
service |
The service to be used for processing the documents.
TYPE:
|
client |
The client to be used for communication with the service.
TYPE:
|
overwrite |
Whether to overwrite existing data in the CDA document.
TYPE:
|
Source code in healthchain/use_cases/clindoc.py
84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 |
|
process_notereader_document(request)
Process the NoteReader document using the configured service API.
This method handles the execution of the NoteReader service. It validates the service configuration, checks the input parameters, executes the service function, and ensures the correct response type is returned.
PARAMETER | DESCRIPTION |
---|---|
request
|
The request object containing the CDA document to be processed.
TYPE:
|
RETURNS | DESCRIPTION |
---|---|
CdaResponse
|
The response object containing the processed CDA document.
TYPE:
|
RAISES | DESCRIPTION |
---|---|
AssertionError
|
If the service function is not properly configured. |
TypeError
|
If the output type does not match the expected CdaResponse type. |
Note
This method performs several checks to ensure the integrity of the service: 1. Verifies that the service API is configured. 2. Validates the signature of the service function. 3. Ensures the service function accepts a CdaRequest as its argument. 4. Verifies that the service function returns a CdaResponse.
Source code in healthchain/use_cases/clindoc.py
ClinicalDocumentationStrategy
Bases: BaseStrategy
Handles the request construction and validation of a NoteReader CDA file
Source code in healthchain/use_cases/clindoc.py
construct_cda_xml_document()
This function should wrap FHIR data from CcdFhirData into a template CDA file (dep. vendor TODO: implement this function
construct_request(data, workflow)
Constructs a CDA request for clinical documentation use cases (NoteReader)
PARAMETER | DESCRIPTION |
---|---|
data
|
CDA data to be injected in the request
TYPE:
|
workflow
|
The NoteReader workflow type, e.g. notereader-sign-inpatient
TYPE:
|
RETURNS | DESCRIPTION |
---|---|
CdaRequest
|
A Pydantic model that wraps CDA data for SOAP request
TYPE:
|
RAISES | DESCRIPTION |
---|---|
ValueError
|
If the workflow is invalid or the data does not validate properly. |
Source code in healthchain/use_cases/clindoc.py
CdaRequest
Bases: BaseModel
Source code in healthchain/models/requests/cdarequest.py
from_dict(data)
classmethod
model_dump(*args, **kwargs)
model_dump_xml(*args, **kwargs)
Decodes and dumps document as an xml string
Source code in healthchain/models/requests/cdarequest.py
CdaResponse
Bases: BaseModel
Source code in healthchain/models/responses/cdaresponse.py
from_dict(data)
classmethod
model_dump(*args, **kwargs)
model_dump_xml(*args, **kwargs)
Decodes and dumps document as an xml string