新しい投稿

検索

Job
· 2025年6月3日

InterSystems HealthShare developer interoperability Developer/Lead

Summary:

 

Duties and Responsibilities:

Design and implement healthcare data integration solutions using the InterSystems platform /HealthShare platform, ensuring data interoperability across various healthcare systems.

Develop and maintain data mappings and transformations to ensure accurate data exchange between systems, leveraging IRIS API’s, HL7, FHIR, and other healthcare data standards.

Build and maintain interfaces to connect health information systems, including clinical applications, EHR, and other healthcare data sources.

Work closely with cross-functional teams, including developers, business analysts, and healthcare professionals, to gather requirements, design solutions, and implement integrations.

Create and maintain comprehensive documentation for integration solutions, including interface specifications, data mappings, and test plans.

Identify opportunities to improve integration processes and solutions, contributing to the overall efficiency and effectiveness of healthcare data exchange.

Education and Skills:

  • Experience with interoperability tools (like InterSystems), such as NextGen Mirth or "Availity" or "Infor" or "IRIS" or Cloverleaf or Rhapsody or Ensemble etc.
  • Experience and expertise with InterSystems IRIS, InterSystems HealthShare.
  • Familiarity / Experience working with Medical Claims data
  • Experience with Amazon Web Services (AWS).
  • Experience developing Continuous Integration / Continuous Delivery (CI/CD).
  • Knowledge and understanding of agile methodologies

Please send your profile to : Antony.Jackson@infinite.com 

antonyjacks@gmail.com

ディスカッション (0)1
続けるにはログインするか新規登録を行ってください
質問
· 2025年6月3日

What's this odd behavior with "select count()" and a Unique Index?

Hello,

I have a class with a "Unique" index (pxfactidIndex) on a %Numeric property (pxfactid) (partially-edit code snippet below):

Property pxfactid As %Library.Numeric(MAXVAL = 9223372036854775807, MINVAL = -9223372036854775808, SCALE = 0) [ SqlColumnNumber = 7 ];
Index pxfactidIndex On pxfactid [ Unique ];
Storage Default
{
<Data name="FactDefaultData">
<Value name="1">
<Value>pysubjectid</Value>
</Value>
...
<Value name="6">
<Value>pxfactid</Value>
</Value>
...
</Data>
<DataLocation>^CRMBI.FactD</DataLocation>
<DefaultData>FactDefaultData</DefaultData>
<ExtentLocation>^CRMBI.Fact</ExtentLocation>
<ExtentSize>3521840</ExtentSize>
<IdFunction>sequence</IdFunction>
<IdLocation>^CRMBI.FactD</IdLocation>
<Index name="DDLBEIndex">
<Location>^CRMBI.FactI.2</Location>
</Index>
<Index name="IDKEY">
<Location>^CRMBI.FactD</Location>
</Index>
<Index name="pxfactidIndex">
<Location>^CRMBI.Fact.4</Location>
</Index>
...
<IndexLocation>^CRMBI.FactI</IndexLocation>
<Property name="%%ID">
<AverageFieldSize>4.99</AverageFieldSize>
<Histogram>$lb(.06666666666666666667,1,0,$lb(27673,228574,456707,618301,892202,1107091,1405679,1604163,1738513,2015749,2270724,2530345,2830827,3047237,3296375,3504324),$lb(1,0,0,0,0,1,1,1,0,1,1,1,0,1,1),$lb(842479159,926299955,842544439,842151989,875902519,875902519,909195315,909195315,943272498,943272498,825307191,825243440,875574582,875574582,909128753,909128753,926103605,825701176,842019125,808531255,842477623,842477623,892547123,892547123,942878776,842543920,858797111,808728370,842610227,842610227,892351539,859123764))</Histogram>
<Selectivity>1</Selectivity>
</Property>
<Property name="pxfactid">
<AverageFieldSize>9.99</AverageFieldSize>
<Histogram>$lb(.06666666666666666667,1,0,$lb(-8377896048695389137,-7487164305435710908,-6406061662044370629,-5112561079609519767,-4588722295094185245,-4512887624516713113,-3293381287254976544,-1753938466698510428,-1561375857877981192,-211989232600898713,2857966673366783778,4457490938253726327,5246678144060189771,6591622321393794159,8944949574919674333,8944949574921469469),$lb(1,1,1,1,3,1,1,2,1,0,0,0,0,0,11),$lb(758657847,942880567,926169143,926169143,909389878,909389878,892416306,892416306,875903032,943208242,825374776,875901234,858929459,858929459,825701683,926233401,892743987,825570865,842084665,758264113,842544439,842544439,875836727,875836727,892482614,892482614,909457713,909457713,943273012,825833015,842085430,943273012))</Histogram>
<Selectivity>0.0000283942484610317%</Selectivity>
</Property>

I see the following odd behavior when counting how many records have that property set to null:

  • The first query (17) returns the number of records in the table. The 2nd query (18) returns what I expect: all records have non-null values for that "pxfactid" property. However, when I run the 3rd query (19) which counts all records with non-null values in that field, I get a much smaller, unexpected, number.

  • The 4th query (20) counts the number of records in a subquery that returns all non-null values for that property in the table and returns the expected number that matches the total number of records in the table.

Does anyone have any idea of what type of coding error would produce the odd behavior seen in query 19 (wrong number of records with non-null values in that indexed property)?

Note that the values in that field have a large range; here's a sample of some of them:

Thanks

8 Comments
ディスカッション (8)4
続けるにはログインするか新規登録を行ってください
お知らせ
· 2025年6月3日

Online Meetup with the Winners of the InterSystems FHIR and Digital Health Interoperability Contest 2025

Hi Community,

Let's meet at the online meetup with the winners of the InterSystems FHIR and Digital Health Interoperability Contest! It's a great opportunity to chat with the InterSystems Experts team and our contestants.

Winners' demo included!

Date & Time: Thursday, June 5, 11:30 am EDT | 5:30 pm CEST

Join us to learn more about winners' applications and to have a talk with our experts.

➡️ REGISTER TODAY

See you all at our virtual meetup! 

1 Comment
ディスカッション (1)1
続けるにはログインするか新規登録を行ってください
記事
· 2025年6月3日 3m read

¿Cómo gestionar la configuración de InterSystems API Manager en una canalización CI/CD?

Kong ofrece una herramienta de gestión de configuración de código abierto (escrita en Go), llamada decK, que significa declarative Kong en inglés.

  • Comprobar que deck reconoce vuestra instalación de Kong Gateway mediante deck gateway ping
deck gateway ping   
Successfully connected to Kong!
Kong version:  3.4.3.11

  • Exportar la configuración de Kong Gateway a un archivo llamado "kong.yaml" mediante el comando deck gateway dump
deck gateway dump -o kong.yaml

  • Después de modificar direcciones IP en el archivo kong.yaml, se muestran las diferencias mediante deck gateway diff
deck gateway diff kong.yaml

updating service test-iris  {
   "connect_timeout": 60000,
   "enabled": true,
-  "host": "192.168.65.1",
+  "host": "172.24.156.176",
   "id": "8fc9849d-9e61-402d-bcad-c3e611808892",
   "name": "test-iris",
   "port": 9092,
   "protocol": "http",
   "read_timeout": 60000,
   "retries": 5,
   "write_timeout": 60000
 } updating service uct  {
   "connect_timeout": 60000,
   "enabled": true,
-  "host": "192.168.65.1",
+  "host": "172.24.156.176",
   "id": "96ad587e-8921-4d6c-acb7-3f7f7a7cc072",
   "name": "uct",
   "path": "/api/uct/",
   "port": 9092,
   "protocol": "http",
   "read_timeout": 60000,
   "retries": 5,
   "write_timeout": 60000
 } Summary:
  Created: 0
  Updated: 2
  Deleted: 0
deck gateway sync kong.yaml

updating service uct  {
   "connect_timeout": 60000,
   "enabled": true,
-  "host": "192.168.65.1",
+  "host": "172.24.156.176",
   "id": "96ad587e-8921-4d6c-acb7-3f7f7a7cc072",
   "name": "uct",
   "path": "/api/uct/",
   "port": 9092,
   "protocol": "http",
   "read_timeout": 60000,
   "retries": 5,
   "write_timeout": 60000
 } updating service test-iris  {
   "connect_timeout": 60000,
   "enabled": true,
-  "host": "192.168.65.1",
+  "host": "172.24.156.176",
   "id": "8fc9849d-9e61-402d-bcad-c3e611808892",
   "name": "test-iris",
   "port": 9092,
   "protocol": "http",
   "read_timeout": 60000,
   "retries": 5,
   "write_timeout": 60000
 } Summary:
  Created: 0
  Updated: 2
  Deleted: 0
deck gateway dump --workspace workspace1
deck gateway sync workspace1.yaml --workspace workspace1

Para más información:

https://docs.konghq.com/deck/get-started

https://docs.konghq.com/deck/reference/faq/

https://github.com/Kong/deck/blob/main/CHANGELOG.md/

ディスカッション (0)1
続けるにはログインするか新規登録を行ってください
InterSystems公式
· 2025年6月3日

Version IKO 3.8

InterSystems Kubernetes Operator (IKO) 3.8 est désormais disponible. IKO 3.8 ajoute de nouvelles fonctionnalités ainsi que de nombreuses corrections de bugs et mises à jour de sécurité. Parmi les points forts :

  • Les groupes de calcul vous permettent de déployer plusieurs types de nœuds de calcul pour gérer différents types de charges de travail dans un seul cluster Iris.
  • Consolidation des volumes : vous pouvez désormais choisir de déployer avec moins de volumes, par exemple pour consolider les données et WIJ sur un même volume.

Suivez le Guide d'installation pour savoir comment télécharger, installer et démarrer avec IKO. La documentation complète d'IKO 3.8 vous fournit plus d'informations sur IKO et son utilisation avec InterSystems IRIS et InterSystems IRIS for Health. IKO peut être téléchargé depuis la page de téléchargement de WRC (recherchez Kubernetes). Le conteneur est disponible dans le registre de conteneurs InterSystems.

IKO simplifie l'utilisation d'InterSystems IRIS ou d'InterSystems IRIS for Health dans Kubernetes en fournissant une définition de ressource irisCluster facile à utiliser. Consultez la documentation pour obtenir la liste complète des fonctionnalités, notamment le partitionnement, la mise en miroir et la configuration d'ECP.

ディスカッション (0)0
続けるにはログインするか新規登録を行ってください