FHIR Chat · Participation Heirarchy · methodology

Stream: methodology

Topic: Participation Heirarchy

Grahame Grieve (Oct 29 2019 at 22:20):

This topic is a continuation of the thread around participation heirarchy: https://chat.fhir.org/#narrow/stream/179166-implementers/topic/Pattern.20Development

There are still implementers out there who think that we need / should have a deeper heirarchy for the participation resources. Where as right now they all have the same common ancestor DomainResource.

The relevant resources are CareTeam, Device, Group, HealthcareService, Location, Organization, Patient, Practitioner, PractitionerRole, RelatedPerson

And see the participation pattern at http://build.fhir.org/participant.html.

Lloyd McKenzie (Oct 30 2019 at 02:15):

Have those implementers submitted change requests providing their rationale? I've heard this proposed by modelers, but can't recall having heard it from implementers

Grahame Grieve (Oct 30 2019 at 03:17):

it's kind of hard to submit something so sweeping as this as a change proposal. The consequences of it would be

Thomas Beale (Nov 11 2019 at 11:11):

For reference, this is the example proposal I was referring to in the Atlanta meeting: https://wolandscat.net/2019/09/11/fixes-for-fhir-the-admin-resources/

Grahame Grieve (Nov 11 2019 at 11:55):

Can you make a smaller proposal? I look at that one, and it's hard to process because so much is different, including underlying requirements. So it's not really applicable...

Thomas Beale (Nov 11 2019 at 21:14):

Well it's a systemic fix, so it all goes together. There are smaller things you could do though to initially clean things up a bit:

• get Device sorted out; the kind of 'Device' being referred to where parties are needed is something like 'AutonomousAgent' or whatever you want to call it; it doesn't include bandages, test tubes, or even PET machines.
• get rid of PractionerRole. Move all the employment-related attributes to a sub-resource called Employement or similar, and then add something like posts: Employment[*] to Practitioner.
• figure out what Substance, Location and Medication (I think) are doing in type lists that should be limited to some kind of Party or Participation. E.g. Contract.term.action.performer.
• figure out what FHIR really means by Group.

Fix that and numerous Resource choice type lists will reduce and the entries on the patterns page will reduce somewhat.

After that, I would start looking at setting up Party, Actor, Role and PartyRelationship, with Actor and Role being descendants of Party, and these three having roughly the definitions I have provided.

Thomas Beale (Nov 11 2019 at 21:27):

I don't think there are any differences in underlying requirements; I just refactored the existing DSTU4 to an orthodox model of Parties that would simplify and clarify a lot of things elsewhere in the model, as well as in downstream implem contexts.

Grahame Grieve (Nov 11 2019 at 22:09):

Do you know why we have both PractitionerRole and Practitioner?

Thomas Beale (Nov 11 2019 at 22:49):

I can only infer what I read in the documentation. It is either (or both of): a practitioner in an employment (post) and/or the definition of such a post (i..e something fillable by a real person). It is not clear. In my analysis, I assumed the first. If it is the second, I will change the model proposal a bit.

Lloyd McKenzie (Nov 12 2019 at 01:38):

PractitionerRole is to capture someone acting professionally on behalf of an organization. This is typically due to an employment relationship, but not necessarily. Also, the role indicates their functional role, not their employment relationship. The former indicates professional responsibilities/capabilities. The latter typically indicates things like pay-band. (We don't do a great job of tracking employment-type information at the moment - for patients or Practitioners because FHIR isn't generally used for HR purposes and the most common use-cases for tracking patient employment are covered by Coverage (i.e. insurance).

Grahame Grieve (Nov 12 2019 at 02:05):

@Brian Postlethwaite @Cooper Thompson Alerting you to this conversation

Grahame Grieve (Nov 12 2019 at 02:09):

my take on it is that we need to able to refer to people playing roles at multiple levels of specificity

• this action was/must be done by a [particular class] of person (by qualification)
• this action was/must be done by a person who is playing a particular role for some organization (e.g. Admitting officer)
• this action was/must be done by a person playing a particular role for a particular organization
• this action was/must be done by a particular person playing a particular role for a particular organization
• this action was/must be done by a particular person (but we say nothing about the organization, even if the concept is actually applicable)

Grahame Grieve (Nov 12 2019 at 02:09):

is that the case?

Lloyd McKenzie (Nov 12 2019 at 02:52):

Right. All of those are currently covered by PractitionerRole with the exception of the last, which can just be Practitioner. (As well we have RelatedPerson which deals with activity by someone based on their personal relationship with the Patient rather than their profession.)

Also note that Practitioner covers all people acting in their professional capacity - so not just clinicians but also contracted cab drivers, receptionists, etc.

Thomas Beale (Nov 12 2019 at 11:11):

In response to @Grahame Grieve , although I don't doubt that all of those needs will apply in some place, some context, some time, building in such tight constraints at the level of the base resources is not likely to be a good idea. The world is far more unpredictable, especially in HR, and what appeared to be specifiable as an org role today will be specifiable only via a certified capability next month, and something else later on.

If the Resource model is viewed as a wide _possibility space_, not a narrow constraint space, things are likely to be easier to manage. Use the profiles to get use-case specific constraining.

Anyway, in terms of a substantive modelling approach to solve this problem more generally, the Party/Actor/Role pattern would take care of it, and any similar kind of situation. This allows a given kind of professional who has his/her own certifications/qualifications (independent of job) to be an Actor, and then to serve in as many Roles as you like. The roles may be specified in terms of certification needs or any other requirement. Trying to do Grahame's list without this just looks painful to me (and the patterns page shows that it is).

On the question of whether a 'Practitioner' can be a cab driver, that will come as news to pretty much everyone in healthcare. I think trying to be over-general like this confounds the natural assumption that any 'Practitioner' specified in a FHIR resource will be a professional competent for that part of the healthcare provision. Cab drivers and receptionists don't really come into it. Where a model category breaks a universal or near-universal understanding of what is contained in the category of that name, trouble is likely to follow...

Lloyd McKenzie (Nov 12 2019 at 14:20):

@Thomas Beale It turns out that the places where models need to be able to point to healthcare practitioners, they also need to be able to point to cab drivers & receptionists. They too can be authors, performers, witnesses, etc. They are acting on behalf of specified organizations. They can have training/certifications. They can have contact information. And they tend to be managed in the same back-end systems. If the systems don't disambiguate, the data elements are essentially the same, and the need to reference the resources occurs in the same place, it doesn't make sense to try to draw a dividing line that splits the concept into distinct resources. Systems can (and do) put limitations on what actions are allowed to be taken based on qualifications. A taxi driver can't generally perform an appendectomy, but a chief of surgery can't generally drive a patient from one hospital to another either. A receptionist may well have training as a nurse, but their functional role (and the permissions that stem from it) remains receptionist. Healthcare workers can be seen on a continuum that ranges from extremely healthcare-specific (physician/pharmacist to more ancillary (psychologist/social worker) to administrative (receptionist/taxi driver). There are no clear dividing lines. (Social workers and taxi drivers are both licensed, and neither are licensed by 'healthcare' governing bodies.)

One of the challenges with the Party/Actor/Role paradigm (similar to the RIM's Entity/Participation/Role model, I think?) is that it's more abstract than existing systems work. We need to represent the data at a granularity that is straight-forward to both expose and capture for existing systems. We can't expect the internal persistence layers, maintenance screens, etc. of existing systems to change much, if at all, as part of the adoption of FHIR. As such, the boundaries of our resources need to align relatively well with how data is stored and exposed by most systems. (Obviously there will always be exceptions that do things differently and that may find FHIR adoption more of a struggle.)

Note that I'm not arguing against refactoring - I'm not thrilled with the Practitioner/PractitionerRole split. I'm just highlighting some of the things we need to think about as part of the refactoring.

Thomas Beale (Nov 12 2019 at 14:49):

@Lloyd McKenzie I'm not really arguing against anything in your first para. I'm just saying that if you name a category 'Practitioner', you set an expectation for the definition of that category; but if you then include in its extension people who are clearly not 'practitioners' in any normal healthcare sense, it will lead to confusion. Not saying you don't need to represent the work / engagements / whatever of receptionists/ drivers etc, just that you need to have a better name for that overall category. In the model I proposed, Practitioner is a subtype of PersonRole, which is a subtype of Role, as follows:
pasted image

We could make this a bit more precise, with a ProfessionalRole subtype of PersonRole, and then Practitioner and (let's just say for now) AlliedProfessional will provide a better categorical distinction.

Lloyd McKenzie (Nov 12 2019 at 15:01):

I'm not opposed to ProfessionalRole (whether we introduce PersonRole or not). It's not clear that "Practitioner" or "AlliedProfessional" would have a lot of value. It's not clear they have distinct elements from ProfessionalRole.

Thomas Beale (Nov 12 2019 at 15:09):

On your second point... that such models are more abstract than existing systems work. Generally speaking, this is likely to be true. But there are two points to consider. Firstly, existing source system data models, however terrible or great, are generally used in a way to try to convey what happened in the real world. In the real world, it is not hard to justify an ontological view that distinguishes 'roles' from 'actors' and so on - indeed, the FHIR documentation is full of just such language, it's just not reflected in the models.

The second point is the existential one I mentioned in Atlanta - is FHIR trying to be about directly reflecting the 'dirty data' of real systems, or about presenting a unified / standardised view of such data to data consumers? If it is the first, it's not going to help, if I am just going to get a copy of the 10 different versions of patient data from 10 different systems. So, it's not really just presenting dirty data, it is normalising it. The real question is: how much? I am arguing that if I, on the receiver side can't even run a query to obtain all 'roles', or to distinguish actors from roles, or to do some basic processing on all parties, then it's not helping much.

Nevertheless, your next statements are obviously correct. So, what is really needed is two layers in the FHIR Resources:

• layer 1 does reflect existing systems' data sort of faithfully, i.e. provides no semantic normalisation, but does impose the FHIR standard URIs, REST model, terminology referencing, identifiers, base data types and so on; this layer could well have client applications wanting to access the 'real data' in their environments, just in a technical standardised manner;
• layer two performs a semantic normalisation from layer 1, and can therefore introduce generalisations such as I propose in the Admin types, as well as (say) an abstract notion of Request as a parent of the *Request Resources. Clients of this layer don't care that much about the horrors that lie behind, they want to get a normalised picture across systems in their environment.

You can't really satisfy both needs with one layer of Resources. This is a major source of confusion in FHIR (I don't make that statement casually, or to denigrate anyone - this problem is an existential confusion for everyone in e-health, all the time).

Incidentally, the approach above is not much different from what I proposed 4 years ago in this post - https://wolandscat.net/2015/12/20/making-fhir-work-for-everybody/

I would argue that making this distinction explicit in FHIR would greatly clarify and improve FHIR resource development.

Lloyd McKenzie (Nov 12 2019 at 15:42):

FHIR is about providing a standardized representation of healthcare data that requires a "minimal lift" from the dirty data of existing systems. If we require a massive refactoring of how systems currently store and process data in order to use FHIR, they simply won't use FHIR. Doing things like "querying all roles for an actor" will only function if systems have that capability in their databases and how they capture data. If the system has no clue that Dr. Smith and Patient Smith are the same individual, separating the 'Smith' from the 'Dr.' and 'Patient' role won't make any difference - the underlying systems will still have separate records for the two and maintain distinct demographics for the two. The purpose of introducing the standard isn't to cause systems to support new types of queries from what they've historically been able to do, it's to let them expose the data they do have in a standard way and allow it to be queried in a standard way. Once we've got that, systems may (and hopefully will) expand their capabilities in incremental ways based on the needs of their stakeholders.

We introduced the Person resource to provide a linking mechanism for the relatively small proportion of systems that have that capability today - i.e. that maintain shared demographics across roles. However, even then, there can be demographics that are role-specific (phone numbers used only in the "Dr." role, addresses used only in the "Patient" role). It's even possible (though not common) for administrative genders to be distinct. So it turns out that having almost the full set of 'Person' information on Patient and Practitioner is useful.

I'm not totally clear on the purpose of the second layer you propose. We do map all resource elements to the HL7 reference model (at least where they fall within the scope of that reference model - some such as CodeSystem, StructureDefinition, etc. do not). We also define patterns which could theoretically be used to expose the 'technical' resources in more abstract ways for those who happen to need/want that. (So far we haven't done much in this space because not a lot of implementers have been asking for it - the strongest demand has typically been coming from the clinical decision support space, but there's a trade-off between more abstract vs. more representative of what data is likely to exist. As an example, an abstract model could expose a start date and an end date for an immunization, but the reality is that they'll always be the same.

Grahame Grieve (Nov 12 2019 at 20:23):

All of those are currently covered by PractitionerRole with the exception of the last

So I don't see the value of Practitioner if that's the case. Why split one use case out? What's different to having just a PractitionerRole without a scoping organization?

Lloyd McKenzie (Nov 12 2019 at 21:05):

The split of Practitioner from PractitionerRole is driven by the registry use-cases. We used to just have one resource. But the registries apparently handle "individual with training" separately from "individual working for hospital X in role Y". @Brian Postlethwaite, can you flesh out my generalizations with some reality? :)

Grahame Grieve (Nov 12 2019 at 21:07):

that would very much be the tail wagging the dog when we could also handle that with an element

Lloyd McKenzie (Nov 12 2019 at 21:09):

Registries have been the major driver of the resources within PA, not their re-use in the systems that reference them. It's more of a two-headed dog and different people want to pet different ends...

Thomas Beale (Nov 12 2019 at 21:09):

Which registries? They are different in every country I have worked in. Also, an 'individual working at X in role Y' will clearly have (the possibility of) training; the work roles are contingent facts, i.e. 0..*. So I would draw the same conclusion as @Grahame Grieve in this case.

Lloyd McKenzie (Nov 12 2019 at 21:09):

(that was a rather awkward analogy... sorry :>)

Brian Postlethwaite (Nov 12 2019 at 21:28):

The original model from dstu1 had a single role on the practitioner, so would have required multiple practitioner resources to represent the multiple things they do. Then dstu2 did cater for the multiple roles via a 0..* cardinality, but then when referenced by other things which role actually applied. Then PracRole was included.
This isn't just a registry thing, it's just something that is handled poorly.
I'm sure none of us deny that it's the reality of the real world that people do different things at different places. Some areas do this more than others, many specialists work at multiple offices routinely on specific days of the week, and in the regional areas often do travel between centres to provide care, but not each of the sites have the same facilities, so their ability to do things changes, or it's just not required at each place.
The model as it is now reflects both usages, and in the clinical space has the option of role/prac to cover both types of systems.

Brian Postlethwaite (Nov 12 2019 at 21:29):

Registries are just a space where the problem gets moved to and uncovered more quickly/obviously.

Thomas Beale (Nov 12 2019 at 21:29):

I am going to assume that there just might be a solution that crunches Practitioner and PractionerRole together, with a concomitant slight simplification of various choice type lists.

How about passive Device v autonomous Device? I.e. where Device appears in active participation locations, it should be the latter. There are some other inclusions such as Substance, Location etc are doing in places typed as some kind of participation. If it is meant to be resource usage, I would strongly recommend separating out resource usage from active participation wherever that occurs.

Brian Postlethwaite (Nov 12 2019 at 21:30):

Yes, many older systems don't differentiate the roles when associating with an activity, they just assumed it.

Brian Postlethwaite (Nov 12 2019 at 21:32):

I didn't follow the notes on device.

Thomas Beale (Nov 12 2019 at 21:33):

@Brian Postlethwaite well I go back to my previous recommendation, distinguishing Role from Actor, as sub-types of Party. Then you can have as many ProfessionalRoles of a Person (who happens to be a qualified GP or whatever) as you like, and whichever applies at some location, that's the one(s) that are referenced in the relevant Resource.

Brian Postlethwaite (Nov 12 2019 at 21:37):

Which is the distinction we have with Prac and PracRole. And but also have the capacity to skip PracRole where not used by a system.

Lloyd McKenzie (Nov 12 2019 at 21:37):

We don't want a generic "Person" - the provider registry systems that capture things in a 'role-independent' way still care about the individual only in their capacity as someone who can work for an organization to deliver healthcare services. They would not capture information about patients or family relatives, friends, etc. Person is something else entirely. It gets used for those (very sophisticated and somewhat small in number) systems that manage linkages of individuals across roles. What's really happening here is that some systems track providers in terms of their relationships with a single organization and single capacity. Others track a provider and all of (or at least some of) the organizations they work for and the different hats they can wear. When we reference practitioners from other models, we typically need to know both the organization and the hat - though sometimes we don't care and the bare practitioner is fine.

Thomas Beale (Nov 12 2019 at 21:49):

You may want more than one flavour of Person in different situations, but at the Resource level, on the Actor side (not the Role side) you probably do want a fairly generic Person. How it gets profiled for specific uses like registries or anything else is another issue. Treat Resource types as defining a 'possibility space' and Profiles as constraining for specific use cases. That methodology will take things a long way.

Lloyd McKenzie (Nov 12 2019 at 22:44):

We can only want a generic person if systems actually track/capture a generic person - and few systems do.

Grahame Grieve (Nov 12 2019 at 23:03):

MnM propose that we hold a BoF discussion at DevDays on Wed evening about this. It won't be open - if you're interested in this, please let me or Lloyd know

Thomas Beale (Nov 12 2019 at 23:04):

I think we are talking about two different things. I am talking about Person as a kind of Actor subtype Resource that aggregates data items that may apply to natural persons in whatever form they may appear in real systems - whether Patients, Professionals, or someone else. It's not trying to say that any system in which a profiled version of Person appears (usually, along with various Role subtypes) is trying to represent 'generic persons'. This is just modelling.

Grahame Grieve (Nov 12 2019 at 23:04):

@Brian Postlethwaite please join us Wed evening

Lloyd McKenzie (Nov 13 2019 at 00:40):

We don't want to split apart the attributes of Person if systems don't naturally store them separately. The granularity boundaries of what we expose as resources needs to reflect the granularity boundaries of what systems capture as distinct business objects with independent statuses. If systems typically don't store the demo. As an example, systems that manage patients don't generally store the names, addresses, etc. associated with the patient separately from medical record numbers and other patient elements. We can't introduce separate objects for these things in the interface if they don't have separate existences and statuses in the real systems.

Brian Postlethwaite (Nov 13 2019 at 01:16):

I'm not going to DevDays Amsterdam :sad:

Grahame Grieve (Nov 13 2019 at 01:17):

oh. we thought you were

Lloyd McKenzie (Nov 13 2019 at 02:36):

When would be a good time - and what would be a good forum - to have this discussion?

Thomas Beale (Nov 13 2019 at 11:45):

@Lloyd McKenzie well there are EMR systems that have a Patient table that conflates person data with the data of the person-as-patient in a relationship with just that institution. There are others that separate out identifying patient data into org / regional (e.g. state gov) MPI or national registry, and useless meaningless identifiers for the EHR/EMR, and a separate {EMRid, Patient id} table to connect the two. In much of Europe, storing identifying data in the EHR is not legal. Either way, in the overall health system, the general case is that a patient can have multiple 'patient' records and/or one or more 'person' records (here 'person' means something like citizen, or health consumer, depending on who owns the national registry).

While I get the point you are making, this is just about clarity in modelling and software. If people are going to build coherent software dealing with FHIR data, the models need to be somewhat structured and normalised. The model structure I have proposed just separates out person-related data items into a dedicated Resource and reuses that in places like Patient, Practitioner etc. It is not hard to separate Person into something like PublicPerson and PrivatePerson or similar if that were needed to reduce the 'person' data items used by things like Practitioner, RelatedPerson etc.

Lloyd McKenzie (Nov 13 2019 at 13:04):

In our case, 'health consumer' would still be a 'Patient' registry a the purpose is being a potential consumer of healthcare. Person really only comes into play if you're linking to demographics that span Patient/Practitioner/RelatedPerson.

Separating out the demographics into a separate resource for modeling purity imposes costs on implementers and doesn't provide any benefit that we've identified. When a system wants to expose a patient, they want to expose the demographics at the same time as the medical record number, link to the patients primary care provider, etc. All of that information is generally maintained in a single table/set of tables. The demographics for practitioners are maintained somewhere completely different (and often with slightly different rules. E.g. most systems that deal with patients track deceased date, while most systems that deal with practitioners don't.)

We've seen occasional questions about consistency across the demographics exposed by Patient, Patient.contact, Practitioner, RelatedPerson and Person, but very few have had an interest in separating the maintenance of the demographics from the elements of the role - and for those who do have that interest, Person as a linking resource seems to meet the need.

One of the key things with a RESTful interface is that when you query a resource, it needs to be useful on its own. A patient resource that doesn't expose name, gender, date of birth and contact information can't really be useful on its own.

Grahame Grieve (Nov 13 2019 at 22:22):

@Brian Postlethwaite did you agree with my 5 point list:

we need to able to refer to people playing roles at multiple levels of specificity

• this action was/must be done by a [particular class] of person (by qualification)
• this action was/must be done by a person who is playing a particular role for some organization (e.g. Admitting officer)
• this action was/must be done by a person playing a particular role for a particular organization
• this action was/must be done by a particular person playing a particular role for a particular organization
• this action was/must be done by a particular person (but we say nothing about the organization, even if the concept is actually applicable)

And Lloyd's response:

All of those are currently covered by PractitionerRole with the exception of the last, which can just be Practitioner

?

Grahame Grieve (Nov 13 2019 at 22:23):

Separating out the demographics into a separate resource for modeling purity imposes costs on implementers and doesn't provide any benefit that we've identified

Actually, we did identify benefits, and we did have that arrangement at some stage. It was no net benefit, though not everyone was happy.

Grahame Grieve (Nov 13 2019 at 22:25):

A patient resource that doesn't expose name, gender, date of birth

It's structurally possible to define a IdentifyingPersonResource that is an abstract ancestor for Patient, RelatedPerson, Practitioner, and Person. We could discuss the merits of that idea as part of this.

Vassil Peytchev (Nov 13 2019 at 22:37):

"It's structurally possible to define a IdentifyingPersonResource that is an abstract ancestor for Patient, RelatedPerson, Practitioner, and Person. We could discuss the merits of that idea as part of this."

I'd this "abstract ancestor" the same as a logical model?

Grahame Grieve (Nov 13 2019 at 22:59):

no, though the difference between abstract ancestor resources like DomainResource and Logical Models is a little theoretical

Grahame Grieve (Nov 13 2019 at 23:23):

@Thomas Beale

get Device sorted out; the kind of 'Device' being referred to where parties are needed is something like 'AutonomousAgent' or whatever you want to call it; it doesn't include bandages, test tubes, or even PET machines

Can you explore this a little more?

Grahame Grieve (Nov 13 2019 at 23:36):

figure out what Substance, Location and Medication (I think) are doing in type lists that should be limited to some kind of Party or Participation

Substance:

• CatalogEntry.referencedItem - I don't think that's a participation. So out of scope, though I think that list is too short.
• Contract.term.action.performer - I don't see how a substance can perform (or not ) the action
• Specimen.subject: I can understand this when substance refers to a particular package. I think it's appropriate...
• Group.member.entity: I think this should be removed (though CDS wants the list extended not shrunk; this is an ongoing discussion with CDS/MnM)

Medication:

• Group.member.entity: I think this should be removed (though CDS wants the list extended not shrunk; this is an ongoing discussion with CDS/MnM)
• Flag.subject: I've never seen any discussion about Flag on a Medication. This list of things a flag can be about is a weird mix.. @Lloyd McKenzie I guess this comes from you?

Location:

• CatalogEntry.referencedItem - I don't think that's a participation. So out of scope, though I think that list is too short.
• Communication.recipient - I think that makes sense
• Contract.term.action.performer - I don't see how a location can perform (or not ) the action
• (Many).subject - that absolutely makes sense to me
• (Appointment | AppointmentResponse | Schedule).actor - is that valid? @Brian Postlethwaite it doesn't seem natural to call the 'location' and actor in an appointment. can you have more than one location? Why not have a separate field for location like iCal?
• several other uses that make sense to me

Brian Postlethwaite (Nov 13 2019 at 23:46):

we need to able to refer to people playing roles at multiple levels of specificity

• this action was/must be done by a [particular class] of person (by qualification)
• this action was/must be done by a person who is playing a particular role for some organization (e.g. Admitting officer)
• this action was/must be done by a person playing a particular role for a particular organization
• this action was/must be done by a particular person playing a particular role for a particular organization
• this action was/must be done by a particular person (but we say nothing about the organization, even if the concept is actually applicable)
  And Lloyd's response:

  All of those are currently covered by PractitionerRole with the exception of the last, which can just be Practitioner

Not sure I follow the difference between 2 and 3.
To me its just 3: * something to be done by a type/class/role of person (org optional) * something to be done by a specific person in the role (org optional) * something to be done by a specific person (with no other context indicated)
The type/class/role/qualification are all variations that differing systems differentiate in different ways, or don't.
And qualification is actually the least important thing from a data perspective, we care about the role that they have within the system.
The Organization definitely cares, that the practitioner has the qualification, and they'd check that before they allocate them to a specific role, but that may never be recorded.

Grahame Grieve (Nov 13 2019 at 23:48):

• something to be done by a type/class/role of person (org optional)
• something to be done by a specific person in the role (org optional)
• something to be done by a specific person (with no other context indicated)

so PR for 1 and 2 and P for 3?

Thomas Beale (Nov 14 2019 at 00:19):

Specimen.subject is documented as "Where the specimen came from. This may be from patient(s), from a location (e.g., the source of an environmental sample), or a sampling of a substance or a device". This means literally any kind of location or thing. It has no specificity at all. Why is this called 'subject', which is usually assumed to mean 'subject of care'? If the specimen is something environmental, e.g. pollen, pesticide etc, then it has no subject in any normal sense.

What is the meaning of Location as a type of X.subject ?

Brian Postlethwaite (Nov 14 2019 at 00:24):

@Grahame Grieve I'd also be interested in places where people really want the org to be optional when using it.
In places like CareTeam, there is a separate property that captures that use case, and even when you don't know the person too.

Grahame Grieve (Nov 14 2019 at 00:26):

can you expand on that last sentence?

Lloyd McKenzie (Nov 14 2019 at 00:59):

Adding Medication, Procedure and PlanDefinition to Flag wasn't me. Rationale is here: GF#10083. Not sure I'm thrilled with it.
I think, based on recent discussions w/ Claude et al that CatalogEntry will be going away
Multiple locations can be involved in an appointment if some participants will be remote (think telesurgery, video con-calls, etc.

Specimen.subject is who/what the specimen was taken from. Is there a different word that would better cover the fact that a specimen could come from a door knob or pond or the floor of a cage containing multiple animals as well as from a human patient? (some of those were location examples)

Grahame Grieve (Nov 14 2019 at 00:59):

well that brings us back to subject/focus again

Lloyd McKenzie (Nov 14 2019 at 01:00):

Organization would most commonly be optional for definitional and sometimes request resources. I.e. This needs to be done by a cardiologist, don't care where or who. Though some resources call that out as a distinct element. PractitionerRole would be most needed when you want to specify not only the role but one or more qualifications.

Lloyd McKenzie (Nov 14 2019 at 01:02):

Specimen can also have a focus. Subject might be Jane Smith. Focus might be fetus#2 or tumor #5. Alternatively, subject might be Room 1152 in hospital XYZ, focus could be door knob or bed-rail.

Thomas Beale (Nov 14 2019 at 10:37):

@Lloyd McKenzie that exact situation is something I brought up in openEHR for clinical workflow, the question there being what is the 'subject' of a Task in a Plan? One answer is subject (of Plan) = <subject of care>; 'focal subject' or 'concrete subject' (of this Task) = sample 1234. I actually think that idea is potentially worth pursuing in FHIR. Generally, commonly named elements like 'subject' should follow the principle of least surprise.

Thomas Beale (Nov 14 2019 at 11:32):

@Grahame Grieve re my point: get Device sorted out; the kind of 'Device' being referred to where parties are needed is something like 'AutonomousAgent' or whatever you want to call it; it doesn't include bandages, test tubes, or even PET machines
Can you explore this a little more?

When I read through all the places where I see 'Device' in a list of participant Resource Types, I think: well, if the Device is a robot or other autonomous (= capable of making decisions, including whether or not to participate; aka having 'agency') agent, probably reasonable, but for all the other Devices, including consumables, imaging machines, most prostheses etc... no. They may be used, they do no participate as authors, carers, orderers or anything else. For this reason, I suggest that:

• a new type AutonomousDevice or AutonomousAgent is defined, with Device documented as being for non-agent devices; this new type would be a subtype of Agent in the Party/Agent/Role type structure;
• in containing Resources where you want to record what people often casually call 'resource usage', meaning people, places and things, that this be modelled with participation(s) separated out from real resource usage, i.e. consumption or use of non-agent materials, devices, places etc.

Thomas Beale (Nov 14 2019 at 11:45):

One of the big reasons for why I and others are proposing (some) type hierarchy in the Admin resources is as follows. WGs building resources are currently in the situation of defining Elements in a Resource, i.e. defining name, type, cardinality etc. The Resources are a typed system. Now, in places where Reference() is used, typing is being subverted; they are no longer stating a necessary type, they are trying to think of all possible use cases, and stating a corresponding list of types of instances in those use cases.

So the first problem here is that the way typing normally works is that for the type of any attribute in a class/module, you state the minimum (= most abstract) type that is needed for the rest of the class to function. What this means is that as long as the attributes defined in that abstract type are present in the instance at run-time (guaranteed in instances of all concrete sub-types), then we are happy. At modelling time, this type choice is the effective meaning of the attribute. In any model system using 'choice' (in FHIR, Reference() or choice[x]), this is not happening. Instead, no-one really knows what the attribute means, they just start creating a type restriction list. As more meetings are held, this list grows, shrinks, changes. No-one can ever say formally if any of the types in the list is correct, because there is no stated list of minimal characteristics, as there would be in a model system using abstract types. The result is brittle models, data and software - because making constant changes to those lists breaks things downstream.

Thomas Beale (Nov 14 2019 at 11:53):

A simple example. Specimen.collector is typed as 'Reference(Practitioner | PractitionerRole)'. What data are required about a collector, really? I suspect, probably just some identity info. Apparently discussions have been had where the group thought that only Practitioners (with or without org responsibilities attached) do this in real life. Firstly, that's not correct (most urine and stool samples are collected by the patient at home); secondly, even if we now modified it to 'Reference(Practitioner | PractitionerRole | Patient | RelatedPerson)' (allows for a parent to collect a child's sample), we still don't know if a) we got all the possibilities, or b) what minimal data items are required here? In other words, what general category of entity do we want here? The most obvious answer is 'party', i.e. an accountable entity with agency, and some minimal (at least potentially) identity, contact info etc. So the type should just be Party, if such a type existed.

Now, in specific local use for an in-house hospital lab, patient collection is out of the question, and you might profile this Specimen resource with a constraint to say

collector matches {Practitioner | PractitionerRole}

I'm using pseudo-archetype notation here to make it clearer that this is now a constraint on the original type-space. Which is what Profiles should be used for (among other kinds of constraining).

Thomas Beale (Nov 14 2019 at 12:06):

Here's a messier example:

Communication.sender[0..1]: Reference(Device | Organization | Patient | Practitioner | PractitionerRole | RelatedPerson | HealthcareService | Endpoint)

well, I can more or less guess the sense in which most of these types could send some communication (although, I will always forget that 'Practitioner' could be a paid driver, who is very unlikely to be sending any clinical communication). But in what sense is EndPoint a 'sender'? Clearly anything sent electronically is likely to come from a WS EndPoint, but this is just the mechanical act of sending, not the intentional act.

And then why not Group? Or following the logic of Specifmen.subject, why not Location? And following many other 'subject' definitions, why not Device? And now let's think about a Practitioner as sender; most likely his/her HealthcareService is also the sender, in an organisational sense. And why not the EMR system EndPoint as well? Which one do we want? As we can see, this kind of thinking can go on forever, but we never answer the basic question: what minimal data items are necessary for Communication.sender to make sense? Role is probably good enough (= any Actor in a role of responsibility under which such communications are sent).

Grahame Grieve (Nov 14 2019 at 12:11):

I'll come back to device after sleeping. We have agreed that we're going to work on to focus/subject thing in several resources. I added Specimen to that list after this discussion.

Thomas Beale (Nov 14 2019 at 12:13):

The same argument now applies here: defined the base Resource with something like Communication.sender[0..1]: Role (or Reference<Role> to keep the notion of 'reference') and then profile in different situations just the specific types you want to allow. Generic receivers know it will always be a Party, and receivers that have been developed with some specific agreement with the sender system developers may be able to assume a shared profile, not just the base resource.

Taking this approach would vastly simplify the endless discussions on what goes in the parentheses of every Reference() expression in a Resource definition. The discussion just becomes, ok, what is the minimal sensible thing here. A Party? A Role? Maybe it is just a Thing. It also means people building software to consume specific Resources can now make some meaningful assumptions about the type of these Reference() typed elements.

Another thing it solves is that in the current way of doing things, the list of types is the super-position of a whole lot of use cases, it doesn't (generally) correspond to any particular use case. So there is not even any sense in building software, queries or anything else that assumes the whole list as stated in the Reference() definition, because that list will never eventuate in any particular use context.

Thomas Beale (Nov 14 2019 at 12:22):

In summary, my general recommendation is:

• treat Resources as a possibility space, defined by open types that state the minimal requirements of any Element in a Resource; doing so requires the insertion of some abstract type Resources (e.g. Party, etc as mentioned above);
• perform all type-constraint in Profiles, specific to the types that really can occur in the use case(s) the Profile is built for. In this sense, Profiles are a constraint space.

The above arguments apply also for the use of choice[x], which is widespread, as shown by this page: http://hl7.org/fhir/R4/choice-elements.json

Lloyd McKenzie (Nov 14 2019 at 13:00):

I understand the concern around "rule of least surprise" and the term "subject". We would need a term that encompasses both patients and locations though - anything you might take a sample of for testing because the use-cases for Specimen encompass agricultural, public health and hospital safety testing. We would also need to retain the ability to have a finer-grained 'focus' which for humans is typically a fetus, tumor or lesion but for locations could be other things. Do you have thoughts on what a less surprising name might be?

I agree that references sometimes get out of control - poor definition of the attribute results in eventual slipping to include more and more resources. I'm not completely convinced that the issue is "what elements must be present on the reference target?" I think it's more about the capacity of the target. When we say that proposals can be 'authored' by a patient, practitioner or device, I don't think that assertion is driven by a shared set of elements held by those resources, it's that the entities represented by each of those resources has the capacity of authoring and we have existing systems where all of those types of individuals/things do author proposals/recommendations.

REST also plays a role. For something like 'collector' we're not concerned with "what are the elements we need to capture about the collector". Instead, we care about "what are the stateful entities that will exist in a registry somewhere we can point to by reference to indicate who/what performed the action?" That essentially changes the "what is the required data?" to "whatever's needed to point to the entity that has the relevant capacity". Fully agree that Patient and RelatedPerson should be part of that list - they have the capacity and commonly perform the action in the real-world. Though we'd need to check with the relevant work group to see if they'd been excluded for good reason (perhaps existing systems don't track collectors who aren't Practitioners?)

From a UML perspective, we can treat relationships as a relationship to a single abstract type or we can treat it as a choice of associations (essentially multiple associations with the same semantic and an invariant that enforces only one can be present - at least for those situations where cardinality is limited to 1). Thus far, we've leaned towards the 'choice' approach for three reasons:
- resources often have multiple 'capacities' and different capacities would logically be part of multiple hierarchies. Multiple inheritance tends to be hard in systems and even harder in serializations, so we've tried to steer clear of that
- we want to ensure that the list of what's allowed to be the target of a reference actually makes sense for a given resource and reflects what existing systems do. (Recognize that what's actually happened has sometimes strayed from that methodology point.) If we rely on inheritance relationships to reflect "what's allowed", then it's much harder to control what can be a somewhat arbitrary set of targets and/or the inheritance hierarchy can start to be convoluted to retain the desired level of control.
- whatever we do needs to support profiling, which can be even more arbitrary. It needs to reflect business rules and design constraints. Inheritance hierarchies will struggle to manage the variability that would be required here.
That's not saying we can't make a change here, just explaining the reason for the existing design and identifying some of the factors we'll need to allow for if we make a shift.

In terms of introducing the notion of AutonomousAgent, you are correct that there is a distinction between devices that have decision-making capability and those that don't, though the boundary can be somewhat fuzzy (and is getting fuzzier). However, devices also have the capacity for being purchased and inventoried and ordered and dispensed (including devices that have decision-making capability). So do we represent the same physical instance with two different resources for each capacity? We could certainly make an entity/role distinction here. Do you think there are elements that are relevant for the 'agent' role that aren't relevant for the typical device role? Would the 'agent' aspect of the device have a distinct state from the 'manufactured item' aspect? Would existing systems manage/track/store that information separately?

Grahame Grieve (Nov 14 2019 at 13:03):

regarding device... we can make the definitions explicit about the different roles and expectations without necessarily separating the resource out .

Grahame Grieve (Nov 14 2019 at 13:03):

generally, I think that Tom is missing something that we aren't generating defining as part of the definitions more than the actual resources

Lloyd McKenzie (Nov 14 2019 at 13:07):

Agree with that. Our definitions are more lax than they should be. In the communication example, if the sender is "who has 'responsibility' for the data shared, then EndPoint doesn't make sense as it can't take on responsibility. (That's the same reason 'Group' is isn't in the list - a Group - as defined in FHIR - can't take on collective action or responsibility. If you've got a collection of individuals that can take collective action/have responsibility, then you're talking about an Organization.)

Lloyd McKenzie (Nov 14 2019 at 13:11):

I very much agree with your idea @Thomas Beale of defining relationship targets as a possibility space. But I think the possibilities need to be driven by the capacities of the real-world objects represented by the entities, not necessarily by the data elements present on those entities. If we were to start requiring that all 'Reference' elements made clear what capacities must be held by the targets and what capacities certain target resources can have, that would drive more consistency while still allowing for refinement to reflect what real-world systems do. What are your thoughts on that? Do you think it would help?

Grahame Grieve (Nov 14 2019 at 13:13):

that seems to be heading in some kind of ontology direction

Lloyd McKenzie (Nov 14 2019 at 13:16):

If we were going to have a specific set of 'capacities' that could be asserted for resources and 'allowed' for References, then yes we'd need an ontology of some sort. I'd hope that it wouldn't have to be super complex. (Hopefully in the range of 10-20 total concepts)

Grahame Grieve (Nov 14 2019 at 13:26):

well, I'd build it into the tooling

Thomas Beale (Nov 14 2019 at 13:36):

I'll leave further replies on the general methodology question for later (maybe some others might want to comment), but re: @Lloyd McKenzie "We could certainly make an entity/role distinction here. Do you think there are elements that are relevant for the 'agent' role that aren't relevant for the typical device role? Would the 'agent' aspect of the device have a distinct state from the 'manufactured item' aspect? Would existing systems manage/track/store that information separately?"

Yes, I did start think about that. It's a good question, but people more in the FHIR space might have better answers than me. I am inclined to always ask the question: well, what is the intention of supplying information X in field Y (say, subject)? Is it to be able to contact the subject, just know the name, or figure out (say) legal status? So, if we put an AutonomousAgent as a possible type for a sender, author or anything like that, the question is what do I want to do if I received that particular kind of instance? My first guess is: know the identity, and possibly trace the chain of responsibility to some senior human or org, just like I might want to do with a junior doc. Do I need to know 28 device manufacture details? I doubt it, but I might want to know that it was a Nexus 6 or a Nexus 8, which is probably like knowing it's an intern v resident v consultant. I am 90% sure the other 27 device manufacture attributes would be junk 99% of the time. So I'd certainly at least be doing AutonomousDevice.manufacture [0..1]: Reference(Device). (choose better names...)

Grahame Grieve (Nov 14 2019 at 13:38):

Type and identifier (= UDI) and maybe photo are the things that come up for me

Thomas Beale (Nov 14 2019 at 13:39):

General point: BFO2 and bioTopLite are useful places to look for very general categories.

Grahame Grieve (Nov 14 2019 at 13:39):

are they? I haven't found it to be so, but I'm happy if you can show us how

Thomas Beale (Nov 14 2019 at 13:41):

Well, if you want a category whose extension includes people, locations, organisations... it's probably just BFO2::Continuant. You might name it something else in the FHIR space, but that's the kind of thing you are talking about. But one has to be very careful to distinguish between types that represent real entities in the world, or data entities that stand in the 'is-about' relation to similarly-named real world entities. Big difference...

Grahame Grieve (Nov 14 2019 at 13:42):

what other relevant things does BFO have?

Grahame Grieve (Nov 14 2019 at 13:43):

does it have anything about subject/record target / focus?

Thomas Beale (Nov 14 2019 at 13:45):

There are two other ontologies IAO and OBI which have potentially useful things. I'll go have a look at latest versions and see what I can find.

Lloyd McKenzie (Nov 14 2019 at 13:45):

Part of the tricky part about designing references (and resources themselves) is that they're supposed to be context-independent. We don't have a specific use-case about what data is needed because the relationship can be navigated by different systems for different purposes. If you're looking at the autonomous agent, you might care about the manufacturer, you might care about the software version, you might care about the responsible organization, you might care about the identity, you might care about all of the above. Obviously if you're looking at a practitioner, some of the concepts would still apply (identity, responsible organization), but others (manufacturer and software version) not so much. On the other hand with a practitioner, you might be interested in qualifications or email address.

Thomas Beale (Nov 14 2019 at 15:41):

Well that's the general situation - we're talking about ad hoc querying after all. So what data are returned is really up to what the client side asks for. As long as the client has the means to navigate references, and make subsequent queries for various bits and pieces, things will be fine. Naturally the modelling choices will never be a direct match for every query from any client. They need to be based on some sweet point between the multitudinous diversity of current systems and a normalised client view, possibly informed by some ontological considerations (i.e what is a Patient, etc)

Lloyd McKenzie (Nov 14 2019 at 15:56):

That's somewhat true. Typically when you have a reference to a Device, Patient or Practitioner you'll get back the whole thing. It might be filtered by your user permissions (you'll only get back what you have permission to see) but generally the client doesn't ask for only a set of data elements. There is a query capability that allows you to constrain what elements you get back, but it's not widely supported/used.

If you're comfortable with the 'capacity' approach to defining what types of capacities a resource has (or a reference should have), then lets pursue that. Would you be willing to define some of your hierarchical levels in terms of what 'capacity(ies)' they represent?

Thomas Beale (Nov 14 2019 at 17:08):

@Lloyd McKenzie

I understand the concern around "rule of least surprise" and the term "subject". We would need a term that encompasses both patients and locations though - anything you might take a sample of for testing because the use-cases for Specimen encompass agricultural, public health and hospital safety testing. We would also need to retain the ability to have a finer-grained 'focus' which for humans is typically a fetus, tumor or lesion but for locations could be other things. Do you have thoughts on what a less surprising name might be?

Here we can start looking for very general terms other than subject, e.g. 'source', 'material source' or whatever and then try to think what kinds of type(s) it could be. I would be inclined to consider a) thinking up a new name like 'materialOrigin' and b) just coding it, i.e. the meaning is type of material origin. The reason for this is that if a data element is so general that literally any entity/thing can go there, I probably have no expectations at all, not even to get proper ids etc, other than, tell me the type of thing. So that would imply just coding it.

Thomas Beale (Nov 14 2019 at 17:13):

@Lloyd McKenzie

If you're comfortable with the 'capacity' approach to defining what types of capacities a resource has (or a reference should have), then lets pursue that. Would you be willing to define some of your hierarchical levels in terms of what 'capacity(ies)' they represent?

I don't know what you mean by 'capacity' yet, in terms of something formally representable. Either it's in the data - that's what you will compute with, or maybe it's in an ontology / taxonomy of types, but still I only care about that to the extent that I can get hold of computable things (usually data) that characterise individuals of those ontology categories. (However, 'capacity' could be quite a good term for this concept, if we can define something workable).

Lloyd McKenzie (Nov 14 2019 at 17:45):

With specimen, we're capturing two aspects - where did the material come from and what record is it attached to. I could live with 'source' as a name.

The data for the things that fit the categories will vary depending on what you're pointing to. What really mattes is what those things are able to do. (softwareVersion matters for Device, email matters for Practitioner, but what matters is that they're both resources that can take responsibility for performing actions. "ability to take responsibility for perform actions" doesn't come from having a common set of attributes, but more from what the object 'is' - i.e. it's definition/scope and the real-world ramifications of that.

Thomas Beale (Nov 14 2019 at 22:27):

@Lloyd McKenzie I am unclear in what sense 'resources can take responsibilities for performing actions'.

Lloyd McKenzie (Nov 14 2019 at 23:17):

The entities represented by the resources can take responsibility - i.e. Patients, Practitioners, PractitionerRoles, HealthCareServices, Organizations and Devices (at least some of them) can have responsibility for an action, though in some cases (PractitionerRole, Device) that responsibility propagates up to the Organization that manages them. On the other hand, the entities represented by Group, Specimen, Location and most other resources cannot take responsibility for an action.

Thomas Beale (Nov 15 2019 at 10:57):

Well that distinction is more or less the concept of Party, i.e. an entity capable of actions (agency) and having accountability. This is usually extended in the Role concept. Specimens, Locations and most Devices are not Parties. Group requires its own analysis (but somewhere up there you said that only a responsible individual within a Group could be accountable, which I agree with).

However... these are general concepts. Trying to guarantee that a specific informational entity (representing some kind of party) attached to some other information representing an act (prescription or whatever) has some particular / ultimate / legal / other level of responsibility I think is not achievable in the base models. You can only achieve this with a known organisational structure and known legal environment. The latter might be possible within some well-defined jurisdiction like 'Norway', or maybe a US state or CA province but knowing how organisational chains of responsibility really work is guesswork.

The other point is: probably the majority of ad hoc requests into systems done via FHIR don't care about ultimate responsibility for an act, they just want to find out the proximate actor to answer the routine question 'who is taking care of this patient right now?' Such requests could be looking for anything - financial data, clinical history, who knows what.

I think that the best that can be done is to do sufficient 'modelling' that commonly agreed categories of things (including abstract categories) are represented in unsurprising ways. Why? Because at the end of the day, data passed through some interop layer to requesting applications is ultimately there to serve some human cognitive need to do with a healthcare process that is underway. So how the professional healthcare sector thinks about entities is one driver. Secondly, in order to achieve software reuse and data processability we need to use generalisation in the models of those things.

With FHIR, we are working with information artefacts and their definitions, i.e. some kind of model. The semantics of the outside world as far as they are internalised in FHIR are just whatever the model says (including derivative models, various implem guides and other concrete artefacts). To come back to your point about 'capacities', I would say that idea can only be realised in terms of concrete Resource definitions in FHIR. So if we ask the question: what kind of thing can be Communication.sender be, we can only answer in the general ontological sense: 'accountable agents', or whatever we think it is. And what FHIR thinks that is is just whatever a Party resource (if it existed) says it is. The model can't make promises that the kind of agent is just the one that truly has legal responsibility for that kind of act in Ontario or Bavaria, or wherever. All it can do is deliver some data that make sense, and let the requesting application make the next move.

Lloyd McKenzie (Nov 15 2019 at 12:27):

I totally agree that there's no way to guarantee that a particular type will/can have accountability in a given circumstance. However, some resource types have the capacity to have accountability and some don't. If a particular relationship requires accountability as part of its semantics, then that should act as a filter on what resources are valid as targets of the relationship. The specific set might still be further filtered based on real-world behavior. For example, the "performer" relationship is generally restricted to resources that can be accountable (so "party" in your terminology). In the current design, that would include Patient, RelatedPersion, PractitionerRole, Practitioner, Organization, HealthcareService, CareTeam, and some types of Device. Business rules would come into play indicating that certain instances of those (say infant Patients, Practitioners that are deceased, disbanded Organizations, Devices like a non-automated bandage, etc.) can't take on responsibility. Further business rules, legal considerations and general reality might place further limitations about what kinds of things a given entity can perform. However, those rules fall into the space of context-specific implementation profiles where you can agree on what data elements will be supported by the relevant systems, what coded values will be present, etc. that might let you restrict to appropriate subsets of the respective resources.

However, we can still do better than say that "all performer relationships can/must allow all 'party' resources as targets". For example, when we are in the specific context of Immunization and looking at what real systems do, Patient, RelatedPerson and Device might fall off the list because we don't have (and don't envision) situations where those resources would ever be captured as the entity that performed an immunization. We can, however, be confident that referencing Specimen or Location as a performer would invariably be wrong because neither of those things can ever have the responsibility for performing anything - let alone performing an immunization.

Does that make sense?

Thomas Beale (Nov 15 2019 at 20:06):

I think you are making excellent arguments for introducing some abstract Resource types such as Party, Role, Practioner and so on! Your statement "We can, however, be confident that referencing Specimen or Location as a performer would invariably be wrong because neither of those things can ever have the responsibility for performing anything - let alone performing an immunization." is exactly the missing capability that I think is needed in working groups that I am advocating for: knowing that an accountable entity is needed here, that a 'request' entity is needed there and so on. With abstract resources that contain just the elements common to these general categories, Resource specifiers can match the data picture to the real world picture, at least in a reasonable approximation, rather than pursuing an interminable guessing game to construct a list of concrete types for many attributes.

Now, as I have pointed out previously, I don't think all the needs can be solved 100% cleanly in this manner. In some cases, you are stuck with specifying a wide type like Party or Role in a base Resource, and then having to create a normative profile that everyone should use, that does some restriction that everyone agrees really is true. We do this in openEHR, but we never do it in the info model layer, only in the archetypes layer (= FHIR profiles layer).

In the ideal case I think FHIR would be greatly improved by getting rid of these choice mechanisms altogether from the Resources (thus obviating the need for many of the compensatory patterns, which are going to be real work to maintain). Instead, use wider single types in the Resources, and in cases where some universal restriction is needed, make a normative profile. I don't know whether people are up for doing such a change, but I guarantee it will bring many benefits.

Grahame Grieve (Nov 15 2019 at 20:36):

I guarantee it will bring many benefits.

I don't yet see any benefits except for much confusion. Resources are normative profiles, why change that? How would it help anyone reading the standard to see the Observation.value allows any Type specialization, when it turns out that it actually doesn't, but you have to find that out somewhere else?

I can't see that being a good outcome. Otherwise, Observation.value is Type, as shown in the UML

Grahame Grieve (Nov 15 2019 at 20:37):

introducing some abstract Resource types such as Party, Role, Practioner and so on

There are other ways to solve that problem as well. We should consider them

Thomas Beale (Nov 16 2019 at 11:28):

I don't yet see any benefits except for much confusion. Resources are normative profiles, why change that? How would it help anyone reading the standard to see the Observation.value allows any Type specialization, when it turns out that it actually doesn't, but you have to find that out somewhere else?
I can't see that being a good outcome. Otherwise, Observation.value is Type, as shown in the UML

Observation.value should just be of type DataValue or some similar parent type of the various data value types. Typing it as 'Type' doesn't help anyone, indeed.
Resources are not really normative profiles, they are a typed model, but containing subversions of their own type system, i.e. the 'choice[x]' and 'Reference()' constructs. This already is an endless confusion. Mixing constraints in with a a typed model doesn't work, which is why XSD is the lone formalism that does it (the designers had no idea of information modelling), and why no-one uses XSD to do real modelling as such.

Lloyd McKenzie (Nov 16 2019 at 12:58):

Making it the parent type would imply that all of the children are allowed - and they're not. Only a restricted list is permitted. The same problem applies if we were to use "Party" as the performer for an Immunization - not all of the specializations of party are permitted. Declaring an abstract type and then saying elsewhere that some of the specializations don't apply doesn't buy anything because implementers can't rely on the abstract type to be true.

Grahame Grieve (Nov 16 2019 at 15:29):

so you keep banging away on this XSD point, which indicates that you still don't follow what's going on.

Grahame Grieve (Nov 16 2019 at 15:30):

we're not aware of any benefit of renaming "Type" to "DataValue" other than making you happy

Thomas Beale (Nov 16 2019 at 18:37):

@Lloyd McKenzie in many cases, the abstract type will be true. It's just a question of which use cases have exceptions. The point about the abstract type is that it represents the minimum capabilities of any attached object. If a concrete type like Practitioner applies in all cases, then you just put that of course.

@Grahame Grieve what don't I follow? FHIR is clearly based on XSD thinking, unless you have re-invented the same thing as XSD without intending to. But it's not a formalism anyone uses to do model representation with typing. It's only (slightly) useful for describing XML document content. There's a reason all formalisms used in IT don't include 'choice' - because it breaks typing. But anyway, I can see you are dedicated to this approach in FHIR, so I won't go on about it.

Lloyd McKenzie (Nov 16 2019 at 19:46):

In most of our cases, there are at least some exceptions. And the choice of what resources are available is driven by semantics - not what the data elements are.

Rather than argue about the modelling theory, let's focus on the use cases. Do you understand the need to be clear about what types or resources are (and aren't) allowed in a particular element?

Thomas Beale (Nov 17 2019 at 10:09):

Sure. It's what we've been successfully doing for 15 years in openEHR. The question is how to do it so that the management of the specification (Resource definitions and other normative artefacts), along with software production and data management are all economic and sustainable in the long run. Using technical things like 'choice' works against this, as has been recognised for a long time in industry (it's the reason 'exceptions' to typing in models are almost always modelled as 'business rules' or other kinds of constraints, in another layer of representation). I'm simply arguing for expressing the constraints you want in a technical way that a) doesn't break the base type system and b) is far more forgiving of requirements that subsequently change.

Anyway, you are not going to agree on that, and I didn't really expect you would. Why not consider the lesser question of introducing some abstract types as discussed earlier, and at least simplify the typing equation? That will certainly provide some value.

Grahame Grieve (Nov 17 2019 at 10:54):

I haven't seen any space in the data types where more abstract types will help, thought the only solid one you've proposed is DataValue.

Grahame Grieve (Nov 17 2019 at 10:55):

back to Resources... we're discussing doing something in the Participations. Can we talk about name and see whether there's something I haven't figured out?

Grahame Grieve (Nov 17 2019 at 10:57):

some of the participations, where appropriate, use name : HumanName. Other participations use name: String - which is close to the same as HumanName.text. So it's logically consistent, and consistent enough to say that they use the same pattern, but it's not something that works for specialization

Grahame Grieve (Nov 17 2019 at 10:59):

so we could:

• Split name out as as a sibling to HumanName and remove .text
• introduce some abstract ancestor for HumanName and push the direct name:String down a level
• ... something else?

None of those options have seemed like a value proposition to the community (and the first is procedurally impossible now)

Grahame Grieve (Nov 17 2019 at 11:07):

I believe that we agreed (loosely) to look at an ontology of participations, and that @Thomas Beale was going to look at BFO etc again to see what was there. There's also HL7's classification(s) from the RIM to look at. I don't want this (sort of) action item to get lost...

Grahame Grieve (Nov 17 2019 at 11:07):

I think the ontology comes before redesigning the resources, btw.

Thomas Beale (Nov 17 2019 at 11:58):

Well, for example iao::author-role is-a bfo::role is-a bfo::realizable-entity is-a specifically-dependent-continuant is-a continuant is-a entity. I would not replicate all of this in an information model, but just note that 'author' is understood as a kind of role. NB: BFO is fully axiomatised; these are not informal relationships. The class specifically-dependent-continuant (SDC) is one important one; it is for continuants that rely for their existence on an independent continuant (like a person or org). Independent continuants are pretty close to what I call Actor - a continuant entity-in-itself. SDCs are an ontological correspondent of what I have called Role, i.e. something that is dependent on its bearer (some Actor).
pasted image

Thomas Beale (Nov 17 2019 at 12:09):

Dispositions and functions are also Roles in BFO.

Thomas Beale (Nov 17 2019 at 12:11):

Regarding the 'name' problem, the orthodox approach is to define an abstract type Name that has various subtypes that has various subtypes like PersonName, OrgName etc. It can also provide at the Name level an interface level of representation like asString: String etc.

Thomas Beale (Nov 17 2019 at 12:11):

If you want a model that allows either a String form OR a parts-form name to be populated, and always provides a way to turn the latter into the former, then you could do:

class Name {
    properties
        asString: String;                     // represented as a String
        parts: Hash<String, String>;         // for example
        abstract parts2string(aParts: Hash<String, String>): String;  // implemented in descendants
    invariants
        asString /= Void or parts /= Void
}

Lloyd McKenzie (Nov 17 2019 at 13:52):

We need to be able to convey the name as a single string, as a collection of parts, or both. We can't count on the receiver serializing a name string from the parts in the same way the sender does - because serialization order varies by context. Thus we need to be able to convey both forms.

Thomas Beale (Nov 17 2019 at 16:04):

Right - that's what the above does.

Lloyd McKenzie (Nov 17 2019 at 16:44):

What I'm saying is that parts2string isn't something that could be defined on the interface.

Grahame Grieve (Nov 18 2019 at 08:32):

I see we fell back to interfaces very quickly. That's what we're currently proposing anyway

Grahame Grieve (Nov 18 2019 at 08:36):

with regard to the bfo roles... that little snippet you posted there is confusing, since it appears to be a single heirarchy but the descriptions imply multi-axial behaviour. E..g entity..continuent.. .. physical object quantity.. morphology

I don't understand that. But does BFO have enough granularity in there to be generally useful for us?
... and I would not consider replicating it in the information model, but I could consider making a BFO code mandatory as a metadata item on references and resources, say, and making it an error in the build if they are not consistent. but my taake on BFO is that it doesn't say the things we'd want to say.

Grahame Grieve (Nov 18 2019 at 08:38):

actually, on the subject of name... here's one place where choices are actually useful - the abstract could be a choice of HumanName | string, but that's not something we'd presently actually do. Maybe we should make that allowed in an abstract type... ?

Lloyd McKenzie (Nov 18 2019 at 11:05):

Because you can have HumanName with just text, that would then give two ways to send the identical thing. I expect we'd actually want to prohibit that in the same way we prohibit a choice of CodeableConcept|string. (We need 'text' on HumanName because it's often use to convey both the discrete parts and the rendered name.

Grahame Grieve (Nov 18 2019 at 11:05):

only a choice in the abstract ancestor

Lloyd McKenzie (Nov 18 2019 at 11:06):

If there was value in having an abstract ancestor? I admit I don't yet understand the use-case for that.

Grahame Grieve (Nov 18 2019 at 11:07):

yes if there was value.

Grahame Grieve (Nov 18 2019 at 11:07):

I think there is...

Grahame Grieve (Nov 18 2019 at 11:07):

I'll make the case after DevDays

Thomas Beale (Nov 18 2019 at 18:58):

I'll get back on the BFO etc question tomorrow. I'll provide a bit more background on these ontologies which might help see how/if they are useful here.

Grahame Grieve (Nov 27 2019 at 04:49):

@Thomas Beale ping on this

Last updated: Apr 12 2022 at 19:14 UTC