Dear all, These thoughts/decisions are part of what I would call: AKF. The Archetype Knowledge Framework that must/will be a joint CEN/ openEHR/HL7 project. This is the knowledge on how to deal with Archetypes and Archetype Types, including the Archetype Ontology.
What is the method we will use to document all results/rules/ decisions of the AKF discussions? Greetings Gerard -- work -- Gerard Freriks, arts TNO ICT Brassersplein 2 Delft, the Netherlands T: +31 15 2857105 M: +31 653 108732 G.Freriks at telecom.TNO.nl On 18-jul-2006, at 22:24, 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-clinical_lists.openehr.org/attachments/20060719/d3af2ac9/attachment.html>
