Chair of openEHR Clinical Review Board (CRB) announced

Clinical (archive)
1

[this is a repost of an announcement made a week ago, for those on the clinical list but not on the announce list]

from Prof David Ingram, CHIME department, University College London:

I am delighted to announce that Dr Tony Shannon has accepted an
invitation, on behalf of the openEHR Foundation Board, to take over the
chair of the Clinical Review Board. Tony has long experience and
interest in clinical information management, as Clinical Lead for the
Clinical Content Service of NHS Connecting for Health and as Consultant
in Emergency Medicine at Leeds Teaching Hospitals.

My UCL colleague, Dr Dipak Kalra, has been the founding chair of the CRB
but felt it the right time to step down and make way for a new
appointment, recognising, as we all do, that openEHR governance needs to
spread beyond the founding members at UCL and Ocean Informatics. Dipak,
Sam Heard and I remain as the active directors of the Foundation, but
this, too, may well change quickly, in the period ahead, as we work to
broaden the governance of the Foundation. Ideally, we feel that the
Foundation needs to remain agile and inclusive in its work, while
consolidating its relationships and accountability to users and
international stakeholder organisations, keen to capitalise on its work.
In this transition, we must try to avoid exchanging a crucible of
innovation for a tanker full of treacle.

Tony Shannon has an honorary appointment as senior research fellow at
UCL and has been active clinically in building wider awareness of and
engagement with the mission of openEHR, for several years. Along with
Tim Cook, a member of the ARB, he has joined Sam, Dipak, Tom Beale and
me in crucial new discussions about how to take the Foundation into its
next stage of development and governance, as its work grows rapidly in
international focus and importance. We have received a number of
approaches for new partnerships and we will be taking these very
seriously and opening discussions more widely within the international
community, including at a session of the WoHIT conference in November,
under the auspices of our collaborating partners in EuroRec.

openEHR exists to champion the clinical ownership of the fundamental
requirements for effective and useful electronic health records and to
support the discipline, engagement and trust required to help them
succeed. Central to its approach is shared and collaborative research,
development and iterative evaluation, though real world implementations.

2

Dear All,

I am very honoured to be invited to take up this important role as Chair
of the Clinical Review Board within the openEHR Foundation.

Please allow me to introduce myself and my interest in openEHRs mission.
I would welcome your feedback and views as I explain below.

3

Congratulations Tony,

Like you I am a silent member of the mailing list must be an "Irish" thing.
Good luck with the post.

Mary Sharp

4

Hello Tony!
Congratulations to you for your new role as chair, and we wish you lots of
success! Hope to meet you in person somtime soon!

Right on into it, you wrote:
"Can I ask you (wherever you are and whatever your clinical challenges
are) what are the *top 5* things you would like to see the openEHR
foundation tackle to move us all in the right direction over the next
year/18months and better support your own challenges as a clinician?
That might be better communication, better means to get involved, better
tools etc etc...whatever you happen to think.."

Now, here comes:

Myself, I am an academic person, electronics engineer, with 15 years of
research experience in a university hospital, doing biosignal analysis, and
software development for experimental research in medicine. I moved into
teaching and standards, and I am now the head of the national mirror to CEN
and ISO TCs for medical informatics, and a founding member of IHE Austria.
We had a lot of contact to 13606, hoping that it would evolve into something
that would solve the problem of reuseability of medical information models.

Over the last year and a half I have been responsible for coordinating work
on medical documents in Austria, together with others. This is still going
on, as a part of the Austrian national EHR project ELGA. We have put
together groups of high ranking medical experts, most of them clinicians,
all in all about 80-100 of them, and started the discussion about the
contents of medical documents: discharge summaries, laboratory reports,
radiology reports, and medication status. The national austrian eHealth
strategy recommends to use CDA as an electronic format for this exercise.
This has been confirmed by politics, and we therefore were obliged to follow
that route. We did some reviews before we started, and it was decided to use
the results of the German CDA work within VHITG as a basis. In the middle of
the work, we discovered the IHE laboratory technical framework, which
contains a very useful laboratory report, see
http://www.ihe.net/Technical_Framework/upload/ihe_lab_TF_rel2_1-Vol-3_FT_200
8-08-08.pdf
This is also used in national projects in the USA, the Netherlands, and
France.

We are now in the middle of the discussion, and, (provided we can continue,
we do have national elections in September), hope to reach some stability by
end of 2008. We are going to keep very close to the mentioned IHE lab
report.

International standards are among the major goals of the Austrian EHR
project. And this is where real trouble begins. People do approach us
"experts", asking: Which standard is the right one for capturing medical
content. At the moment many in Austria believe that this is HL7 CDA.
However, 13606 is a formal international and Austrian standard, and
everybody asks us how the situation is going to look like in 5 years. Will
it still be CDA, or archetypes, or full 13606, or a combination? What is the
direction? What path shall we follow? Where shall we invest our money? Even
if it is not finished right now: Is there at least a clear development path
which will produce useful results soon? Is the cooperation between CEN, ISO,
HL7, openEHR etc. really producing a change, and will it root out the
conflicting standards jungle?

Even being the formally topmost medical informatics standards person in
Austria, and having attended international meetings for years now I must
tell them that I do not know. This is a very unpleasant experience, and I
would very much like to see some movement here.

In order to get something on the way here, I think we need to combine some
major forces, and finally show that we can successfully tackle some real
world problems on a multi-national scale.

- The IHE lab report group does collect clinical input from different
countries, and it has carried the document through many iterations, and
produced a final release in August 2008. After that much effort, it can well
be expected to be of clinical use, and is definitely worth consideration. We
do see a lot of vendor interest here, and things are being implemented,
tested, and put to practical use.

- openEHR is the home of archetypes, a very relevant technology, and also
has a lot of international clinical input and expertise, and the tailwind of
13606 being a formal international standard.

(- HL7 is the home of CDA, and therefore connected deeply)

Would it be possible to connect these two (or all three?) groups, generate
archetypes from the IHE lab report, and show how this agreed clinical
content can usefully be documented and reused with the archetype technology?

About people: I put Francois Macary in cc here, he is coordinating the IHE
lab report work, and also responsible from a national view in France.
Francois, we did talk about these things recently on the phone. I also cc to
Andries Hamster, who is coordinting the lab report work from the Netherlands
side, and Harry Rhodes, who is active in HITSP in the USA. Alexander Mense
and Stafan Sabutsch are part of the CDA work in Austria, representing HL7
Austria. Frank Oemig is very active in HL7, in Germany and internationally.
Wolfgang Dorda and his group at Medical University of Vienna are deep into
13606 for many years, and seem to me one of the few who really understand.
Bernd Blobel keeps telling me that above 13606, CDA and the rest we do need
a lot more specifications on how to build and connect and check things
formally and mathematically. Over the years I slowly tend to believe him
there. We might realise exactly what he means once we realise that a few
things really do not fit together. I can see him jumping in happily then,
saying: "I kept telling you that since 1981, and here is the solution". May
we be able to gracefully realise, learn, adapt and use it when the time
comes. Sure a lot are missing here.

Going through this will not be a smooth ride, and we will have to prove many
novel ideas in practice. The hope is that in the end we will be able to show
clinicians and vendors exactly what CDA is for, and where it obviously is
more efficient to use archetypes.

We do have the Istanbul ISO / CEN meeting in October, and it would make me
very happy to see at least some starategic / formal light on the horizon by
then. Comments are very welcome, should you find the time, and I would be
very happy to discuss this further with whoever is interested.

Well, this is it from Vienna for the moment. Again, all the best for your
chairmanship, I am sure this is an interesting experience, and I am happy to
be at least a small part of it.

Greetings from Austria, and see you soon,
Stefan Sauermann

Acting Program Director
Biomedical Engineering Sciences (Master) University of Applied Sciences
Technikum Wien Hoechstaedtplatz 5, 1200 Vienna, Austria
Tel: ++43-(0)1- 333 40 77 - 988
sauermann@technikum-wien.at
http://www.technikum-wien.at

5

Hi Stefan,

I would suggest that in this eternal quest to ‘merge standards’ (I have been hearing about it for 10 years now), we need understand that standards are not all the same. To understand the differences we need a small standards typology. The following is a rough classification.

  • A - standards for concrete purpose-specific schemas, messages etc, such as for particular kinds of re-imbursement, order, lab result etc; These schemas only have one use (although it might be quite wide) and are almost always hand-crafted

  • Characteristics:

  • Modelling

  • every message schema has to be hand built;- generally limited re-use of elements between messages;- no reuse at all across implementation technologies, there is no way to use a message definition to generate GUI elements, service interface or other expressions;- Interoperability

  • functional interoperability is achieved (within the limits of local variations of message implementations)- semantic interoperability is possible depending on how tightly controlled the definitions and use of coding are

  • systems suffer from semantic incoherence from GUI to persistence layers, because their messages are developed and implemented separately from their GUI capture and display, persistence, and service interfaces

  • very limited support for querying

  • Clinician engagement:

  • usually difficult for clinicians to engage with in order to define content for each new message => messages only approximate requirements- Economics

  • inflexible; changed requirements => new message definitions- relatively low cost of use for a given message, since message structure fully mapped out - implemeters only have to generate prescribed content; no theoretical understanding required

  • scalable to some point but with a linear increasing cost and often NxN complexity characteristics

  • costs of system building borne separately

  • Examples

  • EDIFACT

  • HL7v2 messages

  • HL7v3 messages (slightly more generic message production approach, but vastly higher development cost per message compared to HL7v2)

  • ASTM CCR message (one size fits all approach)

  • B - standards for concrete generic schemas, which can carry a wide variety of content:

  • Characteristics:

  • Modelling:

  • only a single schema required; much cheaper to implement at a basic level

  • however no controls on what how content is expressed in the structures defined by the schemas; two implementers are most likely to develop two different configurations to express ‘vital signs observations’- Interoperability:

  • functional interoperability guaranteed (single shared data schema)- semantic interoperability likely to be poor / chaotic / unmanaged

  • basic querying supported but only useful if content structures standardised

  • Clinician engagement

  • no direct way for clinicians to engage; clinical modelling usually done (badly) by software developers- Economics:

  • relatively cheap in limited local contexts

  • not scalable

  • some software re-use within systems

  • Examples

  • EN13606-1 XSD on its own

  • HL7 CDAr2 XSD on its own (more or less, although it is only partly generic at the Entry level)

  • openEHR Reference Model expressed as an XSD or other similar format on its own

  • C - standards that define concrete generic schemas, plus a formal way of defining content that can be used with these schemas that has the effect of controlling instances of these schemas (i.e. actual documents, XML):

  • Characteristics - as above:

  • Interoperability

    • semantic querying supported

  • Clinician engagement:

    • clinicians can directly engage and build content models for use with schemas
    • modelling governance framework required
    • separate modelling still required for many aspects of systems, particularly GUI and service interfaces

  • Economics

  • higher costs of centralised / regional planning & governance

  • lower incremental costs (i.e. cost of deal with each new requirement)

  • higher implementation cost per site; some level of theoretical understanding required

  • reduced cost of systems due to some software re-use

  • highly scalable with a cost characteristic probably of a NlogN shape

  • possibility of concrete gains in preventative and personalised health due to ability to do true semantic querying through and across EHRs

  • Examples:

  • EN13606-1 + EN13606-2; caveat: EN13606-1 doesn’t provide a direct basis for many useful clinical archetypes; no templates

  • HL7 CDAr2 + HL7 templates (schema specialisations of CDA main schema; limited reuse)- openEHR RM XSD + archetypes + templates

  • D - standards that define a framework for defining reusable formal clinical content models, that can be used with abstract generic schemas to be able to generate various concrete generic schemas (message defs, XSDs, Xforms, java code, DB schemas), and to generate concrete purpose-specific concrete schemas.

  • Characteristics as above:

  • Clinician engagement:

    • getting towards single-source modelling - clinicians can model once and have their semantics appear everywhere.

  • Economics

    • lower implementation cost per site - same as for using hand-built messages
    • significantly reduced costs of system due to pervasive re-use of generated artefacts- Examples:

  • openEHR abstract RM + archetypes + templates;
    openEHR abstract RM ==> generate ==> multiple concrete expressions, including various XSD, database schema, Java code, C# code, and many more;
    openEHR operational template (incorporating archetypes & reference model elements) ==> generate ==> Template Data Schema (TDS) e.g. for messaging, display.

The last kind is what we have been working on in openEHR - it is getting toward the goal of fully semantically informed systems and interoperability engineered within the one framework. Clearly in the above you cannot just compare openEHR with CDA with HL7v2, with whatever else. The overall framework in each case brings significantly different advantages and cost characteristics. Until recently, openEHR was not the cheapest to engage with if you are a single implementer site or company; this has changed due to the TDS; previously message-oriented standards were cheaper to engage with from a single site point of view. However if you are a region or a country, then the cost advantages of a better framework may make a qualitative difference on national health budgets.

I think that if health authorities and governments don’t realise the qualitative differences, they will not succeed in creating a sustainable e-health framework (i..e they will simply succeed in creating the only kind that we know of to date, which is one that has to be recreated every few years).

I did not include IHE above, because it is really a ‘standard’ for a transport system for other content developed by whatever means. But: consider how useful it would have been to have the IHE lab report definition generated from trly reusable content models of lab reports, that could also be used for other purposes. I am not saying that the various kinds of standards can’t be made to work together - they possibly can (some are easy - e.g. openEHR / 13606); the above typology helps show how they could be integrate and what the costs are likely to be (and therefore what integrations make sense).

  • thomas beale

Stefan Sauermann wrote:

6

Hi Thomas,

Thanks for this excellent overview, it’s very helpfull.

One short question? How could I explain ‘semantic querying’ to a non-technical person

Cheers,

Stef

7

Stef Verlinden wrote:

Hi Thomas,

Thanks for this excellent overview, it’s very helpfull.

One short question? How could I explain ‘semantic querying’ to a non-technical person

Cheers,

Stef

Hi Stef,
I missed out ‘semantic interoperability’ in the last categories, which is of course what underpins semantic querying.

Semantic querying is not a completely simple concept in my mind. I would explain it as being able to query the data such that the answer of any query:

  • is independent of the data capture form or grouping of data

  • may include data from different sources and provider enterprises (i.e. can be based on merged data, or even done as a distributed query)

  • correctly takes account of real-world context (particularly time)

  • correctly takes account of data status (actual=N v target=N v mean=N etc; or actual X v risk of X v no risk of X etc)

  • correctly matches concepts (i.e. identified categories of things, e.g. serum sodium, hypertension, viral infection, …)

  • can therefore be safely used as a basis for inferencing, i.e. queries on data about an individual or group can be processed against an ontology like Snomed (when the latter is safe to use;-)
    As a side-effect of all these, semantic queries should be completely independent of the concrete database schemata which may be used to persist health information; they should therefore be ‘portable’.

This concept of ‘semantic query’ can’t really exist without the data either being represented using semantically strong models and formalisms, or existing data having been re-processed into such a form. The latter is achievable in most cases, and we use openEHR templates to perform the conversion.

To try and summarise in a sound-bite, maybe we could define a semantic query as one that works correctly regardless of the origin, capture method, or persistence details of the data.

  • thomas
8

Dear Tony,

Congratulations and thanks for taking up this role.

You asked "what are the *top 5* things you would like to see the
openEHR foundation tackle to move us all in the right direction over
the next
year/18months and better support your own challenges as a
clinician?". Here's my list:

- an 'top level' archetype repository hosted and mainained by an
independent organisation which can assure the quality and
'beschikbaarheid'
- per country a local organisation to review, adapt if necessary and
maintain the local archetypes
- a good course specifically for clinicians how to create archetypes
and templates en user groups where experiences can be shared.
- a clear(er) structure how and where requests functional
requirements for archetypes can be addressed and by whom. Please
don't take this personally but from a distance it seems that all the
request come from the NHS right now and there's not much room for
'others'. In itself it is great that the NHS puts so much effort and
trust in openEHR, but one should try to avoid the picture that
openEHR=NHS. On my personal 'wish list' are still: 1) a manner to
establish if an measurement if performed according a certain protocol
and if yes, which and did the measurement comly to this protocol/
standard. 2) a manner to 're-use' devices information, so that I
don't have to fill out all the device details every time one
performes a measurement (also see my mails sended to the clinical
list regarding this topic a while ago)
- administrative archetypes: how can I bill hours on a certain action?
- tools to create templates including GUI's
- tools to create/add bussines rules

Cheers,

Stef

9

Hi Stefan

It is a big step forward having someone like Tony Shannon with his wealth of experience leading the clinical developments in openEHR. I am delighted that he has agreed to this role. In answering Stefan, as a clinician, I see the world very differently.

I see the first need for standardisation being the clinical content that we want to share - this can be laboratory results, orders, blood gases, differential diagnoses, problem lists, medication lists, weight etc etc. If we are to have interoperability we have to be able to do this in a straight forward manner where clinicians can really agree to the outputs and technicians can work with these. It also ensures that data specifications are relevant at the point of care and can meet the reporting requirements and support distributed work flow. It is a form of collaborative configuration of eHealth - and as such can save massive amounts of money.

The next thing to standardise are the terminologies to support each content specification - not a terminology for everything, rather one that actually supports what we want to share. This task is orders of magnitude more simple if you start with the content specifications. This ensures we assist the capture of key data (not everything) in a way that supports complex inferencing and improves the prospect of reuse of decision support.

After this, it is essential to be able to query clinical data based on the specifications - this requires a standard expression of what is data is requested in terms of the clinical content and the terminology. This means, regardless of implementation, the data can be accessed for reporting, decision support and distributed health care.

Finally, it would be good to standardise the integration and outputs from the clinical data environment. Again millions are spent around the world working with different messages and formats and standardisation of content, terminology and query allows

One step on from this is a standard EHR specification, such as openEHR, which provides all of the above. It does encroach on current approaches and bring capabilities that are not presently available. But if we are proposing a way forward, it must provide a superset of capability and ideally add substantial new prospects.

If you take this view then the actual technology that transmits things down the wire becomes rather more flexible. Within the openEHR environment we can now populate health records in a variety of ways - using IHE, direct web services, HL7 v2 messages, CDA etc - as long as we know what is being sent and that it conforms to the clinical models specified using archetypes.

I believe that Austria, like all the other countries trying to make this a success, will find that such an approach is quite complementary to the technical approaches. It also ensures that the outputs are suitable for future use in an increasingly aligned environment.

Cheers, Sam

Stefan Sauermann wrote:

(attachments)

OceanInformaticsl.JPG

10

I am not asking to merge standards. I am asking for cooperation to show on a large scale and in real world examples where each standard shall be put to use for which purpose. Cooperation with the IHE lab report group may be a useful starting point. There may be better ones.

Greetings from Austria.
Stefan Sauermann

11

Stefan Sauermann wrote:

I am not asking to merge standards. I am asking for cooperation to
show on a large scale and in real world examples where each standard
shall be put to use for which purpose. Cooperation with the IHE lab
report group may be a useful starting point. There may be better ones.

*I think it is quite a good one.

- thomas

12

Ha!
I do sense an air of agreement here!
Makes me very happy!
Are there others who might agree?

See you, greetings to the other side of the planet,
Stefan

[mailto:openehr-clinical-bounces@openehr.org] Im Auftrag von Thomas Beale

13

Stefan Sauermann wrote:

Ha!
I do sense an air of agreement here!
Makes me very happy!
Are there others who might agree?

See you, greetings to the other side of the planet,
Stefan

*let's hope London isn't quite that far from Vienna just yet (although
they do say there may be some continental drift in 2012;-)

- thomas

14

Don’t worry Thomas, if something goes a little bit wrong in the next few days at CERN, we can all unite in an unprecented level of harmony in a nice little black hole.

Of course, the issue about being close to or far away from each other in a black hole is an important one, but I have the feeling that it would not matter to us then.

Sorry, had to say it.

15

Stefan,

Even I agree.

Gerard

– –
Gerard Freriks, MD
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands

T: +31 252544896
M: +31 620347088
E: gfrer@luna.nl

Those who would give up essential Liberty, to purchase a little temporary
Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755

16

It not really an Irish thing. I have been been silent too and from Nigeria.
Good luck with the post. hope to contribute more actively

Sanyaolu Ameye

17

Ooooh! So Nigeria isn't the capital of Ireland?
:slight_smile:

Although IANAC (I Am Not A Clinician), I would like to add another point
that might be worth discussing: the interoperability between openEHR
based systems and those of the Really Big Companies (Microsoft's
HealthVault & RelayHealth, Google's Health). They're gaining momentum,
and maybe we can ride on the wave along with them. Probably it's time
for openEHR to gear up some PR-machinery. The propaganda should be
backed up by tutorials, screencasts, lectures, workshops, flyers,
working demos, etc.

And finally, on the risk of being pedantic, but following these tips
would really make reading the mailing lists on PDA's (as many clinicians
do own) much more comfortable:

http://www.netmeister.org/news/learn2quote.html

Good luck on your new position!

Roger

18

I would like to add another point
that might be worth discussing: the interoperability between openEHR
based systems and those of the Really Big Companies (Microsoft's
HealthVault & RelayHealth, Google's Health). They're gaining momentum,
and maybe we can ride on the wave along with them. Probably it's time

http://www.ictzorg.com/home/id101-49805/nictiz_persoonlijk_zorgdossier_nuttige_aanvulling_op_epd.html
The Dutch ICT in health care organization (NICTIZ) is saying that the
mentioned systems from Microsoft and Google are useful add-ons to the
system Nictiz is defining (for more than 7 years by now, about gaining
momentum).

Nictiz is saying that those systems can be part of national EPD
(electronic patient dossier), but they should never replace the national
EPD.

http://www.ictzorg.com/home/id101-46903/kedzierski_van_mca_vws_kan_wel_stoppen_met_landelijk_epd.html
http://www.ictzorg.com/home/id101-42405/mca_onderzoekt_mogelijkheden_google_health.html
Kedzierski, member of the board of a big hospital (Alkmaar) is saying that
the personal health dossiers from Google and Microsoft can replace the
national EPD system from Nictiz. He is saying that in the USA Kaiser
Permanente, with 9 million patients has chosen for both the MS and the
Google system, and Cleveland Clinic chooses for the Google system only.

The Alkmaar hospital will make its choice after the summer, he says.

19

This was clearly meant geographically. I thought you are in Australia most
of the time. The standard deviation of your spatial distribution of
probability of presence is definiely wider than mine.

Anyway, happy to hear from you, wherever you are.
Stefan

[mailto:openehr-clinical-bounces@openehr.org] Im Auftrag von Thomas Beale

20

I would like to add another point
that might be worth discussing: the interoperability between openEHR
based systems and those of the Really Big Companies (Microsoft's
HealthVault & RelayHealth, Google's Health). They're gaining momentum,
and maybe we can ride on the wave along with them. Probably it's time

http://www.ictzorg.com/home/id101-49805/nictiz_persoonlijk_zorgdossier_nuttige_aanvulling_op_epd.html
The Dutch ICT in health care organization (NICTIZ) is saying that the
mentioned systems from Microsoft and Google are useful add-ons to the
system Nictiz is defining

...
Sounds reasonable.

Nictiz is saying that those systems can be part of national EPD
(electronic patient dossier), but they should never replace the national
EPD.
  

Never say never! If they have enough momentum (being funded by large
companies), their functional coverage can become more and more
extensive, making such a national EPD obsolete indeed in the long run.

http://www.ictzorg.com/home/id101-46903/kedzierski_van_mca_vws_kan_wel_stoppen_met_landelijk_epd.html
http://www.ictzorg.com/home/id101-42405/mca_onderzoekt_mogelijkheden_google_health.html
Kedzierski, member of the board of a big hospital (Alkmaar) is saying that
the personal health dossiers from Google and Microsoft can replace the
national EPD system from Nictiz. He is saying that in the USA Kaiser
Permanente, with 9 million patients has chosen for both the MS and the
Google system, and Cleveland Clinic chooses for the Google system only.

The Alkmaar hospital will make its choice after the summer, he says.
  

But he didn't say 'before <whatever deadline one can imagine here>' :stuck_out_tongue:
So we'll wait and see...

Roger