I'm investigating HL7-FHIR for use in a decision support context and was trying to find out how to extract accident information for a given patient. I had assumed this would be a resource type but I can't find anything that fits.
We don't have a specific resource for this information. Mostly, this sounds like a series of observations, and perhaps a context linking them together. It's the context piece that we haven't yet got (our initial focus was on PHR). That will definitely be in the next version, but for now, I guess you just use the observations directly
Related
Events in an event store (event sourcing) are most often persisted in a serialized format with versions to represent a changed in the model or schema for an event type. I haven't been able to find good documentation showing the actual model or schema for an actual event (often data table in event store schema if using a RDBMS) but understand that ideally it should be generic.
What are the most basic fields/properties that should exist in an event?
I've contemplated using json-api as a specification for my events but perhaps that's too "heavy". The benefits I see are flexibility and maturity.
Am I heading down the "wrong path"?
Any well defined examples would be greatly appreciated.
I've contemplated using json-api as a specification for my events but perhaps that's too "heavy". The benefits I see are flexibility and maturity.
Am I heading down the "wrong path"?
Don't overlook forward and backward compatibility.
You should plan to review Greg Young's book on event versioning; it doesn't directly answer your question, but it does cover a lot about the basics of interpreting an event.
Short answer: pretty much everything is optional, because you need to be able to change it later.
You should also review Hohpe's Enterprise Integration Patterns, in particular his work on messaging, which details a lot of cases you may care about.
de Graauw's Nobody Needs Reliable Messaging helped me to understan an important point.
To summarize: if reliability is important on the business level, do it on the business level.
So while there are some interesting bits of meta data tracking that you may want to do, the domain model is really only going to look at the data; and that is going to tend to be specific to your domain.
You also have the fun that the representation of events that you use in the service that produces them may not match the representation that it shares with other services, and in particular may not be the same message that gets broadcast.
I worked through an exercise trying to figure out what the minimum amount of information necessary for a subscriber to look at an event to understand if it cares. My answers were an id (have I seen this specific event before?), a token that tells you the semantic meaning of the message (is that something I care about?), and a location (URI) to get a richer representation if it is something I care about.
But outside of the domain -- for example, when you are looking at the system as a whole trying to figure out what is going on, having correlation identifiers and causation identifiers, time stamps, signatures of the source location, and so on stored in a consistent location in the meta data can be a big help.
Just modelling with basic types that map to Json to write as you would for an API can go a long way.
You can spend a lot of time generating overly complex models if you throw too much tooling at it - things like Apache Thrift and/or Protocol Buffers (or derived things) will provide all sorts of IDL mechanisms for you to generate incidental complexity with.
In .NET land and many other platforms, if you namespace the types you can do various projections from the types
Personally, I've used records and DUs in F# as a design and representation tool
you get intellisense, syntax hilighting, and types you can use from F# or C# for free
if someone wants to look, types.fs has all they need
Background:
I have been digging into the FHIR DSTU2 specification to try and determine what is the most appropriate resource(s) to represent a particular patient's historical list of GPs/PCPs. I am struggling to find an ideal resource to house this information.
The primary criteria I have been using is to identify the proper resource is that it must provide values to associate a patient to a practitioner for a period of time.
Question:
What is the proper resource to represent historical pcp/gp information that can be tied back to a patient resource?
What I have explored:
Here is a list of my possible picks thus far. I paired the resource types with my thought process on why I'm not confident about using it:
Episode of Care - This seems to have the most potential. It has the associations between a patient and a set of doctors for a given time period. However, when I read its description and use-case scenarios, it seems like I would be bastardizing its usage to fit my needs, since it embodies a period of time where a group of related health care activities were performed.
Group - Very generic structure that could fit based on its definition. However, I want to rule out other options before taking this approach.
Care Plan - Similar to Episode of Care rational. It seems like a bastardization to just use this to house PCP/GP history information. The scope of this is much bigger and patient/condition-centric.
I understand that there may not be a clear answer and thus, the question might run the risk of becoming subjective and I apologize in advance if this is the case. Just wondering if anyone can provide concrete evidence of where this information should be stored.
Thanks!
That's not a use-case we've really encountered before. The best possibility is to use the new CareTeam resource (we're splitting out CareTeam from EpisodeOfCare and CarePlan) - take a look at the continuous integration build for a draft.
If you need to use DSTU 2, you could just look at Patient.careProvider and rely on "history" to see changes over time. Or use Basic to look like the new CareTeam resource.
I need to change an existing system (written in Python using python-hl7) to accept messages with details of a surgical procedure for a patient and then record those details in a database as part of their medical record. This question is more about HL7 (v2) than Python or python-hl7, though. I couldn't find a better Stack Exchange "community" to post this in.
What message types, segments should be used to record details of a surgical procedure. e.g. what procedure was done, when it started and ended, what the outcome was, where it took place, who the primary and assistant surgeons were, etc.
From what I've been able to find so far it seems some sort of ADT message (e.g. A04) with a PR1 segment should be used. Is this correct? Are there example messages?
Thanks.
EDIT: To be clear I am not looking for Python examples. I am looking for sample HL7 messages to get an idea of how other people do it. Of course clear and unambiguous documentation that says exactly what fields are required and exactly what they can/should contain would also help.
It's very unlikely that you can find a single message that covers everything related to surgery (ORU is the closest one). In general surgery is type of Act similar to other events that may happen with the patient. For that reason you need to decide what you are looking for since a “surgery” can be divided into admission/discharge/transfer (ADT), scheduling (SIU, OMS), patient summary (MDM), preoperative (MFN, ORU), intraoperative (ORU, DFT), postoperative (ORU, MDM, DFT, MFN).
Exact type and place of the surgery can be specified by ICD-10 or SNOMED CT.
I have developed a Linux/Umbutu program running on what will be an imbedded P-based device. I wish for that piece of code to be able to send and receive the SNMP data for the entire product. So, I know the OID down to the company level, 1.3.6.1.4.1.34843, and I further know that the two SNMP enabled products we sell are 1.3.6.1.4.1.34843.1 and 1.3.6.1.4.1.34843.2. Pretty sure mine will be .3.
The question is, is there a known structure/convention for the nodes below this point? What I read seems to imply that I can use whatever structure I want. Would ...34843.1.0 exist? Is it a node to fetch (get) the list or max-count of same-level nodes? Would ...34843.1.0.0 exist? Would it make any sense? The guy who developed the first two MIBs is out of town for a while and I can't really ask him, and I'd like to make sure I understand his answer when he gives it to me.
Is there a document that describes the required/suggested organization? Probably some RFC, right. So, is there a document in a language spoken by humans?
Thanks in advance.
The most popular resource is the understanding SNMP MIBs book by Perkins and McGinnis. It describes MIBs in a more readable format. The Net-SNMP tutorials online might be helpful too, as they discuss a lot about MIBs. If you want the RFC, then RFC2578 is the right thing to read.
The quick hierarchy guidance would be something along the lines of:
Use 3 sections: one for objects, one for notifications, and one for conformance information
For notifications, root them at the .0 (see RFC3584 for details on why)
For each table, you might want a scalar showing the number of objects in a table and potentially a LastChanged object for showing how frequently configuration within the table might have changed).
There is a lot more guidance that can be found in the books and other sources listed above than can be repeated here, of course. RFCs 4181, and 5249 may be helpful as well.
What is the quickest way to isolate the source of an error amongst an ordered list of potential sources? For example, given a list of column mappings, and one of those column mappings is incorrect, what debugging technique would lead you to most quickly identify which mapping is invalid? (By most quickly, I mean, which approach would require the fewest compilation, load, and run cycles?)
Assume that whatever error message the database or database driver generates does not identify the name of the errant column. Sound familiar?
Hint:
The technique is similar to that which you might use to answer the question, "What number am I thinking of between 1 and 1000?", but with the fewest guesses.
You can use interpolation in some cases. I've used this successfully to isolate a bad record.
Sounds familiar, but I hate to be the one to tell you that there is no "quick" way of isolating the sources of errors. I know from my own experience that you want to be absolutely sure you've found the correct source of error before you go about resolving it, and this requires plenty of testing and tracing.
Keep adding more and more diagnostic information until I either isolate the issue, or can't add anymore. If it's my code vs. external code, I will go crazy with trace statements until I isolate the critical bit of code if I otherwise don't know where the issue is. On Windows, the SysInternals suite is my friend... especially the debug viewer. That will show any trace statements from anything running on the system that is emitting trace.
If I truly cannot get more specific information from the error source, then I will go into experimental mode... testing one small change at a time. This works best if you know you have a case that succeeds and a case that does not.
Trivial example: If I have row X that won't be inserted into the database, but I know row Y will, I will then take row Y and change one field at a time and keep inserting until row Y's values = row X's value.
If you really are stumped at where the issue is coming from, time to dust off your Google-fu skills. Someone has probably run into the same problem and posted a question to a forum somewhere. Of course, that's what SO is for too.
You're the human... be more stubborn than the computer!