Ditto - the main problem is that while we appreciate the important and complementary roles of clinical terminology, information models and health information exchange specifications (which should normally be created as downstream artefacts from the broader whole of 'EHR' content models for the particular use case that they address) the governments and regional authorities don't seem to get this. Perhaps some get it but find difficult to justify because this is somewhat seen as a rather academic view. I guess it is our responsibility to continue to work on to educate and more importantly create some hard evidence so that they feel more confident in making such decisions. We should also accept the fact that, historically, we have not done a very good job of creating such evidence and be very open and completely transparent to drive that confidence - however I want to believe that things have changed for the better in recent years.
Cheers, -koray From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org] On Behalf Of Erik Sundvall Sent: Sunday, 10 April 2016 6:12 p.m. To: For openEHR technical discussions Subject: SV: CAMSS assessment of openEHR Hi! Sadly I don't think it is very often you see goverment initiatives etc actually looking for standardisation at the "clinical" layer in the sense of documentation models that openEHR archetyping covers. They often look for a technical standard (capable of defining messages and code-value-paitinig etc) plus some set of terminology systems. They often believe that such a combination will solve the interoperability problems efficiently. I do not think they usually consider the quality of the clinical content or the processes, ecosystems, communities and update mechanisms used to produce those message defintitions or documentation patterns. Neither do they consider how well message definitions match what clinicians actually want to enter in EHR systems and later query for. (They probably think that is the job of each EHR vendor and that mapping-wizards will do the magic of converting from EHR entries to messages and back, as usual.) Sometimes this applies: https://coiera.com/2015/05/12/a-modest-e-health-proposal-to-government/ I don't know if that is valid for the Norwegian situation now or not. Please share good examples of national initiatives actually assesing the clinical qualities of different approaches. That could be userful and interesting to look at. Best regards, Erik Sundvall ________________________________ Från: openEHR-technical [openehr-technical-boun...@lists.openehr.org] för Ian McNicoll [i...@freshehr.com] Skickat: den 9 april 2016 09:38 Till: For openEHR technical discussions Ämne: Re: CAMSS assessment of openEHR 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<mailto:i...@freshehr.com> twitter: @ianmcnicoll [https://docs.google.com/uc?id=0BzLo3mNUvbAjT2R5Sm1DdFZYTU0&export=download] Co-Chair, openEHR Foundation ian.mcnic...@openehr.org<mailto: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<mailto: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. :) Regards, Silje Fra: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org<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<tel:%2B44%20%280%29775%20209%207859> office +44 (0)1536 414994<tel:%2B44%20%280%291536%20414994> skype: ianmcnicoll email: i...@freshehr.com<mailto:i...@freshehr.com> twitter: @ianmcnicoll [https://docs.google.com/uc?id=0BzLo3mNUvbAjT2R5Sm1DdFZYTU0&export=download] Co-Chair, openEHR Foundation ian.mcnic...@openehr.org<mailto: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<mailto: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<http://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<http://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<tel:%2B44%20%280%29775%20209%207859> office +44 (0)1536 414994<tel:%2B44%20%280%291536%20414994> skype: ianmcnicoll email: i...@freshehr.com<mailto:i...@freshehr.com> twitter: @ianmcnicoll Co-Chair, openEHR Foundation ian.mcnic...@openehr.org<mailto: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<mailto: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<mailto: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<mailto: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