EHR Package
Overview
The openEHR EHR is structured according to a relatively simple model. A central EHR object identified by an EHR id specifies references to a number of types of structured, versioned information, plus a list of Contribution objects that act as audits of change-sets made to the EHR. The high-level structure of the openEHR EHR is shown in below.
In this figure, the parts of the EHR are as follows:
-
EHR: the root object, identified by a globally unique EHR identifier;
-
EHR_access (versioned): an object containing access control settings for the record;
-
EHR_status (versioned): an object containing various status and control information, optionally including the identifier of the subject (i.e. patient) currently associated with the record;
-
Folders (versioned): optional hierarchical folder structures that can be used to logically index Compositions;
-
Compositions (versioned): the containers of all clinical and administrative content of the record;
-
Contributions: the change-set records for every change made to the health record; each Contribution references a set of one or more Versions of any of the versioned items in the record that were committed or attested together by a user to an EHR system.
The ehr package is illustrated in rm.ehr package below. The classes have a more or less one-to-one correspondence with the objects shown in High-level EHR structure. Each versioned object of type X is defined by a class VERSIONED_X, which is a binding of the type X to the generic type paremeter T in the generic type VERSIONED_COMPOSITION (while such bindings do not strictly require classes of their own, they facilitate implementation in languages lacking genericity).
The Parts of the EHR
Root EHR Object
The root EHR object records three pieces of information that are immutable after creation: the identifier of the system in which the EHR was created, the identifier of the EHR (distinct from any identifier for the subject of care), and the time of creation of the EHR. Otherwise, it simply acts as an access point for the component parts of the EHR.
The system_id attribute is used to record the identifier of the logical EHR repository to which the data containing the audit are committed. What constitutes a 'system' in this context is described in more detail in the Architecture Overview.
References rather than containment by value are used for the relationship between the EHR and VERSIONED_X objects, reflecting the vast majority of retrieval scenarios in which only selected (usually recent) items are needed. Containment by value would lead to systems which retrieved all VERSIONED_X objects every time the EHR object was accessed.
EHR Access
Access control settings for the whole EHR are specified in the EHR_ACCESS object. This includes default privacy policy, lists of identified accessors (individuals and groups) and exceptions to the default policies, each one identifying a particular Composition in the EHR. All changes to the EHR Access object are versioned via the normal mechanism, ensuring that the visible view of the EHR at any previous point in time is reconstructable.
Because security models for health information are still in their infancy, the openEHR model adopts a completely flexible approach. Only two hard-wired attributes are defined in the EHR_ACCESS class. The first is the name of the security scheme currently in use, while the second (settings attribute) is an object containing the access settings for the EHR according to that particular scheme. Each scheme is defined by an instance of a subclass of the abstract class ACCESS_CONTROL_SETTINGS, defined in the Security Information Model.
EHR Status
The EHR_STATUS object contains a small number of hard-wired attributes, and an archetyped other_details part. The former are used to indicate who is (currently understood to be) the subject of the record, and whether the EHR is actively in use, inactive, and whether it should be considered queryable. As for elsewhere in the openEHR EHR, the subject is represented by a PARTY_SELF object, enabling it to be made completely anonymous, or alternatively to include a patient identifier. The subject is included in the EHR Status object because it can change, due to errors being discovered in the allocation of records to patients. If the anonymous form is used, the change will be made elsewhere in a cross-reference table; otherwise the EHR Status object will be updated. Because it is versioned, all such changes are audit-trailed, and the change history can be reconstructed.
Other EHR-wide meta-data may be recorded in the archetyped part of this object, including runtime environment settings, software application names and version ids, identification and versions of data resources such as terminologies and possibly even actual software tools, configuration files, keys and so on. Such information is commonly versioned in software configuration management systems, in order to enable the reconstruction of earlier versions of software with the correct tools. One reason to store such information at all is that it adds to medico-legal support when clinicians have to justify a seemingly bad decision: if it can be shown that the version of software in use at the time was faulty, they are protected, but to do this requires that such information be recorded in the first place.
Compositions
The main data of the EHR is found in its Compositions, i.e. instances of the COMPOSITION class in the RM. Composition is based on the notion of a unit of information resulting from the interaction of a healthcare agent (subject or healthcare professional) with the EHR. It is designed to satisfy the following needs, which include the well-known ACID characteristics of transactions [1].
-
durability: the need for a persistent unit of information committal in the record;
-
atomicity: the need for a minimal unit of integrity for clinical information, corresponding to a minimal unit for committal, transmission and security;
-
consistency: the need for contributions to the record to leave the record in a consistent state;
-
isolation: the need for contributions to the record by simultaneous users not to interfere with each other;
-
indelibility: the requirement that information committed to the record be indelible in order to support later investigations, for both medico-legal and process improvement purposes, and the consequent requirement to be able to access previous states of the record;
-
modification: the need for users to be able to modify EHR contents, in order to correct errors or update previously recorded information (e.g. current medications, family history); and
-
traceability: the need to record adequate auditing information at committal, in order to provide clinical and legal traceability.
The Composition concept originated from the 'Transaction' concept of the GEHR project [2], [3], [4], [5]. In openEHR, it was renamed to 'Composition' (the name of the equivalent concept in ISO 13606-1), and it has been expanded and more formally defined in openEHR in two ways. Firstly, the idea of a unit of committal has been formalised by the openEHR model of change control (see the openEHR Common Information Model); how this applies to the EHR and Compositions is described below.
Secondly, the informational purpose of a Composition is not just to capture data from a passing clinical event such as a patient contact, but also to track longitudinal significant patient state, such as problems, allergies and medications. Accordingly, openEHR Compositions are temporally classified using a small number of broad categories recorded in the COMPOSITION.category attribute. Categories include event, episodic and persistent. From a scientific realist ontological point of view, the kind of information recorded in a persistent Composition approximates a description of some continuant aspect of the patient (see [6], [7]). This is in contrast with event Compositions, which record occurrents, i.e. events or states that occurred or were true at some moment in time. The episodic category corresponds to information that is relevant for the period of time of a care episode.
Persistent Compositions
In an EHR, there is a need to record items that summarise the key aspects of patient state, which are of ongoing relevance in the record. These are often separated by clinicians into well-known categories, such as:
-
Problem list - list of current problems, issues or concerns;
-
Current medications - list of patient medications that are active or suspended;
-
Therapeutic precautions - list of allergies and interactions relevant to care;
-
Vaccination history - list of vaccinations; acts as a proxy for patient immunity state;
-
Patient preferences - list of proscribed and/or preferred types of treatment;
-
Lifestyle - e.g. substance use, profession-related information;
-
Family history - major problems in biological relatives; acts as a proxy for patient risk;
-
Social situation - picture of patient living situation relevant to care provision;
-
Care plan - Plan(s) produced by clinicians describing planned management of chronic problems.
Persistent Compositions can be thought of as proxies for the state or situation of the patient, which are maintained as a single source-of-truth over an entire patient lifetime. The intent is that any changes or updates are applied to the same logical composition instance as new versions. Together they provide a picture of the patient over time. The total number of Persistent Compositions is normally small for any given patient even with the possibility of more than one instance of some, e.g. multiple condition-specific problem lists. However the number of versions due to updating over time may be significant.
Event Compositions
Event Compositions record what happens during healthcare system activities performed with and/or for the patient, such as:
-
observations, assessments, orders and actions performed during a patient contact;
-
actions performed during an activity in which the patient is not a participant e.g. surgery;
-
actions performed during an activity in which the patient is not present e.g. pathology testing.
An important job of the event Composition is to record not only the data from the healthcare event, such as observations on the patient, but also to record the event context information, i.e. the who, when, where and why of the event.
Over time, the number of event Compositions is likely to far outstrip the number of persistent Compositions in a typical EHR, while the average number of versions per Composition (normally only due to corrections) will be far lower.
Episodic Compositions
Compositions may be classified as episodic if they contain information relevant to an ongoing care situation spanning sigificant time, such as pregnancy and birth, major surgery and recovery etc. During a specific episode of care, Event Compositions will still be used to record normal clinical events, particularly routine observations. However, assessments, summaries and care plans specific to the condition being treated may be committed in Compositions with category set to episodic to indicate that they should be treated as having a persistent-like quality i.e updated as as single instance source-of-truth, but only maintained as such for a defined period or set of conditions and not for the entire life of the patient. An example is a Problem list that is maintained as a continuously updated single instance during a hospital admission but only for the duration of that admission. If the patient is re-admitted, a new instance of an Episodic Composition is then created and continually updated for that admission.
Since episodic Compositions are typically regarded as no longer relevant once the episode of care is considered complete, it may be useful to mark them as such. This may be done for a Composition whose owning Version is in the lifecycle state completed by setting the owning ORIGINAL_VERSION.lifecycle_state to the inactive state. If the owning Version is in the incomplete state, it may be abandoned. Version lifecycle transitions are described in detail in the openEHR Common Information Model.
Folders
As Compositions accumulate over time in the EHR, they form a long-term patient history. The folders structures can be used in the EHR to index Compositions using one or more versioned hierarchies of FOLDER objects. In the openEHR model, Folder structures do not contain Compositions, only references to them. More than one Folder can therefore refer to the same Composition or other target object. If folders is not Void, the directory attribute always contains a reference to the first member, for backward compatibility with pre-Release 1.1.0 systems.
Structurally, each reference in folders points to a logical tree of FOLDER objects each potentially containing references to COMPOSITIONs, or possibly just more FOLDERS. Each such tree is versioned, i.e. each version of one folder tree contains a modified version of the previous state of the tree. Folder trees consist of FOLDER objects, which inherit from the LOCATABALE, enabling archetypes to be used to define specific folder tree structures. Within a Folder archetype, the details attribute may be configured to contain meta-data specific to the purpose of the Folder (tree).
The directory reference may be considered by convention as referring to a folder hierarchy that is shared by all users of the EHR to which it is attached, e.g. all medical specialities, departments or settings. It might thus be used to represent episodes. In this case, the other Folder hierarchies referred to by folders might be created, maintained and used by different departments, specialities etc. However, completely different usage of the folder structures is possible. Use of Folder archetypes should be considered for communicating the intended usage in a particular system.
In any Folder hierarchy, regardless of specific use, Folders may be added or removed contemporaneously or subsequently to the committal of the referenced Compositions, including after substantial time has passed. Contemporaneous additions would normally be included in the same Contribution as the referenced Compositions. Similarly, at any time, an entirely new Folder hierarchy may be added, which will be referenced by a new member of the EHR.folders attribute.
Semantically, Folders may be used to manage a simple classification of Compositions, e.g into Event and Persistent, or they might be used to create categories based on episodes or other groupings of Compositions.
A Folder structure containing references to Compositions is shown below, in which the following Folders are used:
-
Persistent compositions: compositions containing information which is valid in the long term;
-
Diabetes: compositions relating to diabetic care, arranged in sub-folders;
-
GP Encounters: GP encounters relating to diabetes;
-
Episode 03-07-2003 - 05-07-2003: diabetes care episode;
-
Episode xxxx: other diabetes care episodes;
-
-
(other problem): Folders indexing Compositions relating to other problems
This structure separates out Compositions on the basis of likely access by applications. Persistent Compositions remain relevant, usually for the patient lifetime, consequently need to be quickly accessible by numerous applications views. Event Compositions contain information whose relevance may fade quickly (e.g. vital signs measurements) or which are effectively indexed by various persistent compositions (e.g. diagnoses). They are indexed in this example by a Folder structure that makes it easy to find Compositions on the basis of problem type (diabetes etc), and then by type of visit.
Neither the Folder names nor the Composition names illustrated above are part of the openEHR EHR reference model: all such details are provided by archetypes; hence, EHR structures based on completely different conceptions of division of information, or even different types of medicine are equally possible.
The Folder hierarchy in each member of the folders attribute is maintained in its own versioned object, ensuring that changes to the indexing structure are versioned over time in the same way as changes to the EHR content itself.
Tags
Items in the EHR may be tagged using openEHR tags, which are lightweight annotations that may be used to thematically classify previously committed data items for convenient subsequent retrieval. They are described in detail in the Common IM Tags section.
Tags are associated with an EHR via the EHR.tags attribute, but have no direct association with the objects they annotate. This has the following consequences:
-
they may be added at any time with respect to the commit time of the content they annotate, including much later;
-
they do not constitute part of the content they annotate;
-
accordingly, where they annotate versioned content, they do not cause re-versioning of the content;
-
a distinct tag instance is used to represent each use of the tag.
The last point implies that if there is a tag "clin-proj-27a" and it is used on 13 EHR content items, there will be 13 separate tag instances with key = "clin-proj-27a". If one is modified or deleted, it has no effect on the others.
According to the model, all tags reside within one logical list, i.e. EHR.tags. No grouping is used. In order to achieve efficient access of all tags with the same key, indexing would be required.
The primary use of tags post-creation is in querying, and their use is supported directly in the openEHR AQL query language such that a query mentioning a tag (either by key, or key/value pair if applicable) will return all items of any RM type annotated by the tag in question.
Change Control in the EHR
Given an EHR in which there is an EHR Access object, EHR Status object, Event and Persistent Compositions, and possibly hierarchical Folders structures, the general model of update of the EHR is that any of these might be created and/or modified during an update. The simplest, most common case is the creation of a single contact Composition. Another common case will be the creation of an Event Composition, and modification of one or more Persistent Compositions, e.g. due to facts learned in the consultation about family history, or due to prescription of new medications. Other types of updates include corrections to existing Compositions, and acquisition of Compositions from another site such as a hospital. Any of these updates might also include a change to the folder structure, or the moving of existing Compositions to other Folders. Naturally these scenarios depend on a structure of the record including event and persistent compositions, and a folder structure. In the extreme, an EHR consisting only of event Compositions and no Folders will experience only the creation of a single Composition for most updates, with acquisitions being the exception. Less often, updates will be made to the EHR Access and EHR Status objects, according to the management and access control needs of the patient and health care providers.
In general, the following requirements must always be met, regardless of the particular changes made at any one time:
-
the record should always be in a consistent informational state;
-
all changes to the record be audit-trailed;
-
all previous states of the record be available for the purposes of medico-legal investigation.
These requirements are satisfied in openEHR via the use of the change control and versioning facilities defined in the Common Information Model. A key facet of the approach is the use of change-sets, known as Contributions in openEHR. Applied to the EHR, they can be visualised as shown below:
-
The first is due to a patient contact, and causes the creation of a new contact composition; it also causes changes to the problem list, current medications and care plan compositions (once again, in a differently designed record, all this information might have been contained in a single event Composition; likewise, it might be been distributed into even more Compositions).
-
The next Contribution is the acquisition of test results from a pathology laboratory.
-
The third is another contact in which both family history and the folder structure are modified.
-
This fourth is an error correction (e.g. a mispelled name, wrongly entered value), and shows that there can be a Contribution even when there is no healthcare event.
-
The last is an update to the EHR status information in the EHR, due to a software upgrade.
The list of Contributions made to a record is recorded along with changes to the data, so that not only are changes to top-level objects (EHR Acces, Composition etc) captured, but the list of changes forming a change set due to a user commit is always known as well.
Versioning of Compositions
Versioning of Compositions is achieved with the VERSIONED_OBJECT<T> type from the Common IM change_control package, which in the composition package is explicitly bound to the COMPOSITION class, via the class VERSIONED_COMPOSITION which inherits from the type VERSIONED<COMPOSITION>.
The effect of version control on Compositions is visualised in the figure below. The versions (each version being an ORIGINAL_VERSION<COMPOSITION>) shown here in a VERSIONED_COMPOSITION are the same versions shown along each vertical line in Contributions to the EHR, this time shown with their associated audit items. The set of versions are understood as a set of successive modifications of the same data in time.
The VERSIONED_COMPOSITION can be thought of as a smart repository: how it stores successive versions in time is an implementation concern (there are a number of intelligent algorithms available for this), but what is important is that its functional interface enables any version to be retrieved, whether it be the latest, the first, or any in between.
Versioning Scenarios
The following scenarios for creating new COMPOSITION versions have been identified as follows.
| Case 0 |
information is authored locally, causing the creation of a new |
| Case 1 |
information is modified locally, such as for the correction of a wrongly entered datum in a composition. This causes the creation of a new |
| Case 2 |
information received from a feeder system, e.g. a test result, which will be converted and used to create a new |
| Case 3 |
an |
In summary, the AUDIT_DETAILS is always used to document the addition of information locally, regardless of where it has come from. If there is a need to record original audit details (via the COMPOSITION.feeder_audit), they become part of the content of the versioned object.
EHR Creation Semantics
EHR Identifier Allocation
openEHR EHRs are created due to two types of events. The first is a new patient presenting at the provider institution. An EHR may be created due to this event, without reference to any other openEHR EHRs that may exist in the broader community or jurisdiction. In this case, the EHR will be allocated a new, globally unique EHR id. This establishes the new EHR as an intentional clone of the source EHR (or more correctly, part of the family of EHRs making up the virtual EHR for that patient).
On the other hand, an openEHR EHR may be created in an organisation as a logical clone (probably partial) of an EHR for the patient that exists in some other system. This might happen as a normal part of the front-desk registration / admission process, i.e. the local EHR system is able to interrogate an EHR location service and discover if any other EHR exists for this patient, or it may occur due to purely electronic communications between two providers, i.e. the EHR is created because an Extract of an EHR has been sent from elsewhere as part of a referral or similar communication. In this second case, the EHR id should be a copy of the EHR id from the other institution. In all cases, the EHR.system_id value should be set to the value that would normally be used for locally created EHRs. In the case of creating a cloned EHR, the system_id is from the receiving (cloning) system.
In theory such a scheme could guarantee one EHR id per patient, but of course in reality, various factors conspire against this, and it can only approximate it. For one thing, it is known that providers routinely create new EHRs for a patient regardless of how many other EHRs already exist for that patient, simply because they have no easy way to find out about those EHRs. Ideally, this situation would be improved in the openEHR world, but due to reliance on such things as distributed services and reliable person identification, there are no guarantees. The best that can be said is that the EHR id allocation scheme can help support an ideal EHR id-per-patient situation if and when it becomes possible.
EHR Creation
When an EHR is created, the result should be a root EHR object, an EHR Status object, and an EHR Access object, plus any other house-keeping information the versioning implementation requires. In a normal implementation, the EHR Status and EHR Access objects would be created and committed in a Contribution, just as any Composition would be. The EHR Status object has a special status in the EHR, indicating whether the EHR should be included in querying, whether it is modifiable, and by implication, whether it is active. Flags might be set to indicate that it is test record, or for educational or training purposes. The initial creation operation has to supply sufficient parameters for creation of these two objects, including:
-
system_id- identifier of EHR repository of the system; -
ehr_id- the unique identifier of this EHR; -
subject_id- optional; the use ofPARTY_SELFallows completely anonymous EHRs; -
is_queryableflag; -
is_modifiableflag - indicates whether the content of the EHR is allowed to be modified (theEHR_STATUSobject itself is always modifiable); -
any other flags required by the EHR Status object in the local implementation.
is is strongly recommended that a UUID always be used for the ehr_id field. This is common practice among implementers.
|
The EHR id will either be a new globally unique identifier, in the case of first time EHR creation for this patient in the health system, or else the same identifier as an existing EHR for the same subject in another system, in the case of an EHR move or copy. The effect of EHR copying / synchronising between systems is that EHRs with the same identifier can be found within multiple systems. However if the same patient presented at multiple provider locations with no EHR sharing capability, a new EHR with a unique identifier will be created at each place. If a later request for copying occurs (e.g. due to a request for an EHR Extract) between two providers, the requesting institution will perform the merge of the received copy into the existing EHR for the same patient.
The main consequences in a distributed environment are as follows:
-
multiple EHR ids for a given patient indicate a mobile patient, but lack of systematic EHR sharing;
-
one EHR id everywhere for the patient indicates a seamlessly integrated distributed environment, most likely with a global identification service.
Note that the first situation is not a problem, and is not the same as the situation in which two EHRs are identified as being for different patients (i.e. subject id rather than EHR id is different) when in fact they are for the same person.
EHR Active Status
The EHR_STATUS.is_modifiable attribute is used to indicate whether the contents of an EHR are modifiable, and is set to True if the EHR is considered active. An EHR’s 'contents' consist of everything other than the EHR_STATUS object, i.e. its Compositions (Versioned objects referred to by the compositions attribute), its hierarchical Folders (Versioned objects referred to by the folders attribute) and any other content that may be added in later releases of this specification. An active EHR is used within a given EHR system as the primary patient record for a subject. An EHR may be deactivated in circumstances such as the following:
-
the patient has died, and no further updates (typically relating to the death) are required;
-
the EHR is discovered to be a duplicate or additional record for a patient already having a primary EHR;
-
the patient formally opts out of further data recording and/or sharing, with the effect that no further additions can be made by healthcare providers to this EHR;
-
the EHR is to be moved to another system (usually due to patient move), but the original copy will not or cannot be deleted for legal or other administrative reasons.
In any of these situations, the EHR can be deactivated by setting is_modifiable to False. An inactive EHR is still visible in the system, and will remain queryable, unless the is_queryable attribute is also set to False.
Time in the EHR
There are numerous times recorded in the EHR, at varying levels of granularity. Certain times are a guaranteed by-product of the scientific investigation process, including time of sampling or collection; time of measurement, time of a healthcare business event, time of data committal. The following figures illustrate the relationship between points on the timeline of real-world clinical activity, and the corresponding data elements in the openEHR EHR.
The first figure shows the relationships for a physical examination at a GP visit.
In this scenario, an observation (say, of blood pressure) is instantaneous for all practical purposes. This may be contrasted with lab testing, shown below, where the sample time (moment of specimen collection) is usually different from the time of analysis and reporting of the sample. The time lag may be as long as the specimen is biochemically stable such that the analysis will still accurately reflect the clinical situation in the patient at the time of specimen-taking.
The following figure shows the relationships between real world time points and openEHR data for radiology.
The last example shown below shows the relationship of time and EHR data for in-patient nursing observations, where the notion of 'encounter' is somewhat artificial.
Other times to do with diagnoses (time of onset, time of resolution, time of last episode) and medication management (time started taking medication, time stopped, time suspended, etc) are specific to the particular type of information (e.g. diagnosis versus prognosis versus recommendation) and are generally represented as archetyped date/time values within Evaluation objects. Basic timing information is modelled concretely in the Instruction and Action Entry types, while archetyping is used to express timing information that is specific to particular content.
Historical Views of the Record
It is important to understand that the COMPOSITION versions at a previous point in time represent a previously available informational state of the EHR, at a particular EHR node. Such previous state include only those Compositions from other sources as have been acquired by that point in time, regardless of whether the acquired information pertains to clinical information recorded earlier. A previous historical state of the EHR thus corresponds to what users of a system could see at a particular moment of time. It is important to differentiate this from previous clinical states of the patient: previous informational states of the EHR might include acquired information which is significantly older than the point in time when merging occurred. A previous clinical state of the patient would be a derivable view of the EHRs in all locations for the patient - what is sometimes called the virtual EHR - at a given point in time, minus acquired Compositions, since these constitute (usually out-ofdate) copies of Compositions primarily available elsewhere.
It is previous informational states with which we are concerned for medico-legal purposes, since they represent the information actually available to clinicians at a health-care facility, at a point in time. But previous clinical views may be useful for reconstructing an actual sequence of events as experienced by the patient.
Class Descriptions
EHR Class
-
Definition
-
Effective
-
BMM
-
UML
Class |
EHR |
|||
|---|---|---|---|---|
Description |
The EHR object is the root object and access point of an EHR for a subject of care. |
|||
Attributes |
Signature |
Meaning |
||
1..1 |
system_id: |
The identifier of the logical EHR management system in which this EHR was created. |
||
1..1 |
ehr_id: |
The unique identifier of this EHR.
|
||
0..1 |
contributions: |
List of contributions causing changes to this EHR. Each contribution contains a list of versions, which may include references to any number of |
||
1..1 |
ehr_status: |
Reference to |
||
1..1 |
ehr_access: |
Reference to |
||
0..1 |
compositions: |
Master list of all Versioned Composition references in this EHR. |
||
0..1 |
directory: |
Optional directory structure for this EHR. If present, this is a reference to the first member of |
||
1..1 |
time_created: |
Time of creation of the EHR. |
||
0..1 |
folders: |
Optional additional Folder structures for this EHR. If set, the |
||
0..1 |
tags: |
Optional list of tags associated with this EHR. Tag |
||
Invariants |
Contributions_valid: |
|||
Ehr_access_valid: |
||||
Ehr_status_valid: |
||||
Compositions_valid: |
||||
Directory_valid: |
||||
Folders_valid: |
||||
Directory_in_folders: |
||||
| EHR | |||
|---|---|---|---|
The EHR object is the root object and access point of an EHR for a subject of care. |
|||
Attributes |
|||
system_id: |
The identifier of the logical EHR management system in which this EHR was created. |
||
ehr_id: |
The unique identifier of this EHR.
|
||
contributions: |
List of contributions causing changes to this EHR. Each contribution contains a list of versions, which may include references to any number of |
||
ehr_status: |
Reference to |
||
ehr_access: |
Reference to |
||
compositions: |
Master list of all Versioned Composition references in this EHR. |
||
directory: |
Optional directory structure for this EHR. If present, this is a reference to the first member of |
||
time_created: |
Time of creation of the EHR. |
||
folders: |
Optional additional Folder structures for this EHR. If set, the |
||
tags: |
Optional list of tags associated with this EHR. Tag |
||
Invariants |
|||
Contributions_valid: |
|||
Ehr_access_valid: |
|||
Ehr_status_valid: |
|||
Compositions_valid: |
|||
Directory_valid: |
|||
Folders_valid: |
|||
Directory_in_folders: |
|||
{
"name": "EHR",
"documentation": "The EHR object is the root object and access point of an EHR for a subject of care. ",
"properties": {
"system_id": {
"_type": "P_BMM_SINGLE_PROPERTY",
"name": "system_id",
"documentation": "The identifier of the logical EHR management system in which this EHR was created. \n",
"is_mandatory": true,
"type": "HIER_OBJECT_ID"
},
"ehr_id": {
"_type": "P_BMM_SINGLE_PROPERTY",
"name": "ehr_id",
"documentation": "The unique identifier of this EHR.\n\nNOTE: is is strongly recommended that a UUID always be used for this field.",
"is_mandatory": true,
"type": "HIER_OBJECT_ID"
},
"contributions": {
"_type": "P_BMM_CONTAINER_PROPERTY",
"name": "contributions",
"documentation": "List of contributions causing changes to this EHR. Each contribution contains a list of versions, which may include references to any number of `VERSION` instances, i.e. items of type `VERSIONED_COMPOSITION` and `VERSIONED_FOLDER`. ",
"type_def": {
"container_type": "List",
"type": "OBJECT_REF"
},
"cardinality": {
"lower": 0,
"upper_unbounded": true
}
},
"ehr_status": {
"_type": "P_BMM_SINGLE_PROPERTY",
"name": "ehr_status",
"documentation": "Reference to `EHR_STATUS` object for this EHR.",
"is_mandatory": true,
"type": "OBJECT_REF"
},
"ehr_access": {
"_type": "P_BMM_SINGLE_PROPERTY",
"name": "ehr_access",
"documentation": "Reference to `EHR_ACCESS` object for this EHR.",
"is_mandatory": true,
"type": "OBJECT_REF"
},
"compositions": {
"_type": "P_BMM_CONTAINER_PROPERTY",
"name": "compositions",
"documentation": "Master list of all Versioned Composition references in this EHR.",
"type_def": {
"container_type": "List",
"type": "OBJECT_REF"
},
"cardinality": {
"lower": 0,
"upper_unbounded": true
}
},
"directory": {
"_type": "P_BMM_SINGLE_PROPERTY",
"name": "directory",
"documentation": "Optional directory structure for this EHR. If present, this is a reference to the first member of `_folders_`.",
"type": "OBJECT_REF"
},
"time_created": {
"_type": "P_BMM_SINGLE_PROPERTY",
"name": "time_created",
"documentation": "Time of creation of the EHR.",
"is_mandatory": true,
"type": "DV_DATE_TIME"
},
"folders": {
"_type": "P_BMM_CONTAINER_PROPERTY",
"name": "folders",
"documentation": "Optional additional Folder structures for this EHR. If set, the `_directory_` attribute refers to the first member.",
"type_def": {
"container_type": "List",
"type": "OBJECT_REF"
},
"cardinality": {
"lower": 0,
"upper_unbounded": true
}
},
"tags": {
"_type": "P_BMM_CONTAINER_PROPERTY",
"name": "tags",
"documentation": "Optional list of tags associated with this EHR. Tag `_target_` values can only be within the same EHR.",
"type_def": {
"container_type": "List",
"type": "OBJECT_REF"
},
"cardinality": {
"lower": 0,
"upper_unbounded": true
}
}
},
"invariants": {
"Contributions_valid": "for_all c in contributions | c.type.is_equal(\"CONTRIBUTION\")",
"Ehr_access_valid": "ehr_access.type.is_equal (\"VERSIONED_EHR_ACCESS\")",
"Ehr_status_valid": "ehr_status.type.is_equal(\"VERSIONED_EHR_STATUS\")",
"Compositions_valid": "for_all c in compositions | c.type.is_equal (\"VERSIONED_COMPOSITION\")",
"Directory_valid": "directory /= Void implies directory.type.is_equal (\"VERSIONED_FOLDER\")",
"Folders_valid": "folders /= Void implies for_all f in folders | f.type.is_equal(\"VERSIONED_FOLDER\")",
"Directory_in_folders": "folders /= Void implies folders.item(1) = directory"
}
}VERSIONED_EHR_ACCESS Class
-
Definition
-
Effective
-
BMM
-
UML
Class |
VERSIONED_EHR_ACCESS |
|
|---|---|---|
Description |
Version container for |
|
Inherit |
||
| VERSIONED_EHR_ACCESS | |
|---|---|
Version container for |
|
Inherits: VERSIONED_OBJECT |
|
Attributes |
|
VERSIONED_OBJECT.uid: |
Unique identifier of this version container in the form of a UID with no extension. This id will be the same in all instances of the same container in a distributed environment, meaning that it can be understood as the uid of the virtual version tree. |
VERSIONED_OBJECT.owner_id: |
Reference to object to which this version container belongs, e.g. the id of the containing EHR or other relevant owning entity. |
VERSIONED_OBJECT.time_created: |
Time of initial creation of this versioned object. |
Functions |
|
VERSIONED_OBJECT.version_count (): |
Return the total number of versions in this object. |
VERSIONED_OBJECT.all_version_ids (): |
Return a list of ids of all versions in this object. |
VERSIONED_OBJECT.all_versions (): |
Return a list of all versions in this object. |
VERSIONED_OBJECT.has_version_at_time ( |
True if a version for time |
VERSIONED_OBJECT.has_version_id ( |
True if a version with |
VERSIONED_OBJECT.version_with_id ( |
Return the version with |
VERSIONED_OBJECT.is_original_version ( |
True if version with |
VERSIONED_OBJECT.version_at_time ( |
Return the version for time |
VERSIONED_OBJECT.revision_history (): |
History of all audits and attestations in this versioned repository. |
VERSIONED_OBJECT.latest_version (): |
Return the most recently added version (i.e. on trunk or any branch). |
VERSIONED_OBJECT.latest_trunk_version (): |
Return the most recently added trunk version. |
VERSIONED_OBJECT.trunk_lifecycle_state (): |
Return the lifecycle state from the latest trunk version. Useful for determining if the version container is logically deleted. |
VERSIONED_OBJECT.commit_original_version ( |
Add a new original version. |
VERSIONED_OBJECT.commit_original_merged_version ( |
Add a new original merged version. This commit function adds a parameter containing the ids of other versions merged into the current one. |
VERSIONED_OBJECT.commit_imported_version ( |
Add a new imported version. Details of version id etc come from the |
VERSIONED_OBJECT.commit_attestation ( |
Add a new attestation to a specified original version. Attestations can only be added to Original versions. |
Invariants |
|
VERSIONED_OBJECT.Version_count_valid: |
|
VERSIONED_OBJECT.All_version_ids_valid: |
|
VERSIONED_OBJECT.All_versions_valid: |
|
VERSIONED_OBJECT.Latest_version_valid: |
|
VERSIONED_OBJECT.Uid_validity: |
|
{
"name": "VERSIONED_EHR_ACCESS",
"documentation": "Version container for `EHR_ACCESS` instance.",
"ancestors": [
"VERSIONED_OBJECT"
]
}EHR_ACCESS Class
-
Definition
-
Effective
-
BMM
-
UML
Class |
EHR_ACCESS |
|||
|---|---|---|---|---|
Description |
EHR-wide access control object. All access decisions to data in the EHR must be made in accordance with the policies and rules in this object.
|
|||
Inherit |
||||
Attributes |
Signature |
Meaning |
||
0..1 |
settings: |
Access control settings for the EHR. Instance is a subtype of the type |
||
Functions |
Signature |
Meaning |
||
1..1 |
scheme (): |
The name of the access control scheme in use; corresponds to the concrete instance of the settings attribute. |
||
Invariants |
Scheme_valid: |
|||
Is_archetype_root: |
||||
| EHR_ACCESS | |||
|---|---|---|---|
EHR-wide access control object. All access decisions to data in the EHR must be made in accordance with the policies and rules in this object.
|
|||
Attributes |
|||
Runtime name of this fragment, used to build runtime paths. This is the term provided via a clinical application or batch process to name this EHR construct: its retention in the EHR faithfully preserves the original label by which this entry was known to end users. |
|||
Design-time archetype identifier of this node taken from its generating archetype; used to build archetype paths. Always in the form of an at-code, e.g. At an archetype root point, the value of this attribute is always the stringified form of the |
|||
LOCATABLE.uid: |
Optional globally unique object identifier for root points of archetyped structures. |
||
Links to other archetyped structures (data whose root object inherits from |
|||
LOCATABLE.archetype_details: |
Details of archetyping used on this node. |
||
LOCATABLE.feeder_audit: |
Audit trail from non-openEHR system of original commit of information forming the content of this node, or from a conversion gateway which has synthesised this node. |
||
settings: |
Access control settings for the EHR. Instance is a subtype of the type |
||
Functions |
|||
Value equality: return True if Parameters
|
|||
Reference equality for reference types, value equality for value types. Parameters
|
|||
Create new instance of a type. |
|||
Type name of an object as a string. May include generic parameters, as in |
|||
Any.not_equal alias "!=", "≠" ( |
True if current object not equal to |
||
Parent of this node in a compositional hierarchy. |
|||
PATHABLE.item_at_path ( |
The item at a path (relative to this item); only valid for unique paths, i.e. paths that resolve to a single item. |
||
PATHABLE.items_at_path ( |
List of items corresponding to a non-unique path. |
||
PATHABLE.path_exists ( |
True if the path exists in the data with respect to the current item. |
||
PATHABLE.path_unique ( |
True if the path corresponds to a single item in the data. |
||
The path to an item relative to the root of this archetyped structure. |
|||
Clinical concept of the archetype as a whole (= derived from the archetype_node_id' of the root node) |
|||
True if this node is the root of an archetyped structure. |
|||
scheme (): |
The name of the access control scheme in use; corresponds to the concrete instance of the settings attribute. |
||
Invariants |
|||
LOCATABLE.Links_valid: |
|||
LOCATABLE.Archetyped_valid: |
|||
LOCATABLE.Archetype_node_id_valid: |
|||
Scheme_valid: |
|||
Is_archetype_root: |
|||
{
"name": "EHR_ACCESS",
"documentation": "EHR-wide access control object. All access decisions to data in the EHR must be made in accordance with the policies and rules in this object.\n\nNOTE: It is strongly recommended that the inherited attribute `_uid_` be populated in `EHR_ACCESS` objects, using the UID copied from the `_object_id()_` of the `_uid_` field of the enclosing `VERSION` object. +\nFor example, the `ORIGINAL_VERSION.uid` `87284370-2D4B-4e3d-A3F3-F303D2F4F34B::uk.nhs.ehr1::2` would be copied to the `_uid_` field of the `EHR_ACCESS` object.",
"ancestors": [
"LOCATABLE"
],
"properties": {
"settings": {
"_type": "P_BMM_SINGLE_PROPERTY",
"name": "settings",
"documentation": "Access control settings for the EHR. Instance is a subtype of the type `ACCESS_CONTROL_SETTINGS`, allowing for the use of different access control schemes. ",
"type": "ACCESS_CONTROL_SETTINGS"
}
},
"functions": {
"scheme": {
"name": "scheme",
"documentation": "The name of the access control scheme in use; corresponds to the concrete instance of the settings attribute. ",
"result": {
"_type": "P_BMM_SIMPLE_TYPE",
"type": "String"
}
}
},
"invariants": {
"Scheme_valid": "not scheme.is_empty",
"Is_archetype_root": "is_archetype_root"
}
}ACCESS_CONTROL_SETTINGS Class
-
Definition
-
Effective
-
BMM
-
UML
Class |
ACCESS_CONTROL_SETTINGS (abstract) |
|
|---|---|---|
Description |
Access Control Settings for the EHR and components. Intended to support multiple access control schemes. Currently implementation dependent. |
|
| ACCESS_CONTROL_SETTINGS (abstract) | |
|---|---|
Access Control Settings for the EHR and components. Intended to support multiple access control schemes. Currently implementation dependent. |
{
"name": "ACCESS_CONTROL_SETTINGS",
"documentation": "Access Control Settings for the EHR and components. Intended to support multiple access control schemes. Currently implementation dependent.",
"is_abstract": true
}VERSIONED_EHR_STATUS Class
-
Definition
-
Effective
-
BMM
-
UML
Class |
VERSIONED_EHR_STATUS |
|
|---|---|---|
Description |
Version container for |
|
Inherit |
||
| VERSIONED_EHR_STATUS | |
|---|---|
Version container for |
|
Inherits: VERSIONED_OBJECT |
|
Attributes |
|
VERSIONED_OBJECT.uid: |
Unique identifier of this version container in the form of a UID with no extension. This id will be the same in all instances of the same container in a distributed environment, meaning that it can be understood as the uid of the virtual version tree. |
VERSIONED_OBJECT.owner_id: |
Reference to object to which this version container belongs, e.g. the id of the containing EHR or other relevant owning entity. |
VERSIONED_OBJECT.time_created: |
Time of initial creation of this versioned object. |
Functions |
|
VERSIONED_OBJECT.version_count (): |
Return the total number of versions in this object. |
VERSIONED_OBJECT.all_version_ids (): |
Return a list of ids of all versions in this object. |
VERSIONED_OBJECT.all_versions (): |
Return a list of all versions in this object. |
VERSIONED_OBJECT.has_version_at_time ( |
True if a version for time |
VERSIONED_OBJECT.has_version_id ( |
True if a version with |
VERSIONED_OBJECT.version_with_id ( |
Return the version with |
VERSIONED_OBJECT.is_original_version ( |
True if version with |
VERSIONED_OBJECT.version_at_time ( |
Return the version for time |
VERSIONED_OBJECT.revision_history (): |
History of all audits and attestations in this versioned repository. |
VERSIONED_OBJECT.latest_version (): |
Return the most recently added version (i.e. on trunk or any branch). |
VERSIONED_OBJECT.latest_trunk_version (): |
Return the most recently added trunk version. |
VERSIONED_OBJECT.trunk_lifecycle_state (): |
Return the lifecycle state from the latest trunk version. Useful for determining if the version container is logically deleted. |
VERSIONED_OBJECT.commit_original_version ( |
Add a new original version. |
VERSIONED_OBJECT.commit_original_merged_version ( |
Add a new original merged version. This commit function adds a parameter containing the ids of other versions merged into the current one. |
VERSIONED_OBJECT.commit_imported_version ( |
Add a new imported version. Details of version id etc come from the |
VERSIONED_OBJECT.commit_attestation ( |
Add a new attestation to a specified original version. Attestations can only be added to Original versions. |
Invariants |
|
VERSIONED_OBJECT.Version_count_valid: |
|
VERSIONED_OBJECT.All_version_ids_valid: |
|
VERSIONED_OBJECT.All_versions_valid: |
|
VERSIONED_OBJECT.Latest_version_valid: |
|
VERSIONED_OBJECT.Uid_validity: |
|
{
"name": "VERSIONED_EHR_STATUS",
"documentation": "Version container for `EHR_STATUS` instance.",
"ancestors": [
"VERSIONED_OBJECT"
]
}EHR_STATUS Class
-
Definition
-
Effective
-
BMM
-
UML
Class |
EHR_STATUS |
|||
|---|---|---|---|---|
Description |
Single object per EHR containing various EHR-wide status flags and settings, including whether this EHR can be queried, modified etc. This object is always modifiable, in order to change the status of the EHR as a whole.
|
|||
Inherit |
||||
Attributes |
Signature |
Meaning |
||
1..1 |
subject: |
The subject of this EHR. The |
||
1..1 |
is_queryable: |
True if this EHR should be included in population queries, i.e. if this EHR is considered active in the population. |
||
1..1 |
is_modifiable: |
True if the EHR, other than the |
||
0..1 |
other_details: |
Any other details of the EHR summary object, in the form of an archetyped |
||
Invariants |
Is_archetype_root: |
|||
| EHR_STATUS | |||
|---|---|---|---|
Single object per EHR containing various EHR-wide status flags and settings, including whether this EHR can be queried, modified etc. This object is always modifiable, in order to change the status of the EHR as a whole.
|
|||
Attributes |
|||
Runtime name of this fragment, used to build runtime paths. This is the term provided via a clinical application or batch process to name this EHR construct: its retention in the EHR faithfully preserves the original label by which this entry was known to end users. |
|||
Design-time archetype identifier of this node taken from its generating archetype; used to build archetype paths. Always in the form of an at-code, e.g. At an archetype root point, the value of this attribute is always the stringified form of the |
|||
LOCATABLE.uid: |
Optional globally unique object identifier for root points of archetyped structures. |
||
Links to other archetyped structures (data whose root object inherits from |
|||
LOCATABLE.archetype_details: |
Details of archetyping used on this node. |
||
LOCATABLE.feeder_audit: |
Audit trail from non-openEHR system of original commit of information forming the content of this node, or from a conversion gateway which has synthesised this node. |
||
subject: |
The subject of this EHR. The |
||
is_queryable: |
True if this EHR should be included in population queries, i.e. if this EHR is considered active in the population. |
||
is_modifiable: |
True if the EHR, other than the |
||
other_details: |
Any other details of the EHR summary object, in the form of an archetyped |
||
Functions |
|||
Value equality: return True if Parameters
|
|||
Reference equality for reference types, value equality for value types. Parameters
|
|||
Create new instance of a type. |
|||
Type name of an object as a string. May include generic parameters, as in |
|||
Any.not_equal alias "!=", "≠" ( |
True if current object not equal to |
||
Parent of this node in a compositional hierarchy. |
|||
PATHABLE.item_at_path ( |
The item at a path (relative to this item); only valid for unique paths, i.e. paths that resolve to a single item. |
||
PATHABLE.items_at_path ( |
List of items corresponding to a non-unique path. |
||
PATHABLE.path_exists ( |
True if the path exists in the data with respect to the current item. |
||
PATHABLE.path_unique ( |
True if the path corresponds to a single item in the data. |
||
The path to an item relative to the root of this archetyped structure. |
|||
Clinical concept of the archetype as a whole (= derived from the archetype_node_id' of the root node) |
|||
True if this node is the root of an archetyped structure. |
|||
Invariants |
|||
LOCATABLE.Links_valid: |
|||
LOCATABLE.Archetyped_valid: |
|||
LOCATABLE.Archetype_node_id_valid: |
|||
Is_archetype_root: |
|||
{
"name": "EHR_STATUS",
"documentation": "Single object per EHR containing various EHR-wide status flags and settings, including whether this EHR can be queried, modified etc. This object is always modifiable, in order to change the status of the EHR as a whole.\n\nNOTE: It is strongly recommended that the inherited attribute `_uid_` be populated in `EHR_STATUS` objects, using the UID copied from the `_object_id()_` of the `_uid_` field of the enclosing `VERSION` object. +\nFor example, the `ORIGINAL_VERSION.uid` `87284370-2D4B-4e3d-A3F3-F303D2F4F34B::uk.nhs.ehr1::2` would be copied to the `_uid_` field of the `EHR_STATUS` object.",
"ancestors": [
"LOCATABLE"
],
"properties": {
"subject": {
"_type": "P_BMM_SINGLE_PROPERTY",
"name": "subject",
"documentation": "The subject of this EHR. The `_external_ref_` attribute can be used to contain a direct reference to the subject in a demographic or identity service. Alternatively, the association between patients and their records may be done elsewhere for security reasons. ",
"is_mandatory": true,
"type": "PARTY_SELF"
},
"is_queryable": {
"_type": "P_BMM_SINGLE_PROPERTY",
"name": "is_queryable",
"documentation": "True if this EHR should be included in population queries, i.e. if this EHR is considered active in the population.",
"is_mandatory": true,
"type": "Boolean"
},
"is_modifiable": {
"_type": "P_BMM_SINGLE_PROPERTY",
"name": "is_modifiable",
"documentation": "True if the EHR, other than the `EHR_STATUS` object, is allowed to be written to. The `EHR_STATUS` object itself can always be written to.",
"is_mandatory": true,
"type": "Boolean"
},
"other_details": {
"_type": "P_BMM_SINGLE_PROPERTY",
"name": "other_details",
"documentation": "Any other details of the EHR summary object, in the form of an archetyped `ITEM_STRUCTURE`.",
"type": "ITEM_STRUCTURE"
}
},
"invariants": {
"Is_archetype_root": "is_archetype_root"
}
}VERSIONED_COMPOSITION Class
-
Definition
-
Effective
-
BMM
-
UML
Class |
VERSIONED_COMPOSITION |
|
|---|---|---|
Description |
Version-controlled composition abstraction, defined by inheriting |
|
Inherit |
||
Functions |
Signature |
Meaning |
1..1 |
is_persistent (): |
Indicates whether this composition set is persistent; derived from first version. |
Invariants |
Archetype_node_id_valid: |
|
Persistent_validity: |
||
| VERSIONED_COMPOSITION | |
|---|---|
Version-controlled composition abstraction, defined by inheriting |
|
Inherits: VERSIONED_OBJECT |
|
Attributes |
|
VERSIONED_OBJECT.uid: |
Unique identifier of this version container in the form of a UID with no extension. This id will be the same in all instances of the same container in a distributed environment, meaning that it can be understood as the uid of the virtual version tree. |
VERSIONED_OBJECT.owner_id: |
Reference to object to which this version container belongs, e.g. the id of the containing EHR or other relevant owning entity. |
VERSIONED_OBJECT.time_created: |
Time of initial creation of this versioned object. |
Functions |
|
VERSIONED_OBJECT.version_count (): |
Return the total number of versions in this object. |
VERSIONED_OBJECT.all_version_ids (): |
Return a list of ids of all versions in this object. |
VERSIONED_OBJECT.all_versions (): |
Return a list of all versions in this object. |
VERSIONED_OBJECT.has_version_at_time ( |
True if a version for time |
VERSIONED_OBJECT.has_version_id ( |
True if a version with |
VERSIONED_OBJECT.version_with_id ( |
Return the version with |
VERSIONED_OBJECT.is_original_version ( |
True if version with |
VERSIONED_OBJECT.version_at_time ( |
Return the version for time |
VERSIONED_OBJECT.revision_history (): |
History of all audits and attestations in this versioned repository. |
VERSIONED_OBJECT.latest_version (): |
Return the most recently added version (i.e. on trunk or any branch). |
VERSIONED_OBJECT.latest_trunk_version (): |
Return the most recently added trunk version. |
VERSIONED_OBJECT.trunk_lifecycle_state (): |
Return the lifecycle state from the latest trunk version. Useful for determining if the version container is logically deleted. |
VERSIONED_OBJECT.commit_original_version ( |
Add a new original version. |
VERSIONED_OBJECT.commit_original_merged_version ( |
Add a new original merged version. This commit function adds a parameter containing the ids of other versions merged into the current one. |
VERSIONED_OBJECT.commit_imported_version ( |
Add a new imported version. Details of version id etc come from the |
VERSIONED_OBJECT.commit_attestation ( |
Add a new attestation to a specified original version. Attestations can only be added to Original versions. |
is_persistent (): |
Indicates whether this composition set is persistent; derived from first version. |
Invariants |
|
VERSIONED_OBJECT.Version_count_valid: |
|
VERSIONED_OBJECT.All_version_ids_valid: |
|
VERSIONED_OBJECT.All_versions_valid: |
|
VERSIONED_OBJECT.Latest_version_valid: |
|
VERSIONED_OBJECT.Uid_validity: |
|
Archetype_node_id_valid: |
|
Persistent_validity: |
|
{
"name": "VERSIONED_COMPOSITION",
"documentation": "Version-controlled composition abstraction, defined by inheriting `VERSIONED_OBJECT<COMPOSITION>`. ",
"ancestors": [
"VERSIONED_OBJECT"
],
"functions": {
"is_persistent": {
"name": "is_persistent",
"documentation": "Indicates whether this composition set is persistent; derived from first version.",
"result": {
"_type": "P_BMM_SIMPLE_TYPE",
"type": "Boolean"
}
}
},
"invariants": {
"Archetype_node_id_valid": "for_all v in all_versions | v.archetype_node_id.is_equal (all_versions.first.archetype_node_id)",
"Persistent_validity": "for_all v in all_versions | v.is_persistent = all_versions.first.data.is_persistent"
}
}References
-
[1] J. Gray and A. Reuter, Transaction Processing Concepts and Techniques. Morgan Kaufmann, 1993.
-
[2] D. Lloyd, “Deliverable 4: GEHR Requirements for Clinical Comprehensiveness,” European Commission AIM, Brussels, techreport, 1992. [Online]. Available: https://www.openehr.org/resources/related_projects/gehr_deliverable-4.pdf
-
[3] D. Lloyd, “Deliverable 7: Clinical Functional Specifications,” European Commission AIM, Brussels, techreport, 1993.
-
[4] S. Heard, D. Kalra, and D. Ingram, “Deliverable 8: Ethical and legal Requirements of GEHR Architecture and Systems,” European Commission AIM, Brussels, techreport, 1994. [Online]. Available: https://www.openehr.org/resources/related_projects/gehr_deliverable-8.pdf
-
[5] T. Beale, D. Lloyd, S. Heard, D. Kalra, and D. Ingram, “Deliverable 19,20,24: GEHR Architecture,” European Commission AIM, Brussels, techreport, 1995. [Online]. Available: https://www.openehr.org/resources/related_projects/gehr_deliverable-19_20_24.pdf
-
[6] R. Arp, B. Smith, and A. D. Spear, Building Ontologies with Basic Formal Ontology. The MIT Press, 2015. [Online]. Available: https://mitpress.mit.edu/books/building-ontologies-basic-formal-ontology
-
[7] J. F. Sowa, Knowledge Representation: Logical, philosophical and Computational Foundations. California: Brooks/Cole, 2000.