The archetype has been through 3 review rounds. There seems to be consensus among the reviewers. The archetype will be published on March 16th.
Link to the archetype: https://ckm.openehr.org/ckm/archetypes/1013.1.331 .
Please reply to this topic if you have any objections or comments.
Published.
I randomly looked at this, and (shoot me for being way too late), but the element âSampling contextâ is confusing different things from an ontological (real world) POV.
Things like âfastingâ and âfull bladderâ are patient state attributes that will (potentially at least) have a direct bearing on how to interpret the sample (extreme example - patient didnât fast prior to reference OGTT sample); but things like âcentrifuge on receiptâ and (I think) âsterile fieldâ have nothing to do with patient state (maybe the latter is infection tracing?).
It seems reasonably obvious that at least two attributes are needed here:
I wonder if the latter is really more fields as well; itâs not clear what the possibilities are.
Iâm not going to shoot you, but yeah youâre way to late for the publication. Would you like to be invited to archetype reviews?
For this one though, you can add a change request. 
Thomas, You are undoubtedly correct and I have had exactly those discussions both in openEHR and UK FHIR care-connect contexts, but in practice we face some challenges.
In many instances these are fine and largely ignored/confused distinctions for both clinical professionals and lab system designers. In fact in many cases the âstateâ is wrapped up in the name of the analyte or carried not in the result but only in the original request. We always need to be careful not to get too far ahead of our customers ability to adhere to whatever rules and guidance we present, especially in the labs world where we are very much recipients of other peopleâs data models. We always have to ask ourselves whether being ârightâ is actually being helpful or achievable, and that does mean we have to look at what happens now, as well as what might be
So I might agree with you about âcentrifuge on receiptâ/ but âsterile fieldâ is a bit more borderline in terms of patient state, I feel. These are exactly the kinds of discussions that we have (endlessly) in the modelling world.
As Silje says you are very welcome to join!!
Just looking for clarity in the real world, as alwaysâŚ
There are 2 varietes of real-world
The ontological real world where actual, factual entities and relationships can be defined and understood.
The practical real-world where the ontology is mangled by both people and technology for good reason or bad!!
Our challenge is to find the optimal path between the two.
I feel I should perhaps offer this to BBC Radio 4 's âThought for the Dayâ slot
âBless me Father for I have sinned, in the matter of patient stateâ 
Well, thereâs really just the real world, and peopleâs misunderstandings of it (John Searle is a good philosopher to read on this). Problem is, humans can mentally sort mis-classifications fairly easily, computers generally canât. But if we properly distinguish what is truly different in reality, we have more hope of computing with it.
I would say the above archetype is an example (maybe with many others) where data/state/protocol applies at a finer-grained level than just the full observation (thatâs actually not true ontologically; those things are theoretically in the right place at Observation level, but in terms of closest association of patient state data points with the focal data points to which they apply, the d/s/p triple might be useful at the finer level).
I agree that if it is not achievable, itâs not interesting to pursue it. But if it is, then it may be worth doing e.g. better quality (even if more complex) mappings at integration points, in order to get better quality (i.e. more computable) data into the EHR. Just copying in crap creates a garbage dump, which might be ok for some uses, but it really doesnât advance us much.
Being ârightâ in these cases doesnât equate to some idealistic notion of perfection, itâs simply whether the result will be computable or not. If itâs not, the data are less useful (which is not to say useless, of course).
This is why people like Barry Smith, Stefan Schulz etc work so hard on this stuff - itâs about enabling machines to help a lot more than they do today.