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
