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

1. (Choose one)
   1. A DCM is a UML package developed in the HL7 DAM process; as such, it is part of a DAM
   2. A DCM is . . .
2. 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

Go to DCM Charter References and Glossary