I Thought I Knew What I was Doing!

Implementers (archive)
1

Well, at least the reference model makes sense to me.

I can build EHR structures like no problem now in my demo.

But reading the Archetypes (definition) makes me think so much is
missing from the ADL. Let's take a simple case study.

Compositions are the primary data container in an EHR.

openEHR-EHR-COMPOSITION.encounter.v1

as shown in the definition:
26 definition
27 COMPOSITION[at0000] matches { -- Encounter
28 category matches {
29 DV_CODED_TEXT matches {
30 defining_code matches {[openehr::433]}
31 }
32 }
33 }

there is one required attribute listed; "category".

Now if you go to 5.4.1 in the EHR IM document you will see that the
following attributes are listed (ignoring the ones inherited from
Locatable for now.):

content - not required
context - not required
composer - required
language - required
territory - required

So my question is. If the oft quoted phrase "an archetype is a maximal
data set of a clinical concept" is true. Then were are these other
attribute values to come from?

I have found many examples of of these missing attributes and in this
case I can say that the other three required ones maybe should come from
the system its self. But shouldn't they at least be listed in the ADL?

Let's look at an archetype where the data cannot possibly come from the
system. openEHR-EHR-INSTRUCTION.procedure.v2draft

26 definition
27 INSTRUCTION[at0000] matches { -- Procedure instruction
28 activities cardinality matches {0..*; unordered} matches {
29 ACTIVITY[at0002] occurrences matches {0..1} matches { -- new
activity
30 action_archetype_id matches {/procedure\.v2/}
31 description matches {
32 allow_archetype ITEM_TREE occurrences matches {0..*} matches {
33 include
34 archetype_id/value matches {/procedure\.v3/}
35 }
36 }
37 }
38 }
39 }
40

Now here we see that this Instruction (EHR IM 8.3.6) provides for a list
of "activities" (not required). But the one required attribute
"narrative" is not present in the ADL. Why? Now, it seems to me to
allow for a slot for an ACTION archetype but it doesn't have a narrative
attribute nor does it's parent class CARE_ENTRY (8.3.3).

There are many of these so I must be missing something basic. Because
it seems to me that I as a developer (not the clinical expert) would
have to decide that these required attributes are on the UI in order to
develop RM compliant data.

If something like that is true then I think we may have a problem as I
understand it there are people out there implementing what they think
are openEHR compliant archetype data based on other data models just
using the ADL as a guide. In fact I once thought that this was possible
from OpenMRS. But it seems to me that archetypes expressed in ADL are
NOT the maximal data set for a clinical concept.

Help me understand?

Cheers,
Tim

2

Hi Tim,

the only things that need to be mentioned in an archetype are those that
need to be constrained with respect to the reference model. If there is
nothing about a given attribute in an archetype, then the reference
model semantics are assumed. The 'maximal' idea is not to do with
reference model archetypes, but the dataset in an archetype. The
archetype for BP measurement contains a bunch of data items that would
never all be used in one situation - it is like the superposition of
different ways of measuring BP. They are all there in the BP archetype,
because it provides a convenient place to collect them and encapsulate
them (and they are often related in some formal way).

- thomas beale

Tim Cook wrote:

3

Hi Tom,

Hi Tim,

the only things that need to be mentioned in an archetype are those that
need to be constrained with respect to the reference model. If there is
nothing about a given attribute in an archetype, then the reference
model semantics are assumed.

Okay, I suppose that makes sense. I just had a wrong impression.
Certainly this causes problems for people like Greg Caulton trying to
use ADL to build openEHR compliant data with a data model like this:
http://www.patientos.org/documentation/datamodel.html

The 'maximal' idea is not to do with
reference model archetypes, but the dataset in an archetype. The
archetype for BP measurement contains a bunch of data items that would
never all be used in one situation - it is like the superposition of
different ways of measuring BP. They are all there in the BP archetype,
because it provides a convenient place to collect them and encapsulate
them (and they are often related in some formal way).

That part I understood. I was just surprised at the missing attributes.

I am happy now. A slight change in the way I build my input screens but
no big deal. :slight_smile:

Cheers,
Tim

4

So does this mean that any optional attribute should NOT appear if it
isn't mentioned in the ADL?

--Tim

PS. I know these questions may seem obvious to some of you; but ...

5

Certainly?

Actually those few diagrams are over a year old now and are not
specific to clinical documentation. The data model is now 231 tables,
several concepts have since changed and addresses OpenEHR quite
nicely, in fact I was in the UK demonstrating to Tony Shannon before
Christmas.

However it is a relational database so there are concepts difficult
for some to grasp. What is important to realize is that while you
might (and I say might because I am not certain) be focused on
replicating the ADL structure in XML in your platform we are not. We
store health care information system data which is configured to
retain the semantic structure of the content while having references
to the archetypes to support AQL querying and data interoperability.

There is little point on arguing the technical merits of one
architecture over the other, most people are already in one camp or
another from personal experiences.

More importantly what we will do though is, per Tony's request, create
a demonstration of a clinical workflow - perhaps an admission
assessment, medication reconcilliation, progress note, medication
order entry, pharmacy dispensing, medication administration and a
discharge note and then show how one can use AQL to query the
underlying data model.

We can have that within a couple of weeks.

6

Tim Cook wrote:

Hi Tom,

Hi Tim,

the only things that need to be mentioned in an archetype are those that
need to be constrained with respect to the reference model. If there is
nothing about a given attribute in an archetype, then the reference
model semantics are assumed.
    
Okay, I suppose that makes sense. I just had a wrong impression.
Certainly this causes problems for people like Greg Caulton trying to
use ADL to build openEHR compliant data with a data model like this:
http://www.patientos.org/documentation/datamodel.html

this is a 'classic' relational schema. The problem with representing
business objects directly in schemas like this is that you never stop
modifying the schema, and this is a real problem when your system is
deployed in 1000 large sites each with millions of records. Plus there
is no easy way to write generic software that can reason about all
Observations, or all Evaluations in a standard way.

- thomas

7

Hi

as I understand it, if an attribute is optional in the RM and it is not mentioned in the ADL it stays optional. Thus it still may or may not be there. However, the ADL could further constrain the model (“tighten it”), e.g. make an optional attribute required or change a cardinality from 0..* to 0..8.

The idea behind openEHR is that of a two level modelling approach, so to use/implement openEHR you always need a component (sometimes called “kernel” in openEHR speak) that brings the two models, RM and ADLs, together. As you correctly concluded Greg Caulton, who BTW does an amazing job with PatientOS, won’t be able to implement his data model in ADL alone.

Regarding your initial confusion about “missing” attributes in ADL. This has also been an issue for (clinical) archetype authors, who thought essential data items such as time of examination etc were missing, although they are covered by the RM, so there is no need to re-model them in the ADL. The reason is that the two widely used tools, Archetype Editor and Template Designer, don’t show the unconstraint RM attributes.

Cheers, Thilo

8

Thilo Schuler wrote:

Hi

as I understand it, if an attribute is optional in the RM and it is
not mentioned in the ADL it stays optional. Thus it still may or may
not be there. However, the ADL could *further* constrain the model
("tighten it"), e.g. make an optional attribute required or change a
cardinality from 0..* to 0..8.

The idea behind openEHR is that of a *two* level modelling approach,
so to use/implement openEHR you always need a component (sometimes
called "kernel" in openEHR speak) that brings the two models, RM and
ADLs, together. As you correctly concluded Greg Caulton, who BTW does
an amazing job with PatientOS, won't be able to implement his data
model in ADL alone.

Regarding your initial confusion about "missing" attributes in ADL.
This has also been an issue for (clinical) archetype authors, who
thought essential data items such as time of examination etc were
missing, although they are covered by the RM, so there is no need to
re-model them in the ADL. The reason is that the two widely used
tools, Archetype Editor and Template Designer, don't show the
unconstraint RM attributes.

in the next week or two, I should have those 'missing attributes'
displaying nicely in the archetype workbench :wink:

- thomas

9

Greg,

I wasn't trying to begin a technical argument. It was only an
observation about how difficult it might be to do your mapping if you
were not aware of the missing attributes in the ADL.

No, I'm not interested in XML. They are objects so they belong in an
object database. :wink:

Cheers,
Tim

10

I am always more than a little disappointed when people make broad
assumptions about other projects when done from an uninformed stance
and despite best intentions come across quite negatively. I don't
think it really helps build a community spirit.

Tom I expected more from you :slight_smile:

For your education the 'classic' relational schema you are referring
to is a naiive implementation that probably was designed in the 80's
whereby one might create a table and add columns one for one for the
attributes one is modelling. So an observation result table might
start out

result (result_id, test_name, data_type, units,...)

As new properties of the attributes of the model are discovered so one
might add columns to model them

*This is not how PatientOS is designed*

We have core models with core attributes (columns) that provide the
basic model but each observation, result, note, any clinical item can
have both an infinite number of attributes and an infinite hierarchy
of attributes. All very easy, without schema changes and unlike an
XML or object based database one is able to keep relational integrity
and index properly to provide high performance. And I *have* worked
on production implementations with relational database with 1000's of
sites, and 100,000,000 records. XML based applications in my
experience tend to suffer from other issues that I think you will find
out when it comes to production deployment with 1000's of users
attempting to update the database not to mention when it comes to
upgrades and maintenance. There is a reason relational databases have
stood the test of time and object databases have not really taken off.

But enough of my ranting...

Tim Cook wrote:

Hi Tom,

Okay, I suppose that makes sense. I just had a wrong impression.
Certainly this causes problems for people like Greg Caulton trying to
use ADL to build openEHR compliant data with a data model like this:
http://www.patientos.org/documentation/datamodel.html

this is a 'classic' relational schema. The problem with representing
business objects directly in schemas like this is that you never stop
modifying the schema, and this is a real problem when your system is
deployed in 1000 large sites each with millions of records. Plus there
is no easy way to write generic software that can reason about all
Observations, or all Evaluations in a standard way.

- thomas

11

Hi Greg,

no offence was intended, was just commenting at what I thought I was seeing, which appeared to be a classic relational database schema. Just for my edification, if I use PatientOS and I realise that I need a new attribute to do with medication orders, say something to do with vaccinations, but I look at the table MED_ORDERS, and I realise it is not there, what do I do? I would have assumed that the MED_ORDERS table had to be changed. Also, for a given kind of medication order (e.g. repeating asthma medication), how would I know which of the many attributes in the MED_ORDERS table are relevant?

Are you saying that the 160 tables-model is the ‘core model’ and can be relied on never to change? Is there a web page describing the design concept of this style of database that can help us to understand better?

As for XML, I am no great fan either, and I have to admit I expected all kinds of problems going into production in our system, which uses XML blobs onto a relational database. But the performance statistics on a rather large and loaded test server don’t support my fears. There is of course a trade-off, between flexibility (blobs means you can change what is in the blob without changing the database) and speed (doing a transparent table design should indeed be faster), but for the moment, there seems to be no problem with the tradeoff we have chosen.

thanks

  • thomas

Greg Caulton wrote:

(attachments)

OceanCsmall.png

12

I am always more than a little disappointed when people make broad
assumptions about other projects when done from an uninformed stance
and despite best intentions come across quite negatively. I don't
think it really helps build a community spirit.

Tom I expected more from you :slight_smile:

I assume you meant Tim. I apologize if they came across negatively. It
was not meant that way at all.

For your education the 'classic' relational schema you are referring
to is a naiive implementation that probably was designed in the 80's
whereby one might create a table and add columns one for one for the
attributes one is modelling. So an observation result table might
start out

Thanks for the education but I was building (what you call relational,
but are really SQL schemas in the 1980's). When I ran into the problems
of building a correct and enduring schema for an EMR I was fortunate
enough to meet Sam Heard at AMIA in Nov. 2000. A short conversation
made me see the light. :slight_smile:

We have core models with core attributes (columns) that provide the
basic model but each observation, result, note, any clinical item can
have both an infinite number of attributes and an infinite hierarchy
of attributes. All very easy, without schema changes

... and yet you point out the schema changes you have made since the
diagram was posted on your website.

There is a reason relational databases have
stood the test of time and object databases have not really taken off.

Primarily because that is what is taught in schools.

But enough of my ranting...

Mine too! Have a great weekend and I wish you the best with your
project. I hope you can contribute what you have learned to the wiki
at: http://www.openehr.org/wiki/display/dev/Persistence

Cheers,
Tim

13

Hi Greg,

no offence was intended, was just commenting at what I thought I was seeing, which appeared to be a classic relational database schema. Just for my edification, > if I use PatientOS and I realise that I need a new attribute to do with medication orders, say something to do with vaccinations, but I look at the table MED_ORDERS, and I realise it is not there, what do I do? I would have assumed that the MED_ORDERS table had to be changed. Also, for a given kind of >medication order (e.g. repeating asthma medication), how would I know which of the many attributes in the MED_ORDERS table are relevant?

When you design orders you build an 'order form' called a form type
and you design and build the controls on that form. Some controls will
be bound to the orders table, some will be bound to the form records,
or form record details. If it is a med some are bound to the
med_orders table. The form, form_records, form_record_details are
what provide the extensible content and can be designed as a hierarchy
(though not usually necessarily to go more much deeper). The form
records and details have identifiers and values which map to SNOMED,
OpenEHR and other content.

Are you saying that the 160 tables-model is the 'core model' and can be relied on never to change? Is there a web page describing the design concept of this > style of database that can help us to understand better?

The data model naturally expands with new functionality but the core
tables which form the hierarchy for clinical documentation has not
changed since it was designed because you don't add columns to add new
attributes, you add record items, details, data elements which equate
to rows not columns. Theoretically I could drop the use of an orders
table and med_orders table and design it with pure forms - but dose
calculations and other orders or med specific functionality is easier
to encapsulate in the corresponding objects.

As for XML, I am no great fan either, and I have to admit I expected all kinds of problems going into production in our system, which uses XML blobs onto a relational database. But the performance statistics on a rather large and loaded test server don't support my fears. There is of course a trade-off, between >flexibility (blobs means you can change what is in the blob without changing the database) and speed (doing a transparent table design should indeed be > faster), but for the moment, there seems to be no problem with the tradeoff we have chosen.

Data integrity and queries across XML documents is what I always find
challenging, but every application is unique so one cannot compare
apples and oranges.

14

Hi Greg,

please see one comment inline.

Cheers, Thilo

Hi Greg,

no offence was intended, was just commenting at what I thought I was seeing, which appeared to be a classic relational database schema. Just for my edification, > if I use PatientOS and I realise that I need a new attribute to do with medication orders, say something to do with vaccinations, but I look at the table MED_ORDERS, and I realise it is not there, what do I do? I would have assumed that the MED_ORDERS table had to be changed. Also, for a given kind of >medication order (e.g. repeating asthma medication), how would I know which of the many attributes in the MED_ORDERS table are relevant?

When you design orders you build an ‘order form’ called a form type
and you design and build the controls on that form. Some controls will
be bound to the orders table, some will be bound to the form records,
or form record details. If it is a med some are bound to the
med_orders table. The form, form_records, form_record_details are
what provide the extensible content and can be designed as a hierarchy
(though not usually necessarily to go more much deeper). The form
records and details have identifiers and values which map to SNOMED,
OpenEHR and other content.

Are you saying that the 160 tables-model is the ‘core model’ and can be relied on never to change? Is there a web page describing the design concept of this > style of database that can help us to understand better?

The data model naturally expands with new functionality but the core
tables which form the hierarchy for clinical documentation has not
changed since it was designed because you don’t add columns to add new
attributes, you add record items, details, data elements which equate
to rows not columns. Theoretically I could drop the use of an orders
table and med_orders table and design it with pure forms - but dose
calculations and other orders or med specific functionality is easier
to encapsulate in the corresponding objects.

Reading this reminds me of the Entity-Attribute-Value database design paradigm (e.g. see http://ycmi.med.yale.edu/nadkarni/Introduction%20to%20EAV%20systems.htm).

Is your design similar to EAV?

15

Yes but I disagree with the first sentence of the second paragraph :slight_smile:
At least not with today's libraries and tools available.

16

That sounds really interesting Greg - where is patientOS implemented (or being implemented) and what is its purpose?

17

Well thanks for asking :slight_smile: The goal of PatientOS is a scalable Health
Care Information System for hospitals that is flexible enough to deal
with everything from a large hospital to a small clinic - but unlike
most EMRs provide extensive customization of the UI, work flow and
business rules - a rapid HIS development environment if you will.

It has been live in a physician clinic for over a year and we are a
month into a large multi-facility hospital organization contract in
the US and expect to be live with an inpatient long term acute care
and rehab facility in the summer - orders, clinical documentation,
chart viewing, HL7 interfaces ADT Inbound, therapy charges outbound,
lab results inbound etc.

This week we are demoing to their Pharmacy the new Pharmacy
Information System functionality including a medication management
workflow - physician med orders, pharmacy order approval, pharmacy
product selection, commercial drug database clinical decision support,
pharmacy administration scheduling, nurse review, nurse administration
with barcodes, labels and scanning at the point of care.

Greg

http://www.patientos.org
http://www.patientos.com

18

So this is an openEHR based system for the clinical content? Can you add new arrchetypes to the system without schema changes and adding new interfaces? Did you use archetypes from CKM to build the system?

19

inlne responses

From: Hugh Leslie <hugh.leslie@oceaninformatics.com
Date: Tue, 03 Feb 2009 10:42:37 +1100

So this is an openEHR based system for the clinical content?

Correct.

Can you add new arrchetypes to the system without schema changes and adding new interfaces?

Yes, you
1) navigate our 'record item tree'
2) create a new folder
3) right click on the folder and select 'import archetype'
4) you browse and select the ADL file
5) it imports all the data elements in the archetype, converting to
our 'record item' format and creates an identifier that is the full
AQL based path to that archetype value
6) these record items are bound to controls when you create your forms
in the form editor

no schema changes, no code changes, no programming skills required,
these are all just user friendly (and dare I say pretty) UI tools.

Did you use archetypes from CKM to build the system?

Actually we did exclusively, we have not imported all archetypes, just
core ones from CKM as needed. It is also not a problem if archetypes
come after the fact, we can map existing record items to new
archetypes assuming the semantic meaning of the data elements are
equivalent.

20

Greg,

what happens when there are elements in archetypes that happen to be in
common with certain columns in the ER schema we were discussing earlier
(and I can see quite a lot), but the exact data types, groupings and
optionalities are not the same. How do these semantics get mapped?

- thomas beale

Greg Caulton wrote: