Find

InterSystems Official
· Jul 9, 2024

InterSystems Reports version 24.1 Release Announcement

#InterSystems Reports (Logi) #InterSystems IRIS #InterSystems IRIS for Health #InterSystems Official

InterSystems Reports version 24.1 is now available from the InterSystems Software Distribution site in the Components section.  The software is labeled InterSystems Reports Designer and InterSystems Reports Server and is available for Mac OSX, Windows and Linux operating systems.  

This new release brings along some great enhancements from our partner, insightsoftware.  InterSystems Reports 24.1 is powered by Logi Report Version 24.1SP2 and includes:

  • Add external files as attachments to the labels and fields (including DBFields, formula fields, parameter fields, summary fields, and special fields) to your report.  For more information, go to this link.
  • Support for common HTML tags when rendering reports in Design mode.
  • Additional capabilities in Page Report Studio to allow for more flexibility when editing reports on the Reports Server

For more information about these features and others, see the release notes available from insightsoftware.

Note that the InterSystems Reports 24.1 installation requires JDK version 11 or 17 for the installation to execute.  Please upgrade if you are using JDK 8 prior to the InterSystems Reports installation.

For more information about InterSystems Reports, see the InterSystems documentation and learning services  content.

Discussion (0)1
Log in or sign up to continue
Question
· Jul 9, 2024

%DynamicObject (JSON) Response into Class Structure

#DTL #FHIR #HL7 #JSON #ObjectScript #HealthShare #InterSystems IRIS for Health #Health Connect #InterSystems IRIS

Using the FHIR DEMO, I have pieced together how to make a FHIR Request using OAuth against an External FHIR Repository. When I execute the Patient search (HS.FHIRServer.Interop.Request), I get a HS.FHIRServer.Interop.Response that has a Quick Stream ID, which I then use to convert the Quick Stream to a JSON Dynamic Object. if I do a trace on the Raw JSON Object, I am able to pull out single elements, however I want to pull the raw JSON into a defined Class Structure. 

I tried using fromDao(dao As %DynamicAbstractObject) As <HS.FHIRModel.R4 subclass> outlined within Working with FHIR Data

in my DTL when I would try...

Set cls = $CLASSMETHOD("HS.FHIR.DTL.vR4.Model.Resource.Patient","fromDao",dao)

I would get...

ERROR <Ens>ErrBPTerminated: Terminating BP TEST_FHIR_PATIENT_SEARCH # due to error: ERROR #5002: ObjectScript error: <METHOD DOES NOT EXIST>Transform+18^osuwmc.FHIR.PatientResposneToFHIRObject.1 *fromDao,HS.FHIR.DTL.vR4.Model.Resource.Patient> ERROR #5002: ObjectScript error: <METHOD DOES NOT EXIST>Transform+18^osuwmc.FHIR.PatientResposneToFHIRObject.1 *fromDao,HS.FHIR.DTL.vR4.Model.Resource.Patient

When I would try to transform the tRawJSON to HS.FHIR.DTL.vR4.Model.Resource.Patient using fromDao.

What could I possibly doing wrong? I want to put the JSON into a Class Structure that could be passed back to an HL7 message if needed in the case we need more information that is available via FHIR but not through the standard HL7 interface.

2 Comments
Discussion (2)1
Log in or sign up to continue
InterSystems Official
· Jul 9, 2024
Open Exchange

Git-source-control launches release 2.4.0 with a new basic mode

#Embedded Git #Git #GitHub #InterSystems Package Manager (IPM) #Open Source #Source Control #InterSystems Official

The Application Services team is pleased to announce the release of git-source-control version 2.4.0, introducing several new features to the open-source project.

For those unfamiliar, git-source-control is an embedded (or "server-side") source control tool for InterSystems products, installed through the InterSystems Package Manager.

 

 

Here are the key additions to the 2.4.0 release:

  1. Basic Mode

Basic mode presents an overall great simplification to the git workflow, suitable for users with less knowledge of git as a source control tool. The basic mode has been explicitly developed for the feature branch and trunk-based models of development.

In basic mode, the typical flow of staging, committing, pulling and then pushing has been enveloped in a 'Sync' operation. Users need only choose the 'Sync' operation from the menu, and their local changes will automatically be synchronized with the corresponding branch in the remote repository (on GitHub, GitLab, etc.).

To enable basic mode, simply navigate to the 'Settings' page of the git-source-control tool, either through the embedded menu or the web UI, and select the 'Use Basic Mode' option in the user settings at the bottom of the page.

        2. Revamped Workspace UI

The workspace section of the git-source-control Web UI provides an area for users to take actions on changes to their repository.

Previously, it was divided into four segments, a diff view, a working copy view, a commit message view and a staging area.



 

 

With the new workspace view, the working copy and staging area have been collapsed into a single list of files with checkboxes, and it's clearer that the commit message is a text field. The diff view has been enhanced, allowing uncommitted files from other IRIS users to be viewed in the diff view, which previously was not supported. We believe these changes make the user interface much more intuitive.

 

          3. Default Merge Branch

In basic mode, a new setting for the 'default merge branch' allows users to specify a branch whose remote copy will be merged into the current branch before pushing to the remote repository.

This setting was implemented to provide additional built-in support for the trunk-based source control approach. Merging with this option will also automatically resolve a common class of merge conflict that occurs when multiple developers are working on the same IRIS Interoperability production.

 

Notable Bug Fixes:

            1. Git commands changing local repository files now synchronize with IRIS

Previously, the checkout, merge, rebase, stash and discard operations did not have their changes to the local file tree reflected by IRIS. Now, upon any of these commands being run, IRIS will update to provide file versions that match the local repository, including deleting files that don't exist in the current branch, or adding files that only exist in the current branch. This also compiles the changed files, which is especially important for changes to interoperability productions to reflect in the Production Configuration page.

             2. Deleted files are now shown in the Workspace UI

Previously, files deleted in the repository would not show up as one of the changes in the workspace. This meant that deletions would go unstaged and uncommitted, leaving the deleted files lingering in the repository. In the new UI, not only do all types of file changes (including deletions) show in the workspace, but the files are also listed with the corresponding git action, such as "modified", "added", "deleted" or "renamed."

 

              3. Users with %Developer are now able to perform all actions though the package without the need for added roles

In some cases, users were unable to perform many of the package's operations with being granted additional SQL privileges. This is no longer the case, simplifying security configuration.

 

 

For a full list of features and bug fixes introduced by the 2.4.0 release, please see the changelog.md file in the git-source-control repository on GitHub.

We are always looking for feedback and improvements for the git-source-control tool! Please feel free to create a GitHub issue in the repository if you encounter a bug or think an important feature is missing.

1 Comment
Discussion (1)2
Log in or sign up to continue
Announcement
· Jul 9, 2024

[Video] Using Artificial Intelligence / Machine Learning for Pain Assessment in a Clinical Environment

#Artificial Intelligence (AI) #Global Summit 2023 #Machine Learning (ML) #Video #Summit #InterSystems IRIS for Health

Hi Community,

Watch this video to learn about the PainChek artificial intelligence technology, which assesses patient pain at the hospital bedside, leverages InterSystems IRIS interoperability to connect to third-party electronic medical record systems:

⏯ Using Artificial Intelligence / Machine Learning for Pain Assessment in a Clinical Environment @ Global Summit 2023

Presenters:
🗣 Philip Daffas, CEO and Managing Director, PainChek
🗣 James Matthias, Head of Product - Adult, Enterprise

Subscribe to our YouTube channel InterSystems Developers to get notified about new videos!

Discussion (0)1
Log in or sign up to continue
Question
· Jul 9, 2024

Has anyone worked with <MAXSTRING> in Fhir R4 Binary deserialization (From Athena)?

#DTL #FHIR #JSON #InterSystems IRIS for Health

I'm running into an intermittent issue with some of our Custom Operations/Processes as a result of some large FHIR R4 Binaries. Essentially we get a response from an AthenaHealth FHIR endpoint that appears to be too large to be processed using the IRIS Built In Functions for FHIR:

I've replicated it on the command line here using a file (binary.json) that has the response from the FHIR Endpoint. Not sharing full contents due to PHI concerns.

HSCUSTOM>S file=##class(%Stream.FileCharacter).%New()

HSCUSTOM>Do file.LinkToFile("/data/binary.json")

HSCUSTOM>w file.Size
4033045

HSCUSTOM>Set FhirBinary = ##class(HS.FHIR.DTL.vR4.Model.Resource.Binary).%New()

HSCUSTOM 2d1>Do FhirBinary.FromJSON(file,"vR4")

<MAXSTRING>%GetNext+12^%Iterator.Object.1

 

Looking into the Class Code:
 

/// Pure binary content defined by a format other than FHIR.
Class HS.FHIR.DTL.vR4.Model.Resource.Binary Extends HS.FHIR.DTL.vR4.Model.Base.Resource [ Not ProcedureBlock ]
{

/// code
/// <p>
/// MimeType of the binary content.
/// <p>
/// mimetypes|4.0.1 is the REQUIRED FHIR4 ValueSet for codes; 
/// you may NOT extend mimetypes|4.0.1 and you may NOT use codes from other ValueSets.
Property contentType As %String(MAXLEN = 1000000, XMLNAME = "contentType", XMLPROJECTION = "ATTRIBUTE") [ Required ];

/// Reference
/// <p>
/// Identifies another resource to use as proxy when enforcing access control.
/// <p>
/// Any FHIR4 Resource may be indicated by this Reference
Property securityContext As HS.FHIR.DTL.vR4.Model.Base.Reference(XMLNAME = "securityContext", XMLPROJECTION = "ELEMENT");

/// base64Binary
/// <p>
/// The actual content.
Property data As %Binary(XMLNAME = "data", XMLPROJECTION = "ATTRIBUTE");

It appears the data is stored as a %Binary (which is basically a %String) and hits the <MAXSTRING> error.

Sample data:
 

{

"contentType": "image/png",
"data": "<LONG Base64 Encoded Content>",
"id": "XXXXXXXXXXX",

"meta": {

"security": [

{

"code": "NOPAT",

"display": "no disclosure to patient, family or caregivers without attending provider's authorization",

"system": "http://terminology.hl7.org/CodeSystem/v3-ActCode"

}

]

},

"resourceType": "Binary"
}

 

I'm essentially trying to deserialize so I can get at the content-type, security, and id properties easily to determine if we do anything with the Base64 itself. It seems odd that productized code from IRIS wouldn't handle this, although I can't say I'm super confident the source data is complying to any standards outside of shape.

We could refactor our existing code to handle SOME of this using DynamicObjects:

HSCUSTOM>s dynObj={}.%FromJSON(file)

HSCUSTOM>w dynObj.contentType
image/png

HSCUSTOM>w $EXTRACT(dynObj.data,1,100) W $EXTRACT(dynObj.data,1,100)
^
<MAXSTRING>

That said, if I still need to access the binary content itself, I'm not sure the best way to handle that. If anyone has run into anything similar, I'd appreciate some feedback.

Thank you!
-Vic

1 Comment
Discussion (1)2
Log in or sign up to continue