openEHR-RM-LINK discussion - now also on mailing list :-)

[system]

Hi!

I hear of a lot of interesting off-line discussions regarding the
openEHR RM object named "LINK". I guess they have not yet reached the
mailing list because of time restrictions and/or the
exploratory/initial nature of the discussions. But now let's get more
good brains involved...

Just to make sure we talk about the same thing, it is the class LINK
described in section 3.2.4 in
http://www.openehr.org/releases/1.0.2/architecture/rm/common_im.pdf
and in XML schema
http://www.openehr.org/releases/1.0.2/its/XML-schema/documentation/Structure.xsd.html#h518145503
(An excerpt from the spec is attached by the end of this mail)

Some of the interesting bits I've picked up so far from discussions:
- Maybe it would be a good idea to make LINK inherit from LOCATABLE
and thus become archetypable in itself
- Tooling support for using LINK in archetypes is currently poor or non existent
- There is very little (if any) reported usage experience of LINK in openEHR
- I believe the NHS has somewhat explored LINK usage in LRA using ISO 13606
- If archetyping LINKS, then it would in _some_ cases be desirable to
be able restrict the type of the "target", especially defining what
archetypes the target objects must adhere to (similar to the archetype
slot mechanism).

Please fill in with nore details and thoughts.

Implementers, would it have a big impact on your implementations if
LINK was made LOCATABLE? (Let's say in v 1.0.3)

I wonder, is it currently safe to archetype the DV_EHR_URI used in the
"target" attribute of LINK just using a string matching pattern or do
we need additional mechanisms? The URI value represents an identifier
of some node inside a versioned object, do string patterns matching
DV_EHR_URI values cover for all kinds of target range restrictions
we'd likely want to express if archetyping LINKs? Maybe they actually
do work using wildcards in the right places? How tricky will it be to
implement that constraint checking at runtime data creation?

Best regards,
Erik Sundvall
erik.sundvall@liu.se http://www.imt.liu.se/~erisu/ Tel: +46-13-286733

Excerpts from section 3.2.4 in common_im.pdf:

Purpose:
The LINK type defines a logical relationship between two items, such as two
ENTRYs or an ENTRY and a COMPOSITION. Links can be used across compositions,
and across EHRs. Links can potentially be used between interior (i.e. non
archetype root) nodes, although this probably should be prevented in archetypes.
Multiple LINKs can be attached to the root object of any archetyped structure to
give the effect of a 1->N link
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - -
Use:
1:1 and 1:N relationships between archetyped content elements (e.g. ENTRYs)
can be expressed by using one, or more than one, respectively, DV_LINKs.
Chains of links can be used to see “problem threads” or other logical
groupings of
items.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - -
MisUse:
Links should be between archetyped structures only, i.e. between
objects representing
complete domain concepts because relationships between sub-elements
of whole concepts are not necessarily meaningful, and may be downright
confusing.
Sensible links only exist between whole ENTRYs, SECTIONs, COMPOSITIONs
and so on.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - -

Attributes :

[1..1] meaning: DV_TEXT
Used to describe the relationship, usually in
clinical terms, such as “in response to” (the
relationship between test results and an order),
“follow-up to” and so on. Such relationships
can represent any clinically meaningful connection
between pieces of information.
Values for meaning include those described in
Annex C, ENV 13606 pt 2 [11] under the categories
of “generic”, “documenting and reporting”,
“organisational”, “clinical”,
“circumstancial”, and “view management”.

[1..1] type: DV_TEXT
The type attribute is used to indicate a clinical
or domain-level meaning for the kind of link,
for example “problem” or “issue”. If type values
are designed appropriately, they can be used
by the requestor of EHR extracts to categorise
links which must be followed and which can be
broken when the extract is created.

[1..1] target: DV_EHR_URI
The logical “to” object in the link relation, as
per the linguistic sense of the meaning attribute.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - -
End of excerpts from section 3.2.4 in common_im.pdf

[thomas.beale]

The culprit is lack of time… as usual…

So far I have created a simple test LINK archetype, showing how a jurisdiction, in this case Sweden, might use it. To see it, follow these steps:

1. if you don’t have it, download the ADL workbench (http://www.openehr.org/svn/ref_impl_eiffel/TRUNK/apps/adl_workbench/doc/web/index.html)

2. SVN checkout or update http://www.openehr.org/svn/knowledge2/ - this will get both the latest test archetypes, and the required updated RM schema file, called openehr_rm_200exp.dadl

3. you will have to install the new RM schema manually, by copying it from the rm_schemas directory in the above checkout, to the directory of the same name in the ADL Workbench install area / rm_schemas directory (i.e. C:\program files\openEHR\ADL workbench\rm_schemas, on Windows).

4. To see the test archetypes, create a profile in the ADL Workbench for the path …\knowledge2\TRUNK\archetypes\openEHR_examples\link_archetypes (see here for help - http://www.openehr.org/svn/ref_impl_eiffel/TRUNK/apps/adl_workbench/doc/web/learning_adl_15.html)

5. you can now compile the test Swedish specialisation EVALUATION archetype, that adds a standard LINK archetype to the existing CKM problem-diagnosis archetype
   I have added a constraint of the ‘target’ property of the LINK classes, based on a new experimental ‘target_type’ computed property of the DV_EHR_URI class (added in the new schema). This shows how it would be possible to constraint the target to OBSERVATIONs, but I am pretty sure something stronger than that is needed, more like the semantic archetype slot constraints described here - http://www.openehr.org/wiki/display/spec/Towards+a+definition+of+%27slot%27+semantics .

If anyone has problems with these steps, let me know on this list, and I will provide further information, but normally the above should be enough.

Others are welcome to have commit access to the knowledge2 repository, and help to grow the test archetype set, as well as experiment with ideas on the RM schemas is welcomed.

• thomas beale

(attachments)

[thomas.beale]

I mean to attach a view of the AWB with the LINK archetype compiled - let’s see if that works:

[system]

Wow Tom!

That was a fast, nice and somewhat unexpected answer, now we’re just awaiting the caption text to explain the image

You at least got me poking around for the archetypes, finding
http://www.openehr.org/svn/knowledge2/TRUNK/archetypes/openEHR_examples/link_archetypes/

• So tooling support already does exist, AWB for viewing & validation and text editor for editing (Or is there more?)
• What about the target range constraints, will string matching expressions cover all likely use-cases?
• This means a small modification (inherit LOCATABLE) to the LINK class in the RM to make the reference to used archetype possible to store in the EHR, right? (The “un-archetyped” LINK information storage is already supported I believe, so data entered this way would be readable in the current 1.0.2 RM, even if archetype info will not be present, is that correct?)

Best regards,
Erik Sundvall
erik.sundvall@liu.se http://www.imt.liu.se/~erisu/ Tel: +46-13-286733

(attachments)

[thomas.beale]

Wow Tom!

That was a fast, nice and somewhat unexpected answer, now we’re just awaiting the caption text to explain the image

You at least got me poking around for the archetypes, finding
http://www.openehr.org/svn/knowledge2/TRUNK/archetypes/openEHR_examples/link_archetypes/

• So tooling support already does exist, AWB for viewing & validation and text editor for editing (Or is there more?)

I don’t think editing capability in the AWB will be out of the question in the near-ish future, but I don’t have any bandwidth to go there right now…

• What about the target range constraints, will string matching expressions cover all likely use-cases?

well I think string matching can work, but any lexical matching to achieve semantic purposes is always dodgy. I think we need to be more careful with how we do this, but I have not analysed it that much yet.

• This means a small modification (inherit LOCATABLE) to the LINK class in the RM to make the reference to used archetype possible to store in the EHR, right?

yep - see the experimental RM schema file (you could diff it with the 102 file and you would see the addtions; they are also explained at the top).

(The “un-archetyped” LINK information storage is already supported I believe, so data entered this way would be readable in the current 1.0.2 RM, even if archetype info will not be present, is that correct?)

yep - there would just be no at-code.

• thomas

[system]

Good summary by Erik and quick response by Thomas =)

Some thoughts on this
1. It seems the LINK constraints can be used to express logical
associations between clinical process steps, e.g. a
EVALUATION.health_issue archetype has a LINK to a EVALUATION.care_plan
archetype which in turn has several links to specific order
archetypes. If this is about a condition specific clinical process,
i.e. a clinical guideline, these constraints should most likely to be
expressed on the template level.

2. In runtime, these LINK archetypes can be used to load relevant
archetypes for the details of the next step according to the process
definition. From this perspective, this type of constraints are used
differently than 'ordinary' archetype constriants.

3. The new "target_type" attribute seems to be a good start. We
probably need something like allow_archetypes to express detailed
inclusion criteria on archetypes, and perhaps even templates.

Cheers,
Rong

[system]

Hi!

A question regarding naming/identifiers.

According to http://www.openehr.org/releases/1.0.2/architecture/am/archetype_semantics.pdf
parts of the grammar for identifiers is...
archetype_id: qualified_rm_entity ‘.’ domain_concept ‘.’ version_id
qualified_rm_entity: rm_originator ‘-’ rm_name ‘-’ rm_entity_name
domain_concept: concept_name { ‘-’ specialisation }*

Surely you must just have been sloppy in...
http://www.openehr.org/svn/knowledge2/TRUNK/archetypes/openEHR_examples/link_archetypes/
...where the identifiers as of this writing (Revision 20) are:

openEHR-EHR-EVALUATION.problem.v1.adls
   openEHR-EHR-EVALUATION.diagnosis.v1.adls
      openEHR-EHR-EVALUATION.diagnosis_sweden.v1.adls
openEHR-EHR-LINK.indication.v1.adls

Should not the identifiers instead be:

openEHR-EHR-EVALUATION.problem.v1.adls
   openEHR-EHR-EVALUATION.problem-diagnosis.v1.adls
      openEHR-EHR-EVALUATION.problem-diagnosis-sweden.v1.adls
openEHR-EHR-LINK.indication.v1.adls

Or have the identifier syntax and semantics requirements changed in
ADL/AOM 1.5? I hope note, because that would make AQL querying
implementation a lot harder when asking for an archetype including any
of it's speicialisations...

Isn't there any automatic check in AWB that specialisation identifiers
are correct?

Best regards,
Erik Sundvall
erik.sundvall@liu.se http://www.imt.liu.se/~erisu/ Tel: +46-13-286733

[Peter_Gummer1 (Peter Gummer)]

Erik Sundvall wrote:

openEHR-EHR-EVALUATION.problem.v1.adls
  openEHR-EHR-EVALUATION.diagnosis.v1.adls
     openEHR-EHR-EVALUATION.diagnosis_sweden.v1.adls
openEHR-EHR-LINK.indication.v1.adls

Should not the identifiers instead be:

openEHR-EHR-EVALUATION.problem.v1.adls
  openEHR-EHR-EVALUATION.problem-diagnosis.v1.adls
     openEHR-EHR-EVALUATION.problem-diagnosis-sweden.v1.adls
openEHR-EHR-LINK.indication.v1.adls

Or have the identifier syntax and semantics requirements changed in
ADL/AOM 1.5?

This has changed in ADL 1.5. The hyphen is no longer used.

I'm sure I remember Thomas starting a discussion about this on the
mailing list about a year ago.

- Peter Gummer

[yampeku (Diego Bosca)]

Shouldn't archetype identifiers and file names be separated?

[thomas.beale]

As Peter said, ADL 1.5 changes this. The hyphen is not nedeed (but it is accepted to allow backward compatibility). See http://www.openehr.org/svn/specification/TRUNK/publishing/architecture/am/knowledge_id_system.pdf and also http://www.openehr.org/svn/specification/TRUNK/publishing/architecture/am/dist_dev_model.pdf for a full description of why this is.

• thomas

[ian.mcnicoll]

The draft spec for 1.5 knowledge identifiers can be accessed via

http://www.openehr.org/wiki/display/spec/Development+and+Governance+of+Knowledge+Artefacts

The '-' based specialisation syntax is proposed to be dropped, as it
became very unweildy once you srart to consider how to handle
namespaces within specialisations , particularly when the
specialisation has a different namespace to the parent. It gets even
more confusing when you add in the requirements for templates and
complex archetypes i.e aggregations.

To get around the querying problem that Erik describes, it is proposed
to carry the specialisation inheritance list in the data.

Archetype identifiers are separate from filenames, but in practice,
archetypes and templates do find themselves expressed as individual
files on filesystems and it can be all too easy for versions/
namespaces to get mixed up, if the file names do not carry the same
sort of uniqueness as is embodied in the offical archetype_id.

From Idenitifer document 5.3.3

The other possibility is to include archetype lineage information in
the data itself. This could be a
modified form of the identifier reference in the case of specialised
archetypes to allow lineage information
to be stored.

TBD_14: proposed RM change: ARCHETYPED.archteype_id -> List[ARCHETYPE_ID]; in
LOCATABLE, just continue to use the direct archetype id as currently done.

The simplest form of this would be as a list of operational identifiers, e.g.

se.skl.epj::openEHR-EHR-EVALUATION.genetic_diagnosis.v1.12,
org.openehr.ehr::openEHR-EHR-EVALUATION.diagnosis.v1.29,
org.openehr.ehr::openEHR-EHR-EVALUATION.problem.v2.4

Ian

Dr Ian McNicoll
office / fax +44(0)1536 414994
mobile +44 (0)775 209 7859
skype ianmcnicoll
ian.mcnicoll@oceaninformatics.com

Clinical analyst, Ocean Informatics
openEHR Clinical Knowledge Editor www.openehr.org/knowledge
Honorary Senior Research Associate, CHIME, UCL
BCS Primary Health Care SG Group www.phcsg.org

[thomas.beale]

In ADL 1.5 they are - you can name the archetype files however you like, and put them where you like.

• thomas

[system]

Hi!

Thanks again for quick and informative replies.

Obviously was not paying enough attention when the discussion of the
identifier change was taking place some time ago. I had started
composing a long reply of how query implementation would get more
complex unless the RM was changed at the same time. Then I saw Ian's
reply regarding suggested RM changes, and trashed my reply. Nice

Three perhaps stupid followup questions:

1. Will the XML schema get updated to make sure patient data instances
carry along the archetype/template inheritance in a good way?

2. Should AQL be modified to include a convenient way of specifying if
we are asking for data only entered using a specific archetype or if
we are looking for data entered using that archetype any of its
specialisations? (Previously wildcards might have worked depending on
interpretation/implementation of AQL documentation, now with the 1.5
change they definitely won't.) What should be the default behaviour if
just writing an archetype name in part of the query?

Quoting from the 01 Feb 2010 version of "Knowledge Artefact
Identification" Section 5.3.3:
..."given an archetype X used to create data, the following archetypes
could be used for querying:
• X, i.e. exact same version, revision & commit;
• any previous revision of X;
• any of the specialisation parents of X;
• any previous revision of any of the specialisation parents of X."

Does the "could be used" wording here mean that the default behaviour
of an AQL response should be to retrieve data matching all these
cases?

3. Will the semantics and syntax of the path strings used in PATHABLE
objects be affected? Where is that path syntax actually defined, is
chapter 11 of the Archetype Overview the authoritative source? Has it
ever been possible to find data from specialisations using calls to
methods of PATHABLE? Should it be?

Carrying specialisation lineage (including version numbers) in the
RM/data itself sounds like a safe and good idea. That would be useful
for simplifying e.g. distributed query implementation and for when
you, in multi-purpose GUIs, want to climb up the generalisation ladder
(e.g. when creating archetype based overviews/summaries).

Best regards,
Erik Sundvall
erik.sundvall@liu.se http://www.imt.liu.se/~erisu/ Tel: +46-13-286733

The draft spec for 1.5 knowledge identifiers can be accessed via
http://www.openehr.org/wiki/display/spec/Development+and+Governance+of+Knowledge+Artefacts

...

To get around the querying problem that Erik describes, it is proposed
to carry the specialisation inheritance list in the data.

...

[thomas.beale]

Erik,

good points; see below

Hi!

Thanks again for quick and informative replies.

Obviously was not paying enough attention when the discussion of the
identifier change was taking place some time ago. I had started
composing a long reply of how query implementation would get more
complex unless the RM was changed at the same time. Then I saw Ian's
reply regarding suggested RM changes, and trashed my reply. Nice :-)

Three perhaps stupid followup questions:

1. Will the XML schema get updated to make sure patient data instances
carry along the archetype/template inheritance in a good way?

not 100% sure what you want to say here: do you mean - will existing data be protected (i.e. will a new RM schema be backwardly compatible with existing data) or are you asking about how this inheritance relation would be represented in the RM XSD?

2. Should AQL be modified to include a convenient way of specifying if
we are asking for data only entered using a specific archetype or if
we are looking for data entered using that archetype any of its
specialisations? (Previously wildcards might have worked depending on
interpretation/implementation of AQL documentation, now with the 1.5
change they definitely won't.) What should be the default behaviour if
just writing an archetype name in part of the query?

this is a good question. I have always believed that data based on subsumed archetypes should be the default match for queries, i.e. if you have the path …/items[at0001]/… in your query expression, any data with at0001.1, at0001.0.3 etc should be matched. This is correct provided that the latter specialised codes do indeed correspond to something that is understood as a kind of the parent code (e.g. at0001.4|serum sodium| is a kind of at0001|lab result value|).

However, there obviously needs to be a way to avoid this kind of matching. Currenly AQL handles this via wildcards (the wrong way to do it in my view). I think instead some other query switch is needed to turn off matching of data built by subsumed types.

Quoting from the 01 Feb 2010 version of "Knowledge Artefact
Identification" Section 5.3.3:
..."given an archetype X used to create data, the following archetypes
could be used for querying:
• X, i.e. exact same version, revision & commit;
• any previous revision of X;
• any of the specialisation parents of X;
• any previous revision of any of the specialisation parents of X."

Does the "could be used" wording here mean that the default behaviour
of an AQL response should be to retrieve data matching all these
cases?

see answer above: as long as semantic subsumption holds, in my view the query should automatically match the data from subsumed archetypes.

3. Will the semantics and syntax of the path strings used in PATHABLE
objects be affected? Where is that path syntax actually defined, is
chapter 11 of the Archetype Overview the authoritative source?

currently yes. A dedicated document is needed of course …

 Has it
ever been possible to find data from specialisations using calls to
methods of PATHABLE? Should it be?

if you mean: could a call to these methods with a path of /x/y[at0001]/z against an information structure whose data actually contained /x/y[at0001.4]/z return the latter node? In my view it should. I don’t think this behaviour is specified anywhere properly at all.

Carrying specialisation lineage (including version numbers) in the
RM/data itself sounds like a safe and good idea. That would be useful
for simplifying e.g. distributed query implementation and for when
you, in multi-purpose GUIs, want to climb up the generalisation ladder
(e.g. when creating archetype based overviews/summaries).

I am sure we have not got it all sorted, but so far I think this concept is also safe and interoperable. It does add a bit of complexity, but as far as I can see, it is unavoidable if we want a) any kind of specialisation / subsumption relationships between data models and b) and the ability to query such data.

Q2 and 3 above are important points, and undoubtedly not sufficiently well specified in the specs. Could you record them in the SPEC-PR tracker - http://www.openehr.org/issues/browse/SPECPR - preferably as two separate issues.

thanks

• thomas

[Heath_Frankel3 (Heath Frankel)]

Hi Erik,
I am still catching up from some time-off, interesting discussion seem to
happen while I am away...

I will start with my comments at the start and likely to respond to later
responses.

Heath

Some of the interesting bits I've picked up so far from discussions:
- Maybe it would be a good idea to make LINK inherit from LOCATABLE
and thus become archetypable in itself

[HKF: ] LINK does not need to be LOCATABLE to be archetyped unless you are
talking about LINK being the archetype root. I don't see why we need to do
this, a LINK only make sense to me within the context of its parent. If
there truly is a need for LINK to be an archetype root then perhaps the
ARCHETYPED association should be moved to PATHABLE.

- Tooling support for using LINK in archetypes is currently poor or non
existent

[HKF: ] This is partly my fault, Sam started supporting LINK in the openEHR
Archetype Editor but I could not see how the constraints being specified
could be usable at the archetype level, so we stopped its development until
we had better understanding of the requirements.

- There is very little (if any) reported usage experience of LINK in
openEHR

[HKF: ] True, although this is changing, we are using it in a significant
development exactly in the way that Rong talks about his response, to relate
content within the same thread of care, in particular an indication of
proposed care and the plan of actions for that proposal. We are
implementing these in the application without archetyping them because we
still think this is not something that can be archetyped and we are learning
how they can be used at the template level (as indicated by Rong).
  

- I believe the NHS has somewhat explored LINK usage in LRA using ISO
13606
- If archetyping LINKS, then it would in _some_ cases be desirable to
be able restrict the type of the "target", especially defining what
archetypes the target objects must adhere to (similar to the archetype
slot mechanism).

[HKF: ] Absolutely, this is was evident to me when I asked Sam to stop his
support for LINKs using RegEx on the target uri. It needs to be some sort
of AQL or A-Path expression. Tom's target type is somewhere towards it but
as indicated elsewhere we need to constrain it further to an archetype ID or
even an archetype path, but definitely not a data path/uri.

Please fill in with nore details and thoughts.

Implementers, would it have a big impact on your implementations if
LINK was made LOCATABLE? (Let's say in v 1.0.3)

[HKF: ] I am against this proposal. I originally thought this was necessary
for PARTICIPATION to allow it to be archetyped, but now I don't. I realised
that for an item to have a node_id in the archetype, it doesn't need to have
a node_id attribute in the class. As long as the constraints on the class
attributes in the archetype are distinct for each class constraint (when you
have multiple LINK constraints, the meaning/type/target_* combinations are
disjoint), then we have enough information to match a data instance at
runtime. The node_id in the archetype is only necessary to allow further
constraints to be applied on the node in specialised archetypes/templates.

The need to populate a name on each LINK would be quite painful and
redundant as it is now for every other LOCATABLE. Although the existing
Type attribute could be made a function taking the value of Name as is done
in the Demographic RM.

If this is necessary so that we can create a LINK archetype then I suggest
moving the association to the ARCHETYPED class to the PATHABLE class, this
would be a non-breaking change.

I wonder, is it currently safe to archetype the DV_EHR_URI used in the
"target" attribute of LINK just using a string matching pattern or do
we need additional mechanisms? The URI value represents an identifier
of some node inside a versioned object, do string patterns matching
DV_EHR_URI values cover for all kinds of target range restrictions
we'd likely want to express if archetyping LINKs?

[HKF: ] As I indicated, I don't believe this is useful and why we stopped
development of LINK in the archetype editor.

Maybe they actually do work using wildcards in the right places?

[HKF: ] Yes, I guess if you ignored all the first part of the URI and just
provide the data path part, then it may be possible. But as I indicated
above, I think it needs to be more of an archetype path than a data path. I
realise difference is semantic but relevant in this case. I think A-Path or
AQL (or ADL rules) would be a better representation than a URI. I know Sam
was of the opinion early that URIs could be used for queries, and this
support by the RESTful service community, this is probably the origins of
his intent to use a URI constrain for LINK target. I just don't see URIs
supporting more complicated query requirements, hence AQL (and I am also a
fan of A-Path)

How tricky will it be to
implement that constraint checking at runtime data creation?

[HKF: ] Anything is possible if the constraint is easily mapped into some
kind of query, but like everything with integrity checking, there will be a
significant performance overhead.

[Heath_Frankel3 (Heath Frankel)]

Hi Erik

1. Will the XML schema get updated to make sure patient data instances
carry along the archetype/template inheritance in a good way?

[HKF: ] I have spoken with Tom on this topic considerable, we are looking at
extending the ARCHETYPED class to support a list of archetype_ids (similar
to HL7 CDA class having multiple template_ids) to support matching on any of
these in queries. We think this is the least impact change while supporting
queries without the need for an external archetype ontology service.

2. Should AQL be modified to include a convenient way of specifying if
we are asking for data only entered using a specific archetype or if
we are looking for data entered using that archetype any of its
specialisations? (Previously wildcards might have worked depending on
interpretation/implementation of AQL documentation, now with the 1.5
change they definitely won't.) What should be the default behaviour if
just writing an archetype name in part of the query?

[HKF: ] Yes, RegEx expression will not be useful any more.

Quoting from the 01 Feb 2010 version of "Knowledge Artefact
Identification" Section 5.3.3:
..."given an archetype X used to create data, the following archetypes
could be used for querying:
. X, i.e. exact same version, revision & commit;
. any previous revision of X;
. any of the specialisation parents of X;
. any previous revision of any of the specialisation parents of X."

Does the "could be used" wording here mean that the default behaviour
of an AQL response should be to retrieve data matching all these
cases?

[HKF: ] From my discussions with the clinicians, this seems what they want.
When we designed AQL to use RegEx based on the structured archetype IDs, it
seemed technically reasonable that we wanted to query a generic archetype
without its specialisations so we made it explicit to request a generic
archetype and its specialisations. This will need to be considered in the
next iteration of query engines. We probably need some implementation
guidance on this (along with many other topics).

3. Will the semantics and syntax of the path strings used in PATHABLE
objects be affected? Where is that path syntax actually defined, is
chapter 11 of the Archetype Overview the authoritative source? Has it
ever been possible to find data from specialisations using calls to
methods of PATHABLE? Should it be?

[HKF: ] I would not expect paths to have the same subsumption rules as
queries, I would expect paths to be specific to a data instance.

Heath