Phase 1

GOALS:

Basic Terminology Authoring
Enable Readiness Assessments
Publish foundational knowledge content
Specify core platform elements

Milestone	Facilitator	Overview	Project(s)	Stewardship	Status
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		Lab, VS, PE 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: - Allow for the creation of new models in a variety of knowledge areas - Support different types of users - Support the full artifact lifecycle governance
			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 Model Development Model Request Model Transformation

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: Identity: establish means to classify discrete users. Authentication: Verifying users are who they say they are. Authorization: Confirm users are supposed to have access to the resources requested Audit: Record user access to resources and for what purposes. Confidentiality: Prevent unauthorized access to information. Integrity: guard against unauthorized modification of healthcare information
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		Implement HAPI FHIR Term Server; Implement SOLOR content	HSPC	Complete In progress
SMART Sandbox (Note: rename "Developer's Sandbox")	Freeman, Narus		Multiple Developers Engineering Space Environment Operations and Maintenance Providing Educational Resources Outreach	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		Renew contract.

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.	FHIR term services to HAPI FHIR Term Server	Logica	Complete
Knowledge Repository Specification	Rubin 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.	outlines the functions that a KR needs to support, including artifact storage capabilities, metadata requirements, artifact access services, 2. governance policies. see Roadmap section...	HL7, VA	1. Investigation

Browser not supported