This is typical use case of assertions in the invariants(ADL
1.4)/rules(ADL 2), although I think none of the existing editors
support their definition. We are working in the addition of assertion
support to archetype edition in LinkEHR as it will be a direct
outcome from an ongoing project. We expect to have some results by
mid-year.
2015-01-14 10:31 GMT+01:00 Kavanagh Richard (HEALTH AND SOCIAL CARE
INFORMATION CENTRE) <richard.kavanagh@hscic.gov.uk>:
Are you able to flesh out the use-case a little more?
As Diego has said, cross element constraint is supported by the ADL
spec but not by any of the editing tools at the moment.
This is not really my field but I think part of the problem is coming
up with a rules formalism that can be interpreted by downstream
systems
In practice I have found that most of the cross-element constraint
rules issues are actually required at template level and are
cross-archetype ( The classic BMI calculation). This is an area where
GDL (http://www.openehr.org/downloads/ds_and_guidelines) is seen as
the best solution by most implementers. I am not too familiar with GDL
but it might well be possible to use GDL for your purpose
Ian
Dr Ian McNicoll
mobile +44 (0)775 209 7859
office +44 (0)1536 414994
skype: ianmcnicoll
email: ian@freshehr.com
twitter: @ianmcnicoll
Director, freshEHR Clinical Informatics
Director, openEHR Foundation
Director, HANDIHealth CIC
Hon. Senior Research Associate, CHIME, UCL
We are attempting to create an archetype to represent an existing information structure that we use within our Child Screening messages, for BloodSpot results.
Consider the following table (abbreviated).
We have a “Status Code” which can take on values of “01”-“09”
We then have a “Subcode” which depending on the “Status Code” is either not required, or has a specified set of values it can take on.
This only represents one of the “tests” from a collection of 9 possible tests that are part of the English BloodSpot
Status code | Suggested term used in child health system | Subcode | Description | ID | FSN |
| - | - | - | - | - |
01 | Specimen received in laboratory | N/A | Same value applies to all screening tests (ie relates to the blood spot card)
Additional data items to be provided with this status code and entered into Child Health systems. electronically or by manual means:
• Date sample taken • Date sample received in laboratory • Laboratory identifier | 509581000000105 | Newborn blood spot specimen received (finding) |
02 | (condition screened for) declined | N/A | | 947891000000100 | Glutaric aciduria type 1 screening declined (situation) |
0201 | Declined, no history of being screened | 951861000000101 | Glutaric aciduria type 1 screening declined, no history of being screened (situation) |
0202 | Declined, screened in UK (as reported by parents) with no evidence of result | 951881000000105 | Glutaric aciduria type 1 screening declined, screened in United Kingdom (as reported by parents) with no evidence of result (situation) |
0203 | Declined, screened outside UK with evidence of result | 951901000000108 | Glutaric aciduria type 1 screening declined, screened outside United Kingdom with evidence of result (situation) |
0204 | Declined, screened outside UK with no evidence of result | 951921000000104 | Glutaric aciduria type 1 screening declined, screened outside United Kingdom with no evidence of result (situation) |
03 | (Condition screened for) Repeat/Further sample required | | | 951941000000106 | Glutaric aciduria type 1 screening, repeat screening with further sample required (finding) |
0301 | Too young for reliable screening | 951961000000107 | Glutaric aciduria type 1 screening, too young for reliable screening (finding) |
0302 | Too soon after transfusion (<72 hours) | 951981000000103 | Glutaric aciduria type 1 screening, sample taken too soon after blood transfusion (less than 72 hours) (finding) |
0303 | Insufficient sample | 952001000000103 | Glutaric aciduria type 1 screening, insufficient sample (finding) |
0304 | Unsuitable sample (blood quality): incorrect blood application | 952021000000107 | Glutaric aciduria type 1 screening, unsuitable sample (blood quality): incorrect blood application (finding) |
0305 | Unsuitable sample (blood quality): compressed/damaged | 952041000000100 | Glutaric aciduria type 1 screening, unsuitable sample (blood quality): compressed/damaged (finding) |
0306 | Unsuitable sample: day 0 and day 5 on same card | 952061000000104 | Glutaric aciduria type 1 screening, unsuitable sample: day 0 and day 5 on same card (finding) |
0308 | Unsuitable sample: NHS number missing/not accurately recorded | 952081000000108 | Glutaric aciduria type 1 screening, unsuitable sample: National Health Service number missing/not accurately recorded (finding) |
0309 | Unsuitable sample: Date of sample missing/not accurately recorded | 952101000000102 | Glutaric aciduria type 1 screening, unsuitable sample: date of sample missing/not accurately recorded (finding) |
0310 | Unsuitable sample: Date of birth not accurately matched | 952121000000106 | Glutaric aciduria type 1 screening, unsuitable sample: date of birth not accurately matched (finding) |
0311 | Unsuitable sample: Expired card used | 952141000000104 | Glutaric aciduria type 1 screening, unsuitable sample: expired card used (finding) |
0312 | Unsuitable sample: > 14 days in transit, too old for analysis | 952161000000103 | Glutaric aciduria type 1 screening, unsuitable sample: more than 14 days in transit, too old for analysis (finding) |
0313 | Unsuitable sample: Damaged in transit | 952181000000107 | Glutaric aciduria type 1 screening, unsuitable sample: damaged in transit (finding) |
04 | (Condition screened for) Not suspected | N/A | | 951781000000101 | Glutaric aciduria type 1 not suspected (situation) |
07 | (Condition screened for) Not suspected, other disorders follow up | N/A | | 951801000000100 | Glutaric aciduria type 1 not suspected and other disorders follow up required (situation) |
08 | (Condition screened for) Suspected | N/A | | 951831000000106 | Suspected glutaric aciduria type 1 (situation) |
09 | (Condition screened for) Not screened/screening incomplete | N/A | | 952201000000106 | Glutaric aciduria type 1 not screened for or screening incomplete (finding) |
0902 | All screens: >1 year, too old for screening | 952221000000102 | Glutaric aciduria type 1 not screened for or screening incomplete: over 1 year old, too old for screening (finding) |
0903 | Moved out of area | 952241000000109 | Glutaric aciduria type 1 not screened for or screening incomplete, moved out of area (finding) |
0904 | Not contactable, reasonable efforts made | 952261000000105 | Glutaric aciduria type 1 not screened for or screening incomplete, not contactable, reasonable efforts made (finding) |
0905 | Baby died | 952281000000101 | Glutaric aciduria type 1 not screened for or screening incomplete, baby died (finding) |
0906 | Not required, previous valid result | 952301000000100 | Glutaric aciduria type 1 not screened for or screening incomplete, not required, previous valid result (finding) |
Regards
Richard Kavanagh
Head of Data Standards
Architecture, Standards & Innovation
Health and Social Care Information Centre
Tel : 0113 397 4398
Mob : 07770 644449 Richard.Kavanagh@hscic.gov.uk http://www.hscic.gov.uk
You probably want to keep the archetypes generic, and use rules for this type of requirement. You can already express such validation rules with the open source GDL editor, http://sourceforge.net/projects/gdl-editor/
Please contact me offline if you need assistance on that.
are these 'statuses' runtime statuses, i.e. set only at processing time? They would seem to be based on their meanings. Are they available in a terminology, or do you even regard them as proper terminology? Modelling something more like an enumeration of simple values could be done, depending... the existence of the subcodes makes me assume that there is some sort of structured terminology there. If not, do you want to use the archetypes to represent the tree structure of allowed subcodes under status code?
The ID column appears to be some sort of code, for a type of test or testing process step, is that correct? Who controls these codes, and when are they set?
The models is intended to be a “semantic target” for a number of different systems dealing with BloodSpot results. To a large degree the model is being created to reflect the current status of systems so needs to reflect the current state not necessarily any future intended state (for now).
With regards to the codes :
“Status Code” used to be an enumeration but has been replaced by the SNOMED code now shown in column “ID”
“Sub Code” used to be an enumeration but has recently been replaced by the SNOMED code now shown in column “ID”
From the threads it would appear that whereas openEHR can theoretical cater for defining these constraints this “feature” is not currently exposed in current tools. We can deal with this problem in other ways so will do so.
