Domain Analysis Model Development Guidelines Clinical Interoperability Council Working Group

Acknowledgment Anita Walden Prepared the initial presentation, allowed the use of material from earlier presentations. Abdul-Malik Shakir Provided definition and discussion of DAM components based on work for NCI.

Purpose of a DAM: Patient Clinician Healthcare Data Systems Patient care Quality Improvement Research Reimbursement Post Marketing Safety Decision Support Administration & Mgt. Public Health Reporting … Data Uses Single Source Multiple Uses

Construction Procedures Standardize at source  healthcare –Data element as atomic unit of exchange –Specificity sufficient for semantic interoperability Include all Stakeholders Examples –Public Health Representation  CDC –Quality Imp.  Professional Societies –Research representation  CDISC,NIH,FDA

Goals for the Guide Provide CIC DAM project groups with a guide on developing Clinical DAMs Promote reuse of DAM components in subsequent DAM projects Provide DAMs with similar designs: increase consistency for smoother harmonization, for integration with other DAMs and HL7 artifacts Improve the quality of the specifications used to develop HL7 products: messages, EHR profiles, CDAs

Guide Table of ContentsStatus IntroductionComplete ObjectiveComplete DAM DefinitionComplete ResourcesComplete HL7 Project ProcessIn progress Tooling (Enterprise Architect, Excel, Word, CaDSR)In progress DAM ModulesDraft Requirement Gathering ProcessDraft DAM Modeling StylesIn progress Next Steps (DCMs, relationship between enumeration in DAM)In progress

What is a DAM? An analysis model developed to improve communication between stakeholders from different organizations. This requirements document is used to formally define and structure data and/or process information to develop specifications within HL7 (e.g., Messaging, EHR functional models, DCMs).

HL7 Educational Resources Tutorials relating to working on DAMs: Introduction to the HDF Domain Analysis Modeling Introduction to UML Introduction to Project Insight Introduction to V3

DAM and the HL7 Process First comes the project statement Determine who is involved –Collaborate with the relevant working groups –Include international communities & affiliates Follow the HDF/SAEF process Ballot as an informative document

DAM Components An HL7 Domain Analysis Model (DAM) is not simply an information model. The DAM may include multiple diagram types. This section discusses the components of a DAM, and their relationships.

Components in a picture

Story Board/Scenario Rationale: Provide a story of some relevant occurrence – sequence of events. Example: Wallace Wackyford, a Fun Store employee, submitted an adverse event report to the FDA to report an incident after being contacted by the principal of the Central Z Middle School. A black color face paint (item# 5), produced by Coverings Corporation, as listed on the label, was applied to the students as part of a special theme day. Approximately 300 students received an application of face paint with different brushes. The following day, approximately students reported having a rash on their face. Later the number of rashes had accumulated to approximately 173. A dozen or so students sought medical treatment. Medical information was not included in the report from Mr. Wackyford. The report was sent electronically using a web-based form. The web-based form translates the information into an HL7 ICSR and routes the report to the appropriate FDA safety evaluator for analysis.

Use Cases Rationale: Provide a more formal treatment of requirements than the storyboard. Describes a sequence of actions that provide a measurable value to an actor. The formality includes: –Identifying use case actors, –showing how actors participate in use cases, –defining the associations between use cases Example: See over

Data Elements Rationale: Represent the data in a way that is more intuitive to clinicians (non modelers) than a class mode (or use case diagram, or activity diagram) Allows easy pulling from forms or existing lists Easy to consider as the unit of data exchange Example:

Example Part Two Data Element Name: History of peripheral vascular disease Clinical Definition: Indicate if the patient has a history of peripheral vascular disease. This can include: 1. Claudication either with exertion or at rest. 2. Amputation for arterial vascular insufficiency. 3. Aorto-iliac occlusive disease reconstruction, peripheral vascular bypass surgery, angioplasty or stent; or percutaneous intervention to the extremities. 4. Documented abdominal aortic aneurysm (AAA) repair or stent. 5. Positive non-invasive/invasive test. This does not include procedures such as vein stripping, carotid disease, or procedures originating above the diaphragm. Valid Values: Yes, No

Class & Attribute Component Rationale: represent the information needs of the domain with more formality than the data element list –Show how data elements clump into classes –Define relationships between classes. Supports downstream migration: – Ease the creation of HL7 RIM based specifications. – Create an entry point for CaDSR migration. Example: See over

TB Class Component

Class Model & Data Elements Both represent the information content of the DAM Can often be reviewed separately: –Clinicians reading the list of elements –Modelers & HL7ists examining the class diagram, class descriptions, attribute descriptions. Keeping these synchronized can be difficult. It always involves work.

Activity Component Rationale: Express workflow within the domain –Identify specific activities, –Show the sequence and conditionality of activities, –Use “swim lanes” to provide hints on where data exchanges take place. Example: See over

Cardio- vascular DAM Activity Component

State Machine Component Rationale: Show the behavior of an individual class within the class diagram. When used for critical classes, it exposes the need for a service or message specification. Example: So far, we don’t have a DAM that has built one.

Working with a Data Repository Class Components are deposited in CaDSR and therefore the requirements should follow their submission criteria

Next Steps Complete Modeling Guides for each Model Component Work with development teams to use and improve the modeling guide Support fuller implementation of DAM building into the HL7 process

Are there any questions?