Hi Silje, Thomas and Erik have answered substantial aspects related to specification review.
*2. A.18: “Is relevant documentation of the development and approval process of the specification archived and identified?”* The Clinical content review process and governance structures is documented at: https://openehr.atlassian.net/wiki/display/healthmod/Archetype+authoring%2C+review+and+publication https://openehr.atlassian.net/wiki/display/healthmod/Content+publication%2C+terminology+binding+and+language+translations https://openehr.atlassian.net/wiki/display/healthmod/CKM+Governance+Environment 3. A.23: “Is relevant documentation of the development and approval process of technical specification or standards publicly available (e.g. preliminary results, committee meeting notes)?” All Clinical content development and approval process is accessed via the international CKM tool at openehr.org/ckm. All reviewer and editorial comments, publication decisions and historical versions are accessible to registered users (free to register). The Management Board publishes a monthly update on the foundation news list on the web. This is emailed to openEHR Members. 4. A.26: “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?” The Foundation is funded by membership fees from Ordinary members and Industry partners, as well as some sponsorship contributions, and in-kind support from Industry. This seed funding is augmented by considerable voluntary effort by Industry representatives, and clinical reviewers / editors. Some clinical content development is sponsored directly by national health services or industry partners. 5. A.27: “Does the technical specification or standard have a defined policy for version management?” The clinical content development process is fully version-controlled using semver.org principles and documented s indicated by Thomas. 6. 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)?” As Thomas indicated, this is under development for technical artefacts used and produced by openEHR implementers. Clinical content artefacts are subjected to a rigorous technical test as part of the upload/ maintenance process in the CKM tool. "this is an area of active development in openEHR and now has its own Component. Currently the only proper conformance testing is done by validation of XML data against the published openEHR XML schemas." 7. A.48: “Does the technical specification or standard address backward compatibility with previous versions?” Clinical content Version compatibility rules and testing are handled specifically in the specifications and are instantiated in the CKM tool when those artefacts are updated, by issuing 'diff' and compatibility reports. Ian Dr Ian McNicoll mobile +44 (0)775 209 7859 office +44 (0)1536 414994 skype: ianmcnicoll email: [email protected] twitter: @ianmcnicoll Co-Chair, openEHR Foundation [email protected] Director, freshEHR Clinical Informatics Ltd. Director, HANDIHealth CIC Hon. Senior Research Associate, CHIME, UCL On 4 April 2016 at 16:02, Thomas Beale <[email protected]> wrote: > > > On 04/04/2016 14:07, Bakke, Silje Ljosland wrote: > > Hi, > > > > The project has now done a preliminary CAMSS assessment of openEHR. It’s > identified some issues that I would like some input on: > > 1. A.16: “Are the technical specification or standards reviewed using > a formal review process with all relevant external stakeholders (e.g. public > consultation)?” > > · The review process is not described. There is a documented a"change > process" (http://www.openehr.org/programs/specification/changeprocess ), but > it seems to be for change. Here, however, neither “review” isn’t described > any more than that input from members of the "community" is sought for major > changes. > > > there are a number of pages describing governance; see e.g. this one. Goals > described here. The left hand menu shows the others. > > The general process is: > > new specifications are added to the current working baseline of a Component > (list shown on the governance page - AM, RM, CDS etc) and are announced > publicly. They have status = development. The various statuses are shown > here. This makes them publicly visible. > for some period of time, development will continue, and users of the draft > spec will report problems on the main Problem Report tracker, or in other > ways. These will be addressed by the specification owner. > At some point, it will be determined by the SEC, in consultation with the > community, that the specification is stable enough to be classified as > 'trial', and it will be included in a named Release of the relevant > component. > It will now be subject to formal change control, and every change made to it > will require a Change Request on the relevant component CR tracker. > At some later point, it will be determined by the SEC, in consultation with > the community that the specification can be classified as 'stable', and it > will be marked as such. > A specification may be subsequently retired if it no longer serves a > purpose. > > All of this lifecycle is managed by the SEC, in consultation with the > community. All documents are openly available on the web, and the sources > are in publicly visible Git repositories. All of the PR and CR trackers are > publicly visible and writeable (requires login, to prevent spam). > > The wiki is used extensively as a discussion and planning resource in these > processes. > > It is the default situation that input from the community is always sought - > announcements are made of all major changes in the above process, and > community members can become involved in a number of ways. > > > 2. A.18: “Is relevant documentation of the development and approval > process of the specification archived and identified?” > > · Issue and problem tracker available but it’s hard to find/access. > Approval process archive not found. > > > See the CR trackers, i.e. SPECxx. There is a link on the home page (top > right corner) going straight to these; also from the specifications > governance pages. > > 3. A.23: “Is relevant documentation of the development and approval > process of technical specification or standards publicly available (e.g. > preliminary results, committee meeting notes)?” > > · We’ve been unable to find any minutes from meetings or preliminary > results anywhere. > > > SEC face to face meeting documentation is published here. Community f2f > meetings are reported as well, e.g. this one in 2014. Admittedly, these > resources should be more clearly linked - we'll fix that. > > The Management Board publishes a monthly update on the foundation news list > on the web. I think this may also go via email directly to subscribed > members, but I would have to check on that one. > > 4. A.26: “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?” > > · Unable to find any info about this. > > > What does the question mean? > > 5. A.27: “Does the technical specification or standard have a defined > policy for version management?” > > · The change process has a description about version numbering, but we > can’t find anything about handling different versions, compatibility, etc. > > > Eveything is versioned in openEHR; the release strategy describes the rules > of versions assignment to releases. Other than that, we would need to know > the specific question to be able to answer better. > > 6. 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)?” > > · Can’t find anything about this on the web pages. > > > this is an area of active development in openEHR and now has its own > Component. Currently the only proper conformance testing is done by > validation of XML data against the published openEHR XML schemas. > > 7. A.48: “Does the technical specification or standard address > backward compatibility with previous versions?” > > · Can’t find any info about this on the web pages. > > > > > see the above link to release strategy. > > - thomas > > > > > > > _______________________________________________ > openEHR-technical mailing list > [email protected] > http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
_______________________________________________ openEHR-technical mailing list [email protected] http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
