This may already have been raised or is known, but re: pg and nb bw, these are data defined by many organizations/assns for required reporting, e.g. Birth Certificates, State, JCAHO, Maternal-Fetal Medicine studies, etc., and for the most part have been captured through the Medical Record abstracting process that occurs in Health Information Mgmt. Ex: nb bw captured on Mo abstract, nb mrn captured on Mo abstract; Mo mrn captured on nb abstract. Also, linking still often occurs in primary care medicine w/ families. W/ paper phys office records the family is given a common identified w/ each member of the family being assigned an add'l and unique ID'r. My description here is for paper records; I do not know what ambulatory primary care SW vendors are offering.
Carolyn Wilson Health Care/Life Sciences Deloitte Consulting, LLP Tel: +1 313 396 3060 Fax: +1 313 392 6350 Mobile: + 1 419 283 1506 carolynwilson at deloitte.com www.deloitte.com <http://www.deloitte.com/> ________________________________ From: Sam Heard [mailto:[email protected]] Sent: Tuesday, July 18, 2006 4:25 PM To: ?mer Hotomaroglu Cc: Heather Leslie; Hugh Leslie; openEHR-Clinical; Stan Huff; Craig Parker Subject: Re: birth_weight, pregnancy, adl Omer The pregnancy archetype is a new approach and therefore draft - but I think it will be a more common approach in the future - I could be wrong! We are debating this at the moment and I am not sure of the final outcome. The pregnancy archetype has the benefit, at the moment, of keeping key information about a pregnancy in one place - a coherent data set that can persist over a long period, be shared and copied - find its way into the baby's health record etc. It is an evaluation, as it has a lot of dates, even decisions. While we can enter the birth_weight of each baby in the mother's record - and we probably will have compositions that relate to the child - this information as a single data item is an observation - and so will be recorded at a particular time - by someone - perhaps with some method involved (although it is a simple observation). The choice here is: 1. Do we create an element archetype (ie one quantity) and set the constraints to Gm or Kg and the values - and then embed it in an observation called birthweight as well as the pregnancy archetype. This will no longer be a specialisation of weight - as it is at present and so will not be able to be graphed with other weights of the baby etc without special processing. There are more problems of this approach - the data subject of the weight is the baby and the pregnancy is the mother - an entry can only have one subject of data. So this approach is not going to work. The decisions to have one data subject per entry is a compromise in openEHR to make queries fast and safe - this is a negative consequence - but there are many positive consequences. 2. Second, do we point from the pregnancy archetype to the birth_weight record in the EHR and have it as a strong link (ie - it will move with the pregnancy data whereever this is sent and copied? We can definitely do this - it will end up in the Obstetric history or some other persistent information bucket and work. For viewing purposes this will be fine - but, if the data is entered retrospectively this will be very messy. It will also require a lot more smarts in application software to display this usefully. 3. Currently we duplicate this information here. This requires some smarts in the software - ie populating the data point - but can be managed by humans without a great overhead. I think this is the best approach and will cause the least problems and errors. We will have to be sure that our Archetype ontology knows about this - but clinicians will be wise enough on their own to go looking here for this information. Software will soon be able to duplicate the information if required. The same issue will arise with some other data points in the pregnancy archetype - e.g. LMP and the details of the menstruation that will also be in another archetype. The design here is really for the shared health record - and as such may be differ a little from the approach one would take in a standalone health record. Also, these data points are optional, so it will be possible to take a different approach in the future when we get more sophisticated. It is not immediately obvious to IT people or clinicians that data entered in a linear way on the screen might end up in different places in the EHR. So we might enter information about the onset of labour in the pregancy archetype at the same time as we enter a vaginal examination record and administer oxytocin in a drip in the event record which becomes part of the ongoing labour record. Finally, our archetype ontology will - we envisage - be able to reason about the links between these two data points and resolve a query if we need it to. I am copying this discussion to the openEHR clinical list and Stan Huff and Craig Parker to give some idea of the issues that arise in this space and what are the best solutions. Cheers, Sam ?mer Hotomaroglu wrote: One quick question: Why is "Birth Weight" defined as a field in "openEHR-EHR-EVALUATION.pregnancy.v1draft.adl", instead of using "openEHR-EHR-OBSERVATION.body_weight-birth.v1.adl" ? -- Dr. Sam Heard MBBS, FRACGP, MRCGP, DRCOG, FACHI CEO and Clinical Director Ocean Informatics Pty. Ltd. <http://www.oceaninformatics.biz/> Adjunct Professor, Health Informatics, Central Queensland University Senior Visiting Research Fellow, CHIME, University College London Chair, Standards Australia, EHR Working Group (IT14-9-2) Ph: +61 (0)4 1783 8808 Fx: +61 (0)8 8948 0215 This message (including any attachments) contains confidential information intended for a specific individual and purpose, and is protected by law. If you are not the intended recipient, you should delete this message. Any disclosure, copying, or distribution of this message, or the taking of any action based on it, is strictly prohibited. [v.E.1] -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-clinical_lists.openehr.org/attachments/20060719/104a9002/attachment.html>
