Rechercher

Question
· Mars 2, 2023

How Does InterSystems FHIR profile validation works?

Hi folks!

Examining FHIR profile validation with InterSystems FHIR server. FHIR profiles is a very useful feature of FHIR standard that helps an organization or solution to establish constraints to a very disperse FHIR standards that are relevant to a particular business solution. Learn more on FHIR profiles.

I created a very simple FHIR profile with the following JSON:

 
Spoiler

As you can see in "differential" section it makes mandatory fields of id, name and gender.

I managed to successfully submit the profile via the POST request to:

localhost:52773/fhir/r4/StructureDefinition

Then I submitted the following test Patient profile, where I omitted the "id" field and included the FHIR profile link in the meta section to:

localhost:52773/fhir/r4/Patient

 

{

"resourceType": "Patient",

"meta": {

"profile": [

"http://example.org/fhir/StructureDefinition/TutorialPatient"
]

},

"text": {

"div": "‹div xmlns=\"http://ww.w3.org/1999/xhtml\"><h1>Elon Musk</hi>/div>",

"status": "generated"
},

"name": [

{

"use": "official",

"given": [

"Elon"
],

"family": "Ramesh"
}

],

"gender": "male",

"birthDate": "1997-09-08",

"telecom": [

{

"value": "9876543210",

"use": "mobile",

"system": "phone"
},

{

"system": "email",

"value": "elon.musk@gmai.com"
}

]

}

And instead of the expected error I'm getting the successfully created patient.

What am i doing wrong? How are the FHIR validation profiles supposed to be used in InterSystems FHIR server?

9 Comments
Discussion (9)2
Connectez-vous ou inscrivez-vous pour continuer
Question
· Fév 24, 2023

IHE Inbound CCD Result Categorisation Customisation

Hi,

I'm currently working on an IHE implementation, and we've hit some issues around categorising inbound CCD results (i.e. mapping lab and rad results to their relevant SDA types).

I know that this is handled by the \CSP\xslt\SDA3\CDA-Support-Files\Import\Section-Modules\DiagnosticResults.xsl out of the box which can be overridden to use different logic, but I was wondering whether there's a standard/best practice approach for handling different sets of logic depending on the supplier of the CCD? We're going to be onboarding multiple data sources, so we're likely going to end up with lists of thousands of procedure codes, each mapped to a different specialty (e.g. Rad, Cell Path, Micro etc.), so I just wanted to get some thoughts on whether there's a common approach to make this as reusable (and painless) as possible.

This may end up being more of an XSLT-related question as I assume it'll likely involve referencing an external list of values from within a particular stylesheet, or is there maybe a way to call out to some objectscript to use a LUT?

Any advice or ideas would be great.

Thanks!

2 Comments
Discussion (2)3
Connectez-vous ou inscrivez-vous pour continuer
Article
· Fév 22, 2023 4m de lecture

Export to JSON - relationships and inheritance

Why I've decided to write this

Once again I had a challenge that costed me some time and a lot of testing to reach the best solution. And now that I've managed to solve it, I'd like to share a little bit of my knowledge.
 

What happened?

In a namespace there were a lot of similar classes, so to make them simpler there were a superclass with comon properties. Also, there are relationships between them. I had to export one of them to JSON, but I couldn't change the superclasses, or I would break down the flow of many other integrations.

What made it all difficult was the problem that my JSON couldn't have the properties of the superclass. Ouch! I could export and take them off one by one, but.. what if someone changes the superclass?

And even worse... what happens with the relationships? If we export a relationship, we export another whole object, with all of its properties, but I couldn't have them either in the JSON.

 

A light in the end of the tunnel

Luckily, there is always a light in the end of the tunnel, and my light is the XData.

The solution is very simple: lets call the class that I had to export ClassToExport, the class with the relationship RelatedClass and the superclass SuperClass.

We'll have:

Class project.SuperClass Extends %Persistent {
    Property CommonProperty As %String;
}
Class project.ClassToExport Extends project.SuperClass {
    Property PropertyToExport As %String;
    Relationship RelationshipToExport As project.RelatedClass [ Cardinality = many, Inverse = RelatedProperty ];
}
Class project.RelatedClass Extends project.SuperClass {
    Property DontExportThis As %String;
    Property ExportThis As %String;
    Relationship RelatedProperty As project.ClassToExport [ Cardinality = one, Inverse = RelationshipToExport ];
}

 

In ClassToExport, I write the XData: there must be a name and a tag <Mapping> with the tags <Property>. The tag <Mapping> carries the xml namespace, xmlns="http://intersystems.com/jsonmapping", and the tags <Property> carry the properties described in %JSON.MappingProperty¹ (of the official documentation).

 

The magic trick is that everything that is not specified in the mapping will be ignored. So, if we change ClassToExport to:

Class project.ClassToExport Extends project.SuperClass {
    Property PropertyToExport As %String;
    Relationship RelationshipToExport As project.RelatedClass [ Cardinality = many, Inverse = RelatedProperty ];
    XData MappingJSON {
        <Mapping xmlns = "http://intersystems.com/jsonmapping">
            <Property Name = "PropertyToExport" FieldName = "Property-JSON"/>
            <Property Name = "RelationshipToExport" FieldName = "RelatedClassJSON"/>
        </Mapping>
    }
}

we'll have in the JSON something like:

{
   "Property-JSON":"value",
   "RelatedClassJSON": [
      {"CommonProperty":"value", "DontExportThis":"value", "ExportThis":"value"},
      {"CommonProperty":"value", "DontExportThis":"value", "ExportThis":"value"}
   ]
}

So the names of the ClassToExport are ready, and only the properties we want are in the JSON, but the RelatedClass still has work to do.

 

Then, we change RelatedClass with an XData with the same name to arrange their properties:

Class project.RelatedClass Extends project.SuperClass {
    Property DontExportThis As %String;
    Property ExportThis As %String;
    Relationship RelatedProperty As project.ClassToExport [ Cardinality = one, Inverse = RelationshipToExport ];
    XData MappingJSON
    {
        <Mapping xmlns = "http://intersystems.com/jsonmapping">
            <Property Name = "DontExportThis" Include="None"/>
            <Property Name = "ExportThis" Include="INOUT"/>
            <Property Name = "CommonProperty" Include="INOUT"/>
        </Mapping>
    }
    
    
}

 

so we'll have in the JSON somehting like:

{
   "Property-JSON":"value",
   "RelatedClassJSON": [
      {"CommonProperty":"value", "ExportThis":"value"},
      {"CommonProperty":"value", "ExportThis":"value"}
   ]
}

which is what we want.

It is interesting to observe that for the property "DontExportThis", I specified a tag with INclude="None". This is the same of not putting any ta at all for that property.

 

¹ read also %JSON.PropertyParameters to understant what each property does.
 

Thank you for reading and I hope the article was useful!

Feel free to ask me for doubts or to get in touch if you think I can help in some specific case. I'll be happy to help!

Discussion (0)1
Connectez-vous ou inscrivez-vous pour continuer
Article
· Fév 12, 2023 3m de lecture

Enabling IRIS Interoperability Source Control with InterSystems Package Manager and git-source-control

Hi Developers!

As you know InterSystems IRIS Interoperability solutions contain different elements of the solution, such as: production, business rule, business process, data transformation, record mapper. And sometimes we can create and modify these elements with UI tools.  And of course we need a handy and robust way to source-control the changes made with UI tools.

For a long time this was a manual (export class, element, global, etc) or cumbersome settings procedure, so the saved time with source-control UI automation was competing with lost time to setup and maintain the settings.

Now the problem doesn't exist any more. With two approaches: package first development and usage of IPM package git-source-control by @Timothy Leavitt 
.

Meme Creator - Funny WOW IT REALLY WORKS Meme Generator at MemeCreator.org!

The details are below!

Disclaimer: this relates to a client-side approach of development, when the elements of the Interoperability production are the files in the repository.

So, this article will not be long at all, as the solution is fantastically simple.

I suppose you develop with docker and once you build the dev environment docker image with IRIS you load the solution as an IPM module. This is called "Package first" development and there is the related video and article. The basic idea is that dev-environment docker image with iris gets the solution loaded as package, as it is being deployed on a client's server.

To make a package first dev environment for your solution add a module.xml into the repository, describe all the elements of it and call "zpm load "repository/folder" command at a building phase of docker image.

I can demonstrate the idea with the example template: IRIS Interoperability template and its module.xml. Here is how the package is being loaded during docker build:

zpm "load /home/irisowner/irisdev/ -v":1:1

the source. 

See the following two lines placed before loading the package source control. Because of it source control starts working automatically for ALL the interoperability elements in the package and will export it in a proper folders in a proper format:

zpm "install git-source-control"
do ##class(%Studio.SourceControl.Interface).SourceControlClassSet("SourceControl.Git.Extension")

the source

How is it possible?

Since recently git-source-control app supports IPM pakcages for source control that are loaded in a dev mode. It reads the folder to export, and imports the structure of sources from module.xml. @Timothy Leavitt can give provide more details.

If we check in terminal the list of IPM modules after the environment is built we can see that loaded module is indeed in dev mode:

USER>zpm
=============================================================================
|| Welcome to the Package Manager Shell (ZPM).                             ||
|| Enter q/quit to exit the shell. Enter ?/help to view available commands ||
=============================================================================
zpm:USER>list
git-source-control      2.1.0
interoperability-sample 0.1.2 (DeveloperMode)
sslclient               1.0.1
zpm:USER>

Let's try? 

I cloned this repository, opened in VSCode and built the image. And below I test Interoperability UI and source control. I make a change in UI and it immediately appear in the sources and diffs:

It works! That's it! 

As a conclusion, what is needed to let you have source control for Interoperability UI elements in your project:

1. Add two lines in iris.script while building docker image:

zpm "install git-source-control"
do ##class(%Studio.SourceControl.Interface).SourceControlClassSet("SourceControl.Git.Extension")

And load your solution as a module after that, e.g. like here:

zpm "load /home/irisowner/irisdev/ -v":1:1

2. Or you can start a new one by creating repository from Interoperability template.

Thanks for reading! Comments and feedback are welcome!

8 Comments
Discussion (8)3
Connectez-vous ou inscrivez-vous pour continuer
Discussion (1)1
Connectez-vous ou inscrivez-vous pour continuer