Use Cases
CdsRequestConstructor
Bases: BaseRequestConstructor
Handles the request construction and validation
Source code in healthchain/sandbox/use_cases/cds.py
construct_request(prefetch_data, workflow, context={})
Constructs a HL7-compliant CDS request with prefetch data.
PARAMETER | DESCRIPTION |
---|---|
prefetch_data
|
Dictionary mapping prefetch keys to FHIR resources
TYPE:
|
workflow
|
The CDS hook name, e.g. patient-view
TYPE:
|
context
|
Optional context data for the CDS hook
TYPE:
|
RETURNS | DESCRIPTION |
---|---|
CDSRequest
|
A Pydantic model that wraps a CDS request for REST API
TYPE:
|
RAISES | DESCRIPTION |
---|---|
ValueError
|
If the workflow is invalid or not implemented |
TypeError
|
If any prefetch value is not a valid FHIR resource |
TODO: Add FhirServer support
Source code in healthchain/sandbox/use_cases/cds.py
ClinicalDecisionSupport
Bases: BaseUseCase
Implements EHR backend simulator for Clinical Decision Support (CDS).
This class provides functionality to simulate CDS Hooks interactions between an EHR system and a CDS service. It handles the construction and sending of CDS Hook requests according to the HL7 CDS Hooks specification.
PARAMETER | DESCRIPTION |
---|---|
path
|
The API endpoint path for CDS services
TYPE:
|
client
|
The client used to send requests to the CDS service
TYPE:
|
The class uses a CdsRequestConstructor strategy to build properly formatted CDS Hook requests with appropriate context and prefetch data.
See https://cds-hooks.org/ for the complete specification
Source code in healthchain/sandbox/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
model_dump(**kwargs)
Model dump method to convert any nested datetime and byte objects to strings for readability. This is also a workaround to this Pydantic V2 issue https://github.com/pydantic/pydantic/issues/9571 For proper JSON serialization, should use model_dump_json() instead when issue is resolved.
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
ClinDocRequestConstructor
Bases: BaseRequestConstructor
Handles the request construction and validation of a NoteReader CDA file
Source code in healthchain/sandbox/use_cases/clindoc.py
construct_cda_xml_document()
This function should wrap FHIR resources from Document into a template CDA file TODO: implement this function
construct_request(document_reference, workflow)
Constructs a CDA request for clinical documentation use cases (NoteReader)
PARAMETER | DESCRIPTION |
---|---|
document_reference
|
FHIR DocumentReference containing CDA XML data
TYPE:
|
workflow
|
The NoteReader workflow type, e.g. notereader-sign-inpatient
TYPE:
|
RETURNS | DESCRIPTION |
---|---|
CdaRequest
|
A Pydantic model containing the CDA XML wrapped in a SOAP envelope
TYPE:
|
RAISES | DESCRIPTION |
---|---|
ValueError
|
If the SOAP envelope template is invalid or missing required keys |
Source code in healthchain/sandbox/use_cases/clindoc.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.
When used with the @sandbox decorator, it enables testing and validation of clinical documentation
workflows in a controlled environment.
ATTRIBUTE | DESCRIPTION |
---|---|
client |
The client to be used for communication with the service.
TYPE:
|
path |
The endpoint path to send requests to. Defaults to "/notereader/". Will be normalized to ensure it starts and ends with a forward slash.
TYPE:
|
type |
The type of use case, set to UseCaseType.clindoc.
TYPE:
|
strategy |
The strategy used for constructing requests.
TYPE:
|
Example
@sandbox("http://localhost:8000") class MyNoteReader(ClinicalDocumentation): def init(self): super().init(path="/custom/notereader/")
Create instance and start sandbox
note_reader = MyNoteReader() note_reader.start_sandbox(save_data=True)
Source code in healthchain/sandbox/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