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:
-
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.
-
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.
-
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: