Hi Silje, As far as I can see the specification process is fully documented at http://openehr.org/programs/specification/ but it is a technical specification and therefore highly detailed.
but in terms of ' standards' development, which I thought was the initial remit, surely the clinical modelling layer is just as significant (possibly more so)? Ian Dr Ian McNicoll mobile +44 (0)775 209 7859 office +44 (0)1536 414994 skype: ianmcnicoll email: i...@freshehr.com twitter: @ianmcnicoll Co-Chair, openEHR Foundation ian.mcnic...@openehr.org Director, freshEHR Clinical Informatics Ltd. Director, HANDIHealth CIC Hon. Senior Research Associate, CHIME, UCL On 6 April 2016 at 13:20, Bakke, Silje Ljosland < silje.ljosland.ba...@nasjonalikt.no> wrote: > I think they’re only interested in the specs, not archetypes. And I think > the point is that it should be possible to learn how the processes work > without being shown. J > > > > Regards, > *Silje* > > > > *Fra:* openEHR-technical [mailto: > openehr-technical-boun...@lists.openehr.org] *På vegne av* Ian McNicoll > *Sendt:* 5. april 2016 23:04 > *Til:* For openEHR technical discussions > *Emne:* Re: CAMSS assessment of openEHR > > > > Just to add. I sense that there is a real difficulty for those involved in > the reviews in understanding anything other than traditional ISO/CEN type > standards/specification processes. > > > > Do we have an opportunity to show them how an archetype review process > works, or to show how the specifications review process works? > > > > Ian > > > Dr Ian McNicoll > mobile +44 (0)775 209 7859 > office +44 (0)1536 414994 > skype: ianmcnicoll > email: i...@freshehr.com > twitter: @ianmcnicoll > > Co-Chair, openEHR Foundation ian.mcnic...@openehr.org > > Director, freshEHR Clinical Informatics Ltd. > Director, HANDIHealth CIC > Hon. Senior Research Associate, CHIME, UCL > > > > On 5 April 2016 at 23:01, Ian McNicoll <i...@freshehr.com> wrote: > > 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: i...@freshehr.com > twitter: @ianmcnicoll > > Co-Chair, openEHR Foundation ian.mcnic...@openehr.org > Director, freshEHR Clinical Informatics Ltd. > Director, HANDIHealth CIC > Hon. Senior Research Associate, CHIME, UCL > > On 4 April 2016 at 16:02, Thomas Beale <thomas.be...@openehr.org> 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 > > openEHR-technical@lists.openehr.org > > > http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org > > > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical@lists.openehr.org > > http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org >
_______________________________________________ openEHR-technical mailing list openEHR-technical@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
