This wiki has undergone a migration to Confluence found Here
<meta name="googlebot" content="noindex">

Difference between revisions of "FHIR Tooling Eco-system"

From HL7Wiki
Jump to navigation Jump to search
Line 1: Line 1:
−
This page describes the FHIR tooling eco-system
+
'''This page is a draft.  Once complete, review and consensus will be sought by current FHIR tooling participants '''
  
−
Note that the FHIR tooling eco-system is a set of disparate tools that are linked by the conformance resources.
 
  
−
= Terminology Tooling Ecosystem =
+
This page describes the FHIR tooling eco-system and the vision for its future development, including the FHIR community's collective view of what types of tooling are needed, how those tools might best interact with each other and how the tooling community itself will interact and collaborate to maximize the benefit of its collective investment.  It also serves as an entry point for those who are new to the FHIR tooling community and are interested in what tooling is available and/or how they might best contribute to the community.
 +
 
 +
We recognize that developers of tools will do so for their own reasons and to meet their own needs.  This document has no binding force on anyone who wishes to go forth and build FHIR tooling.  However, by working together with the community and by adhering to the principles and processes described here, developers are more likely to create tools that work well together and provide a better experience to their user community.
 +
 
 +
This is a living document.  It will evolve as the needs and vision of the community change.
 +
 
 +
=The community=
 +
==Who and what is the FHIR tooling ecosystem?==
 +
The FHIR tooling ecosystem is the collective set of tools that support the development and maintenance of FHIR artifacts - both FHIR specifications and FHIR implementations.  I.e. It is software that supports FHIR.  It does not include the systems that actually use FHIR to deliver healthcare services (registries, decision support, clinical systems, etc.).  Principally, the ecosystem will be those tools that make use of the Conformance resources.  Many of the tools will be FHIR-specific, but some will support a variety of standards including non-HL7 standards.
 +
 
 +
It's entirely possible for FHIR tooling to be developed that provides re-usable plug-and-play components for other features such as document authoring, order set creation, etc.  Such tools are not covered here.
 +
 
 +
The set of tools within this ecosystem are and will continue to be developed by a variety of stakeholders including HL7 international and its volunteers, HL7 affiliates, other standards development organizations (SDOs), researchers and the implementer community.  HL7 does not place restrictions on who can develop FHIR-related tooling, beyond the [[http://hl7.org/fhir/license.html#2.17.2.1 licensing constraints on the use of the FHIR name and logo]].  Similarly, the concepts expressed here are not an exhaustive list of what tools might potentially exist.  New contributions and ideas are welcome.
 +
 
 +
 
 +
==How do I engage with the FHIR tooling community?==
 +
The FHIR tooling community, like the FHIR implementer community, is global.  It lives both within the standards space (principally under HL7, though also under other SDOs) as well as within the FHIR implementer community as represented by the FHIR Foundation. 
 +
 
 +
Within HL7 tooling issues are primarily dealt with by the [[http://www.hl7.org/Special/committees/fiwg/index.cfm FHIR Infrastructure]] (FHIR-I) work group.  Oversight of tooling related to the development and publication process is provided by the [[http://wiki.hl7.org/index.php?title=FHIR_Management_Group FHIR Management Group]] with the support of the HL7 Publishing work group and overall oversight by the Technical Steering Committee and HL7 CIO.  Work happens both at [[http://www.hl7.org/events/workgroupmeetings.cfm HL7 Working Group Meetings]] as well as on [[http://www.hl7.org/Special/committees/fiwg/index.cfm FHIR-I conference calls]].
 +
 
 +
Within the implementation community, discussion and coordination primarily happens on the [[http://chat.fhir.org chat.fhir.org]] discussion space.  Discussions about general FHIR tooling issues, tooling integration issues and even  updates to this page, happen on the [[https://chat.fhir.org/#narrow/stream/tooling tooling]] stream.  However, conversations about more specific types of tooling also happen on other streams including:
 +
*[[https://chat.fhir.org/#narrow/stream/conformance conformance]] (profiling and IG tooling)
 +
*[[https://chat.fhir.org/#narrow/stream/crucible crucible]] and [[https://chat.fhir.org/#narrow/stream/Touchstone touchstone]] testing tools
 +
*[[https://chat.fhir.org/#narrow/stream/terminology terminology]] terminology services tools
 +
*various reference implementations ([[https://chat.fhir.org/#narrow/stream/dotnet dotnet]], [[https://chat.fhir.org/#narrow/stream/hapi hapi]], [[https://chat.fhir.org/#narrow/stream/javascript javascript]], [[https://chat.fhir.org/#narrow/stream/python python]]
 +
 
 +
New participants are welcome, but are encouraged to read the [[http://wiki.hl7.org/index.php?title=Chat.fhir.org_community_expectations community expectations]].  Participants do not need to be HL7 members, though membership is encouraged to better support the FHIR community as a whole.
 +
 
 +
==Being a committer==
 +
Tooling projects sponsored by HL7 will typically have their source managed under HL7's SVN () or GIT () environments.  Read-only access is available to everyone.  Committer access can be received by emailing lmckenzie@gevityinc.com.  To gain committer privileges, send an email to lmckenzie@gevityinc.com stating the following:
 +
* That you've read and agree to abide by chapter 16 of HL7's [[Governance and Operations Manual]] (GOM)
 +
** The chapter deals with IP rights, patents, etc.
 +
* That you are signed up for and agree to actively monitor the [[https://chat.fhir.org/#narrow/stream/committers Committer's stream]] on chat.fhir.org
 +
** Specifically that you will abide by freezes or other constraints on committed content and that you'll monitor commits to ensure they don't break anything
 +
* What SVN or Git user id should be granted the access
 +
 
 +
 
 +
=The architecture=
 +
==Key requirements==
 +
The following represent ideals we encourage FHIR tools to meet.  Aligning with these requirements will maximize community benefit for the tool
 +
 
 +
* '''Modular''': Tools should be designed in such a manner that their features can be leveraged by tools developed by others and also to be able to leverage tools created by others.  Ideally, the user of the tool should be able to configure which of the available implementations of a particular piece of functionality will be used.
 +
* '''Standardized interfaces''': To allow tools to integrate, standard interfaces and integration points are needed.  One of the main purposes of this document is to identify and define such interfaces.
 +
* '''FHIR artifacts as interface''': Tools should consume and/or produce artifacts that are conformant with the FHIR specifications.  Tooling should work with the XML and JSON version of FHIR artifacts or with the .zip and .pack files produced by FHIR publishing processes.  Any additional custom files or configuration files should be kept to a minimum - and ideally discussed within the tooling community to see if the needs might be met in an interoperable way through FHIR resources.
 +
* '''Extensible''': It should be possible (and ideally easy) to extend the tool to accomodate extensions that may be defined to add capability to Con artifacts being produced or manipulated.
 +
* '''Version independent''': While tools are expected to be dependent on specific versions of conformance resources, they should be able to work with other versions of the FHIR specification (including draft versions with new resources and complex data types) so long as the conformance resources defining the content is available.
 +
* '''Multiple OS support''': At a minimum, FHIR tools should run on Windows and on Macs within common Windows emulators.  Ideally, tools should run on Windows, Mac and Linux without emulation.
 +
* '''Free for use''': Essential functions should not require payment.  HL7 tries hard to ensure that there are minimal financial barriers to using the FHIR specification.  While open-source is encouraged, other financial models such as freemium, "pay what you can", "paid support" are welcome as well.
 +
* '''Escrowed source''': Non-open source tooling implementers are encouraged to keep source in escrow to be made available to the FHIR foundation should the authoring organization no longer be able/willing to maintain the tooling going forward
 +
* '''Multi-language''': Tools should be written in such a way that their user interfaces can support labels and instructions in a variety of languages if the FHIR community chooses to provide the needed translations.
 +
 
 +
==Integration Mechanisms==
 +
There are a number of ways to allow different tools to interact together:
 +
 
 +
===Shared files===
 +
Tools can operate on a shared repository of conformance instances, either in a local persistance structure or in a [[#registry_tooling registry]].  Files containing individual resources or resource bundles can also be passed as an argument when invoking a tool and/or returned as the result when invoking a tool.
 +
 
 +
===RESTful operation invocation===
 +
Server-hosted tools can have their behaviors invoked by calling operations defined on those servers.
 +
 
 +
===Library integration===
 +
One tool can be packaged inside of another tool and have its functions directly invoked by library calls
 +
 
 +
===CDS Hooks===
 +
todo: Grahame or Josh to explain how this would work
 +
 
 +
 
 +
=Tooling Environments=
 +
FHIR tooling requirements (those identified to date at least) can be organized into a set of sub-ecosystems:
 +
 
 +
==Design Tooling==
 +
These tools support the creation and editing of the various conformance artifacts used to define both the FHIR specification itself as well as implementation guides and other packages of conformance artifacts.  Without this tooling, artifacts must be hand-edited using one of the FHIR syntaxes which requires a much steeper learning curve and is more error prone.  It is unlikely that a single tool will support all resources. 
 +
 
 +
===Relevant Specification References===
 +
All of these artifacts should (eventually) have authoring and editing tools.  They are grouped into related areas:
 +
 
 +
Implementation Guides:
 +
* [[hl7.org/fhir/implementationguide.html ImplementationGuide]]
 +
* [[hl7.org/fhir/structuredefinition.html StructureDefinition]]
 +
* [[hl7.org/fhir/capabilitystatement.html CapabilityStatement]]
 +
* [[hl7.org/fhir/searchparameter.html SearchParameter]]
 +
* [[hl7.org/fhir/messagedefinition.html MessageDefinition]]
 +
* [[hl7.org/fhir/operationdefinition.html OperationDefinition]]
 +
* [[hl7.org/fhir/compartmentdefinition.html CompartmentDefinition]]
 +
* [[hl7.org/fhir/graphdefinition.html GraphDefinition]]
 +
* [[hl7.org/fhir/workflowexample.html WorkflowExample]]
 +
 
 +
Terminology:
 +
* [[hl7.org/fhir/codesystem.html CodeSystem]]
 +
* [[hl7.org/fhir/valueset.html ValueSet]]
 +
* [[hl7.org/fhir/expansionprofile.html ExpansionProfile]]
 +
* [[hl7.org/fhir/conceptmap.html ConceptMap]]
 +
* [[hl7.org/fhir/namingsystem.html NamingSystem]]
 +
 
 +
Others:
 +
* [[hl7.org/fhir/structuremap.html StructureMap]]
 +
* [[hl7.org/fhir/testscript.html TestScript]]
 +
 
 +
In addition, the [[hl7.org/fhir/binary.html Binary]] resource may be used to convey images, page text and other content for inclusion in the publication.
 +
 
 +
Other areas of interest include:
 +
* [[hl7.org/fhir/conformance-rules.html Conformance Rules]]
 +
* [[hl7.org/fhir/compartmentdefinition.html Compartment Definition]]
 +
* [[hl7.org/fhir/extensibility.html Extensibility ]]
 +
operations.html
 +
messaging.html
 +
profiling.html Profiling FHIR
 +
 
 +
 
 +
For comparing resources, the following operations may be helpful:
 +
*capabilitystatement-operations.html#conforms
 +
 
 +
===Features===
 +
Must have:
 +
* load resources for editing and serialize resources once created/updated
 +
* render resources for the users doing editing/creation
 +
 
 +
Nice to have:
 +
* enforce design rules (both those in the core specification as well as in referenced/enforced conformance artifacts)
 +
* look up other artifacts for reference
 +
* provide general editing capabilities such as undo/redo; copy & paste, etc.
 +
* use WYSIWYG editing of markdown elements
 +
* show changes between two different artifacts or versions of an artifact
 +
 
 +
===Potential Tool Relationships===
 +
* Invoke other design tools such that when encountering a needed missing artifact, it's possible to jump to a new tool to create the needed artifact, passing back a reference.  (E.g. While editing a structure definition, have the ability to go create a value set, then come back and automatically fill in the value set reference.)  Also used to view/edit artifacts already referenced by the artifact being displayed.
 +
* Invoke [[#publication_tooling Publication Tooling]] to see rendered views of artifacts being edited
 +
* Invoke [[#registry_tooling Registry Tooling]] to locate resources for use
 +
* Invoke [[#validation_tooling Validation Tooling]] to confirm that instances are valid against the base resources and any declared/enforced profiles
 +
* Invoke [[#instance_maintenance_tooling Instance Maintenance Tooling]] to create or modify instances based on changes to underlying conformance resources
 +
* Submit created/edited artifacts to a [[#registry_tooling Registry Tooling]] registry for sharing
 +
* Go to [[#collaborative_review_tooling Collaborative Review Tooling]] to look at comments submitted for an artifact or to note changes made
 +
* Invoke [[#support_services Support Services]] to validate or edit XPath, FHIRPath, XHTML, Markdown, etc.
 +
* Invoke [[#support_services Support Services]] for specialized behavior such as snapshot generation for StructureDefinitions
 +
* Invoke [[#terminology_tools Terminology Tools]] for specialized operations such as [[http://hl7.org/fhir/valueset-operations.html#expand ValueSet$expand]] or [[http://hl7.org/fhir/valueset-operations.html#validate-code ValueSet$validate-code]]
 +
* Invoke external tools for referenced Binary and other artifacts (e.g. image editor, HTML editor, markdown editor, etc.)
 +
* Integrate with source control tooling
 +
 
 +
===Existing Implementations===
 +
todo - links
 +
*Forge - .NET (mac emulator friendly) tool that supports creation and editing of StructureDefinition (profile, logical model) and ImplementationGuide
 +
*Trifolia - supports creation and editing of StructureDefinition (profile), ??? others?
 +
*todo (what's the name?) Grahame's vocab tool - creation and editing of CodeSystems and Value Sets
 +
*todo mapping tool
 +
 
 +
 
 +
===Wish List===
 +
Eventually, we need good quality editors for all of the Conformance artifacts.  However, CapabilityStatement, OperationDefinition, SearchParameter and TestScript are probably the most urgent.
 +
 
 +
 
 +
==Conformance Publication Tooling==
 +
This tooling takes a packaged set of conformance artifacts and renders them into a form suitable for implementers, analysts and others to navigate, read and understand the expectations of a particular implementation environment.  Typically this is done as HTML, but PDF, wiki and other representations are also possible.  In theory, this can include both tooling used to define the core FHIR specification as well as implementation guides.  However, the core spec tooling is highly specialized a
 +
 
 +
===Relevant Specification References===
 +
The most important resource is the [[hl7.org/fhir/implementationguide.html ImplementationGuide]] as it defines the organization of all the content to be published. 
 +
* [[hl7.org/fhir/structuredefinition.html StructureDefinition]]
 +
* [[hl7.org/fhir/capabilitystatement.html CapabilityStatement]]
 +
* [[hl7.org/fhir/searchparameter.html SearchParameter]]
 +
* [[hl7.org/fhir/messagedefinition.html MessageDefinition]]
 +
* [[hl7.org/fhir/operationdefinition.html OperationDefinition]]
 +
* [[hl7.org/fhir/compartmentdefinition.html CompartmentDefinition]]
 +
* [[hl7.org/fhir/graphdefinition.html GraphDefinition]]
 +
* [[hl7.org/fhir/workflowexample.html WorkflowExample]]
 +
 
 +
Terminology:
 +
* [[hl7.org/fhir/codesystem.html CodeSystem]]
 +
* [[hl7.org/fhir/valueset.html ValueSet]]
 +
* [[hl7.org/fhir/expansionprofile.html ExpansionProfile]]
 +
* [[hl7.org/fhir/conceptmap.html ConceptMap]]
 +
* [[hl7.org/fhir/namingsystem.html NamingSystem]]
 +
 
 +
Others:
 +
* [[hl7.org/fhir/structuremap.html StructureMap]]
 +
* [[hl7.org/fhir/testscript.html TestScript]]
 +
 
 +
In addition, the [[hl7.org/fhir/binary.html Binary]] resource may be used to convey images, page text and other content for inclusion in the publication.
 +
 
 +
===Features===
 +
Must have:
 +
* Be able to interpret the ImplementationGuide resource to find the resources to package and publish - as per the organization defined by the ImplementationGuide
 +
* Generate a human-readable view of the package of resources
 +
* Package up the generated publication for sharing
 +
 
 +
Nice to have:
 +
* Support to publish all types of conformance resources
 +
* Include link navigation between specification elements and from specification elements to the  relevant portions of the FHIR specification.
 +
* Validate that content is valid (valid examples, profiles, no broken links, etc.)
 +
* Support automatic publication as content is edited
 +
* Support publishing in alternative languages (if the necessary "translation" extensions are present)
 +
* Support searching of the content from within the specification interface
 +
 
 +
===Potential Tool Relationships===
 +
* Invoke [[#registry_tooling Registry Tooling]] to retrieve referenced resources
 +
* Invoke [[#termonology_tooling Terminology Tooling]] to expand value sets for publication
 +
* Invoke [[#support_services Support Services]] to perform snapshot generation and/or narrative generation as part of publication
 +
* Invoke [[#validation_tooling Validation Tooling]] to confirm that interlinked artifacts, including examples, are valid at time of publication
 +
* Push published content to [[#registry_tooling Registry Tooling]] for publication/sharing
 +
 
 +
===Existing Implementations===
 +
* Forge
 +
* Trifolia?
 +
* HL7 IG publisher
 +
 
 +
===Wish List===
 +
*Improved renderings for CapabilityStatement, OperationDefinition, CodeSystem, etc.
 +
*Renderings of any kind for MessageDefinition, GraphDefinition, NamingSystem
 +
*Additional rendering widgits that make artifacts easier to understand/navigate
 +
 
 +
 
 +
===Open Issues===
 +
* It would be nice to be able to share code that renders artifacts across publication tools - how could we do this?
 +
* Need to agree on how much configuration should live inside the ImplementationGuide, how much should be external (but possibly shareable?) and how much should be tool-specific.
 +
 
 +
 
 +
==Reference Implementations==
 +
Reference implementations are sets of generated code that support implementation of FHIR instances in a particular programming language.  These reference implementations provide a starting point for developers that allows them to avoid deciding how to represent FHIR objects within their environment.
 +
 
 +
===Relevant Specification References===
 +
The key concepts needed to produce object or other language-specific representations of resources are found here:
 +
* [[hl7.org/fhir/structuredefinition.html StructureDefinition]]
 +
* [[hl7.org/fhir/datatypes.html
 +
* [[hl7.org/fhir/elementdefinition.html
 +
 
 +
The syntaxes to parse and serialize are found here:
 +
* [[hl7.org/fhir/xml.html XML
 +
* [[hl7.org/fhir/json.html JSON
 +
* [[hl7.org/fhir/rdf.html RDF
 +
 
 +
Most reference implementations also provide build in support for "fixed" terminology bindings, leveraging information found here:
 +
* [[hl7.org/fhir/codesystem.html CodeSystem]]
 +
* [[hl7.org/fhir/valueset.html ValueSet]]
 +
 
 +
Reference implementations may also provide assistance with dynamic behavior, in which case, these links are also relevant:
 +
* [[hl7.org/fhir/capabilitystatement.html CapabilityStatement]]
 +
* [[hl7.org/fhir/implementationguide.html ImplementationGuide]]
 +
* [[hl7.org/fhir/searchparameter.html SearchParameter]]
 +
* [[hl7.org/fhir/messagedefinition.html MessageDefinition]]
 +
* [[hl7.org/fhir/operationdefinition.html OperationDefinition]]
 +
* [[hl7.org/fhir/compartmentdefinition.html CompartmentDefinition]]
 +
* [[hl7.org/fhir/graphdefinition.html GraphDefinition]]
 +
* [[hl7.org/fhir/http.html RESTful API]]
 +
* [[hl7.org/fhir/search.html Search]]
 +
* [[hl7.org/fhir/graphql.html GraphQL]]
 +
* [[hl7.org/fhir/operations.html Operations]]
 +
* [[hl7.org/fhir/messaging.html Messaging]]
 +
* [[hl7.org/fhir/documents.html Documents]]
 +
 
 +
===Features===
 +
Must have:
 +
* Provide a language-appropriate representation of all resource elements
 +
* Can parse and serialize instances in at least XML and JSON
 +
 
 +
Nice to have:
 +
* Support parsing and serializing RDF
 +
* Provide helper support for REST, operations, messaging and/or documents
 +
* Provide helper support for search
 +
* Be available under an open source license
 +
 
 +
===Potential Tool Relationships===
 +
* Incorporate or allow integration with [[#terminology_tools Terminology Tools]] for run-time terminology support
 +
* Incorporate or allow integration with [[#validation_tools Validation Tools]] for run-time instance validation
 +
 
 +
===Existing Implementations===
 +
* [[https://github.com/ewoutkramer/fhir-net-api .NET]]
 +
* [[http://hapifhir.io Java]]
 +
* [[https://github.com/smart-on-fhir/fhir.js Javascript]]
 +
* [[http://hl7.org/fhir/downloads.html Pascal]]
 +
* [[https://github.com/smart-on-fhir/client-py Python]]
 +
* [[https://github.com/smart-on-fhir/Swift-FHIR Swift]]
 +
 
 +
===Wish List===
 +
* Additional languages of interest to a decent percentage of implementers?
 +
* Support for additional runtime dynamic behavior configuration based on the message definition, graph definition, operation definition and similar resources
 +
 
 +
 
 +
==Validation Tooling==
 +
This tooling allows instances of FHIR resources (including conformance resources) to be checked for validity against the FHIR resources that define them or against which they claim conformance. 
 +
 
 +
===Relevant Specification References===
 +
The two primary sources for validation information are:
 +
* [[hl7.org/fhir/structuredefinition.html StructureDefinition]]
 +
* [[hl7.org/fhir/valueset.html ValueSet]]
 +
 
 +
In addition these resources can also provide information that is relevant to the validation process
 +
* [[hl7.org/fhir/implementationguide.html ImplementationGuide]] (defines 'default' profiles)
 +
* [[hl7.org/fhir/graphdefinition.html GraphDefinition]] (sets expectations for referenced resources)
 +
 
 +
The [[hl7.org/fhir/validation.html Validating Resources]] page covers the expectations of the validation process.
 +
 
 +
The [[hl7.org/fhir/resource-operations.html#validate Resource/$validate]] operation defines how validation is invoked as a service.  It will return validation issues as [[hl7.org/fhir/operationoutcome.html OperationOutcome]] instances.
 +
 
 +
===Features===
 +
Must have:
 +
* Ability to validate both XML and JSON resources of any type
 +
* Check structural and syntax validity of the instance
 +
 
 +
Nice to have:
 +
* Perform validation of terminology against specified bindings
 +
* Check FHIRPath constraints
 +
* Check references to external artifacts
 +
 
 +
===Potential Tool Relationships===
 +
* Invoke [[#registry_tooling Registry Tooling]] to retrieve referenced profiles, value sets and other resources
 +
* Invoke or incorporate [[#terminology_tools Terminology Tools]] to check for code validity
 +
 
 +
===Existing Implementations===
 +
* [[http://hl7.org/fhir//validation.html#jar HL7 Java validator jar]]
 +
* .NET todo: find link
 +
 
 +
===Wish List===
 +
* Continue to build the test case library of both valid and invalid cases
 +
* Create validation libraries in additional languages
 +
* Refactor validator to provide multi-lingual support
 +
 
 +
==Registry Tooling==
 +
Registries host conformance resources as publicly accessible websites that can be searched and navigated to find relevant resources.  Registries allow implementers to leverage existing artifacts rather than creating their own.  They also provide a means of ensuring that implementers get the most "current" version of a particular artifact.
 +
 
 +
===Relevant Specification References===
 +
The most critical resources to
 +
* [[hl7.org/fhir/implementationguide.html ImplementationGuide]]
 +
* [[hl7.org/fhir/structuredefinition.html StructureDefinition]]
 +
* [[hl7.org/fhir/capabilitystatement.html CapabilityStatement]]
 +
* [[hl7.org/fhir/searchparameter.html SearchParameter]]
 +
* [[hl7.org/fhir/messagedefinition.html MessageDefinition]]
 +
* [[hl7.org/fhir/operationdefinition.html OperationDefinition]]
 +
* [[hl7.org/fhir/compartmentdefinition.html CompartmentDefinition]]
 +
* [[hl7.org/fhir/graphdefinition.html GraphDefinition]]
 +
* [[hl7.org/fhir/workflowexample.html WorkflowExample]]
 +
 
 +
Terminology:
 +
* [[hl7.org/fhir/codesystem.html CodeSystem]]
 +
* [[hl7.org/fhir/valueset.html ValueSet]]
 +
* [[hl7.org/fhir/expansionprofile.html ExpansionProfile]]
 +
* [[hl7.org/fhir/conceptmap.html ConceptMap]]
 +
* [[hl7.org/fhir/namingsystem.html NamingSystem]]
 +
 
 +
Others:
 +
* [[hl7.org/fhir/structuremap.html StructureMap]]
 +
* [[hl7.org/fhir/testscript.html TestScript]]
 +
 
 +
===Features===
 +
Must have:
 +
*
 +
 
 +
Nice to have:
 +
*
 +
 
 +
===Potential Tool Relationships===
 +
*
 +
 
 +
===Existing Implementations===
 +
*
 +
 
 +
===Wish List===
 +
 
 +
* Conformance Registry
 +
** curated publication
 +
** voting/comment/review
 +
** candidates: Furore
 +
 
 +
 
 +
==Terminology Tooling==
 +
description
 +
 
 +
===Relevant Specification References===
 +
* [[hl7.org/fhir/codesystem.html CodeSystem]]
 +
* [[hl7.org/fhir/valueset.html ValueSet]]
 +
* [[hl7.org/fhir/expansionprofile.html ExpansionProfile]]
 +
* [[hl7.org/fhir/conceptmap.html ConceptMap]]
 +
* [[hl7.org/fhir/namingsystem.html NamingSystem]]
 +
 
 +
terminologies.html Terminology
 +
terminology-service.html Terminology Services
 +
codesystem-operations.html#lookup
 +
codesystem-operations.html#subsumes
 +
conceptmap-operations.html#translate
 +
conceptmap-operations.html#closure
 +
valueset-operations.html#expand
 +
valueset-operations.html#validate-code
 +
 
 +
===Features===
 +
Must have:
 +
*
 +
 
 +
Nice to have:
 +
*
 +
 
 +
===Potential Tool Relationships===
 +
*
 +
 
 +
===Existing Implementations===
 +
todo: Tooling names
 +
* Health Intersections
 +
* Apelon
 +
* Art-Decor
 +
* VSAC
 +
 
 +
 
 +
===Wish List===
 +
???
 +
 
 +
==Instance Maintenance Tooling==
 +
description
 +
 
 +
===Relevant Specification References===
 +
* [[hl7.org/fhir/structuredefinition.html StructureDefinition]]
 +
* [[hl7.org/fhir/messagedefinition.html MessageDefinition]]
 +
* [[hl7.org/fhir/graphdefinition.html GraphDefinition]]
 +
* [[hl7.org/fhir/valueset.html ValueSet]]
 +
 
 +
===Features===
 +
Must have:
 +
*
 +
 
 +
Nice to have:
 +
*
 +
 
 +
===Potential Tool Relationships===
 +
*
 +
 
 +
===Existing Implementations===
 +
*
 +
 
 +
===Wish List===
 +
 
 +
 
 +
==Implementation Test Tooling==
 +
description
 +
 
 +
===Relevant Specification References===
 +
* [[hl7.org/fhir/testscript.html TestScript]]
 +
testing.html
 +
 
 +
===Features===
 +
Must have:
 +
*
 +
 
 +
Nice to have:
 +
*
 +
 
 +
===Potential Tool Relationships===
 +
*
 +
 
 +
===Existing Implementations===
 +
** Test servers
 +
** test clients
 +
** Candidates: TouchStone, Crucible
 +
 
 +
 
 +
===Wish List===
 +
 
 +
 
 +
* Testing Service
 +
 
 +
 
 +
 
 +
==Conversion Tooling==
 +
description
 +
 
 +
===Relevant Specification References===
 +
* [[hl7.org/fhir/structuremap.html StructureMap]]
 +
mapping-language.html
 +
structuremap-operations.html#transform
 +
 
 +
===Features===
 +
Must have:
 +
*
 +
 
 +
Nice to have:
 +
*
 +
 
 +
===Potential Tool Relationships===
 +
*
 +
 
 +
===Existing Implementations===
 +
*
 +
 
 +
===Wish List===
 +
 
 +
 
 +
==Collaborative Review Tooling==
 +
description
 +
 
 +
===Relevant Specification References===
 +
 
 +
===Features===
 +
Must have:
 +
*
 +
 
 +
Nice to have:
 +
*
 +
 
 +
===Potential Tool Relationships===
 +
*
 +
 
 +
===Existing Implementations===
 +
*
 +
 
 +
===Wish List===
 +
 
 +
 
 +
==Support Services==
 +
XPath evaluation
 +
FHIRPath validation and evaluation
 +
Narrative generation
 +
Snapshot generation
 +
Narrative Generation
 +
 
 +
narrative.html
 +
http://hl7.org/fhirpath
 +
 
 +
description
 +
 
 +
===Relevant Specification References===
 +
* [[hl7.org/fhir/capabilitystatement.html CapabilityStatement]]
 +
 
 +
===Features===
 +
Must have:
 +
*
 +
 
 +
Nice to have:
 +
*
 +
 
 +
===Potential Tool Relationships===
 +
*
  
−
A set of services that support operational use of terminologies. Todo: should this cover knowledge resources too (Medication, DataElement)?
+
===Existing Implementations===
 +
*
  
−
A typical story board:
+
===Wish List===
−
* author a value set through a value set editor
 
−
* save it to a terminology service
 
−
* integrate it into a UI by referencing it by URL
 
−
* publish it to a forma registry
 
  
−
Parts of the Terminology tooling eco-system
 
−
* Terminology Service (see [[http://hl7.org/fhir/terminology-service.html official definition]])
 
−
** CRUD on code systems, value sets, concept maps & naming systems
 
−
** expansion / lookup / validation / translation / closure
 
−
** cds-hook catalogue: reference value set, reference display code
 
−
** implementations: Health Intersections, Apelon, Art-Decor, VSAC, ??
 
−
* Terminology registry (does this need to be a terminology service too?)
 
−
** curated publication, voting/comment/review (see collaborative review IG below)
 
−
** implementations: Health Intersections, Furore?, trifolia?
 
−
* Code System / Value Set / Concept Map Editor
 
−
** find resource(file / registry)
 
−
** display / edit them / preview outcomes (speculative evaluation)
 
−
** import / export from other formats - excel, csv, ?...
 
−
** save resource (file / registry - e.g. publish)
 
−
** implementations: Health Intersections, Apelon, VSAC, Art-Decor, PenRad
 
  
−
Open Issues:
 
  
−
* Do we want to add support for patch updates to better integrate with the whole notion of harmonization proposals?  (Even if we don't use that process, we're going to want to allow submission of requests for addition of codes, changing individual definitions, etc. )
 
  
 
= Conformance / Design Tooling Ecosystem =
 
= Conformance / Design Tooling Ecosystem =
Line 43: Line 546:
 
** candidates: Health Intersections, Furore?
 
** candidates: Health Intersections, Furore?
 
** Conformance Servers are recommended to implement the Server Actor in the [[FHIR Colloborative Review Implementation Guide]]
 
** Conformance Servers are recommended to implement the Server Actor in the [[FHIR Colloborative Review Implementation Guide]]
−
* Testing Service
 
−
** Test servers
 
−
** test clients
 
−
** Candidates: TouchStone, Crucible
 
−
* Conformance Registry
 
−
** curated publication
 
−
** voting/comment/review
 
−
** candidates: Furore
 
−
* Editors (?Designers)
 
−
** Profiles
 
−
*** Forge (Furore)
 
−
** Conformance Statements
 
−
*** ?
 
−
* OperationDefinitions
 
−
*** ?
 
−
** Search Parameter(?)
 
−
*** ?
 
−
** Implementation Guide
 
−
*** ?
 
−
* Code generation....?
 
  
 
Open issues
 
Open issues
  
 
* Will need a good way to manage external files too - Basic resources with ad-hoc narrative for security, use-cases, etc; ability to manage Binaries for images, etc.
 
* Will need a good way to manage external files too - Basic resources with ad-hoc narrative for security, use-cases, etc; ability to manage Binaries for images, etc.
−
* Doesn't the publication tooling fall into this too? "$publish" seems a tad light-weight to represent everything that's involved in that process
+
 
−
* Should we be including reference implementation generation too?
+
= Terminology Tooling Ecosystem =
−
* When dealing with voting/comment/review of content, is that only profiles & IGs, or does it include the core spec too?
+
 
 +
A set of services that support operational use of terminologies. Todo: should this cover knowledge resources too (Medication, DataElement)?
 +
 
 +
Parts of the Terminology tooling eco-system
 +
** cds-hook catalogue: reference value set, reference display code
 +
 
 +
* Terminology registry (does this need to be a terminology service too?)
 +
* Code System / Value Set / Concept Map Editor
 +
** find resource(file / registry)
 +
** display / edit them / preview outcomes (speculative evaluation)
 +
** import / export from other formats - excel, csv, ?...
 +
** save resource (file / registry - e.g. publish)
 +
** implementations: Health Intersections, Apelon, VSAC, Art-Decor, PenRad
 +
 
 +
Open Issues:
 +
 
 +
* Do we want to add support for patch updates to better integrate with the whole notion of harmonization proposals? (Even if we don't use that process, we're going to want to allow submission of requests for addition of codes, changing individual definitions, etc. )
  
 
= Collaborative Review Eco-system =
 
= Collaborative Review Eco-system =
  
 
The collaborative review system allows one user to invite a set of other users to make comments on a set of resources. Initially the application of this is to a review conformance resources, to help with distributed development, but it is anticipated to be suitable for use in clinical review processes.
 
The collaborative review system allows one user to invite a set of other users to make comments on a set of resources. Initially the application of this is to a review conformance resources, to help with distributed development, but it is anticipated to be suitable for use in clinical review processes.

Revision as of 07:22, 9 September 2017

This page is a draft. Once complete, review and consensus will be sought by current FHIR tooling participants


This page describes the FHIR tooling eco-system and the vision for its future development, including the FHIR community's collective view of what types of tooling are needed, how those tools might best interact with each other and how the tooling community itself will interact and collaborate to maximize the benefit of its collective investment. It also serves as an entry point for those who are new to the FHIR tooling community and are interested in what tooling is available and/or how they might best contribute to the community.

We recognize that developers of tools will do so for their own reasons and to meet their own needs. This document has no binding force on anyone who wishes to go forth and build FHIR tooling. However, by working together with the community and by adhering to the principles and processes described here, developers are more likely to create tools that work well together and provide a better experience to their user community.

This is a living document. It will evolve as the needs and vision of the community change.

Contents

The community

Who and what is the FHIR tooling ecosystem?

The FHIR tooling ecosystem is the collective set of tools that support the development and maintenance of FHIR artifacts - both FHIR specifications and FHIR implementations. I.e. It is software that supports FHIR. It does not include the systems that actually use FHIR to deliver healthcare services (registries, decision support, clinical systems, etc.). Principally, the ecosystem will be those tools that make use of the Conformance resources. Many of the tools will be FHIR-specific, but some will support a variety of standards including non-HL7 standards.

It's entirely possible for FHIR tooling to be developed that provides re-usable plug-and-play components for other features such as document authoring, order set creation, etc. Such tools are not covered here.

The set of tools within this ecosystem are and will continue to be developed by a variety of stakeholders including HL7 international and its volunteers, HL7 affiliates, other standards development organizations (SDOs), researchers and the implementer community. HL7 does not place restrictions on who can develop FHIR-related tooling, beyond the [licensing constraints on the use of the FHIR name and logo]. Similarly, the concepts expressed here are not an exhaustive list of what tools might potentially exist. New contributions and ideas are welcome.


How do I engage with the FHIR tooling community?

The FHIR tooling community, like the FHIR implementer community, is global. It lives both within the standards space (principally under HL7, though also under other SDOs) as well as within the FHIR implementer community as represented by the FHIR Foundation.

Within HL7 tooling issues are primarily dealt with by the [FHIR Infrastructure] (FHIR-I) work group. Oversight of tooling related to the development and publication process is provided by the [FHIR Management Group] with the support of the HL7 Publishing work group and overall oversight by the Technical Steering Committee and HL7 CIO. Work happens both at [HL7 Working Group Meetings] as well as on [FHIR-I conference calls].

Within the implementation community, discussion and coordination primarily happens on the [chat.fhir.org] discussion space. Discussions about general FHIR tooling issues, tooling integration issues and even updates to this page, happen on the [tooling] stream. However, conversations about more specific types of tooling also happen on other streams including:

New participants are welcome, but are encouraged to read the [community expectations]. Participants do not need to be HL7 members, though membership is encouraged to better support the FHIR community as a whole.

Being a committer

Tooling projects sponsored by HL7 will typically have their source managed under HL7's SVN () or GIT () environments. Read-only access is available to everyone. Committer access can be received by emailing lmckenzie@gevityinc.com. To gain committer privileges, send an email to lmckenzie@gevityinc.com stating the following:

  • That you've read and agree to abide by chapter 16 of HL7's Governance and Operations Manual (GOM)
    • The chapter deals with IP rights, patents, etc.
  • That you are signed up for and agree to actively monitor the [Committer's stream] on chat.fhir.org
    • Specifically that you will abide by freezes or other constraints on committed content and that you'll monitor commits to ensure they don't break anything
  • What SVN or Git user id should be granted the access


The architecture

Key requirements

The following represent ideals we encourage FHIR tools to meet. Aligning with these requirements will maximize community benefit for the tool

  • Modular: Tools should be designed in such a manner that their features can be leveraged by tools developed by others and also to be able to leverage tools created by others. Ideally, the user of the tool should be able to configure which of the available implementations of a particular piece of functionality will be used.
  • Standardized interfaces: To allow tools to integrate, standard interfaces and integration points are needed. One of the main purposes of this document is to identify and define such interfaces.
  • FHIR artifacts as interface: Tools should consume and/or produce artifacts that are conformant with the FHIR specifications. Tooling should work with the XML and JSON version of FHIR artifacts or with the .zip and .pack files produced by FHIR publishing processes. Any additional custom files or configuration files should be kept to a minimum - and ideally discussed within the tooling community to see if the needs might be met in an interoperable way through FHIR resources.
  • Extensible: It should be possible (and ideally easy) to extend the tool to accomodate extensions that may be defined to add capability to Con artifacts being produced or manipulated.
  • Version independent: While tools are expected to be dependent on specific versions of conformance resources, they should be able to work with other versions of the FHIR specification (including draft versions with new resources and complex data types) so long as the conformance resources defining the content is available.
  • Multiple OS support: At a minimum, FHIR tools should run on Windows and on Macs within common Windows emulators. Ideally, tools should run on Windows, Mac and Linux without emulation.
  • Free for use: Essential functions should not require payment. HL7 tries hard to ensure that there are minimal financial barriers to using the FHIR specification. While open-source is encouraged, other financial models such as freemium, "pay what you can", "paid support" are welcome as well.
  • Escrowed source: Non-open source tooling implementers are encouraged to keep source in escrow to be made available to the FHIR foundation should the authoring organization no longer be able/willing to maintain the tooling going forward
  • Multi-language: Tools should be written in such a way that their user interfaces can support labels and instructions in a variety of languages if the FHIR community chooses to provide the needed translations.

Integration Mechanisms

There are a number of ways to allow different tools to interact together:

Shared files

Tools can operate on a shared repository of conformance instances, either in a local persistance structure or in a #registry_tooling registry. Files containing individual resources or resource bundles can also be passed as an argument when invoking a tool and/or returned as the result when invoking a tool.

RESTful operation invocation

Server-hosted tools can have their behaviors invoked by calling operations defined on those servers.

Library integration

One tool can be packaged inside of another tool and have its functions directly invoked by library calls

CDS Hooks

todo: Grahame or Josh to explain how this would work


Tooling Environments

FHIR tooling requirements (those identified to date at least) can be organized into a set of sub-ecosystems:

Design Tooling

These tools support the creation and editing of the various conformance artifacts used to define both the FHIR specification itself as well as implementation guides and other packages of conformance artifacts. Without this tooling, artifacts must be hand-edited using one of the FHIR syntaxes which requires a much steeper learning curve and is more error prone. It is unlikely that a single tool will support all resources.

Relevant Specification References

All of these artifacts should (eventually) have authoring and editing tools. They are grouped into related areas:

Implementation Guides:

Terminology:

Others:

In addition, the hl7.org/fhir/binary.html Binary resource may be used to convey images, page text and other content for inclusion in the publication.

Other areas of interest include:

operations.html messaging.html profiling.html Profiling FHIR


For comparing resources, the following operations may be helpful:

  • capabilitystatement-operations.html#conforms

Features

Must have:

  • load resources for editing and serialize resources once created/updated
  • render resources for the users doing editing/creation

Nice to have:

  • enforce design rules (both those in the core specification as well as in referenced/enforced conformance artifacts)
  • look up other artifacts for reference
  • provide general editing capabilities such as undo/redo; copy & paste, etc.
  • use WYSIWYG editing of markdown elements
  • show changes between two different artifacts or versions of an artifact

Potential Tool Relationships

Existing Implementations

todo - links

  • Forge - .NET (mac emulator friendly) tool that supports creation and editing of StructureDefinition (profile, logical model) and ImplementationGuide
  • Trifolia - supports creation and editing of StructureDefinition (profile), ??? others?
  • todo (what's the name?) Grahame's vocab tool - creation and editing of CodeSystems and Value Sets
  • todo mapping tool


Wish List

Eventually, we need good quality editors for all of the Conformance artifacts. However, CapabilityStatement, OperationDefinition, SearchParameter and TestScript are probably the most urgent.


Conformance Publication Tooling

This tooling takes a packaged set of conformance artifacts and renders them into a form suitable for implementers, analysts and others to navigate, read and understand the expectations of a particular implementation environment. Typically this is done as HTML, but PDF, wiki and other representations are also possible. In theory, this can include both tooling used to define the core FHIR specification as well as implementation guides. However, the core spec tooling is highly specialized a

Relevant Specification References

The most important resource is the hl7.org/fhir/implementationguide.html ImplementationGuide as it defines the organization of all the content to be published.

Terminology:

Others:

In addition, the hl7.org/fhir/binary.html Binary resource may be used to convey images, page text and other content for inclusion in the publication.

Features

Must have:

  • Be able to interpret the ImplementationGuide resource to find the resources to package and publish - as per the organization defined by the ImplementationGuide
  • Generate a human-readable view of the package of resources
  • Package up the generated publication for sharing

Nice to have:

  • Support to publish all types of conformance resources
  • Include link navigation between specification elements and from specification elements to the relevant portions of the FHIR specification.
  • Validate that content is valid (valid examples, profiles, no broken links, etc.)
  • Support automatic publication as content is edited
  • Support publishing in alternative languages (if the necessary "translation" extensions are present)
  • Support searching of the content from within the specification interface

Potential Tool Relationships

Existing Implementations

  • Forge
  • Trifolia?
  • HL7 IG publisher

Wish List

  • Improved renderings for CapabilityStatement, OperationDefinition, CodeSystem, etc.
  • Renderings of any kind for MessageDefinition, GraphDefinition, NamingSystem
  • Additional rendering widgits that make artifacts easier to understand/navigate


Open Issues

  • It would be nice to be able to share code that renders artifacts across publication tools - how could we do this?
  • Need to agree on how much configuration should live inside the ImplementationGuide, how much should be external (but possibly shareable?) and how much should be tool-specific.


Reference Implementations

Reference implementations are sets of generated code that support implementation of FHIR instances in a particular programming language. These reference implementations provide a starting point for developers that allows them to avoid deciding how to represent FHIR objects within their environment.

Relevant Specification References

The key concepts needed to produce object or other language-specific representations of resources are found here:

The syntaxes to parse and serialize are found here:

  • [[hl7.org/fhir/xml.html XML
  • [[hl7.org/fhir/json.html JSON
  • [[hl7.org/fhir/rdf.html RDF

Most reference implementations also provide build in support for "fixed" terminology bindings, leveraging information found here:

Reference implementations may also provide assistance with dynamic behavior, in which case, these links are also relevant:

Features

Must have:

  • Provide a language-appropriate representation of all resource elements
  • Can parse and serialize instances in at least XML and JSON

Nice to have:

  • Support parsing and serializing RDF
  • Provide helper support for REST, operations, messaging and/or documents
  • Provide helper support for search
  • Be available under an open source license

Potential Tool Relationships

Existing Implementations

Wish List

  • Additional languages of interest to a decent percentage of implementers?
  • Support for additional runtime dynamic behavior configuration based on the message definition, graph definition, operation definition and similar resources


Validation Tooling

This tooling allows instances of FHIR resources (including conformance resources) to be checked for validity against the FHIR resources that define them or against which they claim conformance.

Relevant Specification References

The two primary sources for validation information are:

In addition these resources can also provide information that is relevant to the validation process

The hl7.org/fhir/validation.html Validating Resources page covers the expectations of the validation process.

The hl7.org/fhir/resource-operations.html#validate Resource/$validate operation defines how validation is invoked as a service. It will return validation issues as hl7.org/fhir/operationoutcome.html OperationOutcome instances.

Features

Must have:

  • Ability to validate both XML and JSON resources of any type
  • Check structural and syntax validity of the instance

Nice to have:

  • Perform validation of terminology against specified bindings
  • Check FHIRPath constraints
  • Check references to external artifacts

Potential Tool Relationships

Existing Implementations

Wish List

  • Continue to build the test case library of both valid and invalid cases
  • Create validation libraries in additional languages
  • Refactor validator to provide multi-lingual support

Registry Tooling

Registries host conformance resources as publicly accessible websites that can be searched and navigated to find relevant resources. Registries allow implementers to leverage existing artifacts rather than creating their own. They also provide a means of ensuring that implementers get the most "current" version of a particular artifact.

Relevant Specification References

The most critical resources to

Terminology:

Others:

Features

Must have:

Nice to have:

Potential Tool Relationships

Existing Implementations

Wish List

  • Conformance Registry
    • curated publication
    • voting/comment/review
    • candidates: Furore


Terminology Tooling

description

Relevant Specification References

terminologies.html Terminology terminology-service.html Terminology Services codesystem-operations.html#lookup codesystem-operations.html#subsumes conceptmap-operations.html#translate conceptmap-operations.html#closure valueset-operations.html#expand valueset-operations.html#validate-code

Features

Must have:

Nice to have:

Potential Tool Relationships

Existing Implementations

todo: Tooling names

  • Health Intersections
  • Apelon
  • Art-Decor
  • VSAC


Wish List

???

Instance Maintenance Tooling

description

Relevant Specification References

Features

Must have:

Nice to have:

Potential Tool Relationships

Existing Implementations

Wish List

Implementation Test Tooling

description

Relevant Specification References

testing.html

Features

Must have:

Nice to have:

Potential Tool Relationships

Existing Implementations

    • Test servers
    • test clients
    • Candidates: TouchStone, Crucible


Wish List

  • Testing Service


Conversion Tooling

description

Relevant Specification References

mapping-language.html structuremap-operations.html#transform

Features

Must have:

Nice to have:

Potential Tool Relationships

Existing Implementations

Wish List

Collaborative Review Tooling

description

Relevant Specification References

Features

Must have:

Nice to have:

Potential Tool Relationships

Existing Implementations

Wish List

Support Services

XPath evaluation FHIRPath validation and evaluation Narrative generation Snapshot generation Narrative Generation

narrative.html http://hl7.org/fhirpath

description

Relevant Specification References

Features

Must have:

Nice to have:

Potential Tool Relationships

Existing Implementations

Wish List

Conformance / Design Tooling Ecosystem

A set of tools that support the process of working with resources and profiles on resources, and by extension, implementation guides. This includes content design tooling, code generation, publishing, and testing tooling

  • Conformance Service
    • CRUD on StructureDefinition, Conformance, OperationDefinition, SearchParameter, CompartmentDefinition, ImplementationGuide, TestScript
    • Operations: $generate-snapshot, $publish (for ImplementationGuide), $compare (StructureDefinition, OperationDefinition, Conformance)
    • cds-hook catalogue: reference StructureDefinition
    • candidates: Health Intersections, Furore?
    • Conformance Servers are recommended to implement the Server Actor in the FHIR Colloborative Review Implementation Guide

Open issues

  • Will need a good way to manage external files too - Basic resources with ad-hoc narrative for security, use-cases, etc; ability to manage Binaries for images, etc.

Terminology Tooling Ecosystem

A set of services that support operational use of terminologies. Todo: should this cover knowledge resources too (Medication, DataElement)?

Parts of the Terminology tooling eco-system

    • cds-hook catalogue: reference value set, reference display code
  • Terminology registry (does this need to be a terminology service too?)
  • Code System / Value Set / Concept Map Editor
    • find resource(file / registry)
    • display / edit them / preview outcomes (speculative evaluation)
    • import / export from other formats - excel, csv, ?...
    • save resource (file / registry - e.g. publish)
    • implementations: Health Intersections, Apelon, VSAC, Art-Decor, PenRad

Open Issues:

  • Do we want to add support for patch updates to better integrate with the whole notion of harmonization proposals? (Even if we don't use that process, we're going to want to allow submission of requests for addition of codes, changing individual definitions, etc. )

Collaborative Review Eco-system

The collaborative review system allows one user to invite a set of other users to make comments on a set of resources. Initially the application of this is to a review conformance resources, to help with distributed development, but it is anticipated to be suitable for use in clinical review processes.

Retrieved from "https://wiki.hl7.org/w/index.php?title=FHIR_Tooling_Eco-system&oldid=145351"