 |
Page History
...
Term | Definition |
|---|---|
MUST | This word means that the definition is an absolute requirement of the specification. |
MUST NOT | This phrase means that the definition is an absolute prohibition of the specification. |
WILL | This word means that the definition is an absolute future requirement of the specification. |
WILL NOT | This phrase mean that the definition is an absolute future prohibition of the specification. |
SHOULD | This word means that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course. |
SHOULD NOT | This phrase means that there may exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behavior described with this label. |
MAY | This word means that a requirement is truly optional. The developer may choose to include the item based on the needs of their design. |
Use Case Level Criteria
When designing use cases, it is important to maintain a consistent approach to determining at which level use cases are placed when they are authored. The granularity of the use case directly relates to its implementability, so maintaining a leveling scheme will insure that use cases are implemented, tested, etc. at a consistent level. In alignment with this, we will maintain the following use case leveling criteria:
- Global statement
Example: manage patient's health - Use Case Level 0: most general, high level business process
Example: treat this patient for cancer - Use Case Level 1: next level of business flow, such as inter-department level
Example: treat this patient for cancer by using diagnostics, education, treatments, etc. - Use Case Level 2: specific enough to drive major model dimensions (static/information model, behavioral model, governance model, etc.) and can include some exception conditions
Example: treat this patient for cancer by ordering these lab tests, evaluating the results, customizing a treatment or treatment plan to specifically address concerns - Use Case Level 3: includes details of each exchange of information, as well as assumptions about system boundaries
Example: treat this patient for cancer by ordering these lab tests in the caEHR system
i. find the patient, if new add patient, if not check for update
ii. create request(s) for testing for patient, then evaluate the results,
ii-a. read the faxed copy of the result or
ii-b. receive notification in Provider email that a result is ready for viewing, etc... - Use Case Level 4: project-specific solution for exchanges detailed in use case level-3 (could be MSG, SOA, or both)
Example:Standard Process Flow
1. Provider Refers Patient for Cancer Treatment
2. Provider and Patient have an encounter
3. Provider evaluates Patient's condition, treatment plan, current statistics, requests diagnostics
4. Provider updates treatment plan
5. Patient is treated, outcomes documented
6. Flow returns to any of the above steps or patient is released from cancer treatment
Assumptions and Dependencies
...
