Introducing myself + question

Technical (archive)
21

Bill Walton wrote:

That's three things :wink:

just testing...

Seriously though, it sounds like we're on the same
page. Getting the system into day-to-day use in clinical settings is the
objective. Yes?

right.

2) Does the openEHR Foundation exist yet or is it still under formation?

It does exist as a legal non-profit organisation, but as an
international foundation, incorporated in the UK. The "openEHR" name and
other special marks (e.g. "conforms to openEHR vX.X" etc) are also
protected, ensuring that they are used for truly conformant systems and
applications.
   
Excellent.

THe Uuniversity College London has paid and supported that side of things are I believe will make some official announcement soon about the details on the website.

) I may simply not have discovered it yet, but I expected to find a
     

place

on your site where developers were engaged in conversation about the
components of the system they were developing. Could you share a little
about your operating model, particularly with respect to new developers
interested in contributing?

A number of developments are coming online. There is work being done in
C#, Java, Eiffel and XML-schema that I know of. Some of this will become
visible on the website in the next month or two.
   
I assume this work is being done by some of the founding members and that
they're communicating back-channel. Yes?

for the moment, but the intention is not to be secrett, it's just that we are trying to get to the following situation:
a) have a "release 0.9" of the specs up on the web, good enough and stable enough for everyone with work with, criticise etc
b) get the change control process documented and published
c) have a change request system in place

As some people have suggested, sourceforge does some of this kind of thing, so it may well be used for some software projects. openEHR is a bit unusual in managing specifications as well...

I managed a test automation group from '95-'00. As a consultant /
contractor, I'm typically engaged as a Project Manager with a technical
focus in requirements definition and testing. I'll look forward to the
opportunity to contribute once you've got the mechanisms defined.

sounds great. THe change management plan includes these kind of ideas - it's also what I did in a former life. Comments and suggestions will be welcome - we are not trying to set somethign in stone, just write a good enough first draft that sensible conversation can then take place.

Let me know if I can be of assistance. Process definition is a substantial
component of what I do.

excellent - I knew there'd be one lurking out there!

- thomas beale

22

Hi Dave,

David Forslund wrote:

IMHO, archetypes need to be specifiable independent of the platform and language, including the querying.

yes, we do too. We are working on a new (text) formalism for archetypes which we think will enable archetypes for openEHR, CEN and CDA to be interchanged. As soon as I have done enough work on it, I'll post a draft for comment.

   How archetypes are to be stored on disk should also not be part of the specification. Rather they should have a data model independent of platform and language.

even the current GEHR ones have that - they're instances of XML-schema. How they get converted and stored in any particular site is it's business. For example, I wrote an Eiffel kernel, and a converter to do XML->eiffel objects and store that. The DSTC did an XML system, and used the archetypes in their XML form.

I assume that if archetypes are specified by XSL Schema then one would use a form of XPath to query them(?). I actually like something
like the Object Constraint Language for this purpose, but this might not be popular.

Yes, we have been thinking about Xpath; in fact we would like to make the path mechanism in openEHR an Xpath subset if possible. You will see somethign like this in the draft formalism I mentioned above. OCL - I just did a review on this (http://www.deepthought.com.au/it/ocl_review.html - comments welcome) , I think there are a few terrible errors in there, but also a lot of nice things. We don't have enough experience on this. You may be able to spend a bit of time on this to help the effort!

We have used C++ for more than 15 years and find it not particularly easy to embed in other languages compared to other approaches.
It should have nothing to do with the OpenEHR specification.

It doesn't ...!

- thomas

23

Hi people,

lets put "EHR" into every email subject in the future, for Outlook Express

thanks :o)

24

Tom Culpepper wrote:

I again would like to reiterate may opinion on this list concerning the modeling of Healthcare.

The business of Healthcare (both Clinical and Administrative) needs to be modeled in a language, platform and operating system independent manner. This will provide the opportunity for folks to provide implementations that can be used across the widest spectrum while leveraging legacy systems. One such universal modeling language is UML (Unified Modeling Language) and the "OPEN" technology that is making this a reality comes from the Object Management Group (www.omg.com <http://www.omg.com/&gt;\) MDA (Model Driven Architecture).

well as you'll see in the specs there is no language-dependent stuff - it's all UML. The only slight problem at the moment is that OCL has some quite broken semantics which would prevent it being used properly for the constraints, but even then maybe we just have to go with it. In the specs currently, the constraints are expressed in a first order predicate form very similar to OCL. We'll have to fix tis eventually, but as almost no-one except Eiffel people can implement the statements directly anyway, it doesn't seem a big concern...

Making a decision to develop models that force people to use C, C++, Java, Effiel, Microsoft NT, Unix, MVS, or proprietary mechanisms will only hamper IT efforts for interoperable solutions.

right. I don't know why we get into these discussions really - the specifications are competely language independent (I'd have to say even moreso than OMG actually - IDL is actually quite C++/C oriented, but that's history - let's not waste our breath on it now!)

I also concur with David Forsland in the use of the Object Constraint Language.

Tom, I'm interested in what you think about the review I have done. See http://www.deepthought.com.au/it/ocl_review.html.

- thomas beale

25

Denis Petrushin wrote:

Hi people,

lets put "EHR" into every email subject in the future, for Outlook Express

I think we can ask the list managers to automatically put something standard in all messages. But you should be able to filter and sort based on "To: or cc:" - that's what I do in Netscape - it is always dependable - doesn't need any special tags in the subject line.

- thomas

26

Tom Culpepper wrote:

I again would like to reiterate may opinion on this list concerning the modeling of Healthcare.

The business of Healthcare (both Clinical and Administrative) needs to be modeled in a language, platform and operating system independent manner. This will provide the opportunity for folks to provide implementations that can be used across the widest spectrum while leveraging legacy systems. One such universal modeling language is UML (Unified Modeling Language) and the “OPEN” technology that is making this a reality comes from the Object Management Group ([www.omg.com http://www.omg.com/](http://www.omg.com <http://www.omg.com/>)) MDA (Model Driven Architecture).

well as you’ll see in the specs there is no language-dependent stuff - it’s all UML. The only slight problem at the moment is that OCL has some quite broken semantics which would prevent it being used properly for the constraints, but even then maybe we just have to go with it. In the specs currently, the constraints are expressed in a first order predicate form very similar to OCL. We’ll have to fix tis eventually, but as almost no-one except Eiffel people can implement the statements directly anyway, it doesn’t seem a big concern…

Glad to see that.

Making a decision to develop models that force people to use C, C++, Java, Effiel, Microsoft NT, Unix, MVS, or proprietary mechanisms will only hamper IT efforts for interoperable solutions.

right. I don’t know why we get into these discussions really - the specifications are competely language independent (I’d have to say even moreso than OMG actually - IDL is actually quite C++/C oriented, but that’s history - let’s not waste our breath on it now!)

I think that it is important, at times, to make sure this important point doesn’t get forgotten.

If the specifications utilizes UML then you are achieving the first step toward interoperability because UML is a modeling language not an implementation language and you can then have a Platform Independent Model (PIM) expressed in UML. Such a PIM can then be mapped to a Platform Specific Model (PSM) to target platforms like the CORBA Component Model (CCM), Enterprise JavaBeans (EJB) or Microsoft Transaction Server (MTS). Standard mappings should allow tools to automate some of the conversion. Such a PSM, again expressed in UML, can then be actually implemented on that particular platform. This is the OMGs MDA (Model Driven Architecture) http://www.omg.org/mda/

As far as IDL it is an Interface Definition Language used to allow multiple language mappings. One of the first was C and C++ and now Java. I would not discount it as “history” since it is a viable part of keeping legacy systems in the loop and in fact the Java rmic (Remote Method Innvocation Compiler) generates IDL from Java classes. This was done because Sun, a strong supporter, contributor and implementor of it’s specifications, went down the RMI road and quickly realized the need to interoperate with systems that utilize IDL.

I also concur with David Forsland in the use of the Object Constraint Language.

Tom, I’m interested in what you think about the review I have done. See http://www.deepthought.com.au/it/ocl_review.html.

I will get back to you as soon as I have some free time :slight_smile:

  • thomas beale

Tom

27

Rafal

We have seen this coming for some time and I would point out a few things
that seem clear:

1. That queries can be based across a number of EHRs or within one - the
oprimisation issues are somewhat different
2. That queries may return rows of data (like in current RDBS) or lumps of
data for viewing - 'data queries' or 'clinical queries'
3. Within each EHR the query may be limited to a specific composition
(transaction) type (ie and archetyped transaction)
4. Within transactions the query may be limited to specific organisers

All of these queries outlined to this point will return disparate data (even
if they are all entries) and will be very difficult to process - very useful
clinically. Examples are:

What examinations have been done in antenatal attendances
What therapies have been planned or implemented for people in outpatients in
the last week

Then we have queries that get to the data level - these will need to return
known data points in the entries. These will be accessed via paths. When
building these queries the enquirer will be asked which archetypes and which
paths (design time or run time) to return.

This would enable us to get a row of data such as:

For all patients who have had their blood pressure measured in antenatal
clinic - return the systolic and diastolic blood pressures and their weight.
For all patients who are on beclomethasone inhalers return the name and dose
of inhaled steroid and their peak flow measurements for the past year.

You will see that until the query addresses and entry archetype (like a
table in RDBS) you will only return information that is clinically readable
but difficult to process. The entries then become the equivalent of the
tables - the paths are the equivalent of the columns.

Some efficiencies come from running queries on one patient - when the query
engine can use the archetypes in that EHR as the set of archetypes on which
to query - you don't have to look if they are not there. Also, archetypes
become the bases of indexes.

Cheers, Sam

28

Greetings,

Could somebody kindly provide a sample or link to what is done already for
the OpenEHR.

From my side I'd like to apply my experience in developing of change

request/ trouble report handling system that is implemented at Ericsson.

Trusting the above to your entire satisfaction, would you accept my
distinguished wishes. =)

Denis

Hi Thomas,

Thomas Beale wrote:
>
> Bill Walton wrote:
>
/snip/
> >
> >1) Is it your intention that openEHR eventually become a viable
alternative
> >to commercial offerings, or is openEHR intended as an academic /

research

> >tool?
> >
> well, I can say two things:
> a) the core people currently involved in developing the specifications
> intend to try to change clinical computing - everywhere.
> b) as more people become more active in openEHR, they will bring their
> interests to the table. Most of the ones I know of are interested in
> changing clinical outcomes in the real world.
> c) academia and research contexts are of course important, and are where
> a lot of innovation comes from. So we should not discount these. But the
> real aim is to change things (rather than just talking about it, to
> paraphrase Marx;-)

That's three things :wink: Seriously though, it sounds like we're on the

same

page. Getting the system into day-to-day use in clinical settings is the
objective. Yes?

>
> >2) Does the openEHR Foundation exist yet or is it still under

formation?

> >
> It does exist as a legal non-profit organisation, but as an
> international foundation, incorporated in the UK. The "openEHR" name and
> other special marks (e.g. "conforms to openEHR vX.X" etc) are also
> protected, ensuring that they are used for truly conformant systems and
> applications.

Excellent.

> >3) I may simply not have discovered it yet, but I expected to find a
place
> >on your site where developers were engaged in conversation about the
> >components of the system they were developing. Could you share a

little

> >about your operating model, particularly with respect to new developers
> >interested in contributing?
> >
> A number of developments are coming online. There is work being done in
> C#, Java, Eiffel and XML-schema that I know of. Some of this will become
> visible on the website in the next month or two.

I assume this work is being done by some of the founding members and that
they're communicating back-channel. Yes?

> It is still early days, so how implementation work and collaboration

pans

> out is not entirely forseeable.

Understandable.

> However, it is planned to get more people involved to give
> of their expertise on collaborative software development, developing
> test cases, conformance criteria and so on.

I managed a test automation group from '95-'00. As a consultant /
contractor, I'm typically engaged as a Project Manager with a technical
focus in requirements definition and testing. I'll look forward to the
opportunity to contribute once you've got the mechanisms defined.

> The main effort to this
> point has been to get a set of specificatinos good enough to start work
> on. It is believed that the current ones are, and a baseline will appear
> soon.

Saw your earlier note on timeframes and was encouraged.

> Mechanisms for submitting change requests etc will also appear
> soon, but of course, none of this work is instant!

Let me know if I can be of assistance. Process definition is a

substantial

29

Ok, this is great - we have two kind professionals with experience with change management. I will be very happy for you to review a basic draft for change management in openEHR, and work on it together. The timetable is about 6-8 weeks. Inside the current 3-4 weeks we hope to have a basic set of plans written for comment. THese will be pretty loose, with the intention that people such as yourselves can make changes.

I think the aims for change control in openEHR need to:

- be simple and clear. In "heavy weight" software engineering there are a lot of quite complex documents describing CM, SQA, test plans etc etc (e.g. like the IEEE stds) ; this is fine for software engineers, but we don't want to overwhelm the many people in the community who are not engineers

- there will be a set of plans relating to the official specifications - this is what we are developing here. It needs to be recognised that that change management, release plans for any outside given project based on openEHR will usually be outside these plans - e.g. it may be done by a group on sourceforge, using completely different guidelines. I think this is fine. We just have to be clear on what is official openEHR IP and what is not. (Anything can become openEHR IP by donation. The consequence is that the work gets taken care of, even if the donor doesn't have the resoruces to do anything further with it, and it will be guaranteed to be freely available forever, according to the openEHR open source licence. I'm not sure of the official rules, but there will be some published).

- we do need to be fairly careful with how we identify releases and sub-releases, particularly so that any new change is put into the correct release, and also so that any outside project can get a clean baseline for any release and know that it is based on "openEHR v1.3" or whatever. I'm sure Denis and Bill will have good ideas here, by the sound of their experience.

Anyway, we are aiming to have something in place inside the next 8 weeks.

- thomas beale

Denis Petrushin wrote:

30

Count me in. I'll look forward to hearing more when you're ready.

Best regards,
Bill