What is it.
Archetypes get on a fixed path as datavalue in an element a string containing a Post-Coordinated SCT expression. This expression represents the content of an archetype in SCT way. So, it will not contain the semantic rich structures. It does not contain data, because archetypes do not contain data. It contains locations where data can occur. So it is not a completed post-coordinated expression.
To have a connection with the archetype the post-coordinated expression needs archetype-node-value's, My proposal is to do it like this "272741003 | laterality | id123 |", or leaving the optional description out: " 272741003 || id123 |". So the post-coordinated expression parser knows that the data will occur in data-cell "id123". There are several kind of data possible, simple values like Integers, dates or strings, but also SCT concepts, or even other postcoordinated expressions can be a datavalue. At the moment of data-entry, the post-coordinated expression parser will add the datavalues to the expression, which becomes completed then. At the moment of this completion, the archetype-node-id's as also expression parts pointing to empty value parts can be removed.
So in the stored data, the post coordinated expression is a completed valid SCT post coordinated expression, which can be used in expression-contraint-tests.
There are two situations, already existing archetypes which need to be SCT enabled, and new archetypes.
- The already existing archetypes need a manually (with software support for consistent hierarchy use) created post-coordinated expression added.
- Newly created archetypes can be treated as already existing archetypes, but they give a special opportunity while creating them. A new archetype editor, based on SNOMED terms, sophisticated software, can help creating post-coordinated expressions. From this expressions archetypes can be generated, but only archetypes of the GenericEntry type. This will be rather flat, but fully OpenEHR compliant archetypes, which enable the full SCT potential and the full OpenEHR potential.
it can result in a new kind of medical information presentation which allows all the functionality of SCT ( expression-contraint-query, languages, refsets, hierarchies, inferred attributes, etc) and the functionality of OpenEHR (templates, other terminology systems connected, archetype-slots, meta-information, intellectual property, etc).
( http://snomed.org/compgrammar.pdf )
( http://snomed.org/expressionconstraint )
Requirements
Specification
There are only two extensions on the specification-side. These extensions do not stand in the way of the current use of OpenEHR. So for the countries or organizations which cannot use, or don't want to use this, nothing changes. They can use SCT enabled archetypes and ignore the SCT part. They even can use for SCT generated archetypes and ignore the SCT part.
- One extension in specification is to enable AQL to adapt expression constraints. See example.
- The other extension is to designate a fixed path where the post-coordinated expression will always be.
Implementation
On the implementation side there are software additions needed to use the SCT part. It is hardly necessary to change existing software.
The software architecture for SCT is separated from the current software architecture. The current architecture will need to call the SCT-modules. That is the only change.
There are SCT modules needed for
- Validation of the post-coordinated expression in the dialect-syntax used in archetypes. This needs to be called from the archetype-validation software, when there is a post-coordinated expression in it.
- Completion of post-coordinated expression at data entry. The data which are entered in a data-set are needed to complete the post-coordinated expression when this is available in the archetype.
- A query-engine for Expression-constraints is needed to do the actual SCT querying. This will be called from the AQL engine IF there is an expression part in the AQL statement, and if there is a post-coordinated expression in the data-set.
(Note that running an expression constraint query is additional, when this is not used, there is no performance loss on AQL. For optimization reason, in the beginning, f.e. in prototype, the best is to call this module as last. When a dataset comes through all WHERE-tests in AQL, it should be tested for SCT-condition. In this way, the expression-constraint, which runs un-optimized, does not need to test many post-coordinated string, and the expression contraint engine can have some optimizations too, but will on performance not be able to compete with indexed AQL statements.)
Syntax Design
In ADL:
We need to enrich the compositional grammar with archetype node Id's. This is needed at the moment of creating a dataset when the postcoordination expression will be completed with data-values. A post-coordination can have two parts. One part is the conceptId, and the second part is optional, can be a description for readability of the expression. When used in an archetype there is also need of a third part which is not optional but required, containing the archetypeNodeId. So the expression will then look like this: 272741003 | laterality | id123 | =7771000 | left | id456 | or when omitting the optional description: 272741003 || id123 | =7771000 || id456 |
In AQL:
There is a predefined or predictable path to the completed post-coordinated expression, representing the archetype and the data and the expression-constraint needs to be called by the AQL engine.
Examples
An example:
SELECT
e/ehr_status/subject/external_ref/id/value, diagnosis/data/items[at0002.1]/value
FROM
EHR e
CONTAINS Composition c[openEHR-EHR-COMPOSITION.problem_list.v1]
CONTAINS Evaluation diagnosis[openEHR-EHR-EVALUATION.problem-diagnosis.v1]
WHERE
c/name/value='Current Problems'
AND diagnosis/......path_to_postcoordinated_expression...../value/value matches { terminology://Snomed-CT/expressionConstraint?"<19829001:116676008=<<79654002"}