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

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

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

Headerauthor

informant

authenticator

providerorganization

device

providerorganization

device

providerRepresentedorganization

legalAuthenticator provider

Representedorganization

author

informantprovider

organization

device

providerorganization

device

author

informantprovider

organization

device

providerorganization

device

Context Conduction and Inheritance

Scenario A ConstraintsProvider* 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 narrative3. 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

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

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

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)