Stream: implementers
Topic: profiling
Stefan Dimitrov (Jan 26 2017 at 16:13):
On the Profiling page it says "The extension definition also defines the context where the extension can be used (usually a particular path or a data type) and then defines the extension element using the same details used to profile the structural elements that are part of resources.", does this mean that an extension can restrict the type of a Resource field, for instance constrain a Reference to certain resource types?
Vadim Peretokin (Jan 27 2017 at 09:37):
You've got to use a profile if you want to do restriction. I think the latter part of the definition is just saying you use a StructuredProfile resource for both resources and extensions
Stefan Dimitrov (Jan 27 2017 at 17:35):
Can a FHIR profile constrain fields of referenced resources?
Igor Sirkovich (Jan 27 2017 at 18:35):
@Stefan Dimitrov , you would need to profile each resource where you need to constrain any field. @Vadim Peretokin , I think you mean StructureDefinition (there is no StructuredProfile resource)?
Lloyd McKenzie (Jan 28 2017 at 03:43):
@Stefan Dimitrov A profile can assert a target profile for a reference - which would in turn restrict the referenced artifact. However, a profile can't "drill down" into the content of a referenced resource the way it can drill into the components of a data type. (Note that drilling down into a contained resource or an element of type Resource (e.g. in Bundle.entry) would still be possible in principle, though may not yet be supported by all tools.
Vadim Peretokin (Jan 30 2017 at 17:26):
Sorry, yes meant StructureDefinition.
Jayashree Surnar (Apr 24 2017 at 10:45):
hello All , may i know what tool is best to create extension and profiles in fhir? upto now i used clinfhir. as forge doesn't support json as well as STU3. but i come to know that clinfhir is not a standard tool. so whats the alternate to clinfhir? how fhir core extensions and profiles created. please let me know.
Thank you
Michel Rutten (Apr 24 2017 at 13:39):
Hi @Jayashree Surnar there are a number of different tools that support authoring FHIR profiles. ClinFHIR is originally developed to support clinical connecthatons, so it provides a simplified user interface targeting clinicians (not developers). Forge is aimed to be a reference implementation that tries to support all aspects of FHIR profiling (fairly extensive support, but still work in progress; STU3 release to be published this week). Lantana provides the Trifolia tool, which is also a HL7 profile editor. And there is the MDHT tool, a UML-based modeling tool.
FHIR core resources and datatypes are usually designed by manually authoring XML and/or JSON source, because the available profiling tools are usually lagging behind (i.e. while authoring the new STU3 release, available profiling tools were still targeting DSTU2).
Jayashree Surnar (Apr 25 2017 at 04:42):
Thank you @Michel Rutten . what you are saying is , creating the extensions and profile manually is best way. okay. but it's some what difficult and what should i take care while creating them manually? what's the exact process? actually in the begining i tryed that but facing problems. so i used clinfhir. so please help me.
Michel Rutten (Apr 25 2017 at 08:39):
Hi @Jayashree Surnar, actually I'm suggesting that you try to pick a tool that you like. Although it is certainly possible to author XML/JSON profiles manually, I wouldn't recommend it as it is quite involved and fairly easy to introduce errors - while developing the tools, we identified and fixed quite a number of errors in the hand-written core resource definitions. ClinFhir works great for basic use cases and has a very friendly user interface, so if you like the tool, please continue to use it! For more advanced scenario's you could use one of the other tools, e.g. Forge. Note that it is trivial to convert FHIR resources between XML and JSON, so although it may be a bit inconvenient, that shouldn't be a show stopper.
Jayashree Surnar (Apr 25 2017 at 08:49):
again thank you. @Michel Rutten . actually we are building an ipad app stu3 support. where forge willn't support stu3 right. present i'm using clinfhir but i don't know whether it's a standard or not. and for one of the screen we have to create the questions form. so to do that we are planing to use clinfhir(buildScenario) but don't know whether this process is correct? or not?
Michel Rutten (Apr 25 2017 at 09:16):
Hi @Jayashree Surnar, we are now finalizing the new Forge for STU3 release and it will be available for download ASAP. There is no "standard" tool, FHIR itself defines the standard and there are many tools available that implement (specific parts of) the standard. ClinFHIR is a profiling tool designed and used for HL7 clinical connectathons and it is widely accepted. Forge has also gained a significant user base and has been used in production scenarios since FHIR DSTU1.
You already found the Zulip streams, which is a great help for implementers. Don't hesitate to ask your questions in here, as the FHIR community is very helpful. You may even find other developers working on the same problem space.
Jayashree Surnar (Apr 25 2017 at 09:21):
okay sure. @Michel Rutten .
Jens Villadsen (Jun 01 2017 at 10:16):
I'm looking for a sound example use of ElementDefinition.type.targetProfile vs ElementDefinition.type.profile - I have a hard time understanding it so I would like to know if someone can explain it
Grahame Grieve (Jun 01 2017 at 12:08):
say the type of element is Reference(Patient)
Grahame Grieve (Jun 01 2017 at 12:08):
type.profile is a profile that applies to Reference()
Grahame Grieve (Jun 01 2017 at 12:08):
type.targetProfile applies to the Patient part
Jens Villadsen (Jun 01 2017 at 14:40):
@Grahame Grieve I don't follow. Why would type.profile differ from type.targetProfile? Let's say my profiled encounter needs to reference a profiled patient and no other patient profiles. How would profile and targetProfile differ? What is gained?
Lloyd McKenzie (Jun 01 2017 at 14:46):
"profile" would assert constraints that apply to the Reference data type. E.g. whether Reference.reference or Reference.display were required or mustSupport. "targetProfile" would assert constraints that apply to the referenced resource - Patient in this case.
Jens Villadsen (Jun 01 2017 at 15:04):
so "profile" (when marking subject in forge) in forge is a referene to Encounter.subject.reference (in my case)?
Lloyd McKenzie (Jun 01 2017 at 15:31):
profile on Encounter.subject would apply to the data type of Encounter.subject (which is Reerence). targetProfile on Encounter.subject would apply to what the reference points to
Jens Villadsen (Jun 01 2017 at 17:11):
Is there an example where this is used (eg. DAF or somewhere else)?
Oliver Egger (Jun 01 2017 at 17:59):
Hi @Jens Villadsen I have an example here for the targetProfile subject: http://chmed16af.emediplan.ch/StructureDefinition-chmed16af-mp-composition.html
Jens Villadsen (Jun 01 2017 at 18:05):
Hi @Oliver Egger - As far as I can see your example does not contain any types that both have profile AND targetProfile. I understand use of the targetProfile
Grahame Grieve (Jun 01 2017 at 20:55):
it's pretty unusual to do both, because mostly we don't take the time to profile Reference itself. But since we added .identifier, it becomes more common. Consider: you want to say:
- you have to provide a reference, and not an identifier
- the reference has to point to a US patient
Grahame Grieve (Jun 01 2017 at 20:55):
you need both for that
Eric Haas (Jun 01 2017 at 21:11):
I'll make an example and a gforge to add to profiling doco ... its bound to come up again.
Lloyd McKenzie (Jun 01 2017 at 22:05):
Even before Reference.identifier got added, you might want to have made Reference.reference 1..1 (by default it's optional, meaning you can have a Reference that just has a display). As well, you might want to insist on (or more rarely prohibit) Reference.display.
Jens Villadsen (Jun 02 2017 at 07:09):
@Grahame Grieve - now I sort of get it ... but as you point out, I would also expect it to be uncommon that one profiles the Reference it self (I could be wrong here). @Eric Haas - I'll be looking forward to see your great example :)
Grahame Grieve (Jun 02 2017 at 07:16):
yes it's not that common. But it's growing. I've done it - rule out identifier and display
Vadim Peretokin (Jun 02 2017 at 07:18):
It would be nice if the description was better, that's where I looked and it didn't help explain the situation
Grahame Grieve (Jun 02 2017 at 07:18):
do you want to create a task?
Vadim Peretokin (Jun 02 2017 at 07:19):
Yeah happily so. Actually how can I search for tasks I've already made - might have reported it before. I don't know how to filter by all tasks I've ever submitted in gforge
Vadim Peretokin (Jun 02 2017 at 07:23):
Aha, it seems to be http://gforge.hl7.org/gf/my/monitors/
Vadim Peretokin (Jun 02 2017 at 07:27):
Grahame Grieve (Jun 02 2017 at 07:29):
thx
Michel Rutten (Jun 02 2017 at 08:35):
Please note that the initial Forge STU3 release introduces support for both type.profile and type.targetProfile. However there are still a few bugs in the validation logic were it inspects the wrong field and complains. We're planning to publish a bugfix release shortly that will fix this.
Eric Haas (Jun 03 2017 at 04:04):
In SD it looks like this....
<element id="Basic.subject">
...
<type>
<code value="Reference"/>
<profile value="http://www.fhir.org/guides/ig-template/StructureDefinition/ifr"/>
<targetProfile value="http://hl7.org/fhir/us/core/StructureDefinition/us-core-patient"/>
</type>
...
Its implemented here and here but
a couple of issues with ig-pub tool so not rendering correctly ( see GF#13480)
instead of Reference(US Core Patient Profile) it should be Identifer Free Reference Data Type(US Core Patient Profile)
Jayashree Surnar (Jun 05 2017 at 07:10):
hello all,here my doubt is, if i create a patient profile based on HL7 Patient resource, and i'm using othere resources as it is. for example in AllergyIntolerance.patient is refering to the base hl7 Patient, but where as in our case we created the patient profile then again shall i need to create AllergyIntolerance profile which is ponting to our Patient profile? if yes, then un neccesarly i need to create profiles for all the Resources which are pointing to the Patient right? please any suggestions? how to solve this.
Thank you.
Lloyd McKenzie (Jun 05 2017 at 07:29):
Within an implementation guide, you can define default profiles for each resource type - so you could declare your patient profile as the default for your IG, meaning there'd be no need to profile any references to Patient so long as your ownly constraint was that they pointed to your patient profile. If you're not using an ImplementationGuide or you want to control what uses your profiled patient and what uses the generic patient, then you'll need to be explicit with profiles for all resources you use.
Richard Townley-O'Neill (Jun 06 2017 at 00:07):
Default profiles use ImplementationGuide.global
Jayashree Surnar (Jun 06 2017 at 04:07):
Thank you @Lloyd McKenzie, @Richard Townley-O'Neill for ur resposes. again i'm littlebit confusing. what you are saying is if we maintain our IG . and if i create any profiles(ex: patient) then no need to give that reference in other resources(ex:AllergyIntolerance.patient) manually right? or we have to change in each and every resources(example: if we are using other 40 resources) which are refering to patient?
Lloyd McKenzie (Jun 06 2017 at 04:12):
ImplementationGuide.global allows you to define profiles that apply to all resources in your IG that don't explicitly declare other profiles. If you validate an instance and referecence the IG, those global profiles should automatically be applied.
Jayashree Surnar (Jun 06 2017 at 04:15):
@Lloyd McKenzie i'm talking about the profiles for example http://hl7.org/fhir/us/core/StructureDefinition-us-core-allergyintolerance.html here they refering to US core patient profile.
Lloyd McKenzie (Jun 06 2017 at 04:16):
They chose to refer explicitly.
Jayashree Surnar (Jun 06 2017 at 04:21):
here if i'm using nearly 40 other HL7 resources as it is(not creating the profile). and i'm creating the Patient profile. but in other resources by default the reference would be patient(hl7) right. in this case shall i need to change that reference to our patient in all the resources manually?
Lloyd McKenzie (Jun 06 2017 at 04:38):
You don't need to do that if you define all of your profiles in the scope of an IG, your IG declares that patient profile as a default, and the validator is passed the IG when it performs the validation
Jayashree Surnar (Jun 06 2017 at 04:39):
thank you @Lloyd McKenzie
Travis Stenerson (Jun 06 2017 at 19:27):
Hi.. Apologies if this is in the wrong section. I'm trying to use an HL7 extension in one of my profiles, but the IG Publishing tool doesn't seem to like it. It tells me that I 'must have rows', and I'm unsure what that is.. my XML StructureDefinition is identical to all the examples I can find.
I've tried both building with and without the StructureDefinition of the extension downloaded from build.fhir.org. (is this necessary when it's an official extension? )
This is the relevant section of the SD, that when removed allows the IG publisher to finish.
Appreciate any guidance. Thank you.
Lloyd McKenzie (Jun 07 2017 at 01:11):
Can you show the full stack trace?
Eric Haas (Jun 07 2017 at 14:53):
@Lloyd McKenzie @Jayashree Surnar They also did not know about the global element until now (because they essentially ignored ig.xml as pretty lame - I assume the idea is to eventually merge ig.json and ig.xml into a single IG resource).
Does
- 1) global work even if the SD is being defined in the same IG
- 2) and is it reflected in the snapshot generation even if the element is not listed in the differential since you don't care about it - e.g., the
asserterelement US-Core Condition Profile.
Lloyd McKenzie (Jun 07 2017 at 16:47):
Not sure I understand ig.json vs. ig.xml? Are you talking about the JSON igPublisher config file? That's something different - though I generate mine from the ImplementationGuide resource instance. Global should work regardless of where the SD is defined. My understanding of how it works is that if the validator hits a resource and there's no other profile defined on the resource, the global profile applies. (I don't know whether/how well this works in the current validator.)
Jayashree Surnar (Jun 08 2017 at 04:22):
Thank you @Eric Haas , as i'm new to fhir i'm confusing about the IG. from where to start. as of now just we used the clinical resources. but not yet started the IG. so please any suggesions.
Grahame Grieve (Jun 08 2017 at 04:56):
ig.json is a build thing - it doesn't contain anything intended for the consumers of the Implementation Guide. Anything for consumers is in ig.xml. Most of the stuff in ig.json is specific to a particular build tool. So they will remain separate
Vikas Mittal (Jun 12 2017 at 23:09):
Hi All,
I need help to reference a local Patient profile in Medication Statement Profile.
Both the profiles (xml files) are present in the folder structure as shown in the attached snapshot.
None of the profiles has been published online and has no external uri/url.
Can you please suggest how can I reference it.
I can also attach both the MedicationStatement and the Patient profile files for your reference if required.
<StructureDefinition>
...
...
...
<differential>
<element>
<path value="MedicationStatement.subject" />
<type>
<code value="Reference" />
<targetProfile value="../StructureDefinition/dh-Patient" />
<aggregation value="referenced" />
</type>
</element>
</differential>
</StructureDefinition>
Thanks.
Grahame Grieve (Jun 13 2017 at 02:31):
in what context do you want to reference it?
Vikas Mittal (Jun 13 2017 at 03:10):
@Grahame Grieve I have to create a Medication Statement profile where for the MedicationStatement.subject I need to reference the patient profile which has been created and is locally available. We cannot publish the patient profile yet and thus need to find a way to reference it locally.
If I am able to reference this correctly and successfully then I will create a json file for Medication Statement and run that through the IG Publisher to create various artefacts.
Thus I need to know the correct syntax to be used in the MedicationStatement profile for referencing!
Grahame Grieve (Jun 13 2017 at 03:21):
oh. so the the context is the IG publisher
Grahame Grieve (Jun 13 2017 at 03:22):
the IG publisher doesn't have a way to publish something based on something that is not published
Brett Esler (Jun 13 2017 at 03:30):
if you did run the original profiles to produce an IG output you could do a local reference to the definitions.xml.zip output (relative path) by adding a dependency to the ig.json (project) doing the refererencing
Brett Esler (Jun 13 2017 at 03:30):
{
"name" : "aubase",
"location" : "http://build.fhir.org/ig/hl7au/au-fhir-base",
"source" : "resources/base"
}
Brett Esler (Jun 13 2017 at 03:31):
i.e. relative path to an IG output
Brett Esler (Jun 13 2017 at 03:32):
but would need to run Patient profile through ig builder to get an output...
Vikas Mittal (Jun 15 2017 at 03:12):
Thanks @Grahame Grieve @Brett Esler
I will try first what Brett has suggested. will ping back in case i face an issue. Cheers.
Gerhard Andreassen (Jul 06 2017 at 08:55):
Hello. Can someone please help explain this error-message i get in Forge 16.1 ?
The element subject is a reference to a Patient profile which we intend to use.
How can i fix this error and make sure that the MedicationStatement profile refers to the correct Patient profile ?
[Severity: Error] [Code: Invalid] http://test.com/FHIR/profiles/Diagnostics.MedicationStatement/MedicationStatement (Element 'MedicationStatement.subject' has an invalid type profile constraint 'http://test.com/FHIR/profiles/Clinical.Patient/Patient'. The target represents a profile on 'Patient' which is incompatible with the element type 'Reference'.)
Vadim Peretokin (Jul 06 2017 at 09:15):
I think you intend to put it into targetProfile, not profile. Give that a go
Gerhard Andreassen (Jul 06 2017 at 13:02):
Yes, that works. But there is one thing i don't understand. Why don't i get a warning or error on the Patient profile URL, when the URL is invalid ?
In the target.profile textfield, i can input whatever, and it still validates. Why is that ?
Ewout Kramer (Jul 06 2017 at 15:05):
Forge uses the .NET API to validate your inputs, and the .NET API does not validate primitives of type "uri" (which the "targetProfile" element is), since it's pretty hard to validate what's a valid uri. We have found some regexes that try, but I wasn't too sure they were completely right - and frankly people use urls that are not 100% valid - most browsers will still accept them. So, in the end, we decided not to validate uris in the .NET API Pocos....
Ashwin Kandel (Feb 06 2019 at 01:10):
Suppose I am implementing a FHIR server. I decide to use a Patient Resource, but only select/implement few of the fields specified in the base specification along with extensions.
How do i communicate this information to the consumer of my server . Do i need to create new Structural Definition to reflect the modified Patient resource used in my system ?
As per my understanding, capability statement exposes resources and what operations they support on basic level. Is there a mechanism to tell the user of my server what all fields for a certain resource is expected in my system ?
Michele Mottini (Feb 06 2019 at 01:14):
You could create a StructureDefinition with that information, but I don't think there is no standard way for a client to get to that (via API calls)
Michele Mottini (Feb 06 2019 at 01:15):
...and it does not really matter: as long as your server generates FHIR-compliant data the client would not much care which fields are actually implemented or not
Ashwin Kandel (Feb 06 2019 at 01:18):
...and it does not really matter: as long as your server generates FHIR-compliant data the client would not much care which fields are actually implemented or not
What if client send me a field for a resource whose implemention is not defined in my server ? Should i return OperationOutcome resource indicating failure message in such case .. ?
Michele Mottini (Feb 06 2019 at 01:20):
I'd say no: it would force the clients to have to craft request specifically for your server
Michele Mottini (Feb 06 2019 at 01:20):
Just ignore the data that is not supported
Lloyd McKenzie (Feb 06 2019 at 03:44):
The only exception to "ignore unsupported data" is if it's a modifier element whose meaning you don't recognize (which would typically be a modifier extension or an unrecognized uri in implicitRules. In those cases you can't safely process the instance and would need to reject, store it as a text blob of just narrative or invoke some other sort of alternate behavior.
sean zitello (Jan 07 2020 at 21:24):
This is mostly a sanity check as to my understanding of profiling and how to consume on the client side. Generally my transformation tools want to start with XSD which FHIR already provides. Consuming the us-core IG for instance, changes some of the resources adds some values sets and search parameters. That is simple process for the server as I can post those to it. From the client side, I had hoped to be able to have an XSD from the snapshot of profiles to create a new definition for the tooling. But it doesn't sound like that is possible or perhaps even advisable. In which case, not sure what to do except give the developer the IG and code appropriately. Is my understanding correct or have I missed something here?
René Spronk (Jan 09 2020 at 05:25):
XDS is able (by far) to express all of the constraints as present in a profile. As such working with XSD only ever will give you a ballpark idea of the validity of a FHIR instance. If you combine XSD with Schematron it gets a bit better, but it'll still be below par.
For a mapping kind of tool which is based on XSDs I can see why you'd like to have an XSD for a profiled resource, so at least you can take into account whether certain data elements have been made mandatory or whether they have been removed. I'm not aware that such an XSD generating capacity exists, but I'm not a tooling pundit so perhaps others can chime in.
Liam (Jan 09 2020 at 05:57):
Hi,
I have a Use Case where I need ClinicalImpression reference in Observation(not the other way around).
I can take Base Observation profile and add it as a resource reference in extensions.
Is it possible to add ClinicalImpression directly (parallel to subject,context) through profiling and not in the extensions?
Thanks
Richard Townley-O'Neill (Jan 09 2020 at 06:02):
Nope.
Profiles work with existing elements in a profile, they do not really add elements.
A profile adds an extension to a resource by working with pre-existing extension elements in the resource.
Richard Townley-O'Neill (Jan 09 2020 at 06:03):
Extensions are the only way to add elements to a resource.
Richard Townley-O'Neill (Jan 09 2020 at 06:08):
An instance of a resource, say an instance of AU Base Patient Profile can use extensions not mentioned in that profile.
Mentioning extensions in the profile without giving them a minimum cardinality of 1 (e.g. patient-birthPlace) is just documentation.
Last updated: Apr 12 2022 at 19:14 UTC
