CAMSS Assessment of openEHR

This page contains an assessment of openEHR as a 'standard', according to the EC CAMSS methodology.

Nr.	Category	Description	Nr.	Sub-Category	Description	Nr.	Org.	Criteria	Description	KO	Response (Yes/No/Not Applicable)	Quantification	Comments
0	Technical specification or standard		1.0	Type of technical specification or standard		A.0	O	What type of technical specification or standard are you about to assess?	Types of technical specifications/standards: European standard, European identified specification, national standard, international specifications, other technical specifications.		Open specification		Ian McNicoll: This is correct but if 'open specification' is selected, the spreadsheet then locks out most of the Responses as N/A, which to me makes no sense and should be raised with the CAMMS authors.
1	Market acceptance	The technical specifications have market acceptance and their implementations do not hamper interoperability with the implementations of existing European or international standards. Market acceptance can be demonstrated by operational examples of compliant implementations from different vendors.				A.1		Has the specification been used for different implementations by different vendors/suppliers?			Yes	List of implementing vendors, preferably with weblinks	Ian McNicoll: http://www.openehr.org/who_is_using_openehr/healthcare_providers_and_authorities
						A.2		Does the implementation of the specification hamper interoperability with the implementation of existing European or international standards?			Not applicable		Ian McNicoll: No. AOM/ADL is already part of ISO13606.
						A.3		Are you aware of public references of the respective specification by public authorities (especially policies or in procurements)			Not applicable		Ian McNicoll: Slovenian national policy. Appearing in UK tender documents e.g. Manchester Datawell procurement. Silje Ljosland Bakke (Unlicensed): Procurement, Slovenia: http://www.enarocanje.si/?podrocje=pregledobjave&IzpObrazec=369504 CKM, Slovenia: http://www.ezdrav.si/category/projekti/upravljanje-klinicnega-znanja-openehr-ukz/
						A.4		Has the technical specification or standard been used in different industries, business sectors or functions?			Not applicable		Probably not relevant for most e-Health standards? Ian McNicoll: There is some use of archetypes in other fields.
						A.5		Do the products that implement the technical specification or standard have a significant market share of adoption?	For ‘market demand’, the penetration and acceptance of products implementing the technical specification or standard in the market is addressed.		Not applicable		Ian McNicoll: This is tricky since it depends on what is meant by 'significant market share'. There are certainly numerous companies using the standards to deploy EHR systems and number of national organisations have adopted or are investigating national clinical content development, based on openEHR.
						A.6		Do the products that implement the technical specification or standard target a broad spectrum of end-users?	For the ‘users’, the diversity of the end-users of the products implementing the technical specification or standard is addressed.		Not applicable		Ian McNicoll: Yes
						A.7		Has the technical specification or standard a strong support from different interest groups?	For the ‘interest groups’, the degree of support from different interest groups is addressed.		Not applicable		Ian McNicoll: Yes
2	Coherence principle	The technical specifications are coherent as they do not conflict with European standards, that is to say they cover domains where the adoption of new European standards is not foreseen within a reasonable period, where existing standards have not gained market uptake or where these standards have become obsolete, and where the transposition of the technical specifications into European standardisation deliverables is not foreseen within a reasonable period.				A.8		Does the technical specification or standard cover areas different from areas addressed by technical specifications being under consideration to become a European standard? (i.e. technical specifications provided by a non-formal standardisation organisation, that is other than CEN, CENELEC or ETSI can be under consideration to become a European standard or alternatively an identified technical specification)			Not applicable		International standards must also be considered. Ian McNicoll: Yes .. relates to handling of health data inside a system as well as between systems. Uses crowd-sourcing methodology to develop shared definitions of clinical content.
						A.9.a		a/ Is the adoption of new European Standards which cover the same areas as the proposed specification (or standard) foreseen within a reasonable timeframe?			Not applicable		International standards must also be considered. Ian McNicoll: No
						A.9.b		b/ Are there existing European standards with market uptake which cover the same areas as the proposed specification (or standard) being assessed?			Not applicable		Ian McNicoll: No
						A.9.c		c/ If yes, are the existing standards becoming obsolete?			Not applicable
						A.10		Is the standard an international standard or does it comply with relevant international standards?	Technical specifications is coherent if it covers an area different from an area already addresssed by an existing European standard		Not applicable		Ian McNicoll: Partial - ADL
						A.11		Is the standard or specification listed as recommended in at least one Member State?			Not applicable		Ian McNicoll: Yes. England: https://www.england.nhs.uk/digitaltechnology/info-revolution/interoperability/ Silje Ljosland Bakke (Unlicensed): Slovenia: From procurement of national EHR server: http://www.enarocanje.si/?podrocje=pregledobjave&IzpObrazec=369504
						A.12		Is the standard or specification listed as mandatory in at least one Member State?			Not applicable		Ian McNicoll: Yes. Silje Ljosland Bakke (Unlicensed): Slovenia: From procurement of national EHR server: http://www.enarocanje.si/?podrocje=pregledobjave&IzpObrazec=369504
3	Attributes	The technical specifications were developed by a non-profit making organisation which is a professional society, industry or trade association or any other membership organisation that within its area of expertise develops standards in the field of information and communication technologies and which is not a European, national or international standardisation body				A.13		Is the standards developing organisation a non-profit making organisation?			Not applicable		Ian McNicoll: Yes. openEHR Foundation. http://openehr.org/about/governance_structure
						A.14	O	Is information on the terms and policies for the establishment and operation of the standardisation organisation publicly available?	For the ‘openness’ of the organisation, the level of openness for participating in the standardisation organisation is addressed.		Not applicable		Ian McNicoll: Yes http://openehr.org/about/governance_structure
			3.1	Openness	the technical specifications were developed on the basis of open decision-making accessible to all interested parties in the market or markets affected by the standard.	A.15	O	Is participation in the creation process of the specification open to all interested parties (e.g. organisations, companies or individuals)?			Not applicable		Ian McNicoll: Yes http://openehr.org/programs/specification/
						A.16	O	Are the technical specification or standards reviewed using a formal review process with all relevant external stakeholders (e.g. public consultation)?			Not applicable		Ian McNicoll: Yes http://openehr.org/programs/specification/
			3.2	Consensus	the decision-making process was collaborative and consensus based and did not favour any particular stakeholder. Consensus means a general agreement, characterised by the absence of sustained opposition to substantial issues by any important part of the concerned interests and by a process that involves seeking to take into account the views of all parties concerned and to reconcile any conflicting arguments. Consensus does not imply unanimity.	A.17	O	Are the specifications approved in a decision making process which aims at reaching consensus?			Not applicable		Ian McNicoll: Yes http://openehr.org/programs/specification/
			3.3	Transparency	(i) all information concerning technical discussions and decision making was archived and identified. (ii) information on new standardisation activities was widely announced through suitable and accessible means. (iii) participation of all interested categories of interested stakeholders was sought with a view to achieving balance. (iv) consideration and response were given to comments by interested parties.	A.18		Is relevant documentation of the development and approval process of the specification archived and identified?			Not applicable		Ian McNicoll: Yes. http://openehr.org/programs/specification/
						A.19		Is information on (new) standardisation activities widely announced through suitable and accessible means?			Not applicable		Ian McNicoll: Yes via email, twitter, website.
						A.20	O	All relevant stakeholders can formally appeal or raise objections to the development and approval of specifications?			Not applicable		Ian McNicoll: Yes http://openehr.org/programs/specification/
						A.21	O	Is information on the standardisation process publicly available?	For the ‘process’, the level of openness regarding the development and decision-making process for the technical specification or standard is addressed.		Not applicable		Ian McNicoll: Yes http://openehr.org/programs/specification/
						A.22	O	Is information on the decision making process for approving technical specification or standards publicly available?			Not applicable		Ian McNicoll: Yes http://openehr.org/programs/specification/
						A.23	O	Is relevant documentation of the development and approval process of technical specification or standards publicly available (e.g. preliminary results, committee meeting notes)?	For the openness of the ‘documentation’, the accessibility and availability of the documentation of the technical specification or standard is addressed.		Not applicable		Ian McNicoll: Yes http://openehr.org/programs/specification/
4	Requirements	The technical specifications meet the following requirements	4.1	Maintenance	Ongoing support and maintenance of published specifications are guaranteed over a long period.	A.24		Does the specification have a defined maintenance and support process?			Not applicable		Ian McNicoll: Yes http://openehr.org/programs/specification/
						A.25	O	Does the technical specification or standard have a defined maintenance organisation?	For the ‘maintenance’ and future developments, the support and the planned or existing actions to maintain, improve and develop the technical specification or standard in the long term are addressed.		Not applicable		Ian McNicoll: Yes http://openehr.org/programs/specification/
						A.26	O	Does the maintenance organisation for the technical specification or standard have sufficient finances and resources to be sure of freedom from short- to medium-term threats?			Not applicable		Ian McNicoll: Yes
						A.27		Does the technical specification or standard have a defined policy for version management?			Not applicable		Ian McNicoll: Yes http://openehr.org/programs/specification/
			4.2	Availability	Specifications are publicly available for implementation and use on reasonable terms (including for a reasonable fee or free of charge).	A.28		Is the specification publicly available for implementation and use on reasonable terms?			Not applicable		Ian McNicoll: Yeshttp://openehr.org/programs/specification/releases/currentbaseline
				Intellectual Property Rights	(IPR) essential to the implementation of specifications are licensed to applicants on a (fair) reasonable and non-discriminatory basis ((F)RAND), which includes, at the discretion of the intellectual property rightholder, licensing essential intellectual property without compensation.	A.29		a/ Is the specification licensed on a (F)RAND basis?			Not applicable		Ian McNicoll: Yes http://openehr.org/about/intellectual_property
								b/ Is the specification licensed on a royalty-free basis?			Not applicable		Ian McNicoll: Yeshttp://openehr.org/about/intellectual_property
								c/Does the specification licence allow for derived works to be published and used?	is it possible to create profiles of the technical specification.				This element has been added by the Norwegian standards assessment project. Ian McNicoll: Yes - for the archetype /clinical modelling aspects. The current license for the Reference Model specification does not allow for derivatives but this is currently under review, and should not have any practical impact in any case.
						A.30	O	Is the documentation of the IPR for technical specification or standards publicly available (is there a clear and complete set of licence terms)?	For the ‘documentation of the intellectual property rights’, the availability of the information concerning the ownership rights of the technical specification or standard is addressed.		Not applicable		Ian McNicoll: Yes http://www.openehr.org/about/intellectual_property
			4.3	Relevance	(i) the specifications are effective and relevant; (ii) specifications need to respond to market needs and regulatory requirements.	A.31		a/ Does the specification address and facilitate interoperability between public administrations?			Not applicable		Ian McNicoll: Yes
								b/ Is there evidence that the adoption of the specification positively impacts one or several of the following: organisational processes; the environment; the administrative burden; the disability support; cross-border services, public policy objectives and societal needs ?			Not applicable
						A.32		Does the technical specification or standard address and facilitate the development of eGovernment?			Not applicable		Ian McNicoll: Yes
						A.33		Are the functional and non-functional requirements for the use and implementation of the technical specification or standard clearly defined?	For the ‘requirements’, the functional and non-functional requirements for using and implementing the technical specification or standard are addressed. This criterion is related to the use of assessment scenario 3.		Not applicable		Ian McNicoll: Yes http://openehr.org/programs/specification/releases/currentbaseline
						A.34		Is the technical specification or standard applicable and extensible for implementations in different domains?	For ‘reusability’, the level of reusability of the technical specification or standard in the same or other areas of application is addressed.		Not applicable		Ian McNicoll: Yes
						A.35		Does the technical specification or standard provide sufficient added value compared to alternative technical specification or standards in the same area of application?	For the ‘alternatives’, the degree to which the technical specification or standard adds value compared to alternative technical specification or standardsin the same area of application is addressed.		Not applicable		Ian McNicoll: Yes
						A.36		Is the technical specification or standard largely compatible with related (not alternative) technical specification or standards in the same area of application?	For ‘compatibility’, the compatibility of the technical specification or standard with other technical specification or standardsin the same area of application is addressed.		Not applicable		Ian McNicoll: Yes. Examples of interoperability with HL7v2, CDA and IHE-XDS are in production.
						A.X1		Is the technical specification largely compatible with current domain architecture, guidelines and principles for the domain in question?					This element has been added by the Norwegian standards assessment project. Ian McNicoll: Don't understand the question! I am not sure that such a thing exists in eHealth as 'current domain architecture, guidelines and principles'
						A.37		Is there evidence that the adoption of the technical specification or standard makes it easier to migrate between different solutions from different providers?			Not applicable		Ian McNicoll: Yes, absolutely.
						A.38		Is there evidence that the adoption of the technical specification or standard positively impacts financial costs?			Not applicable
						A.39		Is there evidence that the adoption of the technical specification or standard positively impacts security?			Not applicable
						A.40		Is there evidence that the adoption of the technical specification or standard positively impacts privacy?			Not applicable
						A.41		Are the risks related to the adoption of the technical specification or standard acceptable?	For the ‘risks’, the level of uncertainty is addressed for using and adopting the technical specification or standard	Yes	Not applicable
			4.4	Neutrality and stability	(i) specifications whenever possible are performance oriented rather than based on design or descriptive characteristics; (ii) specifications do not distort the market or limit the possibilities for implementers to develop competition and innovation based upon them; (iii) specifications are based on advanced scientific and technological developments.	A.42		a/ Is the specification largely independent from specific vendor products?			Not applicable		Ian McNicoll: Yes. Wholly.
								b/ Is the specification largely independent from specific platforms or technologies?			Not applicable		Ian McNicoll: Yes. Wholly.
			4.5	Quality	(i) the quality and level of detail are sufficient to permit the development of a variety of competing implementations of interoperable products and services; (ii) standardised interfaces are not hidden or controlled by anyone other than the organisations that adopted the technical specifications.	A.43		Has the specification sufficient detail, consistency and completeness for the use and development of products and services?			Not applicable		Ian McNicoll: Yes.
						A.44		Has the technical specification or standard been sufficiently developed and in existence for a sufficient period to overcome most of its initial problems?	For the ‘development status’, the current development status of the technilcal specification or standard in the development cycle is addressed.		Not applicable		Ian McNicoll: Yes.
						A.45		Are there existing or planned mechanisms to assess conformity of the implementations of the technical specification or standard (e.g. conformity tests, certifications)?	For ‘quality’, the level of detail in the technical specification or standard and the conformance of implementations is addressed.		Not applicable		Ian McNicoll: Yes. Planned
						A.46		Does the technical specification or standard provide available implementation guidelines and documentation for the implementation of products?	For the ‘guidelines’, the existence of implementation guidelines or reference implementations is addressed.		Not applicable		Ian McNicoll: Yes. In development.
						A.47		Does the technical specification or standard provide a reference (or open source) implementation?			Not applicable		Ian McNicoll: Yes.
						A.48		Does the technical specification or standard address backward compatibility with previous versions?	For ‘stability’, the level of change to the technical specification or standard and the stability of underlying technologies is addressed.		Not applicable		Ian McNicoll: Yes.
						A.49		Have the underlying technologies for implementing the technical specification or standard been proven, stable and clearly defined?			Not applicable		Ian McNicoll: Yes
			4.6	Adaptation	(i) the ability to extend, restrict and profile the specification to adress business specific needs	A.X2		Does the technical specification provide explicit mechanisms to restrict it to address specific business needs?			Not applicable		This element has been added by the Norwegian standards assessment project. Ian McNicoll: Yes. via Templates.
						A.X3		Does the technical specification provide explicit mechanisms to extend it to address specific business needs?			Not applicable		Ian McNicoll: Yes via Specialisation, aggregation