1 / 33

Methodology for Action Verbs / Operations

Methodology for Action Verbs / Operations. Tony Weida June 10, 2014. Introduction. Methodology can guide progress through established objectives without extraneous detours

Download Presentation

Methodology for Action Verbs / Operations

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. MethodologyforAction Verbs / Operations Tony Weida June 10, 2014

  2. Introduction • Methodology can guide progress through established objectives without extraneous detours • Temptation to minimize rework by trying hard to preserveexisting hierarchies, along with existing names and text definitions • Athoughtful step back may yield more consistent, integrated results • No silver bullet* * By analogy to Brooks, Frederick P. , Jr. (1987). "No Silver Bullet—Essence and Accidents of Software Engineering". Computer20 (4): 10.

  3. Perspective on Integrating Existing Ontologies* • “… there is the question of how and whether to use [all or part of] ontologies that already exist. In general this is a very difficult problem.” • “Skuce’s main point is that in order to agree on ontologies that can be shared among multiple user communities, much work must be done to achieve agreement. One way forward is to make explicit all assumptions underlying the ontology.” • “… when there are similar concepts defined in existing ontologies, it is rarely clear how and whether such concepts can be adapted and reused” *Or for our purposes, vocabularies. Source: [Uschold and Gruninger]

  4. Phases • Prepare • Scope • Enumerate • Group, filter and conceptualize • Define and classify • Review and improve • Document, approve and use

  5. 1. Prepare Up front investment pays off But don’t get bogged down

  6. Naming Our Subject • Agree on one name • Action • Verb • Action Verb • Operation • Suggest single word: Action (or Operation)

  7. Goal: Harmonized HL7 Vocabulary • Shared across CBCC, EHR, Security and other HL7 specifications • Maintained separately from any individual specification

  8. Working Artifact As discussed … • Excel spreadsheet • Posted on HL7 Wiki • Stored and versioned in GForge

  9. Format for Entries • Name • Text definition • Genus and differentia • Template(s): [To enter data is] tocapture data by … • Structured representation • Parent(s) • Other properties, e.g., affected objects (input and/or output), preconditions, postconditions, … • Example(s) • Notes (assumptions, justifications, clarifications, etc.) • Decision history • Legacy definitions

  10. Understand Concepts and Terms • Preview: concepts and terms will factor into methodology • A concept represents a unique idea • A term refers to a concept (in natural language) • Each concept • May have multiple synonymous terms • Should have single preferred term

  11. Cardiac disorder Cardiopathy Myocardial finding (finding) 251052000 Heart disease (disorder) 56265001 Myocardial observation Disorder of heart Heart disease, NOS Disorder of heart muscle Myocardial disease (disorder) 57809008 Morbis cordis Disorder of Myocardium Myocardial infarction Myocardial disease, NOS MI Cardiac infarction Heart Attack Ataque cardíaco Terminology Elements (SNOMED) • Conceptsrepresent unique ideas • Codes uniquely identify concepts • Termsrefer to concepts • Typically • Humans communicate concepts using terms • Computers communicate concepts using codes • Concepts are language independent; terms are language dependent Myocardial infarction (disorder) 22298006

  12. Some Preliminary Considerations • Addressing privacy operations (along with data operations)? • Necessarily committed to any pre-existing names, definitions or hierarchical arrangement? • Definitions re affected object types? • Display vs. in memoryvs.persistent (database) objects • Change existing object vs. create new object? • Example: encrypt, mask, … • On-demand vs. persistent results? • … Eliminate, tolerate or embrace ambiguities? • Separation of concerns between EHR and Security?

  13. Separation of Concerns • EHR • Security • To what extent are actions shared? • Not about ownership

  14. 2. Scope What problems are we solving? What coverage and granularity are required?

  15. Target Audience • HIT standards community • EHR, Security, CBCC … • Authors • Reviewers • Adopters • Policy makers (jurisdiction; provider)? • System implementers? • System adopters?

  16. Purpose in General • Communication among people and organizations • Interoperability (shared resource or interlingua) • Systems engineering (specification, implementation, …)

  17. Motivating Scenarios • High Level • Examples • Specify EHRS functionality • Conformance • Record life cycle events • Specify security and privacy policies; consent directives • Interoperate between EHR and Security subsystems

  18. Competency Questions • Types of questions the ontology (vocabulary) must be able to answer • Generally, ontology should also be confined to answering them • Thus contents are necessary and sufficient • Benefits • Specify scope by providing inclusion / exclusion criteria • Help to justify work effort • Assist with evaluation

  19. Example Competency Questions • What types of action can … • … an EHRS perform (on behalf of a user)? • … be specified in a security policy? • … an EHRS request ask a security system to authorize or deny? • Does a given type of action specialize another? • What types of object(s) are acted on by a given type of action? • [In Security and Privacy Ontology context] Is user U playing role R authorized to perform action A on object O from location L at time T… ? • Note: Questions can be stratified, in the sense that responses to questions can composed to answer other questions

  20. 3. Enumerate • Gather candidate terms • Not yet focusing on concepts, definitions or hierarchy • Take existing lists • EHRS-FM Verbs • EHR-RMES Lifecycle events • Security and Privacy Ontology (SPO) operations • Brainstorm any additional terms (nonjudgmental, for now) • Note: initial focus on terms defers differences in understanding of fundamental concepts

  21. 4. Group, Filter and Conceptualize Identify work areas Assign terms to work areas Coalesce concepts from terms

  22. 4a. Identify Work Areas • Choose “naturally arising sub-groups” [Uschold and King] • Items within a group are relatively similar semantically • Items in different groups are relatively dissimilar • Not necessarily hierarchical classes • Might still start with top levels of EHRS-FM verb hierarchy

  23. 4b. Assign Terms to Work Areas • For each term • Considering our focus, decide to include, discard, or note as borderline case • Assign to appropriate area

  24. 4c. Coalesce Concepts from Terms For each work area • Identify concepts as collections of synonymous term(s) • Note near synonyms – with clear distinctions

  25. 5. Define and Classify Text definitions must precisely reflect taxonomy and vice versa Thus, effectively need to iterate an integrated process

  26. Text Definitions [Uschold and Gruninger] • Ensure consistency with existing (previously defined) terms • Avoid introducing new terms where possible • Avoid circularity • Necessary and sufficient, as far as possible in natural language • Follow template(s)

  27. Definitional Challenges [Uschold and King] When it’s hard to define or reach consensus about a term … • Clarify underlying concept (via research, discussion, etc.) • Temporarily use meaningless label to avoid getting hung up, and define underlying idea • Attach a term accordingly (ideally not the original, problematic term)

  28. Prefer Middle-out Approach [Uschold et al.] • Bottom-up: results in much detail, thus increasing overall effort, obscuring commonality, and increasing risk of inconsistency, hence rework • Top-down: better control of detail, but may yield arbitrary high level categories  risk of less stability, thus rework • Middle-out: • First define “most fundamental” terms in each area • Strikes a balance; reduces potential for rework

  29. 5. Define and Classify • Start with work areas having the most semantic overlap with other areas (get them right first, because mistakes lead to more re-work); If little overlap, proceed in any order [Uschold and Gruninger] • For each work group in turn … • For each concept • Select name (i.e., designate the single preferred term) • Draft precise text definition, ensuring consistency with all previously defined terms • Separately • Give examples as appropriate • Note assumptions, justifications and clarifications • Place into taxonomy • Ensure that text definition reflects position and vice versa

  30. 6. Review and Improve • Present to parent work groups for discussion and feedback • Solicit feedback from other experts?

  31. 7.Document, Approve and Use • Finalize taxonomy with concepts, terms, text definitions, etc. • Prepare and submit harmonization proposal • Adopt in new or revised HL7 specifications

  32. Recap of Phases • Prepare • Scope • Enumerate • Group, filter and conceptualize • Define and classify • Review and improve • Document, approve and use

  33. Discussion

More Related