Data Provenance Tiger Team July 14, 2014 Johnathan Coleman Johnathan Coleman – CBCC Co-chair/ S&I Initiative Coordinator Lynette ElliottLynette Elliott – Tiger Team Support Bob Yencha Bob Yencha – Subject Matter Expert Ioana Singureanu Ioana Singureanu – Modeling Facilitator Kathleen Connor Kathleen Connor – Subject Matter Expert Neelima ChennamarajaNeelima Chennamaraja - Modeling Facilitator

IG Production Most current document is always avail: – FrsReleaseBrowse&frs_package_id=240 FrsReleaseBrowse&frs_package_id=240 Call for content contributors to the ballot document – Can be supplied as bullet points for each section in the ToC in draft IG – Please review the posted document and provide feedback and comments

Authoring Scenarios A.Provider/Patient Authored Document with & without Externally Sourced Sections and Entries composed by ASSEMBLER B.Device authored document with & without Externally Sourced Sections and Entries composed by ASSEMBLER C.HIE-scoped Document Author [Person & Device not specified] with ASSEMBLER composing Document – All contents are externally sourced composed by other authors and/or ASSEMBLERs

The Star and Swoosh, Putting the I in Health IT, the Putting the I in Health IT composite logo, HealthIT.gov, the HealthIT.gov composition logo, HealthITBuzz, and the HealthITBuzz composite logo are service marks or registered service marks of the U.S. Department of Health and Human Services. Office of the National Coordinator for Health Information Technology 4 Entry/Observation Section Header author informant authenticator provider organization device provider organization device provider Represented organization legal Authenticator provider Represented organization author informant provider organization device provider organization device author informant provider organization device provider organization device Context Conduction and Inheritance

Scenario A Constraints Provider* authored document 1.If Author is different at Section and/or Entry (from header), the Section and/or Entry Author playing Entity SHALL be a Person or Device(?) Entity 2.Assigned Author scoping Organization SHALL SHOULD be populated at the Document, Section, and Entry level 1.Include use cases from Lisa N, Bob D in IG narrative 3.If a Person (provider or patient) Author used an ASSEMBLER to compose the Document or Entry – Stopped here 6/30 with proposal that all following constraints should be SHALL – At Headers, ParticipantType = ParticipantType SHALL be DEV, ParticipationFunction SHALL be ASSEMBLER – At the Entry, ParticipantType SHALL be DEV, ParticipationFunction SHALL be ASSEMBLER, Entity SHALL be Device. – At Header and Entry, Scoping Entity SHALL be the ORG scoping the ASSEMBLER – which is likely the Provider Author Org, but could be a Cloud based EHR like Practice Fusion or athenahealth. * “provider” broadly defined to include payers, PH agencies, etc., i.e., everyone who has a role in the care and treatment of patients that is provided under the auspices of an organization vs. the patient who may have no scoping organization.

Scenario A Decision: two templates – one for patient and separate for provider or use ano approach, e.g., LOINC doctype codes, to distinguish (branch) requirements – E.g., All provider (and assembler) documents SHALL have scoping org, patient MAY have scoping org Consensus – pursue 2 template approach 6

Scenario B Constraints Document Device Author [NOT ASSEMBLER] Document Assigned Author playing Entity SHALL be populated with Device Entity If Device Author is different at Section and/or Entry, the Section and/or Entry Author playing Entity SHALL be a Device Entity Assigned Device Author scoping Organization SHALL [SHOULD?] be populated at the Document, Section, and Entry level The above bullets apply to a Document that is generated by one or more Authoring Devices, which are authors of new information There are use cases where a Document has Device Author generating new information in a Document that also includes Sections/Entries authored by a Provider and/or composed by an ASSEMBLER

Scenario B – [continued] Document Device Author [NOT ASSEMBLER] It's possible for a Device to Author a CDA by: Generating new information Adding information authored by other devices or other person Using an ASSEMBLER to compose the information generated by other devices or person authors. An emerging use case we haven’t really explored are the functions performed by Health APPs, e.g., APP A is Document Device Author. APP A measures and reports on heart rate during exercise APP A uses ASSEMBLER to compile heart rate measures with information from APP B APP B measures daily weight and calculates BMI. APP A also uses ASSEMBLER to compile Person Authored information – e.g., a Physical Therapist authored Observation, Procedure, and Encounter Entries into the APP A Authored Document. Thus Document Device Author may only include information it generated or it may include information from other Device Authors and Person Authors.

Scenario C Constraints HIE Uses ASSEMBLER – Author NULL Assigned Author Role SHALL be present and playing Person Entity MAY be NULL – Assigned Author Entity SHALL NOT be Device Entity – Modeling Question: Do we need to constrain the # of Assigned Author Roles? I’m not sure what having multiple Assigned Authors at the Document Level even means? Assigned Author scoping Organization SHALL be populated at the Document Level – Typically the HIE If there is an Author at Section Level: – Assigned Author SHALL be populated – Section Author playing Entity SHALL be one of the following: Person Entity with optional Scoping non-HIE Org Device Entity with optional Scoping non-HIE Org If there is an Author at Entry Level : – Assigned Author SHALL be populated – Entry Author playing Entity SHALL be one of the following: Person Entity with optional Scoping non-HIE Org Device Entity with optional Scoping non-HIE Org [For HIE ASSEMBLER] – Optional Person Entity or NULL with mandatory Scoping HIE Org – Participant SHALL be Populated as DEV ParticipationType with participationFunction = ASSEMBLER

Data Provenance Tiger Team Next Steps Monitor wiki for updated draft based on todays work – Please use the comment capture form on the wiki Requests for community input – Submit any potential requirement not previously discussed or included in draft IG for discussion on next meeting on the wiki Requirements page – Identify any other candidate source IGs for review Next Meeting – Monday, July 3:00PM ET 10

Questions? 11

Data Provenance Tiger Team Background Slides The following slides are included as references and for quick access when/if needed

CDA R2 Definitions – authenticator – Represents a participant who has attested to the accuracy of the document, but who does not have privileges to legally authenticate the document. An example would be a resident physician who sees a patient and dictates a note, then later signs it – legalAuthenticator – Represents a participant who has legally authenticated the document. 13

CDA R2 Definitions – custodian – Represents the organization that is in charge of maintaining the document. The custodian is the steward that is entrusted with the care of the document. Every CDA document has exactly one custodian. 14

CDA R2 Definitions – informant – An informant (or source of information) is a person that provides relevant information, such as the parent of a comatose patient who describes the patient's behavior prior to the onset of coma. 15

Parking lot Document the authoring definitions and capture rationale in IG, verify assumptions How to constrain/test a document with an assembler participant, ensure that actual authors are present on entries (prevent false conduction) 16