Regenerate BASE component with package-qualified classes using latest…

… UML extractor.

.asciidoctorconfig

@@ -0,0 +1,5 @@
+:component: BASE
+
+:package_qualifiers:
+
+:imagesdir: ../

docs/architecture_overview/master02-overview.adoc

@@ -14,13 +14,13 @@ The components in the left group contain the _abstract specifications_ (also kno
 
 * *Foundation (BASE)*: primitive types, definitions, identifiers, other basic types needed across openEHR;
 * *Formalisms (LANG, AM, QUERY)*: various generic formalisms, including BMM (Basic Meta-Model), (ADL (Archetype Definition Language) and AQL (Archetype Query Language);
-* *Content (TERM, RM)*: the models of primary content of the openEHR platform, including demographics, EHR; supporting openEHR Terminology (along with expressions of various ISO, IETF and other vocabularies (language names, territory names, MIME types, etc) that are not typically published in a directly usable format);
+* *Content (TERM, RM)*: the models of primary content of the openEHR platform, including demographics, EHR; supporting openEHR Terminology (along with expressions of various ISO, IETF and other vocabularies (language names, territory names, MIME types, etc.) that are not typically published in a directly usable format);
 * *Process & CDS (PROC, CDS)*: clinical process and clinical decision support components, containing the Task Planning and GDL (Guideline Definition Language) specifications;
 * *Platform Services*: abstract formal APIs defining the interfaces to the openEHR platform.
 
 Some of these specifications (e.g. Antlr grammars) are directly usable in software development. Most of the abstract specifications have concrete expressions in formalisms such as JSON, XML schema, openEHR BMM and REST APIs enabling their direct use in development. These are known as Implementation Technology Specifications (ITSs; also known as 'Platform-Specific Models' or PSMs), and are collected in the {openehr_its_component}[ITS component^] shown on the right. They also constitute openEHR's _interoperability specifications_.
 
-As implementation technologies change over time the ITS specifications will be replaced, while the main group of abstract specifications will generally only change in response to real-world requirements other than information technology.
+As implementation technologies change over time, the ITS specifications will be replaced, while the main group of abstract specifications will generally only change in response to real-world requirements other than information technology.
 
 The {openehr_cnf_component}[CNF component^] at the top defines _conformance criteria_, and is primarily based on ITS artefacts such as REST APIs, XSDs, but also upon AQL queries, archetypes and some other abstract artefacts. It includes a formal definition of the notional openEHR Platform and how to test it in a standard way. This is used as the basis for openEHR product certification and also for procurement tender specification.
 

docs/architecture_overview/master03-aims.adoc

@@ -24,7 +24,7 @@ In this figure, each bubble represents a set of requirements, being a superset o
 bubbles contained within it. Requirements for a generic record of care for any kind of subject in a
 local deployment are represented by the top left bubble. The subsequent addition of requirements corresponding
 to living subjects and then human subjects is represented by the bubbles down the left side
-of the diagram. The requirements represented by the largest bubble on the left hand side correspond to
+of the diagram. The requirements represented by the largest bubble on the left-hand side correspond to
 'local health records for human care', such as radiology records, hospital EPRs and so on. Additional
 sets of requirements represented by wider bubbles going across the diagram correspond to extending
 the scope of the content of the care record first to a whole subject (resulting in a patient-centric, longitudinal
@@ -45,7 +45,7 @@ requirements of an integrated shared care record can also be deployed as (for ex
 radiology record system.
 
 Some of the key requirements developed during the evolution of GEHR to openEHR are listed in the
-following sections, corresponding to some of the major requirements groups of <<scope_of_openehr>>.
+following sections, corresponding to major requirements groups of <<scope_of_openehr>>.
 
 === Generic Care Record Requirements
 
@@ -93,7 +93,7 @@ summarised as:
 * Reducing the incidence of patients being overlooked in the healthcare system due to information not being communicated;
 * Reducing the duplication of investigations and other tests and procedures due to results not being available in the local computing environment;
 * Improved prevention and early detection, based on predictive risk factor analysis, which is possible with quality EHR data;
-* Improved decision making through decision support tools with access to the patient’s whole EHR;
+* Improved decision-making through decision support tools with access to the patient’s whole EHR;
 * Improving access to and computation of evidence based guidelines;
 * Increasing targeted health initiatives known to be effective, based on patient criteria; and
 * Reduced hospitalisations and readmissions.

docs/architecture_overview/master05-package_structure.adoc

@@ -91,11 +91,11 @@ image::{diagrams_uri}/spec_component-lang.svg[id=spec_component_lang, align="cen
 
 === Basic Meta-Model (BMM)
 
-The {openehr_bmm}[BMM specification^] defines a generic meta-model, suitable for formally expressing object-oriented models, including those of openEHR (RM etc). It is roughly an equivalent of UML's XMI, but fixes various problems with the latter around generic (template) types, while being significantly less complex and fragile. BMM models can be expressed in the {openehr_odin}[ODIN syntax^] or any other regular object syntax (JSON etc), and conveniently edited by hand. BMM files are used within tools such as the {openehr_awb}[openEHR ADL Workbench^] and some of the openEHR tooling software.
+The {openehr_bmm}[BMM specification^] defines a generic meta-model, suitable for formally expressing object-oriented models, including those of openEHR (RM etc). It is roughly an equivalent of UML's XMI, but fixes various problems with the latter around generic (template) types, while being significantly less complex and fragile. BMM models can be expressed in the {openehr_odin}[ODIN syntax^] or any other regular object syntax (JSON etc), and conveniently edited by hand. BMM files are used within tools such as the {openehr_awb}[openEHR ADL Workbench^] and some openEHR tooling software.
 
 The BMM is primarily intended to reduce complexity for tools that consume reference model definitions, but is not the only way to implement such tools. Similar tools can be based directly on the openEHR published UML models, as long as typing, template types and qualified attributes are properly handled. Another alternative means of working with models is via software library implementations of the relevant models (openEHR Reference Model etc).
 
-Consequently, understanding or use of BMM specification or models based on it is not necessary in order to implement openEHR systems. However BMM provides a convenient format for model processing, e.g. to auto-generate code stubs in a new language.
+Consequently, understanding or use of BMM specification or models based on it is not necessary in order to implement openEHR systems. However, BMM provides a convenient format for model processing, e.g. to auto-generate code stubs in a new language.
 
 === Object Data Instance Notation (ODIN)
 
@@ -244,13 +244,13 @@ The Query Service defines the interface via which AQL queries which may be store
 
 === Terminology Interface
 
-The Terminology Service service provides the means for all other services to access any terminology available in the health information environment, including basic classification vocabularies such as {who_icd}[ICDx^] and {who_icpc}[ICPC^], as well as more advanced ontology-based terminologies. Following the concept of
+The Terminology Service provides the means for all other services to access any terminology available in the health information environment, including basic classification vocabularies such as {who_icd}[ICDx^] and {who_icpc}[ICPC^], as well as more advanced ontology-based terminologies. Following the concept of
 division of responsibilities in a system-of-systems context, the Terminology Service abstracts the different underlying architectures of each terminology, allowing other services in the environment to access terms in a standard way. The Terminology Service is thus the gateway to all ontology- and terminology-
 based knowledge services in the environment, which along with services for accessing guidelines, drug data and other "reference data" enables inferencing and decision support to be carried out in the environment.
 
 == Global View
 
-The figure below shows all of the openEHR specifications, i.e. object models, languages and APIs, arranged by component. This view abstracts away the components and top-level UML packages, providing a useful _aide memoire_ picture of the totality of openEHR specifications. Dependencies only exist from higher elements to lower elements. The CNF and ITS components are separated since they are semantically derivative from the primary specifications, but are primary artefacts for downstream software engineering use. The other usable software artefact comes in the form of class libraries directly implementing the formal specifications.
+The figure below shows the openEHR specifications, i.e. object models, languages and APIs, arranged by component. This view abstracts away the components and top-level UML packages, providing a useful _aide memoire_ picture of the totality of openEHR specifications. Dependencies only exist from higher elements to lower elements. The CNF and ITS components are separated since they are semantically derivative from the primary specifications, but are primary artefacts for downstream software engineering use. The other usable software artefact comes in the form of class libraries directly implementing the formal specifications.
 
 [.text-center]
 .openEHR Components and specifications - global view

docs/architecture_overview/master06-design_of_the_ehr.adoc

@@ -103,7 +103,7 @@ The choice of these types is based on the clinical problem-solving process, desc
 .Relationship of information types to the investigation process
 image::{openehr_rm_releases}/docs/ehr/diagrams/clinical_investigator_recording_process.svg[id=clinical_investigator_process,align="center",width="65%"]
 
-This figure shows the cycle of information creation due to an iterative, problem solving process typical
+This figure shows the cycle of information creation due to an iterative, problem-solving process typical
 not just of clinical medicine but of science in general. The 'system' as a whole is considered to be made up of two
 parts: the 'patient system' and the 'clinical investigator system'. The latter consists of health carers,
 and may include the patient (at points in time when the patient performs observational or therapeutic

docs/architecture_overview/master07-security.adoc

@@ -9,7 +9,7 @@ respect the privacy of disclosed data) are primary concerns of many consumers wi
 Health systems. A widely accepted principle is that information provided (either directly or due to
 observation or testing of specimens etc.) in confidence by a patient to health professionals during an
 episode of care should only be passed on or otherwise become available to other parties if the patient
-agrees; put more simply: _data sharing must be controlled by patient consent_. A more complex subrequirement
+agrees; put more simply: _data sharing must be controlled by patient consent_. A more complex sub-requirement
 for some patients is allowing differential access to parts of their health record, for example,
 relatively open access rights to most of the health record, but limited access to sexual or mental
 health items. The interrelatedness of health information can make this difficult. For example the medication
@@ -242,7 +242,7 @@ this external identifier is actually set in `PARTY_SELF` instances, as follows:
 
 This simple mechanism provides a basic protection against certain kinds of information theft or hacking
 if used properly. In the most secure situation, a hacker has to steal not just EHR data but also separate
-demographic records and an identity cross reference database, both of which can be located on
+demographic records and an identity cross-reference database, both of which can be located on
 different machines (making burglary harder). The identity cross-reference database would be easy to
 encrypt or protect by other security mechanisms.
 

docs/architecture_overview/master08-versioning.adoc

@@ -98,7 +98,7 @@ A typical sequence of changes to a repository is illustrated in the following fi
 .Contributions to the Repository (delta form)
 image::{diagrams_uri}/ehr_contributions_deltas.svg[id=contribution_deltas, align="center", width=80%]
 
-This shows the effect of four Contributions (left hand side) to a repository containing a number of CIs. As each Contribution is made, the repository is changed in some way. The first brings into existing a new CI, and modifies two others (changes indicated by the 'update' triangles). The second Contribution causes the creation of a new CI due to importing from a lab data feeder system. The third causes a creation as well as three changes, while the fourth causes an amendment to an existing CI.
+This shows the effect of four Contributions (left-hand side) to a repository containing a number of CIs. As each Contribution is made, the repository is changed in some way. The first brings into existing a new CI, and modifies two others (changes indicated by the 'update' triangles). The second Contribution causes the creation of a new CI due to importing from a lab data feeder system. The third causes a creation as well as three changes, while the fourth causes an amendment to an existing CI.
 
 One nuance which should be pointed out is that in the figure above Contributions are shown as if they are
 literally a set of deltas, i.e. exactly the changes which occur to the record. Thus, the first Contribution

docs/architecture_overview/master09-identification.adoc

@@ -70,11 +70,11 @@ au.gov.health.rdh.ehr1                  -- id of creating system
 
 This 3-part tuple is known as a _version locator_ and is defined by the class `OBJECT_VERSION_ID` in the {openehr_base_types}#_identification_package[`identification` package section of the Base Types specification^]. The openEHR version identification scheme is described in detail in the {openehr_rm_common}#_change_control_package[`change_control` package section of the Common IM^].
 
-The contained top-level content item (i.e. a `COMPOSITION` etc) also has a `_uid_` attribute (inherited from `LOCATABLE`), and it is strongly recommended that this be populated with a copy of the `OBJECT_VERSION_ID` from the containing `VERSION<X>` object. This facilitates identifying versions from a naked content object e.g. returned in a query.
+The contained top-level content item (i.e. a `COMPOSITION` etc.) also has a `_uid_` attribute (inherited from `LOCATABLE`), and it is strongly recommended that this be populated with a copy of the `OBJECT_VERSION_ID` from the containing `VERSION<X>` object. This facilitates identifying versions from a naked content object e.g. returned in a query.
 
 A `VERSION` can be _referred to_ using a normal `OBJECT_REF` that contains a copy of the version's `OBJECT_VERSION_ID`.
 
-The last component of identification is the _path_, used to refer to an interior node of a top-level structure of some type `X` (e.g. `COMPOSITION`, `PARTY`, etc), the latter identified by its Version locator. Paths in openEHR follow an Xpath style syntax, with slight abbreviations to shorten paths in the most common cases. Paths are described in detail below.
+The last component of identification is the _path_, used to refer to an interior node of a top-level structure of some type `X` (e.g. `COMPOSITION`, `PARTY`, etc.), the latter identified by its Version locator. Paths in openEHR follow an Xpath style syntax, with slight abbreviations to shorten paths in the most common cases. Paths are described in detail below.
 
 To refer to an interior data node from outside a top-level structure, a combination of a  version locator
 and a path is required. This is formalised by the `LOCATABLE_REF` class, also in the {openehr_base_types}#_identification_package[`identification`

docs/architecture_overview/master10-archetypes.adoc

@@ -44,7 +44,7 @@ A template is used at runtime to create default data structures and to validate
 all data in the EHR conform to the constraints defined in the archetypes referenced by the template. In
 particular, it conforms to the path structure of the archetypes, as well as their terminological constraints.
 Which archetypes were used at data creation time is written into the data, in the form of both
-archetype identifiers at the relevant root nodes, and archetype node identifiers (the [atnnnn] codes),
+archetype identifiers at the relevant root nodes, and archetype node identifiers (the `[atnnnn]` codes),
 which act as normative node names, and which are in turn the basis for paths. When it comes time to
 modify the same data, these archetype node identifiers enable applications to retrieve and use the
 original archetypes, ensuring modifications respect the original constraints.