Getting a fuller picture

I have been discussing the codes that produce the image you see below.
There seems to be a 'cloud' (of misunderstanding) around these things called archetypes.
But it is actually simpler that people think.

Simply put, all what we have been discussing, the blood pressure archetype, lets you have the form (or subform or formlet or whatever you like to call it) that you can see below.


Now, I wont go into the argument of what is more important - whether the templates that it can generate (ie the product) or the codes that generate it (the codes).
Most other issues concerning arhcetypes/templates revolve around the sections we discussed in previous blogs.

Now, imagine, we have thousands of these clinical models, 'certified' by domain experts and tested by many implementations. That explains the interest in archetypes. However, these days I am beginning to ask my self: 'where is the hl7 equivalent of this?'. Thats probably for another day...

Recently, the NHS Trust work on archetypes has really excited me. As you may know, the NHS Trust UK (and NHS Scotland) has made available their archetypes repository for free use.

Visit the NHS work here.

What you might not know is that they have made their xforms engine based on chiba, xmlprocess, also available at the OHT.
See it here

My goal in the coming weeks will be to learn more about Adam Flinton's work, Xmlprocess, and about how archetypes and templates work in his tool.
I think that his work will not only redefine the way we look at operational archetypes and templates, but will stimulate other efforts at using xml archetypes/templates.

Also, since I am generally getting (sorry.. have gotten) inclined to Xforms, I might need to align my work with the new Xforms wave in the OpenMRS community...
Lets keep at the good work...
I'm outta here
...tomorrow is another day...

ciao...

The blood pressure archetype with screenshots

Hmmm...

I was just trying out bloggers email-to-blog feature in my last post with the images put in the right place... but it looks like its really messy if you have pictures within the document...
wont advise you to try it ... except you are a tester...

I have now put in the pics here...
I just hope they make sense...

The Anatomy of the Blood Pressure Archetype 2

Whew!

I need to close up this discussion of the blood pressure archetype to proceed onto how to pass this into OpenMRS.

This is the second part of a discussion of this exemplary archetype.

To reiterate, the sections of this archetype include the following nodes:

archetype_id, adl_version, concept, original_language, definition, translations

description and ontolology.

Please observe that the root node is ‘archetype’ and it has three important attributes.

This archetype was made in the pre-ADL-version2 days and doesn’t have the

ADL2-mandatory node, revision_history.

I would like to say that all I am stating here follow the ADL2 specification, and there is no originality, so to speak... all kudos go to the OpenEHR spec guys!

Lets say something about the 8 main sections:

1. the adl_version section

This is the version of the archetype definition language (adl) used in authoring the archetype.

It has a value of v1 in the blood pressure archetype (as can be seen in the screenshot above), v1 representing version one.

adl is the formal language used in authoring 'raw' archetypes (remember?)

2. concept

is the central concept this archetype represents...

at0000 is its value in the blood pressure archetype.

Thus, at0000 represents the archetype's central concept.

"at", the prefix for the value, short for "archetype term".

All archetype terms can be found in the ontology section.

A peep into the ontology section of the archetype tells me that at0000 corresponds to blood pressure.

Well, I didn’t even have to spy there, because at0000 always represents the whole archetype, which in this case is blood pressure. Each archetype is defined by a concept.

Come to think of it, what’s it with the blood pressure? I think since Laennec invented the steths, clinical practice has really changed. And its a crucial vital sign... something the management guys would call a KPI (Key performance indicator)...

Oops... I'm here to talk about archetypes...

3. ontology

This would probably be better understood if it were called 'terminology' because it doesn’t necessarily store the rich semantic stuff you find in popular ontologies.

If you are from OWL or Protégé or RDF, etc, you'll probably not find your description logics here.

To see the relationship between archetypes and OWL, see here.

The ontology mainly holds the terminology listing within, in different languages. It also contains descriptions (and translations) of terms in child nodes named items.

Have a look at a screenshot below (sorry for the blur):

It also contains mappings (if available) to external terminologies. These are contained in the child node, term_bindings.

My thinking is that a collection of all the archetypes would comprise a whole large terminology that can be used to drive a system. Running a vocabulary is, however, not a goal of the OpenEHR foundation.

4. original_language

This is as-it-reads; the original language in which the archetype was designed... It includes children that specify the ISO code for the language as well as the ISO code_string. These were ISO_639-1 and en, the last time I checked...

5. translations

Of course, this relates to translations from the original language.

The OpenEHR is built for the global Babel of languages - the motivation for metadata to handle language translations. Child elements here have values that include the ISO code_string (de for German), the ISO code and the translator's name and affiliations, including any accreditation.

Archetypes need to be translated completely – and mostly this involves the ontology and description sections, because these sections carry metadata that might need to be displayed in form templates.

The screenshot above shows the translation section of the blood pressure archetype.

6. archetype_id

This is a unique identifier for an archetype and corresponds to openEHR-EHR-OBSERVATION.blood_pressure.v1 (as you can see below)

This identifier gives clues as to which type the archetype is (e.g. an observation archetype). It also mentions its central concept (blood pressure) and its version (v1).

7. description

This contains metadata about the author such as name, email, organization and the archetype was created. It also contains information on the current state of the archetype (draft, in this case).

It also discusses the main purpose of the archetype, as well as its use, misuse and keywords that are important. The details subsection contains succinct domain information. And this contributes to the richness of archetypes and one of its central motivations - which is modeling domain knowledge.

This knowledge also can exist in multiple translations (as you can see in German here)

The blood pressure archetype was originally constructed in English but has a German translation. The purpose is "to record the systemic blood pressure of a person. The measurement records the systolic and the diastolic pressure by some means suitable for the result to be seen as a surrogate for the general and systemic blood pressure"

8. definition

To quote the ADL2 document, the definition section contains the main formal definition of the archetype" It is based on a special form of ADL called constraint ADL.

It is used to define constraints on data. Keywords that can help understand the definition section include: matches, ~matches, is_in, ~is_in, occurrences, existence, cardinality, ordered, unordered, unique, infinity, use_node, allow_archetype, include, exclude. These allow constraints that are related to the underlying information model… or lets say database.

Here the archetype “links” to the EHR (electronic health record) space and can specify or “call” on another archetype or specify a lookup column, etc. More details of this can be found in the ADL document here or here. And you might need some reading on the OCL.

In summary, this is a terribly ‘rough’ but ‘practical’ summary of better and more formal documents in the OpenEHR space. Please have a look at www.openehr.org.

The Anatomy of the Blood Pressure Archetype

Whew!

I need to close up this discussion of the blood pressure archetype to proceed onto how to pass this into OpenMRS.

This is the second part of a discussion of this exemplary archetype.

To reiterate, the sections of this archetype include the following nodes:

archetype_id, adl_version, concept, original_language, definition, translations

description and ontolology.

Please observe that the root node is 'archetype' and it has three important attributes.

This archetype was made in the pre-ADL-version2 days and doesn't have the

ADL2-mandatory node, revision_history.

I would like to say that all I am stating here follow the ADL2 specification, and there is no originality, so to speak... all kudos go to the OpenEHR spec guys!

Lets say something about the 8 main sections:

1. the adl_version section

This is the version of the archetype definition language (adl) used in authoring the archetype.

It has a value of v1 in the blood pressure archetype (as can be seen in the screenshot above), v1 representing version one.

adl is the formal language used in authoring 'raw' archetypes (remember?)

 

2. concept

is the central concept this archetype represents...

at0000 is its value in the blood pressure archetype.

Thus, at0000 represents the archetype's central concept.

"at", the prefix for the value, short for "archetype term".

All archetype terms can be found in the ontology section.

A peep into the ontology section of the archetype tells me that at0000 corresponds to blood pressure.

Well, I didn't even have to spy there, because at0000 always represents the whole archetype, which in this case is blood pressure. Each archetype is defined by a concept.

Come to think of it, what's it with the blood pressure? I think since Laennec invented the steths, clinical practice has really changed. And its a crucial vital sign... something the management guys would call a KPI (Key performance indicator)...

Oops... I'm here to talk about archetypes...

3. ontology

This would probably be better understood if it were called 'terminology' because it doesn't necessarily store the rich semantic stuff you find in popular ontologies.

If you are from OWL or Protégé or RDF, etc, you'll probably not find your description logics here.

The ontology mainly holds the terminology listing within, in different languages. It also contains descriptions (and translations) of terms in child nodes named items.

Have a look at a screenshot below:

It also contains mappings (if available) to external terminologies. These are contained in the child node, term_bindings.

My thinking is that a collection of all the archetypes would comprise a whole large terminology that can be used to drive a system. Running a vocabulary is, however, not a goal of the OpenEHR foundation.

 

4. original_language

This is as-it-reads; the original language in which the archetype was designed... It includes children that specify the ISO code for the language as well as the ISO code_string. These were ISO_639-1 and en, the last time I checked...

 

5. translations

Of course, this relates to translations from the original language.

The OpenEHR is built for the global Babel of languages - the motivation for metadata to handle language translations. Child elements here have values that include the ISO code_string (de for German), the ISO code and the translator's name and affiliations, including any accreditation.

Archetypes need to be translated completely – and mostly this involves the ontology and description sections, because these sections carry metadata that might need to be displayed in form templates.

The screenshot above shows the translation section of the blood pressure archetype.

6. archetype_id

This is a unique identifier for an archetype and corresponds to openEHR-EHR-OBSERVATION.blood_pressure.v1 (as you can see below)

This identifier gives clues as to which type the archetype is (e.g. an observation archetype). It also mentions its central concept (blood pressure) and its version (v1).

7. description

This contains metadata about the author such as name, email, organization and the archetype was created. It also contains information on the current state of the archetype (draft, in this case).

It also discusses the main purpose of the archetype, as well as its use, misuse and keywords that are important. The details subsection contains succinct domain information. And this contributes to the richness of archetypes and one of its central motivations - which is modeling domain knowledge.

This knowledge also can exist in multiple translations (as you can see in German here)

The blood pressure archetype was originally constructed in English but has a German translation. The purpose is "to record the systemic blood pressure of a person. The measurement records the systolic and the diastolic pressure by some means suitable for the result to be seen as a surrogate for the general and systemic blood pressure"

 

8. definition

To quote the ADL2 document, the definition section contains the main formal definition of the archetype" It is based on a special form of ADL called constraint ADL.

It is used to define constraints on data. Keywords that can help understand the definition section include: matches, ~matches, is_in, ~is_in, occurrences, existence, cardinality, ordered, unordered, unique, infinity, use_node, allow_archetype, include, exclude. These allow constraints that are related to the underlying information model… or lets say database.

Here the archetype "links" to the EHR (electronic health record) space and can specify or "call" on another archetype or specify a lookup column, etc. More details of this can be found in the ADL document here. And you might need some reading on the OCL.

 

In summary, this is a terribly 'rough' but 'practical' summary of better and more formal documents in the OpenEHR space. Please have a look at them www.openehr.org. Or can u google?

 

 

Archetypes? Subforms?

Its been a while here...

Since my last post, I've survived a hard disk crash, travelled about 4000km of road and learnt some cool horse riding stuff... and met many many nice guys in the process...
ok... also did (try to?) write something for this year's Athens International System Dynamics Conference...

Emm... doesnt mean I havent been thinking of archetypes.
I must say that I am really excited about the open Xforms trend on the OpenMRS dev. And I am beginning to think that I should carry my 'kaya' (kaya is the Hausa word for load) from the InfoPath side of things to the open Xforms side of things.
And there is something cool on Mark Birbeck's blog. And I have copied some stuff from there (below).

Emmm...

"The subforms technique we used on the current project is to extend the XForms load action to include:
a target attribute to indicate where to place the sub-form;
an additional value in the show attribute of embed.
To show how it works, here is an example of how we place a sub-form into a case when the user toggles that case:



We use the term sub-form to describe the document that is loaded because it may have more than just controls; it may include its own models, submissions, bind statements, and so on.
Using XLinkThe extensions to load are of course non-standard, and this is still very experimental. But it is worth saying that there is logic behind the way we've done this.

For a start, XForms really should support a target attribute on the load action anyway, which would allow new documents to be loaded into frames or other locations.But also, the show attribute in XForms is actually modelled on the XLink show attribute, and the currently supported values--replace and new--come from that...as does embed. In other words, all we're suggesting here is that XForms supports a little bit more of XLink.As it happens, our first version of this functionality achieved it using raw XLink, but the problem is that XLink says nothing about when to load the sub-form. Once we started looking at attaching event listeners, we quickly came to the conclusion that load was much more appropriate, particularly because it already made use of XLink.

Conclusion
However we do this in the future, and whatever mark-up is used, XForms definitely provides the hooks for a flexible way to build complex forms on the fly. Defining the loading of sub-forms using declarative mark-up makes it intuitive for authors to use this feature, and makes the management of the components much easier."


How is this relevant?
I am thinking... archetypes, as in the OpenEHR specs, are not used directly to drive systems. They are used as 'subforms' or 'form parts' or 'formlets' which make up a template.
Of course there are cases where a form (or template) consists of just one archetype.

So, whats the advantage of deriving subforms from archetypes and not just creating from the scratch...
I just mentioned it, from the scratch. Implementers do not really want to do things from the scratch. They want to learn from others.

Another advantage is that if you can select the finite number of archetypes (of course its never finite cos medical requirements are inherently dynamic... but lets just use it for now, there is something called versioning)...you can have the finite number of concepts from the ontology section of the archetype...
So, how do you do that?
Not done that yet... but there's something called xpath that can point to those locations...