Stream: implementers
Topic: lifecycle through profiles
Jens Villadsen (Mar 05 2019 at 15:17):
Is there anyone having experience expressing the lifecycle of resources through the use of profiles. What I was thinking about was to use profiles as a way of maintaining business rules. Eg. one patient profile may be useful during the start of an episode of care and the constraints may be at bit loose. Now later on, when the data on the patient may have been further enriched one might not allow that some cardinality is allowed to go back to 0 - eg. managingOrganization. As a way of not allowing such updates, one could now let the resource be compliant to a more strict profile - based of the originial patient profile. Has anyone got experience with such usage?
Michel Rutten (Mar 05 2019 at 15:25):
Interesting question! Resembles a state machine with well-defined transitions from one profile to another.
Jens Villadsen (Mar 05 2019 at 15:58):
indeed - and it keeps business rules on the server where they belong
Michel Rutten (Mar 05 2019 at 16:03):
The Task resource is designed to model (clinical) workflows. Maybe you can leverage this resource to define conversion operations that transform instance data from one profile to another?
Jens Villadsen (Mar 05 2019 at 16:08):
@Michel Rutten - I can't say I have much experience with Task so I can't say if it could deliver the flexibility that would be required with this profiles-as-states-design. I also can't believe I'm the first one to have this thought - or am I wrong?
Lloyd McKenzie (Mar 05 2019 at 16:09):
Task doesn't model the workflows, it allows execution of them. (The definitions of the workflows are handled with PlanDefinition).
Lloyd McKenzie (Mar 05 2019 at 16:09):
I'm not familiar with anyone else to propose using profiles for workflow business rules
Jens Villadsen (Mar 05 2019 at 16:10):
So the (sort of maybe obvious) question is why not?
Lloyd McKenzie (Mar 05 2019 at 16:12):
Lots of implementers don't have FHIR-based back ends, so they often have other ways to tackle business rules. Also creating profiles isn't a widespread skill.
Lloyd McKenzie (Mar 05 2019 at 16:13):
My own reaction is that it may result in validation messages that are a bit clunky/non-intuitive. Also it might not be the most efficient way to enforce business rules on a transition.
Jens Villadsen (Mar 05 2019 at 16:14):
I'll agree to the fact that the error messages may be a bit clumsy
Jens Villadsen (Mar 05 2019 at 16:14):
But it should be a clean way of expressing the business rules - in a vendor-neutral format
Jens Villadsen (Mar 05 2019 at 16:15):
and it does not require a FHIR based backend ... al least not for full state regular updates
Jens Villadsen (Mar 05 2019 at 16:16):
the validation runs on the wire-format which means that the backend can be whatever
Bret H (Mar 05 2019 at 16:16):
@Jens Villadsen so the FHIR server would have a business rules section in its conformance statement? How do you expose the operations? Are you suggesting an IG for business rules operations?
Jens Villadsen (Mar 05 2019 at 16:23):
I'm merely pitching an idea here. The capabilitystatement (https://www.hl7.org/fhir/capabilitystatement-definitions.html#CapabilityStatement.rest.resource.supportedProfile) already has some sort of room for this. I don't know where business rules section should be located - but it would be a fair assumption for a system having an IG to express its business rules somewhere in its documentation
John Moehrke (Mar 05 2019 at 16:24):
I do this in the MHD profile. I have one set of StructureDefinition for when a document source is submitting new documents, and a different StructureDefinition for the future query results. It is clunky, but it does somewhat follow. There are some intermediate steps I didn't model, mostly because they are less critical and are usually states transition.
Jens Villadsen (Mar 05 2019 at 16:25):
It might also be a non trivial task to figure out when a transition happens - eg. a resource now conforms "to a more strict version of a given profile and should stay that way"
John Moehrke (Mar 05 2019 at 16:25):
yes, and at that transition it stops conforming to the previous.
Jens Villadsen (Mar 05 2019 at 16:25):
why is it clunky?
John Moehrke (Mar 05 2019 at 16:26):
I suspect my statement of clunky is more related to the tooling I have today. I suspect it could eventually work very well.
Jens Villadsen (Mar 05 2019 at 16:27):
my thought was that you start with being compatible with eg. a sparse profile ... and then some way down the road you restrict it further - meaning that the resource conforms to both
John Moehrke (Mar 05 2019 at 16:28):
tooling in that I am using IHE limited tooling, but also because right now I am trying to move to R4 and there is limited tooling to create StructureDefinitions there. And visualizing the transition between the two is not obvious, so you just have before and after snapshots.
Jens Villadsen (Mar 05 2019 at 16:28):
@John Moehrke I guess you're talking about the actual work on the profiles.
John Moehrke (Mar 05 2019 at 16:28):
in the case of MHD, it isn't just going from relaxed to strict. There are some strict rules on submission, because the server fills them.
John Moehrke (Mar 05 2019 at 16:30):
yes I am mostly focused on IG writting and reading. For that it is clunky. But it does mirror the original IHE concepts of a Transaction->Message-Encoding. So for IHE it is logical.
Jens Villadsen (Mar 05 2019 at 16:33):
(lets imagine that creating profiles in R4 would be just as easy as in STU3 - which will happen eventually) - in terms of lifecycle of the actual resource I was actually hoping to gather some knowhow on whether it would be a good idea or not with this design and the caveats between going from either a) relaxed to strict (where the strict would derive from the relaxed) - or b) going from relaxed to something not directly derived from the relaxed - ... if y'all follow
Jens Villadsen (Mar 05 2019 at 16:35):
from top of my head I could imagine that it might not be the greatest idea to let the strict derive from relaxed as it will impose restrictions that might not be beneficial in all cases ...
John Moehrke (Mar 05 2019 at 16:36):
The MHD structureDefinitions for STU3 are at https://github.com/IHE/fhir/tree/master/StructureDefinition (I await new Forge before working on the R4 flavors)
Jens Villadsen (Mar 05 2019 at 16:37):
@John Moehrke does your strict profiles derive from the relaxed?
Jens Villadsen (Mar 05 2019 at 16:37):
and do you have any feeling with the cumbersome details of actually implementing it?
Jens Villadsen (Mar 05 2019 at 16:40):
a benefit of this design is that it changes very little on the resource (only the metadata) and you get to distribute your business logic to the freaking clients
John Moehrke (Mar 05 2019 at 16:40):
no, they are all written from FHIR Core STU3. The concept of including and further restricting was not well supported or obvious at the time.
Jens Villadsen (Mar 05 2019 at 16:41):
@John Moehrke as in derived profiles?
John Moehrke (Mar 05 2019 at 16:42):
I think that mCSD did this for the distance option on Location. (also in that same github)
John Moehrke (Mar 05 2019 at 16:42):
@Luke Duncan was more willing to live on the edge
Jens Villadsen (Mar 05 2019 at 16:44):
I see - the restriction was to require a position - which makes sense i guess
Jens Villadsen (Mar 05 2019 at 16:46):
@Bret H I also guess parts of the operations are already exposed in http://hl7.org/fhir/resource-operations.html#meta
Jens Villadsen (Mar 05 2019 at 16:48):
@Lloyd McKenzie I'm a bit surprised you haven't seen this sort of design since I thought you had seen all what FHIR could offer ;)
Lloyd McKenzie (Mar 05 2019 at 16:49):
Keeping track of what everyone's doing with FHIR is next to impossible. V3 was so much easier - much less uptake and no-one had a hope of getting up and running without help of a small number of people...
Lloyd McKenzie (Mar 05 2019 at 16:50):
(So I guess v3 does have some advantages :))
Jens Villadsen (Mar 05 2019 at 16:51):
(I'd rather have a harsh rash in my buthole than having to go back to working with V3)
Jens Villadsen (Mar 05 2019 at 16:52):
@Lloyd McKenzie spawn more McKenzies then
Michel Rutten (Mar 05 2019 at 17:25):
the validation runs on the wire-format which means that the backend can be whatever
Mind that validation requires access to all referenced external resources (profiles, valuesets etc.). External references not included in the exchange (Bundle) must be resolved from somewhere, i.e. the back end.
Jens Villadsen (Mar 06 2019 at 08:20):
@Michel Rutten you're right - the idea is not totally flawless ;)
Jose Costa Teixeira (Mar 06 2019 at 20:35):
@Jens Villadsen catching up: If i read correctly, this could be similar to what we will have in medication workflows:
1. there is a prescription (this is a medicationrequest)
2. bla
3. there is a medication administration plan - the list of all medications and respective hours of adminisrtation, to set the nurse's schedule. this is also a medicationRequest, but with different constraints
Jose Costa Teixeira (Mar 06 2019 at 20:36):
I am trying to get some time to experiment a bit on "workflow conformance" - which is, defining the fhir constraints along a workflow.
Jose Costa Teixeira (Mar 06 2019 at 20:39):
fwiw, in good old V2 there was a big variance of which message people used to express the same thing. For prescriptions it was random OMP or RDE. For dispenses it was RDS, RGV or RDE. Administrations being RAS or ORU... and in IHE that is the first problem to address.
Jens Villadsen (Mar 07 2019 at 08:54):
@Jose Costa Teixeira keep us posted on your findings if this is something that you dig deeper into
Morten Ernebjerg (Mar 07 2019 at 21:30):
@Jens Villadsen Very late to the party, but I just wanted to add one more class of use case we have seen which can also be modeled as transitions between profiles: In some flows for setting up data sharing based on patient consent, it may be necessary to handle resources entities which, for reasons of data privacy, cannot contain certain information - information which, however, is allowed later on. For instance, for consents it might be desirable to not have both the Patient and the Practitioner referenced before the patient has actually signed the consent, because one otherwise exposes (without consent) the fact that the Patient is associated with a given doctor. Or there may be stages in an on-boarding process where a "dummy" Patient resource is needed because the actual personal information can only be added later (once consent has been given). In these cases, one effectively imposes a (very) strict profile on resources early on in their life-cycle and then later reverts to more relaxed profiles. In other words, the direction of motion in the "strictness-space" is (at least initially) the opposite of what was discussed above.
Jens Villadsen (Mar 07 2019 at 22:10):
@Morten Ernebjerg - you can never be too late to a party. Your case is definitely interesting as well - and certainly proves that the state transitions at not limited to continuous strictness but can just as well (as in your case) be about loosening up. One very interesting aspect in this sort of design or usage is that the backend would hold the transition definitions (structure definitions) - but the client would/or could be the one that actually is in charge of stating what transitions it intends to through - and any transition can in principle lead to any other transition as they are not required to be derivatives of each other - which in turn probably means that state machine might not be spot on ... maybe :thinking:
Morten Ernebjerg (Mar 08 2019 at 16:24):
@Jens Villadsen Hm, I'm not quite sure I'm following here. I thought the idea was that the profiles/structure definitions would define the states and the allowed transitions would be specified somewhere else, e.g the CapabilityStatement (i.e. "if a Patient resource conforms to profile X, it may only be changed such that it afterwards either conforms to profile Y or to profile Z"). At that level, the state machine metaphor seem to fit quite well. Or did you mean that the profiles themselves would also imply transition rules, e.g. that you can only "move downwards" in a re-profiling hierarchy? Anyway, once we talk about resources, I think you're right about the metaphor being strained a bit, since a resource can simultaneously conform to multiple profiles and so would not map to a unique profile state. Unless, I suppose, the profile is always explicit in meta.profile, in which case the server could apply the state machine logic to the "profile before" --> "profile after" transition of a requested update request. But I still imagine that for set-ups with multiple unrelated profiles that do not exclude each other (i.e. a resource can conform to more than one of them), it would be fiendishly hard (but possibly interesting :nerd: ) to ensure that the transition rules are actually consistent.
Jens Villadsen (Mar 09 2019 at 07:39):
@Morten Ernebjerg
Jens Villadsen Hm, I'm not quite sure I'm following here. I thought the idea was that the profiles/structure definitions would define the states and the allowed transitions would be specified somewhere else, e.g the CapabilityStatement (i.e. "if a Patient resource conforms to profile X, it may only be changed such that it afterwards either conforms to profile Y or to profile Z")
yep - What is important to me is the ability to express rules about valid states and for that structuredefs seems capable.
Jay Lyle (Mar 13 2019 at 12:54):
This isn't so much a lifecycle question as a concurrent perspectives question, but it could be both.
Our Pharmacy team is populating resources to support Pharmacy order processing, including some 1:2 cases where a single legacy Pharmacy file will spawn a MedicationOrder (e.g., date written) and a MedicationDispense (e.g., IV composition). I believe the Pharmacy order resource will contain, in addition to the reference to the clinician order file record, two identifiers: one from the Pharmacy file and one from the Order file.
There will be other teams generating MedicationOrder from the clinician order system side. Now we have, potentially, two different resource profiles out there for a single order: one view from the ordering side, and one view from the processing side. For our use cases, that's not a problem: Pharmacy client systems will request one profile; ordering client systems the other. Synchronization rules live in the legacy system.
That sure complicates the idea of a resource. Is that a problem?
Jens Villadsen (Mar 13 2019 at 13:13):
Well - this is not necessarily a problem. One aspect of this is a state machine. Another aspect is to maintain business rules. I imagine that since you have multiple different systems they may all have their own view of what parts of the data that is required and what isn't -and that you can maintain in structuredefs. Having multiple structuredefs would then make you aware of how the systems differ and thereby also be aware of what staes that are needed in order to be compliant with each other.
Last updated: Apr 12 2022 at 19:14 UTC
