Date post: | 01-Jan-2016 |
Category: |
Documents |
Upload: | armando-holden |
View: | 32 times |
Download: | 0 times |
2
Meeting Etiquette
Click on the “chat” bubble at the top of the meeting window to
send a chat.
• Please mute your phone when you are not speaking to prevent background noise.– All meetings are recorded.
• Please do not put your phone on hold. – Hang up and dial back in to prevent
hold music.• Use the “Chat” feature to ask questions
or share comments.– Send chats to “All Participants” so
they can be addressed publicly in the chat, or discussed in the meeting (as appropriate).
3
Agenda
Topic Time Allotted
General Announcements 5 minutesTiger Team report out 5 minutesConsensus Reviewe 30 minutesUse Case Process Discussion/Overview 15 minutesNext Steps/Questions 5 minutes
4
Next meetings:• Tiger Team: Monday June 9th, 2014 3:00-4:00pm ET• All Hands: Thursday June 12th, 2014 – 2:30-3:30 pm ET• http://wiki.siframework.org/Data+Provenance+Initiative
• All meeting materials (including this presentation) can be found on the Past Meetings page:• http://wiki.siframework.org/Data+Provenance+Past+Meetings
General Announcements
5
S&I Framework Phases outlined for Data Provenance
Phase Planned Activities Pre-Discovery Development of Initiative Synopsis
Development of Initiative Charter Definition of Goals & Initiative Outcomes
Discovery Creation/Validation of Use Cases, User Stories & Functional Requirements Identification of interoperability gaps, barriers, obstacles and costs Review of Candidate Standards
Implementation Creation of aligned specification Documentation of relevant specifications and reference implementations
such as guides, design documents, etc. Development of testing tools and reference implementation tools
Pilot Validation of aligned specifications, testing tools, and reference implementation tools
Revision of documentation and toolsEvaluation Measurement of initiative success against goals and outcomes
Identification of best practices and lessons learned from pilots for wider scale deployment
Identification of hard and soft policy tools that could be considered for wider scale deployments
We are Here
6
Data Provenance Timeline for All Hands MeetingsDate Meeting April 24th • Kick Off
• Review of Project Charter: Background, Challenge
May 1st • Tiger Team Report Out• Review Submitted Charter Comments• Continue Review of Project Charter:
• Purpose and Goals, Scope, Potential Standards for ConsiderationMay 8th • CANCELED DUE TO HL7 (Tiger Team Canceled as well)
• Tiger Team will present work to HL7 Weds May 7th Q3
May 15th • Review of Project Charter• Value Statement, Potential Standards for Consideration, Potential Risks, Stakeholders
May 22nd • Final Review of Charter• Begin Charter End to End Review
May 29th • Dispose End to End Review Comments• Start Charter Consensus• Kick off Use Case
June 5th • Charter Consensus• Use Case Review
7
Data Provenance Tiger TeamBob Yencha – Subject Matter Expert
Kathleen Conner – Subject Matter Expert
Ioana Singureanu – Subject Matter Expert
Neelima Chennamaraja – Subject Matter Expert
Johnathan Coleman- Initiative Coordinator
HL7 VOCABULARY HARMONIZATION PROPOSALS
Threading the Eye of the Needle – Increasing Provenance Semantics in the CDA
DPROV CDA Tiger Team Harmonization ProposalASK
• Over the last 4 weeks, DPROV CDA Tiger Team has analyzed whether the CDA R2 can be optimized for Provenance by improving Provenance Semantics via permissible vocabulary updates through HL7 July Harmonization
• DPROV CDA Tiger Team requests that the DPROV community consider approving the following Harmonization Proposals, which will be– More deeply discussed on Monday 6/10 TT call – Moved for final approval on DPROV All Hands on Thursday 6/12
• Note that this approval is for an Initial Submission only• Final submissions are due 7/6 so there are 3 weeks in which to
“tweak” or withdraw any of these proposals (i.e., this is not last “bite of the apple)
DPROV CDA July Harmonization Process and Procedure
• HL7 hosts HL7 v3 Harmonization meetings 3 times a year (March, July, and Nov)
• During meetings WGs bring forward their proposed changes to the HL7 RIM or the HL7 Normative Vocabulary
• All HL7 WGs are required to send representatives to participate
• Vocabulary changes are made on a regular basis – including addition of codes and refined definitions
• But all HL7 RIM & Vocabulary changes must go through this process
DPROV CDA Harmonization ParametersBackground
DPROV CDA• CDA R2 restricts vocabulary to HL7 RIM Normative Edition
2.07 from 2006• Most vocabulary is tightly constrained to the use cases on
which CDA was developed• Over time it’s become clear that other use cases are not well
served by these constraints– CDA profilers are forced to use overgeneralized or inappropriate
codes to convey meaning that the CDA vocabulary can’t support– In a few cases, Realm-specific extensions have been allowed
• E.g., HITSP C32 vocabulary has several extensions such as race and provider type
• For these reasons, Structured Documents WG has initiated a review of those vocabulary constraints in a CDA R2.1
DPROV Harmonization ParametersApproach
• HL7 July Harmonization Proposals are limited to the minimum needed for a future DPROV CDA IG and extensions for CDA R2.1 Vocabulary
• Scoped to maximize the Provenance Semantics currently available in CDA R2
• The extensions will not be used in the initial DPROV CDA IG, but gets them “on the table” for use in CDA R2.1
DPROV CDA Harmonization Proposal [1]
• 2 Proposed value sets have no CDA constraints– New ASSEMBLER & REVIEWER Participation
Function codes– ProvenanceEvent Act.code value set
ASSEMBLER ParticipationFunction CodeBusiness Need & Proposed Definition
• TT has previously differentiated ASSEMBLER Device from the Authoring Device because:– It does not create new information– It assembles already created information
• Recommend proposing as ParticipationFunction to specialize CDA Participation Type DEV (device)– Description: Participant used in performing the act without being
substantially affected by the act (i.e. durable or inert with respect to that particular service)
– Examples: Monitoring equipment, tools, but also access/drainage lines, prostheses, pace maker, etc.
• Proposed Definition: A device that operates on custodian’s algorithms for data extraction of existing information for purpose of generating a new artifact.
REVIEWER ParticipationFunction CodeBusiness Need & Proposed Definition
• esMD representative (Bob Dieterle) requested a new ParticipationType REVIEWER to further specify Verifier
• Since REVIEWER is not in CDA ParticipationType value set, we are proposing a new ParticipationFunction code that further specifies the function that a Verifier performs
• Proposed Definition:– Specifies the exact function an actor is authorized to have as a
verifier of an Act. – Connotes specialized Verifier per jurisdictional or organizational
policy• E.g., The Provider Verifier who takes responsibility for authenticity of a
Verified record submitted to a payer
DPROV CDA Harmonization Proposals
• 2 Proposals are for value set extensions to justify the inclusion of several codes from the Normative Edition 2.07 Vocabulary [CDA RIM] that would increase Provenance Semantic capabilities
• Future may permit:– Inclusion of later HL7 Vocabularies in DPROV CDA
value sets– Updates to DPROV CDA value sets per Harmonization
updates to the HL7 Vocabulary
17
Header relatedDocumentProposed Extension to x_ActRelationshipDocument
Proposed Value Set Extensions for current x_ActRelationshipDocument for richer provenance semantics about a CDA’s relationship to Predecessor Documents• COMP [component] - The target act is a component of the source act,
with no semantics regarding composition or aggregation implied• XCRPT [excerpts] The source is an excerpt from the target
Code Definition
APND (append) The current document is an addendum to the ParentDocument.
RPLC (replace) The current document is a replacement of the ParentDocument.
XFRM (transform) The current document is a transformation of the ParentDocument.
x_ActRelationshipEntryRelationshipNew ActRelationshipProvenanceEntryRelationship
AS IS• COMP can be used to indicate non-specific
aggregation or composition relationship• SAS could indicate succession at in Lifecycle• SUBJ can be used to relate an Entry to a Provenance
Act• XCRPT can be used to indicate that one Entry is
excerpted from another EntryGAP
• SUCC – Succeed– Use Case: Entry has [0…*] ProvenanceEvent
Acts, which succeed one another
• UPDT – Update– Use Case: Entry has [0…*] ProvenanceEvent
Acts, which are updates to a Predecessor
ProvenanceEvent Codes
• Core to the DPROV CDA Modeling approach is a ProvenanceEvent Template to record an Entry’s Provenance relevant Lifecycle stages
Why we need ProvenanceEvent Value Set
• After review of alternatives, TT determined that there are no current HL7 code systems or value sets that are fit for purpose.
• Several HL7 code systems, which can not be used “as is” in DPROV CDA IG, have codes that could be selected for a new ProvenanceEvent value set.
ProvenanceEvent codes
• Reuse of existing HL7 codes for ProvenanceEvent codes to convey the Lifecycle stages that an Entry’s predecessors passed through before the current Entry’s Lifecycle stage, E.g., Target Entry was – Activated by initial author– Dictated by initial author and transcribed by Data
Enterer– Appended by another author with information
excerpted from an external document– Updated by another author based on information
excerpted from another Entry – Completed by a 3rd author
What ProvenanceEvent Vocabulary is & is notProvenanceEvent Vocabulary Harmonization Proposal is the typical way in which HL7 v3 models add to or constrain current HL7 v3 Vocabulary, which is normative • This activity is totally independent of any other HL7 Vocabulary projects such as:
– CBCC WG:• Patient Friendly Language for Consent Directives• Privacy Consent Directive DAM
– Security Work Group:• RBAC Catalog• Healthcare Privacy and Security Classification System• Composite Security and Privacy Domain Analysis Model• Security and Privacy Ontology
– EHR and Security WG “Way with Verbs” Project• Scope is to align EHR FM (& Profiles) Action Verb Glossary with Security WG Security and
Privacy Ontology (SPO)• This “harmonization” or mapping project is not the same as the formal HL7 Harmonization
process and in no way intended to impact the use of the HL7 normative Vocabulary by the many HL7 WGs that use these codes/value sets
• Launched in January 2014 after preliminary efforts that span several years of work
Candidate ProvenanceEvent Value Set Codes [1]
aborted aborted The Act has been terminated prior to the originally intended completion.
ActStatus
activate activate Change the status of an object representing an Act to "active", i.e., so it can be performed or is being performed, for the first time.
DataOperation
annotate annotate Add commentary, explanatory notes, critical notes or similar content to an object.
DataOperation [child of update]
append append Fundamental operation in an Information System (IS) that results only in the addition of information to an object already in existence.
DataOperation [child of update]
AU authenticated A completion status in which a document has been signed manually or electronically by one or more individuals who attest to its accuracy. No explicit determination is made that the assigned individual has performed the authentication. While the standard allows multiple instances of authentication, it would be typical to have a single instance of authentication, usually by the assigned individual.
DocumentCompletion
cancelled cancelled The Act has been abandoned before activation. ActStatus
completed completed An Act that has terminated normally after all of its constituents have been performed.
ActStatus
Candidate ProvenanceEvent Value Set Codes [2]
DI dictated A completion status in which a document has been signed manually or electronically by one or more individuals who attest to its accuracy. No explicit determination is made that the assigned individual has performed the authentication. While the standard allows multiple instances of authentication, it would be typical to have a single instance of authentication, usually by the assigned individual.
DocumentCompletion
DO documented A completion status in which document content, other than dictation, has been received but has not been translated into the final electronic format. Examples include paper documents, whether hand-written or typewritten, and intermediate electronic forms, such as voice to text.
DocumentCompletion
LA legally authenticated
A completion status in which a document has been signed manually or electronically by the individual who is legally responsible for that document. This is the most mature state in the workflow progression.
DocumentCompletion
new new An Act that is in the preparatory stages and may not yet be acted upon. ActStatus
nullified nullified This Act instance was created in error and has been 'removed' and is treated as though it never existed. A record is retained for audit purposes only.
ActStatus
obsolete obsolete This Act instance has been replaced by a new instance. ActStatus
read read Fundamental operation in an Information System (IS) that results only in the flow of information about an object to a subject.
DataOperation
UC unsigned completed document
A completion status where the document is complete and there is no expectation that the document will be signed.
DocumentCompletion
update update Fundamental operation in an Information System (IS) that results only in the revision or alteration of an object.
DataOperation
ProvenanceActRelationshipDocumentHarmonization Proposal Decision 1
Does the DPROV Initiative approve forwarding these Proposals to CBCC for sponsorship in the HL7 July 2014 Harmonization Meeting?
ProvenanceEvent Value SetBusiness Need
• Required to meet Business Need to convey Lifecycle and Lifespan stage of an CDA Entry using ProvenanceOrganizer Template
• ProvenanceEvent Value Set would be used to populate Act.code
ProvenanceEvent CriteriaWhat’s needed are Act.codes that:• Represent a type of action on a target
Resource (e.g., CDA Entry, FHIR Resource, v2 or v3 message component)
– Which cause a Resource to change its Lifecycle or Lifespan stage
• Should cause creation of an auditable event, and meet the following criteria:
– Would likely have its own author, even if the author is the same as the one for the predecessor Resource
– Would not be simply an interim step or workflow “interruption” of the Resource moving from stage 1 to stage 2
• E.g., not a pend, suspend, pause, held etc.
29
Charter Consensus
• Congratulations!!!! we reached consensus on our first initiative milestone – The Project Charter– 7 total committed organization votes(we have a total
of 25 Committed Organizations)• 3 “Yes” votes• 4 “Yes with Comment” votes
– We will review the “Yes with Comments” votes on the actual Charter
• Thank you to everyone who helped us achieve our first of many successes!!!
ONC Standards and Interoperability (S&I) Framework LifecycleOur Missions» Promote a sustainable ecosystem that drives increasing interoperability and standards
adoption» Create a collaborative, coordinated, incremental standards process that is led by the industry
in solving real world problems» Leverage “government as a platform” – provide tools, coordination, and harmonization that
will support interested parties as they develop solutions to interoperability and standards adoption.
Tools and ServicesTools and Services
Use Case Development
and Functional Requirements
Use Case Development
and Functional Requirements
Standards DevelopmentSupport
Standards DevelopmentSupport
Certificationand TestingCertificationand Testing
Harmonization ofCore Concepts
Harmonization ofCore Concepts
Implementation Specifications
Implementation Specifications
Pilot Demonstration Projects
Pilot Demonstration Projects
Reference Implementation
Reference Implementation
Architecture Refinement and ManagementArchitecture Refinement and Management 31
32
S&I Framework Phases outlined for Data Provenance
Phase Planned Activities Pre-Discovery Development of Initiative Synopsis
Development of Initiative Charter Definition of Goals & Initiative Outcomes
Discovery Creation/Validation of Use Cases, User Stories & Functional Requirements Identification of interoperability gaps, barriers, obstacles and costs Review of Candidate Standards
Implementation Creation of aligned specification Documentation of relevant specifications and reference implementations
such as guides, design documents, etc. Development of testing tools and reference implementation tools
Pilot Validation of aligned specifications, testing tools, and reference implementation tools
Revision of documentation and toolsEvaluation Measurement of initiative success against goals and outcomes
Identification of best practices and lessons learned from pilots for wider scale deployment
Identification of hard and soft policy tools that could be considered for wider scale deployments
Use Case Development Objectives
• Engage Stakeholders as Committed Members, Invite Experts, or Interested Parties in the creation of a Use Case This is you all!
• Identify Scenarios and User Stories that address real-world problems
• Keep it simple
• Focus on the business and functional requirements: Focus on “what” the requirements should be rather than “how”
• Create a finalized Use Case that demonstrates value and supports the proposed goals and success criteria for the Initiative
• Publish a finalized Use Case that contains necessary content, supported by artifacts, to enable Harmonization and subsequent S&I Framework efforts to occur
33
•1.0 Preface and Introduction
•2.0 Initiative Overview– 2.1 Initiative Challenge Statement**
•3.0 Use Case Scope– 3.1 Background**– 3.2 In Scope– 3.2 Out of Scope– 3.3 Communities of Interest
(Stakeholders)**
•4.0 Value Statement**
•5.0 Use Case Assumptions
•6.0 Pre-Conditions
•7.0 Post Conditions
•8.0 Actors and Roles
•9.0 Use Case Diagram
Use Case OutlineTailored for each Initiative
•10.0 Scenario: Workflow– 10.1 User Story 1, 2, x, …– 10.2 Activity Diagram
o 10.2.1 Base Flowo 10.2.2 Alternate Flow (if needed)
– 10.3 Functional Requirementso 10.3.1 Information Interchange
Requirementso 10.3.2 System Requirements
– 10.4 Sequence Diagram
•11.0 Dataset Requirements
•12.0 Risks, Issues and Obstacles
•Appendices
– Related Use Cases– Previous Work Efforts– References
** Leverage content from Charter
34
Assumptions• Outlines what needs to be in place to meet or realize the requirements of the Use Case • These points are more functional in nature and state the broad overarching concepts
related to the Initiative• The Use Case assumptions will serve as a starting point for subsequent harmonization
activities
Pre Conditions• Describes the state of the system, from a technical perspective, that must be true before
an operation, process, activity or task can be executed• It lists what needs to be in place before executing the information exchange as described
by the Functional Requirements and Dataset requirements
Post Conditions• Describes the state of the system, from a technical perspective, that will result after the
execution of the operation, process activity or task
Review of Key Use Case SectionsAssumptions, Pre-conditions and Post-conditions
35
Review of Key Use Case SectionsUse Case Diagrams
• Conceptually represents the Business Actors interacting with the Use Case and the User Stories
• Provides a pictorial representation of the environment where the exchange takes place
• Characterizes the types of interactions that an actor has with a specific system
• Shows the association and interaction between the business actors and the Use Case
• It provides an overview of the actors (users or external systems) and the interactions between them
Example: Transitions of Care
36
Review of Key Use Case SectionsDefining the Actors
• This section of the Use Case outlines the business actors that are participants in the information exchange requirements for each scenario. A business actor is a person or organization that directly participates in a scenario.
• The business actor must use a system to perform the functions and to participate in the information interchange. The system or system actor has roles (send, receive, publish, subscribe or in some cases display) and actions which involve exchanging content. Please see the table below for an example of these designations.
Actor System Role
PCP EHR System Sender
Specialist EHR System Receiver
Patient PHR System Receiver
Example
37
Review of Key Use Case SectionsScenarios• The scenario is a comprehensive description of the actors, interactions, activities,
and requirements associated with the information exchange
• Scenarios pertain to supporting the health information exchange and describing key flows, and they are supplemented by User Stories
• Example: Specialist requests a patient’s Clinical Care Summary from Primary Care Provider (PCP)
Scenario 1
User Story 1 User Story 2
Scenario 2
User Story 1 User Story 2
38
Review of Key Use Case SectionsUser Story• User Stories describe the real world application as an example or instantiation of
the Scenario
• User Stories summarize the interaction between the actors of the Use Case, and specify what information is exchanged from a contextual perspective
• These interactions are further described in subsequent sections. Historically, user stories have been utilized to provide clinical context
• Example Scenario (from previous slide): Specialist requests a patient’s Clinical Care Summary from Primary Care Provider (PCP)
• Example User Story: A Specialist receives a referral and requires more information to treat the patient properly at the point of care. Using an EHR System, the Specialist sends a request to the PCP for the patient’s Clinical Care Summary. The PCP successfully receives the requests, understands the requests, and sends the patient’s Clinical Care Summary back to the Specialist via the EHR System. The Specialist successfully receives the patient information, understands it, and makes an informed decision that can provide better quality of care to the patient. 39
Review of Key Use Case SectionsActivity Diagram
• An Activity Diagram is a special form of a state transition diagram in which all or most of the states are activity states or action states
• The Activity Diagram illustrates the Use Case flows graphically, and represents the flow of events and information between the actors– It also displays the main events/actions
that are required for the data exchange and the role of each system in supporting the change
40
Review of Key Use Case SectionsFunctional Requirements
• Functional Requirements identify the capabilities a system in a role must have in order to enable interoperable exchange of the healthcare data of interest– They provide a detailed breakdown of the requirements in terms of the
intended functional behaviors of the application
• The Functional Requirements include:– Information Interchange Requirements– System Requirements
• The Information Interchange Requirements define the system’s name and role. They also specify the actions associated with the actual transport of content from the sending system to the receiving system
• System Requirements include the requirements internal to the system necessary to participate successfully in the transaction. System requirements may also detail a required workflow that is essential to the Use Case
41
• A Sequence Diagram is primarily used to show the interactions between objects in the sequential order that they occur– This representation can make it
easy to communicate how the exchange works by displaying how the different components interact
– The primary use of the diagram is in the transition from requirements expressed as use cases to the next and more formal level of refinement
• Note: Horizontal lines are used to identify the specific activity between the systems
Review of Key Use Case SectionsSequence Diagram
42
Dataset Requirements• Include the data elements and data element sets that will be available within the
message or document. Each data element included is necessary for some aspect of the Use Case; however, the requirements do not specify exactly how they may be used together. All data element sets may contain multiple data elements unless otherwise stated.
• The identification of data elements forms the foundation for harmonization activities. The data elements identified in the Use Case set constraints on the contents of documents and messages.
Issues Risks and Obstacles• Lists the concerns that might interfere with meeting the requirements of the Use
Case• Note: This list takes into consideration risks outlined in the Charter
Review of Key Use Case SectionsDataset Requirements & Issues, Risks & Obstacles
43
Week Target Date (2014) All Hands WG Meeting Tasks Review & Comments from Community via Wiki page
due following Tuesday by 8 P.M. Eastern
1 6/5 Use Case Kick-Off & UC Process OverviewIntroduce: In/Out of Scope & Assumptions Review: In/Out of Scope & Assumptions
2 6/12 Review: In/Out of Scope & AssumptionsIntroduce: Context Diagram & User Stories Review: Context Diagram & User Stories
3 6/19 Review: Context Diagram & User Stories Review: Continue Review of User Stories
4 6/26 Review: Finalize User StoriesIntroduce: Pre/Post Conditions Review: Pre/Post Conditions
5 7/3 Review: Pre/Post ConditionsIntroduce: Activity Diagram & Base Flow Review: Activity Diagram & Base Flow
6 7/10 Review: Activity Diagram & Base Flow Introduce: Functional Requirements & Sequence Diagram Review: Functional Requirements & Sequence Diagram
7 7/17 Review: Functional Requirements & Sequence Diagram Introduce: Data Requirements Review: Data Requirements
8 7/24 Review: Finalize Data RequirementsIntroduce: Risks & Issues Review: Risks & Issues
9 7/31 Review: Risks and IssuesBegin End-to-End Review End-to-End Review by community
10 8/7 End-to-End Comments Review & disposition End-to-End Review ends
11 8/14 Finalize End-to-End Review Comments & Begin Consensus Begin casting consensus vote
12 8/21 Consensus Vote* Conclude consensus voting
Proposed Use Case & Functional Requirements Development Timeline
45
In/Out Scope Items
46
In Scope
1. To identify and define guidance on use of standards to facilitate provenance capabilities by specifying the following: ***
1. Standards for the provenance (e.g. origin, source, custodian(s), FHIR resources, CDA, etc.)
2. Supportive standards (e.g. integrity, non-repudiation)3. Vocabulary standard metadata tags for data
provenance4. Variance in granularity to which data provenance can
be collected, the way it is encoded, and how that provenance is communicated to consuming systems
2. Define system requirements that allow applications to generate, persist and retrieve provenance data and maintain associations with the target record
3. Ensure sufficient granularity to support chain of custody
Out of Scope
1. Patient identity matching***2. Third party mechanisms for checking patient consent and the
relative merits of existing policies or regulations (such as privacy policies or jurisdictional considerations)***
3. Policy-based decisions (such as records management based policies on record retention)
4. Non-clinical data (such as environmental data)
*** Leveraged from Charter
Assumptions
47
1. Clinical information that already exists within the EHR system (without the use of the CDA artifact) is found at the level appropriate for the implementation
Draft Use Case Context Diagram
48
End Point (EHR)
True Source(EHR)
True Source(Lab)
Aggregator(EHR, HIE, other
systems)
True Source(Other)
49
A look ahead: Data Provenance Next Week
• June 9th , 2014 – Tiger Team (3-4 pm ET)• June 12th , 2014 – All Hands Community Meeting (2:30-
3:30)– Review In/Out Scope and Assumptions
50
Support Team and QuestionsPlease feel free to reach out to any member of the Data Provenance
Support Team:• Initiative Coordinator: Johnathan Coleman: [email protected] • OCPO Sponsor: Julie Chua: [email protected] • OST Sponsor: Mera Choi: [email protected]• Subject Matter Experts: Kathleen Conner: [email protected] and Bob
Yencha: [email protected] • Support Team:
– Project Management: Jamie Parker: [email protected] – Use Case Development: Presha Patel: [email protected]
and Ahsin Azim: [email protected] – Harmonization: Rita Torkzadeh: [email protected] – Standards Development Support: Amanda Nash:
[email protected] – Support: Lynette Elliott: [email protected]