“EXAMPLES: each tree in a forest is a member_part of the forest; each piece in a chess set is a member part of the chess set; each Beatle in the collection called The Beatles is a member part of The Beatles.
ELUCIDATION: b is an object aggregate means: b is a material entity consisting exactly of a plurality of objects as member_parts at all times at which b exists. [025-004]“
Well I think this object vs object aggregate divide is stupid. Following this logic everything is an object aggregate (down till quarks): a tree is an aggregate of wood, water leaves etc. Wood is an aggregate of cellulose tissue. Etc etc.
Re the disposable vs device. I find it hard to make this logic hold, a disposable device also needs tracking for availability, and maintenance ( disposal after use, tracking of newly published manufacturing errors etc).
However much fun it is, I don’t think it’s useful for our EHR spec community deciding on these topics. But I also find it difficult to just copy an external ontology into openEHR if we don’t agree with the choices made there. And the sentence justifying modelling choices by US billing sentence makes me want to run away, fast.
So it’s an excellent example of why I think we should stay away from topics like these. And focus on how we can solve our EHR requirements by playing nice with other standards. I’m fine with working with object aggregates, it’s probably been proven useful. And little reason why it wouldn’t work for healthcare if it’s proven to work in other domains. Unlike clinical data, so I prefer to focus our efforts there.
We may not even need Object aggregate; I don’t have a specific example to provide, it is just there for completeness.
Re: Device v Consumable, US billing is just an easy way to understand the difference; it’s universal. And you are right, there are disposable ‘devices’ so we may need better terminology at this level. However, ‘Device’ is a commonly used term in HL7 and health data in general, and consumables are generally distinguished from non-consumables. We can certainly improve the modelling.
There is no doubt that this part of the model is not for all users of openEHR, but there are quite a few who want it, and to implement Task Planning with even basic resource tracking it has to be solved to some level.
Having an archetypable place/model to store EHR related data that does not belong in EHR COMPOSITIONS or elsewhere under the EHR-object can be one of the best ways to play nice with other standards.
It will for example make it easier to store those things imported or to be exported/exposed via FHIR that don’t really fit in an individual’s EHR content, for example many of the resources in the FHIR admin module: Administration-module - FHIR v5.0.0
Yes, often harder than technology. Martin Fowler agrees. I can imagine picking “EHR” over EMR etc. and many other names in openEHR also have been challenging over time.
Regarding some of the non-EHR parts we are exploring in this thread it would be good to fairly soon decide on a reasonable and inclusive generic name of the class/entrance to the collection of entities discussed above. A name that we can use in the REST and URN paths in specification work and that can naturally include the current demographic classes and more. So please engage the synonym part of your minds, suggest and/or discuss a name. Here is a table with some links to click for starter-inspiration:
Edit: added “repository” to table after suggestion by @NeoEHR below.
Personally I lean toward @thomas.beale’s suggestion of “registry” so far after looking up meanings, but I am not a native English speaker, and there may be better suggestions that have not even been on the radar in this discussion yet.
Registry probably is the best candidate. Though it can also be used to refer to data registries such as Cancer registry, which can give the wrong impression, registry is widely used to represent a living collection of related and relevant resources.
For example, one of the key components in the Ayushman Bharat Digital Mission in India (https://abdm.gov.in/home/digital_systems) are registries - Patient, practitioner, provider organizations.
Alternatively, we could use Register (as in register of doctors). But this may cause some confusion with the verb form as in Register for an event.
Update. For now, I’ve left REGISTRY, but it doesn’t really matter much what it is called in the model, this won’t usually be the business name for the deployed facility.
Anyway, this version better separates out the 3 things of interest: Places, Objects and Usage. At the moment I don’t have a better name for what is called CONSUMABLE below INDEPENDENT_OBJECT, but the idea is that a consumable device like a Covid19 lateral flow test could be recorded as a DEVICE with a use_model: CONSUMABLE_USE.
A couple of attributes and relationships could potentially be added, but this is likely as far as we would want to go in terms of ‘hard modelling’. The rest would be archetyping.
(One fix is probably needed; now that there is PLACE, which has addresses: ADDRESS, the contacts of PARTY will probably need adjustment, if we want to connect PARTY to PLACE.
Final note: this is not a finished model, it’s a starter model, for the group to think about in the background.
Update: In a regular SEC meeting a couple of minutes ago, we agreed to use REGISTRY as a working hypothesis regarding name and listen in to other name suggestions and feedback here in Discourse until next meting in another two weeks.
@thomas.beale the concrete ENTITY subclasses seem useful. Could we add a concrete GENERIC_ENTITY subclass and perhaps move the optional type_uri there? (The type of other concrete entity children would already be given by the class names and corresponding documentation.) The GENERIC_ENTITY could be used for purposes analogue to GENERIC_ENTRY, e.g. for imports from external systems or as interim solution while considering/testing new design patterns not yet catered for (or not considered generally reusable enough) in existing ENTITY sub-classes.
We are workning with precision medicine and modeling e.g. some context around genomic testing. There is quality-report data and other information we’d like to store regarding specific batch runs in genomic sequencers and similar equipment. A batch can contain several samples for several patients. (We want traceability, but do not want to copy all that data into each patient’s own EHR, In individual EHRs we just want something identifying the batch and some sample specific results and quality data). Is there a suitable construct in task planning or an ontological entity that could be used as basis for modeling/archetyping data about multi-patient batch runs by a test instrument/device? Or does it fit somewhere in task planning?
We could do that, but it makes the model messier - and I am fairly sure (could be wrong) that the existing implementers would find the software impact very low (I know what it looks like in Java - minimal) or non-existent (i.e. they don’t implement that part of the RM), and I think the data impact, for those that have any, should be zero, or close to it. We should find out from the relevant parties first.
I’d actually rather see type_uri used universally in that model.
The reason I say ‘messy’ is that it kind of breaks the ontological coherence, by adding a ‘not otherwise classified’ sibling to existing siblings that supposedly exhaust the space (which we didn’t yet do - we would need to add in bfo:Generically dependent continuant and bfo: Specifically dependent continuant).
So theoretically, any import should be of some Entity type that we know about. Now, if we want to handle ‘informational entities’ e.g. invoices etc, we need to (probably) add IAO:Document, which is connected to BFO via Generically dependent continuant:
Anyway - bottom line is: I think the SEC should decide as a group on a final approach, following appropriate discussion. I could produce the variant you mention right now of course.
Registry is a location where you keep registers.
Translation: Repository is where you keep master_reference_data
Devices can be reusable or disposable (rather than consumable)
This encourages thinking about tracking the reuse and recording the disposal - an action that can be common to both types of device.
‘Repository’ is certainly another possibility for the concept we have here.
For the second point, I think you are arguing for this:
i.e. USE_MODEL is either SERVICE_USE or DISPOSABLE_USE, which I also think is clearer. This model implies:
a Device can be used in service (multiple times), or used and disposed (e.g. a Covid LFT)
a Consumable would normally be used once and disposed of (gloves, bandages, etc) but could be used in Service a certain number of times, before disposal, e.g. cannula, various kinds of equipment that wear out.
Probably not the end of the story, but closer to reality I think…
I would vote for ‘registry’ rather than ‘repository’. The ‘repository’ will collide with CDR, which we already use quite often. Compared to ‘registry’, ‘repository’ also suggest/relates too much with the action of cache/persistence. @thomas.beale, how would the spec be named then - ‘Registry Information Model’?
So in the multi-patient genomic sequencer batch run mentioned in #3 above, could/should the (quality/meta-)data about the batch run be modelled under a SERVICE_USE instance of the sequencer instance of type DEVICE? And perhaps information about the usage of a chemical library prep kit (CONSUMABLE instance) be modelled under DISPOSABLE_USE if needed?
Or would USE_MODEL be intended for describing potential use rather than actual usage history? Or both? Or does that go in the “resource use” you have described elsewhere?
In the EHR of a patient only part of that information regarding sequencing and prep kit could be referenced using e.g. openEHR-EHR-CLUSTER.sequencing_assay.v0 possibly ehanced with LINKs to the actual instances in the REGISTRY as described above.
Or if properly tagged with a type_uri value of some entity in BFO or another BFO-based ontology, perhaps a GENERIC_ENTITY would be considered ‘elsewhere classified’ rather than ‘not otherwise classified’ in the case that there was no other concrete subclass of ENTITY (yet). For example type_uri value could be IAO:Document (http://purl.obolibrary.org/obo/IAO_0000310). Perhaps a ‘reference archetype’ for document would be used for archetyping the GENERIC_ENTITY, or a CLUSTER archetype suitrable for documents be used to fill the ‘details’ ITEM_STRUCTURE
On the other hand, if there already is a suitable concrete subclass, for example regarding the gene sequencer a DEVICE class, then an openEHR-EHR-CLUSTER.device.v1 archetype could be used to fill the ‘details’ ITEM_STRUCTURE
Based on that description, yes to both, in my view.
This is an important question. Originally I had foreseen separating this out, so that ‘USE_MODEL’ would describe the type of use. But we don’t really need to do that; the relevant archetypes will have the effect of describing types of device / consumable via the choices they make. To represent an actual use needs fields for date/time, duration, probably location, and whatever else, while other details such as use-cost or install/setup type info are (presumably) stable for a given piece of equipment.
What we do need to be clear on is whether instances in an ‘Entity registry’ represent just a kind of device, e.g. Siemens model 111 CAT-scanner, of which a hospital may have 4, or the 4 actual CAT-scanners. In the latter case, the details common to that model of CAT-scanner (e.g. radiation dose levels, modes of usage etc) should preferably only be recorded once; on the other hand each machine may have its own specifics, e.g. , manufacturing ids, date etc. And then there is use of each machine over time. Here it would usually be interesting to know that the machine in cardiology got 6 times the use as the one in oncology.
Yep, not an unreasonable approach to take at all. I’d rather have at least an ‘Information entity’ type class, since this takes care of just about everything that is any kind of document, financial thing etc, but it’s not mandatory.
We will need some proper modelling sessions to sort out the above - which I don’t think is hard, but just requires clarity on the requirements, mainly on the levels of device type → actual device → device use.
Edit: descriptions of types of devices are not devices; they can probably just be a kind of Document. It’s not necessarily hard to solve, just requires clear thinking
A random update to this conversation, due to review work I am doing on the BPM+ standards. I have added a class InanimateEntity within the part to do with what some people (e.g. @sebastian.iancu ) think of as ‘resources’. This allows us to connect the ‘use_model’ property where it belongs, so that it may apply to objects (e.g. devices, consumables) and places (e.g. operating theatres) in an intuitive way.
I have not yet made any addition of @erik.sundvall 's proposed GenericEntity, and I am more inclined not to make it an Entity as such, but just a generic data structure that could accommodate some legacy entity representation from other systems. But - we have only discussed this superficially, and we could go the other way.
On a first look, I see a lot of breaking changes introduced on parties, and even more problematic are some name swapping comparative to RM 1.1 (current ACTOR will be an AGENT, and current AGENT becomes AUTOMATON, ROLE is now PERSONA). I am not familiar with OMG Party models, but in my opinion these changes is now going to brings us much closer to FHIR (judging by the type names at least).
The GROUP.members from my point of view is not necessary, as we have PARTY_RELATIONSHIP.
So… it would be important now to understand the reasoning behind these proposals, before it becomes “too late”, and to discuss impact and solution/choices.
The ‘entities’ are fine I think I am a bit curios about rationale behind FACILITY; and also what would be a BIOLOGICAL_ENTITY and ARTEFACT.
I want to take the opportunity to say it again the current RM.Demographic is quite reach and workable already (I can say that it is a major pillar of Code24 products for more then 9 years, while we also use FHIR for more then 5y). The RM has some missing types and functionalities, perhaps it needs to be freshen up here and there, and we could try to align it as much as it is possible with other standards, but I don’t see the point of introducing too many or major breaking changes. There should be a clear rationale behind this anyways. It would be good to hear more feedback from (future) implementors also.
I meant to mention that I am no longer trying to consider this model as an update to the ‘demographic’ model. I suggest we call it the ‘registry’ model for now.
I also forgot to mention that you can click on any class - the model is reasonably well documented.
They might - I still have to do a new analysis on the details. The class naming is more from BFO.
FACILITY for the moment is a building, theatre, ward, room etc normally with a specific business function. Possibly a bfo:Site or else bfo:3-D fiat boundary.
BIOLOGICAL_ENTITY is (currently): Any entity containing DNA and/or RNA, including living organisms, deceased organisms, body parts, tissue, blood, food items (meat, vegetables, fruit), bacteria and viruses. (This follows BFO).
Yes - I have taken the approach to produce a ‘new’ model for the moment, which allows us to think properly about the issues without constraint. We can then back-port some changes in a non-breaking way to the demographic model.
