FHIR Intellisense in ObjectScript

Discussion

Jose-Tomas Salvador · Oct 21, 2022

#Development Environment #FHIR #ObjectScript #Studio #Tips & Tricks #HealthShare #InterSystems Ideas Portal #InterSystems IRIS for Health #VSCode

Good morning, evening, night,...

A small reflection/question for today... it's true that new IRIS for Health (I4H) releases are more and more powerful each time regarding FHIR capabilities. Nowadays it allows us to consume FHIR resources with extrem easiness, we can connect with end-points in external FHIR servers very easily and make I4H act as passthrough or consume their resources... or, even more, we can define, configure and run a FHIR repository in, literally, less than 5 minutes.

However, there is one think that I miss in projects of type FHIR Façade when we have to implement a FHIR layer on top of a system that "doesn't speak" FHIR. I'm talking about the possibility of counting with help within our IDE (Studio o VS Code) when it comes to code the logic that would create the dynamic object or objects (%DynamicObject) that would represent the FHIR resource(s) we need to define......

I really believe that it would save time and help a lot to have structures/objects that represent the resources of the FHIR version with which we're working, so the intellisense mechanism in our Studio or VS Code could offer help related to properties, referenced resources/objects, etc.., and, not only that, but also that we could use those objects to define new transformations in our DTL editor, to build FHIR resources/objects from other persistent data.

Perhaps I'm the only one to miss such feature, perhaps it's a broader perception... that's why I wanted to launch the question to the Community. Did you ever find yourself in the same situation? Do you think it is an interesting feature to have? Any workaround/trick you're using to mitigate the lack of it?

Time ago I added an entry in the InterSystems site for Ideas/Suggestions, open to the community. Here you have the entry just in case you want to support it, or add ideas/workarounds, etc...

Well, that was my reflection/question.

¡¡Happy Coding!!

Go to the original post written by @Jose-Tomas Salvador

Vadim Aniskin · Oct 24, 2022

Hi @Jose-Tomas Salvador

I updated the visibility of your idea on InterSystems Ideas, now all users can read the idea, vote/comment on this idea, propose workarounds etc.

Thank you for proposing great ideas!

0 0

Dmitry Maslennikov · Oct 24, 2022

Just curious how exactly you expect to see this support. I'm not so much into FHIR, but did something, and no idea how I would expect it to see there.

Jose-Tomas Salvador · Oct 28, 2022

Thinking in how our intellisense works, we need classes generated... thinking on how FHIR work, we will need to use non-persistent objects but with features like the ones that inherite from %Dynamic*** or the ones that make use of %JSON.Adapter... so one (very general) idea would be to start from the JSON schema of a FHIR release or profile with which you need to work and have a tool that automatically generates the classes that map such schema... and those classes have to have the easiness to export/import JSON documents that %Dynamic* and %JSON.* packages give us.

We should have in mind that these are intermediary packages, no need to persist, we just need them to help us for having intellisense when manual programming FHIR resources, also to help in DTL definitions, etc... so we could have several packages, one for each FHIR release/profile we want to use: r4.*, r4uscore.*, r5il.*,... in the end the objects instanced will inherit for a common class of type %<SomeKindOfNew>DynamicObject.... that provide the helpful logic to use %ToJSON, %FromJSON, %BulkExport,... and to be used in DTL definitions from HL7 to r4.* resource... DTL from r4.* to r5.* resources,... and the capability to be easily serializable or work as virtual document if needed to be sent within our interoperability framework...

Just thinking aloud

1 0