1. Who Are We? An open, international ecosystem containing 70+ organizations each working in their own self-interest while collaborating toward a common industry need Led by internationally-recognized experts in open source, health IT, and platform engineering A community of software vendors, healthcare provider organizations, governments, standards bodies, academic institutions, and integrators A technology-neutral open-source collaboration that is based on commercially-friendly licensing A Non-Profit Trade Association, incorporated within the US as a 501c(6). All Members are equal and OHT does not compete with them.

2. Working Session Objectives 1.Introduce and discuss OHT Platforms 2.Within each platform, discuss the different components 3.Discuss potential tooling for architecture modeling 4.Define/refine next steps for the OHT Architecture Council

3. OHT “Underpinnings” Purpose – To transform the world’s health and well being through a diverse, collaborative and productive HIT ecosystem. See the OHT Vision.OHT Vision Principles - The community is based upon openness, transparency, meritocracy, and contributions. See the OHT Principles.OHT Principles Process - OHT is leveraging proven open-source community governance and processes to achieve rapid outcomes OHT Process.OHT Process Platforms – The core products of the community (tools, exemplary applications, etc.), building the technical foundation for OHT collaboration and Innovation. See OHT Platforms and OHT ArchitectureOHT Platforms OHT Architecture

4. OHT Process OHT Purpose OHT Principles OHT Environments OHT “At a Glance” Discover Enable organizations to communicate and coordinate Contribute and discover assets of value Share objectives, lessons-learned, best-practices Find opportunities to share or avoid costs Collaborate Pool ideas within an established, multidisciplinary, diverse community Share common infrastructure and mitigate risks Provide next generation of collaborative tooling Experiment Incubate ideas and evaluate new technologies Provide software, tools, exemplary applications Provide test and simulation environments Reduce costs via sharing technology and expanding markets Deploy Provide a consumer repository and software store Track, manage, distribute info and software assets Empowering users to configure systems to meet their needs Expand market share through platform ubiquity Provide technology training and support Knowledge Management Environment Collaboration Environment Virtualized Testing & Integration Environment OHT Software Center

5. OHT Community Toolset DiscoverCollaborateExperimentDeploy People -- Member Directory -- Open Source Educational Materials -- Skill Inventory -- Early Adopters - Requirements Council -Architecture Council -Health Council - Communities of Practice -Academic innovation and courseware -- Incubators -- Healthcare workforce education -- Training -- Integration labs Process -Project updates on YouTube -Quarterly project updates (BOCA) -- Intellectual property certification -Academic Challenge -Charter Projects -Forge Projects -OHT Governance -Professional Software Development Process -- Approach to assist/assure quarterly incremental delivery (BOCA/Arrow) -Adopt the principles and processes of open source to build reusable assets to help deploy -- Integrate knowledge based engineering into the deployment cycle Tools -Roadmap Documents - BOCA Charts -Community Forum -- inventory of other tools and projects -- CollabNet community -Asset Repository / Knowledge Mgmt -- Community Forum -- OHT Architecture -Professional development, build, debug, integration and testing environment -- Standard configuration and version management -OSS License Management Engine -Software Distribution Platform Normal Text - Available capability Italics - Coming soon

6. Guiding principles on COTS use within the OHT community…. -The OHT community recognizes that off-the-shelf software may be useful for OHT as an organization. As part of sustaining the OHT community itself, COTS may be used so long as: -OHT Intellectual Property can be migrated from any COTS program used -No COTS program becomes so integral to OHT that it cannot be replaced -Work products of the OHT Charter Projects are not inherently dependent on any specific COTS offering

7. Using OHT Products… -OHT’s objective is to provide a set of complementary platforms that support an Open Health Ecosystem -Use of OHT platforms or components does not require adoption of the entirety of the platform(s) [e.g., “rip and replace” is not an expectation] -Planned duplicative functionality may be offered within OHT to address real-world technical considerations (e.g., OS, hardware, software stack)

8. OHT Platforms User Device Platform User Interface Platform User Configuration Multi-Platform Support Stepstone To be developed Components Exist Legend Development Platform Software SDK Content SDK Integration SDK Runtime Platform HIE Connectors Health Data Management Decision support and analytics Security and privacy services Identity Management Shared Standards Packaging & Distribution Platform OHT Software Center Version/Config Management License Management Conformance Tooling Asset Repository Artifact Publishing Other

9. Development Platform Provides tools for software and content developers to create health solutions. These can include tools to generate code and interfaces, as well as health data components such as vocabularies or data models. Development Platform Software SDK Content SDK Integration SDK

10. Runtime Platform Standards-based services and components that facilitate the management, exchange and analysis of health data, including enabling services for managing patient identities, security and privacy. Runtime Platform HIE Connectors Health Data Management Decision support and analytics Security and privacy services Identity Management Shared Standards

11. User Interface Platform Tools and specifications that enable the creation of a user-controllable interface to personal health information that is portable across desktop and mobile devices. User Interface Platform User Configuration Multi-Platform Support

12. Device Platform Projects that provide tools and services to help create and manage software for medical devices, including the exchange of data with health records. Device Platform Stepstone TBD

13. Packaging and Distribution Platform Applications and services that enable OHT solutions to be discovered, downloaded and evaluated. These solutions can include software, interfaces, licenses and conformance tests, among others. Packaging & Distribution Platform OHT Software Center Version/Config Management License Management Conformance Tooling Asset Repository Artifact Publishing

14. Platform Descriptions Development Platform Provides tools for software and content developers to create health solutions. These can include tools to generate code and interfaces, as well as health data components such as vocabularies or data models. Runtime and Integration Platform Standards-based services and components that facilitate the management, exchange and analysis of health data, including enabling services for managing patient identities, security and privacy. User Interface Platform Tools and specifications that enable the creation of a user-controllable interface to personal health information that is portable across desktop and mobile devices. Device Platform Projects that provide tools and services to help create and manage software for medical devices, including the exchange of data with health records. Packaging and Distribution Platform Applications and services that enable OHT solutions to be discovered, downloaded and evaluated. These solutions can include software, interfaces, licenses and conformance tests, among others.

15. Modeling Tools As we refine our architecture we will need to move from PowerPoint to more sophisticated models and tools. There are three issues to discuss: a)Which architecture perspective should we adopt - enterprise architecture, system architecture, or some combination thereof? b) Which notation should we use - an EA notation like TOGAF, a software notation like UML, or some thing else? c) Any suggestions as to which modeling tools we should adopt? The model format should be open and exchangeable. Low cost or free tools would be desirable if possible. Tools do not necessarily have to be open source.

16. Next Steps There are several steps the Council needs to undertake or continue in order to complete the OHT architecture. We need your assistance to help us elaborate and prioritize the following activities: a)Complete the survey of architecturally significant OHT projects b) Identify potential interfaces that could be used to assemble open source suites of health software that incorporate components from multiple vendors c) Identify common standards that could be used to standardize data across open source projects and make them interoperable d) Focus on assisting under-developed OHT platforms, such as UI, Devices and Distribution e) Other activities or priorities?

17. SUPPLEMENTAL SLIDES The following may not be necessary They are being retained until the deck is complete

18. The Definition(s) of Platform… -For a user/consumer: -Concept of what is a platform will vary based upon individual situation -Viability of the OHT platform cannot be predicated on “rip and replace” everything with the OHT offering -Not every component of the platform needs to be of interest/utility for every consumer -The qualities of the OHT Platform(s) include -An integrated set of components forming a “whole” that can accomplish a set of functions or support business and technical needs -Composed of components, they work together and integrate -There is a distinction between the component parts of a platform and the platform itself -Business rules and toolsets -Brought together via an architecture -Governed by an overarching plan -“How much can you change?” “How much do you have control over?”

19. The Definition(s) of Platform… -For a developer/contributor -A framework that facilitates reuse -Define an architectural approach, style, environment, criteria to determine where contributions fit within the platform (and where existing assets exist that can be used/reused) -Support the “minimum set” of features that are needed to be “fit for purpose” for the intended role of the platform -There are components that are “must haves” within a platform. -There are components that may be “nice to have” -There is an expectation that developers/contributors can use all or parts of a platform to achieve their needs; There is further expectation that any additions to a platform will not conflict with/destabilize the existing platform -Dependent on understanding the architectural objectives relating to the boundaries of components and extensibility capabilities -Need to understand the breadth of functionality that is provided and how to access it -Assumptions based upon technology stack, operating system, etc. -The qualities of the OHT Platform(s) include -An integrated set of components forming a “whole” that can accomplish a set of functions or support business and technical needs -Composed of components, they work together and integrate -There is a distinction between the component parts of a platform and the platform itself -Business rules and toolsets -Brought together via an architecture -Governed by an overarching plan -Clearly defined guidelines for interfacing with and/or extending the platform and its components -Quality Assurance toolset/process -“How can you contribute?” “How can you integrate?” -“What can you leverage?”

20. Community Evolution