I guess smart querying services would do the work. But should it also be possible for the client to say when unit conversion should be used and when not?
Use case is when user only want the units stored as grams, and not kilos.
Maybe a pattern from HTTP could be used. The accept pattern.
Accept: profile (metrics, british imperial)
Accept: gram, kilos
Of course all this add complexity and we must be sure that we really need it.
I think we could add something at reference model level to say give me
this quantity in 'x' units, performing the conversion at server level
where possible or return null. This could also be supported in AQL
since it would just be another RM attribute/function?
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
Again, I strongly believe we can achieve this with
Assertions/pseudo-OCL that currently can be defined in archetypes.
For example: "if 'units' from atNNNN are 'kg' then
'value'='value'*1000 and 'units'=g"
I think Thomas told me there were some improvements in the archetype
assertions section/syntax.
we could do this; it would be replicating the applicable rules from the UCUM conversion engine. Writing such rules is certainly doable - it could even be done by an authoring tool that talks to the UCUM service and gets the info it needs to construct the rule.
I don't know if this is a good idea or not at this stage.
I am sure that could be done but it would mean replicating these kind
of statements in every archetype that had multiple units. This really
feels like something that should be handled computationally at RM
level- it is universal and a property of the units not of the
archetype.
Ian
Dr Ian McNicoll
office +44 (0)1536 414 994
fax +44 (0)1536 516317
mobile +44 (0)775 209 7859
skype ianmcnicoll
ian.mcnicoll@oceaninformatics.com
Clinical Modelling Consultant, Ocean Informatics, UK
Director openEHR Foundation www.openehr.org/knowledge
Honorary Senior Research Associate, CHIME, UCL
SCIMP Working Group, NHS Scotland
BCS Primary Health Care www.phcsg.org
Well, I assume that this also works for specialized archetypes, I
don't see why it shouldn't. Declare rules in parent archetype and you
don't need to declare them anywhere else.
You could potentially create a template for each archetype with this unit issue, if you like, and govern it in the Norwegian CKM. That artefact can then be published as the ‘approved’ Norwegian version of the international archetype.
Templates of a single archetype are effectively a profile. We use this in Ocean’s implementations where we want consistent archetype constraints used across multiple document templates.
Templates can then be used in other templates and these Norwegian-specific constraints could be used consistently across templates within a single clinical system and also across multiple clinical systems.
The only remaining issue would be to indicate that the template is the preferred modelling artefact – not sure how we do that other than notification in CKM. It would not be apparent to modellers deep in the tools, and predominantly working with archetypes. Not sure how we could do that… L
Tom, I think profiling would add unnecessary complexity and would backup Heather and Ian's comments.
That sounds more like FHIR thing than openEHR! We already have a well defined mechanism to specify local constraints at template and also Choice type constructs (my inside voice warning hey you are talking to Tom who knows this way better than I do!). I'm really confused that you have raised this idea...
I agree with that approach. I would actually regard this as a kind
specialised archetype, just using template technology.
One of the advantages of moving to ADL1.5/2.0 is that it is is
possible to do this kind of profiling as a specialised archetype not
just within a template. In fact templates and archetypes are
technically identical.
You do raise an interesting point about how/if we flag that the parent
archetype itself should not normally be used.
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
I agree, this will not always be possible but where the conversion can
be safely done, I would still argue that this should be done at RM
level and not per-archetype.
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
RM function to retrieve a magnitude expressed as a particular unit.
I think we could add something at reference model level to say give me
this quantity in 'x' units, performing the conversion at server level
where possible or return null. This could also be supported in AQL
since it would just be another RM attribute/function?
magnitude.inUnit['mg']
I think this is, roughly speaking, what FHIR is doing
Ian
Dr Ian McNicoll
office +44 (0)1536 414 994
fax +44 (0)1536 516317
mobile +44 (0)775 209 7859
skype ianmcnicoll
ian.mcnicoll@oceaninformatics.com
Clinical Modelling Consultant, Ocean Informatics, UK
Director openEHR Foundation www.openehr.org/knowledge
Honorary Senior Research Associate, CHIME, UCL
SCIMP Working Group, NHS Scotland
BCS Primary Health Care www.phcsg.org
well, it's not a reference model thing inasmuch as it's not an information model concept at all, but a knowledge service concept, relying on some database of units that knows about canonical forms, conversions etc. This is what things like the UCUM service do, via an API. I wouldn't want to make the RM dependent on specific functions of such an API; I think the most that the RM should assume (as it does right now in fact) is that the units are in UCUM syntax.
Agreed - the dummy function call says "give me the magnitude in ‘xx’
Units of measure, performing any conversions necessary”.
Ian
Dr Ian McNicoll
office +44 (0)1536 414 994
fax +44 (0)1536 516317
mobile +44 (0)775 209 7859
skype ianmcnicoll
ian.mcnicoll@oceaninformatics.com
Clinical Modelling Consultant, Ocean Informatics, UK
Director openEHR Foundation www.openehr.org/knowledge
Honorary Senior Research Associate, CHIME, UCL
SCIMP Working Group, NHS Scotland
BCS Primary Health Care www.phcsg.org
