This is not an answer, more of a comment, however, there is no harm in considering a mix and match here. For instance, you consider still having a sub-transform for the client elements and still having a separate xsd import for the client XML. Just a thought!
Hi Stephen
The short answer is yes.
The more fuller answer is to talk with your local, friendly Sales Engineer. They will be able to provide you sample code to send and receive via MESH. Or let me know where you are from and I will find out!
Thanks!
Tom.
I just want to provide something on the What is FHIR part of the question in case anyone else stumbles on this page like I just have! FHIR stands for Fast Healthcare Interoperability Resources. It is built on REST web services, where the URL identifies a resource (a patient, a diagnosis, etc., etc.), the URL /fhir/patient/123, for instance refers to the patient with an ID of 123. The HTTP Verb used indicates what you want to do, GET (returns that resource), DELETE (deletes the resource) and so on. The world of FHIR is massive and I would encourage tools such as google to investigate further.
And as Mark has stated FHIR support is a native element of HealthShare and there are lots of our resources on our FHIR support.
Jason
I am a product manager at InterSystems looking at our HealthShare family of products. In particular though, given, that I live in the UK I look for features that could form part of our UK Edition of HealthShare. As part of this work I can happily share with you that it is absolutely our intention to support the Care Connect FHIR profiles. Whilst I can not currently give you firm plans and dates our intention at this point it to augment the standard DSTU2 FHIR based to & from SDA DTL's, with ones that also convert to & from CareConnect based FHIR resources.
Associated with that we are likely going to need to extend our SDA model, although many of the extensions we have already looked at are already part of our SDA model. Once the information was in SDA then it would certainly be very easy for you to write a DTL to create a HL7 message. Once we have that our intention would then be to provide a higher level set of transformations from SDA in to & from Care Connect FHIR to support the Transfer of Care and other national initiatives.
However, whilst this is our current intention this could be very easily be changed once our customers start giving us input on our proposed solutions. Therefore if you or anyone else feels like they have anything to contribute to this support do feel free to drop me a mail. I am sure you can get it from DC, but just in case it is tom.spencer@intersystems.com.
In the mean time I will do some preliminary work on how this could be supported and share that with Mark Massias.
Best Regards
Tom.
Hi Sam
I am afraid, and this is likely my ignorance, I do not fully understand what you are doing here. Why is it you feel the need to create such a translation profile and what are the source and target coding systems? What are you expecting to achieve here when all said and done?
It is relatively unlikely I know the answer, but I suspect those that do may also be staring at this and will not quite understand the question!
Thanks!
Tom.
For the first part of the question, the answer does depend somewhat on which HealthShare product is in use. If this is HealthConnect then all the authentication options are available to be used (OS Based, Kerberos, Cache logins, LDAP and delgated). LDAP (of which active directory is an example, but it does not have to be AD) is probably the best bet for sharing credentials between instances. In essence, setup the LDAP server, create your users in their and then configure Cache to use that. See the following documentation entry, which given default installation would be:
http://localhost:57772/csp/docbook/DocBook.UI.Page.cls?KEY=GCAS_LDAP (Adjust server/port as appropriate)
If the product is Information Exchange then HealthShare employs a delegated authentication approach. This means that HealthShare comes with a ZAUTHENTICATE routine, which allows you to write a security domain class that can do whatever! All login requests are routed to the registry for evaluation. If you want to combine both LDAP/AD and HealthShare then take a look at HS.Registry.Person.User.HSAuthLDAPSample! This sample could be modified to check the credentials on another HealthShare instance (just remember if you do this and use web services for the inter-HS calls to secure the traffic with SSL/TLS or similar!)
http://localhost:57772/csp/docbook/DocBook.UI.Page.cls?KEY=GCAS_LDAP
Once you have the accounts in one place, hopefully your analysis job becomes easier. Within Cache I would always look to DeepSee for analysis, but if you were using AD then maybe there are other tools I do not know about!
Hi Bob
Could you just clarify the HealthShare products you are using, is it Personal Community or is it information Exchange. Connecting up a new source of information for display back to clinicians or to citizens is normally a task performed in the Information Exchange. There is a very useful book in the documentation that will take you through the mechanics of this, which assuming default installation parameters would be:
http://localhost:57772/csp/docbook/DocBook.UI.Page.cls?KEY=HEDAT
Obviously adjust the host/port as appropriate if not using the defaults.
That said I am not 100% sure this specifically answers your question. Please just let us know if it does not.
Thanks!
Tom.
There are in fact a number of ways to look at this.
At a very simple level the patient record itself should be considered a virtual record that is aggregated on-demand from all sources. However, do not think that notifications are impossible as the Information Exchange provides rich functionality to notify systems and people.
When any information comes into the exchange ultimately it is turned into SDA. At that point there is rich functionality to notify based upon what it is. There are 3 levels to this. First there is a topic filter that allows you to filter on the key information in the message (such as what the trigger for the message was, an admission or transfer perhaps). The next is a detail filter that allows you to further notify based on any part of the incoming SDA. So if you want to trigger on receiving SDA with the value of XYZ in some field, then you can. The final element is in conjunction with Health Insight to look at the current state of the patient. So if you wanted to notify if a lab result has abnormal values relative to the 'normal' for this patient, then you can!
Once a trigger is made the notification itself can be pretty much anything. It could for instance be a transformation of the incoming message to a PDF and emailed to a particular clinician, or it could be a transformation of the entire patient record into say a C-CDA and then sent for ingestion into another system the care providers use. The world is pretty much your oyster here!
Thanks!
Tom.