1 / 27

Domain Analysis Model Development Guidelines

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.

drake
Télécharger la présentation

Domain Analysis Model Development Guidelines

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Domain Analysis Model Development Guidelines Clinical Interoperability Council Working Group

  2. Acknowledgment • Anita WaldenPrepared the initial presentation, allowed the use of material from earlier presentations. • Abdul-MalikShakirProvided definition and discussion of DAM components based on work for NCI.

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

  4. 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

  5. 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

  6. 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).

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

  8. 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

  9. 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.

  10. ECCF (Enterprise Conformance and Compliance Framework) Components in a picture

  11. 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 70 - 80 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.

  12. 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

  13. 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:

  14. 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

  15. 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

  16. TB Class Component

  17. 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.

  18. 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

  19. Cardio-vascular DAM Activity Component

  20. 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.

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

  22. 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

  23. Are there any questions?

More Related