Stream: EBMonFHIR
Topic: ArtifactAssessment FHIR Resource Proposal
Brian Alper (Oct 06 2021 at 20:52):
Please use this chat stream to discuss the ArtifactAssessment FHIR Resource Proposal https://confluence.hl7.org/display/FHIR/ArtifactAssessment+Fhir+Resource+Proposal in preparation for FMG meeting October 13. The latest version of the proposed ArtifactAssessment StructureDefinition is at https://docs.google.com/spreadsheets/d/19-s6b9W0gosa-Cr5fxJtqThrTY0HView/edit#gid=1310064706
Please comment on any changes desired to the StructureDefinition to fit your needs. One element to provide feedback for is the ArifactAssessment.contributorship element which is a backbone element with many contained elements (see build.fhir.org/citation.html for Citation.relatedArtifact.contributorship). All of this data can be handled by a Citation Resource with use of ArifactAssessment.citeAsReference, and rater-specific attribution can be handled in the content. If so, are there minimum metadata elements to include at the Resource level (when not referencing a Citation Resource for attribution), such as ArtifactAssessment.publisher and ArifactAssessment.author ?
@Lloyd McKenzie @Lisa Nelson @Bryn Rhodes
Lloyd McKenzie (Oct 06 2021 at 21:53):
I don't understand why ratedArtifact isn't Reference or perhaps a choice of Reference|uri. That gives you a proper FHIR reference, a display, a resource type built in.
I don't understand having 'note' on annotation. This is one set of comments by one person at one time. Having a whole set of annotations seems weird to me (and questionable as to whether it falls into the 80% across use-cases)
In general, I think there's some challenges with the 80% rule here. For example, do we really expect that 80% of the systems that use this resource will capture copyright information about a comment? If not, then copyright should be an extension, not a core element.
Brian Alper (Oct 07 2021 at 00:46):
If we want to use a canonical url AND a display for the ratedArtifact, can we use the Reference data type and provide the canonical url in the reference element? If not, that is why we created the more complex data patterns? I believe @Bryn Rhodes was going to suggest a canonicalReference datatype which could then be a little simpler.
We could simplify to note 0..* string or note 0..* markdown. We have used note 0..* Annotation in many other resources, but in this resource there are already other structures for the author of the note as a separate component. If there is a use case that needs to add timestamps to notes that could be handled by extension.
The 80% rule may be different if considering 80% of systems using the resource for "evidence/community knowledge" as the ratedArtifact vs. 80% of systems using the resource for "patient data/medical records" as the ratedArtifact. Copyright is much more frequent concern in the former vs. confidentiality in the latter. Is there a "related concept" that would have use with a markdown datatype for the medical records context, e.g. naming the element rightsManagement or usageRights rather than copyright? Or is this better as an extension? Having the freeToShare boolean element may be a lot easier for common usage so an extension for copyright seems fine.
Lloyd McKenzie (Oct 07 2021 at 02:18):
If you want a display with a canonical URL, there's a standard extension for that. You're not allowed to use Reference and canonical together. Bryn can propose canonicalReference, but I think we're too far down the road for that.
The 80% would typically be across the full set of systems using the resource. Items that are critical to indicate utility of a resource to a narrow community might still be considered, but we generally want to ensure that the base resource doesn't contain a bunch of esoteric stuff that isn't at least going to make sense and be logical for the common uses.
Brian Alper (Oct 07 2021 at 13:25):
In the spreadsheet for the proposed StructuredDefinition https://docs.google.com/spreadsheets/d/19-s6b9W0gosa-Cr5fxJtqThrTY0HView/edit#gid=1710816721 we added an ArtifactAssessment sheet and in that the first change we made was to delete the contributorship element -- we will handle this with citeAsReference or extensions if needed
Brian Alper (Oct 07 2021 at 13:30):
We replaced 6 elements with: ArtifactAssessment.ratedArtifact[x] 0..1 Reference(Any)|uri
Lloyd McKenzie (Oct 07 2021 at 13:32):
You might consider renaming "ratedArtifact" with just "artifact", given that comments aren't necessarily "ratings".
Brian Alper (Oct 07 2021 at 13:35):
We changed note datatype from Annotation to markdown
Brian Alper (Oct 07 2021 at 13:37):
Good idea. We changed it and the cardinality to be required to:
ArtifactAssessment.artifact[x] 1..1 Reference(Any)|uri The artifact assessed, commented upon or rated. Use uri for the canonical reference
Matt Szczepankiewicz (Oct 07 2021 at 15:49):
Should "copyright" be renamed to "rightsManagement" for better interoperability outside of the US? (Discussed on 10/7 SDWG call.) @Lisa Nelson
Brian Alper (Oct 07 2021 at 15:53):
ArtifactAssessment.copyright was changed to ArtifactAssessment.rightsManagement following discussion with SD WG.
Lloyd McKenzie (Oct 07 2021 at 16:29):
copyright is the generic term we use in other resources, so if the meaning is the same, consistent naming would be preferred.
Brian Alper (Oct 13 2021 at 16:33):
change the element name back to ArtifactAssessment.copyright in the spreadsheet for proposed StructureDefinition which now addresses all the items noted in this chat stream
Brian Alper (Oct 13 2021 at 21:01):
@Grahame Grieve Do you think Scope of Coverage should be changed to:
The ArtifactAssessment Resource provides a structure to communicate any content about a knowledge artifact, including comments, corrections, classifications, and ratings. The ArtifactAssessment Resource is used when the content attribution and management rights differs from the Resource being commented upon. The scope is intended to cover assessments (added information) regarding clinical records about individual human subjects, assessments (added information) regarding healthcare provision for individual persons (such as care plans), and assessments (added information) regarding knowledge artifacts related to community knowledge such as scientific evidence and group-oriented guidance.
Brian Alper (Oct 13 2021 at 21:06):
@Grahame Grieve Do you think Resource appropriateness should be changed to:
Across healthcare communities, there are an extensive number of comments and corrections regarding resources where the commenter is not able or permitted to modify the resource content, and there are many situations in which assessments with classifications and ratings of medical record content are made by parties who would not include the assessments in the medical record. Across the academic, scientific, quality measurement development, and clinical decision support communities there is an extensive need to report assessments and feedback about knowledge artifacts. These artifact assessments may take multiple forms (including text, classifications, ratings or measurements) and may or may not be created, queried and maintained independently from the artifact being rated or commented upon.
Brian Alper (Oct 13 2021 at 21:13):
@Grahame Grieve Does it make sense to add to Resource Boundaries:
Observation Resource is used extensively for observations about people, groups, devices, locations, substances, and procedures -- all of which are physical entities and the subject element may Reference a Resource to represent the physical entity. ArtifiactAssessment may be used for observations where the subject is a knowledge artifact and the artifact element may Reference a Resource that is the knowledge artifact.
Grahame Grieve (Oct 15 2021 at 11:32):
regarding scope, @Brian Alper I winder, what 's a "knowledge artifact" - as FHIR project lead, I would say it's one of these:
Grahame Grieve (Oct 15 2021 at 11:32):
Grahame Grieve (Oct 15 2021 at 11:32):
perhaps that needs some clarification? what makes something an artifact you can assess?
Grahame Grieve (Oct 15 2021 at 11:34):
appropriateness:
not able or permitted to modify the resource content
Well, it's not always that they're not able or permitted, it's that they don't want to change it, merely to propose / discuss issues that may lead to changes or actions elsewhere
Grahame Grieve (Oct 15 2021 at 11:34):
definitely need to add that the boundaries, but I think it needs additional work
Grahame Grieve (Oct 15 2021 at 11:35):
there's the definitional question of what's a knowledge artifact.
Grahame Grieve (Oct 15 2021 at 11:36):
but also: observations are precise facts made on real world entities... at least I think they're real world entities (?). Does this mean you'd use ArtifactAssessment for anything unreal?
Grahame Grieve (Oct 15 2021 at 11:36):
I think that needs additional work.
Grahame Grieve (Oct 15 2021 at 11:37):
And it would be good to add openEHR CKM to the list of inputs, along with @Theo Stolker's care plan review system which is real world prior art in that space
Brian Alper (Oct 15 2021 at 11:44):
@Grahame Grieve To describe 'knowledge artifact' which is like Resource and to address the use case when one has management rights -- Do you think Scope of Coverage should be changed to:
The ArtifactAssessment Resource provides a structure to communicate judgments or qualitative data about a knowledge artifact (a set of data with a known identity or URL by which it can be accessed), including comments, corrections, classifications, and ratings. The ArtifactAssessment Resource is used when the content attribution and management rights differs from the Resource being commented upon, or the commenter desires to separate the comments from the target Resource. The scope is intended to cover assessments (added information) regarding clinical records about individual human subjects, assessments (added information) regarding healthcare provision for individual persons (such as care plans), and assessments (added information) regarding knowledge artifacts related to community knowledge such as scientific evidence and group-oriented guidance.
Brian Alper (Oct 15 2021 at 11:46):
Is this sentence real? That is why I tried to distinguish physical entities from digital entities or information-only entities or knowledge artifacts.
Brian Alper (Oct 15 2021 at 11:51):
@Grahame Grieve Do you suggest to add openEHR CKM as a use case? I don't see where it has a resource or component like ArtifactAssessment as a Content Source for the StructureDefinition.
Also, do you have a link to find more about @Theo Stolker 's care plan review system?
Lloyd McKenzie (Oct 15 2021 at 14:34):
Patient Empowerment wants to use this to comment on everything. I.e. they could comment on a Condition or Allergy or Procedure or any other resource. So I don't think "Knowledge Artifact" is relevant. This could also be used to allow clinicians to comment on clinical resource instances created by others (when and as organizational culture allows) when they can't update the instances directly.
Brian Alper (Oct 15 2021 at 16:36):
You could use the word "Resource" when referring to a "Knowledge Artifact" that is represented in a FHIR Resource, but does the word "Resource" imply "FHIR Resource" or is it also used to refer to external 'resources' that are not in FHIR formats? IF it can apply to non-FHIR resources, then we can just call it Resource and drop the knowledge artifact phrase.
Lloyd McKenzie (Oct 15 2021 at 16:49):
You can use 'Record' - it's pretty generic
Brian Alper (Oct 15 2021 at 17:16):
How about:
The ArtifactAssessment Resource provides a structure to communicate judgments or qualitative data about a record (a set of data with a known identity or URL by which it can be accessed), including comments, corrections, classifications, and ratings. The ArtifactAssessment Resource is used when the content attribution and management rights differs from the record being commented upon, or the commenter desires to separate the comments from the target record. The scope is intended to cover assessments (added information) regarding clinical records about individual human subjects, assessments (added information) regarding healthcare provision for individual persons (such as care plans), and assessments (added information) regarding records related to community knowledge such as scientific evidence and group-oriented guidance.
Lloyd McKenzie (Oct 15 2021 at 18:06):
I would change "a set of data" to "a resource or other set of data..."
Grahame Grieve (Oct 15 2021 at 19:00):
I feel that this is muddied the water with observation
Grahame Grieve (Oct 15 2021 at 19:00):
but it's a bit better
Grahame Grieve (Oct 15 2021 at 19:00):
openEHR CKM - the review process itself is a functional use of artifactAssessment
Brian Alper (Oct 17 2021 at 17:26):
@Grahame Grieve @Lloyd McKenzie I have updated the Resource Proposal https://confluence.hl7.org/display/FHIR/ArtifactAssessment+Fhir+Resource+Proposal with all of the concepts noted above except for the Observation Resource mention. Does this version look ready for Wednesday's FMG meeting?
Grahame Grieve (Oct 17 2021 at 20:19):
this is better, yes. Now, @Lloyd McKenzie we said we would draw wider attention to it...
Grahame Grieve (Oct 17 2021 at 20:20):
the committers channel?
Lloyd McKenzie (Oct 17 2021 at 23:38):
I'm looking at the draft resource and still have a bunch of questions:
- what's the usecase for "approvalDate" and "lastReviewDate" - who would be reviewing comments and why? And why is this core on a comment against a resource when it's typically not core for the resources being commented on?
- Definition for freeToShare is confusing to me. This isn't a concept we have anywhere else in FHIR. Is it core? Definitely needs a clearer definition
- Contributorship says "see Citation", but there is no Citation backbone element
- I thought we said that ratedArtifact would just be a choice of reference|canonical|uri?
- I thought we were dropping 'annotation' for note and just making it a simple markdown element?
- what's the difference between note and description?
- Why is rating 0..*
- It seems that we have a recursive structure, except we're duplicating stuff on the root. Why not have the base structure on the root as 0..1 with component that recurses to that base structure
- Given that rating is optional, 'rater' should be 'commenter'
- The two value sets for certainty and type don't seem to be defined
- If you're going to track a 'disposition', just a code isn't enough. You need a reason for rejections or details for persuasive if mod
- "application" seems like extension space.
Brian Alper (Oct 18 2021 at 00:49):
First look at the ArtifactAssessment Resource tab at https://docs.google.com/spreadsheets/d/19-s6b9W0gosa-Cr5fxJtqThrTY0HView/edit#gid=1710816721 instead of the original ArtifactComment Resource tab when we started this chat stream.
ArtifactAssessments are used for many things other than comments, and when a group is using it to report their collective ratings (such as a guideline development panel) there can easily be uses of approvalDate and lastReviewDate for the collective group effort. Remember this resource was started to meet complex needs in the EBM domain.
freeToShare is a simple boolean that could be considered a yes/no indicator whether this comment/classification/rating is open to the public or not. Again really important (core) for original intent of this resource. I changed the short and long definitions to "Acceptable to publicly share the resource content" and "Acceptable to publicly share the comment, classifier or rating"
contributorship is removed
ratedArtifact is now artifact[x] with datatype choices of Reference(Any)|uri
note is now simply markdown
description is the primary human-readable summary -- note is used for any additional human-readable comments
There are many situations where there can be 2 or more ratings for the same "type" -- when used for ratings (e.g. rating "risk of bias") you could have ratings of both "high risk" and "favors the intervention" for the same "type" being "risk of bias"; when using the elements for classifiers, you could have one type ("keyword") and multiple ratings (multiple keywords as codeable concepts).
There are many elements at the root that are not currently expected in the recursive components. Would it be preferable to add 6 more elements to the root (to be recursive using the base resource) or keep the current proposed structure (in which 11 additional elements are not repeated in the recursive structure)? I created ArtifactAssessment 2 as another tab to show it all recursive from the root. This is simpler for the Resource StructureDefinition and I changed a relatedComment element to become a relatedArtifact element. This could be easier overall if implementers don't find it confusing to ignore many elements on recursive use.
rating is optional, classifying is optional, commenting is optional -- we could change "rater" to "assessor" or leave as rater -- major concern with using the term "commenter" is confusion when used for ratings/assessments and thinking it is someone commenting on the rating/assessment rather than the rater/assessor -- other terms could be "author" or "creator"
EvidenceCertaintyType is defined at http://build.fhir.org/valueset-certainty-type.html
EvidenceCertaintyRating is defined at http://build.fhir.org/valueset-certainty-rating.html
The value sets do not have "Evidence" in the URL but have "Evidence" in the Name and Title as these value sets were created for the Evidence Resource. For this broader use case they are provided as Example bindings. There is no expectation for a Preferred, Extensible or Required binding for these elements that can be used for so many different use cases.
if you are going to track a 'disposition' and use an ArtifactAssessment Resource to do it, you would then use the "comment/classifier/rating" elements to elements to express a reason for rejections or details for persuasive if mod -- these rules can be described in Profiles and Implementation Guides.
If application were an "extension" then perhaps "disposition" should be an "extension" also, but several others may want the application in the core. Overall this is more of a base resource and it would be easier to implement tighter profiles for ArtifactComment, ArtifactClassifier, ArtifactRating, ArtifactRequest, and ArtifactResponse rather than creating extensions for each of these common base profiles or creating 5 base resources with a lot of overlapping elements. Perhaps ArtifactAssessment Resource is like a resource pattern (like MetadataResource Resource) and you then have 6 base resources using the pattern -- the 5 named already and ArtifactCommentRating which supports multiple types in the same resource.
Lloyd McKenzie (Oct 18 2021 at 02:10):
Is there a reason for keeping the original version of the resource? At least make the 'official' version of the resource the first tab.
My question is why are approvalDate and lastReviewDate core. Also, who is approving or reviewing?
freeToShare sounds like it's already covered by Resource.meta.security which is where we flag resources that are open to the public or have patient, provider or other types of sensitvities.
ratedArtifact should just be called 'artifact' or maybe 'focusArtifact' because rating often won't even come into play.
If description is a summary, then call it summary
note should be 0..1 not 0..*. It's markdown. You can have as many paragraphs as you like - no need for multiple repetitions.
Add a rationale that explains and provide examples for multiple ratings
My comment on recursion is "can't the original commenter rate the artifact? If so why not rename 'component' to 'comment' and drop note & description and make 'comment' 0..1. Then at the root you've got a single comment with multiple ratings and an author, plus the ability to recurse for comments about the comment
How about rename 'rater' to 'author'?
There's no ability to associate 'comments' to a disposition that I can see - and a disposition is definitely distinct from comments about a comment.
I'm ok with disposition being an extension, but application is even more an extension. I.e. some moderate percentage of systems that track comments will bother to track dispositions. And a much smaller subset will track details of application (beyond perhaps updating 'status')
Brian Alper (Oct 18 2021 at 12:39):
https://docs.google.com/spreadsheets/d/19-s6b9W0gosa-Cr5fxJtqThrTY0HView/edit#gid=873638642 will now show ArtifactAssessment 3 on the first tab. Not deleting the others yet as this is rapidly shifting and it would be difficult to reconstruct based only on the Zulip chat to see the progression.
We dropped the application elements as we realize we can use component elements of the core resource to reproduce all the concepts in the application element. Even workflowStatus and disposition could potentially be type and classifier elements though many may prefer to have these separately available as codes instead of CodeableConcepts.
We renamed the combined description and note to summary, renamed rating to classifier (easier to understand why you need 0..*), and renamed rater to author.
approvalDate and lastReviewDate are inherited from MetadataResource Resource as the underlying pattern and would have considerable meaningful use in the EBM domain. Also in the quality improvement and legal domains if using the resource to report assessments by committee.
using meta.security as a Coding with no "freeToShare" in the large extensible value set will be cumbersome for this simple boolean and we would end up with an extension anyway. We may find this freeToShare useful enough to add it to the MetadataResource Resource pattern and it would not help the community to make it harder to do at first then change it as we expect frequent use in short times with our expected implementations. There have been national and international consortial efforts wanting to share classifier tags across large systems, and this ArtifactAssessment Resource is the core resource for this function.
John Moehrke (Oct 18 2021 at 12:49):
security workgroup has worked hard to make .meta.security the place for this kind of tagging. Having it in the same place in all resources is exactly why .meta.security exists. Your comment about the valueset has no relevance. (we are in the process of cleaning it up, but the size of a valueset has no relevance on the use of a code). You can define a code and a specific meaning.
Why would you need an extension anyway? I have not been following well enough to understand.
Brian Alper (Oct 18 2021 at 13:06):
If we could add the codes FREETOSHARE and NOTFREETOSHARE this would essentially be 2 different meta.security.code element values that could serve as the simple boolean for use interfaces. Do we have to define a code system for these 2 codes to use it this way?
John Moehrke (Oct 18 2021 at 14:07):
yes you can do that. These might also be good to propose as addtions to the core codesystem. Do both, and adjust if they get accepted in the core codesystem.
Lloyd McKenzie (Oct 18 2021 at 15:09):
My leaning would be to have a meta.security code that says "unrestricted". If that's present, then you're free to share. If not, then you're not. (And details about what the restrictions are would be conveyed by other codes.)
Brian Alper (Oct 18 2021 at 15:48):
The unrestricted code exists and has a definition "Privacy metadata indicating that no level of protection is required to safeguard personal and healthcare information that has been disclosed by an authorized individual without restrictions on its use." so we think may be inaccurate when referring to ArtifactAssessment content that is not personal and healthcare information.
Lloyd McKenzie (Oct 18 2021 at 15:59):
Why would that be inaccurate? It may be that the definition should just clarify that it also covers non-personal information
Lloyd McKenzie (Oct 18 2021 at 16:01):
This isn't really a metadata resource. It's a generic resource that can be used for anything. I'm not saying you can't have approvalDate and lastReviewDate, just that they seem like they should be extensions.
John Moehrke (Oct 18 2021 at 18:24):
on the security front. are we taking about the overall tendency of ArtifactAssessment (the http://build.fhir.org/security.html#SecPrivConsiderations ), or are we talking about tagging an instance (the use of .meta.security)? -- The case you are speaking of seems to be covered by the Confidentiality Code value "L" which is designed to show that there are no privacy impacting data within that instance - https://terminology.hl7.org/CodeSystem-v3-Confidentiality.html#v3-Confidentiality-L
John Moehrke (Oct 18 2021 at 18:26):
overall, the knowledge resources would certainly seem to be http://build.fhir.org/security.html#Anonymous or possibly http://build.fhir.org/security.html#Business; but as this resource starts to expand the scope to ALL FHIR resoruces, then it needs to be identified as tendency to ALL classifications http://build.fhir.org/security.html#Unknowable.
Brian Alper (Oct 19 2021 at 14:27):
We are talking about the tagging of instances with the use of meta.security -- each ArtifactAssessment Resource instance can have a tag to determine the openness to sharing with others. When the instance contains personal data, then the concepts of privacy and corresponding codes make sense. When the instance contains intellectual property considered for publication, then the concepts of copyright and rights management authorization are more relevant than the concepts of personal data protection. If the codes for simple "free to share" concepts are not immediately clear to implementers the community will use a freeToShare extension instead of meta.security -- there is a substantial community in the digital publishing space that will not catch on to FHIR quickly if this simple concept is made too complicated.
Brian Alper (Oct 19 2021 at 14:31):
"The MetadataResource represents resources that carry additional publication metadata over other canonical resources, describing their review and use in more details." This is a key driver for the ArtifactAssessment Resource, and the very reason we are discussing freeToShare and other additional publication metadata concepts. After viewing the introductory statement to PlanDefinition Resource Proposal we will add the following to the first line of the ArtifactAssessment Resource Proposal:
The ArtifactAssessment Resource represents one or more assessments of another record or resource. The resource captures metadata about the assessment, as well as the data for the results of the assessment which may include comments, classifications, ratings, questions, and responses.
Lloyd McKenzie (Oct 19 2021 at 18:55):
meta.security is about data protection policies in general, not only about personal information. It's just that the vast majority of codes defined are in the "personal data" space because that's where most of the identified need has come from.
John Moehrke (Oct 19 2021 at 21:17):
yes, so you are looking for licensing vocabulary. Very mind opening concept. These vocabulary do exist, we should use them. Yes, these vocabulary can be used on .meta.security.
- Creative Commons vocabulary -- https://creativecommons.org/about/cclicenses/
- others?
we should look to existing vocabulary if it fits. but certainly could go beyond.
John Moehrke (Oct 19 2021 at 21:21):
This said... we have brought copyright in as a first-class element in some resources (e.g. StructureDefinition.copyright). Where these exist, they tend to just be narrative. Very interesting to use the .meta.security to hold a code when appropriate. Such as when HL7 publishes an IG it tends to be published as http://creativecommons.org/publicdomain/zero/1.0/
John Moehrke (Oct 19 2021 at 21:22):
code can only say what kind of license, not who the license holder is... but I do like the idea. and I do think this is consistent with .meta.security.
Brian Alper (Oct 21 2021 at 17:56):
2021-10-21 discussion with OO changed the proposed Resource Boundaries to include:
Observation Resource is used extensively for observations about people, groups, devices, locations, substances, and procedures – not about the record describing these entities. ArtifiactAssessment is used for observations where the subject is the artifact or record, not the entity described by the artifact. Simple "assessments" about an Observation such as status, dataAbsentReason, interpretation and note would use the Observation Resource where this is already structured. ArtifactAssessment Resource may be used for complex assessments of an Observation such as justifications for reasons to correct the record.
Lloyd McKenzie (Oct 21 2021 at 20:19):
Will Observation be updated to make clear that they don't cover Observations about records?
Grahame Grieve (Oct 24 2021 at 21:07):
well, hard for Brian to answer that. Someone should create a task to ask OO to make that clarification
Bryn Rhodes (Nov 23 2021 at 21:32):
ArtifactAssessment resource is in the build now: https://build.fhir.org/artifactassessment.html
Last updated: Apr 12 2022 at 19:14 UTC
