Question

Evaluation Describe the methods that can be used to evaluate your CDSS application (what is/are best ways of evaluation strategies to assess the system? And why?) Based on your expected evaluation results, redraw your workflow Diagram and describe your expected effective workflow.

Answer 1

Answer:

a four-phase framework for evaluating clinical decision support architectures. The four phases are:

1. Feature determination: We develop a set of desirable features for decision support architectures based on a review of literature and expert opinions and then evaluated the relative ability of decision support architectures to exhibit these desirable features.

2. Existence and Use: We develop a four level spectrum of the existence and use of clinical decision support architectures, ranging from theoretical discussion at one end to widespread adoption and use at the other extreme.

3. Utility: We evaluate each architecture’s ability to implement a wide range of decision support use cases.

4. Coverage: We measure each architecture’s ability to cover a large knowledge base of decision support content.

The following workflow can be utilised to develop a better CDSS application:

1. the architecture’s ability to be used for use cases with a variety of different properties, including:

2. Developer: Ideally, a decision support architecture should not restrict who can develop decision support content. For example, it is undesirable for an architecture to have technical or other restrictions which allow only a particular clinical system vendor to develop content. Likewise, it likely is desirable for an architecture to support a variety of decision support developers, such as end users, third-party commercial developers, and open source developers.

3. User: The architecture should support decision support with a variety of intended users. Although most decision support is targeted at clinicians, the ability to develop use cases for other potential users, such as public health departments and patients is desireable.

4. Information source: An architecture should not place limits on the source of knowledge or information for decision support interventions.

5. Clinical purpose: The architecture should enable development of decision support across a variety of clinical purposes, including diagnosis, therapy, information display and public health.

6. Inference type: A variety of inference types should be supported – not just simple rule-based systems.

7. Composition: It should be possible to combine or compose decision support rules or services to form new decision support systems.

8. Business model: The architecture should enable a variety of business models for providing decision support, including commercial providers, free and open source providers, decision support provided by the government and decision support provided by expert groups and medical specialty societies (who currently provide written guidelines).

9. Pay Status: There should be a way to support both free and pay models for decision support.

10. Development Status: A variety of use cases should be demonstrated in the architecture, not just decision support systems developed by the same entities that developed the decision support architecture.