oship-dev team mailing list archive

[Otavio Silva <otavio_uff104@xxxxxxxxxxxx>]

   Hi!
   I was reading the document "overview.pdf" and, as I am not an IT professional, I have some doubts with the following terms. If anyone could help me...

* UML

* "semi-automated and automated distributed workflows"

as in:
Shared Care EHR
The following requirements addressed in openEHR correspond to an integrated shared care EHR:• support semi-automated and automated distributed workflows.

* "legacy data purification and validation gateways"

as in:
Overall, a number of important categories of system can be implemented using openEHR
including the following:
legacy data purification and validation gateways;

* "runtime data"

as in:
With the use of two-level modelling, runtime data now conform semantically to archetypes
as well as concretely to the reference model. All archetypes are expressed in a generic Archetype
Definition Language (ADL).

* "caching"

as in:

Under the two-level paradigm, the core part of the system is
based on the reference and archetype models (includes generic logic for storage, querying, caching
etc.), both of which are extremely stable, while domain semantics are mostly delegated to domain
specialists who work building archetypes (reusable), templates (local use) and terminology (general
use).

* "model containing many classes" - model, object, class in Object Oriented 

* "granularity", "fine-grained" / "coarse-grained" 

* "namespaces"

as in:
All packages defining detailed models appear inside one of these outer packages, which may also be thought of as namespaces. They are conceptually defined within the org.openehr namespace, which can be represented in UML as further packages. In some implementation technologies (e.g. Java), the org.openehr namespace may actually be used within program texts


* "Dependencies"

as in:
One of the important design aims of openEHR is to provide a coherent, consistent and re-usable type
system for scientific and health computing. Accordingly, the ‘core’ of the RM (bottom-most layers)
provides identifiers, data types, data structures and various common design patterns that can be reused ubiquitously in the upper layers of the RM, and equally in the AM and SM packages. FIGURE 9 illustrates the relationships between the packages. Dependencies only exist from higher packages to lower packages.

* "type system"

as in:
The support package includes the special package assumed_types, describing what basic types are assumed by openEHR in external type systems; this package is a guide for integrating openEHR models proper into the type systems of implementation technologies.

* freeform legacy data

as in:
The Integration model defines the class GENERIC_ENTRY, a subtype of ENTRY used to represent freeform legacy or external data as a tree. This Entry type has its own archetypes, known as “integration archetypes”, which can be used in concert with clinical archetypes as the basis for a tool-based data integration system. See section 14 on page 79 for more details.

* front-end, back-end and  Non-repudiation

as in:
Other security policy principles that should be implemented in even a minimal EHR deployment but
are not directly specified by openEHR include the following.
Non-repudiation: if digital signing of changes to the record is made mandatory, non-repudiation
of content can be supported by an openEHR system. The digital signing of communications
(EHR Extracts) is also supported in openEHR; coupled with logging of communication of
Extracts, this can be used to guarantee non-repudiation of information passed between
systems (cf. information passed between back-end and front-end applications of the same
system).


* hard information

as in:
In terms of actual content, the Entry classes are the most important in theopen
the record. They are intended to be archetyped, and in fact, archetypes for Entries and sub-parts of
Entries make up the vast majority of archetypes defined for the EHR.EHR EHR Information Model, since they define the semantics of all the ‘hard’ information in

* hashes

as in:
FIGURE 21 illustrates the main security measures directly specified by the openEHR architecture.
These include EHR/demographic separation and an EHR-wide access control object. At the level of
versioned objects, commit audits (mandatory), digital signatures and hashes are available. The following subsections describe these features in more detail.

* inferencing attacks

as in:
A key feature of the policy is that it must scale to distributed environments in which health record
information is maintained at multiple provider sites visited by the patient.
As Anderson points out in the BMA study, policy elements are also needed for guarding against users
gaining access to massive numbers of EHRs, and inferencing attacks. Currently these are outside the
scope of openEHR, and realistically, of most EHR implementations of any kind today.


* "hash (e.g. MD5) of a canonical representation" and "digest strings"

as in:
Digital Signature
The possibility exists within an openEHR EHR to digitally sign each Version in a Versioned object
(i.e. for each Version of any logical item, such as medications list, encounter note etc.). The signature
is created as a private-key encryption (e.g. RSA-1) of a hash (e.g. MD5) of a canonical representation (such as in schema-based XML) of the Version being committed. A likely candidate for defining the signature and digest strings in openEHR is the openPGP message format (IETF RFC24401), due to being an open specification and self-describing. The use of RFC2440 for the format does not imply the use of the PGP distributed certificate infrastructure, or indeed any certification infrastructure; openEHR is agnostic on this point. If no public key or equivalent infrastructure is available, the encryption step might be omitted, resulting in a digest only of the content. The signature is stored within the Version object, allowing it to be conveniently carried within EHR Extracts. 

* versioned persistence layer 

as in:
The signing of data in a versioning system acts as an integrity check (the digest performs this function),
an authentication measure (the signature performs this function), and also a non-repudiation
measure. To guard against hacking of the versioned persistence layer itself, signatures can be forwarded to a trusted notarisation service. A fully secure system based on digital signing also requires
certified public keys, which may or may not be available in any given environment.
One of the benefits of digitally signing relatively small pieces of the EHR (single Versions) rather
than the whole EHR or large sections of it is that the integrity of items is more immune to localised
repository corruptions.


* instances

* rollback

as in:
Versioning of single top-level structures is a necessary, but not sufficient requirement for a repository
that must provide coherence, traceability, indelibility, rollback, and support for forensic examination
of past states of the data. Features supporting “change control” are also required. Under a disciplined
change control scheme, changes are not made arbitrarily to single top-level structures, but to the
repository itself. Changes take the form of change-sets, called “Contributions”, that consist of new or
changed versions of the controlled items in the repository. The key feature of a change-set is that it
acts like a transaction, and takes the repository from one consistent state to another, whereas arbitrary combinations of changes to single controlled items could easily be inconsistent, and even dangerously wrong where clinical data are concerned.
 
* "it acts like a transaction, and takes the repository from one consistent state to another, whereas arbitrary combinations of changes to single controlled items could easily be inconsistent, and even dangerously"


* cardinalities

as in:
The actual type of links between the controlled repository and the other entities might vary - in some
cases it might be association, in others aggregation; cardinalities might also vary. FIGURE 27 therefore provides a guide to the definition of actual controlled repositories, such as an EHR, rather than a formal specification for them.

* proxy

* asynchronous synchronisation

as in:
8.4 The “Virtual Version Tree”
An underlying design concept of the versioning model defined in openEHR is known as a “virtual
version tree”. The idea is simple in the abstract. Information is committed to a repository (such as an
EHR) in lumps, each lump being the “data” of one Version. Each Version has its place within a version tree, which in turn is maintained inside a Versioned object (or “version container”). The virtual
version tree concept means that any given Versioned object may have numerous copies in various
systems, and that the creation of versions in each is done in such a way that all versions so created are
in fact compatible with the “virtual” version tree resulting from the superimposition of the version
trees of all copies. This is achieved using simple rules for version identification and is done to facilitate
data sharing. Two very common scenarios are served by the virtual version tree concept:
• longitudinal data that stands as a proxy for the state or situation of the patient such as “Medications”
or “Problem list” (persistent Compositions in openEHR) is created and maintained
in one or more care delivery organisations, and shared across a larger number of organisations;
• some EHRs in an EHR server in one location are mirrored into one or more other EHR servers
(e.g. at care providers where the relevant patients are also treated); the mirroring process
requires asynchronous synchronisation between servers to work seamlessly, regardless of
the location, time, or author of any data created.

* "reverse internet identifier"

as in:
Versions of top-level structures are identified in a way that is guaranteed to work even in distributed
environments where copying, merging and subsequent modification occur. The full identification of a
version of a top-level structure is the globally unique tuple consisting of the uid of the owningVERSIONED_OBJECT, and the two VERSION attributes version_tree_id and creating_system_id. The version_tree_id is a 1 or 3-part number string, such as “1” or for a branch, “1.2.1”. The creating_system_id attribute carries a unique identifier for the system where the content was first created; this may be a GUID, Oid or reverse internet identifier. A typical version identification tuple is as follows:

* scheme-space

as in:
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 in the 

* object modelLOCATABLE_REF class in the change_control package section of the Common IM. A Universal Resource Identifier (URI) form can also be used, defined by the data type DV_EHR_URI (Data types IM). This type provides a single string expression in the scheme-space “ehr://” which can be used to refer to an interior data node from anywhere 

as in:
Under the two-level modelling approach, the formal definition of information structuring occurs at
two levels. The lower level is that of the reference model, a stable object model from which software
and data can be built. Concepts in the 
Composition, Section, Observation, and various data types such as Quantity and Coded text. The
upper level consists of domain-level definitions in the form of 
defined at this level include things such as “blood pressure measurement”, “SOAP headings”, and
“HbA1c Result”.openEHR reference model are invariant, and include things likearchetypes and templates. Concepts

* serialised form / abstract serialisation

as in:
In serialised form, archetypes can be represented in various ways. The normative, abstract serialisation
in 
Frame Logic queries (also known as F-logic [5]) with the addition of terminology. An ADL archetype
is a guaranteed 100% lossless rendering of the semantics of any archetype, and is designed to be a
syntactic analogue of the AOM. Nevertheless, other lossless and lossy serialisations are possible and
some already exist. For practical purposes, XML-based serialisations are used in some situations. A
serialisation purely expressed in dADL, the ADL object serialisation syntax will be available in the
future. Various HTML, RTF and other formats are used for screen rendering and human review.openEHR is Archetype Definition Language (ADL). This is an abstract language based on
* keystrokes

as in:
Validation is the primary runtime function of archetypes - it is how “archetype-based” data are created in the first place, and modified thereafter. Archetype-based validation can be used in a GUI
application or in a data import service. Although the source of the data (keystrokes or received XML
or other messages) is different, the logical process is the same: create archetype-based openEHR data according to the input stream.
* "atomic internal codes"

as in:
Bindings can also be made between atomic internal codes and external codes, in which case the
meaning is that the mapping always holds, no matter how many times the internal code is used within
the archetype.

* middleware

as in:
13.1 5-tier System Architecture
3. virtual EHR: this tier is the middleware, and consists of a coherent set of APIs to the various
back-end services providing access to the relevant services, thereby allowing user
access to the EHR; including EHR, demographics, security, terminology, and archetype
services. It also contains an archetype- and template-enabled kernel, the component responsible
for creating and processing archetype-enabled data. In this tier, the separation of backend
services is hidden, only the functionality is exposed. Other virtual clients are possible,
consisting of APIs for other combinations of back-end services.

* sinks

as in:
Getting data in and out of the EHR is one of the most basic requirements 
“greenfield” (new build) situations, and for data being created by GUI applications via the 
EHR APIs, there is no issue, since native openEHR aims to satisfy. InopenEHRopenEHR structures and semantics are being used. In almost all other situations, existing data sources and sinks have to be accounted for. In general, external or ‘legacy’ data (here the term is used for convenience, and does not imply anything about the age or quality of the systems in question) have different syntactic and semantic formats than openEHR data, and seamless conversion requires addressing both levels.

* relational databases

* flatter structures

as in:
In technical terms, a number of types of incompatibility have to be dealt with. There is no guarantee
of correspondence of scope of incoming transactions and target 
document for example might correspond to a number of clinical archetypes. Structure will not usually
correspond, with legacy data (particularly messages) usually having flatter structures than those
defined in target archetypes. Terminology use is extremely variable in existing systems and messages,
and also has to be dealt with. Data types will also not correspond directly, so that for example, a mapping between an incoming string “110/80 mmHg” and the target openEHR structures - an incomingopenEHR form of twoDV_QUANTITY objects each with their own value and units has to be made.

* "'full-strength' semantics", "covariant and contravariant" and "inbuilt"

as in:

ITSs are created by the application of transformation rules from the “full-strength” semantics of the
abstract models to equivalents in a particular technology. Transformation rules usually include mappings
of:• names of classes and attributes;• property and function signature mapping;• mapping of basic types e.g. strings, numerics;• how to handle multiple inheritance;• how to handle generic (template) types;• how to handle covariant and contravariant redefinition semantics;• 
to stored attributes (the choice of mapping properties with signature xxxx:T (i.e. properties with no arguments)xxxx:T) or functions (xxxx():T);• how to express pre-conditions, post-conditions and class invariants;• 
 
Thanks a lot!
Otaviomappings between assumed types such as List<>, Set<> and inbuilt types.


      ____________________________________________________________________________________
Veja quais são os assuntos do momento no Yahoo! +Buscados
http://br.maisbuscados.yahoo.com