Demographic model improvements

Specifications Entity/demographics
1

A long-term limitation of the openEHR demographic model 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
demographic_acc1072×431 48 KB

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.

3 Likes
2

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

@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 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 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
image1076×544 54.2 KB

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?

1 Like
3

Here is the ENTITY hierarchy in this very rough initial version.

entity-demographic
entity-demographic776×394 30.4 KB

The abstract types are based on BFO; 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
image469×618 10.1 KB

4

This is probably a good idea.

5

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.

1 Like
6

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

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

1 Like
7

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.

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…

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.

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…

8

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…

9

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” ?

10

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.

2 Likes
11

@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 Registry - Wikipedia (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 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
image1210×822 90.9 KB

1 Like
12

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.

13

As long as the US doesn’t start using openEHR and requesting ‘catalog’ :wink:

Naming is difficult.

2 Likes
14

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.

15

Oh we would go with ‘catalog’, just to keep everyone happy.

16

(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?

17

A consumable device is just a device, right? I would put this difference in the device archetype, not in the spec.

18

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?

19

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) , or the series of books by Len Silverston, which are something like standards in information modelling. Accountability is not some personal idea of mine :wink:

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.

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.

Ha - well you are facing off against an army of scientific realist ontologists in that case (here’s a partial list). See p29 of BFO2 (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), Ontology for Biomedical Investigations (OBI), Information Artefact Ontology (IAO) 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
BFO21230×568 117 KB

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

1 Like
20

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