2016-04-18/19 - SDAG Business Meeting

 Topics and agenda over the two sessions

IHTSDO Architecture looking forward with the current Tooling Roadmaps

Refresh on the Open Tooling Framework (OTF)

Interfaces

Harmonizing architecture of the OTF with existing tooling

Involvement and responsibility of the AG

Handling configuration information independently of code (to support variety of differently configured deployments of the same tool)

Continuous Integration (along with things like static code analysis, etc).

Making developer "data sets" available (or at least tooling for generating them) - e.g. be able to have a stock "dev" build of each tool with sample configuration and data that makes it easy to get started.

What others have done, and what should we be doing in the mobile arena with regards to interact with terminology servers. 

Mobile devices/apps are starting to capture health information, so how should these devices interact with terminology servers.

What standards should we be encouraging the use of?

•  With HL7 FHIR currently in DSTU2, what is the appropriate way forward in serving up terminology? Using Medication Resources, Value Set Resources?
• What does the vendor community need in terms of tools (open source) to help them support and integrate this?

Following on from yesterday's discussion on representation/format of a concept response

• list out use cases
• what already exists (IHTSDO, NEHTA, termMed, WCI, B2i, and more?)
• next steps for follow up meeting

Release cycles: presumably the PMC has the final say but will there be some kind of (regular) schedule that looks further ahead than the upcoming release?

How to involve more organisations & people (Get started tutorials? Starter projects?)

Identifying gaps in the toolkit, or providing a confluence space where contributors can identify those gaps. Not so much extra features as entire tools that would be a logical and valuable part of the Open Tooling Framework. Philip's question about tools for HL7 FIHR would be a case in point. Such projects could also make it easier for other organisations to become involved.

Formats/templates for tooling documentation (e.g. on Confluence)

Supporting new users, contributors, committers etc. It's mentioned in the Charter but how many people are currently able to offer such support?

Managing community contributions - e.g. policy about merge requests, unit/integration tests, etc.

What is the role of National Release Centers in the open source software development & maintenance?