Buried in some recent posts I’ve listed out a rough classification of decision support applications or “use cases”, and also four major classes of knowledge representation.
What I haven’t yet articulated is how and when all this knowledge may interact with the process of care.
Broadly speaking, hospital software will either push or pull decision support output.
“Pushing” will occur as a result of a number of “triggers”:
The output may be pushed to different channels depending on the urgency of the message and most appropriate target. The urgency of a message will itself, almost certainly, require some decision support logic. Indeed determining the urgency could often be the bulk of the logic. SMS (including pager) messages, e-mail or even traditional paper letters can then all go to an appropriate clinician (GP, RMO, ward-nurse, consultant) or the patient themselves (or both). For inpatients, conceivably flashing alarms at the bed-side or ward clinical desktop could deliver urgent alerts.
Less urgent messages related to inpatients could simply cause flagging of patients on routinely generated inpatient lists. This could also include a brief summary message.
Specialist units could also review a list of non-urgent matters relating to outpatients at routine meetings or outpatient clinics.
“Pulling” of decision support would occur at numerous points while interacting with clinical information systems (eg ordering a test, prescribing a drug, completing a referral or discharge summary). Alert boxes and other automated system messages would convey the outcome of the decision support systems conclusions and recommendations.
What I haven’t yet articulated is how and when all this knowledge may interact with the process of care.
Broadly speaking, hospital software will either push or pull decision support output.
“Pushing” will occur as a result of a number of “triggers”:
- new information (such as an investigation result)
- particular patient care events (referral, booking, arrival, discharge, etc)
- automated time-based events (hourly, annually etc)
The output may be pushed to different channels depending on the urgency of the message and most appropriate target. The urgency of a message will itself, almost certainly, require some decision support logic. Indeed determining the urgency could often be the bulk of the logic. SMS (including pager) messages, e-mail or even traditional paper letters can then all go to an appropriate clinician (GP, RMO, ward-nurse, consultant) or the patient themselves (or both). For inpatients, conceivably flashing alarms at the bed-side or ward clinical desktop could deliver urgent alerts.
Less urgent messages related to inpatients could simply cause flagging of patients on routinely generated inpatient lists. This could also include a brief summary message.
Specialist units could also review a list of non-urgent matters relating to outpatients at routine meetings or outpatient clinics.
“Pulling” of decision support would occur at numerous points while interacting with clinical information systems (eg ordering a test, prescribing a drug, completing a referral or discharge summary). Alert boxes and other automated system messages would convey the outcome of the decision support systems conclusions and recommendations.
No comments:
Post a Comment