Yes, I was able to create separate roles, and copy the existing Data Lookup pages, locking the users down to only being able to access that particular page for their lookup tables. There are two class files that would need to be created.
1. Filter Dialog if you want to limit the users down to their particular tables.
2. A copy of EnsPortal.LookupSettings - which will limit users ability to get to other places within Ensemble.
I haven't tested this in IRIS just yet as we are in the process of moving to IRIS.
If a Business Router is sending to a file based HL7 operation, I am seeing NULL values being returned. How can I tell the system that if we are sending a message to a File Based HL7 Business Operation that I don't expect a Return and avoid receiving the NULL value back?
Thanks that helped a lot. However I am seeing when I make a call to send the HL7 message to an operation, the callresponse is coming back NULL. Is there a way to send the message but make the process think we don't need a response back?
Can you show me a screen shot of what you mean by
"Routing rules that are called synchronous respond with a "NULL" message when the Response From parameter is empty.
The fix was to set the Response From parameter e.g. to "*" - the first response received will be the one returned"
In reviewing everything within the Business Process, I finally found that in my CALL requests that the response actions were not always filled in. So I am working through those now.
However I am seeing something weird with when a Router sends to the Business Process. Do I need to do something in the Business Process to send a response back to the Router?
1. I would stay away from Modifying the current EnsLib.HL7.SearchTable if at all necessary. Modifying the source code could lead to consequences down the road, especially when you upgrade it might get overwritten. What I did was that I copied the existing code and modified it for our use. That way we can add and remove fields anytime we want.
Class osuwmc.HL7SearchTable Extends (%Persistent, Ens.VDoc.SearchTable) [ ClassType = persistent, CompileAfter = EnsLib.HL7.Message, Inheritance = right, ProcedureBlock, System = 4 ]
{
Parameter DOCCLASS = "EnsLib.HL7.Message";
Parameter EXTENTSIZE = 4000000;
/* Re-declare indices because the superclass is abstract */
Index indexValue On (PropId, PropValue, DocId) [ IdKey, Unique ];
Index indexDocId On (DocId, PropId, PropValue) [ Unique ];
Yeah tracking down the messages is the hardest part in trying to figure out what is causing it. I am trying to hunt down the problems by using the TimeCreated from EnsLib.HL7.Message and looking for messages around the timeframe of the message in question.
Others have told us that a message always needs to go somewhere, so does that mean if we use a "WHEN" statement within a Router that we should use OTHERWISE too if the message hits the rule but it is not used?
I am not sure I am following what you are trying to do. In my experience with calling stored procs from an external SQL database, I have always returned a RETURN value to tell me if the procedure executed successfully.
I have done a few cases that MS SQL Server assigned a Identity value after the stored procedure executed. In that case I define the output as Output pResponse As EnsLib.SQL.Snapshot within the Method definition, then I will return/loop through the EnsLib.SQL.Snapshot within the Business Process to get the value I need.
Method FetchHospitalEntityKSp(pRequest As osuwmc.CPD.DataStructures.FetchHospitalEntityK, Output pResponse As EnsLib.SQL.Snapshot) As %Status
{
set SPQuery = "{ ?= call CPD.dbo.usp_Interfaces_Fetch_HospitalEntityK_Ens(?) }"
s parm=2
s parm(1,"SqlType")=$$$SQLVARCHAR
s parm(1,"IOTypes")=$$$SQLPARAMOUTPUT
s parm(2)=pRequest.Entity
s parm(2,"SqlType")=$$$SQLVARCHAR
s parm(2,"IOTypes")=$$$SQLPARAMINPUT
set tSC = ..Adapter.ExecuteProcedureParmArray(.FetchEntities,.outputs,SPQuery,"oi",.parm)
If the Stored Procedure is just returning a RETURN statement then you should not need to define it in tQuery. So I am imagining that it would look something like this... If you are returning something other than just the RETURN statement from the Stored Procedure it will be a little different.
set arrParam = 2
//for input and output parameter set arrParam(1,"IOType") = 2 set arrParam(1,"SqlType") = $$$SqlLongVarchar
//for input parameter set arrParam(2)= Message set arrParam(2,"SqlType") = $$$SqlLongVarchar set arrParam(2,"CType") = $$$SqlWChar set arrParam(2,"IOType") = 1 set arrParam(2,"Prec") = 8000 set arrParam(2,"LOB") = 1 set arrParam(2,"UseLOBLen")= 1 set arrParam(2,"SqlTypeName") = "TEXT"
Set tQuery="{?=call dbo.sp_insertMessage(?) }"
Set tSC = ..Adapter.ExecuteProcedureParmArray(.InsertMessage,.tOutParams,tQuery,"oi",.arrParam)
I am receiving the same error trying to launch Studio from HealthShare Health Connect IRIS 2022.2 from my local PC to connect to the server. So we can't have two versions of Intersystems running on the same PC. I have both HealthShare HealthConnect 2018.1.3 and Health Connect IRIS 2022.2?
go to post
Yes, I was able to create separate roles, and copy the existing Data Lookup pages, locking the users down to only being able to access that particular page for their lookup tables. There are two class files that would need to be created.
1. Filter Dialog if you want to limit the users down to their particular tables.
2. A copy of EnsPortal.LookupSettings - which will limit users ability to get to other places within Ensemble.
I haven't tested this in IRIS just yet as we are in the process of moving to IRIS.
go to post
If a Business Router is sending to a file based HL7 operation, I am seeing NULL values being returned. How can I tell the system that if we are sending a message to a File Based HL7 Business Operation that I don't expect a Return and avoid receiving the NULL value back?
go to post
Thanks that helped a lot. However I am seeing when I make a call to send the HL7 message to an operation, the callresponse is coming back NULL. Is there a way to send the message but make the process think we don't need a response back?
Can you show me a screen shot of what you mean by
"Routing rules that are called synchronous respond with a "NULL" message when the Response From parameter is empty.
The fix was to set the Response From parameter e.g. to "*" - the first response received will be the one returned"
go to post
In reviewing everything within the Business Process, I finally found that in my CALL requests that the response actions were not always filled in. So I am working through those now.
However I am seeing something weird with when a Router sends to the Business Process. Do I need to do something in the Business Process to send a response back to the Router?
go to post
1. I would stay away from Modifying the current EnsLib.HL7.SearchTable if at all necessary. Modifying the source code could lead to consequences down the road, especially when you upgrade it might get overwritten. What I did was that I copied the existing code and modified it for our use. That way we can add and remove fields anytime we want.
Class osuwmc.HL7SearchTable Extends (%Persistent, Ens.VDoc.SearchTable) [ ClassType = persistent, CompileAfter = EnsLib.HL7.Message, Inheritance = right, ProcedureBlock, System = 4 ]
{
Parameter DOCCLASS = "EnsLib.HL7.Message";
Parameter EXTENTSIZE = 4000000;
/* Re-declare indices because the superclass is abstract */
Index indexValue On (PropId, PropValue, DocId) [ IdKey, Unique ];
Index indexDocId On (DocId, PropId, PropValue) [ Unique ];
XData SearchSpec [ XMLNamespace = "http://www.intersystems.com/EnsSearchTable" ]
{
<Items>
<Item DocType="" PropName="MSHTypeName" Unselective="true">{1:9.1}_"_"_{1:9.2}</Item>
<Item DocType="" PropName="MSHControlID" PropType='String:CaseSensitive' >{1:10}</Item>
<Item DocType="" PropName="PatientID" >[PID:2.1]</Item>
<Item DocType="" PropName="PatientID" >[PID:3().1]</Item>
<Item DocType="" PropName="PatientID" >[PID:4().1]</Item>
<Item DocType="" PropName="PatientName" >[PID:5()]</Item>
<Item DocType="" PropName="PatientAcct" >[PID:18.1]</Item>
<Item DocType="" PropName="Order#" >[ORC:2.1]</Item>
<Item DocType="" PropName="Order#" >[SCH:26.1]</Item>
<Item DocType="" PropName="Order#" >[ZOR:1]</Item>
<Item DocType="" PropName="Accession#" >[ORC:3.1]</Item>
<Item DocType="" PropName="SIUVisitType">[AIS():3.1]</Item>
<Item DocType="" PropName="SIUProvider#">[AIP():3.1]</Item>
</Items>
}
Storage Default
{
<Data name="HL7SearchTableDefaultData">
<Value name="1">
<Value>%%CLASSNAME</Value>
</Value>
</Data>
<DataLocation>^osuwmc.HL7SearchTableD</DataLocation>
<DefaultData>HL7SearchTableDefaultData</DefaultData>
<ExtentSize>4000000</ExtentSize>
<IdLocation>^osuwmc.HL7SearchTableD</IdLocation>
<IndexLocation>^osuwmc.HL7SearchTableI</IndexLocation>
<StreamLocation>^osuwmc.HL7SearchTableS</StreamLocation>
<Type>%Library.CacheStorage</Type>
}
}
go to post
Yeah tracking down the messages is the hardest part in trying to figure out what is causing it. I am trying to hunt down the problems by using the TimeCreated from EnsLib.HL7.Message and looking for messages around the timeframe of the message in question.
Others have told us that a message always needs to go somewhere, so does that mean if we use a "WHEN" statement within a Router that we should use OTHERWISE too if the message hits the rule but it is not used?
go to post
I am not sure I am following what you are trying to do. In my experience with calling stored procs from an external SQL database, I have always returned a RETURN value to tell me if the procedure executed successfully.
I have done a few cases that MS SQL Server assigned a Identity value after the stored procedure executed. In that case I define the output as Output pResponse As EnsLib.SQL.Snapshot within the Method definition, then I will return/loop through the EnsLib.SQL.Snapshot within the Business Process to get the value I need.
Method FetchHospitalEntityKSp(pRequest As osuwmc.CPD.DataStructures.FetchHospitalEntityK, Output pResponse As EnsLib.SQL.Snapshot) As %Status
{
set SPQuery = "{ ?= call CPD.dbo.usp_Interfaces_Fetch_HospitalEntityK_Ens(?) }"
s parm=2
s parm(1,"SqlType")=$$$SQLVARCHAR
s parm(1,"IOTypes")=$$$SQLPARAMOUTPUT
s parm(2)=pRequest.Entity
s parm(2,"SqlType")=$$$SQLVARCHAR
s parm(2,"IOTypes")=$$$SQLPARAMINPUT
set tSC = ..Adapter.ExecuteProcedureParmArray(.FetchEntities,.outputs,SPQuery,"oi",.parm)
if tSC = 1
{
set pResponse = FetchEntities.GetAt(1)
}
quit tSC
}
go to post
If the Stored Procedure is just returning a RETURN statement then you should not need to define it in tQuery. So I am imagining that it would look something like this... If you are returning something other than just the RETURN statement from the Stored Procedure it will be a little different.
set arrParam = 2
//for input and output parameter
set arrParam(1,"IOType") = 2
set arrParam(1,"SqlType") = $$$SqlLongVarchar
//for input parameter
set arrParam(2)= Message
set arrParam(2,"SqlType") = $$$SqlLongVarchar
set arrParam(2,"CType") = $$$SqlWChar
set arrParam(2,"IOType") = 1
set arrParam(2,"Prec") = 8000
set arrParam(2,"LOB") = 1
set arrParam(2,"UseLOBLen")= 1
set arrParam(2,"SqlTypeName") = "TEXT"
Set tQuery="{?=call dbo.sp_insertMessage(?) }"
Set tSC = ..Adapter.ExecuteProcedureParmArray(.InsertMessage,.tOutParams,tQuery,"oi",.arrParam)
go to post
When I click on "ClassSize query" I am getting a 404 error. Can this link be updated so I can duplicate this?
go to post
I am receiving the same error trying to launch Studio from HealthShare Health Connect IRIS 2022.2 from my local PC to connect to the server. So we can't have two versions of Intersystems running on the same PC. I have both HealthShare HealthConnect 2018.1.3 and Health Connect IRIS 2022.2?