...
- Basic Terminology Authoring
- Enable Readiness Assessments
- Publish foundational knowledge content
- Specify core platform elements
Milestone | Facilitator | Overview | Project(s) | Stewardship | Status | Start date | End Date | Deliverable Indicating Achievement of Milestone | |
---|---|---|---|---|---|---|---|---|---|
Data/Information Models | |||||||||
Priority Terminology Mgmt Environment | Campbell, Matney | Terminology management is a critical enabler and the foundation upon which information semantics are specified and modeled – a capability that will be used by many other milestones and in support of multiple use cases with dependencies on terminology. This milestone will enable the core of terminology management capability, including support for SOLOR, LOINC, SNOMED, and RxNORM and access to value sets in addition to providing SNOMED/LOINC integration. | Termspace? | ||||||
CIMI Reference Model | Huff | CIMI Model Development Pipeline Model Versioning and Governance | HL7 CIMI | ||||||
CIMI Archetypes for Select Domains | Matney | Project based - .... ACOG/ OPA FPAR 2.0 Skin Wound Assessment Common Labs Vital Signs | Logica | ||||||
Data Model API Spec and Conformance Profiles |
Huff? Nanjo? | |||||||||
Create Logica FHIR Profile for select domains | Matney, N. Davis, Kramer | Clinical information models are a foundational product of Logica. Clinical Information Models, in the form of Logica CIMI Models and FHIR profiles, are a collection of definitions that together define a specification for the appropriate set of attributes for specific clinical events, actions and phenomena. Models define the structures, fields, data-types and values required for specific clinical situations such as observations, procedures, and orders. Models allow for robust information sharing. Specific requirements supported by this milestone include: - Creation of sharable HSPC/ FHIR profiles for reading data - Creation of sharable Logica FHIR profiles for writing data - Sharable Logica FHIR profile for supporting a publish/ subscribe environment | Logica | ||||||
Process Knowledge | |||||||||
HL7 CDS |
Knowledge Artifact Specification-for Select Domains | 1, Intermountain 2. Mitre, Penrad 3. ACOG 4. HL7 |
2. Cancer Interoperability 3. FPAR 4. KNART NICU Pilot CIMI Transformation | |||||||
Shareable medical Knowledge models - BPM- Select Domains | Haug Lario | BPM Health Community (OMG) | OMG | ||||||
Develop Knowledge Authoring Metamodel - V1 | Haug and TBD | A general environment that supports the use of models in clinical applications, this will be a part of the tooling allowing developers to specify and configure models of data, events, orders, etc. within their applications. The authoring environment will: | |||||||
CQL | |||||||||
Business | Laura to contact Aneel | ||||||||
Draft of Interop Maturity Model | Logica will provide an interoperability and SOA standards maturity model for enterprises to benchmark their evolution of full interoperability and SOA service capabilities. | Conformance and Certification Principles Determine what needs to be certified as HSPC Conformant Determine how HSPC will state something is HSPC conformant | |||||||
Publish Strategy for Coordination with external stakeholders | Develop a coordinated strategy for the Logica organization to engage with health system and standard org in the development and adoption of the HSPC interoperability roadmap and maturity model. | Marketplace Resource Advertisement Marketplace Marketing | |||||||
CDS and Workflow/BPM Adoption Strategy and Implementation Guide | Logica will provide an enterprise adoption strategy and implementation guide for Clinical Decision Support SOA services incorporating the HSPC-recommended technical infrastructure, knowledge model and content, cybersecurity, and SOA governance standards | ||||||||
Standards Adoption Policy and Draft |
Logica License | Diaz, Lee, Huff | Logica will provide a governance strategy, IP issues analysis, and license recommendation for the open standards addressing roles for the HSPC constituency (members, adopters, technical contributors), includes sustainable adoption strategy for enterprises. | |||||||
Data Services Governance and Models | Logica will provide an enterprise adoption strategy and implementation guide for Clinical Decision Support SOA services incorporating the HSPC-recommended technical infrastructure, knowledge model and content, cybersecurity, and SOA governance standards HSPC will provide an enterprise readiness strategy and implementation guide. | Tooling
| |||||||
Security | Mike Davis | ||||||||
Baseline (Security) Capabilities | Baseline services necessary prior to the implementation of new and improved capabilities Services and capabilities assumed at the beginning, to include:
| ||||||||
Data Segmentation | Technical mechanism for analyzing structured and unstructured data and applying labels according to flexible security and privacy rules. Identify, mark, and segment healthcare information at an appropriate granular level of functionality according to organizational and patient policy/rules. This provides a key enabling capability. | ||||||||
Patient Choice/Consent | This milestone merges concepts of electronic patient consent, and choice (individual control of their own information as provided by law). This typically involves “authorizations” (approvals and/or directions to share and “restrictions” (patient policy restricting access to certain information to authorized persons organizations.). It also includes “Directions” to healthcare organizations to transmit a copy of their own information to destinations of their choice under patient right of access law. Electronic patient permissions regarding disclosure of their own protected health information. | ||||||||
Infrastructure | |||||||||
Terminology Sever Availability | Lee, Freeman, Narus |
| HSPC |
| |||||
SMART Sandbox (Note: rename "Developer's Sandbox") | Freeman, Narus | Multiple
| HSPC | In production; enhancements in progress | |||||
Model Repository | Parker, P. Langford | ||||||||
Marketplace General Availability | Lee | Architectural Principles Platform Reference Architecture Workstream Build Marketplace Infrastructure | |||||||
Terminology Authoring - Purchased SW in use | Campbell, Matney |
| |||||||
Software | |||||||||
Marketplace API Specification | Lee, Freeman | The Marketplace is where developers of information assets can make their products available to others in the health community, and where customers can browse, find and access/download these assets. The API Specification describes how developers and customers can access the Marketplace. Note that there may actually be more than one physical/virtual Marketplace, but a single API specification would help developers and customers to access any Marketplace in a common way. | Healthcare Community Cloud Marketplace Community Implementation Vendor and Provider Neutral Marketplace Requirements | ||||||
CDS Hooks Support | Freeman, Narus | CDS Hooks is a newer specification, now under HL7 oversight, for allowing CDS services to be called from an HIT application (e.g., EHR) using a standard API and triggering events. Support for CDS Hooks within the Platform is a first step towards a more general capability to support decision support logic in an open, standards-based environment. Software Deliverable. Phase I. Dependencies on Development Environment Initiative and its resources, CDS Hooks leadership and resource support. | 4 projects w/ CDS Hooks website support |
Logica, CDS Hooks | 3 projects completed; 1 in progress | ||||
Terminology Svcs API | Freeman, Narus (Lee?) | In order to be truly interoperable, data will need to be transformed from a source terminology (standard or proprietary) to a secondary terminology. Applications, including decision support services, will also need to access terminology in order to resolve terms, domains, and term relationships. Translations may also be needed for terminology within knowledge assets. The Terminology Services API will provide open, standards-based methods for handling these terminology functions at run-time. |
|
Logica |
| ||||||||
Knowledge Repository Specification |
2. TBD | A Knowledge Repository (KR) is necessary in the Platform in order to contain and share knowledge artifacts. The KR Specification outlines the functions that a KR needs to support, including artifact storage capabilities, metadata requirements, artifact access services, and governance policies. |
2. governance policies. see Roadmap section... | HL7, VA | 1. Investigation | ||||