400 likes | 483 Views
July DPROV Draft Harmonization Proposals. “ ProvenanceActRelationshipDocument” value set [Slide 7] ProvenanceActRelationshipEntryRelationship value set [Slide 13] v:ProvenanceActRelationshipExternalReference [Slide 17] REVIEWER ParticipationFunction.
E N D
July DPROV Draft Harmonization Proposals • “ProvenanceActRelationshipDocument” value set [Slide 7] • ProvenanceActRelationshipEntryRelationship value set [Slide 13] • v:ProvenanceActRelationshipExternalReference [Slide 17] • REVIEWER ParticipationFunction
Which x_ActRelationshipDocumentpTypecodes to use a Gap Fix proposals New Provenance Chaining Rules? Header - relatedDocument ActRelationship
ParentDocument Relationships The ParentDocument represents the source of a document revision, addenda, or transformation. ParentDocument.text is modeled as an ED data type - allowing for the expression of the MIME type of the parent document. It is not to be used to embed the related document, and thus ParentDocument.text.BIN is precluded from use. Allowable values for the intervening relatedDocument.typeCode are shown in the following table. Value set for relatedDocument.typeCode (CNE)
Allowable Combinations of ParentDocument Relationships A conformant CDA document can have a single relatedDocument with typeCode "APND"; a single relatedDocument with typeCode "RPLC"; a single relatedDocument with typeCode "XFRM"; a combination of two relatedDocuments with typeCodes "XFRM" and "RPLC"; or a combination of two relatedDocuments with typeCodes "XFRM" and "APND". No other combinations are allowed
Header relatedDocumentProposed Extension to x_ActRelationshipDocument Propose Value Set Extensions for 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 • PART [has part] - The source Act is a composite of the target Acts. The target Acts do not have an existence independent of the source Act. • Usage Note: In UML 1.1, this is a "composition" defined as: "A form of aggregation with strong ownership and coincident lifetime as part of the whole. Parts with non-fixed multiplicity may be created after the composite itself, but once created they live and die with it (i.e., they share lifetimes). Such parts can also be explicitly removed before the death of the composite. Composition may be recursive.” • XCRPT [excerpts] The source is an excerpt from the target
ProvenanceActRelationshipDocumentHarmonization Proposal Decision 1 Does the DPROV TT approve submission of: • 3 existing codes to be added to existing x_ActRelationshipDocument value set named “ProvenanceActRelationshipDocument” value set • COMP • PART • XCRPT
Which x_ActRelationshipEntryRelationshipType codes to use a Gap Fix proposals EntryRelationship
x_ActRelationshipEntryRelationshipCurrent in CDA at Entry Level – GAPS? • COMP can be used to indicate non-specific aggregation or composition relationship • SAS could indicate succession at in Lifecycle – but would SUCC be better? • 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 Entry GAP • SUCC – Succeed • UPDT – Update • USE - Uses
Other ActRelationshipsSUCC LEAF CONCEPT: SUCC (succeeds) KC – Seems like best fit for AR from Last ProvenanceEvent to preceding for LifeCycle – would require extension of the x_ActRelationshipEntryRelationship value set – in a new one for DPROV EntryRelationship Description: Definition: A new act that carries forward the intention of the original act, but does not completely replace it. The status of the predecessor act must be 'completed'. The original act is the target act and the successor is the source act.
Other ActRelationships Of InterestUPDT LEAF CONCEPT: UPDT(updates (condition)) KC – Could be used for LS/LC would require extension of the x_ActRelationshipEntryRelationship value set – in a new one for DPROV EntryRelationship Description: A condition thread relationship specifically links condition nodes together to form a condition thread. The source is the new condition node and the target links to the most recent node of the existing condition thread.
Other ActRelationships Of InterestUSE LEAF CONCEPT: USE (uses) KC – Could be the AR from Entry Act to its Provenance Organizer • Description: Indicates that the source act makes use of (or will make use of) the information content of the target act. • UsageNotes: A usage relationship only makes sense if the target act is authored and occurs independently of the source act. Otherwise a simpler relationship such as COMP would be appropriate.
ProvenanceActRelationshipEntryRelationshipHarmonization Proposal Decision 2 Does the DPROV TT approve submission of: • 3 existing ActRelationship Codes to new ProvenanceActRelationshipEntryRelationship value set? • SUCC • UPDT • USES
Which AR codes to use and Gap Fix proposals External Reference
Proposed ActRelationship Type for new v: ProvenanceActRelationshipExternalReference
v:ProvenanceActRelationshipExternalReferenceHarmonization Proposal Decision 3 • Does the DPROV TT approve submission of two children specializing XCRPT for addition to new v:ProvenanceActRelationshipExternalReference?
RIM BackgroundReference ActRelationship 4.3.8.5 • CDA entries can reference external objects such as external images and prior reports. These external objects are not part of the authenticated document content. They contain sufficient attributes to enable an explicit reference rather than duplicating the entire referenced object. The CDA entry that wraps the external reference can be used to encode the specific portions of the external reference that are addressed in the narrative block. • Each object allows for an identifier and a code, and contains the RIM Act.text attribute, which can be used to store the URL and MIME type of the object. External objects always have a fixed moodCode of "EVN". • The reference class contains the attribute reference.seperatableInd, which indicates whether or not the source is intended to be interpreted independently of the target. The indicator cannot prevent an individual or application from separating the source and target, but indicates the author's desire and willingness to attest to the content of the source if separated from the target. Typically, where seperatableInd is "false", the exchanged package should include the target of the reference so that the recipient can render it. • A description of allowable reference.typeCode values are shown in the following table. As in the table above (CDA entryRelationship Types), the following table is a guideline for reasonable relationships between CDA entries and external objects, and is not a conformance constraint.
ParticipationFunction for Verifier ParticipantType Code REVIEWER
ParticipationFunction Harmonization Proposal REVIEWER – Business Requirement • esMD requested a new ParticipationType REVIEWER • Request was declined because ParticipationType is fixed in CDA as a structural code • May be possible to extend CDA ParticipationType value set to include Reviewer as US Realm or for CDA R 2.1 • Propose Harmonization Request to add as ParticipationFunction as interim alternative despite RIM semantic limitations
RIM Participation.functionCode Participation.functionCode :: CD (0..1) Property conformance: U Concept domain: ParticipationFunction Definition: Additional detail about the function that the Participation has in the Act, if such detail is not implied by the Participation.typeCode. Usage Constraint: No HL7 standard specification may be written to depend on the functionCode. When such a constraint is deemed necessary, it is to be defined in the Participation.typeCode. UsageNotes: This code can accommodate a variety of functions greater than that which can be managed in the tightly controlled typeCode. The numbers and kinds of functions applicable depend on the specific kind of act, e.g., each operation may require a different number of assistant surgeons or nurses. Since Participation functions refer to what people do in an Act, they are effectively sub-activities that may all occur in parallel. If more detail needs to be captured about these activities than who does them, component acts should be used instead.
ParticipationFunction Harmonization Proposal REVIEWER - Recommendation May add fine detail with ParticipationFunction • However, no way to test conformance and receiver can ignore while maintaining Recommendation: • Add new REVIEWER ParticipationFunction • Usage Note to indicate that REVIEWER is to be used with the ParticipationType = VERIFER
ParticipationTypeVRF (verifier) REVIEWER adds specificity to VRF without connoting attestation SPECIALIZABLE CONCEPT:VRF (verifier) Description: A person who verifies the correctness and appropriateness of the service (plan, order, event, etc.) and hence takes on accountability.
ReviewerProposed Definition Proposed REVIEWER Description: • 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 • Need TT to add more specificity to definition • Usage Note: • Used to more fully specify the VERIFER ParticipationType
REVIEWERPlace in HL7 ParticipationFunction Hierarchy ABSTRACT CONCEPT: _AuthorizedParticipationFunction [abstract term] • Description: • <p>This code is used to specify the exact function an actor is authorized to have in a service in all necessary detail.</p> • Concept Properties: • internalId: 22338Concept Relationships: • Generalizes (derived): _AuthorizedReceiverParticipationFunction • Generalizes (derived): _ConsenterParticipationFunction • Generalizes (derived): _OverriderParticipationFunction • Generalizes (derived): _AuthorizedProvenanceParticipationFunction • REVIEWER • ASSEMBLER
REVIEWER ParticipationFunctionHarmonization Proposal Decision Does the DPROV TT approve submission of: • REVIEWER ParticipationFunction • Constrained to use with VRF [verifier] ParticipationType (not necessary) • Defined as: A device that operates on custodian’s algorithms for data extraction for purpose of generating an artifact.
New ParticipationType/ParticipationFunction?ASSEMBLER [assembly software] • Business Need – convey Assembling Software that was used to generate Document or Entry • Could propose ASSEMBLER as new ParticipationType code but this would be an extension. Similar to Reviewer issue. • 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 SPECIALIZABLE CONCEPT: 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 ASSEMBLER Definition: A device that operates on custodian’s algorithms for data extraction of existing information for purpose of generating a new artifact.
New ParticipationFunctionASSEMBLER [assembly software] Could make ParticipationFunction to SPECIALIZABLE CONCEPT: 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.
ASSEMBLER [assembly software]Use as Provenance Actor on Entry
ASSEMBLER [assembly software]Use as Provenance Actor on Header
ASSEMBLER Place in HL7 ParticipationFunction Hierarchy ABSTRACT CONCEPT: _AuthorizedParticipationFunction [abstract term] • Description: This code is used to specify the exact function an actor is authorized to have in a service in all necessary detail.Concept Relationships: • Generalizes (derived): _AuthorizedReceiverParticipationFunctionGeneralizes (derived): _ConsenterParticipationFunctionGeneralizes (derived): _OverriderParticipationFunction • _AuthorizedProvenanceParticipationFunction • REVIEWER • ASSEMBLER
Assembler ParticipationFunctionHarmonization Proposal Decision Does the DPROV TT approve submission of: • Assembler ParticipationFunction • Constrained to use with Device ParticipationType (not necessary) • Defined as A device that operates on custodian’s algorithms for data extraction for purpose of generating an artifact.
ActCodes for ProvenanceEventActs Provenance Event CodEs
ProvenanceEventCodesBusiness Need A ProvenanceEventAct convey an Entry Lifecycle Event • [1…*] ProvenanceEvents comprise a ProvenanceOrganizer • ProvenanceEvent has ProvenanceEvent Act.code, which conveys the type of Lifecycle event • Has effectiveTime [1…1], which conveys temporal relationship among ProvenanceEvents • ProvenanceEvents ordered by ActRelationship SAS [starts after start of] with optional Sequence # to explicitly sequence Lifecycle ProvenanceEvents • ActRelationshipExternalReference convey limited association with Lifespan ProvenanceEvents of Predecessor ExternalActs – e.g., an Entry Lifecycle Event “update” may reference an External Act that this Entry “replaces” • Propose to Harmonization an extended ActRelationshipProvenanceExternalReference value set that includes relevant provenance relationships for future use
ProvenanceEvent value setUses ActStatus and DataOperations • Only some ActStatus and DataOperations Codes relate to Lifecycle or Lifespan Provenance • Others are related only to Workflow
ProvenanceEvent value set Description ProvenanceEvent value set described as codes that convey types of Lifecycle or Lifespan event Usage Note: Conveys the change that a system event causes to a resource which entails an additional stage in the resource’s lifespan or lifecycle.
ProvenanceEvent value setHarmonization Proposal Does the DPROV TT approve submission of the ProvenanceEvent value set listed in preceding Slide?