Reference to the same observation/entry from different templates

Specifications
,
#1

I am new to OpenEHR and still learning about its specifications. Sorry for asking question already written in the docs.

Suppose that I have a time-series of plasma glucose values (store as an instance of Laboratory result archetype, which is event-type Observation) within an EHR of a particular patient.

How can I build a template for diabetes follow-up that pulls existing plasma glucose values that is stored in the database into field/entry within the template, without rigidly embedding these value in the template.

And how can I build another template that uses those plasma glucose values other than diabetes context (such as monitoring response to insulin injection), which is completely independent from the diabetes follow-up template.

In other words, I ask how the OpenEHR specs say about how different templates can pull value from (or just refer to) the same observation object (or an entry within an observation) that is already stored in the database before.

I try to find the portion of specs that say about that thing but didn’t find anything I want exactly.

#2

Welcome to the community. It’s not easy to get started on openehr and concepts like templates.
I’m fairly new to openehr as well but I expect others to correct me if I tell you something wrongly.
All data commited (stored) to the EHR (patient file) is stored as a COMPOSITION. A template (form) is a COMPOSITION that specifies what archetypes are used to store specific data ELEMENTs. So a COMPOSITION can be an encounter. The template e.g. diabetes checkup is based on this composition and includes a lab result OBSERVATION archetype (and additionally includes eg a body weight OBSERVATION). Both data element are stored as a single contribution (in our example a single database field in a json structure).
You could do the same for other templates that include the same OBSERVATION.
To get value from analysing e.g. lab result OBSERVATIONs that are stored as different template COMPOSITIONs you need something like AQL.
Lab results are a bit more complex due to multiple specialisation layers. Additionally recording the value in a diabetes template implies that the user determined the value while in practice a machine in a lab probably determined the value. And the current user only wants to link to the value in a seperate COMPOSITION air non openEHR Alan system. This is possible using the LINK class. But to get an understanding of openEHR I’d get started with including something simpler like body weight and pulse and blood pressure in different templates.
I hope this helps.
We as a community really need better getting started guides btw.
What is your background btw usually it helps to know to be able to help better.
Good luck on discovering this exiting field.

#3

I’m a medical practitioner and have some experience in object-oriented programming and relational database. I’m trying to think of OpenEHR in terms of OOP and I found OpenEHR is very OOP-like.

In the usual OOP, multiple objects can have reference, which is stored in its property/field, to another single object (and the object referenced isn’t belong to any particular object).

I doubt how the OpenEHR specs allow us to do something like that, given that a single laboratory result has many use case.

From your answer, It seems like a lab result (or any observation) need to be stored in some template, it cannot be “floating” in database by itself (like an OOP object that stayed in the heap). And if another template want to get this lab result, it needs to query the result (using AQL) from the “main” template to which the lab result originally belongs. Am I understand correctly?

The diagram is just for illustrating what I understand. Thank you for your answer.

image
image659×752 30.5 KB

1 Like
#4

Welcome pralomram! that is right:-) COMPOSITIONS are the minimum persistence unit in openEHR DBs.
Since you ask for the specs, you can do the query based on AQL retrieving the full composition or only a part of it:https://specifications.openehr.org/releases/QUERY/latest/AQL.html

Another option is to directly get the composition using the RESTFUL API, but then is not a query so you cannot filter based on the archetype elements: https://specifications.openehr.org/releases/ITS-REST/latest/ehr.html#composition.-

The easiest way to try this out is to ask for a demo account to Better for https://www.ehrscape.com/explorer/index.html

Once you understand the REST API, you can install you own open source openEHR DB using EHRbase https://github.com/ehrbase/ there are plenty of tests and queries in there.

1 Like
#5

Can AQL statements be stored in another template (other than a template that stores the OBSERVATION in question itself) to be used autometically to query
that OBSERVATION when that template is queried?

If not, is there a way multiple templates link to a single OBSERVATION?

#6

not really, please consider the COMPOSITION as a self contained document. AQL is a query statement and thus it is not intended to be stored in a template. The COMPOSITION instances are intended to store clinical data. That said, what is possible in some systems such as EHRbase is to store queries.

“If not, is there a way multiple templates link to a single OBSERVATION?”-> taking the concept of self-contained document this is not possible. One or more templates can use the same OBSERVATION archetype (at a information schema definition level). But once that is instantiated in runtime they will be different instances contained in different COMPOSITIONS. What is possible is to establish links from one instance to another in the system. That is a logic link, not a copy of data. Please see: https://specifications.openehr.org/releases/RM/latest/common.html#_link_class

For beginning it may help to think about templates as you think in XML Schemas. These schemas tell the openDB what is the structure of the data to be stored. AQL is the SQL language. OBSERVATIONS; EVALUATIONS etc are complex data types that you can reuse across several of these DB information schemas. In this example, the complex data type (e.g. OBSERVATION) can be used to define several schemas. But the object instances created from that schema are all different. In addition, as in OO the LINK allows you to define a link to another instance.

(…and please consider that using LINKs has to be done carefully. It may create cycles in your EHR tree-like structure, thus leading to computational complexity problems)

1 Like
#7

Pretty close! This diagram from the EHR IM spec might make it easier to visualise.

This overview information on templates might be helpful.

Also this part from the Architecture Overview.

The semantic framework diagram from the What is openEHR page (i.e. this one) might also help, as an aide memoire.

We certainly need to improve the ‘getting started’ level of information, but we need guidance from newer members of the community as to how to put together better learning pathways.

1 Like
#8

Yes are on the right track!!

We cannot store/define the AQL inside the template , as such since this is really a data persistence definition, so the the use of AQL to pull through the existing lab results from another source needs to be documented as a separate implementation guide. We probably do need another type of artefact to let us do that and some of the Form design layers that sit on top of templates do allow that but right now it is not in the formal openEHR specs.

So that allows you to pull the data through dynamically.

If you want to record the references back to the lab test e.g ‘This was the lab test that was used to trigger a diagnosis of diabetes’, you can use a LINK attribute to hook virtually any datapoint to any other. Again this is not something that current tooling allows you to set in the template but can be applied at runtime in the application.

Some archetypes use what are essentially’ hard-wired links’ via the DV_EHR_URI datatype, where the modellers expect to need to reference information elsewhere.

1 Like
#9

THe explanations from @thomas.beale and @luis_marco are much better than mine but

I agree this is helpful but it can lead people into thinking that either the data is stored as XML (which it is generally not), or that the data can only be accessed via the composition i.e you have to know what composition the lab test lives in to find it - this s not the case - AQL is designed to be able to retrieve entry level data agnostic of the parent composition.

1 Like
#10

Thank you for your support. I appreciated answers of you all.
It seem that the practice of referencing other objects from a template is not frequently used, or not quite recommended, in the OpenEHR realm. Maybe my design itself is problematic.

Could you recommend how to redesign a database in the OpenEHR-recommended way, or are there any examples of working database (archetypes/templates) equipped with real-world use case?

1 Like
#11

What we (and ehrbase? https://github.com/ehrbase/ehrbase) do is store a composition as a json structure per db field. And use a Java library (that we opensourced: https://github.com/openEHR/archie) to parse the json so that you can work with the data in Java.
@pablo also built some nice stuff to get started https://cloudehrserver.com/ there are also tools to play around with and YouTube tutorials;)

#12

There is quite a lot of use of linkages, across compositions particularly between instructions and Actions but openEHR is not designed to work like a typical normalised RDBMS. To make sense of it all, you really have to give up many pre-conceptions of what ‘the database looks like’ .

openEHR data management is designed to be handled by a custom CDR - clinical data repository, which handles all of the persistence, audit trails, querying etc through a service layer. THe actual physical db system underneath is opaque to you as a ‘consumer’ and will be quite different depending on the design choices of the CDR implementer.

THere are a few CDRs available, some with free demo environments, others that are open source such as Cabolabs EhrServer or EhrBase

The last thing you want to do is to try to build one yourself (at least initially)!!

So openEHR is very powerful and there are any number of real-world complex Health systems running on CDRs at scale around the world.

1 Like
#13

Hi all,

just my two cents: we indeed use a combination of JSON + relational tables inside EHRbase. It is important to mention that we don’t store the data exactly according to the openEHR Reference Model serialization but do some tweaks and add information to allow querying using the Archetype Query Language. When a composition is requested, we de-serialize the data into Archie which then can be used to provide the data via canonical JSON or XML. On top, we have several tools as part of our Software Development Kit that allows to make handling of openEHR data more convenient by automatically generating Java classes from templates that can be used to read and write openEHR data while hiding the verbose backend format that the Reference Model is.

@s_pralomram: I second Ian that building a proper openEHR CDR is quite expensive and laborious. I think what you might be interested in is a description how a reference is created and used at runtime to link and obtain data. At the moment, at least with EHRbase, this is something that needs to be managed inside the application layer which needs to ensure the provision of references according to this schema: https://specifications.openehr.org/releases/BASE/latest/architecture_overview.html#_ehr_uris

At the moment, we don’t do any checks that there is actually a valid object referenced. We have this on the roadmap and will provide convenience functions to help create, validate and ensure referential integrity of references.

To be a bit more concrete, here is an example of a reference from the spec:

ehr:/347a5490-55ee-4da9-b91a-9bba710f730e/compositions/87284370-2D4B-4e3d-A3F3-F303D2F4F34B/content[openEHR-EHR-SECTION.vital_signs.v1]/items[openEHR-EHR-OBSERVATION.heart_rate-pulse.v1]/data/events[at0006, 'any event']/data/items[at0004]

The correctness has to be ensured by the application system and the retrieval also needs to be implemented manually by mapping towards appropriate REST calls. As mentioned above, ideally this would be supported by the CDR (e.g. EHRbase) and SDK and I’m confident that we will have this later in 2021.

1 Like
#14

Hi all,
That is a great discussion and brings out the very important 'Link" concept in openEHR. I think, if properly understood, this can be a great tool in the hands of application developers. However,a s an implementer, I still lack clarity on how to this is realized in actual compositions and have some questions

  1. Is LINK a part of the basic reference model of the archetypes? Can I add links at run time?

  2. At what level is the link attribute available - Template, Archetype, node?

  3. What is the difference between DV_URI and LINK

  4. Are there any FLAT format examples of how to actually use LINKS
    I think “how to” guides on such specific topics would be a great resource for beginners and could get more developers to become “brave” enough to join openEHR bandwagon.

regards

1 Like
#15

A how to (on links) would be very interesting to me. For some pointers have a look at the expert replies to my question on linking in this topic: Linking in openEHR: goals and problems

#16

LINK defined here in the RM.

DV_URI in the RM.

You can find any class you want from the Global UML link at the top of the specifications home page.

You can also type a class name into the Search box at the top right hand of the specs home page.

We do also have a Stack Overflow-like ‘Questions’ area on the wiki - maybe we should use that more?

#17

That could be useful. Could I get acces?

#18

As long as you have a login to openEHR Jira or Confluence, you can see the Questions section.

1 Like