# Demographic model improvements **Category:** [Entity/demographics](https://discourse.openehr.org/c/entity/112) **Created:** 2021-06-17 18:17 UTC **Views:** 2846 **Replies:** 47 **URL:** https://discourse.openehr.org/t/demographic-model-improvements/1645 --- ## Post #1 by @thomas.beale A long-term limitation of the [openEHR demographic model](https://specifications.openehr.org/releases/RM/latest/demographic.html) has been the ability to clearly represent employment and similar relationships, which are commonly needed in healthcare (and are in the FHIR Admin model for example). A proposal to do this is shown below. It adds the ACCOUNTABILITY concept to the model, which represents a defined requirement or need to be filled for one PARTY by another PARTY, usually playing a ROLE. The most common ACCOUNTABILITY is an employment 'post' or 'position' of an ORGANISATION, but a PERSON might have an ACCOUNTABILITY as well, like 'personal trainer'. Accountabilities are defined by an ACTOR (which in the openEHR model is a real entity, not a kind of role). If the Accountability is currently filled - e.g. if 'Senior obstetric consultant' job post is filled, then there will be a PARTY_RELATIONSHIP between the owner of the Accountability (an Organisation) and the filler, which will be another ACTOR (a PERSON) who has Capabilities including being an MD (and usually further qualifications in the Obstetrics area) playing the ROLE of Obstetric consultant in that relationship. The PARTY_RELATIONSHIP represents the employment relationship, and will be scoped by the ACCOUNTABILITY of that particular position (i.e. Senior obstetric consultant). A modified form of the existing demographic model is shown below to achieve the above, with the modifications highlighted (note that this model is a copy of the original and class names have been changed so as not to clash with the original, i.e. ACTOR2 etc). ![demographic_acc|690x277](upload://wEPTWUEwyXFnolkYVpKgITdW444.png) There are variations in how this could be modelled of course. THe form above enables unfilled Accountabilities such as job posts to be defined against an Actor (usually an Organisation), but for use in many situations, it may be that only those Accountabilities that are actually filled are needed to be represented. In that case, the Actor.accountabilities relationship would not be needed, and Accountability instances would only be attached to the Party_relationship representing their filling; when such relationships were severed (person leaves a job), the Accountability would disappear as well. The model above can be used in both ways. Feedback welcome. --- ## Post #2 by @erik.sundvall Hi! Recently in the specification #general Slack channel we have had some wild brainstorming and discussions ranging from improving to removing (deprecating) the openEHR [demographic specifications](https://specifications.openehr.org/releases/RM/latest/demographic.html) @sebastian.iancu reminded that slack discussions are less visible (and expire when we pass time thresholds) and suggested moving them to Discourse. I hope different voices in that discussion can contribute a compressed version of that discussion also here. ## Background @sebastian.iancu has started authoring a REST specification for accessing the classes in the demographic package so that they can be accessed in a standardized way. In earlier discussions it has been mentioned that demographics is not a perfect name for this if we want to expand it to more general resources like rooms, equipment etc. Perhaps an improved version of this part of the RM can be thought of as a (version controlled) registry of information complementing the more encounter and episode-focused things that the [EHR-part of the RM](https://specifications.openehr.org/releases/RM/latest/ehr.html) focuses on. If we are going that direction, then perhaps we could prefix the new REST services …/registry/... instead of …/demographic/...? Also in the [work with an openEHR URN syntax]( https://openehr.atlassian.net/wiki/spaces/spec/pages/786956289/DV+EHR+URI+related+issues) it would be good to set a more extendible future proof ‘registry’ syntax rather than ‘demographic’ for the parts that don’t fit under the EHR object. ## Current draft suggestion (initial brainstorm) Here is a current model suggestion sketch created by @thomas.beale summarizing part of the Slack discussion (from those that don’t want to deprecate the demographics part). It includes the ACCOUNTABILITY part discussed in the previous post above. Please mentally remove the “2” in the class names below, it was added to avoid naming collisions in a modelling tool. ![image|690x348](upload://AeQOvD8NDps47ZcSQWjKYRBU647.png) The main changes are new ENTITY, ACCOUNTABILITY and REGISTRY classes. The ENTITY class is on purpose very general to allow storing various things in the registry. The inheritance from LOCATABLE and the ‘details’ ITEM_STRUCTURE property makes it archetypable. LOCATABLE also allows for LINKs between registry objects (and potentially EHR content). The type_uri can be used for marking semantic types using ontologies or other URI-identifiable models like HL7 FHIR resources. > **TODO**: Discuss if the ENTITY class should be abstract and have a lot of subclasses (a mix of abstract and concrete) or be concrete and then use archetyping and (possibly improved) LINKs to represent things like devices and facilities. There were more thoughts in the discussion that hopefully will show up in a continued discussion here. What are your thoughts? Should the demographic model be deprecated, unchanged or changed to ar more general registry? Why? --- ## Post #3 by @thomas.beale Here is the `ENTITY` hierarchy in this very rough initial version. ![entity-demographic|690x350](upload://jEgqccZBMKgI0qO7aqQaISD37OR.png) The abstract types are based on [BFO](https://github.com/bfo-ontology/BFO/wiki); Entity in the above is 'Continuant entity' in BFO. We don't include all BFO classes, just those needed. Concrete classes like DEVICE, CONSUMABLE SITE, FACILITY etc then have a place to sit, and inherit appropriate relationships. BFO visualisation: ![image|379x500](upload://xolF7BfpLvmLB96K0Arc6dVvHjV.png) --- ## Post #4 by @thomas.beale [quote="erik.sundvall, post:2, topic:1645"] then perhaps we could prefix the new REST services …/registry/… instead of …/demographic/…? [/quote] This is probably a good idea. --- ## Post #5 by @thomas.beale [quote="erik.sundvall, post:2, topic:1645"] **TODO**: Discuss if the ENTITY class should be abstract and have a lot of subclasses (a mix of abstract and concrete) or be concrete and then use archetyping and (possibly improved) LINKs to represent things like devices and facilities. [/quote] Well the general principle underlying the definition of an information model for use with archetypes is to limit it to 'domain-invariant' semantics. E.g. think of OBSERVATION in the openEHR RM, which is the same thing for any concrete kind of observation. So although we can just make RMs of node/arc, having more detail is useful, as long as it is domain applicable. So, concretely... * we can (potentially) agree that there are such things as 'device' (a thing that is not destroyed in use, and needs to be maintained), 'consumable' (a thing that is destroyed in use, and thrown away), aggregates of things; places which are at least divided into 'site' (something like a geographical area or conceptual place containing e.g. Karolinksa institute) and 'facilities' which are buildings, theatres, rooms, beds etc - places with a particular function/purpose. * if we agree on this minimum of concrete types, then we achieve three things: * users of the model all use those names, i.e. 'CONSUMABLE' or whatever names we agree on * we have standardised relationships and a few attributes built-in, like `PLACE.contained_objects` and so on. * any software and DBs can assumed these fixed names and relationships, and can therefore do useful things like visualise any SITE/FACILITY hierarchy, just like it can compute with PARTY.contacts etc. * if we stop at 'ENTITY' (not even BFO does that!) then every org that does archetypes of day 'device' will do it differently, including with different names, e.g. 'machine' etc. There will be no commonality a priori, and nothing for software to rely on, not even hierarchical structure. Of course the trick is to know where to stop. The above rough model is actually an extract of a model built for the US gov and reviewed by a dozen experts, as well as discussed with BFO authors, so it's not entirely made up. But the bottom concrete classes nevertheless need discussion, and mainly experimentation with an archetyping tool. The way to think about this question in my view is to imagine: what if there were not any kind of ENTRYs in openEHR, just a class ENTRY, and CLUSTER, ELEMENT (a la 13606). Result: no common Observation archetypes in 13606, with easily separable timing, 'protocol' or whatever and no ability to build any assumptions into software. Certainly no hope of querying for Instructions / Actions with current_state = Active. --- ## Post #6 by @erik.sundvall [quote="thomas.beale, post:5, topic:1645"] if there were not any kind of ENTRYs in openEHR, just a class ENTRY, and CLUSTER, ELEMENT (a la 13606) [/quote] The thing that happens then is that you need something else to model shared structure design patterns. In 13606-inspired (and CIMI?) land you may have noticed a need for fairly generic "reference archetypes" or similar constructs to base other (specialised) archeypes on. You'd then likely have such a referenca archetype for PLACE etc. This is nice for people who want small (non-changing) RM-models, but it pushes (and defers) the task of finding shared patterns into the (reference-)archetype level of modeling instead. Some of the obvious drawbacks is that you in practice just get yet another layer of modeling and make software/database optimization at class level for such design patterns harder than if it was in the RM. Simplification at one level may complicate the next level instead... But different tools and people may "rule" the different levels (e.g. RM vs archetype) and that likely has an effect on different people's preferences [quote="thomas.beale, post:5, topic:1645"] Of course the trick is to know where to stop. [/quote] Yes. And the more classes and the more detail, the larger risk of frequent RM changes. (Something we want to avoid, and that gives openEHR system implementers the creeps.) No matter wich way we'd go I believe it would be good to from the beginning actually also have a **generic** entity of some kind available to use in a registry, similar to [GENERIC_ENTRY](https://specifications.openehr.org/releases/RM/latest/integration.html#_overview). That can be very helpful when you need to fit other things in to the registry than the ones we have happened to forsee when designing the ENTITY-subclass tree or when a data source you want to represent won't fit the patterns. Example: let's assume that you for some reason need to represent a [FHIR Invoice](https://www.hl7.org/fhir/invoice.html) in your registry and associate+store it with some other "properly" RM-modelled entity in your registry. Then it would be nice to be able to just use a generic entity and make a suitable archetype for that integration purpose. --- ## Post #7 by @thomas.beale [quote="erik.sundvall, post:6, topic:1645"] In 13606-inspired (and CIMI?) land you may have noticed a need for “reference archetypes” or similar constructs. You’d then likely have such a referenca archetype for PLACE etc. This is nice for people who want small (non-changing) RM-models, but it pushes (and defers) the task of finding shared patterns into the (reference-)archetype level of modeling instead [/quote] I've always found 'reference archetypes' a theoretically attractive idea, but I have great doubts about the level of real cooperation that would occur - consider, we would be then throwing decisions on what constitutes an 'observation' or whatever, over the wall to the community to argue about it. Would they reproduce our research into epistemology and scientific data representation? Or even do anything? More than likely, programmers would take over, push the clinical people out of the way and create a wild west of competing models, all non-interoperable. Don't forget, CDAr2 and 13606 have been around for 15y, and ADL could have been used to do just this. And CDA and 13505 are de jure standards so loved by governments. And yet there is no clinical model of note repository based on either - maybe Spain's 13606 model repository qualifies, but no-one uses it to represent clinical data beyond the Spanish national summary record. There are also no reference archetypes beyond a few obscure places. [quote="erik.sundvall, post:6, topic:1645"] [quote="thomas.beale, post:5, topic:1645"] Of course the trick is to know where to stop. [/quote] Yes. And the more classes and the more detail, the larger risk of frequent RM changes. (Something we want to avoid, and that gives openEHR system implementers the creeps.) [/quote] Well - but we do avoid it. We did pretty well with the openEHR RM. It changes very infrequently, and only via addition - as intended. Don't forget, nothing changed between 2008 (1.0.2) and 2015 (1.0.3) - that's a demonstration of stability I would say... [quote="erik.sundvall, post:6, topic:1645"] No matter wich way we’d go I believe it would be good to from the beginning actually also have a **generic** entity of some kind available to use in a registry, similar to [GENERIC_ENTRY](https://specifications.openehr.org/releases/RM/latest/integration.html#_overview) [/quote] All that is needed to achieve that is to create a GENERIC_ENTITY child of ENTITY, so that instances of it can be created in software, DBs etc. But there's no real point to doing that - whatever entity you concretely want to represent it will be (in reality) a device, consumable object, some aggregate of those, or else some variety of place (if it's something else, we will need to add it). So you can just build an archetype of whichever type you want, say DEVICE, and then ignore any inherited relationships and optional attributes, and just model everything in `details`. Then you have at least instances of DEVICE, PLACE etc, which is a great help in tooling data and many other places. [quote="erik.sundvall, post:6, topic:1645"] Example: let’s assume that you for some reason need to represent a [FHIR Invoice](https://www.hl7.org/fhir/invoice.html) in your registry and associate+store it with some other “properly” RM-modelled entity in your registry. Then it would be nice to be able to just use a generic entity and make a suitable archetype for that integration purpose. [/quote] Well if we were in the business of managing financial entities like invoices, I'd suggest an ENTITY descendant class for that, and the contents will just be `details: ITEM_STRUCTURE`... so it's pretty generic! We can easily enable concrete instances of ENTITY as well, if it makes people happy. With freedom comes responsibility however, and all the evidence points to most sites/projects creating either a mess, or a new definitional silo that won't talk to any other community's data - i.e. what most of the world is trying to escape today... --- ## Post #8 by @thomas.beale [quote="erik.sundvall, post:6, topic:1645"] Yes. And the more classes and the more detail, the larger risk of frequent RM changes. (Something we want to avoid, and that gives openEHR system implementers the creeps.) [/quote] One other comment on that - the FHIR resources have many more data points than the openEHR reference model (i.e. classes x properties). Seems the world is fine with complex models. Maybe they have to be part of a wave of hype... --- ## Post #9 by @sebastian.iancu [quote="thomas.beale, post:4, topic:1645, full:true"] [quote="erik.sundvall, post:2, topic:1645"] then perhaps we could prefix the new REST services …/registry/… instead of …/demographic/…? [/quote] This is probably a good idea. [/quote] IMO "registry" implies a kind of passive-store (i.e. auxiliary, only for registration of things/facts that already happend), often used or useful for the financial subdomain. In reality these concepts could be used for a lot of other use-cases, playing a more active role in application functionality (i.e. it is used to represents things that can or will be used, by actors that will be using them - think of in terms of resources, instructions, tasks), thus "registry" might not be representative. I would rather fancy a name like "entities" (like you had on UML) - although that's not in line with names of the other REST endpoints. Can you relate to this? Can we find a better name then "registry" ? --- ## Post #10 by @sebastian.iancu [quote="erik.sundvall, post:6, topic:1645"] Some of the obvious drawbacks is that you in practice just get yet another layer of modeling and make software/database optimization at class level for such design patterns harder than if it was in the RM. [/quote] Perhaps as architect/modeler we'll like to keep it a bit abstract or simple, but as implementer I would rather be concerned about having too many abstract things, no clear specifications, or too much freedom - then you easily end-up of customizations, and low interoperability on service level. So my preference goes towards more concrete classes. --- ## Post #11 by @erik.sundvall [quote="sebastian.iancu, post:9, topic:1645"] IMO “registry” implies a kind of passive-store (i.e. auxiliary, only for registration of things/facts that already happend) [/quote] @sebastian.iancu I am not a native English speaker and don't have strong opinions regarding the name of the class used for accessing the "collection of entities", so **other name suggestions are welcome**. In the slack-discussion I started by calling it CATALOG (likley influenced by the Swedish word "Katalog", often used for looking up people, metadata etc.), in that discussion @thomas.beale thought "registry" would be a more proper English name. A bit like the "Computing" section of https://en.wikipedia.org/wiki/Registry (Not the "cancer registry" kind of registry.) It's intended for crosslinking and live lookup/query of patients, staff, devices, places etc. often used in the core of EHR and task planning applications. I think it could be used to access storage (or caches/facades to external services) of the things I below have circled with yellow highlighter in a picture from the [Catalan presentation at the HiGHmed symposium](https://www.highmed-symposium.de/#folien) by @jpieraj (Plus devices etc.) Being able to reuse openEHR's archetyping, versioning and mulitlingual capabilities for this would be great both for greenfield applications and when piece by piece replacing/reducing a myriad of (often less flexible) legacy systems for similar purposes. ![image|690x468](upload://te77bXwnIzAO1VzairAgQrDPu8D.jpeg) --- ## Post #12 by @thomas.beale I wouldn't get too hung up on terms for now. Even in English it's somewhat cultural... * 'registry' = a place to catalogue (see what I did there) identified things / people you want to keep track of; commonly used by governments & large orgs for demographics, facilities etc * 'reference data' - oldish term for anything that looks like reference information, e.g. units of measurement, type definitions (e.g. of insurance plans); used to cover what we now call 'terminology' * 'master patient index' (MPI) or 'patient master index' (PMI); same as registry but usually for a single provider organisation; and the 'P' often now called 'Person' or 'Party'. For a catalogue of facilities, wards, beds, and other resources, probably the word in deployment would not be 'registry' - in fact, 'catalogue' (US = catalog) might be a good name for that. But in the model it's all the same. In fact, I'll go back on my initial reaction - 'catalogue' might not be a bad idea, since it's kind of neutral and isn't used for this purpose in industry. So @erik.sundvall 's first idea may be the best. --- ## Post #13 by @borut.jures [quote="thomas.beale, post:12, topic:1645"] ‘catalogue’ might not be a bad idea, since it’s kind of neutral [/quote] As long as the US doesn't start using openEHR and requesting 'catalog' :wink: [quote="thomas.beale, post:12, topic:1645"] ‘catalogue’ (US = catalog) [/quote] Naming is difficult. --- ## Post #14 by @sebastian.iancu [quote="erik.sundvall, post:11, topic:1645"] @sebastian.iancu I am not a native English speaker and don’t have strong opinions regarding the name of the class used for accessing the “collection of entities”, so **other name suggestions are welcome**. In the slack-discussion I started by calling it CATALOG (likley influenced by the Swedish word “Katalog”, often used for looking up people, metadata etc.), in that discussion @thomas.beale thought “registry” would be a more proper English name. [/quote] I'm am also a non-native English speaker, in general I would trust more others nuances and option on this wording of thigs. I just expressed my first impression when i see this word - what the "registry" seems to be used in general., also checked also etymology as a 2nd opinion. In any case, if there is no better name, then I can also accept this. --- ## Post #15 by @thomas.beale [quote="borut.jures, post:13, topic:1645"] As long as the US doesn’t start using openEHR and requesting ‘catalog’ [/quote] Oh we would go with 'catalog', just to keep everyone happy. --- ## Post #16 by @joostholslag [quote="thomas.beale, post:1, topic:1645"] ACCOUNTABILITY [/quote] (Without having read the entire thread, please forgive me) I don’t like the accountability is a separate attribute. Because I think it’s just a particular type of relation. A doctor is primarily accountable to the patient, emotionally and medico legally. And he is also accountable to his employer organisation (depending on country/setting he often owns and manages that organisation). The organisation also has an accountability relation to the patient as well, from medical and civil law. And the organisation has a accountability (?maybe a subtly different word) to regulatory bodies. And the organisation is also accountable to the individual doctor, to enable him to provide better care. All these relations are complex, so I think we should maybe model them using relations of different types, of which accountability could be a specified type, and the relationship may be archetypeable. Does this make sense? --- ## Post #17 by @joostholslag [quote="thomas.beale, post:5, topic:1645"] device’ (a thing that is not destroyed in use, and needs to be maintained), ‘consumable’ (a thing that is destroyed in use, and thrown away), aggregates of things; [/quote] A consumable device is just a device, right? I would put this difference in the device archetype, not in the spec. --- ## Post #18 by @joostholslag I don’t think an object aggregate is a material entity. I think it’s virtual. But may be linked to a place e.g. a storage facility site with a location. A drawer/cupboard could be another aggregate. And I think it’s a sub location as well as a virtual aggregate of material entities. A box may brake this logic, here the aggregate is actually material, but not a location. Tough stuff. Has this not been solved elsewhere? --- ## Post #19 by @thomas.beale [quote="joostholslag, post:16, topic:1645"] Because I think it’s just a particular type of relation [/quote] Arguably yes, but it's such an important one that is tends to be modelled specifically in IT systems. You can look at references such as Analysis Patterns - Martin Fowler ([PDF](https://docs.google.com/file/d/0BzJHmOQ7hCVxM0otMnE3NU1aRjg/edit?resourcekey=0-1yxLhmG3kF-cWBOYDEwCRg)) , or the [series of books by Len Silverston](https://www.amazon.co.uk/s?k=len+silverston&adgrpid=129442639), which are something like standards in information modelling. Accountability is not some personal idea of mine ;) [quote="joostholslag, post:16, topic:1645"] All these relations are complex, so I think we should maybe model them using relations of different types, of which accountability could be a specified type, and the relationship may be archetypeable. Does this make sense? [/quote] Firstly, only the relationships of interest need to be instantiated; archetyping would be used to state the specific kind of accountability. It should be noted perhaps that accountability relationships, specifically employment or other contractual relationship between a provider and an institution are the main kind of relationship required in FHIR data, because they provide the thread of legal responsibility. [quote="joostholslag, post:17, topic:1645"] A consumable device is just a device, right? [/quote] Not generally in the practical sense that e-health standards people use. A 'device' is some sort of machine that has a function and can be used to perform some action on/with patients, e.g. a BP measuring device, ultrasound machine, embedded heart rate monitor. A 'consumable' (could be named differently) is things like bandages, catheters, anything that is used and what remains discarded. In cost tracking in e-health, devices and consumables fall under different models: buy and maintain, and buy for use and discard. So the former is part of an organisations capital investment & permanent facility, while the latter is consumable per-use, and will be charged that way. Only the former potentially has to be 'booked' for use, e.g. MRI or ultrasound; the latter are prescribed or included in orders. So they work differently in a planning model (like Task Planning or BPM+). Obviously people could get into all kinds of arguments about whether something like a Covid19 lateral flow test is a 'device' or a 'consumable', but for healthcare resource planning and accounting purposes, it's a consumable. BTW, this distinction is the same as generally used in HL7, including FHIR, for the reason that healthcare in the US is very oriented to cost tracking. [quote="joostholslag, post:18, topic:1645"] I don’t think an object aggregate is a material entity. [/quote] Ha - well you are facing off against an army of scientific realist ontologists in that case ([here's a partial list](https://github.com/bfo-ontology/BFO/wiki)). See [p29 of BFO2](https://raw.githubusercontent.com/BFO-ontology/BFO/master/docs/bfo2-reference/BFO2-Reference.pdf) (Basic Formal Ontology 2) - it explains 'object aggregate'. BFO2 is the ontology that forms the basis for important biomedical domain ontologies including [Ontology for General Medical Science (OGMS)](https://bioportal.bioontology.org/ontologies/OGMS), [Ontology for Biomedical Investigations (OBI)](http://obi-ontology.org/), [Information Artefact Ontology (IAO)](http://www.obofoundry.org/ontology/iao.html) and many others (see OBO library). It has also over some years been injected into the top of Snomed to fix its broken upper levels. Here's the IS-A view of BFO2: ![BFO2|690x318](upload://xwPx3iRwu1G5ccpIsN3xZSUIe82.jpeg) Edit: the BFO axiom that connects Object aggregate with Object: Every entity which has a material entity as continuant part is a material entity. [020-002] 'Place' on my model would come under Site, which IS-A Immaterial entity (or indeed, probably better understood as a synonym for Immaterial entity). Facility is understood as a Site with a real world address (e.g. OR 8, floor 5, Building 2, St Marys Hospital, Rochester, ...), which could also be bfo:Site or bfo:0-D continuant fiat boundary. (There are debates about this even in BFO-land, but both are Immaterial entities.) If we wanted to literally represent the buildings and rooms made of bricks and steel and glass, we would need to consider those Material Entities, but that's not our interest in HIT generally, whereas material parthood is our interest when it comes to the human organism. This stuff has indeed been solved elsewhere (over some 20 years), and the model I posted is a derivative of that (but still only an initial draft - we should certainly discuss the model, but I don't think violating BFO basics is a good idea). You will notice that even in the BFO2 doc, the concepts of Site and the various immaterial regions and boundaries are still not considered finished work... but as for all of science, we can only use what we have today ;) --- ## Post #20 by @joostholslag “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. --- ## Post #21 by @thomas.beale 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. --- ## Post #22 by @erik.sundvall [quote="joostholslag, post:20, topic:1645"] ...focus on how we can solve our EHR requirements by playing nice with other standards [/quote] 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: https://www.hl7.org/fhir/administration-module.html --- ## Post #23 by @erik.sundvall [quote="borut.jures, post:13, topic:1645"] Naming is difficult. [/quote] Yes, often harder than technology. [Martin Fowler agrees](https://martinfowler.com/bliki/TwoHardThings.html). 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: | [Meriam-webster](https://www.merriam-webster.com/thesaurus/) | thesaurus.com | ... |---|---|---| | [registry](https://www.merriam-webster.com/thesaurus/registry) | [registry](https://www.thesaurus.com/browse/registry) | | [catalog(ue)](https://www.merriam-webster.com/thesaurus/catalog) | [catalog](https://www.thesaurus.com/browse/catalog) | [collection](https://www.merriam-webster.com/thesaurus/collection) | [collection](https://www.thesaurus.com/browse/collection) | | [repository](https://www.merriam-webster.com/thesaurus/repository) | [repository](https://www.thesaurus.com/browse/repository) | | ... Edit: added "repository" to table after suggestion by @borut.jures 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. --- ## Post #24 by @Dileep_V_S 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](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. regards --- ## Post #25 by @borut.jures Should we add **repository** as a candidate? It is so generic it can include anything. repository: - a place where or receptacle in which things are or may be stored - computing: a central location in which data is stored and managed --- ## Post #26 by @thomas.beale 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`. ![demographic2-2021-11-15|690x301](upload://sVtPIOTTUB32Gdiyx0FZChr27tT.png) 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. --- ## Post #27 by @erik.sundvall 1. 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. 2. @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](https://specifications.openehr.org/releases/RM/Release-1.1.0/integration.html#_overview), 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. 3. 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](https://specifications.openehr.org/releases/PROC/latest/task_planning.html)? --- ## Post #28 by @thomas.beale [quote="erik.sundvall, post:27, topic:1645"] 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.) [/quote] 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: ![IAO-document|373x360](upload://2ylKTxqW3vWtKoUIxw5cdSFFtHk.png) 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. --- ## Post #29 by @thomas.beale Here's the other variant: ![Entity-generic_entity|690x264](upload://wILDcuGTSxcnqrGzGDVR4IVYpmE.png) --- ## Post #30 by @Colin_Sutton 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. Regards, Colin --- ## Post #31 by @thomas.beale 'Repository' is certainly another possibility for the concept we have here. For the second point, I think you are arguing for this: ![device-use|426x283](upload://6BTaXQbHVOwCjswOZBJx4ieixDy.png) 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... --- ## Post #32 by @sebastian.iancu 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'? --- ## Post #33 by @erik.sundvall [quote="thomas.beale, post:31, topic:1645"] USE_MODEL is either SERVICE_USE or DISPOSABLE_USE [/quote] So in the multi-patient genomic sequencer batch run [mentioned in #3 above](https://discourse.openehr.org/t/demographic-model-improvements/1645/27?u=erik.sundvall), 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](https://ckm.openehr.org/ckm/archetypes/1013.1.4256) possibly ehanced with LINKs to the actual instances in the REGISTRY as described above. [quote="thomas.beale, post:28, topic:1645"] GENERIC_ENTITY [...] 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). [/quote] 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://www.ontobee.org/ontology/IAO?iri=http://purl.obolibrary.org/obo/IAO_0000310) (`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](https://ckm.openehr.org/ckm/archetypes/1013.1.17) archetype could be used to fill the 'details' ITEM_STRUCTURE --- ## Post #34 by @thomas.beale [quote="erik.sundvall, post:33, topic:1645"] So in the multi-patient genomic sequencer batch run [mentioned in #3 above](https://discourse.openehr.org/t/demographic-model-improvements/1645/27), 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? [/quote] Based on that description, yes to both, in my view. [quote="erik.sundvall, post:33, topic:1645"] 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? [/quote] 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. [quote="erik.sundvall, post:33, topic:1645"] 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://www.ontobee.org/ontology/IAO?iri=http://purl.obolibrary.org/obo/IAO_0000310) (`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 [/quote] 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 ;) --- ## Post #35 by @thomas.beale 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. Anyway, here is the current state of the model. ![Demographic_entity|690x324](upload://cCzOhIkdpvNPTBU20c2NFqnuFG7.png) --- ## Post #36 by @erik.sundvall I have now updated the wiki page https://openehr.atlassian.net/wiki/spaces/spec/pages/786956289/DV+EHR+URI+related+issues to reflect the "registry" name change suggestion from this thread. (In prepararation for a URN namespace-application.) --- ## Post #37 by @thomas.beale This model has been improved, and is [now published here](https://specifications.openehr.org/releases/UML/latest/index.html#Diagrams___19_0_3_8fe028d_1648920292880_630012_5562) (entities) and [here](https://specifications.openehr.org/releases/UML/latest/index.html#Diagrams___19_0_3_8fe028d_1623942831722_493357_5754) (parties). It has been oriented more closely to [BFO](https://specifications.openehr.org/releases/UML/latest/index.html#Diagrams___19_0_3_8fe028d_1652093019886_864595_5188), and documented as such. I will keep developing this, referring to BFO, and also the FHIR Admin and OMG Party models. Possibly interesting for @sebastian.iancu , @erik.sundvall at least. --- ## Post #38 by @sebastian.iancu 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. --- ## Post #39 by @thomas.beale [quote="sebastian.iancu, post:38, topic:1645"] I see a lot of breaking changes introduced on parties [/quote] 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. [quote="sebastian.iancu, post:38, topic:1645"] these changes is now going to brings us much closer to FHIR [/quote] They might - I still have to do a new analysis on the details. The class naming is more from BFO. [quote="sebastian.iancu, post:38, topic:1645"] rationale behind FACILITY [/quote] 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). [quote="sebastian.iancu, post:38, topic:1645"] I want to take the opportunity to say it again the current RM.Demographic is quite reach and workable already [/quote] 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. --- ## Post #40 by @erik.sundvall @thomas.beale I believe you mentioned in another context that Graphite has looked further into things discussed here and prehaps implemented it (or parts of it) too. Could you briefly share current status and what things you learnt in the process. Background: During the recent HiGHmed symposium some participants showed an interest in covering more than pure EHR content using the multilevel technology approach of openEHR. (And at Karolinska Univeristy Hospital we would also be interested in that in order to replace some old systems and also in order to build some new systems/functions related to supporting e.g. precision medicine.) --- ## Post #41 by @erik.sundvall Ping @thomas.beale any news on this from e.g. Graphite? After a demo of [openFHIR](https://open-fhir.com/) today I would very much like to have something like the "Registry" (extended from Demographics) in openEHR so that we could properly model and long-time store stuff that is often exchanged using FHIR. An example is stuff in and related to https://build.fhir.org/genomicstudy.html that we want to use and store for Precision Medicine, over time surviving major FHIR version updates and be able to serve both using V4 (using a hack) and V6. Of course some more general graph querying language than AQL would also be needed for Registry - best would be if it could cross-query the EHRs and Registry in the same optimized queries. See hints about AGQL in e.g. https://discourse.openehr.org/t/ehrs-with-different-system-id-in-the-same-server/3535/37?u=erik.sundvall --- ## Post #42 by @thomas.beale I will have something to share imminently. It covers: * physical entities * kinds - e.g. a type of device such as Philips model 700 obstetric ultrasound machine * individuals, e.g. a particular Philips model 700 obstetric ultrasound machine with UDI 1234, currently in maternity department at clinic ABC, with maintenance history etc * resources - uses of things and people * social entities - the usual Party and related entities, plus relationships * assets - ownership / renting etc of things by Parties * registry - as per openEHR The model has a much more fully worked out form of the physical entity category above, plus a lot of improvements over the draft form currently at openEHR. One of the main improvements is the ability to have a 'smart ref' to any kind of Entity, * a) between entities (e.g. parthood) * b) between data and entities, e.g. a ref from a heart rate recording to the device (any of: category of device, exact device kind (model of machine), or an actual individual device). More soon. --- ## Post #43 by @ian.mcnicoll This may be well off-topic, apologies if so, but we have been working on a Public health use-case, where the top-level object is a 'Case' and not necessarily a person i.e. an EHR object. However in all other respects, so far with the use of Folder and links, the underlying public health documentation documentation works really well with the Folder/Composition/Entry structures. We expect to propose a new top-level object which is pretty well identical to an EHR but does not imply a person. And some documentation e.g Vaccination history is associated with an actual EHR but linked to a Case. We think it is important to clearly distinguish this from an actual person, but we suspect that there could be wider uses than just Public health Case, so we would probably suggest making it a bit more abstract. I raise it here in case some of this overlaps with Registry ideas but what we are talking here is not reference/registry as such. --- ## Post #44 by @erik.sundvall @ian.mcnicoll I think most (or all?) of what you are describing could be covered by a combination of (a possibly imprived version of) the registry/entity/demographics based approach discussed in this thread combined with som top level "SYSTEM" root object above both the EHR and demographics/registry. (This is something e.g. @sebastian.iancu has pointed out a long time.) I agree that there are many use cases where one would like to use the openEHR approach (archetypes/templates etc) for things that ar not neccesaruily rooted in an individual's EHR. For example cases or samples used in laboratory settings and research. When we build genomic related flows we can use openEHR for referral and response when e.g. bacteria samples come from patients in a suspected food poisioning investigation, but would need to build something totally different, non openEHR-based, for the samples that come from a food samples suspected to be the source. (Same thing with infection control where we want to sequence bacteria/virus swabs from door handles hospital rooms. Such samples are related to patients but not neccesarily 1:1 to a specific patient. It would be nice to be able to treat those things in ways and systems similar to samples from patients and also make cross-cutting queries. Due to archetyping we wouldn't need a huge number of new classes to cover a huge number of use cases... < forward-looking-statement > *...but I do believe we would in the long run benefit from adopting (not reinventing) a more general graph query language. Of course function calls in AQL could cover many recurring "registry/demographic" query use cases and be a bridge to the AQL-world. AQL would likely remain used in many systems for looong time. Implementation-wise under the hood I would expect that some implementors would just use the graph querying language for everything and have a query translator to be able to handle AQL (forever) for suitable use cases.* < /forward-looking-statement > --- ## Post #45 by @ian.mcnicoll > we can use openEHR for referral and response when e.g. bacteria samples come from patients in a suspected food poisoning investigation, but would need to build something totally different, non openEHR-based, for the samples that come from a food samples suspected to be the source. That is exactly one of the use cases in scope for us and we are fairly confident that much of the 'working documentation' can be handled within the existing EHR RM, as long as we have a new top-level container which is clearly represents a 'case' or other non-patient collection of compositions. --- ## Post #46 by @thomas.beale [quote="ian.mcnicoll, post:43, topic:1645"] We expect to propose a new top-level object which is pretty well identical to an EHR but does not imply a person. [/quote] Most likely a good idea. Can we assume that the kind of 'case' you are thinking of here corresponds to an 'outbreak' (or suspected outbreak)? For such things the information added (initially at least) will be reports of certain kinds of infection. possibly connected to identified individuals, possibly just aggregated reports from a clinic (i.e. numbers of individuals with xyz symptom). One interesting question is what constitutes a new case? Are 2 x MRSA +ve at the same clinic one case or two? Are all new Covid cases in a particular town one case or more? In my understanding, the general idea is usually to make a case = some independent event, e.g. a patient zero creating infection in some geography, or @erik.sundvall 's example of (say) Listeria emanating from some product delivered by a certain local processing location / factory. Another thing to consider is what kind of assessments (Evaluation) and Orders (Instruction) are likely? Likely to include PH reporting actions, among others. It will be interesting to see if there are any new needs in RM OBSERVATION, INSTRUCTION, ACTION. [quote="erik.sundvall, post:44, topic:1645"] < forward-looking-statement > *…but I do believe we would in the long run benefit from adopting (not reinventing) a more general graph query language. Of course function calls in AQL could cover many recurring “registry/demographic” query use cases and be a bridge to the AQL-world. AQL would likely remain used in many systems for looong time. Implementation-wise under the hood I would expect that some implementors would just use the graph querying language for everything and have a query translator to be able to handle AQL (forever) for suitable use cases.* < /forward-looking-statement > [/quote] We've been using GraphQL at Graphite. It definitely has limitations. For one thing, you can't write a GraphQL query that has a WHERE clause equivalent containing anything other than the AND logical operator. To express a WHERE clause with ORed conditions, you need separate copies of the query, each with one of the conditions modelled in it. --- ## Post #47 by @ian.mcnicoll [quote="thomas.beale, post:46, topic:1645"] Can we assume that the kind of ‘case’ you are thinking of here corresponds to an ‘outbreak’ (or suspected outbreak)? [/quote] This is exactly the space we are in, and not just infectious disease, other public health situations like environmental incidents, radiation scares, legionalla detected in air-con unit etc. So there may be no human individuals at all, or indeed there may be multiple individual persons associated with a case which then may transform into a cluster or outbreak. So far, as long as we can introduce that top-level idea of a 'case' rather than an EHR, the standard RM classes have worked fine, though. Definitely some new archetypes or modifications of the work done by @KBarwise and @heather.leslie. [quote="thomas.beale, post:46, topic:1645"] One interesting question is what constitutes a new case? Are 2 x MRSA +ve at the same clinic one case or two? Are all new Covid cases in a particular town one case or more? [/quote] That seems to be a slightly grey area, as of course it may not be immediately apparent that 2 human cases are associated. Discussed this week but we anticipate multiple 'human cases' to need to be handled under a single public health case, and will probably use folders to associate the various lab reports, interviews etc associated with the human case. --- ## Post #48 by @erik.sundvall [quote="thomas.beale, post:46, topic:1645"] using GraphQL at Graphite. It definitely has limitations. For one thing, you can’t write a GraphQL query that has a WHERE clause equivalent containing anything other than the AND logical operator. [/quote] @thomas.beale, has Graphite investigetad if GQL (or Neo4J's related [Cypher](https://neo4j.com/product/cypher-graph-query-language/)) has the same limitations? It seems to be partly another kind of tool/language. See GQL links in e.g. https://discourse.openehr.org/t/ehrs-with-different-system-id-in-the-same-server/3535/37?u=erik.sundvall (Adding syntactic sugar shortcuts to GQL like AQL did to Xpaths would create what I tentatively would call AGQL :slight_smile: *- see Update March 31 below*) *[**Update March 20:** I found these two sources informative and full of context regarding GQL, Cypher and the standardisation process* *[GQL: The ISO standard for graphs has arrived | AWS Database Blog](https://aws.amazon.com/blogs/database/gql-the-iso-standard-for-graphs-has-arrived/) ...and... [Introduction to Graph Query Languages. From SPARQL to Gremlin.](https://graph.build/resources/graph-query-languages)]* *[**Update March 31:** Adding text for context from a previous not openly available post: GQL ([Graph Query Language - Wikipedia](https://en.wikipedia.org/wiki/Graph_Query_Language)) seems to finally have been made a standard now. If it is/becomes well supported by graph databases, then I was thinkning that perhaps some Archetype-based syntactic sugar on top of GQL (could be called AGQL) and simple preporocessing/translation of the query might do the trick without us having to reeinvent any new wheel or stretch AQL’s tree-focused view too far. With syntactic sugar I mean simplifications like AQL paths have done to xPath in the form of `.../attributename[at0123]/...`]* Sorry for going off topic. --- **Canonical:** https://discourse.openehr.org/t/demographic-model-improvements/1645 **Original content:** https://discourse.openehr.org/t/demographic-model-improvements/1645