发布新帖

查找

InterSystems 官方
· 二月 16, 2023

Speeding up AND becoming more predictable - updates to our release cadence

InterSystems periodically updates our software release policies and practices to adjust to customer needs.

We're now changing our maintenance release cadence in order to be more predictable for customers and partners, and tweaking a few other areas.

This article summarizes the release cadence for our Data Platforms products and recent changes to it, and announces a few new updates.

Why change?

  • Our customers are taking our new releases more quickly.
  • Our customers are adopting new platforms versions (operating systems and orchestrators) more quickly.
  • Security issues are arising more frequently, especially in third-party libraries.
  • Our customers are asking for more predictable delivery dates.

What's the same? Reminder of our feature release cadence

InterSystems has been using a two-stream feature release cadence with InterSystems IRIS since 2018 (see the original announcement). We provide:

  • Continuous delivery (CD) releases—these releases provide access to new features quickly and are ideal for developing and deploying applications that are continuously being updated and can take immediate advantage of new features. Sometimes called the fast train.
  • Extended maintenance (EM) releases—these releases are less frequent than the continuous delivery releases but provide the increased stability of maintenance releases. They are ideal for large enterprise applications where the ease of getting fixes in maintenance releases is more important than getting early access to new features. Sometimes called the slow train.

EM releases are easy to identify because their version number is YYYY.1 (for example 2022.1 or 2023.1).   CD Releases will have a version number of the form YYYY.2, YYYY.3 etc.

A year ago, we evolved our cadence, adding kits for CD releases and adding HealthShare Health Connect into these release trains alongside InterSystems IRIS and InterSystems IRIS for Health. (See the February 2022 update.) A few restrictions on the fast train CD releases remain: there are no maintenance or security updates; there is no in-place conversion from Caché or Ensemble; and the upgrade path for a CD release is limited to the next CD release or the next EM version.

Feature releases (both EM and CD releases) go through a preview phase where customers can download and work with new releases, to help get ready for a new release.  Previews are a great time to provide feedback and test to be sure your application works well with the new release.  Starting with 2022.2 we began updating previews every 2 weeks, always on a Wednesday.

Feedback on the release cadence and these updates has been very positive, and we've been able to manage the two-stream release cadence while maintaining extremely high quality.

Platform updates

Customers are adopting new operating systems much faster, especially in the cloud. We have changed our cadence accordingly. In 2022, we began adding new operating systems support in maintenance releases. 2022.1.1 added Ubuntu 22.04 support; 2022.1.2 added RHEL 9 support. This approach means that customers can adopt new operating systems much earlier.

Security changes are coming more frequently, especially for common libraries packaged with those operating systems, such as OpenSSL.  With our 2022.1 release we began using the OpenSSL libraries from the operating system, so that customers can keep current on security updates via the OS.    This also means compiling and packaging separate kits for each major version of a Linux operating system.   We limit these to two major versions in each EM release. If we introduce new OS support in a maintenance release, we won't remove any earlier versions, so there may be three sets of kits;  this is trimmed down to two with the next EM release.   For example, 2022.1.2 has three sets of Red Hat kits (RHEL 7, RHEL 8, and RHEL 9); 2022.1.3 will have the same sets of kits, but 2023.1.0 will include only RHEL 8 and RHEL 9 kits.

Because platform changes are speeding up, we want to give customers visibility into what is coming up.  We've introduced a quarterly "platforms update" in a newsletter format; you can read the first issue on the developer community.  Please give us any feedback you may have on the format, the time horizon, etc.

Maintenance and security updates

We continue to provide maintenance updates on InterSystems IRIS for two years, as well as maintenance updates on Caché and Ensemble (see Minimum Supported Version). In addition to maintenance updates, we provide security corrections.

We refer to the sequence of releases that update an EM release, across all associated products and platforms, as a stream. For example, 2021.1.0, 2021.1.1, 2021.1.2 is a stream, and 2022.1.0, 2022.1.1, 2022.1.2 is a different stream. This means that we are providing maintenance releases for three streams (the most current EM and previous EM of InterSystems IRIS, InterSystems IRIS for Health, and Health Connect, as well as Caché and Ensemble, which is its own stream).

Starting in April 2023, InterSystems will provide security corrections for the current and the last three years of InterSystems IRIS releases, as well as the latest maintenance release of Caché.  This means that security corrections are provided for two additional streams beyond maintenance updates (a total of five streams). For example, in 2024, InterSystems will provide security fixes for InterSystems IRIS versions 2021.1.x, 2022.1.x, 2023.1.x, as well as the then-current version 2024.1.x; InterSystems will also provide security corrections for Caché 2018.1.x. 

We recently improved our security vulnerability handling policy to accommodate the higher volume of security issues we're seeing, most of which are low or medium severity (see Updated Security Vulnerability Handling Policy). We now include security updates in every release. Information about high and critical severity issues is embargoed (to prevent providing information that could be used to exploit security vulnerabilities) until these issues are addressed in all supported streams—at which point we issue a security alert with details of the vulnerabilities that have been addressed.

Predictable maintenance releases

Customers tell us that they appreciate getting regular software updates and want to be able to make plans based on when they can expect them. We are now formalizing our maintenance release schedule, as follows:

  • Most recent InterSystems IRIS stream: maintenance release every three months.
  • Previous InterSystems IRIS stream: maintenance release every six months.
  • Caché and Ensemble: maintenance release every twelve months.

We published a maintenance release for the InterSystems IRIS 2022.1 stream on January 18 (see 2022.1.2 release announcement). We plan to publish maintenance releases for the InterSystems IRIS 2021.1 stream and the Caché and Ensemble 2018.1 stream on February 28.

In 2023, we plan to have one EM release (2023.1) and two CD releases (2023.2 and 2023.3). Once 2023.1.0 is generally available (GA), it becomes the most recent InterSystems IRIS stream, and 2022.1 becomes the previous stream.

Removing previous releases from the WRC (but not the ICR)

Because our releases have become more frequent and we publish more kits (one per major Linux OS version), the number of available versions on the WRC software distribution site has grown significantly and has become confusing to some customers. We are adopting a new practice of regularly removing older versions in each stream from the distribution site.

  • Only the most recent CD version will be visible—because 2022.3 is now generally available, we'll be removing the 2022.2 images at the end of February.
  • Only the most recent maintenance version per stream will be visible—2022.1.1 was removed when 2022.1.2 was published. This prevents the problem of customers mistakenly installing software with known security issues.

Previous versions are available on request. We also suggest that customers who standardize on a single version for many sites keep their own copy of the kit for that version. To ensure integrity, all kits and containers are signed; checksum files and PGP signature files are downloadable from the WRC distribution site.

We work differently with containers published on the InterSystems Container Repository (ICR), because customers typically use specific versions in CI/CD pipelines. We won't prune old images from the ICR until they are two years old. We recommend that customers keep their CI/CD pipelines current, and the feedback we receive is that they do.

Committed to customer success

All of the changes described in this article have been made with the intent of helping customers succeed. We're listening to our customers' concerns about security issues, platform adoption, maintenance updates, and release cadence and changing things based on that feedback. Please don't hesitate to contact us with feedback and suggestions!

讨论 (0)2
登录或注册以继续
问题
· 二月 16, 2023

HealthShare Health Connect version

Can someone confirm that HealthShare Health Connect 2022.2 is the correct latest release that is available via the Online Distribution? I tried looking at the HealthShare Health Connect on WRC and now do not see a 2022.2 or 2022.3 version. Is this correct? So I shouldn't be running 2022.2? Did Health Connect get renamed? A couple of months ago I downloaded HealthConnect-2022.2.0.368.0-lnxrh8x64 but not seeing it now on the WRC site.

2 Comments
讨论 (2)2
登录或注册以继续
文章
· 二月 15, 2023 阅读大约需 11 分钟

ChatGPT to create message transformations for you?

A "big" or "small" ask for ChatGPT?


I tried OpenAI GPT's coding model a couple of weeks ago, to see whether it can do e.g. some message transformations between healthcare protocols. It surely "can", to a seemingly fair degree. 

It has been nearly 3 weeks, and it's a long, long time for ChatGPT, so I am wondering how quickly it grows up by now, and whether it could do some of integration engineer jobs for us, e.g. can it create an InterSystems COS DTL tool to turn the HL7 into FHIR message? 

Immediately I got some quick answers, in less than one minute or two.


Test

First I want to test I am talking to the right "guy" behind it.


Question 1:  how to convert HL7 V2.4 messages to FHIR STU3?


ChatGPT:

Converting HL7 V2.4 messages to FHIR STU3 involves several steps, as the two standards have different data models and structures. Here is a high-level overview of the process:

  1. Identify the relevant data elements in the HL7 message that need to be mapped to FHIR resources. This will depend on the specific use case and data being exchanged.
  2. Define the mapping rules for each data element. This involves identifying the equivalent FHIR resource and element that corresponds to the HL7 data element, and any necessary transformations or translations.
  3. Write a program or script that can extract the data from the HL7 message, apply the mapping rules, and create the corresponding FHIR resources. This may involve using a combination of regular expressions, parsing libraries, and FHIR resource creation libraries.
  4. Validate the FHIR resources against the STU3 specification to ensure they conform to the standard and contain all required elements.

Here is an example of how this process might look for converting an HL7 V2.4 observation message to a FHIR STU3 Observation resource:

  1. Identify the relevant data elements in the HL7 message, such as the observation code, value, and units.
  2. Define the mapping rules for each data element, such as mapping the HL7 observation code to a FHIR CodeableConcept and the value and units to a FHIR Quantity.
  3. Write a program or script that can extract the data from the HL7 message, apply the mapping rules, and create a FHIR Observation resource with the appropriate elements.
  4. Validate the FHIR Observation resource against the STU3 specification to ensure it contains all required elements and is valid.

The specific implementation details will depend on the programming language and libraries used, as well as the specific HL7 message and FHIR resource being mapped. It's recommended to consult the HL7 and FHIR specifications and seek expert advice if needed.


Well, it not just sounds about right - it actually answers more comprehensively than most human would do. It gets my attention now, so let's jump into it.   
 


Question 2: Can you create a sample transformation in Python to convert HL7 to FHIR  


ChatGPT:

Sure! Here's a sample Python code snippet that demonstrates how to convert an HL7 message into a FHIR STU3 Observation resource:

from hl7apy import core
from fhir.resources.observation import Observation
# Parse the HL7 message
hl7_message = 'MSH|^~\&|SENDING_APP|SENDING_FACILITY|RECEIVING_APP|RECEIVING_FACILITY|20220527120512||ORU^R01|MSGID12345|P|2.4\r' \
              'OBX|1|NM|GLU^Glucose||100|mg/dL||N|||F|||20220527120512\r'
hl7_parsed = core.parse_message(hl7_message)

# Map HL7 elements to FHIR elements
observation = Observation()

observation.code = {
    "coding": [{
        "system": "http://loinc.org",
        "code": hl7_parsed.obx[0].observation_id.value,
        "display": hl7_parsed.obx[0].observation_id.value
    }]
}

observation.valueQuantity = {
    "value": hl7_parsed.obx[0].value.value,
    "unit": hl7_parsed.obx[0].units.value,
    "system": "http://unitsofmeasure.org",
    "code": hl7_parsed.obx[0].units.value
}

# Serialize the FHIR resource as JSON
observation_json = observation.json()

# Print the serialized FHIR resource
print(observation_json)



This code uses the hl7apy library to parse the HL7 message and extract the relevant data elements, and the fhir.resources.observation class from the fhir.resources module to create a FHIR Observation resource.

In this example, the code maps the HL7 observation ID to the FHIR code element, and the HL7 value and units to the FHIR valueQuantity element. The FHIR resource is then serialized as JSON using the json() method.

Note that this is a simple example and you may need to map more data elements depending on your specific use case. Additionally, you will need to install the hl7apy and fhir.resources libraries to run this code.


 

It's not a bad answer at all - gives a decent boilerplate code. Let's give it a bit specific challenge now: 


Questions 3: Can you give a sample transformation from HL7 V2 to FHIR Stu3 in Intersystems COS DTL


ChatGPT:


Certainly! Here's an example of how to transform an HL7 V2 message to a FHIR STU3 Observation resource in InterSystems COS DTL (Data Transformation Language):

Class DTL.HL7toFHIR Extends %RegisteredObject
{

ClassMethod TransformHL7ToObservation(hl7Message As %String) As %String [ CodeMode = expression, DDLAllowed = 0 ]
{
    set src = ##class(EnsLib.HL7.Message).%New()
    set src.DocType = "2.4"
    set src.Parse(hl7Message)

    set obs = ##class(FHIR.Resource.Observation).%New()
    set obs.subject = { "reference": "Patient/"_src.MSH.GetSendingApplication() }
    set obs.status = "final"
    set loincCode = src.GetSegment("OBX", 1).GetField(3).GetField(1)
    set obs.code = { 
        "coding": [ 
            {
                "system": "http://loinc.org", 
                "code": loincCode, 
                "display": loincCode 
            }
        ]
    }

    set value = src.GetSegment("OBX", 1).GetField(5).GetField(1)
    set units = src.GetSegment("OBX", 1).GetField(6).GetField(1)
    set obs.valueQuantity = { 
        "value": value, 
        "unit": units, 
        "system": "http://unitsofmeasure.org", 
        "code": units 
    }

    quit obs.%ToJSON()
}

}

This code defines a class method called TransformHL7ToObservation that takes an HL7 V2 message as input and returns a FHIR STU3 Observation resource as a JSON string.

The method first creates a new EnsLib.HL7.Message object and uses it to parse the input HL7 message. It then creates a new FHIR.Resource.Observation object and sets the subject and status elements.

Next, the code extracts the LOINC code, value, and units from the HL7 message and maps them to the corresponding elements in the FHIR resource.

Finally, the method serializes the FHIR resource as JSON and returns it.

To use this class method, you can call it from another COS method or from an external system using InterSystems' REST API. Here's an example of how to call the method from another COS method:

set hl7Message = "MSH|^~\&|SENDING_APP|SENDING_FACILITY|RECEIVING_APP|RECEIVING_FACILITY|20220527120512||ORU^R01|MSGID12345|P|2.4\rOBX|1|NM|GLU^Glucose||100|mg/dL||N|||F|||20220527120512\r"
set fhirObservation = ##class(DTL.HL7toFHIR).TransformHL7ToObservation(hl7Message)
write fhirObservation

Note that you will need to define the EnsLib.HL7.Message and FHIR.Resource.Observation classes in your InterSystems environment and have the appropriate permissions to run COS code.


 

Well, that's probably the most effective yet comprehensive answer we could ever have expected within about 25 seconds. Right?

(Please note: the above COS sample isn't perfectly accurate. It's only a boilerplate structure, needs more fine-tuning for real-world implementations. As @Tete Zhang kindly pointed, Ensemble level HL7 message class uses ImportFromSting() instead of Parse(); DocType should be more specific etc. And apparently it seemed to create a new FHIR class hierarchy on its own from the COS ground up, instead of using existing HealthShare's built-in FHIR STU3 plumbings. Its "thought process" appears to be following the previous answer of Python structure. It's not going to achieve an Ensemble or HealthShare certification for now, and has a lot to learn with more specialist interactions, but as an excuse we might have to pardon it for its first trial in less than 2 minutes so far, by today?  )   
  

Now that we are here, we need to be fair to other widely used options I have been enjoying too. So I carried on a few more questions with slightly more faith:


Question 4: Can you give a sample transformation from HL7 V2 to FHIR Stu3 in Orion Rhapsody


ChatGPT:

Certainly! Here's an example of how to transform an HL7 V2 message to a FHIR STU3 Observation resource in Orion Rhapsody:

  1. First, create a new Rhapsody channel and add an HL7 Connector component to receive the input HL7 V2 message.
  2. Add a new Data Transformation component to the channel and configure it to use a custom script.
  3. In the Data Transformation component, add the following script to transform the HL7 V2 message to a FHIR STU3 Observation resource:
function transform(msg) {

    var hl7 = Packages.ca.uhn.hl7v2.model.v24.message.ORU_R01(msg.getRawData());

    var observation = new Packages.org.hl7.fhir.dstu3.model.Observation();
    observation.setStatus(Packages.org.hl7.fhir.dstu3.model.Observation.ObservationStatus.FINAL);

    var codeableConcept = new Packages.org.hl7.fhir.dstu3.model.CodeableConcept();
    var coding = new Packages.org.hl7.fhir.dstu3.model.Coding();
    coding.setSystem("http://loinc.org");
    coding.setCode(hl7.getRESPONSE().getORDER_OBSERVATION()[0].getOBR().getUniversalServiceIdentifier().getIdentifier().getValue());
    coding.setDisplay(hl7.getRESPONSE().getORDER_OBSERVATION()[0].getOBR().getUniversalServiceIdentifier().getText().getValue());
    codeableConcept.addCoding(coding);
    observation.setCode(codeableConcept);

    var quantity = new Packages.org.hl7.fhir.dstu3.model.Quantity();
    quantity.setValue(hl7.getRESPONSE().getORDER_OBSERVATION()[0].getOBSERVATION()[0].getOBX().getObservationValue()[0].getValue().getValue());
    quantity.setUnit(hl7.getRESPONSE().getORDER_OBSERVATION()[0].getOBSERVATION()[0].getOBX().getUnits().getText().getValue());
    observation.setValue(quantity);

    var reference = new Packages.org.hl7.fhir.dstu3.model.Reference();
    reference.setReference("Patient/" + hl7.getPATIENT_RESULT().getPATIENT().getPid3_PatientIdentifierList()[0].getID().getValue());
    observation.setSubject(reference);

    return JSON.stringify(observation);
}
  1. Save the script and test the transformation by sending an HL7 V2 message to the channel. The transformed FHIR STU3 Observation resource should be output by the Data Transformation component in JSON format.

This script uses the HAPI FHIR and HAPI HL7 v2 libraries, which are included with Orion Rhapsody. It starts by parsing the input HL7 V2 message using the HAPI HL7 library.

Next, the script creates a new FHIR STU3 Observation resource and sets its status, code, value, and subject elements based on the corresponding values in the HL7 message.

Finally, the script serializes the FHIR resource as JSON and returns it.

Note that this is just a simple example and may not work for all HL7 V2 message types or FHIR resources. You may need to modify the script to handle different message types or map additional fields to the FHIR resource.


 


Questions 5 Can you create a sample transformation converting HL7 v2.4 to FHIR R4 in Mirth integration engine


ChatGPT

Certainly! Here's an example of how to transform an HL7 V2.4 message to a FHIR R4 Observation resource in Mirth:

  1. First, create a new Mirth channel and add an HL7v2 Listener source connector to receive the input HL7 V2 message.
  2. Add a new JavaScript Writer destination connector to the channel and configure it to use a custom script.
  3. In the JavaScript Writer connector, add the following script to transform the HL7 V2 message to a FHIR R4 Observation resource:
var hl7msg = msg['HL7v2 Message'].toString(); // get the HL7 V2 message
var hl7data = Packages.ca.uhn.hl7v2.parser.Parser.parse(hl7msg); // parse the message with the HAPI HL7 parser
// extract values from the HL7 message and create the FHIR resource
var obs = new Packages.org.hl7.fhir.r4.model.Observation();
obs.setStatus(Packages.org.hl7.fhir.r4.model.Observation.ObservationStatus.FINAL);

var code = new Packages.org.hl7.fhir.r4.model.CodeableConcept();
code.addCoding()
  .setSystem("http://loinc.org")
  .setCode(hl7data.get("OBR-4-1").getValue())
  .setDisplay(hl7data.get("OBR-4-2").getValue());
obs.setCode(code);

var value = new Packages.org.hl7.fhir.r4.model.Quantity();
value.setValue(hl7data.get("OBX-5-1").getValue());
value.setUnit(hl7data.get("OBX-6").getValue());
obs.setValue(value);

var subject = new Packages.org.hl7.fhir.r4.model.Reference();
subject.setReference("Patient/" + hl7data.get("PID-3-1").getValue());
obs.setSubject(subject);

// output the FHIR resource as JSON
var json = org.hl7.fhir.r4.formats.JsonParser().setPrettyPrint(true).encodeResourceToString(obs);
return json;
  1. Save the script and test the transformation by sending an HL7 V2 message to the channel. The transformed FHIR R4 Observation resource should be output by the JavaScript Writer connector in JSON format.

This script uses the HAPI FHIR and HAPI HL7 v2 libraries, which are included with Mirth. It starts by extracting the HL7 V2 message from the Mirth message object and parsing it with the HAPI HL7 parser.

Next, the script creates a new FHIR R4 Observation resource and sets its status, code, value, and subject elements based on the corresponding values in the HL7 message.

Finally, the script serializes the FHIR resource as JSON and returns it.

Note that this is just a simple example and may not work for all HL7 V2 message types or FHIR resources. You may need to modify the script to handle different message types or map additional fields to the FHIR resource.



Conclusions?


I don't have any conclusions or next steps anymore, since even my imagination can't catch up with its leaps.  It looks as if there were only limited options for me now:  either I can spend time in picking out its imperfect coding styles, or I can re-think of what's left on my plate in another few weeks? I need to think carefully more than ever about the potential of this thing. :)

Joking aside, while I am enjoying posting on this forum (thanks to the hosts), another thought comes to my mind would be, this "could" actually be an important enabler for some competitive niche player to leap forward to mass market, right?   It used to take years to be really comfortable with some coding languages and scripts, due to various reasons, but now the landscape is moving, and with ChatGPT it not only offers well-composed documentation, instructions and samples, but it might also be able to automatically manufacture the engineering tools of your choice over the coming months or years, right?  It seems to be able to level up the play ground in "languages", and eventually the non-functional side of features such as performance etc service qualities would look more  outstanding.  

7 Comments
讨论 (7)3
登录或注册以继续
问题
· 二月 14, 2023

SOAP - How to create soap and call my StoredProc function from external website?

Hi Every one

 

I'm working on how to use SOAP with my API and StoredProc.

Currently, the method I use is csp page to be able to get pamater from external website and Call my StoredcProc
Step 1 Get pamameter from external site
Step 2 Run My Storeproc
Step 3 Return JSON format

 

How to create soap and call StoredProc function from external website?

3 Comments
讨论 (3)2
登录或注册以继续
公告
· 二月 14, 2023

[Video] InterSystems Startup Accelerator Pitching Sessions

Hi Developers,

Enjoy watching the new video on InterSystems Developers YouTube:

⏯ InterSystems Startup Accelerator Pitching Sessions @ Global Summit 2022

Check out the innovative solutions introduced by cutting-edge healthcare startups. Members of InterSystems 2022 FHIR Startup Accelerator - Caelestinus - will present their solutions, all built on InterSystems FHIR Cloud and Health Connect services.

Presenters

🗣 @Evgeny Shvarov, Startups and Community Manager, InterSystems
🗣 @Dean Andrews, Head of Developer Relations, InterSystems
🗣 Martin Zubek, Business Development Manager
🗣 Tomas Studenik, Caelestinus Incubator cofounder

Enjoy watching and stay tuned! 👍

讨论 (0)2
登录或注册以继续