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.	See notes on normative term in Issues section	Open
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.	closed	0.3
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.	Closed	0.3
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.	Open
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
DDuLong	40399	Edits to Purpose	Partially adopted	Closed	0.7
DDuLong	40399	Edits to Description	Adopted	Closed	0.7
DDuLong	40399	I think we are overemphasizing the wrong concept with "planned" vs. "unplanned". The process is very similiar, the key difference is the location of this event changes the role and actors participating, and not all steps are used in all settings. The example we are illustrating with this use case uses more of a team than other settings. For example, in prehospital, all steps would be performed by a paramedic, in the OR, all steps would be performed by the anesthesiologist. I think we are overemphasizing the planning of an intubation, but a patient is always intubated in order to maintain respirations regardless of the setting.	At this time, our workflow is defined by the assumption. We may change it in another iteration. For discussion.	Open
DDuLong	40399	Edits to Roles	Adopted	Closed	0.7
DDuLong	40399	Devices: delete ABG monitor: it's a lab test	Test in the scenario, but it could be a device. What is the impact on the information model?	Open	0.7
DDuLong	40399	Devices: change Electrocardiograph to EKG Monitor	Adopted	Closed	0.7
DDuLong	40399	Edits to preconditions	Adopted	Closed	0.7
DDuLong	40399	Edits to postconditions	Adopted	Closed	0.7
DDuLong	40399	Edits to workflow actors	Partially adopted	Closed	0.7
DDuLong	40399	Edits to notes	Template notes removed as confusing.	Closed	0.7
DDuLong	40399	Edits to data requirements	Partially adopted	Closed	0.7