DCM use case editorial suggestions

Use Case Editorial Suggestions

Back to Use Case List

Proposed by	Date	Proposal	Approach	Status	Version
ISingueanu	7/20	Under "Use case description" we should add a brief clarification of the difference between planned and unplanned intubation: Intubations that occur in a controlled environment (e.g., the OR) are Planned, and those that occur out of the OR are considered Unplanned. The premise for distinguishing Planned Intubation was to exclude any complications derived from including different anesthesia systems and an additional set of roles specific to the planned procedure.	Added	closed	0.2
ISingueanu	7/20	Under "Actors" I would recommend describing who may  be a "clinician with intubation privileges". Are you referring to the Ordering Physician or the clinician who performs the procedure itself. A brief description of each actor as they participate (e.g. nurse to administers therapy, physician to orders the procedure, the respiratory therapist who administers therapy...).	Added	closed	0.2
ISingueanu	7/20	Under "Pre-Conditions" I think we need to specify that specific panic values for blood gases must be reached. Specifically pH, PaCO2, PaO2 and SaO2 are the four critical ABG values used to determine need for intubation. Another pre-existing condition for intubation may be a physician order.	The number of potential clinical conditions is very large, and none are individually required; propose leaving the clinical decision to intubate to the clincian, and make the Trigger the order or protocol	closed	0.3
ISingueanu	7/20	I would recomment removing "Extension Points" since we are not describing extensible functionality and it may be confusing to some reviewers. In the future we may add "Related Use Cases" or "Included Use Cases" as needed. We could add a placeholder for future use cases as needed.	Removed	closed	0.2
ISingueanu	7/22	Replace “Capnometer” with “Capnometry Monitor”(?) after we validate that is the proper term for the device.	Confirm normative term	IP
ISingueanu	7/22	The first time “ET” is used it should be spelled out. Subsequently the shorthand is OK.	All abbreviations will be spelled out the first time.	closed	0.2
ISingueanu	7/22	Patient identity may be determine based on the ADT records from the HIS system or using a bar code on the patient’s wrist. You may want to add this to the precondition section.	I'll add the bar code possibility to the preconditions, with a note to the effect that any individual device identification is deferred to a different scenario.	IP
ISingueanu	7/22	Confirming observations, measured values is done after the procedure, when the information is reported to the clinical system. All the “confirm” steps should be included in the post-condition.	Confirmation will be rolled into the last step, and the information requirements will be included, scoped by the template and acls protocol.
Team	7/22	Interactions alone are not sufficiently broad scope	Add VA national template and ACLS protocol, as manifest in designated protocol document	closed	0.3
ISingueanu	7/22	let’s rename “Actors” to ‘Participants” in the use case template. Actor is a silly UMLsm, frankly that baffles SMEs all the time. When know what we mean. This way we can include the Patient as a “Participant” even though it’s a subject not “real” actor.	I like that it lets us include Patients. As it's still a spec for the model, we'd need a way to distinguish the two.	IP	"
Team	7/22	Make it clinician-friendly: include clinical details in a way that can't be missed		IP
JRhoads	7/26	The use-case is very specific to a scenario	a) add language to the ballot introduction explaining the two objectives and how we see them fitting together, including language suggesting we are as interested in process-related comments as content-related comments; b) raise the abstraction level of the case by either removing the devices altogether or at least placing the device lists and "system response" column out of scope for comments.	closed	0.3