certification and verification of OpenEHR

Technical (archive)
21

Christopher Feahr wrote:

I'm not sure we are quite ready to think about the big "EHR-in-the-Sky"
repository that exists ONLY for the purpose of keeping local user
records in synchrony...

I don't think "keeping local records in synchrony" makes much sense in a lot of cases. If I were a clinician in hospital A, I want to see the local EPR system + the views available from the regional EHR system. I don't see much value in pulling down copies of all that data into my EPR system, with all the transformation software that that would usually imply (usually object -> relational, archetyped -> non-archetyped etc). In general performing writes to disparate back-end systems is expensive and error-prone. However, if you are positing a local EHR cache, sure, why not. That's just a performance measure.

although we seem to be drifting toward that
model and it is probably an achievable model. The main repository for
such a model could live nicely in India or anywhere. I am NOT a
security expert, but I know that you would have at least a couple mirror
sites and other redundancy built in. AND... perhaps of greatest comfort
to providers... each provider's local EHR system remains always intact
and always kept up-to-the-minute through record refreshes each time he
connects to the [hopefully, small number of] global repositories.

Opinion here obviously differs, and specifications like openEHR are agnostic, but as an engineer, I would not design EHR systems like this. I would distribute them, and have the primary instance of most records in EHR systems which served the needs of "most of the carers for a patient most of the time, plus the patient". As noted in another post, a different model is needed for mobile patients, which is more likely a small number of national/global secure e-health webportals.

Step #1 still seems to be agreement on ONE standard information model...
with only the constraints that are invariably required for each
particular element of health data. Archetypes that express additional
business rules about the information and relate it to other information
elements will be much more difficult to agree on. I think we should try
to standardize that layer eventually, but that will require a very
efficient mechanism to be constructed for getting input from doctors
without them having to attend standards meetings (because they won't
attend!).

archetypes will be much more difficult to agree on. But the point is:
- it is up to domain experts to do the agreeing, not IT people as in the past.
- tools can be (are being) written for handling archetypes, ensuring authors create technically correct archetypes
- standards are emerging for expressing archetypes, and showing how they are related to underlying information models

I don't expect that many globally standardised archetypes, but I do expect a lot of national and regionally standardised archetypes, and a lot of archetype. standardised in specialties. THe evolution of this process will largely be up to domain organisations like specialist bodies, medical colleges etc. Organisations like WHO also could be involved.

In my view, the EHR effort... partly by virtue of the inclusion of the
"record" concept... is starting at too complex a level... at a point
where we are almost designing a particular business management system in
the standard.

The EHR models around at the moment include openEHR and the CEN ENV 13606 standard. If you think these are too complex, we need to know how, in order to improve them.

A rule-free standard model for the INFORMATION should
exist first. From what I understand, SNOMED CT is a very good start on
that.

SNOMED-CT is not a model of information, but an ontological terminology - it is an expression of knowledge. There are no conclusions whatever to draw from it in terms of EHR information models other than at the data level. You will see that in the Coded term data types of openEHR, HL7 and other specifications, that certain relationships etc which exist in places like SNOMED are catered for. But this is just data types. Structuring information comes after that, and it is not SNOMED-CT's business. What it's business is - is supporting decision support.

Also as a standard, we should make an effort within each care
domain to model the actors, places, and things in healthcare, the
relationships between them that are always true, and the relationships
among the information elements that are always true. This can serve as
a useful framework or high-level model for the much more granular and
often unique process and information models of each local
user-enterprise.

right. This is exactly the openEHR approach. Have a look at the reference models, including for demographics (http://www.openehr.org/Doc_html/Model/Reference/demographic.htm), and you will see that is exactly what the approach is. Actually, the demographics model is intended to work for all care domains. Undoubtedly it has to be improved before it does that, but that's what implementation and testing are for...

- thomas

22

>
right. This is exactly the openEHR approach. Have a look at the
reference models, including for demographics
(http://www.openehr.org/Doc_html/Model/Reference/demographic.htm), and
you will see that is exactly what the approach is. Actually, the
demographics model is intended to work for all care domains. Undoubtedly
it has to be improved before it does that, but that's what
implementation and testing are for...

Why are parties versioned? Human cloning is banned in most countries,
and so far unsuccessful in the rest. Maybe for a Raelian EHR? Seriously,
the attributes of a party change, but the identity of the party remains
the same? Or is versioning just an easy way of incorporating the time
domain into the model? If so, it is easy, but inefficient.

Tim C

23

Tim Churches wrote:

right. This is exactly the openEHR approach. Have a look at the reference models, including for demographics (http://www.openehr.org/Doc_html/Model/Reference/demographic.htm), and you will see that is exactly what the approach is. Actually, the demographics model is intended to work for all care domains. Undoubtedly it has to be improved before it does that, but that's what implementation and testing are for...
   
Why are parties versioned? Human cloning is banned in most countries,
and so far unsuccessful in the rest. Maybe for a Raelian EHR? Seriously,
the attributes of a party change, but the identity of the party remains
the same? Or is versioning just an easy way of incorporating the time
domain into the model? If so, it is easy, but inefficient.

the attributes do change. The point is to know what the party looked like at any given point in time in the past - so if you reconsititute the EHR for 2 years ago, you also get the 2-years ago view of all the demographic entities mentioned in it, including the patient. Without versioning of demographic information, medico-legal investigations into past states of the EHR can't work...

Not sure what you mean by "inefficient"..

- thomas

24

Tim,
I can imagine several workable funding models for healthcare. The one
we have in the US is simply the straightforward "selling services for
$", perverted by the brokerage model that insurance has superimposed on
it. In my personal opinion, neither model makes sense for a service
like healthcare... a service that even the most Scrooge-like among us
believe everyone should be have in a time of need.

So I think we are in agreement that a national health service is more
socio-ethically correct than the U.S. mercantile model. I have not
studied the metrics for success of the NHS model, but your numbers sound
credible. We are good at a lot of things in the US, but we seem to
struggle with and mostly reject the value proposition inherent in
considering the needs of the greater community along with one's own.
That's why US feet have so many bullet holes in them!

With regard to EHRs of all sizes... yes, they will look different, and
if some of those differences were not there, a higher level of
interoperability MIGHT result. But again, I contend that it is the DATA
that is most desperately in need of a standard. The EHR efforts seem to
want to standardize both the data AND the horse it rode in on. I think
that is too much... and will simply not be adopted fast enough to ever
reach critical mass.

The real question is, "Where is the best place to start enforcing a
degree of uniformity?" I believe it is best to begin with an
understanding of how healthcare processes are alike around the world....
then derive a common set of functional requirements that support the
universe of [important/critical] care processes... then build a model of
the DATA to support the functional requirements. If we can massively
involve providers in such an effort, I believe providers would accept
standardizing at the process/requirement level... because they already
feel like they are doing that with our published "evidebce-based
practice guidelines".... but they will argue til the cows come home
about what the darned records should look like!

Eventually we might have to create standards for giant data
repositories... the big EHR-in-the-sky... but maybe not. If there
aren't very many such repository systems, or if a very large one (say,
one maintained by the US govt.) made its architecture specifications
public, then that might be all the world requires as a de facto
standard.

We may have too many cooks in the EHR kitchen at the moment. Many of
these proposed record models look useful, but which flavor(s) of which
ones are likely to become the ubiquitous standard? (The rest will have
to go away or risk diluting the success of the ONE... thus, reducing
interoperability for ALL). It just doesn't seem to be the right place
to be digging for what we are after.

Regards,
-Chris

Christopher J. Feahr, O.D.
Optiserv Consulting (Vision Industry)
Office: (707) 579-4984
Cell: (707) 529-2268
http://Optiserv.com
http://VisionDataStandard.org

25

Tim Churches wrote:

>
>
>>right. This is exactly the openEHR approach. Have a look at the
>>reference models, including for demographics
>>(http://www.openehr.org/Doc_html/Model/Reference/demographic.htm), and
>>you will see that is exactly what the approach is. Actually, the
>>demographics model is intended to work for all care domains. Undoubtedly
>>it has to be improved before it does that, but that's what
>>implementation and testing are for...
>>
>>
>
>Why are parties versioned? Human cloning is banned in most countries,
>and so far unsuccessful in the rest. Maybe for a Raelian EHR? Seriously,
>the attributes of a party change, but the identity of the party remains
>the same? Or is versioning just an easy way of incorporating the time
>domain into the model? If so, it is easy, but inefficient.
>
the attributes do change. The point is to know what the party looked
like at any given point in time in the past - so if you reconsititute
the EHR for 2 years ago, you also get the 2-years ago view of all the
demographic entities mentioned in it, including the patient. Without
versioning of demographic information, medico-legal investigations into
past states of the EHR can't work...

Yes, yes, of course, that is taken for granted.

Not sure what you mean by "inefficient"..

Well, I have changed my address several times during my life, but not my
sex or my name. This can be modelled by either keeping an address
history within my demographic record (that is, explicitly modelling the
time domain), or by keeping timestamped versions of my entire
demographic record. openEHR seems to adopt the latter approach. That
approach is less efficient space-wise, but that hardly matters these
days. It is more efficient if the (medico-legal) query is "what was my
demographic record at date yyyy-mm-dd?" Much less efficient if the query
is "how many times did I change my address?". Very, very inefficient if
the query is "what is the mean number of address changes in the entire
population?". I am thinking from an aggregate epidemiological POV, not a
clinical/medico-legal individual patient POV. But then, satisfying the
former POV is what data warehouses, populated from EHRs, are for...

Tim C

26

Christopher Feahr wrote:

With regard to EHRs of all sizes... yes, they will look different, and
if some of those differences were not there, a higher level of
interoperability MIGHT result. But again, I contend that it is the DATA
that is most desperately in need of a standard. The EHR efforts seem to
want to standardize both the data AND the horse it rode in on. I think
that is too much... and will simply not be adopted fast enough to ever
reach critical mass.

not sure what you mean here... three specifications relating to the EHR are:
- the CEN ENV 13606 EHR Exchange standard (abstract)
- the HL7 CDA (an XML standard)
- the openEHR models (abstract + XML)

All of these have a pure information component or container, which is equivalent and converging, as follows:

- CDA Document
- CEN Composition
- openEHR Transaction (soon to be renamed Composition)

You can have a look at all these and you will see that they are all models of the minimum information that can be sensibly included in an EHR commit. None are particularly complex.

Inside the Document/Composition container, you find "Sections"/"Organisers" and then something like "Entries". How Entries are structured depends on what you are trying to record. Basic models, or "analysis patterns" available for Entries are:
- the CEN generic hierarchy data structure
- the stricter but still generic openEHR subtypes of Observation (past information), Evaluation (decisions), Instruction (prospective information)
- the HL7 RIM model of acts
- models of plans
- etc

These specifications have been converging for some time now, and continue to do so with people from all 3 organisations working with each other. I would say we are making pretty good progress overall. (We'll know more at the HL7 meeting in Memphis, the CEN meeting in Aarhus in September;-)

- thomas beale

27

Tim Churches wrote:

Not sure what you mean by "inefficient"..
   
Well, I have changed my address several times during my life, but not my
sex or my name. This can be modelled by either keeping an address
history within my demographic record (that is, explicitly modelling the
time domain), or by keeping timestamped versions of my entire
demographic record. openEHR seems to adopt the latter approach.

Actually, it doesn't, but it's not obvious I agree. If you look at the common RM (http://www.openehr.org/Doc_html/Model/Reference/common_rm.htm) you will see that there is a class VERSION_REPOSITORY<T> and a class VERSION<T>. The former is a functional interface to the stack of versions for one versioned entity, which might be a PARTY, a TRANSACTION of whatever. But it does not say how to implement this. A space-inefficient, but simple, implementation would be to just have successive complete copies. A more efficient way would be to adopt the algorithm used in versioning object databases which only stores new objects in each version, and uses special markers for deleted objects. Normally this would be done backwards, so that it is always the most recent version that is complete, since it is the one most likely to be retrieved all the time.

That
approach is less efficient space-wise, but that hardly matters these
days. It is more efficient if the (medico-legal) query is "what was my
demographic record at date yyyy-mm-dd?" Much less efficient if the query
is "how many times did I change my address?".

for a single patient, neither of these is much work - it's trivial, regardless of the representation of versions

Very, very inefficient if
the query is "what is the mean number of address changes in the entire
population?". I am thinking from an aggregate epidemiological POV, not a
clinical/medico-legal individual patient POV. But then, satisfying the
former POV is what data warehouses, populated from EHRs, are for...

sure - and I agree - this is what data warehouses are for. This kind of querying requires forethought. If you know you are going to be collecting say 50 statistica, including "number of times change address", then you start designing software agents to capture the data as they go into the EHR, e.g. a simple address change counter for your query. Then generating the result is trivial.

- thomas

28

sure - and I agree - this is what data warehouses are for. This kind of
querying requires forethought. If you know you are going to be
collecting say 50 statistica, including "number of times change
address", then you start designing software agents to capture the data
as they go into the EHR, e.g. a simple address change counter for your
query. Then generating the result is trivial.

Alas, the nature of discovery dictates that that one does not always (in
fact, rarely) know what questions need to be answered (which statistica)
in advance. But making ad hoc queries against massive data warehouses
efficient is outside the scope of this list (but of considerable
interest to future epidemiologists).

Tim C

29

Tim,
Data mining and ad hoc queries does not sound out of scope to me.
Sounds like a primary use for the EHR-data.

Christopher J. Feahr, O.D.
Optiserv Consulting (Vision Industry)
Office: (707) 579-4984
Cell: (707) 529-2268
http://Optiserv.com
http://VisionDataStandard.org

30

Christopher Feahr wrote:

Tim,
Data mining and ad hoc queries does not sound out of scope to me.
Sounds like a primary use for the EHR-data.

well, a "secondary" use - clinical patient care is the "primary" use;-) (sorry - just had to say that since it is in most papers, projects you will find on the EHR). But I agree largely - you can't have big epidemiological or research queries from the CDC or somewhere killing your production hospital database - that's what data warehosing is for - transforming data for efficient population querying , and separating out the resources for the primary production use of the information from all other uses..

- thomas beale

31

Chris,

If there
aren't very many such repository systems, or if a very large one (say,
one maintained by the US govt.) made its architecture specifications
public, then that might be all the world requires as a de facto standard.

The US govt. has zero credibility right now in many parts of
the world (among the people, that is, not their governments).

OTOH, there already IS one maintained by the US govt. that has
public specs: Vista. Uptake has not exactly skyrocketed since
(although it did accelerate in the last 6 months or so).

Karsten

32

Dear Chris,

CEN/TC251 is co-operating with OPENEHR.

We are in the process to define a next version of our EHR standard.
It is basicly a standard that defines a Document and facilities for handling
it properly. Plus it will enable to locate doucment items in space and time.
On top of this the standard (EN136060) will include Archetypes.
With these archetypes all kinds of clinical concept models can de defined by
national, loca', regional organisations.

Where appropiate the Archetypes will be able to use items like SNOMED-CT.
And record coded information. The Archetype (=clinical concept model)
The Archetypes need a stable set of archetype-fragments that define for
instance the demographics of persons and organisations, but also the generic
structure of a referral letter,the generic investogation, etc.

We at CEN think it is a tractable problem.
And the people from OPENEHR have demontrated that it is in several beta
implementations.

I can refer you to the OPENEHR website and the CEN one (www.CENTC251.org)
for kore information.

Gerard

33

Thomas,
Thanks for the comments. My only caution about asking physicians to
comment on the desirability of EHR-system proposals is that they may not
understand [what we mean by] our questions... and we probably won't
really understand [what they mean by] their responses.

When we ask for input from practicing physicians, I would rather pose
very discrete questions, such as: "When you do this procedure, our
committee believes that these information components are absolutely
necessary... do you agree?"

Anyway... this has been a busy few days with all the activity in the HL7
EHR SIG, and I guess I was in a particularly verbose mode... even for
me... yesterday! (I saw several "please remove me! messages posted
today... I hope I didn't drive away any of your "regulars customers"!)

Take care,
-Chris

Christopher J. Feahr, O.D.
Optiserv Consulting (Vision Industry)
Office: (707) 579-4984
Cell: (707) 529-2268
http://Optiserv.com
http://VisionDataStandard.org

34

Hi Chris,

Good comments. Don't hold back!

Regarding Providers I must say that they surprise me at times. My primary
Physician obtained a degree in Electrical Engineering prior to his medical
degrees. He has modernized his internal medicine department proficiently.

He could use some help on the records systems but I believe he has the
basics in-hand. Ask him and one might get a verbose response.

-Thomas Clark

35

Absolutely! I'm sure there are thousands of un-tapped pockets of
technical brilliance out in our provider community... but most very busy
with patients and, with the exception of nut-cases like myself, probably
not THAT passionately interested in information technology. However,
virtually all of these folks are experts with respect to the "business
requirements" of medical management software... as are many of their
office managers. We need a mutually agreeable methodology for "mining"
this business knowledge, without taking up too much of their time.

So the task is to construct a mechanism for proactively reaching out to
a [self-registered] vetting pool of provider business experts around the
world. We would build our straw-man models, requirements-lists, etc....
then decompose them (using special tooling) into discrete questions that
make sense to the provider community... perhaps supplemented with
diagrams and graphics that they would readily understand (without first
attending UML Boot Camp)... and collect their structured responses into
a database.

Clearly, we will have to give some thought to (and find a source of
funding for) the tool set I am describing. But at the end of the day,
we should have a mechanism for formally vetting each section of our
user-specific, functional model of health care processes.

(This will also be a way, incidentally, to find those pockets of tech.
brilliance, and to draw these "cursed" individuals further into the
bottomless time-sink of "healthcare standards development". Based on my
US-experience, I often say that "doctors won't attend SDO meetings".
But I don't think that's entirely true. When we have an SDO that is
focused squarely on the business needs of smaller providers... and
doctors have gained an understanding of what is being discussed at SDO
meetings... then I suspect that quite a few will be interested in a more
active role. However, the SDO-labor-model needs to be changed too... so
that fewer face-to-face meetings are necessary.)

regards,
-Chris

Christopher J. Feahr, O.D.
Optiserv Consulting (Vision Industry)
Office: (707) 579-4984
Cell: (707) 529-2268
http://Optiserv.com
http://VisionDataStandard.org

36

This discussion which has been going on recently on the openEHR system and
its uses is of major interest. In follows the attempts in France to ensure
"continuity of care". I completely agree with the comments of Thomas Clark
on overkill. The exchanges and sharing of data must be standardized.
Standardizing the systems for all the uses of the data is unrealistic.
Norbert Lipszyc
----- Message d'origine -----

37

PLEASE REMOVE THIS EMAIL ADRESS FROM YOUR MAILING LIST !!

CENBIOTECH

Dr ALLAERT

TEL : 03 80 29 34 31

FAX : 03 80 29 39 73

-----Message d’origine-----

38

Christopher Feahr wrote:

Thomas,
Thanks for the comments. My only caution about asking physicians to
comment on the desirability of EHR-system proposals is that they may not
understand [what we mean by] our questions... and we probably won't
really understand [what they mean by] their responses.

When we ask for input from practicing physicians, I would rather pose
very discrete questions, such as: "When you do this procedure, our
committee believes that these information components are absolutely
necessary... do you agree?"

Anyway... this has been a busy few days with all the activity in the HL7
EHR SIG, and I guess I was in a particularly verbose mode... even for
me... yesterday! (I saw several "please remove me! messages posted
today... I hope I didn't drive away any of your "regulars customers"!)

don't worry about it - these are interesting topics. The only alternative is to have numerous lists, and we tried that on GEHR, and it exists on HL7, and all you get is massive cross-posting all the time.

- thomas beale

39

Hi All,

> --- (...)
> Been off looking at some operational considerations associated
> with supporting, maintaining and updating global EHRs.
> The following types of users were considered:
> 1)CREATORS
> 2)REVIEWERS
> 3)ADMINISTRATORS
> 4)CERTIFIERS

This idea of certification is not only good for EHRs.

Self-proclaimed openEHR-conformant software sould also be tested by general,
public certification tests, including EHRs & archetypes examples.

Independent organisms should also deliver their stamps, in a scheme like:
"Veritas has controlled this software to be openEHR-compliant with the
specifications issued by... (openEHR, CEN, ISO, HL7 ?) ".

-- Patrick Lefebvre
    "Ce que j'écris n'engage que moi, et ce jusqu'à ma prochaine idée."

40

Patrick Lefebvre wrote:

Hi All,

> --- (...)
> Been off looking at some operational considerations associated
> with supporting, maintaining and updating global EHRs.
> The following types of users were considered:
> 1)CREATORS
> 2)REVIEWERS
> 3)ADMINISTRATORS
> 4)CERTIFIERS

This idea of certification is not only good for EHRs.

Self-proclaimed openEHR-conformant software sould also be tested by general,
public certification tests, including EHRs & archetypes examples.

Independent organisms should also deliver their stamps, in a scheme like:
"Veritas has controlled this software to be openEHR-compliant with the
specifications issued by... (openEHR, CEN, ISO, HL7 ?) ".

-- Patrick Lefebvre
   "Ce que j'écris n'engage que moi, et ce jusqu'à ma prochaine idée."

-
If you have any questions about using this list,
please send a message to d.lloyd@openehr.org

Hi All,

Certification should be identified as well. This should include information such as:
station, date, time, source, results, requestor. With this information tracking
can be performed so that actual/potential problems can be isolated.

-Thomas Clark