INTEROPERABLE, COMPUTABLE CLINICAL CONTENT AND INTEGRATED KNOWLEDGE ENVIRONMENTS KNAR

Transcription

1 INTEROPERABLE, COMPUTABLE CLINICAL CONTENT AND INTEGRATED KNOWLEDGE ENVIRONMENTS KNARTWORK Preston Lee Chief Systems Architect, Biomedical Informatics College of Health Solutions, Arizona State University

2 JUST GIVE IT ME # TL;DR DOCKER RUN -IT -P 9000:80 P3000/KNARTWORK:LATEST OPEN # OR, Preston Lee

3 KNOWLEDGE AS COMPUTABLE CONTENT

4 BACKGROUND HL7 STUFF FHIR Clinical Reasoning FHIR Terminology CDS Knowledge Artifacts CIMI/CEM SMART-on-FHIR Many specifications and architectural trends not specific to HIT

5 FOREGROUND ENVISION A NOT-TOO-DISTANT FUTURE, WHERE.. Basic clinical knowledge authoring tools exist. Products emergent from both vendors and the clinical informatics community are commonly known and used for a small set of knowledge document types. Knowledge management systems have emerged. FHIR Clinical Reasoning, KNART, HeD, CDS Connect etc have inspired a new class of standards-based CMS providing artifact-aware repositories, workflow management, and event hooks. An ecosystem of knowledge compilers and runtimes is available. Projects like CQL Runner, CQL-to-ELM have evolved into CQL and non-cql expression and functional languages with corresponding toolchains.

6 AND, Clinical interfaces have production support for limited FHIR Clinical Reasoning resource/artifact types, such as FHIR questionnaires. They re developed: By clinical subject matter experts (SMEs). Using software with terminology awareness, compilation and debugging. Within a workflow and repository driven by a knowledge management system backend. Artifacts are run as executors on a backend runtime in production.

7 FURTHER, The realm of knowledge artifacts is expanding far beyond KNARTs, now loosely defined as a strongly typed, dynamic binding of: event handlers fulfilling specific functional purposes, logical clinical models needed to run those functions, and references to underlying terminologies and upper-level ontologies A knowledge execution runtime is now an obvious, critical sub-system of clinician-facing production HIT architecture.

8 PROBLEMS

9 TEXT IT D BE IMPOSSIBLE TO SCALE THIS AT <YOUR_EMPLOYER> Bazillions of structured documents/resources References to external terminologies, logic etc elsewhere authoritative Dynamic (runtime) binding of models/terms/service not available at compile time Implausibility of governing workflow through document specifications Provenance and licensing Tamper-proofing and secure access to disparate dependencies Regression testing, debugging and optimization for production deployment How do we test and debug these things without a 12-month QA window?

10 SOLUTION APPROACH TO CLINICAL KNOWLEDGE ENGINEERING LET S STEAL REPURPOSE A BUNCH OF SOFTWARE ENGINEERING CONCEPTS. Preston Lee

11 INTEGRATED DEVELOPMENT KNOWLEDGE ENVIRONMENT

12 TEXT AN IKE IS TO A KNOWLEDGE ENGINEER AS AN IDE IS TO A SOFTWARE ENGINEER Authoring: CRUD specific knowledge artifact resource types via individual artifact editors into authoritative backends such as FHIR, XML files etc. Compilation: 100% programatic transform of declarative artifacts into executable HSP services. Testing: At minimum, regression support for change control and validation in the context of the entire system. Integration: Leverage APIs, event topics etc via direct, programmatic integration and event propagation. Simulation: run and debug binaries locally. Governance: integrate into business processes, policies and accountabilities frameworks spanning all IT systems. Community: Sustainable as a integrated solution of community components.

13 TEXT EXAMPLE USE CASE: TO CREATE AN ECA ARTIFACT, A SME.. 1. Loads IKE UI and creates a new ECA rule for a logical module/namespace. 2. Sets metadata and defines ECA expressions using integrated editor and visualization. 3. Saves the draft artifact at the document level to underlying authorities, such as FHIR. 4. Uses integrated remote compilation and runtime environments to build and deploy the artifact to integrated server-side sandbox environment(s). 5. Launches additional SMART and non-smart tools from the sandbox in pre-defined synthetic clinician/patient contexts to test artifact behavior in a realistic multi-user environment. 6. Repeats the above process to debug and refine and artifact, resetting the sandbox state as needed and engaging collaborators if appropriate. 7. Changes artifact status when development is complete, triggering the knowledge management system to notify subscribed parties/systems.

14 TEXT PROCESS & GOVERNANCE Content, such as a artifact source and underlying FHIR resources, is mostly agnostic to development process. Type-specific artifact lifecycles may be modeled with CMMN, BPMN etc and implemented using traditional ticket tracking or BPM-based workflow engines, based on local policies and standards. Mainstream software development processes should be fine for collaborative development, but poorly suited for large numbers of distinct projects on disjoint schedules. The knowledge management system (KMS) is authoritative for the source artifact, governance activities, and implementation of development methodology. detects the change in KX status, and notifies parties authoritative to author HIT environments.

15 TEXT KNARTWORK IS AN IKE TEASER ~67.29% implementation of HL7 CDS Knowledge Artifacts v1.2. Extremely snappy and 100% web native. All desktops and tablets. Execution is on the backend. Future plug-ability to: fully support Clinical Reasoning etc backends look and feel more like an IDE provide import/export/transforms across standards integrate FHIR Terminology natively add run-time support when online add SCM team stuff (source repos, issue tracking, CI etc)

16

17

18

19

20

21

22 TEXT LINKS