That's not the v3 approach - it's ucum only. If ever I revisited the v3 data types. That would be one of my priorities to fix.
Grahame > On 19 May 2016, at 6:30 AM, WILLIAM R4C <[email protected]> wrote: > > Dear Grahame, I guess you mean the HL7 v3 approach: human readable and > computable codes + unit that FHIR correctly adopted?✅ > > Vriendelijke groet, > > Dr. William Goossen > > Directeur Results 4 Care BV > +31654614458 > >> Op 18 mei 2016 om 21:46 heeft [email protected] >> het volgende geschreven: >> >> Send openEHR-technical mailing list submissions to >> [email protected] >> >> To subscribe or unsubscribe via the World Wide Web, visit >> >> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org >> >> or, via email, send a message with subject or body 'help' to >> [email protected] >> >> You can reach the person managing the list at >> [email protected] >> >> When replying, please edit your Subject line so it is more specific >> than "Re: Contents of openEHR-technical digest..." >> >> >> Today's Topics: >> >> 1. Re: UCUM code in body temperature archetype (Ian McNicoll) >> 2. Re: UCUM code in body temperature archetype (Grahame Grieve) >> 3. Re: UCUM code in body temperature archetype (Thomas Beale) >> >> >> ---------------------------------------------------------------------- >> >> Message: 1 >> Date: Wed, 18 May 2016 17:56:06 +0100 >> From: Ian McNicoll <[email protected]> >> To: For openEHR technical discussions >> <[email protected]> >> Subject: Re: UCUM code in body temperature archetype >> Message-ID: >> <CAG-n1KxqHXMUS73VXVP=qghx-wtuxos9uljo8u4-xo4xqtr...@mail.gmail.com> >> Content-Type: text/plain; charset="utf-8" >> >> Hi Peter, >> >> I think I did manage to identify and fix that particular problem locally >> but was stumped by this wider issue of whether how/if we display code / >> human version or both. >> >> https://openehr.atlassian.net/browse/AEPR-44?focusedCommentId=14127&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14127 >> >> Ian >> >> Dr Ian McNicoll >> mobile +44 (0)775 209 7859 >> office +44 (0)1536 414994 >> skype: ianmcnicoll >> email: [email protected] >> twitter: @ianmcnicoll >> >> Co-Chair, openEHR Foundation [email protected] >> Director, freshEHR Clinical Informatics Ltd. >> Director, HANDIHealth CIC >> Hon. Senior Research Associate, CHIME, UCL >> >>> On 18 May 2016 at 14:03, Peter Gummer <[email protected]> wrote: >>> >>> Hi Silje, >>> >>> Yes, it was at the end of October that I was trying to get it to work. A >>> DataGrid in AE was throwing exceptions, complaining about duplicates >>> because the property_id and text fields have to form a unique key. I did >>> manage to find and remove one pair of duplicates from the file that you >>> provided but even after that it was still complaining. I never got to the >>> bottom of what was causing it. >>> >>> Looking at GitHub, nothing resembling your corrections appears to have >>> made it there yet: >>> >>> >>> https://github.com/openEHR/arch_ed-dotnet/commits/master/ArchetypeEditor/PropertyUnits >>> >>> I would suggest that the best way to proceed would be to add the fixes >>> again, but proceed slowly, testing your file in AE after every few changes. >>> Keep a backup copy after each successful test. Then, if AE complains about >>> a small set of changes, it will be easy to identify what has caused it. >>> >>> Peter >>> >>> >>>>> On 18 May 2016, at 22:37, Bakke, Silje Ljosland < >>>> [email protected]> wrote: >>>> >>>> They usually are, though the units file in the Archetype Editor has had >>> (still has?) a lot of errors in it, which means the correct units had to be >>> edited into the ADL by hand. I made a better version of the units file for >>> the AE a while ago, but there were some issues with it that I'm not sure if >>> have been solved or if it's made its way into a release. >>>> >>>> Regards, >>>> Silje >>> >>> >>> _______________________________________________ >>> openEHR-technical mailing list >>> [email protected] >>> >>> 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/20160518/8940f676/attachment-0001.html> >> >> ------------------------------ >> >> Message: 2 >> Date: Thu, 19 May 2016 02:58:47 +1000 >> From: Grahame Grieve <[email protected]> >> To: For openEHR technical discussions >> <[email protected]> >> Subject: Re: UCUM code in body temperature archetype >> Message-ID: <[email protected]> >> Content-Type: text/plain; charset="us-ascii" >> >> Hi >> >> You missed my point. I assume that the content model will differentiate >> between ucum code and some other code, so as to enable all the behaviour you >> describe. >> But you don't need to force the use of a different element in a different >> place of the model. Merely differentiating the terminology used will achieve >> that. A processor will know when it can use ucum based logic - not that I've >> ever seen that in the real world - and it will know when it can't >> >> Eric's part of this thread notes the issues with doing with this implicitly, >> so I'm not advocating for that, which brings you back to the FHIR model: >> human units, and system + code for computable units. >> >> Grahame >> >>> On 18 May 2016, at 10:06 PM, Thomas Beale <[email protected]> wrote: >>> >>> >>> I knew someone would say that;-) But it's not for some principle of >>> ontological purity. It's for the most basic practical reasons. Consider a >>> quantity / units library designed based on a rigorous model of units, like >>> UCUM (which is a very good and rigorous piece of work), and also >>> other basic principles in science e.g. >>> >>> there are only 9 primitive physical properties; >>> all other physical properties can be obtained by combining the 9 primitive >>> ones, e.g. pressure = mass/area; area = length^2; >>> various mathematical properties hold for true amounts (these can be >>> described formally) >>> etc >>> These things don't hold for 'dose units', because they are not the same >>> kind of thing. They can't be modelled or computed in the same way. >>> >>> So there are two choices: >>> >>> hack a clean model / library of scientific units to force it to deal with >>> non-units; these creates dirty code and bugs, and lots of if/then exception >>> conditions >>> write a new clean model of the new kind of units, and integrate it with the >>> basic scientific units model. >>> I am only interested in one thing here: clarity for coders and data, which >>> translates to error-reduction, better quality data and more maintainable >>> code in the long run. >>> >>> The final result may not be particularly differentiated on the screen, or >>> even consciously understood by end users, but they are miles away from the >>> models and code inside the systems we build. >>> - thomas >>> >>>> On 18/05/2016 12:54, Grahame Grieve wrote: >>>> The arbitrary units are something different, but why does that matter at >>>> the data type level? If you understand the unit, you can work with it, if >>>> you don't you can't. Separating them because of ... Ontological ... >>>> Purity: just creates make -work for all the users who otherwise don't >>>> differentiate them >>> >>> _______________________________________________ >>> openEHR-technical mailing list >>> [email protected] >>> 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/20160519/4a684942/attachment-0001.html> >> >> ------------------------------ >> >> Message: 3 >> Date: Wed, 18 May 2016 20:45:34 +0100 >> From: Thomas Beale <[email protected]> >> To: For openEHR technical discussions >> <[email protected]> >> Subject: Re: UCUM code in body temperature archetype >> Message-ID: <[email protected]> >> Content-Type: text/plain; charset="windows-1252"; Format="flowed" >> >> Grahame, >> >> I think you are saying that you can implement the /semantics /of dose >> units with just a DvQantity / FHIR Quantity. If 'dose units' includes >> the knowledge of the discrete unit of delivery, i.e. table, drop etc, as >> well as total amount, you can't. You need at least the elements here, or >> their equivalent. >> >> class DoseQuantity >> unitForm: DvCodedText // type of physical dose entity >> tablet, capsule, puff etc >> unitAmount: DvQuantity // how much is in a `doseForm` unit >> e.g. 5mg >> doseCount: Integer // how many items of `doseForm` to >> deliver >> >> doseAmount: DvQuantity { // total amount of substance >> delivered to patient >> Result := doseCount * unitAmount >> } >> end >> >> If on the other hand you are saying we just go the pseudo-units route, >> where 'tablet' is a kind of unit, we can, but the Quantity library won't >> work properly anymore, because you no longer know if you can add two >> quantities even if they have the same unit, because 'tablet' as a unit >> doesn't mean anything. Where I am coming from is: Quantity is not just >> data, it is operations and computing >> <http://www.openehr.org/releases/RM/latest/docs/data_types/data_types.html#_quantity_package>; >> >> it includes operators like: >> >> * DV_AMOUNT: =, +, -, *, etc >> * DV_ABSOLUTE_QUANTITY: diff, add, subtract >> >> (there are many ways to model this kind of thing, that's just the >> openEHR way). >> >> If you are saying: use a code + code-system approach, and check the code >> system, and do something if UCUM, and something else if not, I've now: >> >> * got just a data-oriented Quantity type >> * a bunch of if/else code to treat different Quantity 'types' differently >> * I have to move the operators out to another level, because they no >> longer make sense for this new style of Quantity >> >> So, in terms of what we do in openEHR, I don't think it makes sense. In >> terms of FHIR, it makes sense; but I have to check a FHIR Quantity and >> instantiate different kinds of RM structures depending on the units code >> system. >> >> - thomas >> >>> On 18/05/2016 17:58, Grahame Grieve wrote: >>> Hi >>> >>> You missed my point. I assume that the content model will >>> differentiate between ucum code and some other code, so as to enable >>> all the behaviour you describe. >>> But you don't need to force the use of a different element in a >>> different place of the model. Merely differentiating the terminology >>> used will achieve that. A processor will know when it can use ucum >>> based logic - not that I've ever seen that in the real world - and it >>> will know when it can't >>> >>> Eric's part of this thread notes the issues with doing with this >>> implicitly, so I'm not advocating for that, which brings you back to >>> the FHIR model: human units, and system + code for computable units. >> >> -------------- next part -------------- >> An HTML attachment was scrubbed... >> URL: >> <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20160518/56ae46d7/attachment.html> >> >> ------------------------------ >> >> Subject: Digest Footer >> >> _______________________________________________ >> openEHR-technical mailing list >> [email protected] >> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org >> >> ------------------------------ >> >> End of openEHR-technical Digest, Vol 51, Issue 17 >> ************************************************* > > > _______________________________________________ > openEHR-technical mailing list > [email protected] > http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org _______________________________________________ openEHR-technical mailing list [email protected] http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
