DCM Charter Approach
Back to DCM Charter Part One
DCM Charter References and Glossary
Approach
Activities will follow the process defined by HL7 for standard development in the HL7 Development Framework (HDF).
MZ: The current HDF does not include DCM. But I heard (@PHX WGM) that AMS wanted to include DCM in the proces.
JL: Back to question 1: if we are producing a DAM, the HDF would be best, even if we need to tweak it to meet some additional requirements. If we are producing something that is not a DAM, I have a different set of questions.
It is anticipated that DCMs will be represented as packages within the DAM. The project will address modeling issues peculiar to DCMs and not addressed by DAMs as they are identified. Issues that can be addressed in the DAM framework will be so addressed. Issues that fall outside that framework will be identified, prioritized, and either addressed or captured for future resolution.
We expect some of those issues to be addressed by a separate project, the Patient Care DCM project (HL7 project 320); see the Communication section.
Activities
The activities will follow the HDF, augmented with project control activities.
Initiation
Initiation consists of the activities necessary to conduct the project.
Initiation activities are documented in the construction of this Charter, which may be modified to reflect changes in approach. Key activities include scoping to ensure the right things get done and planning to ensure that things get done right.
Scope is documented in section three, above. Approach is documented in this section.
Use Case Analysis
See HDF sections 3.4.1 to 3.4.2.
Initial use case analysis embraces the “dynamic” side of the DAM. It involves the identification of the business processes to be supported, the actors that participate in these processes, reasons they initiate interaction, and interaction goals. At this point, the use case definitions scope the process and data required in the model.
In a further refinement, the use cases are detailed in a process analysis. This analysis specifies any additional steps or interactions required to scope fully the static model domain.
Question: will this include ‘device’ cases as well as clinical cases, or will device detail—to the extent we determine it is necessary—fall out of more detailed analysis of the clinical cases?
AG: Can we make uses cases where both sides are in device perspective and clinical perspective? The clinical perspective is leading, but de device perspective can be added as a separate part?
JL: My assumption is that the business drives the technology: the clinical cases are the business cases, and as they are refined, ancillary and supporting elements (device ID, waveform algorithm) and processes (device status check, firmware update) will precipitate out of them. In order to keep the model clear to clinical readers, technical processes can be modeled in different use cases in a different package; can elements be filtered by viewpoint?
Information analysis
Information analysis comprises the “static” side of the DAM.
AG: Some how we need to define the boundary between the clinical part and the technical part that is not relevant for the clinician or the EHR.
JL: agreed; see above
Information analysis will use the use case interactions to draw boundaries around the information required in the model. The entities will be grouped into packages, and the packages will support identified DCM requirements for granularity and clinical quality.
Business rules analysis
In addition to the static and dynamic analysis, effort will be made to identify appropriate rules for the model. Some rules, such as cardinality constraints, are built into the static model; others, such as trigger conditions, are built into the use cases.
A third class of rules constrains workflow and interactions, and a fourth clinical interpretation. These are not represented in the model per se, and will be captured to support DCM requirements.
Additional activities
The drivers for DCMs include the need for clinical guidelines, attestations of quality, and other documentation of expertise. Some of this knowledge may be considered business rules, addressed above, but much of it is not found in the DAM. These documents may be drafted in forms to be determined. As the candidates for this material include all of medical knowledge, the project team will need to determine a criterion of completeness.
Artifacts
The result of the project will be a Domain Analysis Model, including the following:
- An overview, specifying clinical and technical scope
- Actor names and definitions
- Use case diagrams and definitions, including triggers and results
- Role-based activity diagrams with narrations
- Class model diagrams with definitions, including attribute definitions and data types
- Packaged DCM components, with definitions and clinical metadata
AG: What metadata are meant here in comparison with what is determined for DCM?.
JL: "Clinical metadata" refers to items mentioned in ISO 13972 -- thresholds, quality measures, evidence base, etc. "Packaged components" refers to the concept of a DCM being a UML package within a DAM rather than a separate formalism (see question 1).
Milestones
We estimate the following schedule for project activities:
Incomplete Adapt milestones from the project scope statement Include ‘ballot strategy’ – how many ballots do we foresee; when will specifications be developed
Question: for September, will we complete a subset of use cases, or do wider scope in a more shallow manner? Recommend picking one use case to prove the process.
AG: agree with one use case
Resources
Roles
Role descriptions refer to HDF, plus additions
Domain expert (HDF)
AG: Both form the device perspective as from the clinical perspective.
Business analyst (HDF)
Modeling facilitator (HDF)
Vocabulary facilitator
Project manager
Staffing
Who will fill the roles
AG: See project scope statement.
| role | resource |
|---|---|
| Project Facilitator | PC: Anneke Goossen-Baremans: <annekegoossen@cs.com>
DEV: John Rhoads <john.rhoads@philips.com> Greg Staudenmaier <greg.staudenmaier@va.gov> |
| Other interested parties | Generation of Anaesthesia Standards (GAS) WG |
| Modeling facilitator | HL7: Ioana Singureanu <ioana.singureanu@gmail.com>,
ISO/IEEE: Todd Cooper < t.cooper@ieee.org > |
| Publishing facilitator | Ioana Singureanu < ioana.singureanu@gmail.com > |
| Vocabulary facilitator | HL7: Dr. Christof Gessner <gessner@mxdx.de>,
ISO/IEEE: Jan Wittenber <jan.wittenber@philips.com> |
| Domain expert rep | PC: Anneke Goossen-Baremans: <annekegoossen@cs.com>
DEV: Melvin Reynolds < melvinr@AMS-Consulting.co.uk > |
| Data Analyst facilitator | GAS: Alan Nicol <alan.nicol@informatics-cis.com> |
| Business requirement analyst | Catherine Hoang <Catherine.Hoang2@va.gov>,
Holly Miller <Holly.Miller@va.gov> DEV: John Rhoads <john.rhoads@philips.com> |
| Requirements process facilitator |
Responsibilities
These parties are responsible for the following activities. In the following matrix, the Responsible party performs the bulk of the work, the Accountable party ensures that the Responsible party has the correct direction and executes the task correctly, Contributing parties may assist, and Informed parties need to be apprised of progress but do not contribute.
Party One Party Two Party Three Party Four Party Five Activity One Activity Two Activity Three Activity Four Activity Five
Communication
The project will take full advantage of HL7 project management infrastructure. This includes the use of an HL7 conference line, Wiki for document sharing and contact information, meeting space at working group meetings, and a listserv for broadcast updates.
Status will be reported regularly to the sponsoring committee.
Other HL7 workgroups will be engaged when touchpoints are recognized, and their participants are invited to attend and participate in project meetings when they recognize such touchpoints.
Some of the deliverables of this project depend on input from the Patient Care DCM project (320), [include provisions for communication, accountability, impact of failure to secure expected inputs]
Weekly (?) working meetings on HL7 conference line Weekly (?) status meetings on HL7 conference line Artifacts on the wiki Listserv Other channels?
Quality
Approach – use HDF first, then DCM desiderata Enlist experts from appropriate domains
Risks and Assumptions
Risks
Unclear boundary between clinical and device data
- Mitigation: To be resolved as part of modeling process, but see draft note in Technical Scope section, above
DCM expectations – for repository and transformation
- Mitigation: clarify how this project is to coordinate with 320, ISO requirements project
Difficulty packaging DCM components for reuse
- Mitigation: update DAM to handle reuse of components, if DAM is the product
Conflict between “contextless” DCM requirement and process-based requirements analysis
- A static model can be ambiguous when introduced into a process
- Mitigation: ensure DCM artifacts carry the dynamic context along with the information model
Conflict among simultaneous development efforts (list)
- see stakeholders list
- Mitigation: clearly communicate goals, assumptions, and approaches
Time: goal of September; quality could suffer
- Mitigation: use the DAM, or change the timeline
Clinical scope definition unclear; possibly very large: can we group them?
- Mitigation: while working on the first one, also begin scoping out the full list and long-term schedule
Assumptions
- (Choose one)
- A DCM is a UML package developed in the HL7 DAM process; as such, it is part of a DAM
- A DCM is . . .
- This project will use clinical cases to define device DCMs: all necessary hardware elements will be modeled as required by the clinical domain
Back to DCM Charter
