Composite KNART 20170629

Return to Clinical Decision Support Work Group

Return to Project Page

Agenda

1. Roll Call
2. Agenda Review
3. Housekeeping
   • Resources listserv created - knart@lists.hl7.org
   • Ways of Work
     1. Assign sub-tasks to individuals / small groups
     2. Feedback and review from this group
     3. Periodic updates / feedback requests from sponsors
     4. Final deliverable - recommendation paper submitted to sponsors
4. Discussion topics
   • Relationship between HL7 KNART and other Knowledge Artifacts
   • STAMP (Status, Time, Author, Module, Path)
     • request for contributor to assist with more info
   • Organizing into work tracks
     1. Clinical
        • Core Clinical use cases & goals
        • Known issues with the existing specification
        • ...
     2. Management, Administration and Governance
        • Metadata and Provenance
        • Goverance
        • Lifecycle Management
        • Core use cases & goals
        • ...
     3. Technical
        • Expression Language
        • Representations (FHIR, current XML...)
        • Artifact Types
        • Composition
        • References
        • Packaging
        • Core use cases and goals
        • ...
5. Next Call

Notes

1. Attendance: Emory Fry, Jerry Goodnough, Steve Hasley, Richard Esmond, Lorraine Constable, Davide Sottara, Claude Nanjo, Bruce Bray, Stephanie Klepacki, Bryn Rhodes, Frank Breyette
2. Listserv created knart@lists.hl7.org
3. Discussion topics
   • Relationship of HL7 KNARTS with other knowledge artifiacts
     • a knowledge artifact is a representation of domain knowledge that is Emory - can you complete the comment?

HL7 finds 3 specific definitional kinds of domain structures in HeD - document templates, order sets and ECA rules What other higher conceptual understanding of a knowledge artifact exists that might supercede or expand on these concepts

Current spec defines a common ancestor from HeD domain and includes other artifacts that include libraries and value sets/ vocabulary Davide: Emory nailed it when he said domain knowledge and specifically chunks of domain knowledge and policy that can be shared. Aggregates domain information and policy that can be communicated and needs a language expressive enough to share. Once we have the grammar, we can create a document / artifact that can carry the expression of that knowledge - can carry one or more, if more then composite Distinction between 3 layers : Knowledge track 1 - what are we trying to express clinically. Languages - HeD is one possible expression . HeD ECA rules are one way, and there are several different ways to express rules. Question - are there expression requirements that we need to express that are not expressible in current ECA that can be filled by other languages. 3 layer document - artifact package vocabulary, knowledge, metadata, etc. So in effect, existing HeD spec currently has composite artifacts. Very static and restrictive in current combinations, but in a way HeD artifact is a composite of the knowledge and the metadata. We called them self describing artifacts as they have there own metadata.

1. • • discuss the external world or the items that HeD KNART currently does not express explicitly. Emory: in his clinical world, knowledge is often sequenced with temporal relationship; either full clinical pathway / guidelines, or temporal constraint on individual rules is largely a matter of convenience. Critical item is ability to express temporal semantics in clinical workflow. Davide: process semantics including human and automated - distinguished between Cognitive and Computation semantics.. Process languages such as BPMN and CMN come into play. Application of knowledge even when not orchestrated still interact there is still a choreography Question on distinction 1- temporal sequencing of activities. Flow of actions overtime. Within a single action have a flow of information - process of info by knowledge may be done by computer/person or both. Was using cognitive to address information flow in human. Davide wants to distinguish between flows of information and flows of activity. Emory-they get conflated because we don't think of how our human workflow is affected by computational steps . The term "art of medicine" is a bandaid over processes we have not yet decomposed. We don't often understand / surface the knowledge process that is applied, so is glossed over as art. Davide: what we call processes are fully analyzed, specified actions. The art of medicine is planned as the clinician deals with the situation - still applying structured principles as they adapt to the situation. Emory: the way those principles are applied is based on science - using data sources that have not been predefined or declared and are being adapted to the individual situation. The adaptation is the art, but is scientifically based.

Steve: once you have diagnosed, what is the workflow so we ensure that we have safe, appropriate standards of care. This second part of the activity lends itself more to structured knowledge artifacts encapsulating clinical protocols. Emory: conversation that crystallized for him as a clinician concept of why current applications that attempt to orchestrate clinical process flow have met with resitence. Brings in the notion of degrees of freedom: current application of workflow engines optimized for declaring acceptable paths through a problem space up front. Issue for clinicians, is that rarely are all known accentual paths for orchestrating a treatment or acceptable paths. yes there are ways of describing process flow, but at what point is the knowledge really declared enough and specific enough that is an acceptable way of expressing it. As the degrees of freedom increase, it becomes less acceptable to try to capture process flow that captures all the pathways Jerry - process flow work going on at OMG Today, Knart does not have a way to call out and compose. As it stands today, could be exposed by some external framework. Davide - one language to express them all, or do we make the forms of expressions adaptable to refinements over time. Even if knart of today are meant to express ECA rules of the time. HeD had for good or bad a preliminary expression of workflow in the action group that sequences actions with splits and joins. Small chunk of process semantics already in Knart. Should we use /improve / deprecate. With Brynn going thru the path of expanding on that - the FHIR plan definition tries to cover everything Jerry - notion of leaf node, and what is the role of the composite - is it a packaging and relationship mechanism bundled for governance, etc. Davide - understand the domain and process semantics of each artifact. translate between representations. Jerry - some knowledge artifacts capture explicitly the relationship. Davide whenever we have composite, we have the individual elements and the frame - that frame is a knowledge artifact on its own. Jerry - does it make sense to split the work between how we defined the composite and how we express that / and does it make sense to look at the existing mechanisms both HeD and FHIR to ensure they can be composed and reference compositions Emory - current is highly declarative - do we expand on this or factor out process semantics. Davide - Is knart expressive enough for our needs? If so, at some point one will not be enough, I will need to bring together more than one. Those components that exist individually as karts or other languages need to be brought together - is this composite a knowledge artifact on its own, and do we need knart to be able to express this composite Bruce bray - take a use case - to identify the well identified components - explore how we take the specific knowledge artifacts and how they can be used in specific process flows such as BPMN Bryn - looking thru schemas for update 3 of KA spec - notion of referencing but no notion of packaging, so would need extension to handle that. FHIR ka have the notion of composition - there is a library artifact that represents an asset collection. Look at that to see if there are gaps Emory: pss has two goals - look at the requirements from the VA for composing document templates, order sets for the purpose of handling workflow for consult request. The other requirement in the PSS - how does that meet with the work going on in the activity resource, and the OMG knowledge work - how do those efforts relate. Is the activity resource a platform specific representation of what KAS should represent as a conceptual model of which Avoid creating two conceptual models of the problem space. the intent is to be consistent with the conceptual knowledge artifact specification. there are updates that would need to be added back to KAS. Emory - that is part of where we need to go here. If there is a desire to have two implementation representations of the same conceptual model - one based on FHIR resources and a non-FHIR representation, then is one of the issues that we need a model to drive consistency Claude - need to define a logical model for knowledge artifacts that can drive the work between FHIR and HeD, which is why they relaxed the constraint in CIMI so that we can represent the logical representation of a knowledge artifact. should we take this info and build a CIMI model Davide - notion of a composite knart is partly bundling, partly explicit referrals, also about the ability to assemble artifacts that were not designed from day 0 to be brought together, we should be able to tie them together in an explicit way. Emory - we are explicitly looking at how to de-duplicate when combining artifacts.