Data Provenance Tiger Team

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

2. IG Production • Most current document is always avail: • http://gforge.hl7.org/gf/project/cbcc/frs/?action=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

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

4. Context Conduction and Inheritance provider author organization provider device Header informant organization device authenticator provider Representedorganization legalAuthenticator provider Representedorganization provider Section author organization provider device informant organization device provider author organization provider Entry/Observation device informant organization device

5. Scenario A ConstraintsProvider* authored document • 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 • Assigned Author scoping Organization SHALLSHOULDbe populated at the Document, Section, and Entry level • Include use cases from Lisa N, Bob D in IG narrative • 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.

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

7. Scenario B ConstraintsDocument 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

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

9. Scenario C ConstraintsHIE 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

10. Data Provenance Tiger TeamNext 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 7 @ 3:00PM ET

11. Questions?

12. Data Provenance Tiger TeamBackground Slides The following slides are included as references and for quick access when/if needed

13. CDA R2 Definitions • 4.2.2.1 – 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. • 4.2.2.8 – legalAuthenticator • Represents a participant who has legally authenticated the document.

14. CDA R2 Definitions • 4.2.2.3 – 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.

15. CDA R2 Definitions • 4.2.2.6 – 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.

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