Problem-oriented records and querying by problem
Hi all, just re-sending this question on the clinical list too. I'm wondering how to handle the link between documents and health problems in a problem-oriented record. Thanks! -- Kind regards, Eng. Pablo Pazos Guti?rrez http://cabolabs.com From: pazospa...@hotmail.com To: openehr-technical at lists.openehr.org Subject: Problem-oriented records and querying by problem Date: Thu, 6 Nov 2014 13:28:40 -0300 Hi, another question related to querying: I have a case of problem-oriented records, where I need to query all the COMPOSITIONS related to a specific problem (evolutions, controls, etc). Since we have a Problem List persistent archetype that records OBSERVATIONS about the health problems: - Would it be a good solution to use LINKs between those OBSERVATIONs and the COMPOSITIONs related to those problems in order to solve the query COMPOSITIONS by health problem? Is there another solution for this? What do you think? Thanks! -- Kind regards, Eng. Pablo Pazos Guti?rrez http://cabolabs.com ___ openEHR-technical mailing list openEHR-technical at lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20141118/6dd1709c/attachment.html
archetype UIDs
Hi, I was not aware of this addition. It is clear that having these UIDs it will be simpler to check if the archetype has changed, as you say. But is it also the intention of these UIDs to be used to fill the archetype_id attributes in the RM instances? Or the link between the instance and an specific archetype will be done using the traditional archetype identifier+version+revision+build? Moreover, if now we will have unique identifiers with version+revision+build, why do we need an additional UID? David 2014-11-17 14:44 GMT+01:00 Thomas Beale thomas.beale at oceaninformatics.com: We are finalising the last details of the ADL 2/AOM 2 specifications for a Trial release. One detail is the question of UIDs. The current AOM 2 specification shows two UIDs: provenance_id and instance_id. The former is created at archetype creation and never updated, even with major archetype version changes, meaning that it can always be used to track an archetype, including all versions and copies, through time. The latter is updated every time anything at all changes with the archetype. *The question here is: should these two ids be mandatory in ADL 2? *I believe they should, since they enable tooling to track archetypes and archetype changes properly. Previously, when the specs where identified as ADL 1.5, we had them as optional, for reasons of backwards compatibility, but having moved to ADL 2, we no longer have this requirement. - thomas ___ openEHR-technical mailing list openEHR-technical at lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org -- David Moner Cano Grupo de Inform?tica Biom?dica - IBIME Instituto ITACA http://www.ibime.upv.es http://www.linkedin.com/in/davidmoner Universidad Polit?cnica de Valencia (UPV) Camino de Vera, s/n, Edificio G-8, Acceso B, 3? planta Valencia - 46022 (Espa?a) -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20141118/f0d8c45d/attachment.html
archetype UIDs
On 18/11/2014 12:50, David Moner wrote: Hi, I was not aware of this addition. It is clear that having these UIDs it will be simpler to check if the archetype has changed, as you say. But is it also the intention of these UIDs to be used to fill the archetype_id attributes in the RM instances? Or the link between the instance and an specific archetype will be done using the traditional archetype identifier+version+revision+build? Moreover, if now we will have unique identifiers with version+revision+build, why do we need an additional UID? David Hi David, Personally I don't think UIDs are needed; checking if an archetype has changed is easier to do with an MD5. UIDs are mostly a distraction. But some people and more particularly governments like them. So if we include them in the AOM, then I guess they have to work. So making them optional won't work - because they can't be generated from anything, you have to 'have them' which means they have to have been created at the right point in time, usually by the creator or modifier of some artefact. I don't see any utility in mixing UIDs into the human-readable ID (HRID) either in models or in data. They aren't shorter, and you can't infer anything from them as you can with the HRID, and noone who needs to inspect data (as inescapably happens routinely in integration development work) can easily work with UIDs. So their utility is largely imaginary in my view. But not everyone agrees with that - thomas -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20141118/565dbde3/attachment.html
archetype UIDs
I can see the point now. I couldn't understand the benefits of the new UID attributes. It is OK if they become mandatory in 2.0. We just have to have clear rules to know when a new instance_id has to be created. 2014-11-18 14:31 GMT+01:00 Thomas Beale thomas.beale at oceaninformatics.com: On 18/11/2014 12:50, David Moner wrote: Hi, I was not aware of this addition. It is clear that having these UIDs it will be simpler to check if the archetype has changed, as you say. But is it also the intention of these UIDs to be used to fill the archetype_id attributes in the RM instances? Or the link between the instance and an specific archetype will be done using the traditional archetype identifier+version+revision+build? Moreover, if now we will have unique identifiers with version+revision+build, why do we need an additional UID? David Hi David, Personally I don't think UIDs are needed; checking if an archetype has changed is easier to do with an MD5. UIDs are mostly a distraction. But some people and more particularly governments like them. So if we include them in the AOM, then I guess they have to work. So making them optional won't work - because they can't be generated from anything, you have to 'have them' which means they have to have been created at the right point in time, usually by the creator or modifier of some artefact. I don't see any utility in mixing UIDs into the human-readable ID (HRID) either in models or in data. They aren't shorter, and you can't infer anything from them as you can with the HRID, and noone who needs to inspect data (as inescapably happens routinely in integration development work) can easily work with UIDs. So their utility is largely imaginary in my view. But not everyone agrees with that - thomas ___ openEHR-technical mailing list openEHR-technical at lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org -- David Moner Cano Grupo de Inform?tica Biom?dica - IBIME Instituto ITACA http://www.ibime.upv.es http://www.linkedin.com/in/davidmoner Universidad Polit?cnica de Valencia (UPV) Camino de Vera, s/n, Edificio G-8, Acceso B, 3? planta Valencia - 46022 (Espa?a) -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20141118/923c120a/attachment.html
archetype UIDs
On 18/11/2014 12:50, David Moner wrote: Hi, I was not aware of this addition. It is clear that having these UIDs it will be simpler to check if the archetype has changed, as you say. But is it also the intention of these UIDs to be used to fill the archetype_id attributes in the RM instances? Or the link between the instance and an specific archetype will be done using the traditional archetype identifier+version+revision+build? Moreover, if now we will have unique identifiers with version+revision+build, why do we need an additional UID? David Hi David, What you refer to as version+revision+build is called majorVersion.minorVersion.patchNumber in SemVer. In addition you can have a -alpha flag to indicate that the archetype is still unstable. In this unstable mode a build id is necessary if you want to uniquely identify one particular instance of an archetype - there could e.g. be many 1.0.1-alpha (but only one 1.0.1 or 1.1.0 or 1.0.2). This is just SemVer as far as I am aware. So the complete revision could be e.g. 1.0.1-alpha+BUILD where build is e.g. a UID which changes each time (in a CKM environment on each upload), even if nothing else in the complete revision number changes. Thomas has called this build uid instance id in his initial email. Cheers Sebastian
