go to post Jorge de la Garza · Jan 2, 2018 Here's a routine I use to restart a particular host in the production:RestartEnsHost(pName) set tSC = ##class(Ens.Director).EnableConfigItem(pName,0) if 'tSC write !, $system.Status.GetOneErrorText(tSC), !! quit set tSC = ##class(Ens.Director).EnableConfigItem(pName,1) if 'tSC write !, $system.Status.GetOneErrorText(tSC), !! quit quit
go to post Jorge de la Garza · Oct 10, 2017 I don't have any specific suggestions for the Developer Community, but I really like what this post says about how the manual should be built in to the experience:https://blog.codinghorror.com/level-one-the-intro-stage/
go to post Jorge de la Garza · Oct 3, 2017 Hi Krystian,I understand now, you mean you want to extend the FHIR data model, rather than use the "extension" property in the FHIR core spec. Extending the data model is not something that is supported in the 15.03 release of HealthShare Core, but currently we are planning to support this in the next release. However, even when this is supported, we will actually encourage users to use the "extension" property for simple extensions, rather than extending the data model. This is a sentiment shared by much of the FHIR community, based on their collective experience with extensions.
go to post Jorge de la Garza · Sep 29, 2017 Hi Krystian, are you referring to the "extension" property in the data model? If so, then that is currently supported by FHIR repository in HealthShare. Resources can be created in the repository with extensions and these will be saved. I'm attaching an example of a patient resource that contains multiple extensions. Note that this is a DSTU2 resource, which is the FHIR version that HealthShare currently supports. The current version of FHIR is STU3. HealthShare will support this in a future release.EDIT: I *thought* I could attach a file, but that seems not to be the case. In any event, you can download the FHIR DSTU2 examples directly from the hl7.org site as XML or JSON:http://hl7.org/fhir/DSTU2/examples.ziphttp://hl7.org/fhir/DSTU2/examples-json.zipAnd you can look through those for examples of extensions.
go to post Jorge de la Garza · Sep 27, 2017 Hi Conor,The issue is that HealthShare does not support CORS requests against FHIR endpoints that are secured with standard Caché authentication. So if you look at the Network tab in your browser's developer tools, you'll see that before your browser sends the GET request to that URL, it sends an OPTIONS request to that same URL. HealthShare responds with a 404, and what the browser actually complains about is the response missing some headers that are expected in a CORS response.For an endpoint to support CORS, the authentication in the CSP application settings for the endpoint has to be set to "Unauthenticated". If you're just developing or trying out FHIR, this is fine. In production, the expectation is that this endpoint would be secured via OAuth.
go to post Jorge de la Garza · Sep 6, 2017 Hi Tom, HealthShare provides transforms between FHIR and SDA (the format HealthShare Information Exchange uses to store and transport patient data internally), as well as Ensemble Business Processes that call into these transforms. So if you wanted to feed FHIR data into Information Exchange, and your FHIR data were in patient-centric bundles, then one thing you could do is, implement a REST handler in a HealthShare Edge Gateway namespace that marshalls the FHIR request into an Ensemble request. You can look at HS.FHIR.REST.Handler for an example of how to do this, but I would recommend against trying to use this class as your REST handler. It does things that are specific to a FHIR namespace. Have the REST handler dispatch the request to a service in the Edge production, which should pass the request on to HS.FHIR.ToSDA.DTL.Transaction.Process. This will transform the FHIR bundle in an SDA container, which can be processed normally into the HealthShare Edge gateway. Note that if you decide to do this, you are essentially creating a FHIR endpoint that is write-only. The original FHIR resource cannot be read from that endpoint. Though technically, it isn't really even a FHIR endpoint unless it can serve up a conformance statement.You can read more about transforming between FHIR and SDA here:http://host:port/csp/docbook/DocBook.UI.Page.cls?KEY=FOVW_fhir#FOVW_fhir...
go to post Jorge de la Garza · Sep 5, 2017 Hi Tom, can you describe how you created the FHIR namespace? Also, I'm pretty sure the version of HSCore you're using is 15.03, but could you also include the full version string, for future reference?My guess is that you are trying to interact with a FHIR Gateway namespace, which does not support the create interaction from clients.Basically, HealthShare currently supports two types of FHIR namespaces. The first is a regular FHIR reference server, that supports most of the FHIR DSTU2 standard, including create, read, update, delete, search, history, and vread interactions. However, this server is not a part of the HealthShare federation in any way. It neither sends data to nor receives data from the rest of HealthShare.The other type of FHIR namespace is what is known as a FHIR Gateway. Clients interact with it by first starting a session (there are different ways of doing this), then, within that session, loading a patient's data from the HealthShare Information Exchange into the FHIR Gateway by doing a read on that patient (where ID=the patient's MPIID from Information Exchange). Then queries that are explicitly scoped to that patient via search parameter may be submitted to the FHIR endpoint. Clients may not create resources on the FHIR Gateway. Data can only be loaded into the FHIR Gateway from Information Exchange. Clients can only see data in their session, and after a session ends, any data in that session is physically deleted.You can find more information about the FHIR Gateway in the HealthShare documentation:http://<host>:<port>/csp/docbook/DocBook.UI.Page.cls?KEY=HESUP_fhirOr, if you have any specific questions, I'd be happy to answer them here.
go to post Jorge de la Garza · Jul 19, 2017 In %SQL.StatementResult, do not use %Get to get columns by name, instead just reference the properties directly, e.g. 'Write resultOref.Name' instead of 'Write resultOref.%Get("Name")'Just curious. What is the reason for this?
go to post Jorge de la Garza · Jun 28, 2017 Hi Joao,Probably what has happened is you've corrupted the resource storage by doing a physical delete against the storage table. If you need to delete a resource in the resource repository, the correct way to do this is via the delete interaction:http://hl7.org/fhir/DSTU2/http.html#deletehttp://hl7.org/fhir/STU3/http.html#deleteSTU3 is the current version of FHIR. The version currently supported by HealthShare is DSTU2.
go to post Jorge de la Garza · Jun 7, 2017 "The only reason I can think of, why we do this, is to ..."I can think of one other reason for this pattern, that is perhaps better illustrated if we think of "Film" as a code table, and change the name of "CinemaFilm" to something like "Showing". In the entire world there is only one movie called "Wonder Woman", released in 2017, and starring Gal Godot. So rather than reproducing this object thousands of times for every cinema that happens to be showing this movie, the object exists once in the "Film" code table,
go to post Jorge de la Garza · Mar 22, 2017 Hi Surya,HealthShare has no single transform that can convert from HL7 to FHIR. Rather, what you would do is, first convert the HL7 to an SDA3 container via the Ensemble operation HS.Gateway.HL7.InboundProcess, then convert the SDA3 container into a FHIR bundle via the process HS.FHIR.FromSDA.DTL.Transaction.Process.
go to post Jorge de la Garza · Jan 10, 2017 One of the very first things I learned about programming as a wee lad taking Computer Science in high school is that GOTOs should be avoided, as they lead to what the textbook called "spaghetti code". XKCD agrees, but for a different reason:https://www.xkcd.com/292/
go to post Jorge de la Garza · Nov 16, 2016 I suspect this can be done in v3, but I will have to defer to my colleagues who are experts on it.
go to post Jorge de la Garza · Nov 10, 2016 Hi Scott,One way you could do this is via an MDM^T02 HL7 message. There is actually an example message containing a PDF document distributed with HealthShare: <install-directory>\Data\Scenario_4.hl7The document data is encapsulated in a series of OBX segments:OBX||ED|||^^PDF^Base64^JVBERi0xLjINCiXi48/TDQolICAgICAgICAgIA0KJTEwMDIzMFszMl0NCjEgMCBvYmogDTw8DQovThe critical pieces of this are:OBX-2: Must be "ED" for "Encapsulated Data"OBX-5.3: Must be the file type. In this case it's "PDF". If you want to view this document in the HealthShare Clinical Viewer, then you can find a list of supported doc types at websys.Document:ValidTypes in the Access Gateway namespace.OBX-5.4: Must be "Base64" if the data is base64-encoded, otherwise it can be left blank.OBX-5.5: The document dataBest,Jorge
go to post Jorge de la Garza · Nov 2, 2016 I know of no such built in tool, however here's a routine I wrote to pretty print an XML string: PrettyPrintXML(pXML) for tI = 1:1:10 { write ! } set tTabCount = 0 // if starting with an XML prolog, do not increment tab on next line if ($E(pXML,1,5)="<?xml") { set tI = $FIND(pXML,">") set $EXTRACT(pXML,tI-1) = ">"_$C(13,10) } else { set tI = 1 } for { set tI = $FIND(pXML,"<",tI) quit:tI=0 //cdata if ($EXTRACT(pXML,tI,tI+7)="