We have an ImageViewer based on FHIR and we want to annotate certain images within a study.
We haven't found an adequate resource type for storing annotations line linear measurements, ellipse area, angle, text, etc.
On the top of that, the annotations shall point to a specific series/image pair, rather than the whole study.
What is the recommendation here? To create an extension for ImagingStudy (and have to update the whole resource for each annotation CRUD) or a separated suggested resource type?
FHIR ImagingStudy is designed to work with DICOM imaging (and especially RESTful DICOMweb) and we tried not to replicate capabilities between the two. Among other reasons, this prevents some systems from only being able to see part of the imaging record.
Therefore, annotations and image flagging should be handled using DICOM presentation states (e.g., GSPS) and Key Image Notes. The ImagingStudy can reference those instances and request images be rendered appropriately.
We are always looking for feedback on missing use cases, so please let us know on chat.fhir.org if we’ve left a gap.
Related
We want to categorize patients in our system. For example, in organ transplant, we want to "tag" a Patient FHIR resource as a donor or recipient (ignoring the scenario where a living donor can later become a recipient) since these types of "patients" are stored separately in the back end system. So when someone does a PUT HTTP request with a patient resource, we need to know what kind of patient it is before we can do the update in the database.
It's hard to determine the best way to approach this. Using the meta area seems promising, combined with the UsageContextType of "focus" perhaps, taking on values of "donor" or "recipient".
It's not clear though how to actually code something like this in a Patient resource (JSON for us). Any guidance/examples would be very much appreciated.
Sadly, I think the FHIR folks are going down the same path they used with the V3 RIM....lots of impenetrable standard definitions, but very few practical examples of how to use some of these FHIR standards in the real world. But that is another issue.
Don't understand ignoring the scenario where someone can be both donor and recipient. However, if you needed to, you could add an extension that differentiated. You could also use Patient.meta.tag.
With the RIM there'd have been an esoteric modelling mechanism to define what you wanted, likely walking through 3-4 classes to get to one element (and a whole lot of fixed values along the way). With FHIR, if you're doing something esoteric, you just define an extension.
If you see something in the core specification you find impenetrable, please submit a change request asking for the language to be improved. (There's a "propose a change" link at the bottom of every page and registration is free.)
So as a project matures it will almost certainly be necessary to modify attributes of the resource definitions to cope with additional requirements.
Let's use two trivial examples - to add a country code to a client address, or to remove a middle initial and swap in a middle name field instead.
Currently if the resource definition changes, composer won't read whatever values are extant in the repository. I didn't exhaustively try all combos, but have had to reconstitute my blockchain at least twice because of this problem.
Is there a way to mark fields either as "new" or "deprecated" to get past this that I overlooked? It will be hard to make a case to move a system that can't be changed forward to production.
In the same vein it doesn't seem to like empty or null strings much (at least for participant attributes). Having an "optional" override somewhere would save a lot of extra bounds checking in my application. Is there one of those I missed too?
So you can use the APIs or REST to expose the legacy data? You may be referring to Playground above (its not really a tool for looking at production data, its for model prototyping/sandbox/testing type stuff).
On optional question - can just add that the field is optional in the model - example here -> https://github.com/hyperledger/composer-sample-networks/blob/master/packages/pii-network/models/pii.cto#L20
I am new in FHIR, I want to develop FHIR's Server in C#, Please help me how to handle Resource within Resource. For Example in Encounter Resource, (partOf : Resource(Encounter)), similarly in Organization resource there is Organization etc, I am trying but it goes to Infinite LOOP. Not proceed to next classes.I am retrieving data from Database for time being... Thanks in advance
When you look at the definition of a Resource and you see an element with a datatype of Resource(X) (like the example you mentioned, partOf: Resource(Encounter)) this means that resource references another Resource (in this case, an Encounter). The 'partOf' element is actually an URL (or rather, an uri) pointing to another resource somewhere else on the same RESTful endpoint (or within the same message or document if you are using those constructs). So, this is more like a 'foreign key' in "traditional" database technology.
So, yes, Organizations can reference Organizations, Encounters can reference Encounters!
In my tutorial on FHIR (available at http://www.slideshare.net/ewoutkramer/fhir-tutorial-morning), you can find some examples and background from slide 29 on. Basically, this is what a reference looks like:
<partOf>
<reference value='http://spark.furore.com/fhir/Organizaiton/4433EF-33'/>
<display value="Some other organization"/>
</partOf>
Note that this is very different from containment. If you take a look at the same Encounter resource (at http://www.hl7.org/implement/standards/fhir/encounter.html), you'll see a component 'Hospitalization', this component is nested within the resource (so no reference), as indicated by the "closed diamond" shape in the UML.
In case you need an example of how to implement a .NET FHIR server, please take a look at our open-source implementation here: http://www.github.com/furore-fhir/spark. Also, be sure to get the .NET helper API's via NuGet (just look for FHIR).
With regard to the infinite loop, it's entirely possible for references to loop back to an initiating resource. While resources don't generally point directly to themselves, traversing a chain of resources and winding back up at the starting resource is quite possible. Systems that traverse links will need to account for this potential looping.
A lot of applications with a GUI can be seen as handling a collection of objects (probably at several levels). For instance, a list of contacts or a set of documents. Moreover, maybe there exists the concept of "current object" (current contact, current document or the like) in the application and some GUI controls make actions happen on this current object (and not on other objects in the collection). Obviously, the GUI should offer a way for selecting a different object as "the new current one" before applying new actions on it. I think it is a quite general situation, so maybe there is a quite general solution to where to place such a concept (for instance, an integer index on a list) in the MVC pattern.
I feel it should be out of the Model (I can think of an application with several View/Controller pairs sharing one Model and where each View has its own opinion on which object is the selected or current one), but I have not been able to confirm it by "googling".
I would like to know pointers to authors discussing this subject. Moreover, your opinion is welcome (if such kind of discussion is allowed in this forum). Thanks.
Disclaimer: my primary language is PHP, and only have experience with MVC-related patterns in the context of web (mostly with the Model2 variant of it, because of the obvious limitations of web itself), which has shaped my understanding of MVC structure.
I see the concept of Current Object as an aspect of Model Layer's state. Current object should not directly exposed to other parts of MVC triad. Both the controller(s) and view(s) have only access to it via the higher/public part (I tend to call that part "Services", but it's a bad name) of the model layer.
This lets you freely change, manipulate and swap objects, which you have marked as "current". At the same time other parts of MVC are not directly affected.
As for the materials on subject, I have not really seen any articles/books dealing exclusively with this subject. The best I can suggest is reading Patterns of Enterprise Application Architecture .. again.
I have another programmer who I'm trying to explain why it is that a UI component should not also be a data-structure.
For instance say that you get a data-structure that contains a record-set from the "database", and you wish to display that record-set in a UI component within your application.
According to this programmer (who will remain nameless, he's young and I'm teaching him...), we should subclass the data-structure into a class that will draw the UI component within our application!!!!!!
And thus according to this logic, the record-set should manage the drawing of the UI.
******Head Desk*****
I know that asking a record-set to draw itself is wrong, because, if you wish to render the same data-structure on more than one type of component on your UI, you are going to have a real mess on your hands; you'll need to extend yet another class for each and every UI component that you render from the base-class of your record-set;
I am well aware of the "cleanliness" of the of the MVC pattern (and by that what I really mean is you don't confuse your data (the Model) with your UI (the view) or the actions that take place on the data (the Controller more or less...okay not really the API should really handle that...and the Controller should just make as few calls to it as it can, telling it which view to render)) But it's certainly alot cleaner than using data-structures to render UI components!
Is there any other advice I could send his way other than the example above? I understand that when you first learn OOP you go through "a stage" where you where just want to extend everything.
Followed by a stage when you think that Design Patterns are the solution every single problem...which isn't entirely correct either...thanks Jeff.
Is there a way that I can gently nudge this kid in the right direction? Do you have any more examples that might help explain my point to him?
Have you heard of Martin Fowler?
Separating User Interface
Code
Anyway, if he wants to go further in that direction of adding render methods to his data controls, have him look at "loose coupling". It's okay to create some generic type of interface that gets him halfway there, but the UI component should take it the rest of the way.
This boils down to functional vs. non-functional responsibilities. What the data structure does and how it's visualized are two completely separate things -- essentially the root of the MVC pattern.
There's also a notion of circular dependencies here. Since the UI must know about the data structures, if you allow the data structures to then depend on the UI, you've got yourself a nice little ball of mud.
Generally on the point of decoupling:
Not only can there be different components of the UI rendering the same data structure. You may even have completely different UIs (Web, Desktop Application, ...) Now of course, you could subclass Person with WebPerson and DesktopPerson (this already sounds wrong, doesn't it? The naming is simply not about the kind of Person - it's about something else).
Each UI could work on different kinds of Persons, e.g. Teacher and Student. So we get WebPerson, WebTeacher, WebStudent, DesktopPerson, DesktopTeacher and DesktopStudent.
Now let's say, WebPerson defines the method "drawAddressFields()" to draw a web version of the address fields. But since WebTeacher has to derive from Teacher to use the additional data field "salary" (and let's assume single inheritance), it must implement "drawAddressFields()" once again!
So maybe the argument of "this will cause much more work" will help to create some motivation :-)
BTW, it will automatically lead to creating some delegate that implements the code of drawAddressField(), which will then evolve to creating a component that does the drawing separately from the data structure.