Conversation
Volume 1 and 3 mostly there, numbers updated, many build issues resolved, plantuml revised, formatting, etc
|
|
||
| * started 1..1 MS | ||
|
|
||
| //TODO Kinson - Do we need to keep the following for IDR? And would Endpoint.fsh migrate into examples? |
There was a problem hiding this comment.
There is already an example for Endpoint.fsh used in ImagingStudy. We can discuss if this is a mandatory constraint. Basically currently ImagingStudy is setup so that it must be retrievable when it is referenced in a DiagnosticReport. If this is unnecessary, then we can remove this constraint.
This is inherit from IMR since in IMR, a requirement is the report can have references to the images which allows the user to interact with them.
So arguably, this is not an IDR constraint but an IMR constraint.
| May specify details about how the ordered procedure is to be performed, such as imaging teechnique parameters to use or views to be obtained. Typically, however, such details are left to the imaging department. | ||
| """ | ||
|
|
||
| //TODO Kinson - what was the motivation for this value set? |
There was a problem hiding this comment.
The motivation of this VS is to constraint on the intention that are applicable to radiology workflow. The base FHIR supports other intent like 'Option' that may not be applicable in radiology.
With this said, if IDR supports creating a planned ServiceRequest for follow up studies, then the intent should perhaps include 'proposal' or 'plan' as well.
Alternatively, we can drop this VS and just use the base FHIR VS.
| * #imaging-impression "Imaging Impression" | ||
| * ^experimental = false | ||
|
|
||
| //TODO Kinson - is this for the actionability codes? Should be able to take those from RadLex? |
There was a problem hiding this comment.
This was created initially to allow quick identification if a condition is a finding or impression. Finding is dropped since IDR focuses on impression.
This is a general code to differentiate impression from any other condition in the FHIR server. I saw that there is a TODO for Condition.category. For sure if we have better RadLex / LOINC code to use here, we can switch. Or at least make Condition.category uses this VS but it is extensible rather than required.
3 participants
📑 Description
This pull request is for the primary migration of the TI text in Word into IG format.
Look for TODO and TODO Kinson in the files for things that need feedback and/or work
The .fsh is based on R5 to reduce the number of extensions. At some point we will rebase on R4 and leverage the R4-R5 extensions package (hopefully). There are also changes in progress for R6.
✅ Checks
It built locally on R5 with no errors. Supressing some warnings. Need some tidy up.
Haven't checked the remote build yet.
ℹ Additional Information