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...

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.

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...

Hi there!
Lets hit the road...


Firstly, I will add two elements to the previous list, then list the non-optional components of archetypes, and then proceed to discuss each node.


2 additional elements


The two additions are: is_controlled, whose value is boolean (true or false);
and parent_archetype_id , whose value is the archetype from which the
archetype in consideration was derived.


Non-optional components

All archetypes must have the following portions, as a minimum:

archetype_id, adl_version, concept, original language, definition, ontology and revision_history.

As stated in the ADL2 document, the order is not significant.


We will now proceed to discuss each node:

1. adl_version

which has a value of v1 in the blood pressure archetype

v1 representing version one.
adl is the language used in authoring 'raw' archetypes (remember?)

2. concept

at0000 is its value in the blood pressure archetype

at0000 represents the archetype's central concept, which is blood pressure.
Each archetype is defined by a concept.
All concepts used in an archetype are stored in the ontology section.

More of this ontology and concepts stuff in my next post

I guess it will be possible to dehydrate these concepts onto concept proposals in OpenMRS...
or kind of mass load concepts from here...
just initial thoughts...

I have been trying to upload this long bloodpressure.xml archetype here without success. I think blogspot has turned off uplaods for security reasons...
would need to sort this out soon...

An archetype is a well-structured (formal) model of clinical content. Archetypes are designed to be used as a basis for structuring data eg building forms and building queries (xpath-like).

They are written in a language called the archetype definition language (ADL). ADL archetypes can be converted to xml.

Parts of an archetype

An archetype consists of the following sections (though some sections are not mandatory):

(Please see diagram within ADL2 document here)

archetype_id

adl_version

concept

original_language

translations

description

declaration

definition

invariant

ontology

revision_history

Lets start dissecting the blood pressure archetype xml

Hi there.

I’ll like to introduce the ‘Introduction of Archetypes’ to OpenMRS project. You might find this project mentioned elsewhere as the archetypes integration project, Archetypes module project, OpenEHR-OpenMRS integration or … ().

The OpenMRS development project is a truly open open-source project – that means your ideas are not only welcome but also count in its continuous evolution.

I’ll begin by building (and getting) an understanding of what this archetypes project entails.

Please find few details of this on the wiki at http://openmrs.org/wiki/Archetypes_Module

My initial thoughts…

I’m working on giving the OpenMRS the ability to consume some tasty hamburgers called archetypes. For now, it survives on nice plenty chips called concepts and fields. Archetypes have concepts embedded in them.

There are different categories of archetypes (or hamburgers to continue the analogy) according to size and function – ENTRY, SECTION, CLUSTER, COMPOSITION. Compositions contain sections; sections contain entries (in a sort of hierarchy as you find in CMS like Joomla where you have sections, categories and items). Thus the ENTRY category contains the basic reusable units. ENTRY types include OBSERVATION, INSTRUCTION, ACTION, EVALUATION and ADMIN_ENTRY. Their functions can be guessed from their names and they roughly correspond to OBSERVATION, ORDER, DEMOGRAPHICS (very roughly…because that leaves INSTRUCTION and EVALUATION as part of OBSERVATION )

I think I will concentrate on OBSERVATION.

Please read more at

http://www.openehr.org/clinicalmodels/archetypes.html

http://oceaninformatics.biz/archetypes/MindMap/ArchetypeMap.html

http://svn.openehr.org/specification/TRUNK/publishing/openEHR/introducing_openEHR.pdf.

If you are new to openMRS, please see http://openmrs.org/wiki/OpenMRS. This project aims to make creating forms very easy – as easy as combining archetypes or reusing templates (from both an openEHR and Xforms point of view.)

Important database tables to look at:

Form,

Form field,

Field,

Concept

Learn more about the db at http://openmrs.org/wiki/OpenMRS_data_model

Would really appreciate your comments here…