This wiki has undergone a migration to Confluence found Here
<meta name="googlebot" content="noindex">

DCM use case editorial suggestions

From HL7Wiki
Revision as of 15:05, 26 July 2010 by Jlyle (talk | contribs)
Jump to navigation Jump to search

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