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.