This wiki has undergone a migration to Confluence found Here

DCM use case editorial suggestions

From HL7Wiki
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. 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