Dear All, I think some information is missing in the current pregnancy archetype, e.g. birth plan (or preferred birth choice), pregnancy complications (maybe should have a link between the pregnancy archetype and the complications), indications of high risk pregnancy (e.g. number of miscarriage, fertility treatment etc.), previous laboring history, caesarean history and the reasons for caesarean.
In addition, the birth weight should go with the birth details. Both the mother's record and the baby's record need the birth weight. I don't see it is appropriate to include Breast fed information in the Pregnancy archetype. I also don't think the "Date ceased breast feeding" and "Age ceased breast feeding" should be in the pregnancy archetype. Cheers, Chunlan Sam Heard wrote: > 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/ > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-clinical_lists.openehr.org/attachments/20060720/4506e98f/attachment.html>
